My next project, now that I am done with security analytics for now, is to revisit our cloud security monitoring work. Specifically, some of you remember my 2012 (!) paper “Security Monitoring of Public Cloud Assets”, where I presented these three monitoring architecture choices for your public cloud assets:
- Most Monitoring On-Premises – this is essentially about monitoring the cloud environments by using your traditional on-premise tools, sending cloud logs to your SIEM, etc.
- Most Monitoring on Monitored IaaS – this is about deploying your monitoring tools inside the monitored cloud (only works for IaaS, naturally)
- Most Monitoring via SaaS or Other Third Party [or another cloud] – this one is about using another cloud to monitor your cloud, such as cloud log manager or another monitoring tool (like cloud SWG?)
In reality, back in 2012-2013, by far the most common approach to security monitoring of the public cloud assets was … not to do any. Indeed, while we have seen a tiny number of clients who practiced one or more of the above architectural approaches, most of the rest practiced cloud computing with no security – and thus with no security monitoring. While loud, obnoxious screams “Security FAIL!!” may be heard, the reality is that many organizations used public clouds for stuff that just didn’t matter much, and “no security” was probably about the right amount of security needed. At the same time, industry research seemed to confirm that CSPs were not the source of damaging incidents and “data breaches.”
Boy, have the times changed! The IT media would have us believe that 2010-2012 was the time when “everybody flocked to the cloud” – and I can tell you right away that this is a complete lie. Even now is not the time when everybody uses public cloud computing, and it is most definitely NOT the time when everybody uses cloud for important and business critical stuff. Sure, make no mistake, the use of cloud computing has grown, but mature approaches to security monitoring of the cloud assets are still really, really rare…
Still, I think this research is worth a revisit. Here is what I think really changed – and I would very much welcome your feedback:
- CASB has risen [no, this is not related to Easter at all :-)] – overall cloud monitoring using the “in-between approach” has matured and has (I think) become a primary approach to be added to the above 3, especially for SaaS
- Cloud logging has improved: one word – CloudTrail (one SIEM vendor told me that this was the most requested data sources to integrate in the entire history of their device integration team)
- Monitoring agents to be baked into cloud instances have not become mainstream – while I intend to do more research on this, it seems like “monitor IaaS from the agent” has fizzled [it seemed very promising to me in 2012; BTW, if you are a vendor who can prove me wrong on this one, I am happy to be so proven]
So, got more ideas? Thoughts?
Vendors, want to showcase your relevant technology? Enterprises, got a fun “how I monitored the cloud?” story?
Blog posts related to cloud security monitoring (most from 2012, but still fun!):
- My Cloud Security Monitoring Paper Publishes!
- Webinar on Security Monitoring of Public Cloud Assets
- Cloud Security Monitoring: The “Who” Question
- Is Cloud Secure? WTFC!
- Cloud Security Monitoring: IaaS Conundrum
- Cloud Security Monitoring for IaaS, PaaS, SaaS
- More On Security Monitoring of Public Cloud Assets
- Cloud Security Monitoring!
- Cloud IS Different: So Monitoring Must Be Different?
- Many Faces of Application Security Monitoring
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.