Leveraging NetFlow and Logs for Effective ICS Threat Hunting

Introduction

In industrial and critical infrastructure environments, maintaining operational continuity and safety is paramount. As threat actors increasingly target Industrial Control Systems (ICS) and Operational Technology (OT), the ability to detect, understand, and respond to anomalous network activity is no longer a luxury—it is a necessity. This post explores the technical underpinnings and best practices of leveraging NetFlow and traditional log sources for threat hunting within ICS, providing a deep dive into architecture, methods, and the unique challenges facing IT/OT environments today.

NetFlow: Historical Context and Relevance in Industrial Networks

Originally introduced by Cisco in the mid-1990s, NetFlow was developed to monitor IP network traffic by capturing metadata about traffic flows. Unlike full packet capture, NetFlow emphasizes efficiency by summarizing communications as flows—sequences of packets sharing key properties (source/destination IP, source/destination port, protocol, etc.).

The utility of NetFlow in IT has long been established, serving roles in traffic engineering, performance monitoring, and—critically—incident detection and forensics. Its adoption in OT and ICS environments has lagged due to concerns around resource usage, the determinism required in real-time networks, and a lack of native support on many legacy devices. Nonetheless, recent industrial network modernization and increasing cyber risk have pushed NetFlow (or similar protocols such as sFlow and IPFIX) into the industrial threat hunter’s toolkit, often via network taps or flow exporters on mirrored ports.

Key Characteristics of NetFlow in ICS Settings

• Resource-light: NetFlow generally imposes lower overhead than full packet capture—critical for preserving network determinism in sensitive ICS networks.

• Non-invasive: Deploying NetFlow collectors on mirrored/monitor ports avoids interfering with critical control traffic.

• High-level visibility: Although NetFlow does not record payload data, its summarized metadata greatly aids in mapping communications between assets and detecting anomalies or policy violations.

Log Sources in ICS: What’s Available?

System and application logs in traditional IT environments are foundational for threat detection: OS logs, security event logs, application logs, and firewall logs provide granular insights. In ICS, log collection must account for both IT and OT elements:

• Engineering Workstations and HMIs: Often run on Windows or Linux and produce familiar event logs, authentication records, and local application logs.

• PLC and RTU Logs: Vendor-specific, with varying degrees of granularity; may include command audit trails, fault logs, and network diagnostics.

• Network Infrastructure Logs: Industrial switches, firewalls, or routers that support syslog, SNMP traps, and proprietary logging protocols.

• Third-party Security Sensors: Inline IDS/IPS, anomaly detection, protocol-aware inspection tools—often acting as a bridge between standard IT logging capabilities and proprietary OT traffic analysis.

Historically, many field devices simply had no logging capabilities or were not configured to retain logs, meaning deployment of industrial Data Diodes, secure log servers, and log forwarding solutions is now often required for visibility and auditability.

Architectural Considerations: IT/OT Convergence and Data Flow

Deploying threat hunting infrastructure in ICS is not a direct transplant of IT practices; strict segmentation (often via demilitarized zones/DMZs or unidirectional gateways) and diverse device capabilities complicate log and flow collection.

Typical Architecture for NetFlow and Log Collection:

• ICS Zones: Segmented layers (e.g., Purdue Model levels) where core process control devices operate, with minimal direct connectivity to corporate IT networks.

• Collection Points: Monitoring ports on industrial switches or boundary devices, often in the “DMZ” between enterprise IT and process control networks, forwarding NetFlow records and syslogs to centralized collectors.

• Data Aggregation and Analysis: Centralized SIEM or specialized OT security platforms, frequently air-gapped or isolated, capable of ingesting NetFlow, syslog, and application logs for real-time and retrospective analysis.

Effective collaboration between IT and OT teams is essential: IT brings expertise in log analysis and SIEM operation; OT understands process priorities, asset criticality, and protocol idiosyncrasies. Joint runbooks and escalation plans anchored in both NetFlow and logs can bridge this divide.

Threat Hunting Techniques: Utilizing NetFlow and Logs Together

1. Asset Inventory and Baseline Behavior

• NetFlow: Map peer-to-peer communications, frequency, duration, and data volumes between endpoints. Industrial protocols (Modbus/TCP, DNP3, OPC) should be strictly bounded between known roles and time windows. Tools can automate asset discovery with flow data, flagging “new” hosts or protocol use.

• Logs: Enrich flow-based observations by correlating authentication events, device reboots, firmware changes, remote session initiations, and engineering station access.

2. Suspicious or Unauthorized Communication Detection

• NetFlow: Identify lateral movement, atypical source/destination pairs, new or unexpected protocols, or abnormal volume spikes. For example, an ICS engineering workstation initiating outbound connections after hours can be quickly pinpointed.

• Logs: Confirm with workstation security or application logs—was a remote management tool initiated? Were there failed or anomalous login attempts prior to the suspicious connection?

3. Industrial Protocol Abuse Observations

• NetFlow: While packet payloads are not available, repeated high-volume or frequent flow records on OT protocol ports may indicate scanning or unauthorized command issuance.

• Logs: Where available, use device event logs or protocol gateway logs to spot unauthorized tag reads/writes or failed authentication at the control layer.

4. Threat Attribution and Forensics

• NetFlow: Useful in timeline analysis—mapping the “blast radius” of compromised assets by showing all entities they communicated with before, during, and after an event.

• Logs: Provide context—such as operator actions, configuration changes, or device status—that can confirm or dismiss NetFlow-derived hypotheses.

Challenges and Pitfalls

• Protocol Granularity: NetFlow delivers metadata, not payload analysis. Encrypted or custom industrial protocols may obscure meaningful flows.

• Time Synchronization: Accurate correlation between logs and NetFlow depends on consistent timekeeping; many industrial networks historically lack NTP discipline.

• Incomplete Logging Coverage: Legacy field devices may be “dark” with no log support, necessitating reliance on NetFlow or passive traffic analysis.

• Data Retention and Storage: The volume of flows and logs can overwhelm limited forensic storage if not tiered and curated based on asset criticality.

Conclusion: Towards Robust, Collaborative ICS Defense

Integrating NetFlow and log-based visibility in ICS environments demands both technical rigor and deep cross-disciplinary collaboration. While NetFlow provides scalable, non-intrusive insight into communication patterns and flows, the enrichment of this data with OT and IT logs is key to high-fidelity threat hunting and forensic readiness.

Securing critical infrastructure relies on actionable visibility. By designing architectures that respect industrial process requirements while enabling comprehensive collection and analysis of both flow and log data, defenders can effectively detect and investigate even subtle anomalies before they threaten safety or resilience.

As threat actors continue to innovate and target ICS, so too must defenders advance—using every available data source, contextualized with experience and institutional knowledge, to tip the scales in favor of secure, reliable operations.