The Importance of Identification 
in Cybersecurity 
Incident Response

Welcome to the third episode of our Energy Talks miniseries titled, Why Should You Talk About Incident Response? Join OMICRON cybersecurity consultant Simon Rommer as he explores the different process steps involved in cybersecurity incident response alongside other experts from the power industry.

In this episode, Simon speaks with Johann Stockinger who is Head of Digital Forensics and Incident Response at the Deutsche Telekom Security Operations Center. Simon and Johann talk about the importance of Identification, which is the second step in the incident response process. 

Johann highlights the complexities of cybersecurity, particularly in the context of data overload, the importance of historical data analysis, and pro-active threat hunting. He emphasizes the role of SIEM in security operations, the necessity of specialized tools in operational technology (OT) security, and the convergence of IT and OT security monitoring. 

Johann also highlights the importance of contextualizing alerts for effective incident response, building a comprehensive incident timeline, and the critical collaboration between IT and OT teams in cybersecurity defense.

If you haven’t already listened to Part 1 and Part 2 of this miniseries, be sure to check them out – 

#85: Why Should You Talk About Incident Response? | Part 1 - OMICRON

#95: Why Should You Talk About Incident Response? | Part 2 - OMICRON

Scott: Hello everyone! My name is Scott Williams from the podcast team at OMICRON. This is the third episode in our Energy Talks podcast miniseries about cybersecurity titled, "Why Should You Talk about Incident Response?” Your host of this miniseries is Simon Rommer, who is an OT Security Consultant in the OMICRON Power Utility Communications Team. Simon is currently exploring the steps involved in the incident response process with his guests. So, without further delay, I hand over the microphone to Simon. Hi Simon!

Simon: Thank you, Scott. I welcome our listeners to the third episode in our Energy Talk Cybersecurity mini-series, where we explore the critical roles of IT and OT in power system cybersecurity and discuss the steps involved with the incident response process according to SANS. The SANS Institute is a highly regarded organization specializing in cybersecurity training, certifications, and research. In our previous episode, I spoke with Tibor Külkey from ALSEC, a leading Swiss consulting company about Preparation, which is the first step in the incident response process. 

In this episode, I speak with Johann Stockinger, a former colleague of mine from the Deutsche Telekom Security Operations Center. And Johann is also leading both the threat hunting and the digital forensics and incident response team respectively. Today we are talking about Identification, which is the second step in the incident response process. So, without further delay, I welcome Johann to talk with me about the importance of identification in the incident response process.

Johann: Thank you so much.

Simon: Let's head right in. What is identification exactly and what is the difference to detection?

Johann: So, depending on who you ask, they're essentially the same. Some people might differentiate, but honestly, for the most part, whether you call it identification or detection, those people will consider it very, pretty much the same thing. If you want to make a distinction, I'd probably call detection as, let's say detection is looking for anomalies.

You're not sure what you found, something anomalous, you're looking at it, you're still analyzing it, but it's something that you found, right? It might be malicious, might be benign, but it's something that you've detected. And identification to me is then saying, “Hey, all right, I found something, I've looked at it, and this is malicious, or at least this is suspicious enough to warrant a response. It's not benign, it's not false positive”.

So, if you'd like to make this distinction, then I'd go with that way. But honestly, you could just call both detection or identification and most people will know what you're talking.

Simon: So, what is the thing that we are detecting here? What is the medium that we are identifying in? Is there something special in OT? How is it going on in IT? What is the difference and what kind of medium are we talking about?

Johann: What you're looking for is essentially behavior that is not normal, behavior that in some shape or form could be attributed to an attacker. Now, as for the medium, I mean, it depends on how you look at it. Essentially, you are looking at some hardware running some software that does something. But in IT, what you can focus on what you should focus on is looking at the endpoints themselves. So, looking at behavior on the endpoints, processes being created. Yeah, yeah, workstation service. It doesn't make too much of a difference in that regard. You're looking at processes being created, network connectivity being established from the device, you're looking at files being written. Really any kind of behavior going on an endpoint, that is the most effective way to find an attacker anywhere, but in IT it's easy to do. 

Whereas in OT, because you mentioned that, it's harder to detect or to monitor behavior on an individual system. Simply because in IT, you can install an agent, because that's the easiest thing, you have an agent installed on the system, and that just monitors everything. Whereas in OT, you're constraining what you can do on an endpoint itself. You cannot just install an agent. you do that, it's just that two OT engineers, probably, well, they can't do that, right? You can, you're very constraining what you can do for a variety of reasons.

Simon: So, there is solutions to try to do that on IEDs and intelligent electronic devices. But this is more like a proof of concept. And the other thing is in OT, endpoints are quite old. So, XP, not so much anymore, but Windows 7 is out of support as well. So that's why we don't have that many possibilities to detect stuff on the endpoint. So, I'm totally with you that network traffic and like the network communication is our source of truth, so to say.

Johann: It's what remains if you cannot look at the endpoint, you need to look at what the endpoint signals out to something else, right? And that, like you mentioned, will be network. It might be logs being written out. It might be anything that you can collect without being on the endpoint itself. Whereas in IT, it's the other way around. 

Simon: Yeah. And the other difference is that in IT everything is encrypted. In OT, for example, Goose, MMS, 104, Modbus, OPC, so everything is clear text. That's why it's easier to detect anomalies in network traffic.

Johann: It's easier to monitor network traffic. And obviously that results in being able to detect stuff because like you mentioned in IT, everything, most network communication nowadays is encrypted. You'd need to break that encryption that introduces a whole new level of complexity and not just technically, also regarding compliance legally. Whereas in OT, you can just do that. And that was the case in IT as well, like 20 years ago. There was a much larger focus on detecting malicious network patterns because 20 years ago, not everything was as encrypted as it is today. That's the reason the fact that, like you mentioned in the beginning, OT systems are old. They still do not use and cannot use encryption in the way that you do it in IT systems. So, network behavioral monitoring will be more possible than it is in IT and you will find stuff more quickly or more reliably than you will in IT, I guess.

Simon: Also, in OT encryption is more of a hindrance and can take away some possibilities to troubleshoot that you need on a daily basis instead of bringing better to being encrypted. So, encryption is not helpful so to say in OT.

Johann: I guess you could make an argument for IT as well, but yeah, I know where you're coming from.

Simon: So, we're talking about technical stuff already, but let's get back to what are the methods and what are we looking for in network traffic. So, what is the things that stand out to us or to you as a forensic analyst?

Johann: Yeah, mean, especially if you focus on OT now, or let's approach this differently. In an IT network, you will have lots of different behavior going on. You will have new endpoints constantly. You will have changing destinations, changing traffic. You will have lots of change. It's a very dynamic network, very dynamic environment. Whereas in an OT world, typically, ideally, or hopefully,

You will not have that kind of dynamic, the environment won't be as dynamic because you will not have new systems being deployed daily. These systems have very specific purposes. And so you know what they are doing. You know where these systems connect to, you know, when they need internet connectivity, which is a whole different kind of worms, which I think we'll get to later, it's a more static environment.

So, simply since it is so static, compared to the dynamic IT world, you can focus on finding behavior that just is rare. If you just look at other new endpoints in an OT world, that is something you can detect on the network level, because you will have new senders, new recipients in the network. And you can build detection rules for that, and then you can investigate whether this endpoint is legitimate or whether somehow an attacker managed to put their own device into the network. You cannot do that in your typical IT network because new notebooks are deployed in such a regular occurrence, especially if you look at, let's say, modern setups with containers, you will have new speakers in that network within minutes and cannot detect based on that, but you can in OT. that, I that's just one example, but that is how you detect threats in OT due to the nature that it's so static. You can build a certain baseline and the ground truth much more efficiently and reliably than you can in IT. And anything violating that ground truth, that is something to look at. Not necessarily that it's malicious, but it's something to explore.

Simon: So basically, what you're saying is that in OT environments you are supposed to know the system, especially in Electronical Engineering or in the energy world where we are coming from with 61850, the whole substation is defined in a project file and everything that is not in this project file or everything that is besides the expected behavior is supposed to be investigated. Is that what you're saying?

Johann: Yeah, essentially, it's worth looking at because either you somehow forgot to document something, like it can happen, but typically in such an environment, you should be aware of all the assets, all the endpoints of everything going on. And if there's something that you are not aware of, yeah, you should probably look at that if only to update your documentation.

Simon: Asset inventory is a big pain point for not only IT but also OT and I think everybody has had their fair share of headaches with asset inventory.

Johann: If you've ever heard me talk anywhere, one of the main points that I always stress is that you need to be aware of what you're defending, otherwise you cannot defend it.

Simon: So, with that said, it sounds quite straightforward or quite easy to be honest. Just detect something that deviates from the baseline or deviates from a known good or from a status quo. Is there things that attackers can do to be undetected or can they evade detection? So how do attackers distinguish themselves from script kiddies or from a student that tries something out to being more sophisticated?

Johann: So, you mean the level of sophistication that adversaries may have. I mean, it differs, right? You will have all kinds of adversaries, especially nowadays. Let's take a step to the IT world again. One of the main, one of the most common and feared threats are ransomware groups nowadays, right? And the level of sophistication differs substantially between attackers simply since we have ransomware as a service nowadays. So, you have adversaries that just buy tools, buy the ransomware, buy various access to platforms and they themselves don't need the skills that you would if you do not have access to these ransomware as a service kind of platforms. 

In an OT world, because it's not IT, many of these, let's say unsophisticated or less sophisticated attackers, they will be brought to their limits simply because it's not IT, simply because it's not your regular network. And because the less sophisticated an adversary is, the more reliant they are on having sort of a playbook for their attack. And that playbook will probably be focused on what they commonly encounter. So, your standard Windows-based IT domain. 

I’ve even had clients which, because they were so small, like they only had like two or three servers and a couple of workstations, they did not have a Windows IT domain. They had Windows, standard Windows IT network. And they did not have a good security posture at all. Like RDP was exposed to the internet. That's how the attackers got in. But the attackers never managed to do anything because there was no domain. They couldn't move laterally because their playbook, I guess, didn't specify what to do if you do not find a Windows domain. And this is a very simple and basic example, but it translates over very well to OT. You will not have your standard Windows-based IT domain. And so many attackers without the skill set to adapt, they might not know what to do with that.

Simon: Also, the ones that get detected easily, I guess.

Johann: Yeah, because they just follow their standard playbook. They will make noise. Once you make noise, it's easy to detect someone, or easier, because that is what you're detecting, right? These are the signals and anomalies we've talked about. And then you can react to that. Now, if you have attackers who are actually, let's say, capable of adapting, they aren't reliant on their playbook. They just adapt to whatever the situation demands. Those will be able to infiltrate OT networks or any networks because they have this level of sophistication that you need to do so. These attackers are also typically very aware of detection mechanisms and what most organizations do to detect threats. And so, they will adapt their behavior to reduce the chance of being detected. Now, these are obviously, any sort of state sponsored actor and APT will, there's a high likelihood that they will have the skills to adapt and not to be detected as easily. Some financially motivated actors will as well. And there is even an overlap between state-sponsored and financially oriented actors. But let's say these more sophisticated attackers, they will be able to infiltrate OT networks. And they will know what to do because they typically are there with a clear purpose and a clear mission. And that is most often not more than just encrypting what they can and demanding ransom. Especially for target state sponsored actors, they have a reason for being there. And this is not getting more money.

Simon: As we've seen in the past with attacks and hacks, they even built a twin system to be able to try out different attack methods and train for the attacks, so to say. Especially with the Ukraine conflict where Russia invaded Ukraine, they also attack that had different goals than money. So, they wanted to disrupt the infrastructure. What you're saying is what we see in real life where cyber-attacks are not only motivated by money in our industry, but most likely they are motivated by a political goal. But this does also mean that the attackers are aware of the tools and they're of using the tools that normal engineers use which also makes it very difficult to detect them because they can evade detection techniques. So, what are you guys in the SOC doing in such cases? So, is there some extra measurements or is there some extra activities that you are doing?

Johann: I mean, neither side, at least to my knowledge, has magic at their disposal. So, neither the attackers, regardless of how sophisticated they are, nor the defenders, regardless of how sophisticated they are, like we're all bound to some constraints that the technologies give us, right? This is just real life. Any attacker, regardless of what their goals are and what level of sophistication they have, there are some things that they need to do. They need to move naturally. They need to escalate their privileges. They need to gain access to the infrastructure to begin with. Like these basic steps of an attacker's workflow, they are always the same, regardless of who the attacker is and what their goals are. And you will never be able as a defender to detect every single attack pattern on every single vector that may exist. You'll never be able to cover all of that. Not realistically, not feasibly. So, what we do in general is to focus on these TTPs, so tactics, techniques and procedures that attackers use, that are just essential to any kind of attackers kill chain, if you want to use that phrase. Let's take lateral movement. Every attacker will need to move laterally. So, if you focus on detecting signs of lateral movement and disregard, let's say, more exotic signs of, I don't know, on system manipulation and how exactly they manage to exploit their privileges on a system. But rather, as I said, focus on lateral movement, focus on these basic patterns that they need to follow, then you have a higher chance of detecting them. Not just these sophisticated attackers, but all attackers.

Simon: For our listeners, lateral movement is when you go from one device to the next device but on the same network level. For example, from Workstation A to Workstation B. And you need to do that because Workstation B has all the SCADA controlled software on it, for example. 

But that's you saying that you're going for the basic techniques, but are you doing this regularly or is it automated process? Is there something that you still need to do manually?

Johann: Yeah, mean, it's both really. When detecting, you have two main ways of going about it. You have your regular, what most people think of when they hear security operation center monitoring, you have a constant stream of data, of real time data that you monitor via certain detection rules. For example, you have your network traffic, you have your logs being sent, you have your detections being triggered by certain security products, all of them in real time end up with the SOC. And there are some detection rules to find patterns, to find suspicious patterns in that data. 

Now, when you do that, you need to be careful about the detection rules you employ because the amount of data that you're seeing, it can be vast, right? Depending on the infrastructure and what you're monitoring, you have thousands of events coming in every second. And obviously, it's completely impossible to look at all of these single events. You need some detection rules to find these patterns. And if the number of detections is too high, as in you're finding stuff that is suspicious but benign, so classically what you'd call a false positive, and you have too many of them, you will develop a certain alert fatigue within your analysts because you're seeing the same things over and over and over, and eventually you start paying attention because you've seen it hundred times before. So, if you're doing that way, you will be able to find threats in real time, ideally, but you need to fine-tune your detection rules accordingly. And that fine-tuning will create blind spots. Because you will, in order to prevent this enormous number of detections, you will have to tune your alerts to a point where something slipped through. And that is where you go the other way, and you proactively, in regular intervals, search through all the historic data and see whether you've missed something. When you do that, you don’t need to put in as tight of constraints as you have when monitoring real-time data. You look for certain patterns that you think should be there if an intrusion happened. So, you assume an intrusion happened, this results in certain artifacts having to be present in your data. And now you retroactively look at that data and see if these patterns are there. 

Simon: And can also take your time a little because you're not constrained by needing to be able to process the data in real time.

Johann: You don't have the next detection flowing in or the next and the next and the next. You can fine tune stuff, ask the engineers, hey, I found these patterns. And I'm not sure, like it could be an artifact from the intrusion, but it could also be legitimate, giving you feedback here. And then you incorporate the engineer’s feedback. And so, you fine tune your results and basically get a smaller and smaller and smaller number of artifacts that you look at until you can either say that yes, we found conclusive evidence that an intrusion might have happened. So now we need to go a step further. Or you say, all right, we've had this hypothesis, this attack should have left these kinds of artifacts, we didn't find any. So, it doesn't appear like this intrusion happened. And if you combine these two approaches, this real time monitoring, and this proactive threat hunting, then you get a rather holistic picture of the entire infrastructure. Now, obviously, there's no guarantee that you will find every single detection. But there's a good chance if your scope, if the scope of your monitoring, both reactively and proactively, includes many assets, then you should find at least some remnants of an intrusion, either because it's happening in real time or because it's happened recently, but you should find something. You don't need to find everything. Like finding every single detail is something that you can do when going into incident response and doing deeper forensics. Right now, during identification, your goal is just to find a clue that something might be off. You don't need to find everything. You cannot find everything.

Simon: That's a really big chunk of information right here with lots of interesting points to talk about. Some things that you said were really standing out, for example, you have loads of data. So where do you store all this data? What is the central point and how do you deal with the data? So there has to be some central log management system. We both know it's called SIEM. Our listeners might not know it. So, can you talk about the SIEM a little bit? 

The second thing was when threat hunting, you said that you have some smaller indications of compromise or smaller indicators of an attack. And then you talk to the engineers. And this is also something that I've seen in the past that the engineers and the OT personnel plays a really big role. So, these are two points. Could you elaborate on those?

Johann: Sure, so let's address the first one first. So, a central point of information. Now you've mentioned the term SIEM, so Security, Incident and Event Management, but this is what historically has been the heart of any kind of security operations center, whether it's an IT or an OT, SIEM was the heart of it. It's where all the logs and all the monitored network traffic,

got consolidated, got correlated, and then you had your detection rules in place, and you found your attack patterns. Yeah, that is the historic viewpoint. And in an OT setup, that might still be somewhat relevant because, like we said earlier, you are very much dependent on not on endpoint stuff, right? Network traffic or logs. In an IT world, this is, in my opinion, a SIEM is no longer required because you have all of these specialized tools like EDR solutions, XDR solutions, NTRs, IDTRs, whatever. There's a whole, whole, whole world of abbreviations, but essentially you have specialized tools that no longer produce raw data, but they produce qualified alerts, and you only react to those. So, you no longer need a SIEM. You need something else where all this data is collected, some central plane, but honestly in IT that's no longer senior. 

Now in OT, it depends on how you've set up your monitoring. Now, if you have specialized tools, I'm just saying these names now without any sort of value attached to them, right? So, in an OT world, you still have some specialized solutions like a StationGuard, your solution... But you also have raw network traffic. Or you could have raw network traffic and log data, especially if you do not have specialized solutions. And then you need to store and correlate this somewhere and the CM or some kind of log management setup would still probably be required to have detection rules. Otherwise, you're just getting raw log data. But raw log data doesn't tell you anything by itself, right? You need to find the patterns within that log data. And this is where a SIEM comes into play. Now, if you have a very good coverage with these specialized tools, you might not need SIEM there either. Because that tool is like StationGuard, if they have the coverage, if you deploy them with sufficient coverage, they will detect these anomalies and you just need to react to the alerts raised by StationGuard. So now you can converge your OT monitoring and your IT monitoring because I'm just assuming most people, if they have an OT environment, they will also have an IT environment. And ideally, you probably want to converge the security and the incident response parts of both because if the OT is affected, the IT will as well. But we will cover this a bit more in your second point, where we include engineers in incident response. 

So, if you have this converged monitoring, and let's say you don't have a SIEM, but you have some form of source solutions, so security orchestration, automation, and response. Fancy, fancy terms I know, but essentially something where all the alerts come together and where you can have automations to enrich detections, to pull in additional information, pull in more context and then trigger responsive actions. And you can have all this conversion there and work from there. And you might not need a SIEM. Of course, if you have, log data, if there's some things that you can only detect via log data and you want that, you need that, then you will need some form of SIEM solution as well. However, this will probably also just raise alerts, right, detections, and then these also get typed into a SOAR solution, at least if you have a SOC that is built with a modern tool stack. 

Simon: And what you also do is you have runbooks and then there is stated how these alerts are handled and what are the steps to basically get to know if it's false positive, true positive or true negative.

Johann: Essentially whether it's something that is benign behavior, expected behavior, whether it's something that you can tune going forward, or whether it's something that you need to take a deeper look at. Yeah, exactly. So, this, for your first point, yes, you will have some solution where all this data converges, comes together, and then you can have a look at all of this together. Because if you just look at the solutions independently,

Let's say you might have a detection in some log data, and you might also have some anomaly in your network data. If you look at those independently, you might in both cases decide, all right, it's a strange behavior, but honestly, I can find any indicator of maliciousness. But if you look at both together, you might see a bigger picture. Obviously, the more data you have, the more things come together in your centralized source solution the more context you can establish about certain alerts, the more correlation.

Simon: That is also the reason why good asset management or complete asset management is also important for the security operations center. Because they check the device type or the manufacturer and so on and look if the behavior that the SOC has seen is in according to what is expected. So, if you don't know what kind of device it is, you can't really do that correlation.

Johann: Exactly. Or if you say you have data on what is happening on the device and you have login data of certain users, then you could correlate that and you could see that a certain account was used to alter behavior. And if you can then see that this person is an engineer who's actively working with this asset and he's made other benign changes, I don't know, five minutes ago on a different system within the same subnet or substation or whatever you're dealing with, you can build context from that. Whether if this is a user who is barely active at all, or is an emergency user or something, it shouldn't really be used if you have that information. And this emergency user is currently changing variables somewhere. And this is something that will probably raise alarm bells, right? So, the more context you have, more complete your asset management is, as you've mentioned, the better.

Simon: It's also about context in the terms of “Is there maintenance going on?” Is this normal maintenance? Is there like a bigger maintenance window where external contractors are in here? So, we can dump it down to context is key and the more context you have the better informed your decisions are. So, the source is the SIEM in our world at least still until the foreseeable future, I guess. But we both know this can happen sooner than the technologies change. 

So, what is the first thing you do when you see something malicious? So, for me, in the past it was also getting the context first and then setting up a timeline.

Johann: Yeah, basically that is what you're trying to do. So, this is because at the very beginning, you've asked me about the difference between detection identification. And this is where you could make this distinction right now. Now you have some behavior that you consider to be suspicious, that you consider worth checking out at least. Now you get your context, you get the information on what asset is affected, you get information on the user accounts, potential maintenance windows, whatever. And you're still convinced, or you believe, right, this is... You might not know it's actively malicious, but it's still very, very suspicious, even with all this context included. So, then you begin a deeper analysis. Building a timeline is just what you do. Because building a timeline will give you more context, namely more context on the behavior itself of the potential attack. So, you establish what happened, at what point in time, on which system, under which user account, with what, if you're especially talking about network traffic, what sources and destinations were involved, and you just try to represent the attack, or at least the potential attack, as clearly as possible and as structured as possible. So, you have this timeline at the end and simply having this timeline as complete as possible and being able to tell what happened at what point in time that will allow you to then react to them draw conclusions and potentially react to the incident.

Simon: So, you're painting a picture of what the attacker did and depending on how clear the picture is you have a clear idea of the steps they took.

Johann: The steps they've taken so far and of what steps they could take next.

Simon: Exactly, that's the point. And if you know what they did or what they're trying to do, then you can act accordingly. But this is something for a later episode where we go for Remediation. At this point, we are still at detecting identification. I know your specialty is forensics. It's part of my hobbies, forensic challenges and so on. But let's get back to the identification part.

In OT environments in the energy sector, we are really blessed with 61850 and 104, which is why we have very static and well-defined environments, especially in 61850, the aforementioned project file. You have every signal listed down, you have everything defined, there is no uncertainties. This is a big plus in our energy sector compared to, for example, manufacturing or pulp and paper or chemistry and so on. Building automation, very big horror of mine, building automation processes in the past. But let's get back to the context. I've been working in OT for quite a couple of years now. You're more of a general IT guy that had his fair share of OT experience. I would say we are both not as experienced in real substation communication as for example a protection engineer. You said before that you go with your findings to the engineers and ask them for their opinion. Also, in my experience this is something that is important to see or to look at security as a team sport.

Johann: Oh, absolutely. This is true everywhere, also in the IT world, but especially in the OT world, because like eventually it's most people who work in information security, they have an IT background. I have an IT background. You've been working OT for a while, but you originally from IT as well. Most of us know IT much better than we know OT. And so, even in an IT world, it's important to talk with the operations teams to realize what is, what is truly going on. Because at the end of the day, it's the operations teams who maintain the infrastructure, who must, yeah, exactly. And this is even more relevant in an OT world where my knowledge of how things work…

Simon: And to know their systems inside and out.

Johann…is less pronounced than it is in the IT world. I'm very much... Almost every IT security guy will be very much dependent on the OT engineers, on the people working with the actual, maintaining the OT to truly identify threats. And for every step that comes after that, like especially once you get into containment and recovery, you are dependent on the people to implement these things, because I wouldn't know how to do that. Sure, I could probably hack something together, but I wouldn't trust critical infrastructure with a quick hack I've just built somewhere. Yeah, so you're dependent, and it is absolutely a team sport from the very first step to the very last. And this starts before the identification. This starts with what are we actually defending? Now we're back to…

Simon: Hahaha.

Johann: Like I said, this is something that I repeat pretty much every time I talk. You cannot protect what you cannot defend. And you need, even that is a team sport because only the people that actually maintain the technology will be able to tell you how it works and what it does.

Simon: And they will also notice if something's off or something's different.

Johann: Yeah, yeah, they will help you build detection rules and build mechanisms to detect anomalous behavior because they, like you said, know what's normal. So, they will also know what's not normal. And once you find something suspicious, they will very quickly be able to tell you, yeah, that was me or that was my colleague or that was because of this and that or, right, I also have no idea why this happened. This is not good. We need to take a deeper look.

Simon: This is something funny for me because I've been preaching the same thing for at least five years now. the one thing that we always admit is that our security quote unquote is not perfect. So, attackers need to get it right only one time. We need to get it right every time. This is not really something that is possible. So, defense in depth, so having more layers of security. And the last layer of security is our engineers in the fields. The last layer of security is our listeners. All the protection engineers, secondary, primary... So, you guys out there who are listening to this, you are our last line of defense, so to say. It sounds a little bit, yeah, little bit cheeky, but that's how it is.

Johann: No, absolutely. It's not just the last line of defense. You also are the people who need to rebuild later and who are the only ones who can rebuild later. So, yeah.

Simon: I tried once to build a 61850 substation and I failed miserably. Fortunately, I have some capable colleagues at OMICRON who are 61850 experts. With that said, thanks, Jonny, for talking to me. It was really a pleasure to talk to you once again after so many years not seeing each other.

Johann: Yeah, it's been fun. Thank you very much for having me.

Simon: And with that, our next episode in this Cybersecurity Incident Response Mini-Series will explore the important following steps in the incident response process called Containment Eradication and Recovery. And with that I am handing the microphone back to Scott.

Scott: Thank you, Simon, for hosting this and upcoming episodes of your new Energy Talks podcast miniseries titled, Why Should You Talk about Incident Response? We look forward to listening to further discussions about this important area of cybersecurity.

And to our audience, a big thank you for listening to this and other episodes of Energy Talks! We always welcome your questions and feedback. Please send us an email to podcast@omicronenergy.com.

OMICRON has several years of experience in power system testing, data management, and cybersecurity and offers the matching solution for your application. For more information, please visit our website at omicronenergy.com.

Please join us for the next episode of Energy Talks and stay tuned for feature episodes of our new Mini-Series titled, Why Should You Talk about Incident Response, with Simon Rommer.  

Goodbye for now, everyone!