Who Does What In Cloud Threat Detection?
This post is a somewhat random exploration of the cloud shared responsibility model relationship to cloud threat detection.
Funny enough, some popular shared responsibility model visuals don’t even include detection, response or security operations. Mildly embarrassing, that.
Anyhow, let’s start here: a naïve view of shared responsibility model and detection is simply the following: the cloud provider (CSP) is responsible for detecting threats to their backend systems while the customer is responsible for detecting threats to whatever they put in the cloud. This view is often promoted by people who have never seen a cloud and who probably cannot even spell “I-D-S” :-)
So, if you think about it for 5 seconds, you realize that this is naïve and frankly misguided. Or, at least, simplistic bordering on impractical. In the real world, very clearly there is a role for cloud providers in both facilitating threat detection against whatever the customer puts in the cloud (say via a network IDS), or in some cases, just doing that detection themselves for customers (like say what we do here or here).
Thus, the lines for shared responsibility for detection are drawn somewhere else. We need to go look for those lines and/or redraw them if they are not visible anymore. By the way, we need to go look for them, because many cloud security issues originate at the seams of the shared responsibility model or arise due to cloud customers assuming too much about what the CSP is responsible for …
Let’s look at some examples first, because I feel this is a good place to do “bottom up” thinking.
A CSP develops and offers tools for detection, while customers are responsible for configuring the tools, including deploying the correct rules and detection content; then customers handle the alerts. This feels normal and largely parallel to what we see on-premise, no? However, the attack surface of a modern public cloud is so fundamentally different from the attack surface of an on-premise data center that translating from one to the other is hard. Moreover, many organizations using cloud are short-staffed (to put it mildly) in their security departments and may not have anybody who knows what to look for and what detection logic to build for the cloud. Frankly, even decent SOCs are often confused about cloud detection. So just as we rightly impugn “lift and shift” of workloads, we should neither lift and shift our threat models nor our detection rules. Of course, you know what this means: more work …
A CSP develops and offers tools that come complete with detection logic to detect common threats against the customer side of the cloud; the customer still gets the alerts. This approach of course makes the detection work like magic (for a customer), but limits the ability to tune and adjust the detection use cases based on your business in the cloud. To me, this means that fully shifting the detection responsibility to a CSP is a bad idea today (so the responsibility line is not drawn such that CSP is doing all the work). Note that here and in the previous scenario, the managed service provider (MSSP / MDR) may get the alerts to help the client figure out what to do (if they know how to handle the cloud themselves, that is).
A CSP develops infrastructure for detection which is then used by a third-party vendor who then sells detection tools complete with content / rules to the cloud users. This adds yet another party in the shared responsibility model. Alerts are handled by a client or by some managed services somewhere. In this case, we do have to draw more lines: CSP responsibility line, client responsibility line, 3rd party technology vendor responsibility line and potentially the managed service responsibility line (a lot of line drawing afoot!). While the third party vendor may do a better job than a CSP in some areas, they won’t understand the underlying technology as well (it also further divorces system creation from rule content creation that may be a recipe for unhappiness at times).
Naturally, a CSP also develops and operates the detection tools that detect threats to their infrastructure (and handle these particular alerts); here the naïve view is essentially correct, at least in part.
So, what do we learn here? Let me try to “overthink” it a little bit and present a table that summarizes the routes we just discussed.
(BTW, secretly, I think that in the long run the CSPs will do more of this work; this is why I am not investing any money into multi-$B cloud security startups).
Finally, some of you have skimmed this post and now have a burning question: which route is “better”? Furthermore, some of you are going one step further: which route is better for what cloud models, services, migration approaches? These are great questions and they will make a great follow-up post; this was meant to frame and start, not provide the final answer …
Thanks to Tim Peacock for helpful comments and some text contributions. Thanks to Anna Belak for the initial inspiration for this post.
Related blogs:
- “Why is Threat Detection Hard?”
- “On Threat Detection Uncertainty”
- “Is Your Fate In the Cloud?”
- “Move to Cloud: A Chance to Finally Transform Security?”
- “Cloud Migration Security Woes”
- “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
- “EP27 The Mysteries of Detection Engineering: Revealed!” (on our podcast)
- “EP39 From False Positives to Karl Popper: Rationalizing Cloud Threat Detection”
