How to Solve the Mystery of Cloud Defense in Depth?
This post continues the discussion started in “Use Cloud Securely? What Does This Even Mean?!” and focuses on an area that should be easy for every purported security professional — defense in depth.
So, before reading further, ask yourself two questions:
- Do you understand the concept of “defense in depth” (DiD) in security?
- Do you understand how DiD applies in public cloud environments?
BTW, my own answers to these would have been “Yes, I think so” and “No, not really.”
Next, if your answer to question #1 is anything but a yes, please read the superb post “Defense in Depth” by Phil Venables. Phil reminds us of a few commonly forgotten aspects of DiD:
- “The goal of defense in depth is not just multiple layers of controls to collectively mitigate one or more risks, but rather multiple layers of interlocking or inter-linked controls.”
- “Defense in depth should also be fractal in that you need to construct defense in depth across the following domains and in turn within each of these domains”
- “The defense of a system overall […] is about the interplay of layers of control at the organizational level, the human and technical component levels in those organizations as well as also having inter-locking layers of control in each one of the domains.”
(and no, defense in depth does not mean “just use more than one security control”)
Now, onto the cloud. As I started looking into this, I’ve discovered 3 schools of thought:
- DiD in the cloud is not at all different from on-premise
- DiD in the cloud does not exist and does not matter
- There is “cloud-native DiD” for sure, you just need to discover it for yourself …
The first view is basically a “lift and shift DiD” view.” Let’s take a look at the classic DiD layers:
“The traditional security layers for defense-in-depth architecture are:
Network security: This includes firewalls, intrusion detection systems, and intrusion prevention systems. Network security controls are used to protect the network from attacks.
Host security: This includes anti-virus software, personal firewalls, and host-based intrusion detection systems. Host security controls are used to protect individual hosts from attacks.
Application security: This includes web application firewalls, application firewalls, and application-level intrusion detection systems. Application security controls are used to protect applications from attacks.
Data security: This includes encryption, access control, and data loss prevention. Data security controls are used to protect data from being accessed by unauthorized users or exfiltrated from the organization.
Security operations: This includes security information and event management (SIEM), vulnerability management, and security awareness training. Security operations controls are used to detect malicious activity, investigate security incidents, and educate users about security.” (source: Bard)
Now, let’s add the word “cloud” to each, and you have “defense in depth … in the cloud.” Uhu, yeah, right … This may be “correct” if you did indeed copy/paste your systems onto a cloud provider infrastructure, but it is almost certainly not the most defensible cloud architecture possible (and, no, I don’t know why the bot tossed security awareness into the SecOps bucket, mysterious ways of AI and all that, but IMHO the bot is correct in including security awareness as one of the DiD layers).
The second view is, I am guessing, popular with the “in the cloud, you are one IAM mistake away from a breach” crowd. Intuitively, but also rationally, I know this camp is just plain wrong. This is really not how a well-designed and well-architected cloud environment works (good example of a largely IAM-independent control). Furthermore, IAM mistakes are less likely in a well-architected cloud environment. So, “DiD does not apply in the cloud” is just being stupid.
Finally, the third view is a bit of a mystery. Let’s try to discover it together here!
Now for the fun part! Let’s check what we know for sure so far?
- DiD almost certainly matters in the cloud
- DiD is still about layers of controls and interlocking controls within each layer; this applies to technical and procedural controls across the cloud environment.
- In the cloud, DiD gets married to shared responsibility model where cloud provider controls some of the layers (and may get involved in client owned layers too)
- Some of the traditional control layers clearly survive (e.g. data security, application security, detection/response, etc)
- Some of the layers change a lot or vanish for some cloud usage models (e.g. endpoint/host security for SaaS)
- There are new defensive boundaries and perhaps even new layers (Is organization or project boundary a separate layer or a sublayer within, say, IAM?)
- Some of the popular DiD elements clearly matter less in the cloud (e.g. “firewall sandwich” or “multiple endpoint protection agents”)
- Cloud means a lot of “…as code”, so your DiD better be “… as code friendly” (and the place that delivers that code everywhere better be defended in depth!)
- IAM plays an oversized role as a layer. You also must have controls that are IAM-independent; otherwise, you DiD is again out of the window.
Finally, it is useful to think of public cloud defense in depth when thinking of both threats and configuration mistakes. If we just changed permissions on that storage bucket to ‘public’ by mistake and that automatically caused the data breach, this means DiD was absolutely missing in your environment…
Where to next? Perhaps to some DiD architectures?
Got any thoughts?
Related posts: