Why Maritime Cybersecurity Became a System Engineering Issue (4/9)
Why Maritime Cybersecurity Became a System Engineering Issue (4/9)
Chapter 4: Understanding Why IACS Introduced E26 and E27
In Chapter 1, we explored how modern vessels are evolving into digital OT environments. In Chapter 2, we examined how increasing System Interdependency is making it more difficult to understand the behavior of the overall system by looking at individual CBSs alone. In Chapter 3, we discussed how these changes are transforming Cybersecurity from a matter of security controls into a System Engineering challenge.
"Why did IACS introduce the new requirements known as E26 and E27?"
Many people view E26 and E27 simply as Cybersecurity standards. While this perspective is not entirely incorrect, it does not fully explain why these requirements emerged in the first place.
When examining the background behind E26 and E27, it becomes clear that their purpose extends beyond introducing additional security functions. Rather, they represent an industry response to the new challenges that have emerged in the design, integration, operation, and verification of increasingly complex ship systems.
1. The Industry Needed More Than Security Features
In the past, shipboard systems often operated independently. As a result, equipment suppliers primarily focused on designing and validating their own products, while shipyards could satisfy most requirements by integrating individual systems together.
However, modern ship environments have changed significantly:
- Systems are interconnected
- Data flows across multiple CBSs
- Operational functions increasingly depend on the coordinated behavior of several systems
Under these conditions, the proper operation of individual CBSs alone is no longer sufficient to guarantee the reliability of the overall system.
2. The Industry Needed a Common Language
In real-world projects, shipyards and equipment suppliers often view the same system from different perspectives.
"Our equipment provides all required functions."
"Additional considerations are necessary from the perspective of the overall system."
The issue is not that either party is wrong — they are addressing different levels of the same problem. In modern ship environments, the following concepts are becoming increasingly important:
- System Boundary
- Trust Boundary
- Zone
- Interface
- Recovery
- Operational Dependency
3. The Industry Needed Better Visibility
Modern vessels continue to grow in complexity. Yet in many cases, visibility into how these systems actually behave remains limited:
- ▸ Operators may not fully understand the conditions required for normal system operation
- ▸ Shipyards may not have complete visibility into how a particular CBS exchanges data with other systems
- ▸ Suppliers may struggle to explain how their equipment interacts with the broader operational environment
As a result, questions such as the following frequently arise:
- Which systems are operationally critical?
- Which functions will be affected if a failure occurs?
- Through which paths can impacts propagate?
- Which functions should be restored first?
4. The Industry Needed More Predictable Recovery
When a Cybersecurity Incident occurs, the most important issue may not be the attack itself. More often, the critical questions are:
- Can operations continue?
- Can the vessel maintain a safe condition?
- Can recovery procedures be executed successfully?
In practice, situations such as the following may occur:
- ▸ A specific CBS becomes isolated
- ▸ Portions of the network are disconnected
- ▸ Certain functions become unavailable
Even under these circumstances, the vessel must continue operating safely. The answers to these questions are determined not at the level of individual CBSs, but at the level of the overall system formed by those CBSs.
5. The Industry Needed Verifiable Engineering
In the past, design documentation and functional testing were often considered sufficient. Today, however, the following questions are becoming increasingly important:
- Does the system behave as intended within the integrated environment?
- Have the design assumptions been verified?
- Can the recovery scenarios actually be executed?
- Do interfaces behave only in the intended manner?
These questions cannot be answered through documentation alone. They require actual verification.
6. E26 and E27 Are About Coordination
Many people describe E26 as a shipyard-focused requirement and E27 as a supplier-focused requirement. While this distinction is generally correct, there is a more important perspective to consider.
E26 and E27 provide a framework that enables different organizations to work toward the same objective:
Closing Remarks
IACS UR E26 and E27 are not simply collections of Cybersecurity requirements. Rather, they represent an industry framework designed to address practical challenges faced by modern vessels:
- Increasing system complexity
- Growing system interdependency
- Limited visibility
- Recovery challenges
- Greater verification needs
- Increased collaboration among stakeholders
The purpose of E26 and E27 is not merely to introduce new security functions.
Their broader objective is to provide a common foundation for making increasingly complex digital ship environments more predictable, understandable, and manageable.
Maritime cybersecurity professional specializing in IACS UR E26/E27 compliance, system engineering frameworks, and digital ship environments. Writing for engineers, consultants, and operators navigating Maritime 4.0.
🌐 Korean version: blog.naver.com/jiholew/224321574840
💼 LinkedIn: Jiho (Jay, 智晧) Lew
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment