[BOOK] Industrial Control System Security(6/8) - Fundamental Understanding from an IACS UR E26 and E27 Certification Perspective

Analyst / Contributor :
📚 Book Review IACS UR E27 Documentation Security Architecture

[BOOK] Industrial Control System Security — Chapter 6

Documentation Fundamentals — Structuring Security into Verifiable Form

Blue Horizonist
Blue Horizonist (Lew)
Maritime & Cyber Security Consultant · ISP Consultant
📅May 10, 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

While previous chapters established technical controls — from network segmentation and host hardening to threat modeling and detection — Chapter 6 addresses a fundamental certification question: How do we prove that the system is actually secure? This chapter explains how to express security design through documentation that can be verified.

Chapter 6
Documentation Fundamentals — Structuring Security into Verifiable Form

1️⃣ Why Does Chapter 6 Appear at This Point?

All previous chapters focused on technical security design. Chapter 6 marks the transition to certification readiness.

Ch.1 OT Systems → Ch.2 Network → Ch.3 Host → Ch.4 Attack Modeling → Ch.5 Monitoring → Ch.6 Documentation ✦
The fundamental question in certification:

"How do we prove that the system is actually secure?"

→ In cybersecurity: If it is not documented, it does not exist. No matter how well a system is designed, without documentation the design intent cannot be verified.

2️⃣ Overall Structure of Chapter 6

The ten documents in Chapter 6 follow a logical security architecture lifecycle.

Security Architecture Lifecycle
System Definition
→
Architecture Description
→
Security Capability
→
Operational Security
→
Verification & Test
Phase Document
System DefinitionAsset Inventory
Architecture DefinitionTopology Diagram
Security Capability DefinitionSecurity Capabilities
Security OperationConfiguration / Maintenance
Incident ResponseIncident Response
Change ManagementManagement of Change
VerificationTest Procedure / Test Report

3️⃣ 6.1 Asset Inventory

Fundamental Principle
What are we protecting?

Asset Inventory is not just a list of devices — it answers:

· What systems exist?
· What functions do they perform?
· What networks are they connected to?
· What software is running?
From a Security Professional's Perspective

Asset Inventory is the foundational data for:

Risk Assessment Threat Modeling Patch Management Vulnerability Management
Without knowing PLC firmware versions, EWS patch levels, or protocols in use, vulnerability management is not possible.
Relation to UR E26/E27
Provides the baseline for identifying systems subject to testing: Communication Integrity · Malicious Code Protection · Authentication

4️⃣ 6.2 Topology Diagram

Fundamental Principle
Defines the Security Boundary — system boundaries and communication paths

Critical questions the Topology Diagram must answer:

→ Which systems communicate with which?
→ Through what paths does communication flow?
→ Where are the security control points?
Typical OT Architecture
Enterprise
↓
IDMZ
↓
Control Network
↓
Cell / Area
If the architecture is unclear:
✗ Security boundaries remain undefined
✗ Attack paths cannot be identified
✗ Network controls cannot be validated

5️⃣ 6.3 Description of Security Capabilities

Fundamental Principle
What security functions does the system provide?

Security capabilities must be explicitly described, including how they are implemented and configured.

🔐 Authentication
User authentication methods & password policies
🛡 Authorization
Role-based access control & privilege management
🔒 Encryption
Communication encryption & data protection
🦠 Malware Protection
Secure boot & firmware integrity verification
📋 Logging
Audit trail & security event recording
✅ Integrity Protection
Configuration integrity & change detection

6️⃣ 6.4 Test Procedure for Security Capabilities

It is not enough to claim that security functions exist.

A Test Procedure answers: How do we prove it works?

A Test Procedure Must Include:
Test Environment Test Conditions Test Steps Expected Results
Example — Authentication Test:
1 Create a test user account
2 Attempt login with valid credentials
3 Exceed the failed login attempt threshold
4 Verify account lockout behavior
Test Procedures form the basis for: Factory Acceptance Test (FAT) · Certification Test · Security Verification

7️⃣ 6.5 Security Configuration Guideline

Even if security functions exist, misconfiguration can render them ineffective. Configuration guidelines define the secure baseline for every component — equivalent to a Security Baseline in IT.
Configuration Items
· Password policies· Account privileges· Network service settings· Patch policies· Logging configurations
Industry References
· CIS Benchmarks· STIG Guidelines· IEC 62443-2-4· Vendor hardening guides

8️⃣ 6.6 Secure Development Lifecycle

Security by Design
Security must be considered from the design stage — not bolted on afterwards. Security validation must be performed at each stage of the development process.
Secure Development Process
Requirements
→
Design
→
Implementation
→
Verification
→
Release
→
Maintenance
Threat Modeling Code Review Vulnerability Scanning

9️⃣ 6.7 Maintenance & Verification Plan

Continuous Security
Security must be maintained after deployment — not just achieved at the point of certification.
Maintenance Plan
· Patch management· Vulnerability response· Backup / recovery· Periodic security checks
OT Specific
· Maintenance windows· Vendor patch validation· Process continuity planning

🔟 6.8 Incident Response Support Information

Security incidents are inevitable.
The system must answer: When an incident occurs, what do we do?
Detection
→
Containment
→
Recovery
→
Investigation
⚠ OT-Specific Considerations
→ Process safety during incident response
→ Shutdown procedures that preserve evidence
→ Forensic data collection from OT devices

1️⃣1️⃣ 6.9 Management of Change

In OT environments, change is the highest risk factor.
Every change — configuration, software, network modification — must follow a structured approval and verification process.
Change Management Process
Change Request
→
Impact Assessment
→
Approval
→
Implementation
→
Verification

1️⃣2️⃣ 6.10 Test Reports

Executing tests is not enough — you need evidence.
Test Reports are the documented proof that security capabilities were tested and verified. Critical during certification audits — the auditor must trace from claim to evidence.
Required Content Purpose
Test ScopeWhat was tested and what was out of scope
Test ProceduresHow each test was executed (reproducibility)
Test ResultsPass / Fail with observed behavior
Identified IssuesDeviations, non-conformances, gaps
Remediation ActionsHow issues were addressed before certification

1️⃣3️⃣ Key Summary of Chapter 6

Documentation Lifecycle Flow
System Definition
→
Security Architecture
→
Security Capability
→
Security Operation
→
Security Verification

Chapter 6 connects: Technology → Certification → Operation

Security design without documentation cannot be certified. Certification without documentation cannot be verified. This chapter provides the framework that bridges technical implementation with verifiable compliance.

#ICSsecurity #OTsecurity #Documentation #SecurityArchitecture #IACS #URE27 #SecurityCertification #MaritimeCyberSecurity #ManagementOfChange #Maritime40
Blue Horizonist
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.

Comments

Post a Comment