7 ms·
> If you don’t use a cloud provider: why not? This makes it sound like it's a negative, but a solid argument can be made controlling your application all the w
by jamiesonbecker 6y ago
> If you don’t use a cloud provider: why not?
This makes it sound like it's a negative, but a solid argument can be made controlling your application all the way down to the metal is a more, not less, secure way to go.
We can all make opinionated assumptions about whether a cloud provider is "more" or "less" secure than doing it (whatever "it" is, exactly) on your own, but even the fact that it's so debatable proves that it's not really a defining point that should be on this list of questions (although it might be to an individual team, especially if you're trying to bring things in-house in the first place, but of course this set of questions is really relevant to SaaS.)
- count 6y agoI would suggest that for the VAST majority of organizations, a cloud provider[1] will be an unequivocally more secure infrastructure than running it themselves 'down to the metal'. The big clouds have security research security ops teams larger than many companies. I don't think anyone who has seriously spent time looking at this would debate it at all. Nb. this has no bearing on if it's the right business decision, mind you. That absolutely could end with you being better on your own metal! But you won't be more secure. Source: spent a decade doing security evaluations of cloud providers for the DoD/IC, who also had this misconception going into things. [1] to be fair, I'm only talking about the large cloud providers (AWS, Azure, GCP, etc.). There are tens of thousands of SaaS/smaller cloud providers that are absolutely debatable around security posture.
- jamiesonbecker 6y ago> But you won't be more secure. I respectfully disagree. A cloud has many more vectors for attack, and even the largest clouds have blind spots. For example, check out AWS's (lack of) response to a vuln report that I filed with their security team: https://github.com/aws/aws-codedeploy-agent/issues/30 https://github.com/aws/aws-codedeploy-agent/issues/30 Did you know that AWS does NOT pay for security vulns and does not operate a bug bounty program? It seems a common myth that AWS is more secure than any particular company. Your security inside or outside of a cloud has to do more with your internal security posture than what AWS brings to the table (and leaves behind). The public cloud is not magic security pixie dust. It's a virtualization platform with extra services attached. You are still 100% responsible for securing your servers (meaning everything down to the network routing layer, and some beyond that, too). Obligatory reference to the AWS Shared Responsibility Model[0] This is not a bad thing, but it's still a thing. Anyone who migrates to the cloud and magically expects their security posture to improve one iota is simply wrong unless they take active steps to integrate as tightly as they can into that cloud's security tools. As someone who has done a ton of AWS security audits, I can tell you that people take multiple approaches on that: either they don't integrate into it fully, or they submit to vendor lock-in. This is perhaps too deep of an argument, since clearly intelligent and skilled people can reasonably disagree. FWIW, lapsed AWS SA, recovering Fortune 50 cloud security architect, and please don't take my argument about the cloud to indicate that I'm anti-cloud: my security-focused SSH key management company, https://userify.com https://userify.com, is strongly cloud focused: AWS Advanced Tier, GCP Partner, SOC-2, PCI, HIPAA. I'm very much pro-cloud, while recognizing that it enlarges your threat model but brings other security advantages. Where you're hosted doesn't matter as much as whether you're paranoid and clueful, and perhaps have former blackhats on your team ;) So my point is simply that the cloud question isn't that relevant, and the thrust of the other questions should be used to determine security competency instead of where they're running their operations. 0. https://aws.amazon.com/compliance/shared-responsibility-model/ https://aws.amazon.com/compliance/shared-responsibility-mode...
- permille42 6y agoFormer blackhats? Why not current blackhats. 0:)
- teddyh 6y ago> The big clouds have security research security ops teams larger than many companies. That’s like claiming that a company is on safe legal basis beause of the army of lawyers they employ. It might be true, but the inverse correlation also holds.
- count 6y agoOK, I should have added in qualifiers 'highly competent and respected'. More bodies doesn't necessarily equal better product, for sure. They can devote teams of researchers and engineers to topics like CPU side channel attacks, entropy draining in virtualized environments, and other stuff that your average firewall/AV admin isn't even aware are attack vectors.
- jamiesonbecker 6y ago> OK, I should have added in qualifiers 'highly competent and respected'. More bodies doesn't necessarily equal better product, for sure. Agreed. > They can devote teams of researchers and engineers to topics like CPU side channel attacks, entropy draining in virtualized environments, and other stuff that your average firewall/AV admin isn't even aware are attack vectors. True. Of course, side channel attacks aren't even possible threat vectors on bare-metal/non-virtualized/single OS/tenancy environments. From that perspective, virtualization can be seen as having two primary benefits: potentially higher availability and the cost savings of combining multiple functions onto a single piece of hardware, but if costs were not a concern and all else being equal, separate bare-metal servers will have better isolation. One thing that concerns me is that KPIs at some large cloud providers seem to be focused on creating new features and not fixing bugs, especially security bugs, so there's no incentive to do the drudgery of curing security flaws for a developer. It's hard and detail-oriented work, which makes me even more concerned when I see a trillion-dollar company that won't pay to find about bugs in its own products. Lots of huge companies with tons of money have big security teams. This does not always give the best results, as we've seen. Of course, having great arguments (like this one!) helps in raising awareness and comprehension among the less technical stake holders. Iron sharpens iron!
- permille42 6y agoI've worked at some of the big companies, including multiple cloud providers. I wouldn't trust their shit ever. Perhaps it seems more secure than self built stuff but it really isn't. The same idiots you think won't build their own infrastructure correctly are also building the pieces of the cloud you so cherish. I'll agree that it is more likely the cloud providers have more logging and monitoring in place though, and that can make a big difference. On the other hand, cloud providers get far more attacks. I disagree that hosting and doing everything yourself is not more secure. It absolutely is, especially if you use your own non-standard setup and work hard to prevent easy analysis of your setup. Example: If you host your own server and only server static web files with no interactivity... and only expose port 443... it is possible to pretty much guarantee the server cannot be hacked and at best could be DDOSed. Obviously hardening measures would be necessary too, and taking care to not expose anything besides pure static file serving, but that can be done with relative ease. If you use a cloud provider, the attack surface is HUGE. All of them have extensive APIs, with so many possible places where there could be a vuln discovered. I think it is absolutely incorrect that using a public cloud service is more secure; there are simply too many bells whistles gears bolts shims and everything else.
- count 6y agoExample: if you restrict things to not being useful for most organizations then you can do it safer? Except, which is less likely to be owned and have no impact on your business, S3 or some janky home baked web server? Are you staying up on every single dependency and security vulnerabilities present in that entire stack of gear (you aren't hooked up a web server directly into a provider backbone...so you've got routers, switches, an OS, firmware, the web server software, a building to hold it all in, etc. etc.). Even something so absolutely simple as 'serve static web pages' has a huge cross cutting set of things keeping it functioning. Do you have guards preventing someone from just walking out with the drive on that single machine? Is the data encrypted? Is it backed up? Is the backup offsite? Is the backup offsite encrypted? Who's got the keys? Are the keys backed up? Who's got access to the key backups? Etc. etc. etc.
- permille42 6y ago