How do you plan for recovery when the system you’re trying to protect can’t be shut down—and won’t wait for IT’s playbook? In this episode, Tobias Halmans, an incident responder at admeritia in Germany, shares how disaster recovery and business continuity must be rethought when applied to operational technology (OT) environments.
⬥GUEST⬥
Tobias Halmans, OT Incident Responder | GIAC Certified Incident Handler | Automation Security Consultant at admeritia GmbH | On LinkedIn: https://www.linkedin.com/in/tobias-halmans/
⬥HOST⬥
Host: Sean Martin, Co-Founder at ITSPmagazine and Host of Redefining CyberSecurity Podcast | On LinkedIn: https://www.linkedin.com/in/imsmartin/ | Website: https://www.seanmartin.com
⬥EPISODE NOTES⬥
Business continuity planning is a familiar exercise for most IT and security leaders—but when you move into operational technology (OT), the rules change. In this episode of Redefining CyberSecurity, Sean Martin talks with Tobias Halmans, an incident responder at admeritia, who helps organizations prepare for and respond to incidents in OT environments. Tobias shares why disaster recovery planning in OT requires more than simply adapting IT frameworks. It demands a change in approach, mindset, and communication.
OT engineers don’t think in terms of “ransomware readiness.” They think in terms of safety, uptime, manual fallback options, and how long a plant can stay operational without a SCADA system. As Tobias explains, while IT teams worry about backup integrity and rapid rebooting, OT teams are focused on whether shutting down a system—even safely—is even an option. And when the recovery plan depends on third-party vendors, the assumptions made on both sides can derail the response before it begins.
Tobias walks us through the nuances of defining success in OT recovery. Unlike the IT world’s metrics like mean time to recover (MTTR), OT environments often hinge on production impacts and safety thresholds. Recovery Time Objectives (RTOs) still exist—but they must be anchored in real-world plant operations, often shaped by vendor limitations, legacy constraints, and tightly regulated safety requirements.
Perhaps most importantly, Tobias stresses that business continuity planning for OT can’t just be a cybersecurity add-on. It must be part of broader risk and operational conversations, ideally happening when systems are being designed or upgraded. But in reality, many organizations are only starting these conversations now—often driven more by compliance mandates than proactive risk strategy.
Whether you’re a CISO trying to bridge the gap with your OT counterparts or an engineer wondering why cyber teams keep showing up with playbooks that don’t fit, this conversation offers grounded, real-world insight into what preparedness really means for critical operations.
⬥SPONSORS⬥
LevelBlue: https://itspm.ag/attcybersecurity-3jdk3
ThreatLocker: https://itspm.ag/threatlocker-r974
⬥RESOURCES⬥
Inspiring Article: https://www.linkedin.com/posts/sarah-fluchs_notfallvorsorge-in-der-ot-traut-euch-activity-7308744270453092352-Q8X1
⬥ADDITIONAL INFORMATION⬥
✨ More Redefining CyberSecurity Podcast:
🎧 https://www.seanmartin.com/redefining-cybersecurity-podcast
Redefining CyberSecurity Podcast on YouTube:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
📝 The Future of Cybersecurity Newsletter: https://www.linkedin.com/newsletters/7108625890296614912/
Interested in sponsoring this show with a podcast ad placement? Learn more:
[00:00:00]
[00:00:00] Sean Martin: Hello everybody. You're very welcome to a new Redefining Cybersecurity podcast here on ITSP Magazine. This is Sean Martin, your host, where I get to talk about all kinds of cool topics in cyber and, and risk management and beyond. Uh, hopefully in a way that, uh. That explores how we can not just protect the business, but actually help them generate revenue and growth in a sa, safe and secure manner.
And in doing so, I, I'm honored to be able to talk to, uh, a lot of cool people as well, who are much more versed in specific topics, uh, than I, um, I have a nice overview, but sometimes it's good to dig, dig deeper in some of these things. And, and today I'm thrilled to have Tobias Almansan. How are you, Tobias?
[00:00:42] Tobias Halmans: Hello? Uh, I'm good and you.
[00:00:44] Sean Martin: I'm very, I'm very good. You're very welcome. And, uh, yeah, this is gonna be fun. Today we're gonna be talking about kinda the quote unquote, emergency preparedness for, uh, operational technology environments. So OT is, it's affectionately referred to [00:01:00] because we like to shorten everything to, to, uh, acronyms, right In this industry.
[00:01:04] Tobias Halmans: oh yeah.
[00:01:05] Sean Martin: Yes, exactly. Tech, tech is for sure, and definitely cybersecurity. Um, so we're gonna look at what it means to be resilient and have good disaster recovery, and how do we measure success and who knows what else? We'll, we'll dig into there, uh, specific around OT environments. Uh, before we get into, uh, the topic, the bias, maybe a few words from you about who you are, what you're up to, what led you to where you are and, and maybe why you're passionate about this topic.
[00:01:35] Tobias Halmans: Um, yes. Uh, thank you. Um, so, uh, I work for a consulting company at Maia in, uh, Germany. And we do, um. Our, our business is to, to do consulting, like all around, uh, OT security. And, uh, for, for me in particular, I am, uh, actually an, an incident responder. So most of my [00:02:00] work is, is all, all around that and of, of course also incident preparedness and, um, yeah, business continuity is, uh.
Touching on that. So I often have to, um, just to think about that as well. And, uh, uh, yeah, customers often ask, uh, what, uh, uh, what, what should we do to be prepared, uh, in, in the best possible way? And, uh, that's what I've been thinking about, what I've been studying about, uh, in, in recent years and where I have, uh.
Um, also some experience in, um, yeah, like de developing, uh, business continuity planning and also, uh, testing and, and applying that, uh, which is, uh, of, of course especially interesting. Um, uh, and then yeah, that's to, to also put that into practice. Not all, uh, not only or put it on paper. Um, yeah, that's, that's what I'm up to.
Um, basically.[00:03:00]
[00:03:00] Sean Martin: Yep. Well, that's fantastic. And, and this conversation, um, was driven, I, I often get inspired. Uh, I know it's nerdy. I get inspired by, uh, things that I see primarily on LinkedIn, sometimes other sources. But, uh, this, this crossed my, my path, uh, or my desk, if you will, through, uh, Sarah Fluke, who mentioned, mentioned an article that you wrote on Medium, uh, that, that's talking about business continuity and, and, uh, resilience in there.
So what, I'm gonna start there actually. What, what prompted you to write that piece? And maybe if you can give us a, a summary of. What it is and what the, what the outcome of it should be for people that read it.
[00:03:41] Tobias Halmans: Um. Um, yes. Uh, maybe to, um. Yeah, to, to give you an I Id an idea of where, where that all came, came from is, uh, um, as I said, usually it comes from, from an incident response perspective. So there [00:04:00] is some sort of cyber incident. Um, doesn't matter if it's in an IT environment or an OT environment. And at some point, uh, you will, uh, the, the, in the incident is.
Investigated and you have found out what, what has been going on and you eradicate the incident. Um, and then you, you need to recover everything. You want to go back to normal operations. Um, this is where we ask for business continuity plans, so to say. So, um, yeah. Well, of course we, we, we asked that beforehand.
Um. But, uh, this, this is where this comes into play when, uh, when, when, when you talk about cybersecurity. Um, and, uh, we did a lot of, uh, research and a lot of pro also projects on incident readiness and incident [00:05:00] preparedness. And, uh, when it came, when it came to the point where we discussed the recovery. Um, uh, I, yeah, yeah, it, it, it made, I, I somehow came aware that there is a huge difference, uh, in, in make, making such a recovery plan.
Uh, if, uh, on one hand, if you do it in an, uh, if, if you, if you ask it guys to do it in an IT environment, and on the other hand, if you. Ask, uh, OT engineers to do recovery in, uh, or a recovery plan for, uh, for a OT environment. So, yeah, A actually, to to, to be honest, we tried to, um, to use, at first we tried to use the same methods for, for both, uh, scenarios.
Um, and then I realized, okay, this is somehow different. We need to, we need a, a different approach. There is, um. The, it's, it's the [00:06:00] same goal. After all, you're going to recover as quickly as possible, but, um, the way you do the preparation is, is somehow different. So in my, my article, I, uh, uh, I made a brave statement saying, this is the most, uh, this is the thing that is, uh, mostly different between IT and ot.
Well, I, I, I'm open to other opinions, but in my opinion, uh, uh, or to to, to my experience, this is something you have to really, to take care. Um. Uh, yeah. You want to, to, um, to make a disaster recovery plan. Uh, who am I talking to? Am I talking to an IT guy? Am I talking to an OT guy? You need a different aplo approach.
Um, we start to realize that, and this actually made me write this article. Um, it came out quite long, so, um, a lot of differences that, that have been spotted. Um. Yeah. So that's, that's where it came from. [00:07:00] Um, and, uh, yeah.
[00:07:03] Sean Martin: So when? When, yeah. So when you say approach, um. I guess just, just general view from this, from my perspective, is there might be nuances, right? Where an IT environment looks like this and you might have to kind of maneuver in a certain way. In, in the IT and the OT environment looks different because of how it's networked or the protocols or whatever, and therefore you have to maneuver a different way.
But you, you said approach, which to me seems a little more strategic in how you. Define what needs to be done, not just maneuver, not, not just how you maneuver. Um, and perhaps that's a way, you also mentioned the ultimate goal is the same, but what, what, what's the difference in the approach that, uh, is, is worth noting here?
[00:07:56] Tobias Halmans: Um, um, [00:08:00] well, at, at first you need to, um, have a different way to, to let, let me say, to talk to people. Um, if you talk to it people, you can, I mean, what, what are, uh, usual scenarios, uh, for it disaster recovery? Number one, perhaps, uh, ransomware. You want to prepare for ransomware scenario. Um. It people, they, they know that this is dangerous.
So, um, that, that's a good scenario, uh, for, for them. Um, if you talk to OT engineers, uh, first thing they ask you is, um, yeah, okay. Well, what does this apply to? Does this apply to my SCADA system? Well, this might be a Windows space. Uh, yeah, that would be nasty. I don't want that, but, um, maybe my plant is still running because, uh, I, well, I, I, I don't really need my scada for my [00:09:00] operation, so, uh, as long as my DCS is running, um, I don't really care about ransomware.
There's some. Incident responders, some, a vendor, whoever coming, recovering my SCADA system, uh, in the meantime I can, I can run my operations manually. So, and then, then you start thinking, okay, what, what, what, what will I respond to that, what, what, what other scenario is is dangerous to an OT environment?
So, yeah, of course if you have a power outage, yeah, production plant will be down after. Sometime. Okay, what do you do then? Else then, then they say, okay, that will be bad. Um, but I have a recovery plan at hand. Uh, because, uh, we do this on a regular basis. Um, we, we do plans that, uh, like every three or five years because we need to shut the plant down for [00:10:00] maintenance.
Shutting down and recovering. Uh. It's, it's nothing that we really worry about. Um,
[00:10:09] Sean Martin: As long. As long as it's planned, and I guess, yeah. And then in a situation where it's maybe not planned it, it's still familiar because they've done it right.
[00:10:19] Tobias Halmans: Yeah, that's the first, um, perhaps the first, uh, miscommunication that can happen. As, as you say, it's not always only about the, the recovery. Maybe the recovery is, is already planned and, uh, you know, what the recovery should look like after a maintenance. Um, uh, a maintenance window. Um, yeah, but you're perfectly right.
But if the shutdown is not planned, how do you, um, uh, how do you do the shutdown? Um, and this is in, in ot. This is something especially interesting because you somehow need to, [00:11:00] uh, to do it safely.
[00:11:02] Sean Martin: I was just gonna say safe safety is paramount
[00:11:05] Tobias Halmans: E exactly.
[00:11:06] Sean Martin: o, in O2. Yeah.
[00:11:07] Tobias Halmans: Uh, what, what would the IT guy say if you ask him about shutdown? Oh, just switch. Switch it off?
[00:11:16] Sean Martin: Switch it off, turn it back on.
[00:11:17] Tobias Halmans: Yeah, switch it off, turn it back on. And, uh, uh, yeah, so there are, as, as you say, it's, it's nuances, but they, they make the difference. Um. Uh, after all, they make a difference in, um, in the way you, you communicate to people. And of course, in, in, in the answers you will get, uh, and those answers is, uh, yeah. That that's what you need, uh, to, to, to bring it to your final result, into your disaster recovery plan.
Um, I'm, I'm talking from, from my perspective here, so I am a, uh. Um, consultant or, I mean, who, who [00:12:00] does things like that? Usually it works like some management, uh, on, on, on top level management. They say, okay, we are somehow afraid of business outages. Uh, we want to have a disaster recovery plan. And then they start, uh.
A CO or a consultant like me, they come and, uh, start breaking down the business into, uh, different business processes. Um, and, uh, then they talk to, hmm, who, whoever is responsible for that process, uh, how can we, uh, what is the, um. Uh, how, how important is your process? How do, how can we recover it? Um, and, uh, yeah, if, I dunno, if you go to HR department, if you go to sales department, uh, this is, uh, uh, of, of course they will always say, uh, my process is the most important one.
If I'm not, uh, uh, if, if I'm, if I'm not working, then uh, the [00:13:00] whole business is at risk. Um, yeah. But, uh, asking a few questions, then you will Yeah. Get. A better picture of course. Um,
[00:13:09] Sean Martin: that point, if I may, because it, it, it starts with the business impact analysis, right? Which ultimately determines. That landscape. So what's, where, what, what's the impact if it goes down, what's the impact if the integrity is shot? What, what is the impact of the business if something happens?
And so my, my question on that point is, um, where do you see that, that, um, part of the program of, of being prepared and resilient in, in the organization being driven by, so who, who's. Who do you see is running the BIA, the business impact analysis and do you see that security's part of it generally, or is security an afterthought or do you see two teams?
There's, there's general business impact [00:14:00] analysis and then I'll then I'll say cyber impact analysis that kind of run in parallel. Uh, I'm curious 'cause it security seems to be bolted on a lot of times and I'm wondering what, what you're seeing.
[00:14:15] Tobias Halmans: Um, um, well, um, I, well what I see is that, uh, business, most of the times business continuity follows security. Um, in, in ot, so they do risk assessments, um, because they, uh, I, I mean it, uh, it, it, it makes sense. They, at first you want to see the whole picture of what could go wrong and, and, yeah. Due to a cybersecurity risk and, uh, business continuity.
At the end of the day, it's, it's just the answer to, to a, to a certain kind of risk. [00:15:00] It's for, for example, let's, let's go back to ransomware. Uh, this is just one scenario or power outage, another scenario or flooding. Natural disaster, whatever. It's just one scenario where you just one risk scenario, uh, where your response or where your mitigation, uh, should be a, uh, business continuity plan.
And, um, as soon as you have determined that, uh, you, you get aware. Okay? Um, I'm, I'm not quite sure what my business impacts are. So I need the business, business impact analysis. Analysis. Maybe you need it, maybe you don't need it. Um, uh, so the, the NIST standard, uh, for that, for example, they assume, uh, that a, yeah, that the business impact analysis is actually closely related to a risk analysis.[00:16:00]
Uh, and that, yeah, that, that's what what I also see, um, most of the times, um. Uh, but, but of course in general it's, uh, it's, it's two independent things because yeah, business continuity. It, it doesn't necessarily have to do with, with cyber. There's also other reasons where business continuity needs to be discussed.
Uh, let's let, let's look at COVID a few years ago. Um. It, it's not the IT systems or OT systems in this case that are not available anymore. It's, uh, it's the people because they cannot come to office or can, cannot, uh, go to, to visit the customer anymore. Uh, and that's also a situation where you need business continuity.
So in, in fact, I, um, it, it, it should be two different, um. [00:17:00] Two different management systems for that to, to cover all possible scenarios, not only the cyber scenarios, um, but we see that it's, um, the, the most cases that we see, it's, it's driven from, from cyber to be honest, because there, there's, uh, there people are afraid of, of those cyber scenarios, uh, to, to happen.
[00:17:25] Sean Martin: Yeah, and I guess to, to your point, um, the, well, the response and then the recovery, uh, can vary dramatically depending on what the actual incident is. Right. Um. So is it, is it a data integrity thing? Is it a, is it a workflow process and speed issue that gets injected into the, like making things spin faster than, than they should or, or valves opening and closing when they shouldn't?
That kind of stuff. [00:18:00] Um, very different response than. We have, we see some lateral movement on the network, uh, due to ransomware and it's spreading and, and we have a loss of data. Um, so I guess I'm curious kind of this, this chicken and egg thing where, how do organizations approach this? 'cause I hear you saying cyber is driving a lot of this probably.
'cause the scenarios are, are. Interesting. I'll say, um, and clearly security people can speak to the, the, uh, the fear of what can happen when something bad occurs on the OT network. So I guess I'm rambling a little, rambling a little bit here, but I guess what I'm trying to figure out is. If you try to do manage all risk across everything, it's, that's a huge endeavor that may never finish.
So I'm wondering how, how we get to the point where [00:19:00] we can say, here are the threats, here are our weaknesses. Here are the impact, the business to the business, if the threat actually compromises or exploits a weakness so that we can, and then the prioritization of all that stuff are we. Generally speaking, are we in a good place for kind of that loop or back and forth to take place or is it the loudest voice in the room, gets the, gets the project budget?
[00:19:30] Tobias Halmans: Um,
it, it, it, it should be like that. Um, I wouldn't, so if, if, if I, if I get your question right, you're, you're asking something like, is the. Uh, incident, uh, preparedness, uh, the, the, like, is, is it the easiest thing to get budget for because, uh, it, it, uh, incidents [00:20:00] always are frightening. Uh, is, is, is, is, is that your question?
[00:20:05] Sean Martin: So I, I think what I'm trying to understand, and, and maybe you can paint the, the process for me, but my, my sense is that somebody, you know, you don't have unlimited organizations, don't have unlimited resources to prepare for, um, unplanned downtime regardless of the use case, but some. Some parts of the business are impacted more, some of the threats can have a, a bigger impact regardless of where it touches the business.
So who, how do those conversations go where they say this has the biggest impact on the environment, which may get budget because it's a very clear scenario versus. Here's a small incident, but it could have the biggest impact on the business and therefore that should get the budget. Who, who's, who's driving those decisions?
'cause I hear you say the CSO and security are [00:21:00] really driving some of the BCP stuff, um, which may or may not directly relate to. What's the biggest impact on the business? Does that make a better way to put it?
[00:21:12] Tobias Halmans: Okay. Um, so, um, it's, it's a little bit hard, hard to tell. So, um, to, to be honest, uh. Those kind of projects are not always risk driven. Um, uh, very, very often they're compliance driven, um, of, as, as you say, of course, there're, there're frightening scenarios with, uh, huge impacts with huge possible impacts.
Although, uh, the likelihood may be maybe small. Um. Uh, especially in OT environments, as I said, was if, if you come up with, with scenarios to, [00:22:00] to OT engineers, uh, they may, they, they don't really want to. The first thing is they, they ask how, how could that happen? Um, that's usually a thing you don't ask in, uh, in, in business continuity.
You, you just assume, um, uh. It, uh, it, it, it, it could happen, although the likelihood is, is low. Um, but if it happens, the, the impact is, uh, is, is, uh, of, of course very high. Um, uh, but, but, but as I say, uh, as, as I said, the, I, I, I would say the low likelihood is rather something that, um. Is, is not beneficial to, to get the budget for those projects.
So, um, managers are, they tend to say, okay, um, our OT environment is, is closed and, uh, we don't have internet access, we don't have emails, we don't have, uh. [00:23:00] Uh, much vectors for initial access. Um, we, we do not prioritize that, although they know, uh, this is where the impact is, is the highest. Definitely. So if you have a production outage for a few days or even weeks, uh, due to a cyber incident, um, not, not every company would would survive that depending on, uh.
How huge, uh, the, the incident is. Um, yeah. So, so that's, that's what I see. Uh, and as I said, on the other hand, uh, uh, those things are, are also compliance driven because, um. Pol policy makers demand that, um, and insurances. They want to, they want you to pre, uh, they want you to prepare for that. Um, uh, I don't know in internal, uh, [00:24:00] policies, uh, management, uh, I-I-S-M-S, uh, management systems, uh, policies, um.
That, that's what I see mainly where, where that comes from. Um, and if it comes, uh, if it's risk wise, uh, as, as you say, um, uh, then, then it's because they think, um, that there, that there is actually a likelihood for things like that to happen. I, I hope this, this, this answers your question or gives you at least some insights
[00:24:36] Sean Martin: Yeah. Yeah, I think so.
[00:24:37] Tobias Halmans: start off.
[00:24:39] Sean Martin: I think so. So. Yeah, I, I mean, I'm curious in general, and, um, my primary audience is, uh, IT and the CISO for the IT environments, and, and so. Part of my questions are for them to perhaps understand how their world looks compared to, [00:25:00] uh, their, their counterparts in the OT space. And it leads me to this question about the, as more and more things come online in ot, connecting to the internet, perhaps even connecting to the IT environment, um, how do you see some of those?
Connectivity and, and intra network connections changing how organizations look at things.
[00:25:31] Tobias Halmans: It's, uh, it's a huge change, I would say, um, uh, for, uh, so organ organizations look at things, uh, differently in, in a way that they see more risk, um, general. Of, of course there are more cyber risk. Uh, not only the need to, to talk about business, uh, continuity planning, um, [00:26:00] or service continuity planning for ot.
Uh, but about risk in general. Um, definitely, yeah. And, uh, maybe coming back to, to what I have said recently, uh, since. Business continuity planning is, uh, very often cyber driven. Um, yeah. The, the, this is, uh, as, as you say, uh, OT is more and more connected to, to the outside world. Um, this is where, this is why organizations, uh, think about risk.
Uh, and as a consequence of that, they think about, uh. Business continuity planning, and they think about compliance, uh, as well. Uh, this, this new world arising be beyond the, uh, level three firewall somewhere. Uh, it, it needs to be, uh, [00:27:00] included in, in what I have, uh, in, in my risk management.
[00:27:04] Sean Martin: Yeah. Yeah. And when we look at, uh, disaster recovery as well, um, so I, I kind of pointed to it earlier, but different threats on different systems. And of course we just talked about increased connectivity and inter interconnectivity. Um. It means more, perhaps more people are involved in the response and recovery, um, which of course has to be captured in the disaster recovery plan.
So describe that process to me. Who, who's leading that charge? Is that also cyber driven? Um, because I'm thinking like communications right? In it you might have a, a dedicated system. That's not on the main network where you manage tickets and calls and things like that. Um, [00:28:00] what does, what does the OT environment look like?
Did they leverage the IT stuff or they leverage the SecOps or incident response teams systems? Do they have their own? What's that world look like?
[00:28:11] Tobias Halmans: Um, okay. Um, there's, uh, there's engineers. Um, OT engineers that are, um, yeah, let's say they administrating the, the systems. Um, usually you have different engineers for different technology. Um, they, their job is to, to somehow keep it running. Um. Oftentimes, uh, they are a little bit overwhelmed, uh, when they have to do, when, when they're asked to do the recovery on their own.
Um, oftentimes they really rely on, um, service providers. So in,
[00:28:56] Sean Martin: In terms of the, the manufacturer of the, the device [00:29:00] primarily, or, or a third party? Yeah.
[00:29:02] Tobias Halmans: It's Honeywell, Siemens, Amazon, um, out there they have, uh, service contracts. Uh, and, uh, again, I'm, I'm telling that story, uh, talking to the OT engineer, asking him about what, what's the, what will be the recovery look like. He's gonna say, okay, I have my support contract. Uh, my vendor will be here within two hours and he's going to do the recovery for me.
Um. Then in the next meeting, uh, you will invite the vendor and ask him what is his opinion about, uh, what is in that service contract? And he will say, okay, no. That service contract, um, if, if we have, uh, no, uh, any kind of, of disturbance in the system, uh, we will come over, have a look at it and resolve it, and then we go away.
Uh, if we have to recover the entire thing, which [00:30:00] is. Tens or dozens of, of servers, workstations, um, hardware, software, uh, whatever, whatever that may look like. They say, okay, we don't have enough people for that. Uh, or we don't have the, the knowledge for for that. And anyway, this is not in our contract. We are not obligated to do that.
So these are the kinds of, uh. Dis discussions that you, that you will hear, um, starting off, uh, making a, a business continuity plan. So, um, coming back to your question, what does it actually look like when it, when it's working? Um, it, it looks, uh, as, as I said, there's OT engineers. There are, um, uh, the vendors.
Uh, or the, the vendor staff that actually knows how to set up, uh, the system. Um, [00:31:00] and then there, there's a lot of, uh, of, of crisis, uh, crisis management team around this. Um, usually, uh, OT companies, uh, already have crisis management teams, um, uh, in terms of safety. So when there is a safety hazard, when there is a severe accidents accident, they have crisis plans for that they're supposed to have.
Uh, and they don't care where that crisis comes from. Does it come from a cyber incident or does it come from some random accident? It, it doesn't. It doesn't matter. Um, the, the crisis team, um, takes care of it, but of course, uh, at the beginning they don't know about how to resolve a cyber incident. So that's where they actually need support and where you need to bring together the vendors, the [00:32:00] engineers, and uh, perhaps some skilled incident responders and, uh, forensics.
Forensic guys, um, that actually know how to chase a threat, uh, and to, to chase a, uh, an adversary out of the network. Um, yeah, that's, that's basically what it looks like in a, in a, in a mature organization, I would say.
[00:32:23] Sean Martin: Okay, so in that, in that same mature organization, I would, I would expect them to, to understand where the shared responsibility and, and limitations of their vendors land and. Have a plan in place when an incident occurs, where they know we're gonna get support up to this point. And from there, it's on us either to figure it out ourselves or find yet another, another third party perhaps to, to work that out, which if you recognize that, [00:33:00] um, hopefully it's through a conversation with the vendors.
And then once you, once you have that understanding then and confirmation of, of responsibility. Um, the business continuity plan, disaster recovery plan would reflect that, I would think, for the mature organizations. Does that exist generally, or, um, does it fall down a lot? Do you see a lot of organizations get to the, have an incident, get to the point and, and realize our vendors can't help us and we have nothing in place to, to get past from, from B to Z.
[00:33:36] Tobias Halmans: Um, well. Uh, yeah, at, at, at the beginning. Um, expectations are usually a little bit higher on both sites. So, uh, as it's, it's as you said, the, uh, you, you create the, the, the, the business continuity plan by talking to each other. What do [00:34:00] I expect from my vendor? Um, what does the vendor expect from me? Um, things like, uh, licenses or.
Uh, stuff like that. Passwords, uh, they, they don't know the, all the, all the passwords for, uh, yeah, for, for recovering all the system from the backups. Uh, so these are the, the things you need to find out and, and the business continuity plan. And as, as you say, as in, in a mature organization, it's, um. That's actually the same as, as a, in an IT environment, uh, you need to know about who's, who is responsible and who's capable of doing what for on, on a particular system.
So, uh, that's, that's basically the same as, as in I, as in an IT environment. So what is, what can the administrator do? Can he set up the [00:35:00] whole thing and, uh, re recover it from the backup? Or where does he need help from? Does he need help from his managed service provider or from his cloud platform provider?
Uh, where is the help needed? What exact kind of help is needed? Um, that takes a lot of room in, in our discussions, um, preparing those, uh, business continuity plans.
[00:35:30] Sean Martin: And so. What does, how, how do these teams ma or measure, define success and measure success? Because in it, the incident responses mean time to recover, time to respond, mean time to recover, that kind of thing. And language is slightly different in, in ot, right? There's recovery time, objectives and things like that.
So how, how do those measurements. Our definition of measurement of success [00:36:00] look like an ot and maybe how's it differ from a, an IT environment?
[00:36:05] Tobias Halmans: there, there's not much of, of a difference, I think. So our recovery time objective is a, um, ex exists for, for both, um, IT or OT environments. Um, it is just a little different to, as, as I said, to apply it to, um. To an OT environment, actually it has to come from the business. So if, if you talk to the engineers and you want to find out about the, um, meantime to recover or the recovery time of rather about the, the meantime to recover for the process.
Um. Most of the time it's already too late. So you need to get that information from, from somewhere else. They will say, uh, okay, I have, um, they, they only know, uh, the plant is running, or plant is not running. So [00:37:00] either, either on nor off. Uh, and if, if there's most services in there, there's actually two kinds of services in ot.
Um, ones that are, uh. Uh, what the first kind that is, um, uh, urgently necessary for the process. So if you shut that down, the entire process will shut down in a very short time after that. Uh, for example, the, the everything that is related to the DCS that controls the process, if you don't have that. Pro you, you, you need to shut down the process manually or it shuts down itself.
And the second kind of service is, uh, those that are, um, where, where actually nobody cares if they're running, uh, because the process is running without them for, for a very long time. For example, data, data acquisition for, uh, whatever purposes for performance monitoring or something [00:38:00] like that, you can.
Usually easily for weeks or month, uh, live without those kind of things, um, without those services. Um, uh, and yeah, it's, it's, it's a little bit hard to put the recovery time objective in that framework. So usually you assign a recovery time objective to a single service. In your network. Um, and if you ask for a recovery time objective for, I don't know, any service in the DCS, they will say, okay, it's, it's at, at the end of the day, it's zero, uh, zero seconds because if the service is not running, my plan is not running.
Um. So this is a, again, this is not the right way to, to communicate, uh, and it's not the right question to ask. Um, yeah. [00:39:00] So yeah, coming back to your question, uh, how to, how to measure the success, how to measure if the recovery time objective is met, um,
is, uh, that you, you need to, to. To step up to, to a higher level where you have defined your, uh, yeah, rather yeah, your, your meantime to recover. So how long, uh, is it, is it bearable to be out of production, to have the production out? Its for the business, uh, whatever that means. Uh, if the, if the business will completely go bankrupt because of that. then it's already too late. Uh, or if I have a loss, a revenue loss of, well, let's say 20%, 50%, whatever. And then I will, uh, put, define that [00:40:00] as, as my, uh, meantime to recover. And then you will go to the engineers and say, okay, your business, uh, wants you to be up and running again after this amount of time.
Uh, what needs to be done in this scenario and in this second scenario and in this third scenario. Um, and this is where, um, yeah, people start giving, uh, interesting answers.
[00:40:31] Sean Martin: Uh, I love it. I appreciate that. And so I wanna, I wanna, we're coming up on time here, so I wanna close with this. It's, it's a question I often ask my guests who are primarily in the IT space. Um. When I, when I picture the business and we, we, we didn't say the, the two letter acronym, that seems to be touching everything nowadays, but when, when we start, when organizations innovate and they build out new business processes, launch new [00:41:00] products, enable new services, and the it world, it, it brings a plethora of new technologies and new microservices and.
Third party vendors and all this stuff, which it starts to get pretty complex. And with that complexity I see driving the need to have better detection and response in the IT world. Um, and so my question to most of my guess is if security were able to really drive. Or be, be a significant part of the definition of what gets built and how it gets built and deployed.
Perhaps their job as security detection and response becomes easier because they're helping to shore up and close the gaps and, and mitigate the vulnerabilities before it's even built. Um, so I'm wondering if, if we're in a, in a state, in the OT world where we have [00:42:00] information that says. Here's what this environment could look like. Much more safer, much more resilient if we did this because we know these threats are coming and we don't wanna, we, we don't wanna put that exposure in place in the beginning. Are those conversations happening in OT where it's, they say the environment needs to change or should change to be more secure from the design and the architecture and, and therefore not?
Not leaving risk exposed and killing the security team in response.
[00:42:34] Tobias Halmans: Um, yes, those conversations are taking place definitely in, in recent years. Um, they're taking
[00:42:43] Sean Martin: have any examples
[00:42:44] Tobias Halmans: um.
[00:42:45] Sean Martin: like where, I don't know, protocols are not used or connections are not made, or different vendors are selected. Are there any examples you can share where
[00:42:54] Tobias Halmans: Yeah. Uh, um, I, uh, [00:43:00] uh, know of a, a redesign, uh, there, so, uh. I, um, operate of a chemical plant. They recently redesigned their safety environment, so consisting of safety PLCs, engineering workstations, um, uh, sequence of events. So, so that's kind of a historian for safety, uh, for safety PLCs and, um, some data acquisition O-P-C-U-A.
Um. And, uh, I know this, this conversation took place between the vendor and the operator and also myself. And uh, uh, that's why I know that those things are going on. So they decided to, um, have a completely, a separated network for that. Uh, with, uh, dedicated security [00:44:00] architecture. So they have their own active directory.
They have their own, um, uh, patch deployment. They have their own antivirus, um, which hasn't been there before. So that environment was a couple of decades already running and in operation. Um. And, uh, when the, the day came that they just, um, yeah, wanted to replace the systems just because they were old. And this is where those conversations of course, take place.
And then the, when the vendors say, okay, um, maybe you want to consider security here, we have a nice, uh, offer for you how you can secure your ground, your, your safety, uh, controllers, which is. Your number one crown jewel. Um, here's our idea, how you can do better. [00:45:00] And then those discussions start. And then they, uh, of, of course the operates, sometimes they come to us and ask, okay, is this something uh, that really helps me or is this just something for the vendor to make more money?
Um, and then sometimes we say yes, and sometimes we say no. Um, but. Those are the, the kind of conversations that, that take place. Um, and, uh, yeah, and it, it, it's not only vendor driven, um, it is, uh, operator driven. It is also compliance driven, of course. Uh, because, um, yeah, those, those days you, you cannot ignore.
Um. Yeah, the, the, that, that kind of, that, that kind of legislation also applies to, to OT environment. Um, you have to take care of things, uh, like that. Auditors come around, uh, ask for that, [00:46:00] ask nasty questions, and you want
[00:46:02] Sean Martin: different, different bodies, but, but, uh, same, same uniform.
So. Well, this has been, uh, really insightful, Tobias. I really, I appreciate your time. Uh, we're, we're kind of at the end here, but uh, is there something that we didn't touch on that you think folks should hear before we close?
[00:46:26] Tobias Halmans: Uh, there's, there's so many things, uh, that we could continue talking about. Um,
[00:46:32] Sean Martin: How about this? Maybe, maybe one or two things we should talk about some more. And that that organizations should be thinking about.
[00:46:41] Tobias Halmans: Um, uh, I think I would, I I think there's, there's not much more, um, to add to that. Uh, but let, let me try to, uh, yeah. To, to carve out the, the main points that I would, uh, [00:47:00] uh, coming back to that article that I had in mind, uh, that I wanted to share. Um, and, uh, I, I, I try to, to share it here once again. So, um, as, as I said, uh, IT and ot, disaster recovery, uh, preparation goals are the same.
At the end of the day, you want to, uh, maintain your business. Um, you want to make sure that the disaster re, uh, recovery does not take too long for your business. Um. To, to be not longer a business anymore. Um, but, uh, you should be careful in your, in the way you communicate to people. And, um, things in OT need to be explained differently.
Um, they need to be, questions, uh, need to be asked in a [00:48:00] different way. Different questions need to be asked. Um, to get the answers, uh, that you need to, that you actually need for your, your recovery preparation.
[00:48:13] Sean Martin: Yeah, so it sounds like also being prepared for questions from, uh, specifically the engineers that, that may not have the same level of understanding and, and level of trust with the cyber part of the equation. Um, to your point. Earlier. Um, how or why would this happen or could this happen? Um, so being prepared to again, and using your other points you made and respond, be prepared with those questions and respond in a way that that helps 'em understand and builds trust with, with the team to, uh, to see it through. So, Tobias, it's been a pleasure, my friend. It's good to, good to meet [00:49:00] you. And, uh, hopefully,
[00:49:02] Tobias Halmans: much.
[00:49:02] Sean Martin: I don't know when I'll be in Germany next, but, uh, perhaps we can, we can meet up there or at one of the many conferences. Uh. I attend. Maybe you'll be at one of those when you can meet in person, but I appreciate you writing that article.
Appreciate you ta taking the time to chat with me here. And, uh, I, I appreciate Sarah for, uh, for sharing that. So, across my path now, now I'll, I'll be following you, so I'll get, I'll get direct access to new stuff that you write and, uh, I would encourage everybody to connect with Tobias, uh, and. Keep the conversation going there, of course on LinkedIn and other, other social platforms if you wanna engage with us.
Thank you for listening and watching today. Please do subscribe, share with your friends and enemies if you so choose to do so. And uh, thanks for watching another episode of Redefining Cybersecurity on ITSP Magazine. Thank you.