No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
Disclaimer: this blog is very obviously inspired by current events, but it is absolutely not about those events. Meoooow! Lawyercats, stay away! No mice here.
So, I hear there was some kinda incident and so Mandiant is investigating, as they tend to do. Mandiant blog has these fact-based quotes about the situation (sanitization is mine to emphasize the point above):
- Somebody “is systematically compromising $cloud_database customer instances using stolen customer credentials”
- Some “organization’s $cloud_database instance had been compromised by a threat actor using credentials previously stolen via infostealer malware”
- “Mandiant identified hundreds of customer $cloud_database credentials exposed via infostealers since 2020.“
- “The impacted accounts were not configured with multi-factor authentication enabled, meaning successful authentication only required a valid username and password.”
- “Mandiant’s investigation has not found any evidence to suggest that unauthorized access to $cloud_database customer accounts stemmed from a breach of $cloud_database enterprise environment.” It was further emphasized by said vendor that “we have not identified evidence suggesting this activity was caused by a vulnerability, misconfiguration, or breach of $cloud_database platform.”
These are the facts. All good so far?
So here are the questions:
- How does this work with shared responsibility for cloud security?
- Who is getting the blame in the court of public opinion, media, etc? Where is the outrage pointing?
Now, I used Gemini to analyze the articles, but here is one example that says it very well:
- $cloud_database_vendor “lets each customer manage the security of their environments and does not automatically enroll or require its customers to use multi-factor authentication.”
- “What is clear is that $cloud_database_vendor bears at least some responsibility for not requiring its users to switch on the security feature and is now bearing the brunt of that — along with its customers.”
I think we need a framework for thinking about blame, responsibility (the one you can outsource) and accountability (the one you cannot). Notice that I am elegantly not touching liability — beware of lawyercats! What we already have does not work well.
Here is the spectrum of uncooked ideas …
- The vendor never built a more secure way, lets customers figure out if they can secure it, and how (yuck!)
- The vendor built a more secure way, charges extra money for enabling it.
- The vendor built a more secure way, never told anybody about this option
- The vendor built a more secure way, and mentioned it on page 237 of a 300 page hardening guide inspired by NIST 800-infinity document..
- The vendor built a more secure way, made it a visible choice, recommended it in UI
- The vendor built a more secure way, did not set it by default, but “UX-nudges” users to consider it
- The vendor built build a more secure way, enabled it by default, and provided easy instructions on how to shift to less secure way (secure by default starts here)
- The vendor build a more secure way, made insecure choice very hard, with a lot of “good friction” (secure by default is here, secure by design starts here [admittedly, these two are complementary rather than levels on the same spectrum…])
- The vendor forced customers to use the secure approach (secure by design, “inevitably secure” [not that the only way to do it is to remove customer choices…]), and removes the less secure way (“Want to use our app? MFA. Don’t want MFA? No app!”)
… and your mission — should you choose to accept it — is to think about the “blame pie chart” (vendor vs customer) for each scenario.
P.S. Now, go and enable MFA whenever you can. If you think you can’t, try to anyway. If you can’t, reconsider your life choices…
P.P.S. You curious what Gemini said? This: “In security incidents involving MFA, the responsibility often lies with both the vendor and the customer. While vendors should prioritize security and make MFA easily accessible, customers must also take ownership of their security by enabling MFA and practicing good security hygiene.” So the bots hedge :-)
Related blogs and resources:
