[BOOK] Industrial Control System Security(5/8) - Fundamental Understanding from an IACS UR E26 and E27 Certification Perspective
Chapter 5. Host Security — Explaining Visibility Required After Preventive Controls
1️⃣ Why does Chapter 5 appear at this point?
Looking at the flow of the previous chapters:
Chapter 1 → OT system characteristics
Chapter 2 → Network security
Chapter 3 → Host security
Chapter 4 → Attack scenarios
Up to this point, all content has been focused on prevention.
However, in cybersecurity, there is a well-known principle:
“Not all attacks can be prevented.”
Therefore, we must be able to answer the following question:
“When an intrusion occurs, how do we detect it?”
This is exactly the role of Logging / Auditing / Monitoring,
which is the main subject of Chapter 5.
2️⃣ Overall Flow of Chapter 5
The structure of Chapter 5 follows this logical sequence:
5.1 Purpose of Logging
↓
5.2 What logs are required?
↓
5.3 How are logs analyzed? (Use of SIEM)
↓
5.4 How do we respond when the logging system fails?
This flow corresponds directly to real-world security operations:
Log Generation → Log Collection → Log Correlation → Incident Detection
3️⃣ 5.1 Purpose of Logging in OT Environments
The essence of logging is:
“Recording events that occur within a system.”
However, from a security perspective, logs are not just records.
They serve three critical functions:
Attack detection
Incident analysis
Accountability (traceability)
From a cybersecurity perspective, logs are the core data for detection.
For example, consider the following events:
Login failure
Change in administrative privileges
PLC configuration change
Network scan
These events can be early indicators of an attack.
Logs provide answers to the following questions:
Who / When / What / Where / Why
Why Logging is More Important in OT
In IT environments, the following visibility sources typically exist:
EDR
Endpoint monitoring
Cloud telemetry
However, OT environments have the following constraints:
Restrictions on agent installation
Limited system resources
Prohibition of system changes
Therefore, in OT environments, logs often provide the only meaningful visibility.
Relationship Between Logging and UR E26 Testing
UR E26 includes the following test items:
Auditable Events
Audit Storage Capacity
Timestamp Accuracy
Response to Audit Processing Failures
These correspond to verifying the following:
Are logs generated?
Are logs stored?
Are logs timestamped accurately?
Can failures in the logging system be detected?
4️⃣ 5.2 Types of Logs in OT Environments
Logs in OT environments originate from more diverse sources than in IT.
① System Logs
Examples:
Windows Event Log
Linux syslog
These are the most fundamental logs from a security perspective and record:
Login events
Service execution
Account changes
Policy changes
② Network Logs
Network devices also generate logs.
Examples:
Firewall
Switch
VPN
ICS firewall
These logs provide information such as:
Connection attempts
Blocked traffic
Unusual port usage
③ ICS Device Logs
These are the most critical logs in OT environments.
Examples:
PLC events
HMI alarms
Controller state changes
These logs capture process-level events, which are fundamentally different from IT logs.
Examples:
Setpoint changes
Tag value changes
Mode changes
④ Historian Logs
A Historian system stores process data and generates logs such as:
Data collection failures
Communication timeouts
Abnormal data patterns
These logs are critical for detecting process anomalies.
⑤ Security Solution Logs
Examples:
Antivirus
Application control
IDS
These logs record:
Malware detection
Blocked processes
Suspicious network activity
5️⃣ 5.3 SIEM-based OT Monitoring
In large-scale OT environments, millions of events can occur daily.
Therefore, the following technology is required:
Security Information and Event Management (SIEM)
Basic Structure of SIEM
SIEM operates in the following stages:
Log Collection
↓
Normalization
↓
Correlation
↓
Alert Generation
↓
Security Analyst Investigation
Meaning of Correlation
Correlation means linking different logs together.
Example:
VPN login + EWS login + PLC configuration change
If these events occur together, it may indicate an attack.
Characteristics of SIEM in OT Environments
OT SIEM differs from IT SIEM due to the following characteristics of OT networks:
Communication patterns are highly consistent
Very little variation in normal traffic
Limited number of devices
Therefore, Anomaly Detection is highly effective in OT environments.
Examples:
PLC write command that does not normally occur
Unusual network path
Unexpected engineering workstation activity
6️⃣ 5.4 Response to Audit Failure
Logging systems can fail.
Examples:
Insufficient log storage capacity
Log server failure
Log collection failure
In such cases, attacks may go undetected.
Therefore, security standards require:
Audit Failure Detection
In other words:
If the logging system fails → an alert must be generated.
From an Operational Perspective
When logging systems fail, the following actions are required:
Administrator notification
Log buffering
Use of alternative storage
System status verification
Additional Considerations in OT
If logs are unavailable during an incident, the following cannot be determined:
When was PLC logic modified?
Who made the change?
Which workstation performed the change?
Therefore, preventing log loss is critical in OT environments.
7️⃣ Connection Between Chapter 5 and OT Security Operations
The core message of Chapter 5 is:
Security controls are divided into two types:
Preventive Control
Detective Control
Previous chapters mainly addressed preventive controls:
Segmentation
Firewall
Hardening
Authentication
Chapter 5 addresses detective controls:
Logging
Monitoring
Detection
8️⃣ Key Summary
The core flow of Chapter 5 is:
System Activity → Log Generation → Log Aggregation → SIEM Analysis → Security Alert → Incident Response
And in OT environments, the following characteristics apply:
Host visibility ↓
Network visibility ↓
Log visibility ↑
In other words:
Logs are the core data for OT security operations.
Comments
Post a Comment