14 JulBy PDF

Today’s highly automated industries require fast and reliable data transfer. This evolution started the era of industrial Ethernet as a universal communication standard within Operational Technology (OT) environments.

Ethernet meets the availability and real-time communication requirements of Industrial Control Systems (ICS) and enables communication with external networks and systems. However, increased connectivity brings numerous threats and vulnerabilities previously unknown to these systems.

This white paper provides an overview of ICS, including Supervisory Control And Data Acquisition (SCADA) systems, outlines common threat scenarios, and suggests strategies to meet event log management and passive network monitoring requirements. Its intended audience is IT specialists unfamiliar with ICS/SCADA environments and ICS/SCADA specialists and managers looking to secure their systems.

Definition of SCADA

SCADA systems are a big part of modern Industrial Control Systems. They provide real-time monitoring and supervisory control of industrial processes and equipment in industries like oil & gas, pharmaceutical, petrochemical, food & beverage, manufacturing, power, recycling, transportation, water & wastewater, mining, etc.

The primary function of SCADA is to acquire data from remote devices and provide visibility on their status in a single control center. Operators rely on this data to monitor and control processes and respond to various situations effectively.

In addition, SCADA systems allow long-term archiving of data for analyzing and improving efficiency, informing decision-making, and preventing downtime. SCADA software can combine data from numerous sources, process it, and send it to other systems in various formats.

Advanced SCADA systems can generate reports and automatically respond to certain conditions, for example, by generating alarms and warnings in hazardous situations or potential loss of product quality.

The main functions of SCADA systems are:

  • Controlling industrial processes locally or remotely

  • Monitoring, gathering, and real-time processing of data

  • High-performance data archiving

  • Analyzing process values (trends) and messages (alarm control)

  • Interacting with a wide range of devices using extended communication infrastructure

  • Communicating with external applications (ERP, MES, DBMS, spreadsheets, etc.)

SCADA is crucial for industrial companies, allowing them to control assets locally or remotely, gain operational insights, control processes, and make data-driven business decisions. SCADA systems save a significant amount of time and money, increase the efficiency of operations, reduce downtime, and ensure product quality.

Structure of SCADA systems

An Industrial Control System comprises SCADA software interacting with numerous complex hardware devices over a network. The overall structure of this type of ICS includes the following distinct levels:

  • Field devices (sensors, actuators, etc.)

  • PLC (Programmable Logic Controller) and/or RTU (Remote Terminal Unit)

  • Communication networks

  • Communication protocols

  • SCADA host software

Let’s discuss each level in more detail to understand how data is transferred and transformed between levels.

Field devices

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.

PLC and RTU

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.

Communication networks

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:

Field level

This is the lowest level, including field devices such as sensors and actuators. Devices operating at this level typically employ discrete signals, 4-20mA current loops, or serial point-to-point communication options (RS-232, RS-422, RS-485). The most sophisticated communication technology used at this level is Fieldbus (e.g., PROFINET, PROFIBUS, HART, ControlNet, DeviceNet, CANBus, and Foundation Fieldbus), allowing distributed control among smart field devices and controllers.

Control level

This level typically includes PLCs, Distributed Control Systems (DCS), SCADA/HMI systems, and related network infrastructure. Data is gathered and distributed to the various automation systems or PCs for supervisory control and monitoring at this level.

Information level

This is the highest level of an industrial automation system that handles higher-level management functions. Here, process data is saved, processed, and analyzed.

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

  1. Industrial networks have a much more complex architecture with a hierarchy of three to four levels with different protocols and physical media. In contrast, an organization’s commercial network may consist of Local Area Networks (LAN) connected by a backbone network or a Wide Area Network (WAN).

  2. Industrial networks support critical industrial systems. The failure of these systems may have severe effects, including damage to equipment, production loss, environmental damage, loss of reputation, and even loss of life.

  3. Industrial equipment and control loops may need to operate in a high-speed mode that requires data to be transmitted, processed, and responded to as close to real-time as possible. Systems in commercial networks do not have such strict response time requirements.

  4. The data in the lowest levels of an industrial network must be transmitted in a predictable manner, which means bounded latency of a signal to predict when a reply to transmission will be received.

  5. Industrial networks provide periodic data sampling and require the transmission of asynchronous events, such as alarms and state changes.

  6. Industrial networks require determining transmission time and event order, e.g., for asynchronous events, using timestamps and synchronized clocks.

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.

ICS communication protocols

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 software

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:

I/O server

A dedicated communications server connecting diverse data sources to consolidate all plant and industrial data. It acts as a communication protocol server providing data from specific vendors' PLCs and other factory devices. It is responsible for servicing clients' read, write, and subscription requests and keeps up-to-date information by regularly retrieving data from each connected I/O device.

Alarms server

This process is responsible for assessing the conditions that define an alarm.

Trends server

Controls the accumulation and logging of trend information to provide an up-to-date and historical plant overview. Trend data helps to understand plant and equipment performance better and is used for visual analysis, production records, or recording of equipment status for maintenance.

Reports server

Process dedicated to creating custom reports based on real-time or historical data. It can design, schedule, or trigger complex reports containing any number of parameters from various sources, such as history or alarm databases.

Historian server

A high-performance long-term archiving server storing process values and messages in a central database.

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.

Security

Humanity employs a set of utilities that are critical for our vital activity. These industries, such as water and wastewater, oil and gas, power generation, transportation, and communication, are classified as Critical Infrastructure.

A significant part of the world’s Critical Infrastructure relies heavily on industrial networks and ICS. Disruption to any of the systems associated with these infrastructures could impact our society and safety.

Due to an attack’s potential impact, industrial systems are a very attractive target for hackers. As a result, security for ICS has become a critical and widely discussed topic in recent years.

Operational Technology (OT) security challenges

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.

Table 1. OT vs. IT security
Characteristics IT OT

Malware protection

Widely used

Often difficult or impossible to use

Vulnerability scanning

Active scanning

Passive scanning during planned outages is recommended to avoid disrupting operations

Patch management

Frequent

Complex, not possible due to legacy systems, or requires supplier approval

Reliability

Incidental failure is manageable

Failure is not acceptable

Availability

Some degree of network and system interruption is acceptable

Network and system interruptions are not acceptable

Security testing

Widely used

Requires identifying risks

Performance

Occasional delays and network instability are expected and communication is not time sensitive

Occasional delays and network instability are not acceptable and teal-time communication is required

Security

Little separation between networks at the same location

The information system network is isolated from the plant network

Security and awareness

Good

Bad

Security Criteria

The objective of industrial security is to fulfill three criteria:

  • Safety of personnel and the environment

  • Availability of assets and data

  • The integrity of operational and configuration data

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.

Threats

Human threats

The human factor is the most significant threat to ICS security. Incorrect configurations, programming errors, and failing to monitor alerts are only a few possible threats caused by negligent or poorly trained personnel, disgruntled employees, contractors, or vendors. They may disrupt the production process by sending incorrect commands or using parameter values that might cause process equipment to malfunction.

An employee with comprehensive knowledge of an industrial process may also become a threat due to financial gain, dissatisfaction, or unintentional human error.

Internal threats

Due to insufficient or nonexistent authentication or role-based access to restrict user activity, an employee may gain unlimited access to any device on the network, including SCADA applications and other critical components. Many unauthorized accesses to ICS come through computers used to access the system for diagnostic or maintenance purposes rather than external devices.

External threats

These are primarily hacker attacks with the criminal intent to jeopardize the control system by causing operational disruption, damage, or espionage.

Importance of SCADA/OT log collection and passive network monitoring

As discussed in the previous section, protecting information from unauthorized access is standard procedure in IT systems. However, the same level of protection is often lacking in OT, despite being increasingly more connected with IT systems.

The international standard ISA/IEC-62443 defines global industrial security recommendations for protecting ICS information, devices, and systems. It focuses on personnel safety, the environment, and production quality and efficiency.

ISA/IEC 62443-3.3 "System security requirements and security levels" of the standard describes general ICS security requirements and contains two critical topics for the implementation of cybersecurity in industrial systems, namely "Auditable Events" and "Continuous monitoring."

SR2.8 - Auditable Events.
  • Requirement.
    The control system shall provide the capability to generate audit records relevant to security for the following categories: access control, request errors, operating system events, control system events, backup and restore events, configuration changes, potential reconnaissance activity audit log events. Individual audit records shall include the timestamp, source (originating device, software process or human user account), category, type, event ID and event result.

  • Rationale and supplemental guidance.
    The purpose of this requirement is to record the occurrence of important events which need to be audited as significant and relevant to the security of the control system.

  • Requirement enhancement.
    Centrally managed, system-wide audit trail. The control system shall provide the capability to centrally manage audit events and to compile audit records from multiple components throughout the control system into a system-wide (logical or physical), time-correlated audit trail. The control system shall provide the capability to export this audit records in industry standard formats for analysis by standard commercial log analysis tools, for example, security information and event management (SIEM).

— NIST Cybersecurity Framework Core: Informative Reference Standards ISA 62443-3-3:2013
SR6.2 - Continuous monitoring
  • Requirement.
    The control system shall provide the capability to continuously monitor all security mechanism performance used commonly accepted security industry practices and recommendations to detect, characterize and report security breaches in a timely manner.

  • Rationale and supplemental guidance.
    Control system monitoring capability can be achieved through a variety of tools and techniques (for example, IDS, IPS, malicious code protection mechanisms and network monitoring mechanisms). As attacks become more sophisticated, these monitoring tools and techniques will need to become sophisticated as well, including for example behavior-based IDS/IPS.

    Monitoring devices should be strategically deployed within the control system (for example, at selected perimeter locations and near server farms supporting critical applications) to collect essential information. Monitoring mechanisms may also be deployed at ad hoc locations within the control system to track specific transactions.

    Monitoring should include appropriate reporting mechanisms to allow for a timely response to events. To keep the reporting focused and the amount of reported information to a level that can be processed by the recipients, mechanisms such as SIEM are commonly applied to correlate individual events into aggregate reports which establish a large context in which the raw events occurred.

    Additionally, these mechanisms can be used to track the effect of security changes to the control system (see SR 2.8 - Audible events). Having forensic tools pre-installed can facilitate incident analysis.

— NIST Cybersecurity Framework Core: Informative Reference Standards ISA 62443-3-3:2013

Implementing a process for logging security-related events and monitoring network assets is also an essential requirement of security standards and catalogs such as NERC CIP-007 and the BDEW white paper.

Additional tools are often required to comply with the above requirements and provide an enhanced level of ICS security. The following sections discuss this issue in more detail and propose a possible solution.

Auditable events

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:

  • User activity

  • Configuration changes

  • System backups

  • Software updates

  • System diagnosis

  • System services activities (Start/Stop, Activate/Deactivate)

  • Communication events

  • Trace logs

  • Compilation summary

  • Runtime events

  • Performance information

  • Audit trails

  • Import/export and migration events

  • License information

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 alarms

  • Process status

  • Equipment failure and diagnosis events

  • Scheduled or triggered archiving (tag logging)

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.

Continuous monitoring

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.

Man in the middle (MitM)

An attacker gains access to the network between the control entity (e.g., SCADA, HMI) and the PLC or RTU. Using simple network manipulation techniques (e.g., ARP spoofing), the attacker relays messages between the components as if they were talking to each other when the attacker controls the entire conversation. A MitM attack has several repercussions:

  • Listening to the network traffic allows the attacker to retrieve information about processes' functions and the network’s structure.

  • An attacker can distort the information sent by the control entity, leading to potential damages. This type of attack requires knowledge of the current process, devices, and industrial protocols.

  • An attacker can modify the information sent to the control entity. This approach can hide malicious actions on the PLC or RTU by hindering the control entity from generating alarms or warnings.

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

Denial of Service (DoS)

Network traffic is disrupted by flooding a targeted host or the entire network. As a result, the targeted host cannot respond or crashes, preventing legitimate users from accessing the system and thus impacting availability.

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

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.

Log collection from ICS environments with NXLog

Integrating SIEM solutions with OT-specific tools and applications enables industrial organizations to extend visibility, security, and control across IT and OT operations. You can achieve seamless interoperability by forwarding OT alerts and events to the relevant SIEM system.

NXLog Enterprise Edition is the ideal solution for collecting and processing events from diverse sources. NXLog can be installed on various platforms and receive logs via UDP, TCP with TLS/SSL encryption, or HTTP(S). It can also read events from files and databases and supports platform-specific sources such as Windows Event Log, Linux syslog and kernel logs, and the macOS Unified Logging System (ULS).

NXLog can perform advanced processing of log messages, such as rewriting, correlating, alerting, pattern matching, scheduling, and log file rotation. After processing, NXLog can write logs to a central repository or forward events to a third-party platform.

NXLog Enterprise Edition supports passive network monitoring with a dedicated input module for capturing network packets (im_pcap). This module supports various communication protocols, including industrial communication protocols such as BACnet, DNP3, Modbus TCP, IEC 60870-5-104, IEC 61850, PROFINET, and S7comm. In addition, network packets can be parsed, processed, and converted to different data formats such as JSON, XML, CSV, syslog, etc.

Processing text-based log files

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.

Example 1. Processing SIMATIC WinCC Operator logs

This input sample is from WinCC_Op_xx.log located in the SIMATIC WinCC general diagnostic folder C:\Program Files (x86)\SIEMENS\WinCC\diagnose. The log file is UCS-2LE encoded.

Input sample
65535,23.03.2022,21:09:45:094,1008003,8,SPVSR,WINSRV99,PASSRT,,,0,0,MSG_STATE_COME,,,,

NXLog can read the file with the im_file input module, convert data to UTF-8 encoding, and parse each event into structured data to facilitate processing by other modules.

The parsed data can be converted into various formats and routed to different destinations. For example, the following output sample shows the same event converted to JSON format.

Output sample
{
  "EventReceivedTime": "2022-03-23T21:09:45.558079+01:00",
  "SourceModuleName": "from_file",
  "SourceModuleType": "im_file",
  "Application": "PASSRT",
  "ErrorMessage": "",
  "ID": "65535",
  "MessageClass": "8",
  "MessageNumber": "1008003",
  "NewValue": "0",
  "OldValue": "0",
  "Reason": "",
  "State": "MSG_STATE_COME",
  "Station": "WINSRV99",
  "UserName": "SPVSR",
  "VarName": "",
  "EventTime": "2022-03-23T21:09:45.000000+01:00"
}

Capturing network packets

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.

Example 2. Capturing Modbus TCP packets

NXLog can collect network packets with the dedicated im_pcap input module. Captured packets can be converted into various formats and routed to multiple destinations. For example, the following samples show Modbus TCP query and response packets in JSON format.

Query sample
{
  "modbus.function_code": "Read Holding Registers (03)",
  "modbus.length": "6",
  "modbus.prot_id": "0",
  "modbus.query.read_holding_regs.qty_of_regs": "3",
  "modbus.query.read_holding_regs.starting_address": "0",
  "modbus.trans_id": "636",
  "modbus.unit_id": "1",
  "EventTime": "2022-05-05T16:48:08.064553+03:00",
  "EventReceivedTime": "2022-05-05T16:48:08.369641+03:00",
  "SourceModuleName": "pcap_protocol",
  "SourceModuleType": "im_pcap"
}
Response sample
{
  "modbus.function_code": "Read Holding Registers (03)",
  "modbus.length": "9",
  "modbus.prot_id": "0",
  "modbus.response.read_holding_regs.byte_count": "6",
  "modbus.response.read_holding_regs.registers": "251, 247, 241",
  "modbus.trans_id": "636",
  "modbus.unit_id": "1",
  "EventTime": "2022-05-05T16:48:08.075087+03:00",
  "EventReceivedTime": "2022-05-05T16:48:08.369641+03:00",
  "SourceModuleName": "pcap_protocol",
  "SourceModuleType": "im_pcap"
}

Reading logs from a database

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.

Example 3. Reading records from a database table

The following is a sample record from an AVEVA System Platform Alarm database table depicted in CSV format.

Input sample
EventId,EventGuid,ProviderId,GroupName,TagName,EventClass,EventType,EventState,EventPriority,EventValue,EventLimit,ValueString,LimitString,EventTime,EventTimeFracSec,EventTimeZoneOffset,EventDaylightAdjustment,OperatorNode,OperatorName,Comment,User1,User2,User3,OperatorID,EventStamp
45721,C94E61BD6DB54E249FFBFBEC6D665EAF,1,USER,MB_1,"EVENT   ","DDE ","         ",9,11,10,11,10,2022-01-10 09:16:40.343,3440,-480,0,WIN-5RU7GP5MI4V,None,MB_1 alarm,0,0,,NULL,2022-01-10 01:16:40.343

NXLog’s im_odbc input module can query any ODBC data source, provided that the relevant ODBC driver is installed on the system.

NXLog can convert records to various formats. For example, the following output sample shows the same event in JSON format.

Output sample in JSON
{
  "EventId": 45721,
  "EventGuid": "C94E61BD6DB54E249FFBFBEC6D665EAF",
  "ProviderId": 1,
  "GroupName": "USER",
  "TagName": "MB_1",
  "EventClass": "EVENT",
  "EventType": "DDE",
  "EventState": "",
  "EventPriority": 9,
  "EventValue": "11.0",
  "EventLimit": "10.0",
  "ValueString": "11",
  "LimitString": "10",
  "EventTime": "2022-01-10T09:16:40.343000-08:00",
  "EventTimeFracSec": 3440,
  "EventTimeZoneOffset": -480,
  "EventDaylightAdjustment": 0,
  "OperatorNode": "WIN-5RU7GP5MI4V",
  "OperatorName": "None",
  "Comment": "MB_1 alarm",
  "User1": "0.0",
  "User2": "0.0",
  "User3": "",
  "OperatorID": null,
  "EventStamp": "2022-01-10T01:16:40.343000-08:00",
  "EventReceivedTime": "2022-01-10T01:16:41.329046-08:00",
  "SourceModuleName": "from_odbc",
  "SourceModuleType": "im_odbc"
}

Collecting Windows events

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.

Example 4. Processing Windows events

This event sample is from the CCArchiveManagerService log source.

Event sample
Log Name:      Application
Source:        CCArchiveManagerService
Date:          5/20/2022 9:36:28 PM
Event ID:      0
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      WIN-6TE9FAEN678
Description:
Service started
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="CCArchiveManagerService" />
    <EventID Qualifiers="0">0</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-05-20T18:36:28.086013900Z" />
    <EventRecordID>10908</EventRecordID>
    <Channel>Application</Channel>
    <Computer>WIN-6TE9FAEN678</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Service started</Data>
  </EventData>
</Event>

NXLog provides the im_msvistalog input module to collect Windows events. This module supports XPath queries and can collect events locally and remotely.

Collected events can be converted into various formats. For example, the following output sample shows the same event in JSON format.

Output sample
{
  "EventTime": "2022-05-20T21:36:28.086013+03:00",
  "Hostname": "WIN-6TE9FAEN678",
  "Keywords": "36028797018963968",
  "LevelValue": 4,
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 0,
  "SourceName": "CCArchiveManagerService",
  "TaskValue": 0,
  "RecordNumber": 10908,
  "ExecutionProcessID": 0,
  "ExecutionThreadID": 0,
  "Channel": "Application",
  "Message": "Service started",
  "Category": "%1",
  "Opcode": "Info",
  "Level": "Information",
  "Data": "Service started",
  "EventReceivedTime": "2022-05-20T21:36:28.402837+03:00",
  "SourceModuleName": "from_eventlog",
  "SourceModuleType": "im_msvistalog"
}

Conclusion

Industrial Control Systems are at the core of almost every industrial process. Found in various facilities, they constantly face operations technology (OT) and information technology (IT) risks. Moreover, exposing industrial infrastructure to the internet and third-party networks has given rise to a host of new threats that can be detrimental to the entire industrial process and have severe consequences.

Securing an ICS requires risk analysis and a deep understanding of the industrial process, making it a challenge for OT and IT network administrators. Numerous recommendations and standards endorse the importance of event log management and continuous monitoring of industrial networks to protect against the growing number of threats. Log data provides vital information, whether the goal is to increase security, improve operability, meet compliance goals, or gain business insights from IT/OT environments.

NXLog Enterprise Edition is an all-in-one log collection, processing, and forwarding solution that meets the logging requirements discussed in this paper. It can collect logs from thousands of different sources and store or forward them in numerous data formats. In addition, it supports passive network monitoring with a specialized focus on ICS protocols, making it one of the industry’s most flexible and powerful log collection solutions.

NXLog Ltd. develops multi-platform log collection tools that support many different log sources, formats, transports, and integrations. The tools help administrators collect, parse, and forward logs so they can more easily respond to security issues, investigate operational problems, and analyze event data. NXLog distributes the free and open source NXLog Community Edition and offers additional features and support with the NXLog Enterprise Edition.

This document is provided for informational purposes only and is subject to change without notice. Trademarks are the properties of their respective owners.