Think about it more abstractly from the perspective of trust and # of actors involved.
If you run 100% of your IT workload on-prem, the ability to control the flow of data can be boiled down into a physical exercise of following fiber channel cables in your own datacenter. Having a unified set of firewall rules that define your entire public interface also helps a lot.
You can actually make deterministic guarantees to your customers that not only your own systems are secure, but also that the systems of your vendors and other 3rd parties are as well. The moment you start configuring site-to-site VPNs with 3rd parties across which you intend to transact sensitive business knowledge, you are surrendering an entire mountain of security constraints.
If we are being honest with ourselves, a lot of shops that are 100% on-prem probably have worse security practices than AWS, et. al. Perhaps the biggest hazard is really the hybrid model. If some fintech went 100% into the cloud without even an HSM on-prem to worry about, then you could probably have a solid argument on the other side of the spectrum. Also, remember that multi-cloud might seem like a resiliency measure, but it also adds another target to your back.
The middle ground is where all the pain seems to be. Hybrid cloud usually means more required trust than most organizations ever wanted to enter into. I frequently find myself as the harbinger of bad news when I get into deep-dive technical calls with some of our customers. Turns out a lot of the other vendors we work with like to bend the truth in order to make a quick buck. Many perverse incentives are pulling these massive organizations into hilariously-contorted IT stances, and some of us are starting to see a consulting opportunity.
> You can actually make deterministic guarantees to your customers that not only your own systems are secure, but also that the systems of your vendors and other 3rd parties are as well.
You can make a "deterministic" guarantee, whatever that is, that your systems are secure? That's seems pretty bold and probably dangerous, no?
> That's seems pretty bold and probably dangerous, no?
Its not dangerous in my experience. The more dangerous angle for me is this belief that it is impossible (or hopelessly difficult) to build a secure system.
The reality is that it is only possible if you are willing to take total ownership of the entire vertical. If you control every single byte that enters and exits your enterprise, you can prove that things are secure. Is it practical to do this in all cases? No. Is it feasible in theory and in certain cases? Absolutely.
If you buy into the 3rd party hosting game, you instantly lose control over the critical variables you would need to in order to create the opportunity for these sorts of guarantees to exist in the first place. You (and your customers) will be stuck wondering about side channel damage and human factors that you have no direct control over. When you own the hardware and the real estate it is parked on top of, you can start to reel these things back in really quickly with powerful policy frameworks (2-person rules for critical changes, mandatory checklists, etc). These sorts of policies seem to work really well for very tricky areas like keeping our nuclear weapons from doing inappropriate things.
How do you know your own programmers aren't introducing security bugs? Or are even acting against your interests intentionally? It happens to every other software developer, why not you?
Do you build all your own hardware from raw materials? How do you know everyone in the supply chains is perfectly secure?
Attacks have succeeded against the CIA, against RSA, Google, and many others. Nuclear weapons plans have been stolen. I would not trust a vendor who claimed they could guarantee security.
> If we are being honest with ourselves, a lot of shops that are 100% on-prem probably have worse security practices than AWS, et. al.
Does it matter? You have the same freedom to fuck security up setting your AWS infrastructure as you have setting your on-prem infrastructure. All the very competent AWS staff is able to do is add less risk, they can't save you from anything.
No it was due to the officially-endorsed fiber optic cables sitting in plain sight and the fact that they do business with so many other parties.
I work with some intermediate vendors in this space (they have direct access to the credit bureau data), and their security mechanisms are of concern. I am under some very strict NDA constraints, but I can say that there are serious problems and I am not surprised that breaches occur with regular frequency.
You can barely trust your own in-house developers to get these things right. How can you possibly hope to trust many other additional parties to get it right simultaneously as well?
> I suppose the infamous Equifax breach was due to a secret fiber optic cable running out of their datacenter?
No, of course not. But when you're dealing with physical infrastructure you can actually touch, it's much clearer and more certain what you're dealing with.
I don't think that is as true as you make it sound. I have managed on-prem and cloud infrastructure and am much more confident that my cloud servers are secure because a whole lot of stuff is done by the provider who know a lot more than me between them.
Even on a really simple on-prem scenario, you have switches to configure, vlans to setup, hardware drivers, a gazillion updates to make all the time and a tonne of employees making it all very difficult. The fact I can see it physically doesn't realy help me that much.
For one, at a certain scale you shouldn't be running an inhouse DC solo, you can get away with it more in the cloud but at a certain ace again you want more manpower for review/auditing and brain/man power.
Most of what you described aren't actually principle attack vectors either. The primary vectors are the same between on premise and cloud. Misconfigured VPNs, stolen VPN credentials, poor network segmentation (Cloud absolutely does not fix this for you, you still need brain power and auditing to find accidental misconfigs).
Just my observations, but some business entities run into legal challenges that vary greatly by industry. B2B customers have a contractual relationship with you, not your hosting provider. If your hosting provider has an "oops we leaked your data" they only breached the contract with their vendor, not themselves. The contract can specify how data is managed. Adding to this, some companies/banks legal controls are compatible with SOC2 controls of a 3rd party data processor being audited and some companies are not. Some companies can cite the 3rd parties audited certifications and some can not based on preexisting legal contractual agreements with their own customers. I am not a lawyer, but had to sit in many meetings with lawyers and businesses and this is a real issue they have to address. I have also worked for a large bank. Rules, regulations and contracts around 3rd party data processors and financial institutions can get very complicated. There are a myriad of additional complicating variables that go beyond regulations. Legal obligations also vary by relationship. If a bank has preexisting relationships with other banks, they may be obligated to get approval from the other banks to change how their data is managed. Amending contracts is non-trivial. This rabbit hole can get very deep.
I'm a banking attorney and I think you've hit the nail on the head. Vendor management is popular with regulators, particularly with respect to info sec and data privacy, and the navigating the contractual responsibilities can quickly become burdensome.
Getting the lawyers on both sides to agree to language for the ongoing certification(s) that will also satisfy the internal auditors, the outside auditors, the regulators... suddenly something that sounded simple when the contract was signed takes several meetings and a lot of back and forth.
What's the worst that can happen in a on-premises attack, Vs the worst that could happen if AWS was hacked?
The amount of financial data that could be exploited at once is magnitudes larger in a popular cloud. I don't think it's strange that a regulator might look at that failure point with some trepidation.
On the other hand, at least AWS, Azure etc. all have a vested interest in doing things well and securely. At a bank, most employees know nothing and care nothing about the HW and SW systems, they just use and abuse them.
Well they do have the vested interest but they are predictably irrational in another one - trying to make more money and cutting costs from "non-core businesses". It isn't rational but certain sorts of predictable stupidity are more common in some contexts than others.
