Gartner Blog Network


More Cloud Security Monitoring Contemplations

by Anton Chuvakin  |  April 25, 2017  |  4 Comments

Your choice for security monitoring and/or threat detection technologies for different cloud models (SaaS, PaaS, IaaS) is, essentially:

  1. 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?
  2. 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?
  3. 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:

Category: cloud  monitoring  security  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on More Cloud Security Monitoring Contemplations


  1. Andre F de Miranda says:

    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….

  2. Matt says:

    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….



Comments are closed

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.