| There's going to be a question about the expected probability of this across cloud service providers. I've done security work for multiple cloud service providers and know a lot of people in the industry. I'm not really privy to give details. I can say: dev teams face limits on what they can build securely, platform teams face limits on what secure by default and monitoring features they have time to implement, security operations teams have a lot of data points to look at, and in theory even changes in personnel in a couple of teams can have an impact on the threat posture for a given set of a company. People are trying. But if you do the math for introduction of attack surface over time versus risk mitigation effort over time for that attack surface you can derive some estimates for likelihood of attack. If your cloud provider isn't providing you that data as a customer, it's not simple to make a determination about likelihood of risk introduction and breach of your cloud provider. This hasn't really been something people talk about because there was a tacit assumption that the biggest companies are mostly getting this right. I'm not trying to say the cloud is inherently broken, I run a lot of workloads in the cloud and trust sensitive data to the cloud. But I do wish there were better ways for customers to have data points with which they could evaluate platforms besides extrapolating the history of public breach reports. |
> dev teams face limits on what they can build securely, platform teams face limits on what secure by default and monitoring features they have time to implement, security operations teams have a lot of data points to look at, and in theory even changes in personnel in a couple of teams can have an impact on the threat posture for a given set of a company.
I couldn't agree more. It's too bad, because I believe most companies should be solving this by building on a battle-tested platform that provides a safe path for devs. In theory, platforms like Heroku improve cloud security by reducing margin for error. In practice though (as we're seeing), these platforms can introduce new security vulnerabilities in the layer they introduce on top of IaaS.
I also very much appreciate your comment about having a better way to evaluate the security of platforms without relying on public breach reports, or implicitly trusting what platforms say. I think the best thing is for platforms to be 100% transparent in how they implement security, namely by:
1. Running alongside IaaS services instead of layering a black box on top of them (coordinating, not fully abstracting)
2. Providing clear accountability for security defaults: every security default enforced by the platform should be represented in a validation that end users can view (if not alter)