As part of its cyber security recommendations series, IACS issued a recommendation intended to clarify the need for developing contingency plans for the situation following a failure of onboard computer based systems and laying out expectations for the provision of systems and services that need to remain intact, in order for the crew to be able to respond appropriately.
-
- How to conduct proper software maintenance
- Efficient control of software dependent systems
- Contingency plan for onboard computer based systems
- Guidelines on ship board network architecture
- Data assurance of computer-based system onboard
- Protecting network systems onboard from cyber risks
- How to ensure proper operation of integration systems
- Developing an inventory list of computer-based systems
- Recommendations for remote access to onboard IT systems
The report notes that the shipowner has overall responsibility of developing the contingency plan based on essential information which should be provided by the associated system integrators and suppliers to enable effective contingency planning.
The Contigengy Plan should contain a set of predetermined instructions or procedures for how crews will detect, respond to and limit consequences of cyber incidents in a timely manner, and for how crews will recover the affected systems after securing the ship’s safety by suitable response actions.
In this context, the following response process in the event of a cyber incident should be taken into account:
- Detect a cyber incident and identify the failed system;
- Determine effective response options and take appropriate actions;
- Recover the failed system;
- Investigate and document the cyber incident;
- Evaluate the effectiveness of response options and update the contingency plan.
Meanwhile, the Contingency Plan should include the following information as a minimum:
- List of computer based systems covered by the Contingency Plan;
- System configuration and descriptions for systems covered by the Contingency Plan;
- Incident response plan;
- Recovery plan;
- Periodic testing plan;
- Maintenance procedure for the Contingency Plan;
The contingency plan should be formatted to provide quick and clear directions in the failure event for use of onboard personnel unfamiliar with the plan or the system. A concise and well-formatted plan reduces the likelihood of creating an overly complex or confusing plan.
Developing the Contingency Plan
At the initial stage of developing a contingency plan, IACS notes it is very important to identify and to include all computer based systems on board. The provision of application scope of contingency plan among all computer based systems on board should be clearly defined based on their effects in a failure situation. At a minimum, all Category III systems according to UR E22 should be included in the plan. Category II systems should be also reviewed, if specific provision for contingency needs to be available, such systems should be included in the plan.
Incident Response Plan
Typically when a cyber incident is discovered, a quick assessment is performed to evaluate the consequence and the options to respond. For example, one possible response option is to physically isolate the failed or malfunctioning system and to use the redundant system, or if not available, independent or local control may be another response option. To assist crews to find effective response options quickly and to take response actions in a timely manner the provision of systems to facilitate an incident response plan for the identified systems on board should be developed in clear, concise, and easy format to implement in the event of a failure.
The incident response plan should, as a minimum, include the following information:
- System for response and breakpoints;
- Alarm indication or abnormal symptom caused by a cyber incident;
- Failure consequence;
- Effective response options which do not rely on either shut down or transfer to independent or local control, if any;
- Independent or local control change over procedure;
Recovery Plan
Recovery plans should be easily understandable by the internal personnel and potential external personnel, and include essential instructions and procedures to ensure the recovery of a failed system and how to get external assistance if the support from ashore is necessary.
In addition, software recovery medium or tools essential for recovery on board should be available. When developing recovery plans, it is important to specify the recovery objectives for the various systems and subsystems involved.
There are two distinct types of objectives as below:
- System recovery: it involves the recovery of communication links and processing capabilities, and it is usually specified in terms of a Recovery Time Objective (RTO). This is defined as the time required to recover the required communication links and processing capabilities.
- Data recovery: it involves the recovery of data describing production or product conditions in the past and is usually specified in terms of a Recovery Point Objective (RPO). This is defined as the longest period of time for which an absence of data can be tolerated.
Once the recovery objectives are defined, a list of potential cyber incidents should be created and the recovery procedure developed and described. Recovery plans may be supported through access to the following information;
- Instructions and procedures for restoring the failed system without disrupting the operation from the redundant, independent or local operation.
- Processes and procedures for the backup and secure storage of information
- Complete and up-to-date logical network diagram
- The list of personnel responsible for restoring the failed system
- Communication procedure and list of personnel to contact for external technical support including system support vendors, network administrators, etc.
Explore more herebelow:
