Now that I’m retired, I try hard not to be the guy who stands in the back of the room and shouts “You kids get offa my lawn!” but I have to admit that I often feel that computer security (as a field, in general) has gone horribly out of control and is thumping through the rough terrain and weeds while the driver, who lacks vision, keeps grasping for simple solutions to what is really a complex problem involving strategy, economics, and skepticism.

I did an interview with ITSPMagazine’s podcast back in November, in which I did a lot of high-level grumbling that amounted to “kids, these days…” [itspm] Since you’re already familiar with my thoughts about security nowadays, e.g.: how Parler managed to build a fine hole for itself, then crawl into it and bring in a power-shovel, [stderr] you probably already know the sorts of things that I have to say. I’m tempted to listen to it, and pull out some quotes, but really it’s summarizable as:

Things suck and will not get better.

That’s an easy prediction, after 30 years working in IT security, and observing that things sucked when I got into the field, and they’ve hardly improved. I.e.: I may have wasted my life (but the food pellets were good!)

After we were done the interview, they asked if there were any other topics I felt particularly strongly about, or about which I had interesting views. Hint: don’t ask a question like that unless you want to be deluged. Coincidentally, a few minutes before we started recording the interview, I had just done a consulting call regarding “zero trust networking” which is an idea that is being promoted by a firm that builds such technology and is trying to seed its market. So, I immediately suggested that they could interview me (“bad cop”) and my old friend Ron Dilley (“good cop”) about zero trust networking, because surely we could help illuminate all the things. What I meant, of course, was “we will leave you with your head spinning and a sense of existential despair.” In other words: the correct head-space for an IT security person. If you’re not regularly despairing, you don’t understand the situation very well, or you’re partaking of opiates and I hope you brought enough to share.

The resulting interview is [itspm] here.

Ron and I both approach the problem as a question not of specific technologies, but as a problem in control bandwidth. Individuals and organizations have to make strategic or policy decisions about security and how it fits into the big picture, and many organizations aren’t willing to pay the cost to do so; consequently they end up with exactly the security that they bargained for, like Parler. Or, as Buckaroo Banzai almost said, “if you don’t know where you are going, how will you know if you get there?”

I posted this earlier elsewhere, but it’s a good framework for many organizations’ security strategy process:

1. “We need security”
2. “Buy stuff”
3. “Now, we are secure”

Naturally, unless you have defined what security is, for you (strategy) then the tactics (“stuff you buy”) is a crapshoot and the result is never “now we are secure” but rather endless “… maybe?”

Add to that toxic optimism as transmitted by vendors’ marketing teams: “this will solve your problem!” Uh, which problem? and the computer security market looks more like victimization than problem-solving.

Note: I am carefully not repeating any of the points that Ron or I made in the podcast, because if you are interested, you’ll listen to the podcast and I wouldn’t want to be repetitive.

One thing I carefully did not say on the podcast is that “zero trust networking” products are absolutely not “zero trusting” anything. The “zero trust networking” products are a management plane that centralizes a form of detailed access control – you can flip switches about who can talk to whom and what and when and, since the 1960s people like Dr Roger Schell [ranum] have been calling it (depending on how strongly it’s guaranteed) “mandatory access control” or “discretionary access control.” The “zero trust networking” products out there are “a discretionary access control automation framework” and the fact that the very vendors that are claiming to sell that, don’t understand that, ought to be a great big red flag to you.

Another way of thinking about “zero trust” as a management plane is this: what happens if bad guys take control of it? If the answer is “they can do anything they want” then there is no trust boundary. The entire purpose of trust boundaries is to prevent a compromise from cascading. This is all my round-about way of saying that “zero trust networking” is utter bullshit.

[I thought about putting a “red flag” image in, about here, and did a google image search for “red flag” which caused me to conclude that – wow, that’s an overused metaphor. Forget it. On the other hand, I still need a good image for “stupid roger” and Great American Satan is too busy doing self-sustaining work to make me one, even though I offered him money, waah waah waah]

The premise of “zero trust networking” is one that has been around for a long time (I first encountered it in the early 90s) and it appears and vanishes because it’s a hard problem. That’s being nice. It’s actually a stupid problem. Given that the internet protocol software relies on crucial decision-making data from off the network, it’s not possible to build a usable untrusted network with those protocols. I used to tell people “if someone says they don’t trust the network, say two words to them: ‘arp’ and ‘dns’ and if they don’t shut up and change the subject, they are clueless.” In the podcast, Ron tries repeatedly to tackle the trust issue in “zero trust networking” by pointing out that you have to trust a slice or stack of features from the application layer down to the physical link layer and everything in between – you can’t just trust one piece of it because all of the other layers are perfectly capable of cheerfully lying to you. Ron’s just a lot nicer than I am. “Good cop” remember?

My attempt to frame the problem is from the standpoint of governance/management cost and the simple fact that if you expand your trust model to a matrix, it’s easier to manage a 5 x 5 matrix (25 items) than it is a 121,281 x 121,281 matrix, which is a random approximation of the number of entities that might exist on a typical large corporate network. Individually managing those entities is brain-bustingly complex, so we reach for organizing principles that allow us to establish groups of behaviors which we may as well call “firewall policies” and “IP address groups” and “application groups” etc.

Let me put that another way, as I have explained it on many “zero trust network” consulting calls: between VLANS, per-port controls in your switches, and edge firewalls, you already have all of the capabilities from which you can build “zero trust” models. Yet, you don’t. You struggle to merely define your network into segments or zones and that’s hellaciously hard. Why on Earth would you want to manage a zoned network where number of zones = number of systems? That means that number of control points = number of systems, squared.

Enjoy the podcast, if you think that sort of thing is interesting. I swear, I’m trying hard to be nice in the recording and I don’t think I specifically referred to anyone as an “idiot.”

Oh, one more nail I just have to hammer into that particular coffin: heterogenous systems. The “zero trust network” products that people are pushing run on one, maybe 2 operating systems or in a networking device that controls the network fabric. The latter, I call “a firewall” and that makes the “zero trust network” product “a firewall management plane” (note: the firewall is trusting the management plane) If the idea is that the endpoints are, you know, not trusting the network, then the controls have to be applied at the endpoint. In which case I’d call it “a distributed endpoint firewall with a management plane.” But the endpoints, in order to participate, have to be commonly under that management plane – that means every device, switch, router, web cam, desktop, server, virtual server – every thing with a network address. (and dual-addressed things need to be treated as unique by address) See what I mean? You cannot believe in “zero trust networking” and not understand this stuff; it’s Security 101. I helped write that book.