As you learned from my previous posts related to security monitoring of public cloud assets, there are challenges related to monitoring data availability as well as data interpretation.
IaaS environments – such as the well-known ecommerce-retailer-turned-cloud-provider as well as other cloud service providers (CSPs) – offer an interesting challenge that I call “IaaS conundrum.” To remind, when procuring IaaS resources, the organization essentially buys an ability to deploy their own virtual machines on a public provider network. That means that the cloud customer controls everything from the OS up (and usually has no way of affecting the lower layers) while the cloud provider controls everything under the OS down (and usually does not mess with upper layers).
Herein lies the conundrum: as the cloud customer wishing to monitor the security of your IT assets, do you really NEED access to below-OS layers of the cloud stack?
Two possible answers are:
YES: in physical environments, the enterprise controls the data center, the hardware management and physical access control. The only people who can affect the server at the “below the OS” layers are essentially trusted system administrators. Public cloud deployments create an opaque layer that is not controlled (by definition) and thus MUST be monitored by the cloud customers. In addition, a new cast of characters with “superpowers” – CSP administrators – can affect your environment at the lower layers. These “superheroes” do not serve you – they serve their CSP masters.
NO: just as most security monitoring of physical assets starts at OS (think syslog, anti-malware, access control, application security monitoring), it is OK to accept that monitoring will start at the OS layer. Most of the monitoring tools – as well as security tools in general – have not yet grown to understand virtual and cloud environments, thus notions like “hypervisor security” or “cloud stack introspection” are essentially alien science to them. On top of this, it is challenging, if not impossible for a provider to de-multiplex security monitoring data from shared environments.
What do you think?
If you move anything important to the public cloud, would you require that your provider enable such access for ongoing monitoring?
Alternatively, would you prefer that the provider accept the responsibility for security monitoring of your assets?
Maybe, you have another party – think MSSP – that can take over such security monitoring responsibilities?
Previous cloud security monitoring related posts are:
- Cloud Security Monitoring for IaaS, PaaS, SaaS
- More On Security Monitoring of Public Cloud Assets
- Cloud Security Monitoring!
- Many Faces of Application Security Monitoring (briefly touches on cloud applications)
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
2 Comments
Ideally a cloud service provider which builds a PaaS or SaaS on top of another provider’s IaaS would have insight into the layers of the technology stack (network, physical, environmental, etc) in order to understand the full picture of the security of the environment. However, in the current real world of cloud computing this is not feasible; those logs and that infrastructure below the OS layer are shared with many other PaaS and IaaS vendors; providing transparency to has the potential to provide too much information about the IaaS provider’s other customers thereby decreasing security.
NIST has addressed this to a degree with the FedRAMP initiative, presenting a model which could be leveraged with non-Federal cloud vendors. That is where there are shared responsibilities, or a handoff of responsibilities aka touch points, there needs to be clearly defined and documented security incident response and escalation procedures. In other words the IaaS provider needs to know when to contact a IaaS or PaaS provider or vice versa when an attack or anomaly is detected.
Surely the security relationship between IaaS and PaaS/SaaS providers needs to improve and I have faith it will over time.
\Ideally a cloud service provider which builds a PaaS or SaaS on top of another provider’s IaaS would have insight into the layers of the technology stack (network, physical, environmental, etc) in order to understand the full picture of the security of the environment. \
Thanks for the comment – indeed a CSP that seeks to provide \secure\ PaaS (for some definition of the word) services over an insecure IaaS can build a lot and solve some of the problems. Still, the layers underneath might be sand, not concrete.
And cross-customer information leakage is indeed an argument used by some CSPs to avoid providing the data to customers.
Still, I also hope that in the future more providers will build secure foundations, with more visibility…