Where Does Shared Responsibility Model for Security Breaks in the Real World?
Shared responsibility model for cloud security is the fundamental concept — perhaps the most fundamental concept — in cloud security. However, there are many challenges with how this concept fares in the real world today.
This blog is basically an alpha version for a future blog on how we are evolving and improving the shared responsibility model shortcomings with our shared fate model, but this one only has the challenges, and not the solutions. This post is loosely based on this Twitter discussion with more ideas added from various other sources, and my [ex-]analyst brain applied to this to organize the information in a more useful manner.
General erroneous perceptions
In the area of general misunderstanding of the shared responsibility model, there are several scenarios. First, there are examples where a customer assumes that a cloud provider handles a particular security task or delivers some security outcome, and sometimes they think so for no good reasons whatsoever. “Cloud is so secure, we won’t have to do a thing” is as much a misconception as “cloud is insecure, we can’t use it.” (see this for a much more clear explanation)
Sometimes the model is not understood at all, and this can be problematic. “If responsibility is shared, nobody is really responsible” is perhaps a simplistic view that is not entirety correct. To me, while shared responsibility is definitely possible, shared accountability is a different story. Ultimately, cloud users own the business risk, and that’s that.
There are cases where the customer doesn’t understand — or chooses not to understand, perhaps — that they are responsible for some key security activities. Sometimes they think so because they have been confused by a reseller or another partner. As mentioned above, a fringe case of this is of course the old trope of “we thought cloud is so secure, so we didn’t realize we had to do anything.” It is definitely more 2012 than 2022, but there are still organizations that are trying to operate like this. As they say, “A common cause of failure with this approach is when customers do not take the time to understand their security responsibilities.”
Overdelegation
Sometimes shared responsibility failure mode is linked to the fact that cloud users assume that CSP does more than it really does.
There are cases where the CSP documentation clearly states that something is customer responsibility, but the customer does not read said docs and hence stays unaware that the responsibility was, in effect, handed to them.
Sometimes, there are case of a security activity that is being pushed to the cloud user, even though the cloud provider is more skilled and better equipped to handle it, while the customer is just organizationally incapable of completing the task at hand (e.g. configure a particular security system while having no security professional of any kind in their team).
So, don’t assume “provider does it”, maybe they do, maybe they don’t, but it is clearly your task to figure out which one it is.
Capability vs Responsibility
Some point out examples where the cloud provider is limiting what the customer can do to secure something, yet shifting the responsibility to a customer. For example, with some managed (in a cloudy definition, not security one) services, the cloud provider can change the system, but the customer is responsible.
Another scenario similar to this is where the responsibility for a particular task sits with a customer, but only select tools are allowlisted by the provider available to do this.
Some also point at cases where the provider owns the process (such as to remediate the vulnerability in the container management system, for example) yet the customer owns the risk without any chance to affect it. Admittedly, this is a narrow time window for this, but it still bothers some people. To me, it represents a minor shared responsibility pitfall.
I loosely place the question of customer side confusion where the security team perhaps is aware of the cloud shared responsibility model, but they lack access to particular cloud subscriptions. At the same time, the person who has access, lacks the ability to secure (and awareness that he needs to), and those who have the ability, lack access. Naturally, one can say that this is a customer process breakdown, not the model breakdown, but hey… I can see people who will debate this point.
Finally, there is a failure mode connected to the fact that security technology on the provider side changes rapidly and the security teams at more traditional organizations are not able to keep up. For example, a new control becomes available, and the customer is ultimately responsible for enabling it — yet the customer needs to become aware of it first.
Too Much Work and More Complexity
One can say that this category is a subcategory of the above, but somehow I feel like treating it separately.
There are cases where a complicated technical task is ungracefully pushed to the customer side of the shared responsibility model, yet CSP offers no help in completing the task. This to me also sounds like a genuine hiccup in the model. Ultimately, I personally abhor when the shared model works like this: “Cloud customer, it is your responsibility to do <this really complicated task that is easy for a CSP> otherwise <bad things happen to you>” scenario.
For example, you can detect this threat by reviewing a petabyte or two of logs that the CSP gracefully delivers to a client. A client goes and ungracefully fails at this task. But can you really blame them?
Even for compliance tasks, complexity of what commonly sits on the client side of the responsibility model has caused trouble in the past.
Default Confusion
Misunderstanding the default controls and who needs to change them to align with client security goals. The default may be less secure than this customer needs, and it is his responsibility to change them. The default can be more secure than the customer needs, and it is their responsibility to adjust them, rather than simply turn them off.
Specifically, insecure defaults that need to be changed before going prod would be another example of a breakdown. Who is really responsible for a failure: a CSP with loose defaults or a customer who didn’t change them to what matches their risk profile?
Generally, not understanding the gap between the default security at the CSP and the risk-driven security needed by the client is not uncommon. In other cases, product complexity leads to clients never understanding what to change the defaults to and how.
Fuzzy Lines
Overall, in PaaS, this seems worse. IaaS and SaaS shared responsibility boundaries tend to be better understood compared to PaaS that is both more programmable than SaaS and more alien (to those used to colocation spaces and rented data centers) than IaaS.
Multi-party cluster
Shared responsibility model becomes even more complicated for many cloud users when multiple parties are involved. For example, it may involve a cloud provider and a reseller, or a set of chained cloud services — or both.
Client + cloud provider + reseller, Client + cloud provider + managed services provider, cloud + cloud provider + their cloud provider are all “exciting” and “turn real nasty real fast….” It is also much easier to blame than fix the issues here (example).
For resellers specifically, may have admin access to client cloud, sometimes jointly with the client, and so the client side of responsibility is clearly further split in a set of painfully confusing ways.
Overall, multi-party stuff is leading to situations of more security areas being missed because “surely one of the other two parties would do this” scenario.
Tricky Areas of Security
But wait, there is more! I think there are areas of technical security where the responsibilities are inherently mixed and drawing the clear lines of responsibility (like this sits on the provider side, well that sits on the customer side) is inherently difficult. My favorite example is threat detection in the cloud where working together with the provider on certain tasks rather than debating separate responsibilities is perhaps the only route to success (another example).
With this, we set the theme that success in securing the cloud is likely correlated with clients and service providers working closer together ultimately sharing their fate,
Scary fringe cases
And then there are threats that seem to wreck the entire model. Without going into too many details, blind subpoenas come up in some such discussions, usually held in hushed tones…
This one is admittedly a debatable example, but some people assume that if a security breach happens on the provider side (like Cloud Hopper sort of was, but not precisely) yet client environments and client data are affected it indicates a breakdown of shared responsibility model. To me, this discussion rapidly veers into philosophical and perhaps would not be covered here in detail…
Finally, there are crazy situations like cloud providers canceling their contracts on short notice like what happened to cloud users in a certain country recently. I am not implying that everybody should have that in their threat model, but you’d all agree that one can no longer discount this threat as purely theoretical.
As they used to say, “more to come!” Please comment, argue, debate at will.
P.S. Please treat this as alpha code, this is probably a bit raw, but I want to start a deeper discussion here, and so here we are :-)
Related:
