📚 Book Review
IACS UR E26
Security Testing
OT Security
[BOOK] Industrial Control System Security — Chapter 7
Security Testing Fundamentals — Verifying That Security Actually Works
Blue Horizonist (Lew)
Maritime & Cyber Security Consultant · ISP Consultant
📅May 29, 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 6 established the full spectrum of technical design and security documentation. Chapter 7 addresses the final validation question: Do the security functions described in the documentation actually work? This chapter explains the verification layer between design and certification — security testing as attack-scenario-based control validation.
Chapter 7
Security Testing Fundamentals — Verifying That Security Actually Works
1️⃣ Why Does Chapter 7 Appear After Documentation?
Up to Chapter 6, all content covered design and documentation. Chapter 7 marks the final step before certification readiness.
Ch.1 OT Systems
→
Ch.2 Network
→
Ch.3 Host
→
Ch.4 Attacks
→
Ch.5 Monitoring
→
Ch.6 Documentation
→
Ch.7 Testing ✦
The critical question in certification:
"Do the security functions described in the documentation actually work?"
→
Chapter 7 explains the verification layer between design and certification — where documented security claims become proven security controls.
2️⃣ Overall Structure of Chapter 7
Security testing is not just functional testing — it is about validating the effectiveness of security controls under attack conditions.
Testing Process Flow
Security Capability Identification
↓
Test Scenario Design
↓
Test Execution
↓
Result Verification
Security Perspective
Security Control
↓
Attack Simulation
↓
Expected Behavior Verification
Testing is not about checking functionality — it is about verifying how the system behaves under attack conditions.
3️⃣ Structure of Key Test Domains
UR E26-based security testing consists of the following domains, each aligned with real attack stages:
| Test Domain |
Meaning |
| Authentication | User identity verification |
| Authorization | Access control validation |
| Communication Security | Protection of communication integrity |
| Malicious Code Protection | Malware defense validation |
| System Integrity | Integrity verification |
| Audit & Logging | Logging functionality validation |
4️⃣ Authentication Testing
Fundamental Principle
Is the user really who they claim to be?
What Authentication Testing Validates
· Successful login conditions
· Handling of login failures
· Account lockout policies
· Password complexity
Typical Test Procedure
1 Attempt login with a valid user
2 Repeatedly enter incorrect passwords
3 Verify account lockout after threshold
This test ensures protection against brute-force attacks.
5️⃣ Authorization Testing
Fundamental Principle
If Authentication is "who the user is" — Authorization answers: What is the user allowed to do?
Authorization Testing Verifies Scenarios Such As:
· A standard user attempting administrative functions
· Attempts to modify unauthorized configurations
· An operator account attempting to modify PLC configuration
· A guest account attempting to access system settings
In all cases, the system must deny access appropriately.
6️⃣ Communication Security Testing
Fundamental Principle
Can communication be tampered with?
OT Communication Paths at Risk
HMI ↔ PLC
EWS ↔ Controller
Historian ↔ Control Network
What Is Verified
· Encryption of communication
· Message integrity
· Authentication of communication
Attack Scenarios Tested
· Packet replay
· Man-in-the-middle (MITM)
· Message modification
The system must be able to detect or prevent these attacks.
7️⃣ Malicious Code Protection Testing
Fundamental Principle
Can malicious code execute within the system?
What Is Verified
· Antivirus detection
· Application allow-list enforcement
· Script execution restrictions
Test Scenarios
· Execution of unauthorized executables
· Execution of suspicious scripts
The system must block or detect such activities.
8️⃣ System Integrity Testing
Fundamental Principle
System components cannot be altered without authorization.
Components Covered
Firmware
Configuration
Executable Files
What Is Verified
· Secure boot mechanisms
· Firmware validation
· Configuration protection
Test Procedure:
1 Attempt to modify system files
2 Attempt firmware changes
3 Verify system detects or rejects unauthorized changes
9️⃣ Audit & Logging Testing
Security events must always be recorded.
Without logs: attacks cannot be detected and incident analysis becomes impossible.
What Logging Testing Verifies
· Recording of login events
· Recording of privilege changes
· Recording of system modifications
Example Test Scenarios
· Login failure events
· Configuration changes
· User creation actions
The system must confirm that these events are properly logged.
🔟 Test Execution Environment
Security testing is difficult to perform in live operational environments. Therefore, a dedicated Test Environment is used — one that mirrors the real system without impacting actual operations.
🖥 Test PLC
Identical firmware & configuration to production
🔌 Simulated Network
Isolated topology matching production
💻 Test Workstation
EWS/HMI environment for test execution
1️⃣1️⃣ Mapping Security Testing to Attack Models
The attack stages from Chapter 4 map directly to the test domains in Chapter 7 — demonstrating that security testing is fundamentally attack scenario-based validation.
| Attack Stage |
Corresponding Test |
| Initial Access | Authentication |
| Execution | Malicious Code Protection |
| Privilege Escalation | Authorization |
| Credential Access | Authentication / Logging |
| Lateral Movement | Communication Security |
| Impact | System Integrity |
✅ Key Takeaway
Security testing in OT is not about verifying features — it is about validating how systems behave under attack conditions.
Security Testing = Attack Simulation + Control Validation
#ICSsecurity
#OTsecurity
#SecurityTesting
#PenetrationTesting
#IACS
#URE26
#AttackSimulation
#MaritimeCyberSecurity
#Maritime40
Blue Horizonist (Lew)
Maritime & Cyber Security Consultant · ISP Consultant
Maritime cybersecurity professional specializing in IACS UR E26/E27 compliance, supplier certification strategy, and Type Approval frameworks. Writing for engineers, consultants, and operators navigating Maritime 4.0.
📚 관련글 — ICS Security Series
Comments
Post a Comment