Your choice for security monitoring and/or threat detection technologies for different cloud models (SaaS, PaaS, IaaS) is, essentially:
- Use the security controls that your cloud service provider (CSP) offers … but for many CSPs these are really shitty [or worse!], and even if they are great – they only work for this one provider. Does anybody who uses cloud use just ONE provider?
- Use legacy controls that you have deployed on-premise (SIEM, DLP, NIPS, EDR, UEBA, etc)… but prepare to fight many technology and process hurdles and incompatibilities. If you think vendors will adapt to cloud technology peculiarities, do you think them won’t trip over devops and cloud-style operational processes?
- Use native “built for the cloud” security tools (CASB, CWPP, cloud log management, etc)…. but accept that you will lose the single view across old and new environments. Would you like to check 2 consoles for every task and have little visibility across?
Naturally, in reality, the combinations are very likely. Just as naturally, for every organization it depends on its approach to cloud adoption and usage (e.g. “fork-lifters” tend to like #2, while some “cloud-firsters” may gravitate to #3)
But, overall, are we thinking about it the right / useful way? What do you think? Vendors, you are also welcome to argue your position here in comments or here.
Related blog posts on cloud security:
- Cloud Threat Detection Research (2017)
- Cloud Security Monitoring … Revisited (aka It Is Not 2012 Anymore!) (2015)
- My Cloud Security Monitoring Paper Publishes! (2012 – as are all the posts below)
- 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
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
4 Comments
Anton,
I would agree with the concerns highlighted here but I will focus on what clearly became a massive pain point to many of the environments I worked with.
Logging.
In terms of SIEM, the move to the cloud has been incredibly painful.
Many vendors used IPs as primary identifiers for processing logs but in the cloud, IPs are worth far less than instance IDs and instance IDs far less than metadata that can be used to associate with a business application. But hey! then we got containers! 🙂
Add to that to the fact that many cloud logs are pull, instead of push and horror follows. Many SIEMs are just terrible at pulling data.
The way we ended up going was to use a “ETL” mechanism (Apache NiFI) to bolt things together but the more we progressed the more we realised we were doing more and more of the SIEM’s job within the ETL pipeline. So at one point we decided to go “SIEM’less” and plan to do some of the correlation job ourselves.
It is now a journey to the fainted hearts but I reckon that until a SIEM vendor goes truly cloud ready, there is very little that can be done. In addition I wouldn’t be surprised the same will happen with UEBA vendors. The more things goes to the cloud the more important metadata and flexibility become. UEBA algos will have to cater for that.
Cheers
Disclaimer:
Since starting this journey I became an Apache NiFi PMC member.
Indeed, IP – based assets and non-scalable log pull (GET 100 TB file, repeat in 5 min, ask for a diff…ha-ha) are shitty in the cloud. But as APIs improve, the second problem may get fixed and it won’t req a new tool category….
Not sure how well SIEM vendors are doing at processing API data in the same way CASBs do but it wouldn’t take a leap of faith by them to promote ‘native cloud inter-operability’ by building, acquiring or piggy-backing through CASB partnership this type of capability (to form API connections and consume usage, audit and security data for the purposes of security analysis, alerting and reporting). This of course assumes that it’s far easier and more useful to consume API data (SaaS and IaaS) than log data (IaaS only) but the CASB market is a testament to that.
Matt, thanks again for the comment. Indeed, SIEMs read the CASB logs, but then CASB-less customers are out of luck. This is indeed a tricky one, use native logs vs CASB vs both vs some other control….