📚 Book Review
IACS UR E26
Logging & SIEM
OT Detection
[BOOK] Industrial Control System Security (5/8)
Host Security — Explaining Visibility Required After Preventive Controls
⚓
Blue Horizonist
Maritime and Cyber Security Consultant / ISP Consultant
📅April 4, 2026
Book Information
Industrial Control System Security
Author: Pascal Ackerman · Published: 2019 · Korean Edition: Acon
Principal Industrial Cybersecurity Consultant @ Rockwell Automation (since 2015) · 15+ years in large-scale industrial systems & network security
Chapters 1 through 4 established a strong foundation in preventive controls — segmentation, hardening, authentication, and threat modeling. Chapter 5 completes this framework by addressing what happens after prevention: how do we detect intrusions through Logging, Auditing, and Monitoring? In OT environments where traditional endpoint visibility is constrained, logs are not merely records — they are the primary detection surface.
Chapter 5
Host Security — Visibility Required After Preventive Controls
1️⃣ Why Does Chapter 5 Appear at This Point?
Looking at the flow of the previous chapters, all content has been focused on prevention. However, in cybersecurity there is a well-known principle:
Ch.1 OT Characteristics
→
Ch.2 Network Security
→
Ch.3 Host Security
→
Ch.4 Attack Scenarios
→
Ch.5 Detection ✦
"Not all attacks can be prevented."
Therefore, we must be able to answer: "When an intrusion occurs, how do we detect it?"
This is exactly the role of Logging / Auditing / Monitoring, the main subject of Chapter 5.
→
In OT environments where EDR and cloud telemetry are unavailable, logs are often the only available detection surface.
2️⃣ Overall Flow of Chapter 5
The structure of Chapter 5 follows a logical sequence that maps directly to real-world security operations.
5.1
Purpose of Logging — Why logs are the core data for OT detection
5.2
Types of Logs — System · Network · ICS Device · Historian · Security Solution
5.3
SIEM-based Monitoring — Collection → Normalization → Correlation → Alert
5.4
Response to Audit Failure — What happens when the logging system itself fails
Log Generation → Log Collection → Log Correlation → Incident Detection
3️⃣ 5.1 Purpose of Logging in OT Environments
Logs are not just records of events. From a security perspective, they serve three critical functions:
Events such as login failures, privilege changes, PLC configuration changes, and network scans can be early indicators of an attack. Logs capture these signals before damage occurs.
→
Directly supports UR E26 Auditable Events test item — verifying that security-relevant events generate log entries.
②
Incident Analysis (Forensics)
After an incident, logs provide the timeline of events needed to understand attack vectors, affected systems, and the sequence of actions taken by adversaries.
③
Accountability (Traceability)
Logs answer the five fundamental security questions. Every action must be attributable.
Who
When
What
Where
Why
Sub-Section
Why Logging is More Important in OT
IT Environments
✓ EDR available
✓ Endpoint monitoring
✓ Cloud telemetry
OT Environments
✗ Agent installation restricted
✗ Limited system resources
✗ System changes prohibited
∴ In OT environments, logs often provide the only meaningful visibility.
Sub-Section
Relationship Between Logging and UR E26 Testing
| UR E26 Test Item |
What Is Verified |
| Auditable Events |
Are logs generated for security-relevant events? |
| Audit Storage Capacity |
Are logs stored with sufficient capacity? |
| Timestamp Accuracy |
Are logs timestamped accurately (NTP sync)? |
| Response to Audit Processing Failures |
Can failures in the logging system be detected and alerted? |
4️⃣ 5.2 Types of Logs in OT Environments
Logs in OT environments originate from more diverse sources than in IT. Understanding each source is essential for building a complete audit trail.
①
System Logs
Windows Event Log · Linux syslog — Login events, service execution, account & policy changes. The most fundamental logs from a security perspective.
②
Network Logs
Firewall · Switch · VPN · ICS Firewall — Connection attempts, blocked traffic, unusual port usage. Maps directly to Communication Integrity monitoring.
③
ICS Device Logs — Most Critical
PLC events · HMI alarms · Controller state changes — Setpoint changes, tag value changes, mode changes. These capture process-level events fundamentally different from IT logs.
④
Historian Logs
Data collection failures · Communication timeouts · Abnormal data patterns. Critical for detecting process anomalies at the IDMZ boundary.
⑤
Security Solution Logs
Antivirus · Application control · IDS — Malware detection, blocked processes, suspicious network activity. Supports Malicious Code Protection verification under UR E26.
5️⃣ 5.3 SIEM-based OT Monitoring
In large-scale OT environments, millions of events can occur daily. Security Information and Event Management (SIEM) is required to correlate and surface actionable alerts.
Correlation means linking different logs together. Individually, each event may appear benign — but combined, they reveal an attack chain:
VPN Login
+
EWS Login
+
PLC Config Change
→
⚠ ATTACK INDICATOR
②
Characteristics of SIEM in OT Environments
OT SIEM is more effective than IT SIEM for anomaly detection because OT network behavior is highly predictable:
→Communication patterns are highly consistent
→Very little variation in normal traffic
→Limited number of devices — smaller baseline to model
Anomaly examples: PLC write command not in baseline · Unusual network path · Unexpected EWS activity outside maintenance window
6️⃣ 5.4 Response to Audit Failure
Logging systems can fail. When they do, attacks may go completely undetected. Security standards require explicit mechanisms to detect and respond to these failures.
Common Audit Failure Scenarios
· Insufficient log storage capacity
· Log server failure
· Log collection pipeline failure
UR E26 requirement: If the logging system fails → an alert MUST be generated.
Operational Response Requirements
Administrator Notification
Log Buffering
Alternative Storage
System Status Verification
⚠ If Logs Are Lost During an Incident
? When was PLC logic modified?
? Who made the change?
? Which workstation performed the change?
These questions become unanswerable. Preventing log loss is not optional in OT environments.
7️⃣ / 8️⃣ Summary & UR E26 Linkage
Security Control Framework — Chapter 5 Completes the Picture
Preventive Control (Ch.1–4)
· Segmentation· Firewall· Hardening· Authentication
Detective Control (Ch.5) ✦
· Logging· Monitoring· SIEM / Correlation· Audit Failure Response
System Activity → Log Generation → Log Aggregation → SIEM Analysis → Security Alert → Incident Response
In OT environments: Host visibility ↓ · Network visibility ↓ · Log visibility ↑
Logs are the core data for OT security operations.
| Chapter 5 Topic |
UR E26 Test Item |
UR E27 Document Element |
| Log Generation |
Auditable Events |
Security Event Logging Plan |
| Log Storage & Retention |
Audit Storage Capacity |
Incident Response Support Info |
| Timestamp Sync (NTP) |
Timestamp Accuracy |
Time Synchronization Spec |
| SIEM / Correlation |
Auditable Events |
Security Monitoring Architecture |
| Audit Failure Detection |
Response to Audit Processing Failures |
Maintenance & Verification Plan
|
#ICSsecurity
#OTsecurity
#Logging
#SIEM
#IACS
#URE26
#AuditTrail
#MaritimeCyberSecurity
#DetectiveControl
#Maritime40
⚓
Captain Ethan
Maritime 4.0 · AI, Data & Cyber Security
Maritime professional focused on the intersection of vessel operations, classification society regulations, and OT/IT cybersecurity. Writing for engineers, consultants, and operators navigating Maritime 4.0 together.
Author: IN SUNG (Ethan) LEE
Follow insights on LinkedIn: https://www.linkedin.com/in/shipjobs/
🌐 More Articles ↗
Jiho Lew's LinkedIn Address
https://www.linkedin.com/in/%EC%A7%80%ED%98%B8-%EC%9C%A0-1b5823364/
Comments
Post a Comment