Unspoken Security Ep 52: Do We Even Need Operational Technology-Specific Threat Intelligence?

AJ Nash and OT specialist DJ Jablanski question whether OT-specific threat intelligence actually works, arguing that basic controls like network segmentation matter more. They criticize vendors for exaggerated claims and call for honest data and better visibility into what organizations are actually protecting.
Chapters
, when it comes to cybersecurity, we have not done a good job articulating here are the ways that cyber instances can create those same failure modes that you're prepared for and understand to a ridiculous scientific degree. And that's where we are today in OT. That's what we're really, really focusing on is how do we bridge that gap, drop some of the jargon, and be able to build good people, process, and technology activities around those types of learnings. So that this always-never principle that I borrowed from OT is effective across cyber-physical environments. It's always ready to be used with our control, and it's never going to be used or abused or turned off, essentially, you know, inaccessible, bricked, DoSed, whatever, when we need it to be accessible.
Welcome to Unspoken Security, the raw and gritty podcast for security professionals who are looking to understand the most important issues related to making the world a safer place. Including intelligence-driven security, risks and threats in the digital and physical world, and discussions related to corporate culture, leadership, and how world events impact all of us on and off our keyboards. In each episode, host AJ Nash engages with a range of industry experts to dissect current trends, share practical insights, and address the blunt truths surrounding all aspects of the security industry.
Hello, and welcome to another episode of Unspoken Security. I'm your host, AJ Nash. Spent 19 years in the intelligence community, mostly at NSA. I've been building and maturing intelligence programs in the private sector for 10, 11 years now. I'm passionate about intelligence, security, public speaking, mentoring, and teaching. I also have a master's degree in organizational leadership from Gonzaga University. Go Zags! And I continue to be deeply committed to servant leadership. So this podcast brings all these elements together with some incredible guests to have authentic, unfiltered conversations on a wide range of challenging topics. This is not going to be your typical polished podcast. My dogs make occasional appearances. People argue here, we debate, we even swear here, and that's all okay. I want you to think of this as a pod— this podcast as a conversation that you might overhear at a bar after a long day at one of the larger cybersecurity conferences. These are the conversations we usually have when nobody's listening. So today I'm joined by Danielle, DJ Jablanski of STV, a professional services firm that specializes in infrastructure, including transportation, buildings, and water facilities. DJ leads STV's operational technology, or OT, cybersecurity consulting program, advising clients in security program development, strategy, tool selection and development, or in deployment, I should say, to mitigate cybersecurity threats facing operational technology and cyber-physical environments across transportation, energy, water, and infrastructure projects. So just all the things we use all the time. With past stops as an SME in the Office of the Technical Director of CISA, at Nozomi Networks, and at Guidehouse, DJ is an experienced strategist, analyst, and program manager with hands-on industry and governance experience in OT and industrial control systems. She's an expert. DJ, anything you want to add to that?
What's not in my short bio is I also teach. So I have two courses. I teach an undergrad course on ICS cybersecurity, and I teach a grad-level course at Middlebury Institute on Cyber-Physical Defense that's launching this spring. And my undergrad course is at the Dallas College, community college.
So, well, well, that's very exciting. And I didn't know that. That's very cool. So as usual, my guest is far too good for this show, but I've suckered yet another person into spending some time with us today. So, and I'm really excited to have this conversation actually. Operational technology, we don't, I don't talk about it enough on this show. And it's an important thing, right? It comes up obviously every once in a while in the news. We get something about a massive ransomware attacks, something like that. This is a huge issue that we really should talk more about. So I'm, I'm really thankful that you were able to make time to come on today. And so let's jump right in. You know, for, for folks who don't know, I always like to level set. You never know the audience. Some people are really experienced and some not so much. But when we talk about operational technology, what are we actually saying? What are we talking about?
Yeah, I always call this an umbrella term, and I promise not to read too much definitionally from the internet, but I did actually write the, the latest definition we have from CISA. So there's a new document that came out from CISA, the Asset Inventory Guidance for OT. And it basically just captures operational technology as a broad set of technologies covering process automation, instrumentation, cyber-physical operations, and industrial control systems. Mm-hmm. So we usually hear industrial control systems when we think of controllers, but we don't really understand the nuances and layers and what that means for like network architectures off the bat. So again, most often we're like referring to ICS, but it actually could in— incorporate drones and IoT and robotics, right? The OT umbrella covers all those things that do something physical in the real world. In my class, when I'm giving examples for those who, you might have mentioned, don't have the background, it's the baggage claim at the airport, right? It's— that's running on a motor, and that motor has something that's programmed. It's called a jog circuit that can be safe or unsafe depending on the programming, and accessible or not accessible depending on the network, right? And then in more of our day-to-day examples, when you go to get a car wash, there's a touchscreen you're pushing, right? And that touchscreen actually starts a sensor process that moves something in the physical world. Hopefully your car with your windows up. That is an HMI. It's a human machine interface. And so all of those things go into what we think of as, as operational technology. From the security perspective, there are a lot of industrial control systems that are called legacy devices, and that means that they were created before we really thought about security, whether that's like memory safe language or encryption. And they run on proprietary protocols. So OT gets really, really convoluted and complex really quickly. But the one thing I'll make sure to say is that a lot of these industrial control systems are built on relay logic. So we've borrowed a lot from the electric sector and they're designed to ensure predictable and reliable data exchange. So they actually grew up out of serial bus communications to Ethernet, Ethernet IP, and they were not created for that. So this real-time explosion of communications industry 4.0, 5G, all these things that are hitting right now, we're still playing catch up, you know, to get to where IT was 10 years ago. And we're talking about OT security. So there's so many different facets of OT. And I, I really wanna encourage your, your listeners to, if they're not, you know, maybe they don't touch it or they think it's too opaque, just jump into one of those little nuggets and, and learn a bit more.
Well, and it's a little, it's disturbing, I guess, is the word I'm gonna use for this. That we're, you know, we're behind on something that is, it affects so many things, right? In, in big ways, right? And, and listen, this is how technology works. We know that, right? The internet wasn't designed for what we use it for. So, you know, it was designed, you know, for free sharing of information by scientists. So security wasn't thought of and afterwards trying to bolt it on. Lo and behold, the internet's really never been secure as a result. And that's sort of the same thing here. But the challenge is, you, when we were talking about ICS, you're talking about industrial control systems. I mean, I know you gave a couple examples, but you know, for those who don't know, you know, this is, uh, stoplights. This is, water pumps and pumping stations, power stations, every, uh, major—
fuel tank gauges, electric grid, uh, rail transportation, rolling stock for trains.
Right. Oil pumps. Like everything that a machine does essentially that is a modern machine.
Yeah. Anything that used to be analog that you rely on today basically for civil society.
Right. And most of them are tied to the internet in some form or fashion, whether it's, you know, a closed network or an open network. And unfortunately closed networks become open very rapidly as anybody might recognize. Right. Just watch the news. So, so basically we're saying some of the most critical things that we all depend on for our safety, our security, our, you know, modern world living are tied to systems that weren't designed for that purpose and aren't, are, we're still trying to play catch up when it comes to securing them and, and, and building safer systems. So that makes for a busy career, I imagine.
Yeah. I'll just add the one thing that people don't understand is that we're not directly interacting with them every day. So it's not necessarily that they're set and forget. There's so many proprietary ways to configure these things that there are technicians who might come in and change maybe a set point or a, you know, part of the direction for the actual software that's executing. But the built-in variables and tag values and things like that just depend on the vendor. So there's so much expertise vendor to vendor that's required to do this. And that human interaction with some of these control systems just doesn't happen very often. There's a control level that a controller is actually interacting with the valves, the motors, the sensors, the pipelines, the flows, the tanks, all of that in real time instead of a human. And so that's the other kind of layer of abstraction on top of technology that we have to remember.
And so how many manufacturers— like, I'm sure there's a lot, but like how many major— like Siemens obviously comes to mind. I know Siemens.
Yeah, there's a ton. You could rattle them off. There's ABB, Honeywell, Schneider Electric. You know, we go on and on.
Oh yeah, Schneider Electric, sure.
The average though on a plant floor or in a factory, 'cause we haven't even talked about manufacturing, right? Production lines. Uh, it's, there's an average of about 12 per, uh, environment, typically different proprietary OEM. And then that protocol, they could run multiple protocols. So I always kind of detail it as like a Rubik's Cube. It's not quite in the quintillions of permutations, but the, yeah, number of different ways that you can configure and deploy these purpose-built systems is A large number.
And so I, unlike IT where nobody seems to have their CMDB sorted out and nobody understands their assets, I'm sure everybody's got this all locked down for OT, right? People know where all their assets are, they know all the different, you know, variations they have. I'm sure they understand what's updated, what's patched. We don't have anything to worry about there, right? Everything's solid.
I'm glad you asked. So, um, I referenced that asset management guidance that CISA did put out, and I actually pushed for that guidance to come out because there was no vendor agnostic guidance on asset management. There's also for OT, and there's also no guidance on network segmentation principles for OT. So there's a draft sitting somewhere at CISA that, that people need to co-seal and review and change from my original draft that'll hopefully come out because the vendor specific product stuff says, here's everything you should care about because this is how our product is built and this is what we're good at, which is fine for sales, but we need vendor agnostic guidance. And so no, there's, there's not a lot of great asset management out there at scale. There are certain companies that have good budgets and big teams that can do this for OT, but visibility has become this huge buzzword across OT over the last 5 years. And that's what made my career, right? I worked in one of the continuous monitoring solutions. I was a strategist there doing market strategies and product strategy, even some cooperation with some of our competitors, and then all of our kind of government affairs and things like that. When I— the big issue with the breakdown is depending on who you ask, those tools are for asset management or security, and then in the middle, sometimes both. Um, and so when I went to CISA, I actually did a listening tour and I asked roughly two dozen asset owners across all the cyber-physical sectors within the 16 critical infrastructure sectors. So like everything but banking, and I think IT I left out.
Sure.
You know, what are you guys struggling with? And the number one thing was asset management. And it's really scary, right? Because the lack of regulation that exists at, like, we didn't reference chemical, right, as a sector either. Oh, right. Which sometimes, like, pharmaceutical sits in one or the other. Chemical touches a lot of our food production in the United States. And so I saw major chemical companies saying, well, it's not enforced, there's no regulation that tells me I have to do asset management at scale, so we buy so many companies, we just leave it to them. So their security posture is distributed rather than centralized. And I'm not here to say whether or not that's a good idea.
Oh, I am. It's not a good idea.
I'm here to say that the asset management gaps are obvious, or the visibility gaps are obvious, whatever you want to call it.
Yes.
Um, And again, yeah, there's a, you know, food, there's chemical companies that touch 70% of our food in, in the United States. So it's something to be at least cognizant of that we can start to set some mile markers for going forward.
Well, and you, you make a good point, not calling out anybody in particular, which is smart, but companies will say, well, there's no rule that makes me do it. You know, there's no law, there's no regulation.
Mm-hmm.
That's, I mean, that's the crux of it unfortunately, right? You know, there are plenty of people who are anti-regulation for a number of reasons and, and I get it. And some regulations are onerous and difficult, et cetera. And regulations slow down innovation. There's plenty of logical, strong arguments against certain regulations. Yeah, but the blanket argument of just no regulation, deregulate everything, you know, free market, run, run, run, it kind of falls apart when you keep in mind that businesses, you know, for-profit enterprises, their only model, their only goal is profit. And that's not— I'm not saying it's evil. I'm not saying, you know, capitalism is a problem. It's actually a fiduciary responsibility of those companies that they are required to do what's in the best interest of their stakeholders.. And so they're not going to decide to spend, you know, hundreds of thousands or millions of dollars or tens of millions of dollars on a thing they're not required to do because that's gonna hurt their bottom line.
The ROI for some of the tools becomes this whole conversation around if a tree falls in the woods and nobody heard it, or like, right, exactly. If you come from counterterrorism, like you don't hear about all of the attacks you've thwarted, like the same ROI problem exists for some of these tools. And I've seen this kind of confluence of tool outcomes and metrics becoming the risk management metrics for organizations. Yeah. And that's like a complete recipe for disaster. When I was a consultant before this time, actually a number of years ago before I joined Nozomi Networks, there was this kind of rule of thumb that the 60/40 rule existed for companies that were in deregulated markets, that 60% would wait around and see what the other 40% did if they wanted to lead on something cutting edge. And then the 60% may or may not follow after seeing what the 40% success rate was. The most widely used analogy, I think, for cyber has always been like the seatbelts argument, right, around safety. And the safety issue is huge for OT, right? Like, we need to lean into that everywhere we can. But I, I argued for a long time in cybersecurity writ large that it was 80/20. 80% are going to wait around for the 20% that want to do something different or groundbreaking or instrumental or coordinated. Um, and honestly, those 20% have more money and more people and more lobbyists and more visibility and more government relations. So it's not like it's an even playing field for the 80%.
No, it's definitely not. And sadly, I might even argue it's not even 80/20 anymore. I think it's leaning further the other direction.
95/5.
I might say, yeah, 90/10, 95/5. It's, you know, I've had this discussion on a few shows now, so I hope people listen to more than 3 shows if I get bored of it. But when I first moved from the government to the private sector, I moved, I was in the financial sector, and it was very clear why we did what we did. Again, I'm an intel guy with cyber intelligence and, you know, intelligence-driven security. But it was very clear why they were willing to spend the money, cuz everybody believed, hey, we're a bank, you know, we work on trust. If we get compromised, people won't trust us, they will move their money. Well, it turns out that's not true. We've had so many breaches and so many compromises over the years, and you go and you look and you find out that companies who've had terrible incidents happen, yeah, they're fine. Their revenues go up next quarter, their profits continue to go up. That's it. That's the motivator for, for private enterprise. If it doesn't actually hurt my bottom line, And it isn't legally mandated, keep in mind. Then why the hell would I do it? Right? It costs a lot of money to do these things well, and nobody seems to care, and there's no consequence. Now, OT hopefully will be a little different, sadly the hard way, because eventually people die in the worst case circumstances. But then again, you look at the Colonial Pipeline, what a disaster. It wasn't a— oil didn't end up everywhere. It wasn't that kind of a disaster.
Right. What a terrible situation. And OT actually wasn't impacted from a technical perspective, which is great. They actually had the visibility to say with meaning, we have evidence to suggest we're not just guessing and hoping. We actually have the integrity in our security monitoring to say OT has not been directly impacted, but out of an abundance of caution and because we can't make money on the transactions, we're going to shut it down. There's a lot of really good research out there that for the last 10 years has pushed back against the reputational risk as a false assumption for cybersecurity. It's really good. There's actually research out there that suggests that the way you respond is, makes, makes more, makes or breaks your reputation. 100%.
And that's what companies are doing. And they figured that, and it's cheaper. Like it's, yeah, there was an article that came out a couple of years ago. Harvard Business Review did a piece that I really disliked and I normally really like them, but it was a piece that basically talked about, again, what I was saying, that there's this deterrence factor, but it was old. It was relatively new, but it was based on really old data. And I was like, this is bullshit. And so I went and did my own little research and came back and I wrote a piece that was like the 9 biggest breaches of the year. And I showed what the, the quarterly revenue was before and what it was the next quarter and what it was the next year.
Yeah.
Tie that also to, there's a generational shift. There's a, a younger generation doesn't worry as much about security or privacy, so they're not worried about, you know, credit cards being compromised, things like that. And I pointed out that there's a fallacy that this is still a deterrence, but as you said, it's how you respond. Listen, my bank, my bank has figured out The answer when my credit card is compromised is to give me no friction. Bingo, done. You know, here's your card's shut off. I have a new card in the mail, 24 hours it's at my house, and I already have a virtual number 3 seconds later that I can use if I need to buy something that minute. And they start moving all my accounts around, my, my recurring payments, et cetera. They have figured out that's the answer.
They own the risk. There's also silent cyber coverage from the insurance market that nobody really talks about, but there's been some precedent set in the courts because there hasn't been good legal precedent elsewhere that basically says that there's a lot of coverage that companies can recover from other policies, which makes it silent cyber coverage, which is why we call it that. So like for Target, you know, even though they had an HVAC incident, they could claw back money from insurance by saying it was the same as theft, like you walking into the store and stealing merchandise. There was an ATM incident, same thing. They were able to argue even though it was a remote hack that It was similar to me stealing your debit card. So silent cyber is, is kind of, I think, not forcing our hand in terms of some of the more regulatory aspects that need to be sorted out. Uh, the GPAC is another good one to read into. Even the Uber stuff from years ago in Arizona, really good legal precedent to look into.
Yeah. So I mean, it's, it frustrates me because again, my goal coming into the private sector, you know, like everybody's I'm sure, was to make things better, right? To contribute to improved security, you know, in my case, intelligence-driven security, you know, bring the best of the government's, you know, knowledge into the private sector or whatever little bit I had in my head at least to be one cogs in the wheel and, you know, and help improve things. And I've, I've been frustrated. A lot of times you find organizations that, oh, they, they maybe were committed to it, but they're less and less now. It's, it's, they do the math over how many years is it gonna take? How likely are we to be compromised? How bad's the damage gonna be? How much does PR cost and, and recovery versus actually doing prevention? I hope it's a little different with, with OT. Again, I, you know, I deal mostly with IT. With OT, again, if people do that long enough, what happens when all of our stoplights don't work that day because somebody tampers with them and we have, you know, massive car accidents? Yeah. When water stops flowing, you know, there are things that are much more significant. So I'd like to think people take it more seriously because life or death shows up faster.
We do take it more seriously because we have to, like you said, but also because from the security perspective, majority of people have bought into the fact that the OT version of resilience, which IT typically defines as like the ability to remediate, isolate, remediate, recover, mm-hmm, is actually just the ability to operate under compromise. And you can't operate under compromise if your system's integrity is in question. So for water, as an example, if you don't know whether or not to tell your constituents to boil their water and it's safe or to evacuate because it's so unsafe, then it doesn't matter. If a threat actor can take a screenshot of a mimicked screen and say that they can manipulate controls, or if they can actually change set points in the control logic, because your integrity is so questionable that you cannot continue to operate under compromise. And so that's really been some of the business continuity planning and impact analysis work that's gone into, um, OT. I push for a long time something I've borrowed from my nuclear weapons policy background, which is effects-based analysis versus means-based analysis. So regardless of the means that a threat actor might have or the capabilities that we can derive from the MITRE ATT&CK for ICS, they— there's a specific one. What is the worst effect that can be caused with the technology that I have, the process that I run, the, you know, range of values you can set this to, the safety system, the environment, right? Like, what is the worst possible outcome here? Is it a fire? Is it a hazardous material leak? Is it, you know, something getting stuck somewhere? Right. Is it dropping a really heavy piece of equipment? Right. Like, What is the physical worst case scenario? How do we potentially alert to that worst case scenario? And how do we then defend with that defense in depth approach, access to those crown jewels, right? Because we work back from there and do that crown jewel assessment. Whether people test that or spend all their money on doing means-based assessments, unfortunately, and learn from those is a different story, right? Depending on the, the program. But that's one I've borrowed from, from, you know, military. Obviously we don't clear what type of weapon you use. If, you know, there's a threshold of impact, then there's going to be a, you know, particular response for that, that impact, as you know. Yeah.
Well, and also you've got, and I assume you're doing this, but I'll ask anyway in case it's not part of what you're doing. In the military, we also talk about, you know, the most dangerous course of action, most likely course of action, right? So you map that up against adversaries. If the most dangerous thing is, you know, an unintentional, you know, nuclear detonation in a silo. Okay. You know, can China do that? And, and if the assessment is no, they have absolutely no capability to do it, it's completely air-gapped system, et cetera. It doesn't matter. It's the most dangerous. It's, it's completely unlikely, right? So what you work on, as you know, I'm sure, is, is to start in that top right corner, most likely, most dangerous.
Right.
And then, you know, you figure out where the, it's, it's for those who don't know, it's like a heat map basically. Top right's normally very red and then you get, you know, the oranges and the yellows and the greens or whatever. And, and so the idea is just to work from top right down and, you know, most like, most likely, most dangerous to least likely, least dangerous. And nobody bothers to mitigate the least likely, least dangerous, frankly, because You can't stop everything. And if that happens, you go, ah, big deal, butterflies, and you move on.
There's 6 scenarios that the NIST wrote for OT in their guide. It's the NIST 800-82 Revision 3. And there's 6 generic scenarios that I like to use with organizations and I make them specific. So most recently I did this with a major commuter rail entity and just kind of postulating, hey, are you prepared for these scenarios? And so OT does focus in on high consequence scenarios. But we never suggest avoiding those high consequence scenarios because they're unlikely because of that responsibility to, you know, protect people, right? Lives, human lives, safety, uh, environment, and then economics. So the most likely is always going to be ransomware still. And, you know, the, there's this theory of 99 that Mandiant wrote about in 2019 that suggests that 99% of OT incidents start in IT. So then you talk about lateral movement and the kill chain and what that means for OT. And that's why people have really jumped onto that visibility piece of, well, I can't protect what I can't see across OT, so I need more visibility. But then they just use visibility metrics as if they equate to risk reduction, and they don't, because visibility intelligence, as you know, is actually meant to produce, uh, a decision, not just more data and more metrics. That tide is starting to turn a little bit, but, uh, the jury is definitely still out there on, on how much is enough good data to train for OT incidents based on intelligence. And something that might pique your interest is like intelligence in OT has become, it's kind of in two camps. It's either a bunch of emails and manual work to piece things together from multiple sources, or it equates to detection, period. I have rules and behaviors in a tool I have to buy, and I need to be able to tune and deploy that tool to the best of my ability to get the maximum ROI to meet my risk reduction metrics for my program. Not the best two camps for intelligence in the world, but that's really what we've gotten to. I actually heard a product the other day claim that they have 23 open source, uh, sources for their— I don't want to name the product or allude to it, but to like what they're mapping against essentially for available TTPs and ICS.
Uh-huh.
I could not, gun to my head, name 23 sources that had OT-specific and, you know, not codependent sources. Yeah, not circular reporting or intelligence that would really, you know, have a— have that impact.
So are you suggesting there's a chance that a vendor might be dishonest in their marketing in some fashion? I'm suggesting some numbers a little bit.
A lot of OT, uh, spaghetti on the wall, like, type attacks that we're claiming might be OT incidents. That are really kind of part of your general intelligence that you might not need to spend twice on. That's it.
Well, and that does happen. Uh, yeah, it's a common problem. And yeah, having built Intel programs and then having helped other people do it, I've also said some redundancy is good. Yeah, the first thing is to know what your redundancy is. Don't buy a bunch of feeds and then find out later, you know, you're comparing contrast, like, geez, 80% is the same from 4 different companies. Well, you paid a lot of money then.
Well, it's not just the feeds, right? So one of the core principles for intelligence collection is multiple sources. And the problem we have in OT is that the telemetry data for visibility that is being sold in the monitoring tools is in private solutions or OEMs.
Yeah.
So we've got this really great intelligence on IT incidents across critical infrastructure, but when we say critical infrastructure, we don't typically delineate whether or not we're actually investigating IT versus OT versus all the different types of traffic. We're talking about networks of networks, right? We've got cellular, we've got you know, fiber cable, all these different ways to connect and, and do network monitoring from just an NSM capability. And then how do we add feeds and rule-based detections and anomaly detection to understand the actual process variables for the environment on top of that? That's pretty sophisticated stuff. It's not that it doesn't exist in the vendor market. I know it does, right? That was my expertise. It's that like the companies buying the tools may or may not be ready for those you know, future use cases.
Mm-hmm.
Yeah. And might kind of spin, spin their wheels on some of that intelligence that really just is like lots of malformed packets, which is great intel. It's just, I don't think that detection is the end-all be-all of how we use intelligence.
No. And, and, and you're right. There's a lot of organizations that don't have the maturity. So you have some organizations don't have any intelligence because they just don't. There's less of that now, thankfully. And then you have some that have bought a whole bunch of it, but don't know how to use any of it because they weren't mature. They just, you know, hey, we're gonna buy stuff. They got a budget, they got excited. They decided they were gonna name somebody the new director of intelligence, cyber intelligence for the organization. And that's Bob, who was doing incident response last week. Bob doesn't know anything about intelligence, but now he's in charge of building an intel program and has a budget. He buys a whole bunch of fancy stuff cuz there's vendors there to tell him all the great things that are gonna make his life easier and make him a hero. And yeah, and then you find out later like that maybe there was some other steps that should have gone in. There's some planning direction, you know, maybe we shouldn't have run to do all these things and you haven't really made yourself safer. You've made yourself noisier and tired.
Right.
But you haven't made yourself safer. Signal to noise ratio is a huge uphill battle. And so I've seen organizations rush to put solutions where they've had prior incidents, which is a normal reaction, right?
Sure.
Yeah.
You're gonna put a bandaid on a scar. Yeah, but absolutely. I haven't seen really good intelligence inform other parts of a security posture to the degree that it can. So if we're not just looking to detect IOCs of known bad actors, Why are we not also using intelligence to drive decisions around network segmentation, which has different practices and tools and capabilities and could take years to roll out and get right and perfect? But instead it's intelligence equals detection, detection equals early warning. That's not true because you have to wait for somebody else to be a victim for those IOCs to be created, to be replicated, to be standardized, to have some Staxy rule, like all of those things. Rely on being reactive forever and not extremely proactive. One of my first days at CISA, we did an offsite at the British Embassy in D.C. It was amazing, wonderful hosts. And there was a gentleman there who had been doing some adversarial emulation work before I was there. He's still there, thankfully. And he got up there and he was giving his presentation. He was working with some vendors from the UK actually that were, were really, really helpful. And he got up there and was kind of reading from some of his key takeaways and he said, Oh, you know, in some of our adversarial emulation work, you know, 9 times out of 10, I don't remember the statistics, but it was like some figure saying when they, they're met with really good network segmentation, they give up and move on. And then he moved on and I was like, wait a minute.
Wait, back up.
Yeah. I was like, come on.
Network segmentation is the solution for everything is what you're saying. Hold on a second.
So I, I always, in almost every conversation, kind of revert back to network security time and time again. Like I've joked, if I were to run for president, I would, my platform would be, it's the network, stupid.
But it's still a very small demographic that's going to understand that, unfortunately.
Well, I'd be the president of a very small island, so. But yeah, I mean, it's not necessarily that it's even an OT-specific indicator, but it also gets into like, what is the level of OT-specific information that we're required to share for highly tailored attacks when we see so many organizations not shoring up opportunistic attacks. And so, I mean, I've joked with other people and I think I told you, you know, just in our prep call that when I was at CISA, people wanted to be at these like top classified circles and environments to learn all of these, like when native functionality might be targeted in a specific control logic, right? Component of, they, they wanna know about it. And it's like, well, you don't even deploy that. You don't have that protocol in your environment. So why would you need to know that level?
And Cause it's interesting.
And then this, this report comes out from CISA before I was there a number of years ago that showed, you know, hundreds of instances of Conficker, the worm that won't die, across ICS environments, specifically in ICS networks. And so there's this kind of, I just sit on this like seesaw of if intelligence is detection and detection is prior and we're not clearing up prior issues, what are we really trying to accomplish in our continuous improvement in order to operate under compromise?
Yeah, it's, uh, it's, I, we're not accomplishing a lot is what it sounds like in a lot of cases. I think there are, in some cases, people are really good at their jobs, right? Whether it's IT, whether it's OT, you know, whether it's, you know, intel. I think a lot of people are struggling. I think a lot of people are frustrated. I think, I think we have some maybe aren't up to the task and others may have just worn out. Quite frankly, it's, it is a thankless career field. This isn't an excuse, by the way, if you're shit at your job, get out of your job. Get out of the way and let other people do it because these are important jobs. But I get it. I mean, there are people that are burnt out and they're tired and it's endless and it's thankless. And frankly, the bad and the good all mix together. And if there aren't really consequences, you just kind of get through the next day and, and, you know, it's been very challenging. But no, it, you, you hit it on the head that what we're doing, like, listen, if you're looking backwards, you're not really doing intel. You have, it's, there's some backwards look to understand adversaries, but intel's about looking forwards. It's about understanding what's coming next. It's about going where the ball's gonna be, not where it's been. And about helping, you know, leadership and organizations make informed decisions. It also takes a lot of investment and a lot of energy and time to do it. And it leads to the question I want to get into. I know you wanted to talk about— you've already snuck a lot of the common talking points into this, but should we have OT-specific intel?
Well, I want to push back a little bit on the industry itself as well, and some of the solutions providers, some of the marketing. You know, cybersecurity continues to be an unregulated market in and of itself. So we continue to kind of boast about the ability to alert on, pinpoint, and defend these like needle in the haystack type of attacks, right? But we don't invest in helping end users, asset owners, practitioners build the muscle memory to be able to do that.
Mhm.
So we've just kind of put the onus on tech to do all the fancy math and statistics, right?
Yeah.
All of the engines learning all of the things. To be able to do these kind of pinpointed alerts.
Mm-hmm.
And that's not just in monitoring, right? That's in other types of things.
In everything.
Certified networking, rule-based, just all these things. In OT, everything is so complex and we used to push back against this security by obscurity. So why are we not trying to simplify things? Mm-hmm. That's been kind of a more difficult, you know, since I've left government and I've gone back to the private sector in consulting, I still, You know, talk to companies a lot and I'm, I'm still really trying to stay on top of the vendor ecosystem and luckily I get to do so because I'm in an agnostic consulting, you know, position. But I was reviewing a paper for a company the other day and they were asking, you know, they kept saying like, this is paramount and this is paramount and this is paramount. And I was like, everything can't be. You're actually suggesting something that is a tried and true approach. And if you were to rephrase how you're actually just reframing something that is essentially like. Network address translation on crack. Don't put it that way, right? I mean, the way to go, if you were to simplify this and like offer it up is like, hey, we're actually not trying to reinvent the wheel here.
We think a better way.
Exactly. We think that pairing tried and true techniques to obfuscate some things to the best of our ability, to be able to do a different approach to network segmentation around your crown jewels, X, Y, and Z, that could have these types of impacts, and this is the value proposition. I was like, lean into that. Like, that's what's going to— it doesn't have to be this like whiz-bang use case. Um, if you're simplifying something for, you know, an organization that has one OT, one network engineer who also does IT and OT, and like, great, you know, is doing all the routing, all the configurations, everything else. I was working with a water utility last year who said that like their list of firewall updates, reviews, revisions, rule sets, was the only thing that their main person could get to for the next year.
Oh my God.
And then in terms of like threat modeling, you know, they were kind of asking me these similar questions. How do I understand there's this, you know, sector-specific approach and there are the ISACs that I can draw on. And then there are these really great large companies that do this, you know, amazing analysis, but that analysis is typically regional. And this is something I ran into in government. So I was able to start a, a briefing that was OT specific because I saw really good intel analysts would report on regional trends and there might be, there's really good OSINT on fuel tank gauges. And that's all out there. You can Google it and see what happened and how these devices were found, uh, exploited, potentially internet connected, whatever it was across many different sectors. And the impacts of that are obvious, but typically something like that actually first pops up in a sector or in a, in a regional specific intel report. True. And there was no way in government or other places to then say, wait, we need to go out and grab this like cyber physical potential impact analysis. 'Cause that's just not how we think of intelligence. So that's another horizon, like challenge for OTs. How do we, if it's important enough to share with everyone, how do we bust it out of the regional reporting? Mechanisms that most of our, like, TTP analysis is because it's tied to threat actors in particular regions. That makes sense, right? We have to distill information to make it useful. But an analyst who's trained to understand TTPs from a nation state maybe isn't looking for tanks and valves and pressure sensors, right?
Oh yeah.
Because it's just not how we've thought about impact analysis. Some of the NSM22 work did start to touch on this, right? Looking at some of those lifeline sectors and saying, well, You know, we know if something is targeting this, this, and this, that's looking at the electric grid, right? That's pretty obvious. When we move away from electricity, it gets actually a little bit more difficult to understand what that targeting and blast radius begins to look like.
Is that just because there's a lot of dual-use technologies? A lot of things you can be targeting for attack can be used on a lot of different things. Like the same— I, I might be wrong, by the way, but the same valve that is used in the, you know, oil industry is the same one used for water, for instance. That kind of a concept.
So yeah, like the spoke nature of the purpose-built technology is such that it can be utilized in many different ways depending on the logic and the configuration and the deployment. But it also may or may not be critical in some operations. So sometimes it may rely on SCADA, it may not, it may have redundancy, it might have backup power, it may not. So there's that mission-critical analysis. And this is where people kind of lean on IEC 62443 to do zones and conduit mapping for their networks. But when I did that listening tour at CISA across the US, I don't know if it was selection bias, we did a randomized sampling, but not many organizations had 6443 in mind. It was more of the product certification that came out of 6443 that they paid attention to for the, you know, secure design lifecycle for the OEMs. But there's like this logical mapping around mission criticality and, and how you might wanna segment your network and, and do redundancy there. I wrote a blog about this just to tie actually those, those NIST scenarios that I mentioned to Crown Jewel analysis so that we could do more impact assessment. Rather than just saying, you know, this, this VLAN looks good, let's leave it at that.
Well, yeah. And the impact is what matters, right? So, you know, we talk a lot of times on the Intel side in the private sector, you know, we talk about— and I'm sure OT does too, everybody does at this point— but we talk about the business risk, right? We talk about the business impact because that's— there's a number of reasons to it. First of all, if you want to have a job, you better figure out how to tie your job to business risk and business impact or revenue in some way, or you're going to be, you know, gone eventually. But, but it is a good metric, right? To say, how is this affecting the company positively, negatively, et cetera. And so, you know, that's, that's where we end up talking a lot about, about our, our threats is where does it affect the business? I feel like it should be part of that. I'm sure in OT, but I feel like there's also just a whole different set of threats that go along with that.
Yeah.
That aren't as much business risk as like public, public—
You asked a little bit about like delineating from energy and elsewhere. So in the electric grid, we have bulk energy that serves more people. And so population statistics are really easy to understand for bulk energy, and so bulk energy is regulated, which is great. And ERC-CIP is doing its job. You know, there's different arguments about checklists and compliance versus security, but that's not what this podcast is for. Population mapping for understanding the criticality and impact of electricity is easy to do. In manufacturing, downtime for production is actually easy to calculate.
Sure.
Every other sector gets a little harder. So like hospitals pretty difficult, right? Because you look at locality, you don't know what your backup looks like. You don't know if it's a trauma center. You don't know if they have heart specialists. You don't know if they have who is on call, what their staffing looks like. So actually, you know, people might assume that, you know, in a major urban area they have multiple hospitals. So if one goes away, it's okay. That's not true. And you might also assume that large hospitals in urban areas deserve more resources. But then you start to think about when you get into rural areas, one hospital might be the only one for 30 miles and might service multiple small communities.. And so the population load isn't that high, but the demand is incredible, right? And so that, that can't go down. So that population mapping doesn't equate across sectors. The other thing that I've pushed back against for many years is this issue between prevalence and provenance.
Mm-hmm.
So when I got to government, there were some ideas around projects that we could do, like a national asset inventory, right? What are the systems from OEMs that matter? This is kind of like supply chain risk analysis at the same time, right? Mm-hmm. Understanding the vulnerabilities in those systems. You can't count where these systems exist because they have been in production for 15, 20, 30 years. And so even if you went to the OEMs and said, how many of these, you know, serial numbers have you sold, right? This, uh, you know, you might be able to get some rough numbers. The provenance issue is where this breaks down. So the chain of custody, who first bought it, if it's on eBay today, what status update it's on, what version of software has been updated, what the firmware looks like. What integrator or reseller has touched, configured, designed, turned something off, enabled a feature? That provenance chain of custody problem is bigger than any one company, government, organization, any mission that we have out there to solve the OT problems because it's bespoke and purpose-built. So it's not just whether or not it's critical for whatever environment it's in, it's who's touched it. And then even if we had all of that data, what security controls are actually there at the end user to prevent some of the low-hanging fruit opportunistic attacks, because then we would be able to start to discriminate. Well, yeah, you know, this is connected to the internet with a hard-coded password and this vulnerability, and it's used for this, you know, mission-critical thing that seems really important. But sometimes you actually do get into these organizations where they've considered this and they've thought it through and they actually have really good compensating controls, and you wouldn't know that by face value, understanding who they bought it from, what software version it's running, what the firmware vulnerabilities might be, and, you know, how many of them are in their plant. So it's a data problem too.
I mean, that's a really good point because, because there are so many variables to all this, right? You know, what if somebody said, well, what's safer, Windows 11 or Windows XP? I mean, the answer normally you'd say Windows 11, right? Well, but there's a lot of questions there. Where is it? If you've got a Windows XP system that is air-gapped and is doing nothing, but playing, you know, checkers, that's a really secure system. Uh, if you've got a Windows 11 system that's online and isn't, isn't, you know, has no, no antivirus and no endpoint protection and it's tied to critical systems, that's a really big problem.
If you remember NotPetya, when that happened, there was— people were really criticizing some of the health— healthcare victims.
Oh God, you're gonna talk about XP, aren't you?
Well, and so it's not just whether or not something is a more secure version, it's what other operational technology relies on that older version. So, you know, we all say in the OT that there's no such thing as an air gap. I fundamentally believe that because of remote access and vendor maintenance. But, uh, how do you then make the decision to rip and replace your technology when like maybe your radiation and X-ray, all of these things that we use every day that are touching, you know, the real world rely on, and then you go to the vendor and they say, oh, the Windows 11 version of this is going to come out in a year and a half, or the, it wouldn't be Windows 11 actually, it'd be like the Windows—
No, not anymore.
Yeah. It would be, it's, it'd be a couple Windows versions behind because that's how this— Yeah. There's these, and it's not really the, I mean, the OEMs are doing their best as well with their product lifecycles and building in a lot of new things, but the patch rates, if you ask the OEMs, are tiny.
Yeah.
For their install base.
Well, that was part of the issue. That was part of the issue with, with, you know, why healthcare has always been such a such a challenging industry, right? I've said finance is always gonna lead the way and that's cultural. As long as there's been banks, people have been robbing banks. So finance gets it right away that adversaries are gonna come after us. There's a cultural difference in the medical field. Nobody's been running into hospitals stealing patients historically, right? So medical field hasn't been as much about security, but even putting that aside, it's that technological piece. You know, when you go in and you realize all the little wheelie things that people carry, you know, move from room to room in the ER or whatever, that's all hardcoded XP can't even be updated.
Availability of that is so important.
Yeah. Yeah. It's, and it's a whole new system. You're like, oh, this isn't like we're just going to upgrade from Windows XP to Windows 11. This is, you know, $20 million worth of hardware and software and training and all the things that go with it because every piece of equipment has to change out because they were designed hardcoded one operating system can't be updated, which is, should be criminal for God's sakes.
And then there was this congressional testimony a couple of years ago. I referenced it in a paper and I had the link and there was a, I think it was a representative who got up and said, Why don't we just disconnect it all? Take it all. Why does it communicate?
Great idea.
Yeah. So go back essentially to, you know, manual operations on-prem, and that's a good exercise for like black start operations. And, you know, manual operations planning is definitely a requirement. Like you should have standard operating procedures for how you might do that. But at scale, the way that we have introduced commerce and efficiency and just-in-time manufacturing and, you know, the ability to to have clean drinking water all the time. I mean, all of those things, there's no way to go back to analog. And that's before you even get to, like, manufacturing in terms of our economy and the impacts that that would have, right, on our, like, economy.
Oh my God, everything would be so much slower. It's like asking, why don't you use a fax machine again?
Like, well, like production, ERP. I mean, these businesses are just never going back. And so we have to be able to secure. And I think that's what people kind of forget. And We need a reminder a lot of times in security. I mean, we still exist to secure the business, not to, you know, be on a high horse or sit in an ivory tower and say, here are all the controls that you're getting wrong. I mean, that's, I've never liked that approach. So that continuous improvement, operating under compromise, understanding that impact analysis and saying, you know what, I know that everything I'm doing today is for the benefit of reducing the severity of any impacts for any physical impact that could result from a cyber incident. It's really hard to do that. Like the failure modes, the logic. I mean, you mentioned traffic lights, the way people think you can hack traffic lights versus, versus the actual logic parameters in a traffic light are typically very different. There are some interlocks in there that are created to avoid some of the worst case scenarios we might dream of in a traffic instance, right?
Everything that's been in the movies, basically.
1000%. Yeah. And so, a lot of this stuff just doesn't map from sector to sector. And so we're continuously learning. That's what I've been doing for a number of years. And now that I'm in transportation and I'm learning about rolling stock and CBTC infrastructures, you know, relying more on wireless connectivity for train sets, it's incredible. But a lot of that ICS basics really applies. And then how we frame availability above all else after safety, more so than confidentiality. But that middle ground is gonna be integrity no matter what, which is what we started off talking about.
Yeah, that's a good point. So I guess looking ahead, like, are we going to effectively defend against, you know, threats to OT? Are we gonna get proactive on OT security or is it, is it just a lost cause? Are we gonna continue to just look backwards, see signals and, and, you know, whack 'em all our way through this?
Yeah.
Are we, are we getting better as an industry? Are we going to get better? Are we going to get ahead of this at some point?
I think if the fix eventually is gonna be better aggregate data, I don't know who's gonna own that fix ultimately, if it's gonna be the private sector, if it's gonna be an ISAC, if it's gonna be the government, but I think we're going to see better aggregate data to understand what does early warning look like in industrial control environments and how do we investigate things earlier. I think we're also going to see an emerging trend of more people that grew up in engineering becoming cyber practitioners. That's something we've been pushing for a long time. There are certain people that are in a camp that only engineers and people that understand control systems can do the cybersecurity for OT. I'm not in that camp. I think if you're willing to learn and you put in the time, that it doesn't matter what background I mean, there are network engineers that I just met one last week who's in the train world and just runs circles around me, right? In, in every sense of the, the networking world and is a, you know, incredible resource. So it doesn't matter your background. So I think that that emergent focus area, and that's the reason that I teach, right, is to make sure that people have access to learning about this before they get a 4-year degree and missed potentially the opportunity to become, you know, intrigued by the cyber-physical world. But I think we have a long, long way to go in risk mitigation metrics that are copy and paste. So it's going to be unique because it's purpose-built and bespoke. And so that's what I tell everyone. I mean, don't— you can't borrow from this list and this framework and that you have to build your own. You have to be your own trusted advisor and you have to, you know, say it's not necessarily which list can I should I achieve? It's what can I reasonably do to validate continuous improvement for my stakeholders, whoever that might be at your level in your organization. So that's what I always push back against. It's not about the list, it's about what you can actually get done. And I hesitate to say like, stop passing the buck, but there's a lot of like, oh, we blame the integrator, the integrator blames the OEM, the OEM blames the asset owner, the asset owner blames the, the patching window, the, you know, and then the, You know, they're not gonna have a patch for this system because it's end of life. I mean, right. We could go round and round and round for years and effectively you have no metrics for risk mitigation because you've just been on that merry-go-round.
Well, and no accountability, which is, you know, which is a great place to be. If you're in an organization where you have no accountability, it's gonna be a good life for you, right? And that's, I think a lot of people push for that, whether they do it consciously or not. Like you said, there's a lot of, well, it's over here, it's over there, and you keep moving, moving the ball around and nobody can figure out who's actually accountable. And then it goes back in the circle and then you're onto the next thing.
And until you have a—
it ends up being Until you have an incident, and then whoever's held accountable is almost certainly not the person accountable, it appears. It's going to be some low-lying unnamed intern is the problem, right? That's definitely how things work, by the way, for anybody who doesn't know. Definitely the unnamed intern's the problem. There wasn't a manager and a senior manager and a director and a senior director and a vice president that all had to approve things. It was definitely some, some no-name that caused the big problems.
Yeah, and change management in these complex environments is huge. Like program management, change management, documentation, like those— I used to say all the time, then people got sick of me saying it, like, security should be boring.
Yeah, if you're doing a good job, nobody should know you exist. If it's— if you're doing a good job, it's like being a referee. If you're really good at it, nobody notices you. Yeah, you know, and that's— but that's not how it works, unfortunately, for us. People notice security regularly. And that's not all because people are doing a bad job, by the way. The adversaries are also pretty good at their jobs. Yes, this is not, uh, not an easy career field and never will be because the other side's also talented and motivated. And less restricted, quite frankly. They can be more agile. They can break things accidentally. It doesn't really matter. They don't have to sit down in rooms and have policies and procedures and, and write a whole bunch of manuals and, and worry about them. They just go. Like, they're the most agile group ever is the bad guys, cuz they don't have to worry about most of the consequences.
Yeah.
So it's—
Except in OT. I mean, we assume that there are some red lines that we don't necessarily have on paper for some of those lifeline sectors.
Mm-hmm.
Which is a good thing. But yeah.
Yeah. I mean, I, I think you're right. Certainly in nation states, we know, like, obviously depends on attribution, which is always debatable. But, but then you see some, you know, we thought we had some red lines during COVID and then, you know, organizations that said they weren't gonna attack hospitals or weren't gonna attack, you know, medical facilities that were building vaccines, then decided to because they figured out it was profitable and they're like, ah, the hell with it, we're criminals. And so you, but you also saw some pushback from other criminals, which was interesting. You know, there were some groups saying, hey, you're making us look bad.
It was baby monitors in the UK.
Yeah.
Right. That was, yeah.
It was a huge thing. And there are lines there. And I don't know how much of that is because they have ethics or how much of it is because they just recognize, hey, this is too far, there's gonna be pushback.
Don't— yeah, we generally don't know. I actually was going to do a PhD and that's what I wanted to do it on, was like, there are operating handbooks out there for nation-states, we just don't get to see them. We have to kind of use intelligence to piece together motivations. And there's a whole argument actually that we don't want red lines on paper because as soon as you put it on paper, you have a tripwire.
That's true.
And I'm in that thing. Right, exactly. So the fact that we can't study them means I can't get my PhD, but also the fact that they're not written down, I'm okay with.
Yeah, I don't know that you can get your PhD in that though. I think you could certainly, in my opinion at least, pull enough data together to give a hypothesis on an unwritten rule, you know, and they would be different for different countries and different cultures. There's the Hofstede comes to mind as an analysis tool for this kind of thing. But yeah, there's different ones for different cultures to say, you know, where they draw their lines, what is too far. And it can change from generation to generation too.
I've never done this, and you can cut this. Do you know Jason Kitchen?
Jason Kitchen? I think it rings a bell. I think I worked with him.
I think so. He comes from Intel, and I have not talked to him in forever, but he was the person that I was saying, like, should I really try to go in on my PhD and do this from the Intel world? And he was like, you're never going to get your hands on the actual—
oh, that's true—
stuff you need. And I was like, you're right.
But yeah, I mean that, that's a really good point. Yeah. Unless you're inside the classified environments and there are master's degrees and PhDs programs that are inside, you know, government universities where you could do that kind of thing. Yeah, he's right. You're not gonna get that. It's gonna be, you'll have a lot of hypothesis, a lot of theory, and you might get some people that'll leak some information that's maybe was classified or maybe isn't anymore.
Yeah.
It'll be tough to get clean data, which is what you need for, you know, a real research project.
Obviously shout out to Jason.
Large clean data.
I never did. Shout out to Jason, but he's now the CISO at Tricentis.
Oh, I, I do not know him. It's a different kitchen than I know.
Okay.
I don't even know if they're related. We'll find out later, I, I'm sure. 'Cause Jason will now be the 14th person to watch this show.
Right.
But no, it's, it would be interesting actually. And, and it's the red line thing. You're right. I think there's some understood things, but rarely are they actually written down because things do move. Every country also doesn't wanna back them, back themselves into a corner where they've painted this, you know, this is the red line. Then you cross, you're like, uh-oh. Well, all right, now I got two choices. I either have to follow through. Or I'm weak. There's no way to get around that. And that happens occasionally, right? And then, you know, I mean, Iraq did that with Saddam and it didn't work very well. He drew all sorts of lines in the sand that we just walked right over. And then it was pretty clear that he didn't have anything.
Yeah, I think that's a different podcast too.
But it is, it is undoubtedly.
There is one more theme that I borrowed from military theory. And so somebody asked me the other day, like, is there any such thing as deterrence in cyber or is it just defense in depth? I'm squarely in the defense in depth. Camp. We moved a long time ago away from, there's gonna be some type of cyber incident that's gonna be the equivalent of a nuclear weapon on New York City. That's not going to happen. Actually, when I was at Stanford, there was some research for the reinsurance community that actually stated, you know, you wouldn't even wanna go after a sector specifically. You'd wanna go for a portfolio that could lead to cascading impacts that would kind of mimic the outcome of the 2008 financial crisis. And they were like, let's not publish that. But that's what we're more likely to see. But there's this always-never principle that we are now starting to try to educate operators around where they understand failure modes, they understand safety. There's tons of ISA regulations around safety. There's OSHA requirements, all of these things. But when it comes to cybersecurity, we have not done a good job articulating here are the ways that cyber instances can create those same failure modes that you're prepared for and understand to a Ridiculous scientific degree. And that's where we are today in OT. That's what we're really, really focusing on is how do we bridge that gap, drop some of the jargon, and be able to build good people, process, and technology activities around those types of learnings so that this always-never principle that I borrowed from OT is effective across cyber-physical environments. It's always ready to be used. With our control, and it's never going to be used or abused or turned off, essentially, you know, inaccessible, uh, bricked, DoSed, whatever, right, when we need it to, to be accessible. And so that always-never rule is what's kind of leveling the playing field right now. It used to be this like IT/OT convergence conversation, and there was like lunch and learns and brown bags, and like, that's kind of interesting, like if you care about, you know, the monitoring of the flow of oil in a pipeline to understand how much you can charge per barrel and how many barrels you can produce per day. Like, if you're interested, it is really interesting to understand like historian data and SCADA and all the software that brings all the math together. But that's not what everyone's interested in. And so this other, like, failure mode analysis of always/never is kind of the other way we're starting to see teams bridge the gap between cybersecurity speak and operator speak.
Yeah. To go back to, to the part of that question you had asked about, you know, is there such thing as deterrence? So, I, I don't know if you and I are, are entirely in the same camp on this. I think there's, there are very few forms of deterrence. I think there's virtually no deterrence when it comes to cybercriminals. I think we can all almost agree on that. Virtually no deterrence, especially for the most sophisticated and organized criminals. If you're a script kitty out there that's gonna start doing criminal behavior, there's probably some deterrence because you're not very good at this. There's a good chance you'll get caught and there's a lot of jail time waiting for you. But the reality is, uh, cybercrime has like a 0.1% prosecution and conviction rate. It's, it's incredibly low. Uh, it's a great industry to go into if you wanna make a lot of money. Uh, there's, there's a, it's a booming industry for those who don't have jobs. There's a, there's a lot of jobs in cybercrime right now.
But, uh, and impossible to police at scale. That's the other problem.
Exactly. So, you know, the, deterrence on the crime side is, is very limited. On the nation state side, there's, there are deterrence only in the sense that there are deterrence just like there are for everything else when nation states interact. It obviously attribution's a factor, but you don't necessarily have to—
Counterstrike capability is another factor.
Exactly.
Right.
And you don't have to have, you don't have to have positive attribution necessarily. Governments will seek that. But if, if a massive attack happened on the US and we had a reasonable believe, we had a more likely than not belief even, that we had a nation state, there would be a consequence to it. Now, it may not be kinetic, it may not be bombs on targets.
Uh-huh.
Uh, there are other levers to pull. There are economic levers to pull, you know, which is normally the first thing the U.S. will look for because we have an economic power advantage over most countries. But, and those things come into play, and the Chinese know that. There's some deterrence there. Their economy is certainly dependent on the rest of the world. They're dependent on U.S. consumerism. The Russians have seen this, you know, with oil can be shut off, and their ability to get oil to the market can be can be a problem, and that's most of their economy. So there are deterrents to keep nation states from going too far with each other. Occasionally nation states step over the line. It's happened. It's happened to us. It's happened by us. But there's, there's some deterrent built in, but not, not in the same sense, right? And again, there's almost none for cyber criminals. And occasionally company countries are going to step over the line. There also has to be some backchannel discussion about, well, we were only doing recon, we didn't mean for that to happen. But recon is considered, you know, spying is considered to be understood and accepted and, you know, semi-legal.
Like, everybody depends— factor though has not been analyzed enough. It's really interesting when you talk about the ship-to-shore crane technology at port facilities, which there are a couple great reports out. And there's two camps on like, there's a backdoor in the supply chain and it's the most critical vulnerability in the whole world. And there's this other camp of like, transactions run the economy, transactions go through ports, ports have containers, containers need to be moved. There's some middle ground and it's a really interesting one to look at if you're looking at deterrence.
Yeah, I mean, it's definitely important whenever you look at nation-state to look at, you know, does it— would it end up hurting them just as much as it would hurt the enemy they're going after, right? An example I will give very briefly, which maybe we'll get cut later, but it was a debate, I don't know, a week or two that popped up because the Saudi prince was in the US. So people talk about Saudi Arabia again, and of course 9/11 came up again, and there are people that say, you know, the Saudis did 9/11. And yeah, I can give a lot of stories behind that, but I will, I will, you know, boil it down to this. 9/11 wasn't good for Saudi Arabia. There's, there's not a lot of logic in suggesting, yes, 15 of the 9/11 attackers were Saudis, but the Saudi government didn't support them. And the reason is it's not in their best interest to do so. Having the U.S. under attack was not good news for Saudi Arabia. It's not good for their business interests. It's not good for their political interests. And Osama bin Laden, one of his devout goals was to bring down the Saudi Saudi family. He was a sworn enemy of the Saudi family. So it defies logic to think that somehow the Saudi government would do this because it would be not in their best interest. But, you know, people don't want to hear that.
There's a lot of other, you know, my degree is actually in Middle East geopolitics and Arabic.
Oh boy. Oh, I've stepped into it now. I stepped right into this one.
People kind of timestamp like, what does it mean to support something? And there's so much more historical reference to factions. Oh, sure. But somebody, yeah, did ask, there's the new kind of conversation around deterrence by denial, specifically in cybersecurity. And I just do not think that deterrence by denial for most organizations, asset owners that I talk to in OT, is an option, right? That defense in depth approach that is, again, more than VLANs, more than a DMZ, more than a product, more than a firewall. Is it needs to be rudimentary. Like it needs to be boring. That step-by-step, what do I know today that I can prevent in terms of impacts? What am I gonna focus on tomorrow to make sure at a fiduciary level that I am doing everything I can with the dollars I have to continue to prevent X, Y, and Z? What do I know I can't prevent and how do I move closer to that prevention? But we've fallen into this trap of this detection-first mindset, or, you know, this blurring of the lines of metrics that tools produce versus metrics for my continuous improvement. And I think once we uncouple those two things, we actually do have a pretty good future for leaders in these roles that can say, no, no, no, regardless of the tooling, regardless of the means and motivations of threat actors, here's what I know I can do today. Here's what I know I can't do today. And here's what I'm working on. And that's so basic, but we've gotten really far from that.
Yeah. Well, and you make that good point about trying to be boring. Listen, there are too many organizations that are enamored with the flashy and the fancy and, you know, the newest technology and the newest, you know, whatever it might be that vendors are pushing out. And it's, you know, it reminds me of somebody who has this incredible, you know, high-tech security system, cameras and, and, you know, all these things at their house, but they don't lock their front door. They leave their windows wide open. You're like, it, it's not gonna do you any good. Like, it's, yeah, I can't continue to tell people, you know, multi-factor authentication. It's boring. Nobody wants to hear it, but it's still a huge thing that nobody seems to be, or very few people do. And, you know, it goes a step further. Hey, not use a text message, text message or email, how about that? Uh, but I'd be happy if people just did some of those right now. You know, the basics don't get done because people get sucked into the more exciting things that are being sold to them.
Well, somebody asked me the other day about like device security. It was a laptop that they wanted to connect to a train, and I was like, well, why not create a separate laptop for that and then lock the laptop away and only have it used for that? They're like, oh. I was like, yeah, it's written down somewhere, but like, that's the It's a best practice that would be suggested. But like what we think about in terms of like transient devices now is also so different, right? Of course, the military learned that with like fitness trackers, but the intelligent versus like IoT level, like that's just not intelligent actually. So, and you know, the post-quantum issues with some of the hard-coded passwords are going to be a problem. And so, yeah, there are little things that are just going to become bigger. Issues down the road if we're not focusing on them. Again, there are compensating controls that could fix those issues if you're paying attention to them, but there are no silver bullets, and that's what becomes problematic. When I was an analyst years ago, the words point solution were like dirty words. Like, nobody wanted point solutions, right?
Mm-hmm.
That's all you're gonna get if you want the best in class of those solutions. You have to be able to mix, manage, and marry, you know, multiple solutions to get the most effective holistic security platform or stack you're gonna be able to deploy. And I'm, I'm gonna pull up a, a quote from a report that I was reading today.
Hmm.
And it, the question was, it's an ICS-specific report. It comes out from CSAE is one of the organizations, and then KPMG. They do this annual report about security practices for industrial control systems environments. And the question was, what practice or approach do you wish cybersecurity technology providers would stop doing? And the answer from somebody in the field was they should refrain from making exaggerated or unsubstantiated security claims about their product. Honesty and transparency about a product's capabilities and limitations are essential to building trust with customers. Providers should also not operate in isolation. Collaborating with security researchers, industry peers, and customers can help identify and address vulnerabilities and threats effectively. If that wasn't written for me, I don't know what was. So thank you to whomever this anonymous respondent was. But like, that is my entire spiel wherever I go. Build trust, be your own trusted advisor, beg, borrow, and steal from best practices. And then push for the security stack that you have vetted to the fullest ability of your brain to understand your environment and say, this is how we can do reducing severity of impacts to our environment, regardless of what TTPs are out there, regardless of the shiny new objects, regardless of the AI tools and math that's out there.
So, yeah, I mean, I think, I think that's a good point. I would love to see vendors do more of that. They don't because being honest and transparent doesn't sell nearly as well. As being full of hyperbole that does, and they figured that out and people keep buying the hyperbole. I've worked enough organizations to see some of this and maybe not outright lying, but there's certainly people will push to the extremes about what their things, you know, their tools and technologies may or may not be able to do. 'Cause people, the other side, buyers want to buy the dream, but they don't want to buy the reality. If you tell them, hey, this is bumpy and it's going to be difficult, it's not perfect and you're not going to be 100% secure, but everything you have, we have, we can, you can trust and we'll tell you what your gaps are, et cetera., and somebody else comes in and says, there'll be no gaps, 100% secure, day one.
Yes.
Yeah.
100%. Uh, what's the phrase? Single pane of glass out of the box.
That's right. Yeah. It's plug and play, 100% secure. Like all, everything integrates with everything else. We didn't even talk about AI this entire time we were talking. We didn't even get into AI.
We're not going to. I'm kind of a hater, so I'm glad.
Yeah, we're not going to, 'cause we're outta time for that. We maybe another day, 'cause there's a whole lot that goes into that too.
But, um, yeah, some of the robotics and AI applications for transportation is actually really incredible. Like battery electric vehicles is really cool. Yeah, that could be a whole nother episode, I'm sure.
Yeah, we may do that, but we're out of time at this point. So I want to get to the final question, right? So as you know, the name of the show is Unspoken Security. And with that in mind, you're on the seat now. So you get to tell me something you never told anyone before, something that so far has been unspoken.
And sorry if there's some background. I know you said you had dogs and cats on the show before, but my partner just brought my baby home early.
Babies are good too.
That wasn't a phantom baby sound I heard. It was real. So I gave you a teaser here and it was, what does Belarus, Samantha Power, Condoleezza Rice, and Tesla all have in common? And I've listened to the show and I've heard people say both humble things and very humbling things in their unspoken delivery. And so what all of these four things have in common, just, you know, other than really interesting human rights backgrounds, is I have like blundered with all of these. And so when I worked at Brookings, I didn't know how to pronounce Belarus. I think I said Belarus, and somebody like laughed in my face.
Sure, sure. Which is mean, but I get it.
Yeah, of course. And when I was there, I was in Congress with some, some of my coworkers and I met Samantha Power and I totally froze. And I actually studied abroad in Rwanda and read her book and was like enamored by her. And instead of saying anything remotely impressive, I said, you have nice hair, which she probably appreciated.
For what it's worth, I'm sure.
But I'll take that to my grave. And then I met—
it's worse if you're a man. By the way, that'd be much worse if you were a man. If you'd done that, at least, at least you're a little better off.
Yeah, it's much worse. Um, I met Condoleezza Rice when I was at my grad school. She came and did like a ribbon-cutting ceremony for a building. And again, instead of anything intelligent or remotely like geopolitical, or no, I said we're in the same sorority, and she was like, cool. You know what I mean?
That's a great reaction.
Cool.
And the other one for Tesla is when I first moved to— I'm not a tech person at all. Like, we don't have an Alexa. We don't— I hate apps. I always use the browser for everything. I moved to California in 2018, and this one I've really never told anyone other than my partner who knows everything. I saw the Tesla for the first time and I sent a picture to him. It's 2018, this has been around for a while, and I was like, is this a new Thunderbird? And he was like, what? Like, I did not know Tesla exists.
So Thunderbird—
oh, I love this. Unspoken are these like blunders because people tend to respect like powerful personalities in this field. And first of all, there's no reason for that. Like every personality has a role in, in this, you know, world that we live in. But you're not smart because you know things. You're not dumb because you don't know things. Don't be afraid to ask questions and don't be afraid to like fall on your face a little bit is kind of my unspoken. Those are my 4 examples. And you look back and just realize that you are gonna have all the respect from learning and that somebody was always in your shoes. And there's really, you know, there's so many different ways to advance. And so this is like stuff I look back on, but at the moment in the time I was like so embarrassed. But yeah, now they're funny stories.
It's, it's a, no, it's a great message too. Like you said, it's nobody's, nobody's perfect. I don't care where anybody is. I don't care how there's somebody looks up to somebody else always. Right. And, and I, the chances are that person looks up to somebody else as well and probably doesn't realize somebody looks up to them and there's, there's no one path. Nobody— if somebody seems larger than life and they seem to think they're larger than life, then they're probably just jerks, right? Everybody's trying to struggle, everybody's trying to get through it. Everybody's made mistakes. Everybody's made what would be considered silly mistakes and stupid mistakes. If you look back, you're like, oh my God, I can't believe I did that. That's just part of learning, right? That's part of the process.
Correcting somebody never makes you right is what I've learned. So that's really the best.
It's not—
yeah, it's not usually well received. Sometimes it's required. It just depends on what it is, how serious it is, obviously. But there's still a nice gentle way to do it. You know, there's definitely, you know, nicer and less nice words. I will say, I, uh, somebody dear to me once told me, you know, if somebody mispronounces a word, it just means they're probably a reader and you shouldn't hold it against them. You know, they may have— there's a lot of words that you don't say out loud, they don't look like they sound right. They've read a lot of books, they know the word, and then they say it out loud and you're like, that's totally wrong. You're like, well, I'd never had to say it out loud before. They're probably just a reader. There's nothing wrong with that.
Just the other day, heterogeneous and homogeneous, you can say homogenous or homogeneous, but you can't say heterogeneous.
Heterogeneous is not a word to my knowledge, at least. So, yes, yes. Heterogeneous is not, as far as I know, at least. So, no, it's a good point.
English is the hardest.
Well, English is the only 5, Cat 5 language in the world. Uh, coming from a linguist, I can tell you English is the only Cat 5 language in the world. So yeah, that's definitely what people needed to close the show on. We'll probably cut that out. Anyway, so listen, this has been great. I really appreciate you taking the time. You're very, obviously you're very knowledgeable, but you're also very interesting. Listen, OT isn't always something that people find very interesting, but you're passionate about it. I love it. It's fascinating. I think it is interesting. I think it's part of all of our lives in ways that people don't even realize. And we've got to do a better job as we do in all of security, obviously. We got to make sure that we are, as an industry, pushing it. We got to work with government on this. We got to push regulations. Again, it comes back to companies aren't going to do what they don't have to do. So, you know, there's going to come back to that discussion of regulation and where that fits in and who's going to be able to have the power to lean on companies to do what needs to be done before tragedies happen. But I'm thankful we have people like you who are way smarter than me, who know about these things and are deeply invested in this and are trying to help people be better about this before bad, bad things happen, before AI takes over everything and ruins us all. So last thoughts before we leave. Anything you want to end on? Anything you want to plug? Anything you want to talk on? And then we're out of here.
We like to focus at my organization right now on, you know, people like to say low maturity organizations. I call those early adopters. So there is no such thing as low maturity. And when it comes to ICS, I have a whole primer on relay logic. And the point that matters for me in OT is when it clicks, it sticks, right? When something makes sense to you, you're going to remember it. And so everyone's kind of starting from a different playing field, and that's what we're working on is leveling that playing field. So whatever that looks like in OT, you know, I share my syllabus for my class. It's all open source material. Anyone that wants it.
Oh, sweet.
I'm totally open to it. I use the same lab that INL uses, and so I just really encourage people, you know, there's really no pitch or sell here. If you're interested in this, learn about it because we need you. Like, this— we're so far behind IT. The thing that I will say, and I hope you don't cut this because this is my key takeaway, is I got so annoyed with the word awareness in OT over the last couple years because it's easy to spread awareness about OT. We understand what happens when the lights go out and water is, you know, now soiled and we're shutting down malls, you know, all these things, airports.
Yeah, airports.
Yeah. Impacts are easy to articulate to people. The gap between where we are in IT security and where we need to go in OT security is incredibly difficult to articulate today. And it's so wide and it's not getting that much smaller in the incremental ways we needed it to be. So we need to cover more ground. We need more people to care about it. And so that's the awareness that we really need to start to have the tipping point to say, no, this is what we need to do. We need more aggregate data. We need better early warning. We need, you know, more telemetry that is statistically significant to indicate that these controls might work or these metrics might matter. Hi baby.
Hi baby.
Okay.
Join us.
Hi, hun.
Daddy's just smirking over there.
This will be the first baby ever on Unspoken Security. Oh my goodness. For those who stuck around for the whole show, it was worth it, wasn't it? That is such a cute baby.
This is Quinn.
Hi. Welcome to the show.
Almost a year old.
Welcome. Yeah, I know your birthday's coming up. Welcome to the show. Look, you're already famous. Thanks for coming on and joining us. I appreciate it. You're already my favorite guest. Thanks for coming to the show today.
Absolutely my favorite baby.
Yes. Well, that's good. That'd be weird otherwise. All right, listen, I'll let you go so you can go be with the baby and thank you again for the time. I appreciate it. We'll definitely be talking more. If there's anything I can do to help you, let me know. For those listening and watching, thank you for doing so. Please, you know, subscribe and tell other people about the show. And if you don't like the show, shut up. I don't want to hear about it. But now let me know and I'll see if I can make it better somehow. But please do spread the word. You know, we want to have more guests like, you know, like DJ on the show so we can, you know, keep spreading good information to people who need it. Thank you very much. And thank you, Danielle, for being on and go enjoy baby time. I appreciate it.
It's really fun. Can you say bye-bye?
Bye-bye. Say bye. Good enough. Well done.
She does it in person.
That's okay. I don't blame her. She's like, who's the weird guy? All right. Well, with that in mind, we're going to shut it down today. For everybody listening, again, thank you very much. This has been another episode of Unspoken Security.
That's a wrap for this episode of Unspoken Security. If you enjoyed this episode, follow us wherever you listen to your favorite podcasts. See you next time.
More from AJ

Unspoken Security Ep 61: Should We Be Afraid of Artificial Intelligence (AI)?

Unspoken Security Ep 58: Stolen Credentials, Fake Hires, and the New Insider Threat








