📚 Book Review IACS UR E27 Documentation Security Architecture

[BOOK] Industrial Control System Security — Chapter 6

Documentation Fundamentals — Structuring Security into Verifiable Form

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.

Ⅰ. Structure of This Volume

Chapter	Title
Chapter 1	The Nature of ICS/OT and the Security Paradigm
Chapter 2	ICS Network Architecture Fundamentals
Chapter 3	Host Security Fundamentals (IACS UR E26/E27)
Chapter 4	Threat Modeling — Attack Chain Structure & EWS Pivot
Chapter 5	Host Security — Visibility After Preventive Controls
Chapter 6	Documentation Fundamentals — Security into Verifiable Form
Chapter 7	Security Testing Fundamentals — Verifying Security Works
Chapter 8	OT Security Architecture & Deployment Fundamentals

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 Definition	Asset Inventory
Architecture Definition	Topology Diagram
Security Capability Definition	Security Capabilities
Security Operation	Configuration / Maintenance
Incident Response	Incident Response
Change Management	Management of Change
Verification	Test 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 Scope	What was tested and what was out of scope
Test Procedures	How each test was executed (reproducibility)
Test Results	Pass / Fail with observed behavior
Identified Issues	Deviations, non-conformances, gaps
Remediation Actions	How 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 (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.

🌐 More Articles ↗ 💼 LinkedIn ↗ ✍ Personal Blog ↗

📚 관련글 — ICS Security Series

📖

[BOOK] Industrial Control System Security(1/8)

Fundamental Understanding from an IACS UR E26 and E27 Certification Perspective

→ 📖

[BOOK] Industrial Control System Security(2/8)

Fundamental Understanding from an IACS UR E26 and E27 Certification Perspective

→ 📖

[BOOK] Industrial Control System Security(3/8)

Fundamental Understanding from an IACS UR E26 and E27 Certification Perspective

→ 📖