NIS2 meets store floor

The requirements of NIS2 are high: it requires companies to define and implement state-of-the-art measures that correspond to their specific risk and the potential impact of an incident. By combining technology, operations and organization, they must be strategic in nature.

The NIS2 directive covers all threats, including cyberattacks as well as operating errors, physical malfunctions or operational errors, as soon as they can have an impact on IT or OT systems. This results in very specific tasks: Companies need to know their assets and architecture, identify incidents and mitigate them quickly. They must ensure operational continuity, evaluate their supply chains with regard to security aspects, procure and maintain systems securely, prove the effectiveness of their security measures and establish "basic hygiene". NIS2 does not specify what this means in detail. In addition to NIS2, there may be new sector-specific requirements. It is therefore crucial that a security program remains adaptive.

Strengthening the company's back

No tool can replace governance, but suitable OT tools can provide companies with operational support and evidence of the implementation of security measures. Two examples show why IEC 62443-2-1 is safety-relevant and concrete.

Example 1: A seemingly harmless change

A typical incident begins harmlessly: a service provider quickly changes a VLAN or port profile outside the change window. This goes unnoticed because the line continues to run. But suddenly, unwanted connections are created between zones, for example between the office network and the control network or between the safety segment and IACS (Industrial Automation and Control Systems). A good CM setup, as described in IEC 62443-2-1, recognizes the deviation, compares it with a baseline and displays the difference in a comprehensible manner. Versioned config back-ups accelerate the return to the released state without technicians having to take action "by feel" in the event of a fault. This technology does not replace a change board, but it prevents security gaps in the process from leading to unnoticed technical risks.

Example 2: An unknown device on a port

An unknown device is suddenly connected to a switch port in production. At this moment, context counts: in which zone is the port located, which conduits connect it to other areas and which systems can the device potentially reach? Is it a safety zone with safety-related functions, a control zone with a direct influence on the process or just a less critical area? The answer determines whether there is a risk of production downtime, danger to persons or only a limited operational risk.

A NET program in accordance with IEC 62443-2-1 ensures that these relationships are structured in advance. It requires documented zones and conduits, clearly defined responsibilities for network areas, regulated change processes for network configurations and monitored transitions between zones. Monitoring systems support this transparency by making new devices, topology changes or firmware deviations immediately visible and documenting events in a traceable manner. On this basis, prepared technical measures can be implemented in a targeted manner and decisions can be made based on defined responsibilities.

The path to auditability

For audits, it is irrelevant whether a specific tool is used. Rather, it is crucial that all operational requirements are met. This includes, for example, inventory reports with a documented topology, event logs or evidence of recoveries, config back-ups including history, traceable changes, transparent firmware versions and fully traceable technical countermeasures. At the same time, companies must provide evidence of organizational aspects such as guidelines and roles, escalation paths, training and supplier specifications, as well as a risk logic that explains why controls were chosen in the way they were. This is where the "operational evidence" versus "organizational evidence" distinction from everyday OT helps. OT-oriented network management solutions, such as Moxa's MXview One software, collect operational evidence, while governance artifacts are compiled in management and quality processes.

Three steps that have an immediate effect

But what is the best way for companies to achieve this? A first step is to align risks with their impact: Which systems and dependencies would hit production, safety or delivery capability the hardest in the event of an incident? In the next step, it is worth using IEC 62443-2-1 as a kind of map and strengthening the operational heavyweights first. This usually includes the asset inventory, change control, monitoring/alarming and back-up/recovery. Finally, every plant needs a logic of proof that matches the risk: Which reports, logs and protocols occupy CM, Event, Avail, which documents occupy Org, User, Comp, Net And Data? If you combine these two levels, NIS2 becomes less abstract and ensures auditable compliance on the store floor.

Compliance is not a product that is installed, but a program that must be developed and implemented. NIS2 sets the framework of expectations, IEC 62443-2-1 organizes the implementation, and a disciplined OT operating model turns it into practice - in everyday life and in audits.

Laurent Liou, Product Marketing Manager, Moxa Europe