Real-time maritime weather conditions including wind speed, wave height, barometric pressure and sea state — updated for the vessel's current position.
📡 Visitor Intel
Visitor intelligence panel — displays connection origin, language, timezone and maritime region context for site visitors.
🛰 Vessel & Fleet Analysis
Live AIS vessel tracking map — displays real-time positions of commercial vessels including cargo ships, tankers and bulk carriers operating in Korean and East Asian waters.
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:
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
Logs are not just records of events. From a security perspective, they serve three critical functions:
①
Attack Detection
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.
WhoWhenWhatWhereWhy
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.
Basic Structure of SIEM
Log Collection
→
Normalization
→
Correlation
→
Alert Generation
→
Analyst Investigation
①
Meaning of Correlation
Correlation means linking different logs together. Individually, each event may appear benign — but combined, they reveal an attack chain:
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 NotificationLog BufferingAlternative StorageSystem 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
Comments
Post a Comment