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.)
I 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.
> 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.
OK, 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.
> 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!
If you don't think side channel attacks are a threat vector on your single tenancy system... (you can leverage these vectors to gain access to privileged data/etc. through unprivileged processes). They're differently threatening to you on your own metal, but as long as your systems take user input somewhere, they're a threat vector.
As to KPIs: there are significant cultural differences between providers. That was extremely evident while evaluating them. The differences in approach, thought, consideration and priorities between even the big 3 was substantial.
I'm curious as to why AWS doesn't run a bug bounty, although I could probably guess (lots of their sec teams have background in the intelligence community, etc.).
I'd also like to re-iterate that this is not 'cloud', but specific cloud providers. There were quite a few I looked at that were...unaware that security might be a thing (full push-to-prod creds on every developers laptop, working from cafes around the world, etc.).
> side channel attacks.. gain access to privileged data/etc. through unprivileged processes
True, but tbh that's not the first thing I'd reach for. if someone already has pwned your single function or a control plane, then it's usually game over anyway, and escalation sploits are usually a lot easier than a side channel.
Whether AWS has IC or FedRAMP background seems kind of irrelevant to a simple bug bounty program, especially for a trillion dollar company, when I was able to find an escalation vuln in about three minutes in an unfamiliar codebase in a language that wasn't my primary. They should have at least acknowledged and said thanks for the heads-up.
Big provider controls planes are not going to be ruined by a privilege escalation. There are many, many layers to their defense systems.
The Intel Community and it's members tend to not do anything to call attention to themselves, their actions, their capabilities, etc.
Overall security can be enhanced by keeping things quiet, or at least, that is a common perspective from that part of the world.
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
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, 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.
I'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.
Example: 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?
Having a "home baked server" in no way means it is "janky". There are some pretty clear and correct ways to setup a secure server these days.
Using an OS such a RHEL gives some guarantees about auditing for vulns being done already for you. You don't have to take on the responsibility for analyzing everything yourself. CentOS historically gives some of the same benefits.
What do you think Amazon uses internally for Amazon.com? They use a variant of RHEL. ( albeit a really old "jankified" version )
I'm not suggesting you run the server over home networking. ( which is against TOS by the way ) You can own your own server and place it in a good Colo facility who are already handling the power, routing, etc.
I previously wrote the management software for a major company that handles configuration and setup of all their data centers. I know a thing or two about what is necessary.
Redundant power and networking with monitoring of both is essential, and also common and easily available in a decent colo. You can of course use a bottom dollar colo that just throws some shit together, but you will, as you say, risk there being vulns in the stack outside your server.
That said, it isn't hard either to setup your own data center from nothing. You need multi-phase power, redundancy, and a number of components that are somewhat costly for an individual, but there are reasonably affordable options these days. You can get 220 in the home if you pay for it. I'd recommend having a commercial location pre-setup with it though of course. Preferably you'd want your data center near a major internet hub and/or with connections to multiple major internet providers...
And yes. I have guards from someone walking away with my equipment. I have a gun and I'm happy to shoot any intruder in the face with it. All my drives are encrypted as well and if there was a breakin they will auto-shutdown...
I own enterprise level tape backup equipment and hundreds of tapes. So yes: offsite backup that is encrypted. The keys are backed up and encrypted themselves.
You can go down the rabbit hole as far as you like. My setup is still more secure than Amazon and the like.
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.)