To start, let’s remind our audience what we mean by threat detection and detection and response. A balance security strategy recovers attention to all 3 elements of a security triad prevention / detection / response. Prevention does improve, but never becomes perfect. Hence we need to find the badness that comes through despite preventative controls. Finding and confirming malicious activities and presenting them to the security team and/or automatically responding to them constitutes detection and response. [A.C. — you, the esteemed reader of this blog, do not need this explanation, perhaps, but a typical cloud user might]
How is the cloud different compared to the traditional environment? A framework to understand this includes:
- Threat landscapes change
- Environment changes
- Detection methods change
First, threat landscapes change. This means new threats evolve, old threats disappear all the while the importance of many threats changes. If you perform a threat assessment on your environment, then migrate the entire environment to the public cloud, even if you use the naïve lift and shift approach, the threat assessment will look very different. MITRE ATT&CK Cloud helps understand how some threat activities apply to public cloud computing.
Second, the entire environment around you changes. This applies to the types of systems you would encounter, technologies, and operational practices. Essentially, the realm where you have to detect threats is different — as are the assets being threatened. While some people often choose to present this picture as some alien land where a blue team would have only challenges, the opposite is mostly true. Cloud does bring a lot of new opportunities for detection, the subject of this post. The main theme here is change, some for the worse and some for the better.
After all, cloud is
- Usually distributed — running over many regions and data centers
- Often immutable — utilizes systems that are replaced, rather than updated
- Ephemeral uses workloads often created for the task and then removed
- API driven — enabled by pervasive APIs
- Centered on identity layer — mostly uses identities and not just network perimeter, to separate workloads
- Automatically scalable — able to expand with the increasing workload.
- Shared with the provider.
Sometimes the combination of Distributed, Immutable and Ephemeral cloud properties is shorthanded to “DIE” and called a DIE triad.
All these affect how we are doing threat detection for the cloud environment.
Third, telemetry sources and detection methods also change. An astute reader would assume that this is a derivative of the previous point we made, but it is not entirely true. Let’s look at some easy examples first. For some cloud services, and definitely for SaaS, a popular approach of using an agent such as EDR would not work. However, new and rich sources of telemetry may be available (Cloud Audit Logs are a great example here). Similarly, an expectation that you can sniff traffic on the perimeter, and that you even will have a perimeter may not be entirely correct. Pervasive encryption hampers layer 7 traffic analysis, while public APIs rewrite the rules on what a perimeter is. Finally, detection sources and methods are also inherently shared with the cloud provider, with some under CSP control while others are predominantly under cloud user control.
This leads to several domains where we can, and should, detect things in the cloud.
These six domains provide the coverage needed (network, identity, compute, container infrastructure, etc) and some specific detection mechanisms (API access logs, network traffic captures, etc).
Let’s review a few threat detection scenarios in the cloud.
Everybody highlights the role of identity in cloud security. Naturally, it matters in threat detection as well — and matters a lot. While we don’t want to repeat the cliché, that in a public cloud you are one IAM mistake away from a data breach, we know that cloud security missteps can be costly. To help protect organizations, GCP offers services that automatically and in real time analyze every IAM grant to detect outsiders being added, even indirectly through Google Groups!
Detecting threats inside compute instances such as virtual machines (VM) using agents seems to be about the past. After all, VMs are just servers, right? However, this is an area where cloud brings new opportunities. For example, VMTD allows security teams to do completely agentless YARA rule execution against their entire compute fleet (magic!).
Finally, products like BigQuery require new ways of thinking about detecting data exfiltration. For example, SCC detects queries and backups in BigQuery that would copy data to different GCP organizations.
Naturally, some things stay the same in the cloud. For example, broad threat categories (insiders, outsides, etc) are probably the same. Steps in the cyber kill chain, i.e. coarse grained stages of an attack, broad MITRE ATT&CK tactics, are largely unchanged as well.
What does that mean for the defenders?
- When you move to the cloud, your threats and your IT change and change a lot.
- This means that using on-premises detection technology and approaches as a foundation for future development may not work well.
- This also means that merely copying all your on-premise detection tools and their threat detection content is not optimal.
- Instead, moving to Cloud is an opportunity to rethink how you can achieve your continued security goals of confidentiality / integrity / availability (and perhaps reliability too) with the new opportunities created by the technology and process of Cloud.
