Dr. Rishabh Das

Dr. Rishabh Das is an Assistant Professor at the Scripps College of Communication, Ohio University. Dr. Das has over a decade of hands-on experience in operating, troubleshooting, and supervising control systems in the oil and gas industry. Dr Das’s research portfolio includes virtualization of Industrial Control Systems (ICS), threat modeling, penetration testing in ICS, active network monitoring, and the application of Machine Learning (ML) in cybersecurity.

Operational technology security leaders recognize a fundamental truth: “You can’t protect what you don’t understand.”

Safeguarding an industrial environment demands an asset-centric approach that begins with a comprehensive understanding of the specific components within that operational environment. This involves taking a detailed look at the assets and their interconnections.

In the world of industrial control systems (ICS), “normal” operations are often fairly consistent, with devices communicating in predictable patterns and processes following routine schedules. This stability means that once you know your assets and baselines, any deviation stands out like a red flag.

In this article, we explore how to leverage the predictability of the operational technology environment (OT) to create a fingerprint of “what good looks like” for your specific OT environment. We will cover three key areas: fingerprinting your assets, baselining what “normal” looks like, and finally using the baselining to respond to abnormal traffic

Know your assets

Effective OT security begins with asset visibility. This means security engineers need to identify every critical asset, such as PLCs, RTUs, HMIs, engineering workstations, etc.

In practice, “knowing your assets” involves creating an inventory of hardware, software, and communication protocols in use. Although automation and sophistication are encouraged, engineers can start the process by using simple tools like a spreadsheet to keep a record of the running inventory. That said, if an organization does opt to use manual processes like spreadsheets, it will need a tightly coupled governance structure. That structure should include reviewing and updating manual entries at a set cadence to maintain accuracy in real-time of the asset log.

As we stated in our previous article, “defending and improving OT operations starts with understanding your assets and the environment,” only then can you define “normal” for your particular network. This principle sets the stage for everything that follows in an OT threat detection strategy.

Baselining “Normal” OT behavior

Once you have a good outline of available assets, the next step is to develop a baseline of normalcy. Baselining helps you catch changes that could introduce risk. For instance, if we know a certain pump controller only communicates with its HMI and historian, any communication outside that set is immediately suspicious.

This inventory consists of details about devices, such as their make, model, firmware, and typical network traffic patterns (including which devices communicate with each other, the protocols they use, and their communication frequencies).

The baseline can also include typical process values and user behaviors, specifying which accounts access specific resources. Essentially, it’s “what good looks like” for your specific OT environment. To build and utilize a baseline for threat detection, we can take the following steps.

• Plan the scope and data sources. Most security baselines capture the asset inventory and network activity. An asset inventory baseline means documenting all devices, their connections, and configurations. Network baseline means capturing typical traffic patterns and performance metrics. The security team should also discuss how to get the data. Common sources can include SPAN or TAPs for the network, PLC project files, configuration dumps, logs from the control system, and even data from physical walkthroughs.
• Passive data collection. Collection can include non-intrusive methods to gather info. This can include deploying a passive monitoring tool (like EmberOT) that can listen to traffic on a SPAN port and gather information without influencing the physical operations of the plant. For quick visibility, the team can also use a combination of Wireshark (with ICS dissector) and the PCAP analysis tools like Network Packet Miner and EmberOT’s OT PCAP Analyzer. PCAP analysis can provide a quick snapshot of the asset communication and summarize traffic flows.
• Data aggregation and analysis. For the network baseline, we identify all device pairs that communicate, including how often they do so and the protocol or port used. For each device, we note the normal communication partners. Other baseline metrics can include the volume of traffic and the frequency of communication for assets. The team can also compile details on the PLC model and firmware version, and correlate process data from field sensors and information that may come from historians or SCADA logs.
• Validate with operational staff. At this point, we have a draft outline of what the OT environment is doing. The typical practice is to refine the data, which involves two steps. First, operators and engineers review and validate the data to ensure accuracy.

At this stage, the baseline might already find useful information. For instance, the operations team might explain, “Oh, that PLC-to-PLC communication you captured shouldn’t be there… it may be a leftover connection, and we can remove it.”

The second step involves continuous data aggregation over a window of time, mostly for a month. This ensures a variety of operational scenarios have been captured over a meaningful amount of time.

The combination of the two steps ensures the baseline truly reflects necessary behavior and filters out known exceptions or planned activities.

• Establish the baseline documentation. Modern OT monitoring platforms build baselines automatically and let you see them in a user interface, or dashboard.. For organizations taking a more manual approach, even a simple spreadsheet with a communication matrix outlining the device versus protocol can serve as baseline documentation for smaller systems.

Using the baseline for threat detection

Many passive monitoring tools have baseline learning modes. Given correct data flows, the learning mode can automate the baseline creation process.

Once the baseline is set, the next step is to monitor deviations. Although the system can get noisy at first, with proper tuning, it can provide a very solid detection framework that flags any anomalous behavior. For example, you might configure an alert: “Alert if a new device (MAC/IP) appears on the network that was not in the baseline.” This catches rogue or transient devices.

Some popular rules used by OT security teams:

• New Connection alerts. If your baseline says the HMI never talks to the safety PLC, but suddenly there are packets between them, that’s worth investigating. It might be an attacker pivoting to a new asset.
• Changed communication frequency or volume. Suppose a PLC normally sends 100 packets/hour to the SCADA, but now it’s sending 10,000/hour. Baseline thresholds would catch this spike.
• Unknown protocol usage. If all your baseline traffic is, say, Modbus and CIP, and one day you see an HTTP connection or an SSH session in the OT subnet, that’s not baseline. It might indicate someone introduced a new service or an attacker using a backdoor.
• Asset attribution change. Baselines can include device settings. If a PLC’s firmware version changes from baseline, and you didn’t perform an update, this is critical – it could be an unauthorized firmware change by an intruder.
• User behavior deviation. If operators usually log in during the day shift only, an after-hours login is off-baseline. This might catch compromised credentials being used at odd times.

A baseline-driven alert should lead you to ask, “Is this new behavior okay or not?” Sometimes the alert uncovers a legitimate need (and then you update the baseline accordingly), but other times it’s a red flag of compromise.

OT baselining isn’t a one-and-done exercise. Industrial environments change, albeit slowly. New projects, expansions, or upgrades will necessitate updating the baseline. It’s good practice to schedule periodic baseline reviews or reassessments. To enhance security, it is essential to keep security engineers actively engaged with continuous monitoring tools. This approach guarantees human oversight and helps validate the evolving baselines of our systems.

---

View additional articles submitted by guest author Dr. Rishabh Das:

Modernizing OT Security with Human-in-the-Loop GenAI Agents

Monitoring GenAI-driven Data Exposure in Critical Infrastructure

Detecting GenAI Usage in Critical Infrastructure

Become a Subscriber

EMBEROT WILL NEVER SELL, RENT, LOAN, OR DISTRIBUTE YOUR EMAIL ADDRESS TO ANY THIRD PARTY. THAT’S JUST PLAIN RUDE.