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.
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.
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:
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 EnvironmentTest ConditionsTest StepsExpected 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.
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 ModelingCode ReviewVulnerability Scanning
9️⃣ 6.7 Maintenance & Verification Plan
Continuous Security
Security must be maintained after deployment — not just achieved at the point of certification.
· 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.
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.
Senior Manager at a global consulting firm specializing in Maritime Cyber Security, AI, and Data Analytics. 17+ years spanning shipbuilding R&D, AI product development, and maritime cyber compliance. Specializes in IACS UR E26/E27, IMO MSC guidelines, and smart ship development. Founder of ShipPaulJobs.
All content on ShipPaulJobs reflects direct field experience and operational insight from maritime cybersecurity practice. Select posts carry additional verification badges indicating independent review by our editorial team, technical advisory board, or industry partners.
Learn More →
🍪 이 사이트는 Google Analytics 및 Google AdSense 쿠키를 사용하여 사이트 이용 통계를 수집하고 맞춤형 광고를 제공합니다.
This site uses Google Analytics and Google AdSense cookies for usage analytics and personalized ads.개인정보 처리방침 / Privacy Policy
Comments
Post a Comment