Field devices is a generic term used for sensors and actuators in industrial automation technology. Generally speaking, a field device is a type of equipment used for measuring and controlling the industrial process and other similar equipment.

Sensors transform the physical parameters of a process into standardized signals (analog, discrete, digital, etc.) and relay data to the SCADA host software through a local PLC or RTU, where the data can be normalized or scaled.

Most control field devices, such as valves, pumps, etc., have been fitted with actuators, enabling a PLC or RTU to control the device. Actuators allow the control system to optimize production or react quickly to abnormal events, such as shutting down the system in case of a hazard.

Early Programmable Logic Controllers (PLC) and Remote Telemetry Units (RTU) had distinct differences in design, but nowadays, their functionality overlaps.

PLCs are industrial controllers used to operate different electro-mechanical processes. They use communication protocols to interact with SCADA/HMI systems or other controllers and cyclically execute internal logic to control process equipment (valves, pumps, etc.) according to digital/analog inputs.

RTUs are microprocessor-based devices that interact with physical objects and a SCADA system by transmitting telemetry data and altering connected objects' states. They are an interface between the field sensors, actuators, and a SCADA central control unit.

RTUs are far more durable, resistant to harsh environments, and offer more comprehensive communication functionality, making them more effective for geographically distributed telemetry applications. PLCs, on the other hand, are better suited for local control.

Some PLC and industrial automation hardware manufacturers include Siemens, Rockwell Automation/Allen Bradley, Schneider Electric, ABB, Honeywell, Emerson, Phoenix Contact, Mitsubishi Electric, Beckhoff, Omron, and B&R.

We live in a world of interconnectivity where different devices are continuously interacting. The backbone of interconnectivity in the industrial world is complex industrial communication networks designed for real-time control and data integrity, allowing the transmission of large volumes of data with limited bandwidth in large plants and potentially harsh environments. These industrial control networks are necessary to relay data between the different levels of the ICS hierarchy, such as:

Incorporating Ethernet technology into industrial networking blurs the difference between industrial and commercial networks. However, the two have fundamentally different core requirements:

Since factory operations have become dependent on machine and production line data provided by automation systems, networking has become one of the core requirements of industrial systems.

Each level of a typical industrial network uses specialized communication protocols that provide a set of rules and syntax to standardize information exchange between transmitters and receivers. Some of these protocols may be proprietary or licensed.

Industrial protocols interconnect systems, interfaces, and instruments of an industrial control system in real-time. Many were initially developed for serial communications over RS-232/422/485 physical connections (Modbus RTU/ASCII, PROFIBUS, CAN, etc.) Various industry players designed these protocols, which eventually became standards. Some of them are still popular and widely used due to the long life cycle of industrial systems.

Once industrial Ethernet gained popularity and became a de facto standard in industrial networking, many industrial communication protocols were adapted to operate over Ethernet-based solutions. Industrial Ethernet is a cost-effective solution that supports higher speed, increased connection distance, and more nodes. As a result, they are now widely deployed over various common industrial network infrastructures.

Various vendors drive many different industrial Ethernet protocols. These protocols include PROFINET, Modbus TCP, DNP3, IEC 60870-5-104, IEC 61850, BACnet/IP, EtherNet/IP, etc.

SCADA is a multi-task software package based on a real-time database (RTDB) located on one or more servers.

Most SCADA systems support client-server architecture where each host can act as a server, a client, or both. Server processes are responsible for data acquisition and handling, such as plant equipment polling, alarm checking, calculations, logging, and archiving. It is also possible to have a dedicated server for each task.

The following is a list of possible server process types:

Clients provide the interface for evaluating and interacting with the system.

The most significant SCADA client is an HMI, i.e., operator interface. The HMI visualizes process data in mnemonic schemes, graphs, charts, or user-friendly digital dashboards. Operators leverage the HMI to view and manage alarms and perform sophisticated control.

Many vendors offer SCADA/HMI solutions, but the most significant players in this market are Siemens, Schneider Electric, AVEVA, Emerson, General Electric, ABB, YOKOGAWA, and Rockwell Automation.

Traditionally, ICS were isolated and did not necessarily need to connect to public networks. However, today’s business needs for remote control and supervision require industrial networks connected to the internet and other third-party networks. In addition, since adopting Ethernet as the de facto communication standard in industrial automation, industrial networks have become more sensitive to threats, bringing new OT security challenges. The result is that these systems are now affected by many of the same security vulnerabilities affecting traditional IT systems.

Industrial networks mainly focus on availability, real-time data transfer with low latency, and deterministic response times but lack security mechanisms. The closer you get to sensors and actuators, the less security-aware industrial networks are. Historically, ICS used proprietary communication protocols that did not implement security. However, even after adopting Fieldbus protocols for Ethernet-based communication, security is still lacking.

The criticality of processes controlled by ICS is a crucial difference from IT systems. Unexpected system behavior results in a disrupted process that can cause production losses and damaged equipment. For example, an attacker can compromise the process by changing setpoints, causing tanks to overfill, exceeding threshold temperatures, or damaging actuators by incorrect manipulation. In addition, an infiltrated industrial network can prevent personnel from accessing the process and controlling equipment, leading to severe repercussions.

The objective of industrial security is to fulfill three criteria:

In contrast, the IT domain focuses on data confidentiality, integrity, and availability.

Availability in the OT context is intertwined with safety. When industrial systems malfunction or are not available, it can jeopardize the environment and safety of personnel. Loss of availability for OT environments has more severe consequences than the loss of confidentiality. Any failure of the ISC directly affects the devices underneath, leading to extensive material loss, potential human loss, and even environmental disaster in some uncommon cases.

Confidentiality in the OT context is less critical because data is often raw and must be contextually analyzed before it has any value.

Most control systems based on SCADA or complete DCS and their components mostly comply with the ISA/IEC 62443-3.3 SR2.8 - Auditable Events requirement because they generate various events logged in plain text files, a dedicated database, syslog, or Windows Event Log.

We can categorize generated events into system events and process-related events. System events refer to all important events generated by a system and its components. These provide significant insight into internal system processes and can be used to investigate different types of issues. Examples of system events include:

Monitoring system events is crucial, especially for control systems behind Critical Infrastructure. These logs allow you to detect potential malicious cyber activity or unauthorized access to your ICS.

Process events represent ICS process status and activity. For example, reaching the warning or emergency level of a controlled physical parameter, losing connection with a remote station or terminal, or a diagnosis event from the I/O module (input/output signal out of range).

Possible process-related events include:

Process events are primarily stored in a dedicated database or a Historian database. They are rarely found in plain-text files or proprietary formats.

Analyzing process event data may help predict, prevent, or investigate potential production incidents.

Why is continuous monitoring of network assets so important for ICS?

As discussed in previous chapters, ICS networks are complex, use legacy protocols designed for real-time exchange, and lack security mechanisms.

We also mentioned security threats inherent to ICS. To better understand the benefits of network monitoring, we will consider a few scenarios.

A trespasser may also disrupt production by falsifying information from a remote monitoring point without directly accessing the SCADA system.

To continuously monitor assets, you require various tools, from network packet sniffing and capturing to analyzing captured data by Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS). IDS and IPS compare the gathered data against attack signature rules. If they detect anomalous network activity, they can generate an event and forward it to a Security Information and Event Management (SIEM) system for further analysis.

Network monitoring is especially beneficial when monitored systems or devices such as RTUs, PLCs, and IEDs do not generate native logs.

Security Information and Event Management (SIEM) is a supervisory system that receives and aggregates data and correlates events from various sources.

In an industrial setting, a SIEM can aggregate and correlate system events, process events, and other events to detect possible incidents. For example, correlation rules may deem a recurring event in a short period as a potential attack. Likewise, an operator’s activity reported outside of their work hours or an engineer changing configuration outside of scheduled downtime or service period can be interpreted as a potentially harmful event.

SIEM systems also provide a unified view of the current security status of an organization, allowing filtering of data and generating reports. This information is valuable for system administrators and security analysts.

The addition of a SIEM system extends security mechanisms and allows active process monitoring, helps to reduce the impact of malicious attacks, and provides the necessary information to prevent future incidents.

Many ICS store the majority of their operational and diagnostic logging in text files. NXLog can collect these events and parse them into structured data for further processing and analysis. The following example shows an authorization event generated by the Siemens SIMATIC WinCC runtime, a SCADA and HMI system used with Siemens controllers.

NXLog supports passive network traffic monitoring of numerous protocols, including industrial communication protocols.

The following example captures and parses Modbus TCP packets, one of the most popular protocols used in ICS architectures.

The typical SCADA system handles tremendous volumes of data for various purposes. This data may be stored in local or remote databases for additional processing.

Aggregating events from different database tables gives you insight into internal components and processes (e.g., tag data, process alarms, and process events.) Analyzing this data helps you improve asset management, operations, safety of personnel, etc.

NXLog can be configured to collect events produced by various ICS and their components from Windows Event Log. The following example shows the processing of events generated by Siemens SIMATIC WinCC services.