Hacker News new | ask | show | jobs
by photon12 1508 days ago
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.

5 comments

(Founder of Aptible, a Heroku-like PaaS focused on security and compliance)

> 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)

> In practice though (as we're seeing), these platforms can introduce new security vulnerabilities in the layer they introduce on top of IaaS.

Isn't Aptible another layer on top of IaaS?

That's how most of our customers use Aptible, yes. That said, we currently have our first customers running Aptible as an integration with AWS, and we believe this will be the most popular way to use Aptible in the future.

With this new product model, you integrate Aptible with your AWS account, and we provide functionality to provision high-level constructs like apps and databases that simply set up and coordinate AWS services like ECS, EKS, RDS, etc. Aptible only needs permission to write to a set of SQS queues in your account. To make sure things stay compliant, we set up AWS Config checks for every security control relevant to your chosen compliance framework(s), and maintain a set of managed IAM roles that you can assign to your dev team to ensure least-privilege access without having to constantly update IAM.

Unrelated to your main point, "I'm not really privy to give details.", that's not how you use privy. If you have the details but aren't allowed to share them then you are privy to the details, but you can't share them.

Privy means "sharing in the knowledge of (something secret or private)", but it has nothing to do with sharing that knowledge with others.

The phrase to use would be "I'm not at liberty to give details".
This is something I've been thinking about as a user (provisioner) of cloud services like Heroku, AWS, Google, and VMs from Linode and Digital Ocean. Especially with the potential of state actors trying to cripple large businesses (I don't actually know how serious a threat this is TBH).

Sure they take security further (I hope) than I would provisioning my own hardware, but I also worry about how large a target they are and how much more complex their systems are (increasingly large attack surface).

It's appealing to just let someone else handle my hosting, including security, but I also wonder if I'd be better off running colocated metal. I mean I still have to worry about the hosts network and physical security when colocating, but it's a much smaller attack surface, and also a far smaller target than massive hosts like AWS.

I think cloud provider's might need to level up their security practices, even if it incurs some friction with their customers and staff. I don't even know if it is feasible to evolve as fast as potential attackers from a cost perspective over the long term for many (or all) of them.

Not to single anyone out, but take Digital Ocean as an example. They're constantly adding features to their platform. I assume this increases their attack service? How much weight are they giving to security as they add features? I assume quite a lot, but I don't really know! Another example is AWS, who are constantly growing their features / services (to the point where it's near impossible to navigate all of their offerings!). Every cloud provider is doing the same.

There's also no real accountability. If my database on Heroku (or another provider) is compromised it could have a massive impact on my business, but at most it might mean losing a customer for my hosting provider, and maybe some bad press (not really enough though IMO). So the incentives aren't perfect.

I have no experience in organizations or IT systems that big, but, I can very much imagine that it's not only a matter of not having enough time to check everything, but over time, your systems become so big that it's hard to maintain an overview or, for that matter, control.

I mean, there's been numerous incidents of a random developer having copies of customer data on their systems, or accidentally opening up a database or an Elasticsearch instance to the world.

And I'm afraid the only way to help mitigate that is to restrict what an individual can access and do on the one hand, and bureaucracy on the other. And full-time staff whose only job is to maintain security and juggle access rights around.

Agreed. cloud providers’ incentives are aligned with growth which naturally mean easy accessibility; hence all the defaults being generally “open”. Its so easy to make a resource accessible to anyone, or an IP accessible from anywhere in the cloud without proper restrictions by internal teams in the company; and often the default is to give teams superadmin to “unblock their time sensitive project” rather than maintaining principle of least access which requires more discipline (and thus effort).

Either cloud providers need to assume more responsibility for security or a Federal Agency like the FBI or NIST need to be more proactively engaged in improving the security posture of cloud hosted US corps.

> cloud providers’ incentives are aligned with growth which naturally mean easy accessibility; hence all the defaults being generally “open”

So no different from every VC funded startup (or startup seeking VC funding) then?

The sentiment of imposing tighter regulations around data security feels counter to the general idea that the lack of regulations around data security (e.g. strong data protection laws) are what allows the US tech industry to dominate compared to its EU equivalents.

I'm not disagreeing with this, I'm just pointing out the contradiction and wondering how those who believe the latter would reconcile that belief with demanding the former.

It’s quite simple. Doing the right thing has short term costs and long term benefits.