In the majority of young security programs, questions regarding logs arise at an early stage. With the introduction of a SIEM, it is crucial to consider how to integrate operational technology (OT) into the predominant information technology (IT) infrastructure.
In most cases, the most straightforward solution is to collect all the logs and attempt to derive some sort of meaning from them, if possible. For many companies, having OT logs in their SIEM is merely a box to tick on the requirements for NIST or other frameworks. This approach does not scale well, however, as incorrect configuration can result in thousands of events per substation per week.
Furthermore, OT logs can be invaluable when handled correctly. As with IT, the key is not to focus on which logs to collect and how long to store them, but to view logs as a helpful tool. They are a means of understanding circumstances and automatically flagging changes.
Visualizing the network connection from the station to SOC and SCADA
Selectively collecting logs in a centralized database per site
How to decide what to log?
Now that has been clarified, the pertinent questions can be defined as follows:
- What information do I require and wish to be notified about?
- What level of urgency do I require for notification?
- For how long after the event is the information useful, and how long do I need to look back to be able to troubleshoot or solve issues?
It is essential to define structured conditions, such as “use cases” or, more commonly “alerts,” that can be used by SIEM or other types of log management software/devices.
There are two common approaches:
- Bottom-Up: Reviewing the available logs to identify valuable alerts.
- Top-Down: Defining a set of use cases and attempting to describe the relevant circumstances in a machine-understandable format.
Another key difference between IT and OT security is that the former’s primary objective is to ensure the security of data and systems, whereas the latter’s overarching goal is to guarantee the safety of personnel and assets. Thus, security is not the primary focus, but rather a means of avoiding any potential compromise to safety.
It is therefore recommended that the majority of security logs be used for monitoring processes in OT, as this is a necessary and effective approach. Some more specialized security operation centers (SOCs) will also alert on process violations, as a deviation from the standard process can also be indicative of an attack from internal or external sources. Ultimately, this decision is up to the organization, contingent on the availability of the requisite skills to determine the criticality of circumstances. As a preliminary step, the MITRE ATT&CK ICS matrix can serve as a reference point for identifying potential attacks and process violations to monitor and alert. This matrix provides a summary of methods that have been used in past, offering insights into potential vulnerabilities.
All OT-specific intrusion detection systems (IDSs) provide common alert structures, including new connections via common IT protocols like IP, TCP, UDP, SNMP, and DHCP. Additionally, they generate alerts indicating deviations or unusual behavior from process automation devices, such as RTUs. Some common examples are when a new instruction set is uploaded to the controlling devices. In specific cases, this can extend to having an exact description of the environment, with any discrepancies from this description being flagged. This is a key benefit of IEC 61850 environments.
To return to the initial query, “What should be documented and for how long should it be stored?”
The answer is both straightforward and, as is often the case, multifaceted. It can be summarized as follows: “It depends.”
How to proceed?
To achieve the optimal use of resources, the IT and OT departments must collaborate to determine which alerting functions will be handled by the SOC and which will be managed by OT engineers. Once this decision is made, the relevant logs for collection can then be identified.
Generally, the type of logs that are important in the OT are as follows:
- Local events, e.g., of the operating systems
- Events from domain controllers
- Firewall/router/switch/server events
- Malware protection software events
- Events from intrusion detection systems (IDS) or intrusion prevention systems (IPS)
In addition to the aforementioned events, the following data should be recorded:
- Date and time,
- Description of the event,
- Criticality,
- Source of the event, e.g., application, operating system
- Affected OT system/process
One effective method for addressing this challenge is the use of highly specialized monitoring tools that perform the filtering process automatically. One such tool is our energy sector-specific StationGuard solution. StationGuard analyzes the complete traffic and generates automatic alerts. This helps with the monitoring of devices and processes without the need for extensive log collection.
Resources
