Podcast Episode with
Simon Rommer
In this episode of Energy Talks, OMICRON Cybersecurity Expert Simon Rommer launches an essential new mini-series focused on operational technology (OT) cybersecurity countermeasures in the power industry. Instead of just chasing the latest tech trends or treating security like a generic checklist, this series takes a step back to ask a fundamental question: Countermeasures - what for, and against what?
“A countermeasure is not valuable simply because it's considered good practice. It is valuable because it reduces a specific risk, addresses a specific weakness or improves resilience against one or more credible threat scenarios.”
Listen
to the podcast episode on Spotify and Apple Podcasts – or directly on OMICRON Energy:
Listen to the EpisodeWhy Effective OT Security Starts with
Risk, Maturity, and Operational Reality
In OT cybersecurity regulatory requirements are increasingly an important driver for investment. This is a positive development, but it can also encourage a checklist mentality: Which measures do we need to implement to demonstrate compliance? In my view, that question comes too early. Before choosing a countermeasure, we should first understand which risk it is intended to reduce and whether it can achieve that objective in the respective operational environment.
A countermeasure is not valuable because it is widely recommended or technically impressive. It is valuable because it reduces a specific risk, addresses a weakness, or improves resilience against a credible threat scenario.
This distinction is especially important in power system environments. Security controls must coexist with availability, reliability, maintainability, and most of all operational safety. They also have to work with long asset lifecycles, restricted maintenance windows, and systems that were not designed for modern authentication or logging. The correct question is therefore not simply, “Which control should we implement?” It is, “What are we protecting, against what, and under which operational conditions?”
The Fundamentals Are Not Outdated
Many of the most effective countermeasures are not new. Network segmentation, asset management, secure remote access, identity management, change management, backup, and recovery have been recommended for years. Their familiarity can make them seem less interesting than advanced analytics or automated detection. Yet attacks and operational disruptions still exploit basic controls that are missing, incomplete, poorly maintained, or disconnected from supporting processes.
What I consider particularly important is that security controls do not exist independently of one another. Their effectiveness depends on the maturity of the environment around them. Monitoring depends on reliable asset knowledge, useful data sources, and an understanding of normal communications. Fine-grained segmentation depends on visibility into required data flows and a disciplined process for approving changes. Advanced access management depends on systems that support individual identities, role separation, and appropriate authentication. If these prerequisites are absent, adding a sophisticated system may increase complexity without producing the intended reduction of risk.
Segmentation, monitoring, and asset knowledge illustrate these dependencies particularly well.
🟪 Segmentation Must Reflect the Actual System
Segmentation is a good example. It is often presented as a fundamental OT security measure, but simply separating networks does not automatically reduce risk. The objective is not segmentation itself, but to control which systems can communicate, constrain potential attack paths, and limit the impact when something goes wrong. To achieve this, segmentation must reflect the actual system architecture, communication dependencies, operational processes, and credible attack paths. If zones and conduits are poorly designed, undocumented, or not consistently enforced, segmentation may create a false sense of security while introducing operational complexity.
🟪 Monitoring Should Create Useful Visibility
Security monitoring has a similarly broad role in OT. From my perspective, its value should not be measured by the number of alerts it generates, but by whether the resulting information helps the responsible teams understand what is happening and decide what to do next. The same visibility can reveal misconfigurations, unexpected communication patterns, and abnormal device behavior. In operational environments, cybersecurity monitoring and functional monitoring can reinforce each other, provided responsibilities and escalation paths are clear.
🟪 Asset Knowledge Supports More Than Security
Accurate knowledge of assets and configurations is the third foundation. It supports vulnerability management, incident response, change management, recovery, and monitoring. Asset inventory is often reduced to the phrase, “You cannot protect what you do not know.” I would go further: you cannot reliably operate, recover, or improve what the organization has not documented and assigned to an owner. Knowledge that exists only in the heads of experienced employees is not a sustainable way to operate a station, and even less so a working security control.
These three examples also show why I would be cautious about assessing countermeasures in isolation. A technically capable solution can still provide limited value if the information, processes, or responsibilities it depends on are missing.
Compliance and Security Should
Reinforce Each Other
The motivation behind a countermeasure often shapes its implementation. If the primary goal is compliance, the discussion can narrow to whether a requirement is formally fulfilled. If the goal is to reduce an operational risk, the focus shifts to effectiveness: does the measure prevent, detect, contain, or support recovery from the scenario that justified it?
Utilities need both perspectives. Standards and regulatory requirements provide a valuable catalogue of expected capabilities and a common baseline. Risk assessment should then determine where those capabilities create the greatest operational benefit and where additional measures are needed. Compliance can define the minimum, but it should not become the endpoint.
I therefore see compliance as an essential baseline rather than the endpoint of an OT security program. A control that exists on paper and cannot be operated, tested, or maintained creates assurance without equivalent protection.
Match Security Controls to OT Maturity
When discussing security controls, I find it useful to distinguish between three broad maturity levels. These are not intended as another formal maturity model, but as a practical way to consider whether an organization has the foundations needed for a particular measure to deliver the expected value.
🟪 At a beginner level
The priority is visibility, ownership, and basic control: knowing which assets exist, who owns them, who has access, which communication paths matter, and whether current backups and documentation are available.
🟪 At a moderate level
The objective is repeatability and manageability. Typical capabilities include structured access management, zones and conduits, defined change management, security monitoring, periodic reviews, and formal incident response procedures.
🟪 At an advanced level
The focus moves to optimization, validation, and resilience through advanced detection, continuous configuration verification, fine-grained privilege management, exercises, recovery testing, and measurement of control effectiveness.
These levels are not a ranking of good and bad organizations. They help identify dependencies. More advanced controls can be introduced earlier when they directly strengthen a missing foundation, but their expected value should be realistic. The question is therefore not whether an advanced security control is inherently better than a basic one, but whether it addresses a relevant risk and whether the organization has the prerequisites to operate it effectively. The goal is not to collect capabilities. It is to build a coherent system of controls that the organization can sustain.
A Six-Question Framework for Every Countermeasure
The accompanying podcast episode introduces a common framework that we will use throughout the mini-series. By applying six simple questions, the discussion consistently shifts away from whether a particular countermeasure is considered state of the art and toward whether it actually contributes to reducing risk in the environment where it will be used. It also makes dependencies and limitations visible before an organization invests in a measure whose prerequisites may not yet be in place.
For each technical, organizational, or architectural measure, I propose asking the following six questions:
1. What risk does it address?
Define the threat scenario, weakness, or operational concern that the measure is intended to reduce.
2. What prerequisites are required?
Identify the technical, organizational, and procedural foundations without which the control cannot be effective.
3. What maturity level does it require?
Determine when the measure becomes useful and how it fits into the broader security journey.
4. What operational constraints apply?
Consider availability, reliability, maintainability, safety, legacy technology, maintenance windows, and engineering workflows.
5. How will effectiveness be measured?
Validate the control through testing, reviews, monitoring, audits, exercises, or operational metrics.
6. What residual risk remains?
Document assumptions, limitations, dependencies, and plausible bypass paths, then decide whether complementary measures are required.
The Right OT Security Controls
for the Right Risk
When I assess an OT security measure, I am therefore less interested in how advanced it sounds than in how well it fits the risk, the operational environment, and the organization that has to sustain it. A basic control that is understood, maintained, and regularly tested can contribute more to resilience than an advanced capability without the prerequisites needed to support it.
For me, effective OT cybersecurity is therefore not about implementing the greatest possible number of controls. It is about understanding the risks that actually matter and implementing the right controls, in the right sequence, under the operational conditions in which they ultimately have to work.
Listen
to the podcast episode on Spotify and Apple Podcasts – or directly on OMICRON Energy:
Visit OMICRON EnergyResources
