Today’s information systems architects start with three a priori assumptions. Everything they do is based on the belief that these three assumptions are not just assumptions, but fundamentally true. Before I tell you what they are, let’s review the term, “a priori,” because it’s not all that common. For some of my readers, this may be their first exposure to the term, and I can’t help myself – after teaching college courses for seventeen years, I like to start everyone on common ground by defining key terms.
From Merriam-Webster’s Dictionary, a priori means “relating to or derived by reasoning from self-evident propositions; being without examination or analysis; presumptive.”
In other words, these assumptions are accepted as true without giving it any thought. A priori assumptions aren’t derived by reasoning from proven facts. Instead, they’re derived by reasoning from things that are considered self-evident. I’m going to challenge you today to reconsider whether these three assumptions really are self-evident.
Assumption 1) The cloud is the only way to design a modern system.
Assumption 2) Centralized architecture is always better than decentralized, or distributed, architecture.
Assumption 3) These two design standards taken together – cloud, and centralization – can be made safe and secure.
But these assumptions are just not true, by any historical or statistical measure.
Cloud architecture has been around long enough now that there are system architects all the way up into their mid- and late-30s who don’t know anything else. Those of us who are older can remember being deeply suspicious of the dangers of moving first, our data, and later, our operations, to the cloud, but we were overruled by CEOs and CFOs who anticipated immense cost savings by following the advice of the cloud service account reps.
Those same account reps said, “It’s very secure!” Yet today we know that the cloud systems of 2006-2010 were leaky buckets, at best. It’s no accident that the attorneys for the cloud services advised contract language that insisted on a shared responsibility model. From the beginning, this was intentionally and thoughtfully designed to minimize the cloud service providers’ risk of liability in the event of data loss or breaches.
Public cloud services are best for publicly accessible data, not for sensitive data. Here are two reasons.
REASON #1: More complexity equals more vulnerabilities.
Whether it’s a mechanical system with gears and levers, or an algorithmic system with lines of code, the number of possible failure points increases with the number of system elements.
Back in the day I used to refer to this as the “photocopier syndrome,” because the photocopier was the most complex electro-mechanical device in the typical business office. They were notorious for frequent breakdowns. Today, cloud services are becoming more complex. They’re not becoming simpler. The number and type of possible configuration errors is vastly greater than it was in 2006-2010.
REASON #2: Centralization makes any accident more catastrophic.
I’ve used this expression before, but it’s worth repeating:
“Let’s put all our eggs in one basket. Then, when there’s a slip-up and the basket falls to the pavement, we can all be shocked by the size of the mess.”
(–Bob Young, 30 October, 2019)
Here’s an example. There was a time when every insurance agent kept the records of their customers in their own office. If a cybercriminal breached the insurance agent’s system, they got information on maybe 2,000 people. Today, the insurance agent is required to store those customer records on the insurance company’s centralized system. Now, if a cybercriminal breaches the insurance company’s system, they get information on hundreds of thousands of people. Maybe millions.
And that, in a nutshell, is the dangerous problem of centralization.
Exfiltrating data? Centralized data makes the problem worse.
Encrypted by ransomware? Centralized data makes the problem worse.
Data accidentally deleted? Centralized data makes the problem worse.
Earthquake? Fire? Flood? Centralized data makes the problem worse.
The danger is so real, so pervasive, and so well understood that it’s becoming difficult to buy cyber liability insurance that even comes close to offering real protection. If you think data centralization in public cloud services is secure, invite your favorite insurance actuary to coffee and have a chat about the risk.
Drivers for Cloud Services and Centralization
There are two reasons why business owners insist on using cloud services for everything, and centralizing data (and data processing) as much as they possibly can:
1) It appears to be cheaper.
2) They want to monetize the data in their large data oceans.
Neither of these reasons has anything to do with security. They’re accepting the greater security risk (with your personal information, BTW) to reduce expenses and generate revenue.
That’s it.
And the IT community and the Cybersecurity community are accepting this, not just as an alternative with pros and cons, but as the only way to design a system. Most system architects today can’t even conceive of designing a system with:
1) local servers, or
2) remote servers only accessible through private, physically constructed data circuits, or
3) with the branch data stored at the branch level.
“It costs too much money!”
“We can’t monetize the aggregated data!”
Let me rephrase:
“We won’t pay for security.”
“We care more about making money with your data than we care about protecting your data.”
The Darién Gap
Today’s information systems architects aren’t paid to make information secure. To ease their own conscience, they lie to themselves, and to each other, about how to make public cloud services and data centralization secure – even though every new breach, every new ransomware story, demonstrates that it simply cannot be done. It has never been done. There will be more breaches this year than last year. The road to creating Internet accessible, centralized data is the Darién Gap of information systems. This is not the way.
This is the way:
- Data that is only accessible via private data circuits is always more secure than data accessible from the Internet.
- Segmented, distributed data is always more secure than centralized data.
Does Secure Architecture Really Cost More?
That’s the wrong question to ask. You should feel guilty about asking it. The right question, the moral and ethical question, is: What information systems architecture, and what business operations practices, will provide safety and security for our customers and stakeholders?
Be sure you understand this. You aren’t comparing two secure alternatives to see which one costs less.
You’re deciding if you want to design secure systems.
And if you do decide you want to design secure systems, you’ll quit aggregating the data in online storage, and you’ll move as much of the data offline as you possibly can.
–Bob Young
July 10, 2024