Listen to this Post
Introduction:
Operational Technology (OT) security often fails not because of weak tools, but because teams collect overwhelming amounts of network data while missing the most critical signals: changes to PLC logic and state. By focusing on just six core events—login success/failure, configuration changes, program changes, program start/stop, and PLC restarts—you can detect nearly 80% of real-world impact scenarios, including internal mistakes and unauthorized access.
Learning Objectives:
- Identify the six essential PLC events that expose the majority of OT incidents and ICS ATT&CK techniques.
- Implement lightweight log collection and monitoring for these events using open-source tools and native OS commands.
- Build a minimalist OT SIEM strategy that prioritizes PLC state changes over noisy network packet captures.
You Should Know:
- Why PLC Logic Monitoring Trumps Network Traffic Analysis
Most OT security setups start with full packet capture and deep protocol parsing, yet they miss the moment a PLC’s logic or state changes. Attackers and negligent engineers target the PLC itself—not the network. To monitor effectively, you need to collect event logs directly from PLCs or their engineering workstations.
Step‑by‑step guide to set up a basic syslog collector on Linux:
Install rsyslog (most Linux distributions) sudo apt update && sudo apt install rsyslog -y Debian/Ubuntu sudo yum install rsyslog -y RHEL/CentOS Configure rsyslog to accept remote logs sudo nano /etc/rsyslog.conf Uncomment or add: $ModLoad imudp $UDPServerRun 514 $ModLoad imtcp $InputTCPServerRun 514 Create a separate log file for PLC events echo 'if $fromhost-ip startswith "192.168.1." then /var/log/plc/plc.log' | sudo tee -a /etc/rsyslog.d/50-plc.conf Restart and enable sudo systemctl restart rsyslog sudo systemctl enable rsyslog Test by sending a test message logger -n 127.0.0.1 -P 514 "PLC Test Event: Login success"
2. The 6+1 Essential Events for OT Monitoring
Based on real incident data, the following events cover ~50%+ of ICS ATT&CK techniques and ~80% of impact scenarios:
– Login success
– Login failed
– Configuration change (including firmware upload/download)
– Program change (ladder logic, function blocks)
– Program start / stop
– PLC restart / reboot
How to capture these on Siemens S7 PLCs (using TIA Portal logging):
– Enable “Security logs” on the PLC hardware configuration.
– Forward logs via Syslog to your collector (set IP and port in device properties).
– For Rockwell Automation (ControlLogix): Use “FactoryTalk Audit” to log controller changes and forward to SIEM via Syslog or OPC UA.
3. Detecting Login Failures and Successes on PLCs
Most PLC compromises begin with credential abuse. Monitor authentication events on engineering workstations and direct PLC access logs.
Windows command to extract login events from engineering workstations (PowerShell as Admin):
Get successful logins (Event ID 4624) for the last 24 hours
$time = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624; StartTime=$time} |
Select-Object TimeCreated, @{n='User';e={$<em>.Properties[bash].Value}}, @{n='Workstation';e={$</em>.Properties[bash].Value}} |
Export-Csv -Path "C:\OT_Logins.csv" -NoTypeInformation
Get failed logins (Event ID 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625; StartTime=$time} |
Select-Object TimeCreated, @{n='User';e={$<em>.Properties[bash].Value}}, @{n='Reason';e={$</em>.Properties[bash].Value}}
Linux command to monitor SSH access to PLC emulators or jump hosts:
sudo ausearch -m USER_LOGIN -ts recent | grep -E "success|failed" sudo journalctl -u ssh --since "1 hour ago" | grep "Failed password"
4. Monitoring Configuration and Program Changes
Program and configuration changes are the primary vectors for logic bombs and process manipulation. Use file integrity monitoring on PLC project files and version control.
Set up AIDE (Advanced Intrusion Detection Environment) on a engineering file server:
sudo apt install aide -y sudo aideinit sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db Configure to monitor PLC project directories (e.g., /srv/plc_projects/) sudo nano /etc/aide/aide.conf Add line: /srv/plc_projects/ R sudo aide --check --report=file:/var/log/aide/aide-report.log Schedule daily cron job echo "0 2 root /usr/bin/aide --check --report=file:/var/log/aide/daily.log" | sudo tee -a /etc/crontab
Git version control for ladder logic exports (example for Rockwell L5X files):
cd /plc_backups git init git add .L5X git commit -m "Baseline PLC config" Detect changes automatically with a cron job: /30 cd /plc_backups && git diff --quiet || git add . && git commit -m "Auto-change $(date)" && git alert
- Real-Time Alerting for PLC Restarts and Program Stops
A PLC restart or program stop can indicate a crash, a denial-of-service attack, or a firmware update. Use SNMP traps or periodic polling.
Python script using pyModbus to poll PLC status and alert on restart:
from pyModbusTCP.client import ModbusClient
import time
import smtplib
PLC_IP = "192.168.1.100"
client = ModbusClient(host=PLC_IP, port=502, auto_open=True)
previous_uptime = None
while True:
try:
Read holding register with uptime seconds (vendor-specific address)
uptime = client.read_holding_registers(0x2000, 1)[bash]
if previous_uptime is not None and uptime < previous_uptime:
print(f"ALERT: PLC {PLC_IP} restarted at {time.ctime()}")
Send email alert (configure SMTP)
previous_uptime = uptime
except Exception as e:
print(f"Error: {e}. PLC may be stopped.")
time.sleep(60)
Windows scheduled task to check PLC reachability:
:check_plc.bat ping -n 1 192.168.1.100 > nul if %errorlevel% neq 0 ( echo %date% %time% PLC unreachable >> C:\OT_Logs\plc_down.log powershell -Command "Send-MailMessage -To '[email protected]' -Subject 'PLC Down' -From '[email protected]' -SmtpServer smtp.local" )
Schedule with `schtasks /create /tn “PLC_Health” /tr “C:\scripts\check_plc.bat” /sc minute /mo 5`
6. Building a Lightweight OT SIEM with ELK Stack
You don’t need expensive commercial SIEMs. Use Elasticsearch, Logstash, Kibana (ELK) to aggregate and visualize your 6 events.
Step‑by‑step installation on Ubuntu 22.04:
Install Elastic Stack wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - sudo apt install apt-transport-https echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list sudo apt update && sudo apt install elasticsearch logstash kibana Configure Logstash to parse syslog events sudo nano /etc/logstash/conf.d/plc-events.conf
input { syslog { port => 514 } }
filter {
if [bash] =~ /Login success/ { mutate { add_tag => ["login_success"] } }
if [bash] =~ /Login failed/ { mutate { add_tag => ["login_failed"] } }
if [bash] =~ /Configuration change|Firmware/ { mutate { add_tag => ["config_change"] } }
if [bash] =~ /Program change/ { mutate { add_tag => ["program_change"] } }
if [bash] =~ /Program start|Program stop/ { mutate { add_tag => ["program_start_stop"] } }
if [bash] =~ /PLC restart|reboot/ { mutate { add_tag => ["plc_restart"] } }
}
output { elasticsearch { hosts => ["localhost:9200"] index => "plc-events-%{+YYYY.MM.dd}" } }
Start services sudo systemctl start elasticsearch logstash kibana sudo systemctl enable elasticsearch logstash kibana Access Kibana at http://your-server-ip:5601
7. Mitigation and Hardening Against Internal Threats
Since most incidents come from internal mistakes or disgruntled engineers, harden access and enforce audit policies.
Windows Local Security Policy for engineering workstations (via PowerShell):
Enable auditing for account logon and object access auditpol /set /category:"Logon/Logoff" /subcategory:"Logon" /success:enable /failure:enable auditpol /set /category:"Object Access" /subcategory:"Detailed File Share" /success:enable Force PLC engineering software to require smart card or MFA Set-ItemProperty -Path "HKLM:\SOFTWARE\Siemens\TIA Portal\Security" -Name "RequireMFA" -Value 1
Linux-based jump host hardening for OT access:
Install and configure fail2ban to block repeated login failures sudo apt install fail2ban -y sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo systemctl enable fail2ban --now Force SSH key-only authentication and disable root login sudo sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config sudo systemctl restart sshd Log all commands executed by users (auditd) sudo auditctl -w /usr/bin/plc_upload -p x -k plc_change sudo auditctl -w /opt/plc_tools/ -p wa -k plc_config
What Undercode Say:
- Less data is more security: Focusing on six critical PLC events reduces noise and highlights real threats, contrary to the “collect everything” mindset.
- Internal threats dominate OT incidents: Most damage comes from authorized users making mistakes or abusing access; monitoring program changes and logins catches these before process disruption.
- Minimalist OT SIEM is achievable with open source: Using syslog, ELK, and native OS commands, any team can build effective monitoring without expensive commercial products.
Prediction:
As OT security matures, the industry will shift away from network-centric IDS towards process-centric monitoring that directly observes PLC logic and state changes. AI-driven anomaly detection will be applied to these six events, automatically correlating login failures with program changes to predict sabotage. Internal threat detection will become the top priority, leading to widespread adoption of immutable audit logs and real-time integrity verification for PLC firmware. Organizations that ignore this minimalist approach will continue to drown in alerts while missing the attacks that actually stop production.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zakharb How – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
