Five industrial network security mistakes to avoid

There is increasing pressure on companies to integrate operational technology (OT), such as manufacturing plants, power stations, and logistics hubs, with corporate IT networks. Real-time data on the shop floor can lead to better decisions, quicker maintenance cycles and leaner operation. However, the security risk is also very real and often underestimated.

OT networks, unlike IT environments, were designed to be available and deterministic, not for confidentiality. It is not the case that updating a laptop or a PLC during a shift. Downtime is measured by tonnes and not by help desk tickets. This makes OT environments more difficult to secure and explains why they are increasingly targeted by threat actors.

Five mistakes are repeated in industrial environments where there have been breaches or near misses. It is not necessary to replace all the assets on the floor in order to avoid these mistakes. This requires deliberate architectural choices where OT data crosses over into the IT domain.

1. Running industrial protocols with no encryption or authentication

Modbus and DNP3 as well as older versions of OPC DA, were all designed at a time when air-gapping security was assumed. They do not have native authentication, and they transmit data in plaintext. Once a network has been connected to corporate infrastructure, or even indirectly the cloud, these properties are liabilities.

By using OPC UA, both issues are resolved. OPC UA provides certificate-based Authentication and TLS-encrypted Sessions at the protocol layer, without requiring workarounds on the application level. Environments that use legacy protocols for connected segments, without compensating controls, are taking a well-documented risk.

The industrial connectivity platforms are crucial in this regard. A server that is configured properly sits in between field devices, and the IT network. This server converts legacy protocols to authenticated, encrypted sessions, before data leaves OT. One of the most important security decisions that an OT engineer will make is to select and harden this layer. Kepware It is one of the most commonly deployed platforms for this purpose, and its configuration – particularly in relation to OPC UA security and user authentication – deserves the same scrutiny that any network appliance.

2. Flat networks without segmentation between OT Zones

In a flat OT network, any device capable of communicating with a single asset is able to communicate with them all. This architecture is what allowed the Oldsmar water-treatment incident of 2021 to progress as far as they did: An attacker with access on one workstation could reach the SCADA interface that controlled chemical dosing.

Purdue Model, IEC 62443 and IEC 62443 both recommend segmenting OT Networks into zones based on their criticality and functions with conduits controlling the traffic between them. In practice this would mean industrial DMZs or firewalls separating the Level 1 devices (field devices) from the Level 2 supervisory control and Level 3 operations management, with explicit whitelistings of communication paths that are allowed.

Segmentation does not happen in a single project. Each new data flow, such as cloud telemetry or remote access by vendors, represents a conduit that needs to be evaluated and controlled.

3. The vendor remote access is left permanently open

Many industrial installations have been commissioned with remote access always on configured for the OEM. RDP was enabled on engineering workstations or jump servers were configured with credentials shared by all users.

This is the most common way to gain access in OT incidents. If a maintenance route is open at an address that can be accessed by the public, attackers don’t need to compromise a plant network.

The pattern for corrective action is well established. Replace permanent connectivity with time-limited, session-initiated access. Solutions that use encrypted tunnels and are broker-mediated, requiring explicit approval of each session to proceed, reduce the risk while maintaining vendor support. The use of multi-factor authentication for all remote access pathways to OT systems cannot be negotiable.

4. No asset inventory means no baseline for anomaly detection

It is not possible to detect abnormal behaviour in a network if you do not have a complete inventory. Many OT environments do not have a complete, current inventory of all connected assets. This is partly due to the fact that devices are added over time, partially because legacy controllers don’t respond to standard discovery probes and partly because this task is viewed as a one-time exercise, rather than a continual process.

Intrusion detection systems are useless without a baseline. A tool that is unfamiliar with normal operations will not be able to distinguish traffic that appears unusual to an analyst.

Asset inventories can be created automatically by passive network monitoring tools for OT. These are the ones that monitor traffic without generating queries which could disrupt sensitive controllers. Platforms such Claroty Networks and Dragos have been designed for precisely this. This is a valuable asset for both security and compliance: the NIS2 mandates that organisations classified as important or essential entities maintain documented risk assessment of their OT environment. If you’re unsure if your organization is included in the scope of NIS2, please consult the NIS2 OT Security Check The assessment of your classification and preparedness can be done in a structured way.

5. Do not treat OT security as a separate IT responsibility

Organisational mistakes are more common than technical ones. IT security teams are familiar with firewalls, endpoint detectors, and identity management. They do not usually understand the operational limitations of a DCS or the implications of the watchdog timeout for a safety instrumented system.

If OT security is left to the IT security team, it can lead to either ineffective controls or a stalemate, where nothing gets done because neither the IT team nor the OT team has the authority to take action without OT approval.

A joint model is required for effective OT security: IT security provides the threat intelligence, tools, and governance frameworks, while OT engineering contributes process knowledge, safety concerns, and the authority to make changes in the field. The programme must have a named person who is at the intersection between both functions. It also needs executive sponsorship to treat OT security more as a matter of business continuity than a project.

Start here

Organizations that do not have a formal OT Security Programme rarely need to tackle all five areas at once. An effective starting point would be a network review. Map what’s connected, identify the points where OT traffic crosses over into IT infrastructure or cloud infrastructure and assess security posture at those crossing points.

Almost always, the connectivity layer – the servers and gateways which aggregate data from the field and send it north – is the most important. In most industrial environments, the biggest attack surface comes from the connectivity layer. This is where authentication and encryption protocols are enforced, as well as a segmentation of the network between the field and IT networks.

The remaining items – vendor access controls (including asset inventory), anomaly detection and governance structure – can be implemented over a period of six to 12 months, without any production downtime.