
The Industrial Security Podcast · 2025-06-17 · 53 min
Key moments - from our scoring
Substance score
66 / 100
Five dimensions, 20 points each
This episode reframes how industrial security professionals should think about risk assessment in OT environments. Rather than relying on the traditional risk equation of consequence × likelihood (probability), Kenneth Tittelstad argues that credibility - whether an attack is reasonable to believe could occur - provides a more practical framework, especially at the high end where nation-state targeting and sophisticated attacks are not random events. The discussion draws on real incidents like Stuxnet, Triton, and attacks on Ukraine to establish which threats should be considered credible. Kenneth brings 15 years of OT cybersecurity experience from roles at Equinor and Supersteria, and chairs the Norwegian IEC Subgroup working on IEC 62443, the widely-used industrial cybersecurity standard. Andrew Ginter, VP of Industrial Security at Waterfall Security Solutions, contributes perspective from leading early industrial SIEM work. The conversation covers consequenc-driven cyber informed engineering, unidirectional data diodes, islanding capabilities, and why false negatives (missing real attacks) matter more than false positives (unnecessary alarms). Operators in critical infrastructure, energy, and manufacturing will find practical guidance on moving beyond probabilistic risk models to credibility-based decision-making.
Credibility is a qualitative judgment about whether an attack is reasonable to believe could happen - based on past incidents, near-misses, and demonstrated capabilities - rather than trying to quantify the probability of an attack occurring.
At the high end, cyber attacks are not random events: nation-state actors target repeatedly until achieving their mission, and ransomware that worked once will work the same way again, so randomness-based probability models don't apply.
Triton (safety system attacks), attacks on Ukraine, the Colonial Pipeline ransomware incident, and Stuxnet are all credible attacks because they actually occurred; near-misses like the Triton attempt that didn't cause destruction also count as credible.
IEC 62443-3-2 now allows consequence-only risk analysis, enabling organizations to focus first on what harm is possible and then revisit credibility qualitatively, rather than forcing probability estimates.
Islanding automatically severs IT-OT communications during suspected attacks, cutting off remote attacker control while minimizing operational impact because organizations already have the capability to run OT systems independently.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers substantive ideas about risk analysis frameworks - particularly the credibility-over-likelihood distinction for high-consequence scenarios and consequence-driven risk assessment. However, significant portions consist of personal narrative (Bovo platform story, Stuxnet backstory) and repeated conceptual explanation that dilutes insight density. The core contribution (credibility as a qualitative framework to replace probability discussions) is sound but not densely packed.
Credibility gives us tools in our language to actually be able to talk about the left part of the equation. So it's something that is a bit more analog and analog value where we can moved more towards the consequence approach
likelihood is flawed, that the high end of cyber attacks, not the low end...Nation state targeting is not random either. You know, it's not that they try for a while and they if they don't succeed, they you know, go try somewhere else. Nation state threat actors keep targeting the same target until they achieve their mission objective
The credibility framework is a genuine alternative to standard risk equations and represents original thinking - particularly Ginter's argument that likelihood breaks down at the high end of consequence. However, the episode relies heavily on established references (IEC 62443-3-2, consequence-driven cyber informed engineering, CDIEE) and does not substantially challenge or extend those frameworks. The AI attack scenario (Kali Linux + AI model) is provocative but presented as speculation rather than evidence-based analysis.
credibility is what's reasonable to believe...Is it reasonable to believe that the consequence will be realized?
Things that have happened, actually have happened once or twice or three times, they are credible
Kenneth Tittelstad is a strong guest with 15 years in OT security, direct experience at Equinor and Supersteria, and current CCO role at Omni. His involvement with IEC 62443 standards committees adds credibility. However, he is positioned as a vendor (Omni) at the time of recording, which introduces a commercial angle. Andrew Ginter is a recognized practitioner-author on industrial security, though the episode relies heavily on his framing and commentary rather than genuine back-and-forth debate.
I've been working in the field now for almost fifteen years...I've just started as a commercial officer in Omni. I went over from Supersteria where I was heading up OT cybersecurity
I'm working as a chief commercial officer in OMNI and I've also been chairman for the Norwegian Electrotechnical comedy the group that hand is Handling I C. Sixty two four four three
The episode references specific incidents (Stuxnet, Triton, SolarWinds, Ukraine attacks, Colonial Pipeline) and standards (IEC 62443-3-2) by name, which is good. However, it lacks concrete metrics, timelines, or quantified consequences. The AI attack scenario is almost entirely theoretical with no real examples. The firewall troubleshooting anecdote is narrative but lacks specifics (no platform name, no metrics on the noise level, no timeline). Claims about credibility are illustrated with scenarios rather than data.
in nineteen seventy seven, the big horbo blowout happened
Stuxnet...I think we got to hear about it. In twenty ten
Ginter asks thoughtful follow-up questions and introduces productive tension (e.g., challenging Kenneth on false positive risk of automated shutdown, or questioning whether consequence-only risk assessment appears in IEC 62443-3-2). However, the conversation rarely becomes genuinely adversarial; Kenneth's responses are largely affirmed rather than pressed. Ginter does substantial monologuing (the AI threat scenario, the bridge engineer anecdote) that shifts the episode toward lecture format. The questioning lacks the sharpness needed to stress-test Kenneth's framework.
Can we detect cyber attacks reliably enough to prevent this kind of unnecessary shutdown? You know? And you know if we do shut down whenever there's a bunch of alarms, is that not a new sort of denial of service vulnerability?
I've not seen those words in three dash two. Are you sure that you're not reading in the three dash too to be there
Computed from the transcript - who did the talking, and the words that came up most.
Safety defines cybersecurity - Kenneth Titlestad of Omny joins us to explore safety, risk, likelihood, credibility, and deterministic / unhackable cyber defenses - a lot of it in the context of Norwegian offshore platforms.
Transcribed and scored by The B2B Podcast Index.
Large scale destructive attacks on big machinery. It's not something that I would consider a credible attack. Welcome, Everyone's the Industrial Security Podcast. My name is Nate Nelson.
I'm here with Andrew Ginter, the vice president of Industrial Security at Waterfall Security Solutions, who's going to introduce the subject and guest of our show today. Andrew, how are you. I'm very well, Thank you, Nate. Our guest today is Kenneth Tittelstad.
He is the chief commercial Officer at Omni and he's also the chair of the Norwegian International Electrotechnical Committee Subgroup working on sixty two four four to three. So this is the Norwegian delegation to the IEC that produces the widely used IEC six two four four three standard. We're going to be talking about credible threats, what should we be planning for security wise? And by the way I happened, I had an opportunity to be in Norway and I visited Kenneth at the OMNI head office where they have a lovely recording studio.
So we recorded this face to face in their studio in their head office. Then let's get right into your conversation with Kenneth. Hello, Kenneth, and welcome to the podcast. Before we get started, can you tell our listeners give us a bit of information about your background, about what you know, what you went up to, and the good work you're doing here at Omni Security.
Thank you so much, Andrew, and welcome to Norway and our office. I'm so glad to have you visiting us. So my name is Kenneth Tiklestad and I'm working as a chief commercial officer in OMNI and I've just started as a commercial officer in Omni. I went over from Supersteria where I was heading up OT cybersecurity.
I've been doing that for six years. Before that, I was working in ecuinor also working on OT cybersecurity. So I've been working in the field now for almost fifteen years. And also for the last five or six years I've been chairman for the Norwegian Electrotechnical comedy the group that hand is Handling I C.
Sixty two four four three. So I've been diving deep into OT cybersecurity now for quite many years. Yeah, and at Omni we are developing a software platform for handling cybersecurity and security for critical infrastructure. It contains us a security knowledge graph and AI that provides actionable insights into security for critical infrastructure.
So it's about it OT and physical structure. Our topic today is creditibility. Now this is talking about risk. You know a lot of people think risk is boring.
Okay, A lot of people when they enter the industrial security space, they want to know about attacks, they want to know about the technical bits invites. You tell me that you got interested in risk a very long time ago. Can you talk about that? Where where did that come from?
Absolutely, I'm not sure if I when I considered it as a risk or as as a. Field of expertise. So when I was just a small boy, Actually, my dad he worked as a control room technician offshore at in Conico Phillips or back then it was called Phillips. So when I was only two years three years old, in nineteen seventy seven, he was working at the Bovo offshore oil and gas platform and I I don't remember this of course back then, but it was always a topic around the dinner table at my home where he talked about how it was working in the oil and gas business.
So in nineteen seventy seven, he was on his way out to the platform when the big horbo blowout happened. He was not actually he hadn't arrived at the platform, but he was on his way out there. So it really was a big topic around the dinner table all the time about safety risks involved in oil and gas. So I was always listening with my small ears back then, being a bit fascinated about this world.
I didn't see the real danger in it, but I was trying to picture it in my mind what it was to actually work in these kind of environments. So I was was kind of primed back when I was just a small small boy, and later on when I moved into the I was more into computers, so I did a lot of gaming and programming on Commodore sixty four and I started to work in equinor on the IT side. But I was still fascinated, fascinated about the core business being oil and gas and production and exploration.
So when I actually got my first trip offshore, I kind of felt that the circle was closed and I saw the big world, the industrial world that my dad had been talking about for several years, and the kind of the risk perspectives also kicked in the first thing you meet when your step on board such a platform. Is the HC focus a lot of focus on HC, and it's for a reason. And I fully got to understand that first when I actually came on board such a facility, I understood why it's so important because it's it can be really dangerous if you don't have control over what you're doing.
So that's when I actually saw the big scale of risk as a perspective. Yeah, offshore platforms are intense. I've never set foot on one myself, but I've I've heard the stories. It's yeah, yeah, absolutely, environment and this is I mean we're talking about industrial cyber security.
So you know offshore platforms are intense in terms of physical risk. Can you talk about cyber risk? Yeah? Absolutely, it's an emerging topic.
So when I was working in Statle when it was called Statyle now it's Equinor, we started to look into that area around twenty ten, twenty and eleven. I still remember the day when people came charging into the meeting room and they started talking about the news of stucks net. So that was I think we got to hear about it. In twenty ten, I was working on the IT side and I was responsible for large part parts of our windows infrastructure in the company, and we started to I started to look into what this KATA things, what is it.
I didn't know about PLCs. I had never seen a PLC. I didn't know that there was actually other kind of digital equipment operating critical infrastructure. So with stucknt, I started to dive into the landscape of OT cybersecurity and also as a company, we started a big journey back then on really making OT much more cybersecurity, and stuck Net was kind of a kickstart for it.
Andrew, it feels like maybe there are certain kinds of SEM and all the cybersecurity incidents in the OT world we talk, we reference often the two thousand and seven Aurora test, maybe you know Triton and Destroyer, But Stuck's net is that foundational thing that you know, set the timeline for everybody. Right indeed, and you know I was active in the space. I mean I was leading the team at Industrial Defender building the world's first industrial SEM at the time, so stucksnet was big news.
I did a lot of work on stucks Net. I had a blog at the time, you know, every time I learned something new about it, because somebody had published a report, somebody had published another blog. I'd done a little research on my own, I'd published this. I published a paper on how stucks net spread because you know, analysis had been done of the artifact, you know, the malware, but it had been done by it people at semana tick at, I think E set a bunch of people had analyzed the malware, and you know, that's work I couldn't do.
I'm not a I'm not a reverse analyst. But I sat down with Joel langel I, sat down with Eric Buyers, and we investigated the impact that stucks net would have in a network. What would what would happen if you let this thing loose in a network? Given our understanding of the Semen systems.
Joel was an expert on the Seaman systems, you know, Eric and I were sort of more expert more generally on on you know, firewalls and industrial systems. So we all contributed to this paper and you know, said, here's what happens if you let loose stucks net into an industrial network. And you know, in hindsight, I have to wonder if we didn't do you know, more damage than than good. You know, because a lot of people learned stuff about sucks net, but there was only one outfit that benefited, and that was Iran's nuclear weapons program was the only you know, site in the world that was physically impacted.
So I, you know, I regret some of the stuff that I published about about stocksnet. Do you recall if that research got traction, whether it might have gotten over there or is there no way to tell? I have no way to tell. I do recall a conversation, you know, sometime later, you know, because I'm a Canadian, I work with the Canadian authorities.
I remember a conversation with Canadian Intelligence services and I remember, you know, asking them, you know, I've I've stopped, you know, at one point, when I figured out that there's only one place in the world that's physically benefiting from my research, I stopped publishing anything about stucksnet. And I remember sometime after that talking to Canadian intelligence saying, you know, I've stopped publishing anything about stocks neet. You don't have to tell me nothing in the future.
If you ever see me putting out in that's helping our enemies, tap me on the shoulder, would you and tell me shut up? Ginter, you're doing more harm than good and I will shut up. So yeah, I you know, I look back on stucks net with mixed emotions. It was a wake up call for the industry.
You know a lot of people learned about cybersecurity because the stucks net. But who benefited because of all that research? Okay, so that's you know, stucks net is how a lot of people got started in the AT space. It was the big news.
Yeah, fifteen fifteen years ago. Can I ask you, you know, let's let's talk about industrial security and the work you're doing. You the work you've been doing. Stucks net is where it got started.
Where have you wound up? What are you up to today? Yeah, it's it's as you say, it's fifteen years and it's been for me. I think it's been a very interesting journey.
So but back in twenty ten, when when stucks net hit the news, I wasn't immediately immediately diving into OT cybersecurity full time. I was working on the IT side, trying to secure windows environment in a large oil and gas company. But shortly after a while I moved more and more over to OT cybersecurity, and I had my first trip offshore oil and gas platform. I think that first trip was in twenty thirteen, so actually three years after this dug Net.
But then I was going out just to do some troubleshooting on a firewall. So but more and more I was moving into OT cybersecurity, and at the end I was I moved over to Supersteria I think it was in twenty seventeen, and at the end I was really working hard on finding really proper solutions for OT cybersecurity. When when potential nation states are targeting, what do you then do if you must sort of have their mindset of assume breach and these kind of systems with the PLCs and or they are really really vulnerable, what do you do when you are being targeted?
So then I started to look into I heard rumors that could there could be something that was non hackable, so I started investigating into UNI directional data diotes was exposed to Waterfall. That was one of the first examples of where I heard about non hackable stuff. And also I got to hear about the Crown Jewel analysis cyber informed engineering. Back then it was consequence driven cyber informed engineering.
But those kind of topics really really sparked an extra interest for me because then I saw on some attack vectors, on some of the risks. I saw actually a solution that could remove risk instead of just mitigating it. So your first sort of for a you know, everyone was interested in stock step, but you started working on the problem. You said, with a firewall, And you know, to a degree that makes sense.
I mean the firewall, the ITOT firewalls often the boundary between the engineering discipline on the platform in the industrial process and the IT discipline, where information is the asset that needs to be protected, and so that boundary is something that both the engineers and the IT folk care about. So that kind of makes sense. I'm curious. You know, you got out to the platform, you were tasked with the firewall.
What did you find there? Yeah, it was actually kind of a long long lasting ticket we had in our system that was a firewall between IT and OT that was noisy. So it was creating a lot of events and alert on traffic that it shouldn't have. So I was tasked to go out there and try to trouble shoot this.
We we absolutely didn't think that it was a cyber attack or or kind of evil intent, but it was incorrectly configured firewall rule. But when I got out there, I could see that it was it was just incorrectly configured fire world was nothing, not anything dangerous or a cyber attack involved. But I also got to think of a scenario where if it had actually been a cyber attack and one that created so much noise as well on a security boundary, a security component sitting on the outskirts of OT, shouldn't the OT environment do something to sort of shut down or go into a more failed safe situation.
So I got kind of interesting in actually the instrumentation behind your security components on the outskirts of OT. So that's a topic I continued to explore for several years, having in the back of my mind cyber informed engineering, non hackabal approaches, unidirectional mechanisms, And on S four last year, I talked about the safety instrumented system because safety has always been a particular interest of mine, so I talked about the cyber informed safety instrumental system.
Shouldn't the safety instrumented system at some point when you're under an attack, shouldn't the sort of the big brain in the room, shouldn't that actually take an action, an instrumented automated action, and going into a more not necessarily failed safe only, but a more fail fail over to a more safe and secure situation. So that makes sense in theory. I mean, if the firewall was saying help, help, I'm under attack over and over again, should some action not have taken place on the OT side.
But let me ask you this, it was a false positive. Yes, it would have shut down the platform, you know, a very expensive platform unnecessarily. Can we detect cyber attacks reliably enough to prevent this kind of unnecessary shutdown? You know?
And you know if we do shut down whenever there's a bunch of alarms, is that not a new sort of denial of service vulnerability? The bad guys don't even need to get into OT. They just need to launch a few package that firewall, generate some alarms, and the whole thing shuts down without them even bothering to break into OT. Is that really the right way forward?
No? I totally agree, it's not a good coach going forward. But at the same time, I think to shut down one too many times is better than not actually doing it. So we should be kind of overreacting and going into failed safe situation and it could cause unnecessary downtime and it could it's the vulnerability on the production side, but I think it's much more dangerous with the false negatives where we actually don't see any attacks, but it's it's actually happening, so false positive.
We need to reduce them. But it's much more important to actually reduce the false negatives. So Nate just listening to the recording here. I mean, this is not something I discussed with Kenneth, but we were talking about, you know, automatic action when we discovered that an attack might be in progress, for example, because there's a lot of alarms coming out of the firewall.
You know, he agreed with me that shutting down the platform is probably an overreaction because you know, that introduces a new attack vector. The bad guys just need to send a few packets against the firewall, generate a few alarms, and the whole platform shuts down. I agreed with him that something should be done, but we didn't really figure out what. You know, here's an idea.
In hindsight, A number of jurisdictions are introducing what they call islanding rules, meaning if it is compromised, you need to you know, basically, I don't know, power off the it OT firewall, nothing gets through into OT anymore for the duration of the emergency, so you have the ability to shut off all communications into OT. This is part of you know, the regulation says you must be able to island, So now you have that capability. You know, I wonder if it isn't reasonable to trigger islanding when when you discover, you know, automatically discover a whole bunch of alarms coming out of anything.
Because the modern attack pattern most of them of modern day attacks are not like stocks net where you let it loosen, it does its things. Most of modern day attacks have remote control from the Internet. And if you island, if you break the connection between it and OT, if there was an attack in the OT network, the bad guys can no longer control it, they can no longer send commands. So and this is not this is not new.
The term islanding is a little bit new. The concept of sort of an automatic shutoff has been bandied about for many years. But again, given that the regulators are demanding an islanding capability, you know, maybe engaging it automatically from time to time is not the worst thing that can happen. It increases our security and the impact on operations is minimal because you've you've deployed the ability to island already, you've developed the capability of running EUROT system independently and so uh, you know, interrupting that communication for a period of hours at a time while you track things down and say, oh, that was a false alarm.
I'm guessing is you know, minimal cost. So there's an idea. Let's come back to our topic here. The topic is credibility.
You know, we're talking about the risk equation. The typical risk equation is consequence times likelihood. Uh, you know, generally we do it qualitatively, but we we wind up with a number coming out of that to compare different different kinds of risks, you know, high frequency versus versus high impact risks. You know, can you talk about that?
Where does credibility fit in that equation? I think it fits very well into that equation because when we when we talk about it likelihood or the probability part of it, the left side of the equation. It's always a very very difficult conversation to have when you try to identify the risk or the risk levels we are talking about, or you try to identify the consequence levels involved. It's sad to see that a lot of the conversations they go astray due to not being able to put the number on the probability or the likelihood.
And I think the conversation gets to be much more fruitful if we can get rid of that challenge on trying to figure out the number on the probability or the likelihood. Credibility gives us tools in our language to actually be able to talk about the left part of the equation. So it's something that is a bit more analog and analog value where we can moved more towards the consequence approach, the consequence driven where the right side of the equation is more important to talk about.
As long as you get if you consider it being credible, then okay, let's stop the discussion there and focus on identify the consequence levels. Well, you know I have to agree. You know, I've argued in my previous in my last book, that likelihood is flawed, that the high end of cyber attacks, not the low end. The low end.
Likelihood actually works the high end. The outcomes of cyber attacks are not random. If the same ransomware hits a factory twice, and we've always done is restore from backrupt. It took them down the first time.
We restore from backup, we make no changes. It hits again, They're going to go down the same way. It's not random. I argue that on the high end, Nation state targeting is not random either.
You know, it's not that they try for a while and they if they don't succeed, they you know, go try somewhere else. Nation state threat actors keep targeting the same target until they achieve their mission objective. It's not random. Once they've targeted you, it's not random.
So you know, randomness, to me, doesn't work at the high end. Credibility makes more sense. You know, is the threat credible? Is the consequence credible?
If this threat comes after us, it's this attack comes after us. Is it reasonable to believe? You know, credibility is what's reasonable to believe, not who what's reasonable to believe? Is it reasonable to believe that the consequence will be realized?
You know, I think it makes a lot of sense, but it's it's new. I don't see the word credibility in a lot of standards. You know, where does this it? What?
What you know? Is this is this something people are talking about. Yeah. Absolutely.
In my work with with the clients I've been working with and also the professionals I've been working with, we have discussed for some years now that the or we have discussed the big challenge of the likelihood or the probability part of the equation, and we've we've without actually having having without following standards or best practices, we've seen that we need to skip the discussion on the probability or the likelihood and talk about the consequence side of it first, and then we revisit the likelihood and probability afterwards.
But I also see in ie C sixty two four three, especially with three dash two, it actually talks about consequence only risk analysis, So that's giving opportunity to actually move away from the discussions on probability. And also, of course with the consequence driven approach with cyber informed engineering, we start to see more focus on the far right side with the consequence consequence side, but leaving out. What to do with the likelihood. And I think with credibility we get some language based tools to actually place it where we talk about it in a qualitative manner instead of having to force it into a number.
I have the sense that over time, in the course of time, cyber attacks become more sophisticated, More sophisticated attacks become credible. Attacks that were dismissed a decade ago as theoretical have actually happened. Do you see that, you know, what do you see coming at us in terms of sophisticated attacks in the near future? Here, I think that's a really challenging question looking far into the future or or far into the into the history to try to extrapolate what could we expect from the future.
We see with with. The stocksnet, the attacks against Ukraine, Triton, the colonial pipeline, we see incidents that have had a really high impact, but there's not very many of them. So but but we see it's those kind of capabilities are being explored and are being put into different tools so they can be used by not only nation states but also criminal groups. So with with that kind of analysis, we can expect more and more sophisticated attacks and also buy more and more non sophisticated groups.
So we should expect increase in high impact incidents. So if we're not talking likelihood, we're not talking probability, we're talking credible. How do we decide what's credible? How do we decide what's reasonable to believe?
Yeah, that's a good question. So we need to have some grasp of what is credible and what is not credible. I'm also of the opinion that the credibility part of the equation. It's a qualitative thing.
It's not a zero or one. It's something that is attached to a kind of a slippery slope, not easily defined. But what we could say, if we are trying to see credibility as a zero or one, what is credible? Things that have happened, actually have happened once or twice or three times, they are credible.
So the Triton incident or a safety only type of cybersecurity attack, that's now a credible attack because it has happened. And also near misses. That's something that Triton was kind of a near miss. They didn't actually cause this destructive attack, but it could have happened, and so we also have other near missus incidents that we should be considering as credible attacks.
Credibility sounds like a judgment called how do we decide what's. Credible's that's a good question. I think there's a good recommendations in sixty two four for three for instance, three thatsh two. It talks about, like I said, the consequence only as an example on how how you can approach the risk equation.
But it also talks about the need for focusing on worse case consequences. So there's it talks about essential functions, which basically it could be the safety functions for instance, you need to investigate the consequence if those are are actually attacked and compromised, what could be the worst case consequence? So you begin there and then once you identify the worst case consequences, then you move over to the probability or likelihood dimension. And then then you need to consider other factors.
So what are the. Vulnerabilities involved, what are the safeguards and or what the standard is talking about your compensating countermeasures, you consider that you consider the function or the asset as well that if there's if there's no actual interest in the asset, then the vulnerability could be also non interesting to address or analyz. So but you start with the consequence side. Then you start to look at the likelood and probability, and you are informed by the consequence approach.
Okay, so let me challenge you on that. I've read the c IE Implementation Guide. It says start with the worst case consequences. It says those words.
I've not seen those words in three dash two. Are you sure that you're not reading in the three dash too to be there. I've been searching for that specific part of three dish too many times because because I've heard others say that the same, and it's actually there. It's really gold nuggets in three dish two talking about the essential functions, specifically saying the worst case consequence and also specifically saying that you can choose to do a consequence only risk assessment.
So that's really really important. Single words or single sentences in three dish two so worth highlighting in the three dish two. Okay, so that makes sense in the abstract. Can you give me some examples what you know applying these principles, what should we regard as credible?
Yeah? Interesting question. I think that the things that come to mind first is, for instance, the Triton incident before twenty seventeen, where when it actually happened, we didn't think it was credible that someone would actually target a safety only system or cause a safety incident with a cyber attack with Triton it we actually saw the first first of its kind and the threat became obviously credible. And then Solo Winds as well.
It's a very interesting study where the way they actually compromised the Solo Winds update mechanism suddenly massive, massive deployment of kind of malware within critical and non critical infrastructure became a really credible threat as well. And also near misses. Of course, we should be informed by things happening out there and coming on the news that are near misses that can talk about talk to us about what is a credible threat. Another kind of near miss that I think or it's not a near miss, but it's scenarios or incidents that could talk about credibility is is where we actually have a safety incident.
For instance, we have had lots of them in Norwegian oil and gas and in oil and Jazz gas in general. Is safety incidents where we which is not cyber related at all, but where we see that it's it could be able to be replicated by a cyber attack. So that's something that we should be considering as a credible threat going forward, where we actually could replicate the cyber or the incident with the cyber course on credibility, I also think we need to put have in the back of our mind or in the analysis, we have to have focus on the technology evolution to development and sharing of new technology.
So I see it as a graph where where we are exposed to more and more heavy machine or heavy software that can be used on the adversary side, So with Kali, Li Nux, metasploit nowadays also AI. So what is being becoming a credible threat threat is more and more sophisticated stuff due to development of technology. So AI now is on both sides of the table, both as an attacker, as a tool that makes more more attacks credible, but also on the on the defensive side where we actually need to use it to to protect against more and more sophisticated attacks.
Let me go just a little bit deeper into into Kenneth's last example. I remember talking to him about this two days before I recorded the session with Kenneth. I was at another event, you know, I had a half hour speaking slot. I was, you know, listening politely to the other speakers, I remember, and one of the speakers was a penetration tester.
I remember asking the pen tester a question about AI and his answer alarmed me. And you know, I discussed it with Kenneth. I disgusted with other people, since you know, the future is is difficult. I asked the AI you know, the pen tester, so you know you touched on AI.
What should we look for from AI going forward? And I asked, you know, should we worry about about AI crafting phishing attacks because I've heard of that happening. Should we worry about AI helping the bad guys write malware to write more sophisticated malware, because I've heard of that happening, you know. And I paused, and his answer was, Andrew, you're not thinking hard enough about this problem.
You know. Yeah, that stuff's happening. But what you need to worry about is somebody taking a Cali limit Linux ISO image. This is the Linux disc image that every body uses.
All the pen testers use lots of attack tools, he says, taking that gigabyte of isoimage, you know, coupling it, adding it together with two gigabytes of AI. Model and the model has not been trained on natural language and creating phishing attacks. The model has been trained by watching professional pen testers attack OT systems mostly in test beds. I mean, this is what pen testers do.
They take a test bed that is a copy of a system that they're supposed to be, you know, doing the pen test on No one that does the pen test on a live system. They do it on a test bed. They use the calilinux tools, They attack the system and demonstrate how you can get into the system and cause it to bring about simulated physical consequences. So you've taught this AI model how to use the calilinux tools to attack OT systems, to brick stuff and bring about physical consequences.
You take that training model, couple it with the image, wrap it up in you know, enough code to run the image as a sort of kind of embedded virtual machine to run the the the AI model, the million by million matrix of you know numbers, that is a neural network. Run the neural network, run the KELLAI Linux image, and have the AI operate the tools to attack a real OT system. Drop that three three and a half gigabytes of attack code on an OT asset, start it and walk away, and it will figure out what's there.
It will figure out how to attack it. It will figure out how to bring about physical consequences. I heard that and I thought, crap, that's nasty. You know, back in the day, stucksnitt was autonomous.
It did its thing, but it was a massive investment to produce an asset, a piece of malware that did its thing without human intervention. This strikes me as again, something that will do its thing without human intervention and it will figure out as it goes. It's one investment you can leverage across hundreds of different kinds of targets. I was alarmed.
This is something I'm thinking about going forward. You know. It's to me, this is a credible threat. This is something we only need to worry about.
I don't know that this thing exists yet, but I'm pretty sure it will in five years. Is everything credible? What, in your mind is not a credible threat? At this point, I would think that large scale destructive attacks on big machinery is not something that I would consider a credible attack.
But it also goes back to the motivation of the threat actor. For instance, if you have a small municipality, I would see that really heavy sophisticated cyber attacks, a lot of them wouldn't be actually credible due to the target not being interesting for such a threat actor. So large scale destructive attacks is something that in a lot of scenarios wouldn't be a credible attack. And then we have, for instance, large scale blackout is quite an interesting story nowadays because a couple of weeks ago, I would think that it wasn't actually a credible attack.
Once we now see that it can happen. For instance, with Spain, it wasn't probably not a cyber attack, but it was something that happened on the consequence side. If we can show that or identify that it actually can be caused by a cyber attack, then that suddenly, nowadays, within the last week, has become a credible attack. And also swarm kind of attacks.
I hear discussions on that from time to time where they see talk about whether it's a credible thing where you attack at millions of cars. As of now, I don't see that as a credible attack, but things can change, you know. It's an interesting statement he made there that large scale attacks on heavy machinery isn't credible. You know, when I think about what we're talking about on this podcast.
The purpose of OT security presumably is that there are significant risks to really important machines at large scale. But maybe at this point we've covered that. That's a good point. I think one of the lessons here is that determining what is and is not credible is a judgment call.
Okay, different experts are going to disagree. I've you know, a few years ago, I saw research published saying, look, here's let's take for the sake of argument, the possibility of attacking a I don't know, a chemical plant and you know, causing a toxic discharge. And the researchers concluded that it was theoretically possible, but it was such an enormous amount of effort on the on the part of the adversary, all of which would have to go on undetected by the site. They said, you know, in the end, I just don't know that this is reasonable to believe that this will ever happen.
So, you know, that was one site, one one data point. But again, you know, there are the experts. Experts disagree. This is the what I learned on the very first book I wrote.
I got wildly different feedback from different internationally recognized experts. Here's here's an insight to me. This means that when we make judgments about credibility, we probably have to be We have to make you know, if we're going to make a mistake, make a mistake on the side of caution, error on the side of caution. Because different experts have different opinions, we might be wrong.
You know, every expert has to be honest enough to admit that we might be wrong and build a margin for error into their judgment of what's credible. So even if we don't believe that, you know, an attack that I don't know destroys a turbine is credible, we might want to take some reasonable defenses to against you know, such a not terribly credible attack in our opinion, But we might want to deploy defenses anyway, just because we might be wrong. And you know this, this is something that is also being discussed.
It's how big a margin for error do we need to build into our planning. I mean, I talk to a gentleman who produces who designs pedestrian bris. I said, how do you calculate the maximum load? He says, that's easy, Andrew, you build a barrier to either side of the bridge.
Vehicles can't get on the bridge. Most people are less than two meters tall. Most people are mostly water. You model two meters of water the width of the bridge, the length of the bridge, that's your maximum load.
And then he says and then he says, you multiply that by eight, and you build the bridge to carry the multiplied load. Because these are people we're talking about, it is unacceptable for the bridge to fail under load. And so this is the margin for error that engineers routinely build into their safety calculations. I believe we as experts in cybersecurity need to build a margin for error into our security planning as well.
One of the things that appeals to me very much about the credibility concept is using the concept to communicate with non technical decision makers like boards and directors. You do this, you have experience with this? Can you talk about your experience? Yeah.
I think it's interesting when when we talk to talk to board members and the c xos in different companies, they then they don't necessarily go into details about risk, but they know that they have a special accountability. So when we talk about credibility for those kind of people, they are getting more on board with the discussions. They know they have a special accountability. They draw the line in the sand.
For instance, if the potential consequence is that somebody would die, then that's a non acceptable risk and they take on that kind of position due to their accountability as board members or heads of the company. And they also are being accountable for from from the the government and from this for the society. So some some risks when it comes to the consequence side. If if we talk about people dying, then that's absolutely not acceptable risk for the society.
And the representatives for for that kind of approaches is elected persons in the government and they put the heads of the company or the board of directors as accountable for that on top of the company. So that makes sense. You know, boards care about consequences that the business or the society is going to find unacceptable. You didn't use the word credible.
How does credibility fit into acceptability when you're communicating with the board. Yeah, we don't have to defend against all possible cyber attacks. What we do have to protect against is the credible ones. So when we bring credibility in as a concept, then it's something that communicates communicates much better for the board of directors and the head of head of the companies.
This has been good, but you know, it's it's a field big enough that I fear we've missed something. You know, let me ask you an open question. What should I have asked you? Here?
We've been talking about credibility. Credibility is what is reasonable to believe. But it's not enough to talk about reasonable attacks. We also need to be talking about reasonable defense.
So what is a reasonable defense. We then need to be considering or taking all the tools. We need to use, all the. Tools at our disposal for a reasonable defense, and nowadays that also obviously includes AI on the defensive side, not only on the offensive side.
This is also a very important part part of me of the reason for me joining Omni. So Omni is built on our security knowledge graph, So it's a data model where we can put all information we need about our assets, on the vulnerabilities, on the network topologies, on the threats, the threat actors. So it becomes a digital representation or a digital twin of our assets. Combining that with AI, which we have built in from the beginning, we get a very strong assistant on security where it matters most.
This has been great. Thank you Kenneth for joining us before I let you go. Can I ask you to sum up for our listeners? What should we take away from this episode?
Thank you Andrew for having me, and thank you so much for being here in Norway and visiting us at our office. So we've had a good conversation about consequence, the focus on the worst case consequences, where we moved over to talking about credibility, replacing the likelihood concept with credibility, especially for high impact stuff where we don't have the probability or the data to talk about it. We also talked about reasonable attacks and reasonable defenses, So what is a reasonable defense against increasingly credible, sophisticated attacks with high consequences.
So it's been a really good discussion about all of these topics. If people wanted to know more about these topics or they want to discuss them, please connect with me on LinkedIn Message me there. I'm more than a happy discussion to discuss these topics. Please visit our webpage omnisecurity dot com.
Our platform addresses most of these topics we talked about today. Andrew, that just about does it for your conversation with Kenneth Tittelstadt. Do you have any final words you would like to take out our episode with today. Yeah, I mean we've we've talked about about credibility, and this is a concept that is relevant to sort of the high end of sophisticated attacks, the high end of of consequence.
But you know, I'm not sure. Let me let me try and and and give a very simple example. I mean, I was I was raised in Brooks, alberta little town, you know, ten thousand people in the middle of nowhere, literally an hour's drive from any larger population center. You know, in terms of cyber threats, do let's pick let's pick on I don't know the Russian military.
Does the Russian military have the money to buy three absolute cyber gurus, train them up on water systems, plant them as a sleeper cell in the workforce of the town of Brooks water treatment system, have them sit on their hands for three years, and after three years, using the passwords they've gained, the trust they've gained and the expertise that they have, have them launch a crippling cyber attack that the damages equipment, that takes the water treatment system down for forty five days.
Is that a credible threat? Well, the Russians have the money to do that it's you know, they have the capability to do that, but you have to ask, why would they bother? I mean, this is a little agricultural community, there's a little bit of oil and gas activity. Why would they bother?
That does not seem to be It does not seem to be reasonable to launch that kind of attack against the town of Brooks. It just makes no sense. I don't see that as a credible threat. Is that a credible threat for the water treatment system in the city of Washington, d C?
Home of the Pentagon. I do think that's a credible threat. So the question of what's credible is an important question that I see one and more people asking in risk analysis going forward. You know, we have to figure out what's credible for us?
You know, are what capabilities do our adversaries have? What kind of assets are we protecting, what kind of defenses do we have deployed? What makes sense? What's reasonable to believe in terms of the bad guys coming after us?
This is an important question going forward, and I see lots of people discussing it. I'm grateful for the chance to explore the concept here with with Kenneth. Well. Thanks to Kenneth for exploring this with us, and Andrew is always thank you for speaking with me.
It's always a pleasure. Thank you, Nick. This has been the Industrial Security podcast from Waterfall.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.