A lire sur: http://www.ecommercetimes.com/edpick/79077.html
Is your website up to the challenge of increased holiday traffic
during the biggest online shopping season of the year? Join Compuware
and Things Remembered CIO Mark Lilien, to learn how you can improve your
chances of having a successful online holiday season. Free Webinar – October 17 – Register Today!
In the case of Infrastructure as a Service, the network is outside the scope of your direct control. In the case of Platform as a Service, OS configuration and everything below it is. For Software as a Service, it's everything below the application itself. The reason this is compelling for technologists is that -- assuming everything is done correctly -- abstracting these lower level components allows staff to focus on the areas of most business impact: the applications that the business users interact with directly.
They select those controls according to a number of different factors: the availability of technical tools; staff skill sets; economics; input from other teams; etc. While the level of the stack at which a given threat is likely to manifest certainly influences where a given control is applied, other factors might make implementation at another layer comparatively more advantageous and therefore influence the selection process.
Consider, for example, an organization that seeks to apply encryption to stored data. It has a few options for how to do it: It might decide to implement that control at the application layer -- for example, by authoring application routines that perform the encryption -- it might implement it in the database (column-level encryption), or it might implement it at the OS level (for example, encrypting individual files as they are stored).
In the case of an app developed in-house, maybe it would choose to encrypt at the application level, making use of application APIs to accomplish that. In the case of a COTS application, maybe it would choose to implement at a lower level of the stack instead, because it couldn't modify the application code directly.
What happens when you introduce cloud to a scenario like this one -- for example, if an organization subsequently decides to move an application supported by underlying controls at various levels of the stack into a cloud environment where they only control the stack above a certain demarcation point?
In that case, depending on the type of controls in place and the level of the stack at which they're implemented, they may or may not be able to continue to use that same control. Some controls might become nonviable and fail; others might silently fail and discontinue, providing the risk-mitigation benefits for which they were selected in the first place.
In an ideal world, security practitioners would know about each and every control they'd selected in the past, and understand exactly what the original threat scenarios were that caused them to select that particular control. They'd also know how any given control would or would not be applicable post-cloud. However, as those organizations that have gone through a cloud migration know, the practical challenges with this are legion.
First of all, very seldom is all that information fully documented -- the particular threats that drove a particular control to be selected in the first place are often unclear and difficult to trace. Oftentimes, one particular control may mitigate more than one specific threat. So removing any given control can have a cascading impact throughout multiple applications and threat scenarios.
As organizations initially adopt cloud, as they expand their cloud deployments over time, and as they consider adopting different types of cloud, it's often beneficial to revisit the risk analysis decisions they've made in the past.
Specifically, organizations should look to re-evaluate their threat environment in light of the decisions they've made about cloud to determine where keystone controls may no longer be applicable and what that means to the security of a given application or process as a result.
In doing this, it is also advantageous to employ a systematic, formalized risk management process. Why? Because this is not the first and only time that the control environment is likely to change. For example, if you're revisiting your risk for an IaaS migration today, you may as well capture and leverage application risk information for the PaaS migration that could occur tomorrow.
Going through the exercise of understanding and documenting the threat environment, understanding and documenting controls you've deployed in response, and understanding and documenting residual risk areas that remain can be particularly important as organizations move into a post-cloud world. Moreover, keeping track of these decisions going forward in anticipation of continued changes down the road is a good argument for systematic risk analysis according to a formalized framework.
- See more at: http://www.ecommercetimes.com/edpick/79077.html#sthash.QGxmLZhQ.dpuf
In an ideal world, security practitioners would
know about each and every control they'd selected in the past, and
understand exactly what the original threat scenarios were that caused
them to select that particular control. They'd also know how any given
control would or would not be applicable post-cloud. However, the
practical challenges with this are legion.
Is your website up to the challenge of increased holiday traffic
during the biggest online shopping season of the year? Join Compuware
and Things Remembered CIO Mark Lilien, to learn how you can improve your
chances of having a successful online holiday season. Free Webinar – October 17 – Register Today!
As the prolific trend of
adoption would suggest, the case for cloud is compelling from both a
business and technology perspective. There are a number of reasons for
this, but one of the more compelling reasons from a technologist's point
of view has to do with the ability to abstract lower levels of the
application stack.
Specifically, depending on the model of cloud employed, varying
amounts of the underlying technology components move out of the scope of
your direct control and instead become substrate upon which your
enterprise applications rest.In the case of Infrastructure as a Service, the network is outside the scope of your direct control. In the case of Platform as a Service, OS configuration and everything below it is. For Software as a Service, it's everything below the application itself. The reason this is compelling for technologists is that -- assuming everything is done correctly -- abstracting these lower level components allows staff to focus on the areas of most business impact: the applications that the business users interact with directly.
Cloud Security Levels
Compelling though that is to an IT generalist, it can have unexpected ramifications from a security point of view. Consider how security organizations have historically addressed security issues. Specifically, security and risk professionals often select controls on the basis of overall risk mitigation: They look at a given business process -- including the applications that support that process -- holistically, selecting appropriate controls to mitigate the various threats that the process might be susceptible to.They select those controls according to a number of different factors: the availability of technical tools; staff skill sets; economics; input from other teams; etc. While the level of the stack at which a given threat is likely to manifest certainly influences where a given control is applied, other factors might make implementation at another layer comparatively more advantageous and therefore influence the selection process.
Consider, for example, an organization that seeks to apply encryption to stored data. It has a few options for how to do it: It might decide to implement that control at the application layer -- for example, by authoring application routines that perform the encryption -- it might implement it in the database (column-level encryption), or it might implement it at the OS level (for example, encrypting individual files as they are stored).
In the case of an app developed in-house, maybe it would choose to encrypt at the application level, making use of application APIs to accomplish that. In the case of a COTS application, maybe it would choose to implement at a lower level of the stack instead, because it couldn't modify the application code directly.
What happens when you introduce cloud to a scenario like this one -- for example, if an organization subsequently decides to move an application supported by underlying controls at various levels of the stack into a cloud environment where they only control the stack above a certain demarcation point?
In that case, depending on the type of controls in place and the level of the stack at which they're implemented, they may or may not be able to continue to use that same control. Some controls might become nonviable and fail; others might silently fail and discontinue, providing the risk-mitigation benefits for which they were selected in the first place.
Revisiting Risk Decisions Post Cloud
The reason this matters is twofold: first, as more organizations transition more of their environments to cloud services, the likelihood underlying controls will be obviated increases. Secondly, many have predicted that use of cloud is evolutionary -- meaning that those organizations initially making use of lower-level abstraction models (like IaaS) may over time increasingly favor higher-level abstraction models like PaaS or SaaS. Should that happen, more of the security controls implemented at the lowest levels of the application stack will likewise be obviated. This impacts risk dynamics.In an ideal world, security practitioners would know about each and every control they'd selected in the past, and understand exactly what the original threat scenarios were that caused them to select that particular control. They'd also know how any given control would or would not be applicable post-cloud. However, as those organizations that have gone through a cloud migration know, the practical challenges with this are legion.
First of all, very seldom is all that information fully documented -- the particular threats that drove a particular control to be selected in the first place are often unclear and difficult to trace. Oftentimes, one particular control may mitigate more than one specific threat. So removing any given control can have a cascading impact throughout multiple applications and threat scenarios.
As organizations initially adopt cloud, as they expand their cloud deployments over time, and as they consider adopting different types of cloud, it's often beneficial to revisit the risk analysis decisions they've made in the past.
Specifically, organizations should look to re-evaluate their threat environment in light of the decisions they've made about cloud to determine where keystone controls may no longer be applicable and what that means to the security of a given application or process as a result.
In doing this, it is also advantageous to employ a systematic, formalized risk management process. Why? Because this is not the first and only time that the control environment is likely to change. For example, if you're revisiting your risk for an IaaS migration today, you may as well capture and leverage application risk information for the PaaS migration that could occur tomorrow.
Going through the exercise of understanding and documenting the threat environment, understanding and documenting controls you've deployed in response, and understanding and documenting residual risk areas that remain can be particularly important as organizations move into a post-cloud world. Moreover, keeping track of these decisions going forward in anticipation of continued changes down the road is a good argument for systematic risk analysis according to a formalized framework.
- See more at: http://www.ecommercetimes.com/edpick/79077.html#sthash.QGxmLZhQ.dpuf
Aucun commentaire:
Enregistrer un commentaire