Navigating
Cybersecurity

In this episode, hosted by OMICRON cybersecurity consultant Simon Rommer, we explore the critical roles of IT and OT in power systems cybersecurity, focusing on security risk assessments from a design and construction perspective. Jose Paredes, Regional Engineering Manager at H&MV Engineering, discusses the importance of bridging the knowledge gap between IoT and electrical engineering, as well as the necessity of integrating cybersecurity into the design process from the outset. 

The conversation highlights the challenges of managing client expectations, compliance, and procurement in the context of cybersecurity, as well as the impact of latency on project success.  Jose emphasizes the need for effective partnerships and thorough risk assessments to navigate the complexities of cybersecurity in power systems.

Scott: Hello everyone, my name is Scott Williams from the podcast team at OMICRON. This episode covers another interesting topic about cybersecurity and focuses on security risk assessments performed during construction projects in the energy sector. Your host for this episode is Simon Rommer, who is an OT security consultant in the OMICRON Power Utility Communications team. Simon asks his guests questions about the recommended security risk assessments and whether they are advisable in the early design phases of construction projects. So, without further delay, I hand over the microphone to Simon. Hi, Simon.

Simon: Thank you, Scott. I welcome our listeners to this new episode of our podcast, where we explore the critical roles of IT and OT in power systems cybersecurity. We are going to talk about security risk assessments from a design and construction point of view. 

For this, my guest is Jose Paredes, who is a regional engineering manager at H&MV Engineering. H&MV Engineering is a global leader in high voltage design, engineering, and construction services. We will talk about Jose's experience as an engineering manager and how he sees the key steps of a successful project with all security-related engineering requirements fulfilled.

Jose: Hi Simon, thank you for having me.

Simon: First of all, how was the development during the last few years, and what made you want to talk about this topic?

Jose: First of all, there's the knowledge gap. That's the knowledge gap we have between the IoT and the electrical engineering part. That causes a lot of issues in the beginning. I started this journey more than three years ago. We, as a company, we're always trying to design our systems in a secure manner. But with the implementation of all the new cybersecurity rules we have to comply with in Europe and in the UK in particular — that is the region I am in charge of — we have to step up. Thus, I've been along this journey with the company and the different other clients to see how they're going to implement all these new rules.

Simon: So, you say that it's externally motivated, and basically your customers — if you want to say it that way — they force you to have cybersecurity as part of your services. I'm sure that the NIS and the upcoming NIS2 are big parts of that as well.

Jose: Yes, it all depends on the client requirements as well. The way it works in our company is — we basically are tendering constantly to different types of projects around the whole Europe and different regions because we have work in the Middle East, the UK, and Ireland, and where our offices are based. But it's all depending on the client requirement. And we noticed in the previous years that client requirements are asking more and more about cybersecurity in particular. 

This particular case I brought to you kicked off my own learning: it was a project in the UK, and they had very demanding cybersecurity requirements. Even though it doesn't require us to be compliant or produce a compliant design, it requires us to follow 62443 guidelines and do good practices. Also, the UK has a different documentation that we have to use as a standard design. But that's basically what it means. This is what the client wants, and our company is client-driven, client-first, and we try to fulfill what the clients want from us. 

Simon: So, this sounds like it was very complicated in the beginning because you said you are responsible for the UK and you have your own legislature, and then there are parts of your company that work in the Middle East where there is a different legislature. I'm sure internationally it diverges quite a bit from the NIS. But I think one of the major points is always the 62443. It's a staple in our industry.

Jose: Yes, what I've seen is every region has its own rules. Even though we all enter a European zone, every country has its own rules. Every project needs to follow them. I particularly deal with the UK, but Ireland has its own, Germany has its own, Scandinavia has its own. And we are noticing that every country is at a different level of this journey. Countries like the UK are very far ahead, as I might say. Germany, of course, like always, is at the forefront of this stuff with key trees and the type of stuff. 

But it is, like you said, everyone now has to comply with NIS2 in Europe. And, for example, I have other projects that also have to comply with American standards because the products they are installing are American and have to comply with NIST. That is another sort of rule. 

Yeah, and part of when we get the projects, we start reading through the ER. We need to check what requirements we need to comply with. As a company, we're kind of developing a whole set of procedures — or we have developed a set of procedures — to deal with all these eventualities. And it all depends. Some clients don't want this or that. Some clients are very advanced. Some clients handle the cybersecurity themselves. They put panels — that they call them... they can have whatever name, but for the purpose of this discussion, let's call them enterprise cabinets — that they put on our site, and they handle all the DMZ zones and the server security themselves. Other clients, like the one we're going to discuss a little later, basically they quote H&MV to produce that for them. 

That's something, like I say, we are client-driven. We just went through this journey. Exactly. We do it. Yeah. And that's usually how it works for most of our projects. And that's the way we have gone into.

Simon: If the client wants it, we can get it.

Jose: Into battery storage systems, solar systems, wind farms, and data centers. So, we have a big range of all different types of projects we deal with.

Simon: So yeah, your mentality is like, say yes first and ask questions later, I guess.

Jose: Well, I wouldn't say it like that. We do have certain rules on products we don't engage with. For example, power plant control of battery storage and solar parks — we don't, that's not our facility. We depend on specialist companies to do that on our behalf. As a company, we have learned that it's so difficult to do that we particularly don't want to. But, you know, if a client wants it, and sometimes clients tell us, “No, you have to take everything if you want this project.” And then we as a company, as a business, decide to go ahead with the project, take the risk, and figure it out as we go. And that's the only way you get into the forefront of stuff.

Simon: We both know that good partners are very valuable in this case. So, if you have a tender where you don't have all the expertise in-house, a good partner is always valuable. You mentioned requirements, but what experience do you have with security requirements during construction projects? You also mentioned that it's getting more and more because of regulations and requirements from the customers. So how do you see this topic?

Jose: Well, like I mentioned in the beginning, it's that gap. It's the gap between the IoT world and the electrical engineering world that is the most difficult part we have encountered. For example, an electrical commission engineer might know how to program a relay, but they won't know about the protocols to be used. They might know what a 61A50 is because that's a protocol we use in this industry, but they might not know what the data center uses, like MQTT and those types of things. And that is the knowledge gap. 

There are also a lot of new elements moving into virtualization now, server-based protection, and service-based security. And that gap, how to deal with those IoT devices, is one of the main hurdles we are encountering at this point. And also, the standards have not been working together. For example, we work in the protection and control work — they have their own set of rules, own set of protocols, their own ways to do things. And the IoT world has its own. 

At the moment, we have a discrepancy between both. If you have a network, you have to protect it, you have to encrypt it, you have to do certain things that are not compatible with the protection and control work. To put it this way: a specific example, if you want to know, is 62443 asks to encrypt all the networks in a system. As you get into what is 61850 — that is the protocol used for the control and protection system, relays — that network should not be encrypted because that will cause delays and increase latency. Remember, we're talking about very fast-acting devices, sometimes called real-time networks. So, it is not advisable. It's possible, but not advisable. 

So that's, for example, one case where the standards clash with each other, because how do you comply with a requirement when you're trying to achieve compliance and doing your risk assessment? That's a risk — it will be identified — you cannot encrypt this. And then how do you do it? At the end, you can't. You have to mitigate the risk and acknowledge the risk and put it into the recent risk assessment.

Simon: So, basically, even standards themselves sometimes conflict, and you have to make a trade-off or mitigation. That’s a challenge in itself.

Jose: Exactly. That’s the reality of our projects. We have to identify the risks, then provide mitigation or documentation showing why a certain requirement cannot be applied because of latency or safety reasons. And that’s accepted by most clients as long as it’s well documented.

Simon: So, it's basically an involuntary mandated patch window or maintenance window if you want to say it like this.

Marie: Yeah, think of it as an opportunity. Yeah, see the chance to do the things that the work that you maybe have put off for way too long and you see the nature.

Simon: Hahaha. Especially in our industry, nothing is as permanent as a temporary solution. So maybe seize the chance as you said. But we also said, so we are one part of many voices or one part of the bigger team. We talked about the crisis board already in the last episode, we described the crisis board a little bit, what its roles are. But what is happening with the crisis board? Are they instantly dismissed? Is everybody going back to their daily business?

Marie: Yeah, so I think it's important to not only think about tools and technical systems here. I think you have to also think about the people that's been involved in incident response. They've been working overtime. They've been dealing with this cyber crisis for a while. They might be exhausted. They might even be a little bit traumatized and they will also need some type of closure to move on from the incident. So a good after action process should have a debrief. It should have a lessons learned or lessons identified first and then lessons learned, which is really important. And that should be documented. It should be followed up on so that you can then improve your, your incident response processes for future crisis.

Simon: So, you already talked about the topics that we need to discuss, but this is just the preparation for the next incident, right? Because there is just two types of companies, I like to say, is like ones that have been breached and ones that just didn't know yet. And if we look at the incident response process, the process is never ending, right? So it just feeds in back to the start. We talked about preparation for almost all the episodes. It's basically if you prepared well enough then the processes can go smoothly. So what you say is also that the last step is just preparation for the next incident, right?

Marie: Yeah, that's correct.

Simon: So is there some special processes that need to be discussed or need to be reviewed or how would you go about it in a real-life scenario? is there like a retrospective or are you collecting thoughts via email or how would you do that in a real-life scenario?

Marie: Yeah, you would, you would carry out an after action debrief retrospective or whatever you want to call it, a hot wash up maybe some kind of a process where you go through what went great during this incident response, what did not go so well, any gaps and so on. And you should use the outcome of this to improve upon your existing incident response plans, procedures. And you might have even detected that you're lacking some of those processes. So typical documents that you should review is the incident response plan, your business continuity plan, your communication plan, and maybe also your crisis management plan if the incident was escalated to a real crisis. And these should all be reviewed and updated based on your findings in that after action debrief.

Simon: That makes sense. You mentioned the design phase earlier. How early in a construction project do you typically get involved with these security requirements?

Jose: Ideally, as early as possible. The earlier you get involved, the better. It allows us to influence the architecture and the selection of devices. But in reality, sometimes we’re only brought in after the initial design is completed. That’s challenging because we then have to retrofit security measures, which is more costly and complicated.

Simon: So, early involvement is key. Is that something you actively push for with your clients?

Jose: Yes. We always recommend a security workshop during the early design phase. It helps align expectations, identify critical assets, and define the scope for the risk assessment. Once the client sees the value, they are usually more open to our involvement early on.

Simon: That seems very practical. Can you give an example of a security risk assessment you performed on a recent project?

Jose: Sure. One of our recent projects was a substation expansion in the UK. The client requested full compliance with 62443 for the new relays and control systems. We performed a comprehensive risk assessment, including network segmentation, access control, and protocol security. During the assessment, we discovered that some older devices could not support encrypted communication. We documented this risk and suggested compensating controls, like strict access policies and monitoring via IDS. The client accepted our recommendations, and the project went ahead without compromising operational safety.

Simon: So, your assessment not only identifies the risk but also provides practical mitigation strategies.

Jose: Exactly. It’s not about ticking a box; it’s about understanding the real-world implications of implementing security measures. Sometimes, the ideal security solution is not feasible in an operational environment. The goal is to reduce risk as much as possible without impacting functionality.

Simon: And how do you document and communicate these risks to the client?

Jose: We produce a detailed risk assessment report. It includes identified threats, affected assets, impact levels, likelihood, and recommended mitigations. We also include a risk matrix and prioritization for the client. During a review meeting, we walk the client through the findings and discuss trade-offs, so they understand both the risks and the reasoning behind our recommendations.

Simon: That sounds very thorough. And how do you see the trend for security requirements in construction projects moving forward?

Jose: I think the trend is definitely toward more regulation and standardization. Clients are becoming more aware of cybersecurity and expecting compliance with international standards. Also, with NIS2 in Europe, there’s going to be more mandatory requirements. So, engineers like us will need to integrate security considerations from day one of any project.

Simon: Absolutely. The early integration not only helps with compliance but also reduces costs and operational risks.

Jose: Exactly. Retrofitting security is expensive and sometimes even impossible without affecting operations. By addressing it early, we can design systems that are secure by default, which is better for everyone.

Simon: Thank you, Jose. This has been really insightful. Is there anything you would like to add before we close?

Jose: Just that security is a team effort. It requires collaboration between clients, engineers, and cybersecurity specialists. No one can do it alone. The more we work together early in the project, the more resilient our systems will be.

Simon: Perfect. Thank you for sharing your experiences and insights.

Jose: Thank you, Simon. It was a pleasure.

Simon: Now, back to you, Scott!

Scott: Thank you both. That concludes today’s episode on security risk assessments in construction projects. We hope our listeners found this discussion helpful. Stay tuned for our next episode, where we will cover another critical topic in the power systems cybersecurity space.