Hot Topics

Cloud Security Security Bloggers Network

Home » Cybersecurity » Cloud Security » A SOC Tried To Detect Threats in the Cloud … Your Won’t Believe What Happened Next

A SOC Tried To Detect Threats in the Cloud … Your Won’t Believe What Happened Next

by Anton Chuvakin on May 27, 2021

A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next

Now, we all agree that various cloud technologies such as SaaS SIEM help your Security Operations Center (SOC). However, there’s also a need to talk about how traditional SOCs are challenged by the need to monitor cloud computing environments for threats. In this post, I wanted to quickly touch on this very topic and refresh some past analysis of this (and perhaps reminisce on how sad things were in 2012).

Back in my analyst days, I’ve noticed that some traditional organizations tried to include their cloud environments in the scope of their security monitoring at some point in their cloud migration journeys. Surprisingly (Hey … you surprised about it? No? Thought so!), some of these projects have not gone well. SOC teams were not equipped to deal with various cloud challenges (old paper on this). There were also cases where both business and IT migrated to the cloud, but security was left behind and had to approach cloud challenges with on-premise tools and practices. Essentially, security was left behind … again.

Here, we wanted to quickly summarize some of the challenges, covering the usual range of people, tools, and processes:

Uncommon log collection methods (compared to on-premise systems). Cloud providers haven’t necessarily simplified this journey for customers, even though, compared to 2012, decent logs actually exist today in many cases.
Telemetry data volumes may be high (especially from all those web-facing production systems); this has sometimes led to “log fragmentation” where cloud logs never make it to a SIEM, but are left to rot in some storage buckets in the cloud.
Egress costs are there sometimes, especially if you want to move the logs from one cloud to another for analysis.
Alien licensing models for security tools (compared to on-premise), some teams can’t afford what they used to be able to afford on-premise or they can’t afford a new cloud-native tool in addition to the on-premise tool they already have.
Alien detection context — instances, containers, microservices, etc — has confused many teams born and raised on server names and IP addresses for context. This topic is big enough to be explored in a dedicated post later.
Lack of clarity on cloud detection use cases is there despite useful resources like ATT&CK Cloud. Sadly, cloud providers haven’t necessarily simplified this journey for customers either, and many traditional SOC teams are not sure what to detect in the environments that their business is using today (“is this container access bad?”).
Also, there is a lot of cloud; this means governance sprawl causes visibility gaps for the SOC. Examples include shadow IT (“BYOCloud” and SaaS purchased by departments) as well as other cloud sprawl (that is why people are reaching for all those novel attack surface management tools; this should help).
SOC teams lacking cloud skill in general; complex public/hybrid/multi — cloud scenarios require more extensive knowledge of various technologies, their security implications, diverse (and alien) data sources, while SOC teams are too busy doing D&R to grow their cloud skills.
For those organizations trying to stick to old on-premise tools many other challenges abound; tools don’t support many cloud telemetry sources — they lack collection machinery, parsing/analysis, use cases, useful visuals, etc. Also, log support is often not done at “cloud speed.”
Lack of input from SOCs into cloud decisions, ranging from provider choices to IT architecture (and even security architecture). Frankly, many SOC teams are too busy and too focused on threats and don’t have a dedicated headcount focused on preparing their organization for the cloud change …