This “zero trust” thing is really starting to get out of hand. It’s clearly the newest security drug everyone seems to be pimping on every street corner—from vendors to advisors to the media.
“Pssst….hey buddy. I know they say you can’t buy it, but…wanna fix?”
The reason it’s so important to get these low-class dealers off the street is they can’t even stay consistent with their own hype. It’s like they’re 7-year-old girl, sitting on the wall thinking about a boy, daffodil in hand, saying:
“It’s the network”
“It’s not the network”
“It’s the network”
“It’s not the network”
…until she runs out of petals.
To illustrate the diversity of fixes on offer depending on which corner you happen to visit, I first present a fairly common view of zero trust that appeared in my inbox today as Exhibit A:
===
Zero trust was a term coined by analyst firm Forrester in 2010 to describe the need to cope with ever more complex IT security requirements that put increasing strain on perimeter-based security measures.
…
For Walsh and Grannells, zero-trust default security means that nothing is trusted outside or inside an organisation’s network, so controls must be put in place to reduce risk to an acceptable level. In other words, defence in depth.
They say: “Zero trust changes the traditional model of ‘trust, but verify’ – where you assume that any device or asset attached to your internal network is likely to be permitted and safe to access internal-only resources, but still verify that this is the case. Instead, that becomes ‘never trust, always verify’ – where every device must pass authentication and security policy checks to access any corporate resources, and to control access only to the extent required.”
…
Trust involves an interplay between people and technology. According to Walsh and Grannells, the starting point for these trust factors is a well-thought-out and up-to-date set of policies, standards, procedures and work practices, supplemented by detailed, up-to-date network documentation and asset inventories covering information, software licences and hardware.
===
Now Walsh and Grannells seem to be lawyers (even if one’s a partner) in Fieldfisher (or it’s a Think Tank. It’s hard to tell), so I guess you might forgive them for being so IT-centric. But all that talk about policies, standards, and the rest of it—especially the way they ignore the elephant in the room:
The part that goes: “we think we can isolate access to the information we don’t really understand by isolating access to the systems we THINK access and store that information.”
And since we don’t really know how to solve those hard problems, we’re back to the bottom-up architecture approach I mentioned this morning—
Focus on what we can find, kick and lock down…
…because at least we can do something, and at the same time leverage the tools we already have, right? And if it’s locked down,
It must be secure.
Next, for your reading amusement, I present Exhibit B, a snippet of an interview with John Tolbert of KuppingerCole linked from Exhibit A:
===
“Many people associate this approach with the network, but zero trust is really an architectural design principle,” he told Computer Weekly.
“While a zero-trust security model is definitely applicable at the network level, it is about applying a notion of identity – specifically authentication and authorisation.”
This ensures that all traffic within an enterprise is properly authenticated and authorised, whether that is someone coming in from the outside on a virtual private network (VPN) connection, an application talking to another application on the network, or a user trying to use an application on the network.
===
In Exhibit B, for all their “it’s not a network thing,” the only controls they actually consider are…
…network security controls.
Go figure.
Now you might be thinking, “But Andrew, they mentioned it’s an architecture principle. Why don’t you quit bustin’ their balls?”
Because it’s funnier than the first Lethal Weapon movie to think that you can pay lip service to architecture principles when
…we’ve already established that almost nobody really does much architecture
…and if they do, the architecture the create is limited to the infrastructure and connections of the components within it
…and even if they did do architecture, the standard go-to frameworks are mostly either IT focused or control libraries, so there’s no chance of getting close enough to the business to do anything much more than try and circle the wagons tighter than before around the things we think are important to the business…
…without having the validated traceability required to PROVE they’re important.
“Oh, come on, Andrew,” you might say. “Everyone knows they’re important if they process business data.”
Oh, really?
How important are they?
How much investment in low-level security components to create and manage the circled wagons is actually justified and where should that investment be made…
…and in what order?
[crickets chirping in the darkness]
There is a nugget in Exhibit B, however, that does point the direction to the legalization and regulation of the zero trust Kool-Aid that will clean the low-life drug dealers off the street, and that’s the admission that:
“…it’s about applying a notion of identity—specifically authentication and authorization.”
Correct.
But without the proper architecture models of you organization – and the reality of the state of security architecture in general – it’s no wonder the corners are filled with shady characters peddling magic band-aids to the antiquated perimeter defenses people still seem to have in place.
All that implies that actually, architecture now matters more than ever—but only if it’s the RIGHT approach to developing architecture to deliver the right kind architecture artifacts.
Architecture that’s actionable.
Architecture that’s really used.
And, most importantly, architecture that even the business owners of the information and value we’re trying to protect can understand and independently judge that, after all,
“Those security guys are really doing the right thing.”
Are you ready – right now…today – to build that kind of architecture?
Are you ready to be able to build a compelling case why the opportunistic zero trust drug dealers shouldn’t hold out their hand and take great gobs of your security budget?
Only you can answer that question. Not me.
All I can do is say that the architecture I’m talking about depends on a formalized, reliable…
…and actually APPLIED…
…understanding of SABSA domains and trust relationships beyond what you might’ve learned in the official SABSA Foundation training—and even what you might have done in the Advanced courses, if you’ve done those at well.
It’s the kind of understanding that you can only get as part of going through Module 1 and Module 3 of the upcoming run of our Building Effective Security Architectures program. It’s the kind that depends on a deep understanding of the theory why SABSA domains actually work
…and how to apply that theory – quickly, easily and effectively – to build the architectures that underly a truly business-driven security program…
…which just happens to deliver all the “zero trust” you’d ever need.
Because it’s baked in.
By design.
By principle.
By practice.
And if you’re thinking that maybe because you were in my COSAC presentation last year when I started to explain this, you might already understand it. However, I can tell you that that was only the beginning.
The rest is something you’ll only find if you’re a member of the program cohort.
And the time you have to do that is running out faster than a greased pig slips through your fingers at the county fair.
So if you want to join the cohort before the registration deadline closes on Friday, just 3 days from now at 11:59pm US/Eastern…
…then you’d better push on past those zero trust drug dealers and visit this link:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
