FINAL CHEAT SHEET Industrial Network Security Monitoring Incident Response
FINAL CHEAT SHEET Industrial Network Security Monitoring Incident Response
NSM is a human driven, proactive, repeatable process Collection – Align with the Purdue architecture to Analysis - Using "hits" from Detection, Analysis helps
of Collection, Detection, and Analysis. NSM excels in establish enforcement boundaries, naturally creating determine when ICS IR is needed. Start with no-cost
ICS environments because they are more static and chokepoints for NSM data collection and doubling as tools to extract suspicious files from network
host fewer users than IT environments. Below are two control points for contamination. Collect ICS traffic at captures. File hashes can be searched across malware
methods to ensure NSM Collection is established. least at Purdue Levels 0-3. Use fully managed switches databases or files can be executed in isolated
Having an ICS asset inventory prior to NSM is ideal. to passively collect data via SPAN, or TAP. Capture at malware analysis sandboxes to determine threat
least 5-tuple IPFIX data, but full packet capture is behaviors for quick defense countermeasures.
Network TAP - Hardware device in-line in the ideal.
ICS network that copies network traffic. Wireshark – Has many ICS protocol
Typically requires a network outage to dissectors built-in. Extract files: File ->
5-tuple IPFIX capture – Only src and dst IP, src
install. Always ensure it fails open and Export Objects -> <type> -> Save
and dst port, and protocol.
allows traffic to flow through in the event
of device failure, otherwise it could NetworkMiner – Categorizes and extracts
interrupt legitimate control operations. Full Packet Capture - Entire packet content. 5- data for quick analysis – images, files,
tuple IPFIX and full payload. Can extract web sessions, SSL keys, passwords, etc.
files, malware samples, etc. Consumes
Network SPAN - May be available on existing significantly more storage than IPFIX alone.
managed switches. No network outage required 5. ICS NSM – In Practice
to implement. May miss or drop mirrored
packets if switch is overloaded. Phase
VLANs, network segments, into the SPAN
3. Network Security Monitoring – Detection Phase in NSM Collection around critical and most
configuration one or two at a time to ensure vulnerable ICS assets first; historians, field devices,
switch CPU and memory can manage the load. Detection – Leverage threat intel from your ICS HMIs, engineering workstations, etc., one segment at
sector, tcpreplay, an IDS with ICS rulesets, and use a time. Sift through collected data for indicators of
Commands differ across switch manufacturers. Pseudo these pseudocode rules to start network detection. compromise starting with IP addresses.
command to create a local SPAN session 1 for Analyze network 5-tuple data first for:
monitoring bi-directional traffic from port 1 to port 2, Replay packet capture files against a Network IDS: • Matches of known malicious Ips
and show change is applied: sudo tcpreplay --intf1=<nic_for_ids> --
• Top talking IP addresses
mbps=500 potentially_evil.pcap
• Devices talking that did not previously
# monitor session 1 source interface • Network oddities - spikes in traffic etc.
gigabitethernet1/1 both Alert on communications to PLC that is not HMI:
alert tcp !$Modbus_HMI any -> $Modbus_PLC Analyze deep packet network data for:
# monitor session 1 destination interface any (msg: “TCP comms to PLC but not HMI”;) • Abnormal ICS protocol patterns/commands
gigabitethernet1/2 • Signs of unexpected encryption
Alert on possible recon scan or mapping attack: • Outbound Internet or odd DNS requests
# show monitor all alert tcp any any -> any 502 (msg: “Scan or • Newly registered devices on the network
usage of ModbusTCP on network without it”;)
You can collect network data with a Security Onion Repeat NSM Collection, Detection, Analysis steps.
laptop using Wireshark, tcpdump, etc. Beyond just Alert on possible connection to known evil C2: High-confidence indicators of compromise matches
alert tcp any any -> <evil_C2_ip> any (msg: and anomalies will trigger ICS incident response.
security events, ICS NSM can uncover fixes for
“Connection attempt to known evil C2 IP”;)
networking and engineering misconfigurations.