rules on cyber security for the classification of marine...

Rules on Cyber Security for the Classification of Marine Units

NR 659

Consolidated edition for documentation only

December 2019

This document is an electronic consolidated edition of the Rules on Cyber Security for the Classification of Marine Units, edition December 2019.

This document is for documentation only. The following published Rules are the reference text for classification:

• NR659 DT R00 E Rules on Cyber Security for the Classification of Marine Units December 2018

• NR659 DT Err E Erratum December 2019 December 2019

December 2019 Bureau Veritas

RULE NOTE NR 659

NR 659Rules on Cyber Security for the

Classification of Marine Units

Chapters 1 2 3 4

Chapter 1 GENERAL PRINCIPLES

Chapter 2 ADDITIONAL CLASS NOTATION CYBER MANAGED

Chapter 3 ADDITIONAL CLASS NOTATION CYBER SECURE

Chapter 4 SURVEY OPERATIONS

December 2018 with Errata 2019

CHAPTER 1GENERAL PRINCIPLES

Section 1 Classification Notations

1 General 11

1.1 General1.2 Classification notation

2 Definitions 11

2.1 Global terms2.2 Roles2.3 Systems and equipment terms

3 Documentation management 14

3.1

4 Documents to be submitted 16

4.1

5 Regulation and standards 16

5.1

Section 2 Cyber Risk Analysis

1 General 18

1.1 Framework1.2 Worlflow

2 Context establishment 20

2.1 Scope2.2 Inventory2.3 Process chain

3 Risk assessment 22

3.1 Criticality level3.2 Feared hazard3.3 Threats likelihood (K)3.4 Exposure (E)3.5 Human factor (H)3.6 Level (L)3.7 Risk calculation

4 Risk treatment 28

4.1 Residual risks

2 Bureau Veritas December 2018 with Errata 2019

CHAPTER 2ADDITIONAL CLASS NOTATION CYBER MANAGED

Section 1 General

1 General 33

1.1 Application

2 Document to be submitted 34

2.1 Methodology2.2 Documentation updates

Section 2 Equipment Management

1 Compliance policy 37

1.1 Components identification1.2 Compliance monitoring1.3 Compliance maintenance1.4 Compliance incident response

2 Equipment security 38

2.1 Equipment security settings2.2 Antivirus software2.3 Equipment maintenance2.4 Equipment monitoring2.5 Equipment incident response

Section 3 System Integration

1 Remote access 42

1.1 Usages1.2 Demilitarized Zone (DMZ)1.3 Traffic security1.4 Remote access monitoring1.5 Remote access maintenance

2 Wireless networks 45

2.1 Wireless identification

3 Cabled networks 46

3.1 Network identification

4 Networks 46

4.1 Network monitoring4.2 Network maintenance

December 2018 with Errata 2019 Bureau Veritas 3

Section 4 Vessel Management

1 Governance 48

1.1 Cyber risk analysis1.2 Cyber security policy1.3 Information protection

2 Roles and responsibilities 48

2.1 Management2.2 Predefined roles

3 Cyber operations 50

3.1 Operations management3.2 Monitoring policy3.3 Maintenance policy3.4 Incident response policy

4 Physical security 52

4.1 Management4.2 Vessel4.3 Removable and mobile medias

5 Change management plan 53

5.1 Management5.2 Change request5.3 Change approbation5.4 Change homologation5.5 Change validation


CHAPTER 3ADDITIONAL CLASS NOTATION CYBER SECURE

Section 1 Cyber Secure Class

1 General 57

1.1 Application1.2 Ship approval

2 Documents to be submitted 58

2.1 Documents for equipment2.2 Documents for the vessel2.3 Documents for security solutions2.4 Submitter

Section 2 Equipment Design

1 General 61

1.1 Application1.2 System integration1.3 Identification

2 Development 62

2.1 Context2.2 Development platform2.3 Development principles

3 Protection 63

3.1 Context3.2 Hardening3.3 Access3.4 Physical security

4 Verification 66

4.1 Context4.2 Equipment compliance4.3 Elements of integrity

5 Evaluation 68

5.1 Global5.2 Antivirus

6 Commutation 69

6.1 Network policy6.2 Industrial Control Systems (ICS)

7 Preservation 69

7.1 Context

8 Maintenance 70

8.1 Context8.2 Administration guide8.3 Operator guide


9 Monitoring 71

9.1 Architecture9.2 Events manager9.3 Investigation manager

Section 3 Vessel Design

1 Architecture 73

1.1 Principles1.2 Security mechanisms1.3 Design

2 Network 76

2.1 2.2 New-generation firewall2.3 Intrusion and prevention system

3 Systems 78

3.1 Cabinet protection

Section 4 Security Solutions

1 General 79

1.1 Application

2 Compliance and Software Registry (CSR) 80

2.1 Mechanisms2.2 Functionalities2.3 Maintenance2.4 Security mechanisms

3 Inspection and Decontamination Gate (IDG) 83


4 Events and Logs Recording (ELR) 85


Section 5 Vessel Management

1 General 87

1.1 Management1.2 Forensics


CHAPTER 4SURVEY OPERATIONS

Section 1 General

1 General 91

1.1 Survey1.2 Cyber survey manual

2 Initial inspection 92

2.1 Scope of survey

3 Annual survey 92

3.1 Scope of survey

4 Intermediate survey 92

4.1 Scope of survey

5 Class renewal survey 92

5.1 Scope of survey

Section 2 Monitoring Survey

1 General 94

1.1

2 Surveys 94

2.1 Compliance testing2.2 Compliance availability testing2.3 Equipment accounts testing2.4 Remote access events testing2.5 Wireless events testing

Section 3 Infrastructure Survey

1 General 96

1.1

2 Surveys 96

2.1 White box testing2.2 Cabled networks2.3 Remote access robustness2.4 Remote access logging2.5 Wireless networks robustness2.6 Black box penetration tests


Section 4 Equipment Survey

1 General 99

1.1

2 Surveys 99

2.1 Account security settings2.2 Operating systems security2.3 Features security settings2.4 Antivirus solution2.5 Software maintenance

Section 5 Maintenance Procedures Survey

1 General 102

1.1

2 Surveys 102

2.1 Recovery plan testing2.2 Compliance update2.3 Maintenance protection tests2.4 Wireless patch management


NR 659

Chapter 1

GENERAL PRINCIPLES

SECTION 1 CLASSIFICATION NOTATIONS

SECTION 2 CYBER RISK ANALYSIS


NR 659, Ch 1, Sec 1

SECTION 1 CLASSIFICATION NOTATIONS

1 General

1.1 General

1.1.1 Application

These requirements apply to design, construction, commis-sioning and maintenance of computer based systems wherethey depend on software for the proper achievement of theirfunctions. The requirements focus on the functionality of thesoftware and on the hardware supporting the software. Theserequirements apply to the use of IT (Information Technolo-gies) and OT (Operational Technologies), see [2.3.1], f),computer based systems which provide, communicate ortransport control, alarm, monitoring, safety or internal com-munication functions which are subject to classificationrequirements.

In addition, the Shipowner may specify other IT or OT sys-tems to be included in the scope of the notation.

These requirements apply to new building ships and toexisting ships.

1.1.2 Cyber risk analysis

A Cyber Risk Analysis methodology is proposed with astandard template detailed in Sec 2. This template andmethodology may be used by the Shipowner to perform theCyber Risk Analysis by himself or use a 3rd party contribu-tor in accordance with a recognized methodology.

1.1.3 Exclusion

Navigation systems required by IMO SOLAS Chapter V,Radio-communication systems required by IMO SOLASChapter IV, are not in the scope of this requirement. How-ever gateways and interfaces, when connected to the targetof evaluation, are to be included in the scope of thisrequirement.

Systems may be excluded according to the Cyber Risk Analysis.

1.2 Classification notation

1.2.1 General

The additional class notations CYBER MANAGED andCYBER SECURE may be assigned to ships or offshore unitswhose equipment and networks comply with the require-ments of this Rule Note.

For an automated approach of cyber security, CYBERSECURE class notation should be used.

1.2.2 CYBER MANAGED

CYBER MANAGED is a first level of cyber security. Itrequires human actions, a strong human organization and asignificant amount of procedures to achieve objective.

The CYBER MANAGED classification notation correspondsto compliance with a set of requirements dealing with:

• critical equipment

• management

• crew training

• remote access

• change management and

• system integration.

Note 1: CYBER MANAGED notation is a way to control securitywith manual procedures with minor impact for in-service vessels.

1.2.3 CYBER SECUREThe CYBER SECURE Classification notation corresponds tocompliance with a set of requirements dealing with:

• cyber management

• equipment, and

• vessel secure by design.

CYBER SECURE notation is a way to control security bymeans of automatic software. It requires dedicated techni-cal equipment for security. The class notation is assignedwith construction Mark ({ or [ or µ) in accordance withShip Rules, NR467, Pt A, Ch 1, Sec 2, [3].

Note 1: Since the requirements are mainly focused on designphase, this classification notation is more adapted for new con-struction than for in-service units.

2 Definitions

2.1 Global terms

2.1.1 The following general terms are used within this RuleNote:

a) Society means the classification Society with which theship is classed

b) Ship Rules means these Rules for the Classification ofSteel Ships (NR467) and documents issued by the Soci-ety serving the same purpose

c) Surveyor means technical staff acting on behalf of theSociety to perform tasks in relation to classification andsurvey duties

d) Survey means an intervention by the Surveyor forassignment or maintenance of class as defined in Chap-ter 4, or interventions by the Surveyor within the limitsof the tasks delegated by the Administrations

e) Approval means the review by the Society of docu-ments, procedures or other items related to classifica-tion, verifying solely their compliance with the relevantRules.


NR 659, Ch 1, Sec 1

2.2 Roles

2.2.1 The definitions described in [2.2.2] to [2.2.8] areused in this Rule Note for each stakeholder.

2.2.2 Master

The Master is in ultimate command of the merchant vessel.The Master is responsible for safe and efficient cyber opera-tions of the ship.

2.2.3 Cyber security office

The cyber security officer is the head of IT and OT security,driving the IT and OT security strategy and implementationforward whilst protecting the Shipowner from securitythreats and cyber-hacking. Operational compliance tostandards and regulations is the responsibility of the cybersecurity officer. This is a senior role and will commonlyinvolve directing a team and taking a seat on the manage-ment board. The cyber security officer is appointed by theShipowner and delivered in the Cyber Security Policy Ch 2,Sec 4, [2].

2.2.4 Cyber security responsible

The cyber security responsible is, onboard, the executiveresponsible for establishing and maintaining the class nota-tion Rules. This includes the entire scope of cyber securityaccess controls, procedures application, registry consist-ency, documentation updates, events detection, emergencyresponses, change management and follow-up indicators.For example this role could be hold by the Chief Engineerafter being trained or certificated. The cyber securityresponsible is appointed by the Shipowner and delivered inthe Cyber Security Policy Ch 2, Sec 4, [2].

2.2.5 Shipowner

The Shipowner is responsible for contracting the ship andowns the systems at vessel delivery. After vessel delivery, theOwner may delegate some responsibilities to the vesseloperating company.

2.2.6 Shypyard

The Shipyard is responsible of systems installation anddelivery

2.2.7 Vessel integrator

The vessel integrator is in charge of the cyber security of theunit. The vessel integrator is responsible of the integration ofsystems and equipment ordered by the shipyard or the Ship-owner. The scope of applicability covers OT, IT and com-puter networks. If there are multiple parties proposing pre-integrated systems (as many OT Suppliers generally do), thevessel integrator must pay attention to connections, networktunnels, remote accesses, vulnerability monitoring andequipment approvals. In accordance with the risk assess-ment he has the authority to accept or refuse equipment, aconnection or a software. The vessel integrator shall coordi-nate operations during the different stages of the vessel'slife: from design to in-service life. If there are multiple sys-tem integrators, the vessel integrator is in charge of theircoordination. The role of vessel integrator is under responsi-bility of the Shipowner or a third-party partner.

2.2.8 SupplierThe supplier is any contracted or subcontracted provider ofsystem components or equipment (hardware or software).The supplier is responsible for providing programmabledevices, sub-systems or systems to the shipyard. The sup-plier provides a description of the software functionalitythat meets the vessel integrator's specifications, the CYBERSECURE class Rules and applicable international ornational standards.

2.3 Systems and equipment terms

2.3.1 The following definitions are used in this Rule Notefor the various equipment and systems referred to in therequirements:

a) Administration workstation are industrial systems (OT)of Category A (Cat. A) dedicated to administration ofindustrial system, servers, firewalls, switches...

b) Ashore equipment: Refer to systems and equipment notpresent on the ship but used from on ground premises tocommunicate, monitor or control on-board systems andequipment, excluding airtime providers intermediateequipment.

c) Categories (Cat. A, Cat. B or Cat. C) define the nature ofthe equipment:• Cat. A are equipment operated thanks to a standard

operating system like Windows, Linux, Android ormacOS. For example, Cat. A are servers, virtualmachines, calculators, blade servers, workstations,terminals, tablets, smartphones and, generally, anyendpoint.

• Cat. B are equipment operated thanks to a dedicatedoperating system, linked to a dedicated firmware, underthe form of a specific appliance. Examples of Cat. Bequipment could be network equipment for TCP/IProuting, firewalls or network security equipment.

• Cat. C are industrial automation and control systems(IACS) operated thanks to a firmware. Cat C exam-ples are programmable devices (DCS, PLC, SCADA)or Safety Instrumented Systems (SIS).

In this document, we will refer to Category with the fol-lowing wording: Cat. A, Cat. B or Cat. C.

d) Engineering workstation are industrial systems (OT) ofCategory A (Cat. A) mostly stationary computers dedi-cated to industrial system process engineering.

e) Equipment are identifiable part of a system, which mayperform a specific function or a set of functions. Equip-ment may be software only, hardware only or a combina-tion of both. Equipment may be a computer, a laptop, anautomation, a programmable logic controller, a software,a virtualized environment with networks and software, anetwork firewall, a physical switch, a diode, a connectedobject or a mobile phone, etc. In this document, theword equipment will be exclusively considered.

f) Industrial systems: Industrial systems are known as usingOT (Operational Technologies). IT (Information Technol-ogies) and OT are two traditional areas used to distin-guish equipment. The requirements of this Rule Noteapply to both world and rules are globally written forboth environments. As OT system contain Cat. A and


NR 659, Ch 1, Sec 1

Cat B. equipment which come from IT world, rules havebeen unified and are still exhaustive. As Cat. C equip-ment are more OT system oriented, Cat. C rules willmostly apply to OT world. The borderline between ITand OT tends to fall down because of interconnections,manufacturers remote accesses, and internet of thingsindustry. For all those reasons, rules have been designedin order to be used both for OT and IT. For very specificcases, OT is stated in the rule.

g) Level: The level characterizes the exposure of a systemto cyber threats., and is determined with the Cyber RiskAnalysis. See definition in Cyber Risk Analysis terms[2.3.3].

Level: formula (L). Level is calculated by using likeli-hood and impact. Rules apply to equipment dependingof their level. Level 1 refers to unexposed equipment.Level 3 refer to very exposed equipment. Level 2 isintermediate.

h) Onboard equipment: Refer to any IT and OT systemsand equipment installed on the ship.

i) Operator console are industrial systems (OT) of Cate-gory A (Cat. A) mostly mobile systems involved inindustrial system process engineering and maintenance.

j) Systems are a combination of interacting programmabledevices and/or sub-systems organized to achieve one ormore specified purposes. Systems are generally con-nected through a dedicated network or a dedicatedVLAN. They are generally dedicated to a well-definedmission and localized in a distinct room space. How-ever, systems may be distributed with distant location,or sites, and connected through networks tunnels. Sys-tems may also be interconnected to other systems. Asystem is generally pre-integrated in that sense where itis developed, delivered and maintained by an individualSupplier. Of course, systems may also be a group of ele-ments integrated by the shipyard or the Shipowner to fillout a specific mission, service or function. Systems mayregroup different Categories of equipment. For example,a typical industrial controlled system regroups Cat. Cequipment like safety instrumented systems, Cat B. net-work switch and Cat. A workstation for SupervisoryControl And Data Acquisition (SCADA). In this docu-ment, the word system will be exclusively considered.

Note 1: Sub-systems are subcategories of systems. For the require-ments application, sub-systems are considered like systems.This is due to the fact that cyber security looks at connectionpoint between different levels of risks. Sub-systems wording isnot used in this document.

2.3.2 Cyber class notation terms

The following definitions of specific cyber security relatedterms are used in this Rule Note:

• Hardening of a system: The process of securing a systemby reducing its surface of vulnerability, which is largerwhen a system performs more functions; in principle asingle-function system is more secure than a multipur-pose one. Reducing available ways of attack typicallyincludes changing default passwords, the removal ofunnecessary software, unnecessary usernames or logins,and the disabling or removal of unnecessary services.

• Hash: Any function that can be used to map data ofarbitrary size to data of fixed size. The values returnedby a hash function are called hash values, hash codes,digests, or simply hashes. One use is a data structurecalled a hash table, widely used in computer softwarefor rapid data lookup.

• Monitoring: Human procedures used to monitor eventsrelated to cyber security of equipment and systems.

2.3.3 Cyber risk analysis termsThe following definitions are used this Rule Note in relationto the Cyber Risk Analysis, as detailed in Sec 2.

a) Attacker: formula (AT). Grade, from 1 to 5, whichdefines the requested competencies to successfullyachieve a feared hazard. Attacker is part of the humanfactor formula.

b) Complexity: formula (CX). Grade, from 1 to 3, whichqualifies depth of parameters, amount of technologiesand granted privileges of a system. Complexity is part ofthe exposure formula.

c) Connectivity: formula (CY). Grade, from 1 to 5, whichqualifies aperture of a system regarding accesses,exchanges and communications. Connectivity is part ofthe exposure formula.

d) Context establishment: It is a first step of the Cyber RiskAnalysis. This step defines mission and feared hazards(objectives). An inventory of process chain and equip-ment is also delivered. This step refines the scope ofapplication of these Rules by identifying vital functions.

e) Effect: Consequence of a feared hazard.

f) Exposure: formula (E). Score, from 1 to 5, to measure theattack surface of a system. Complexity and connectivityare part of the formula. Exposure is part of the likelihoodformula.

g) Feared hazard: Cyber security events which are suscep-tible to have a huge impact.

h) Human factor: formula (H). Score, from 0 to 4, to qual-ify non-technical elements susceptible to affect a cyber-event. Human factor is part of the likelihood formula.

i) Impact: formula (P). Impact qualifies effect of a fearedevent. Impact may be negligible, acceptable, unaccept-able, high or catastrophic.

j) Likelihood: formula (K). Odds of having appearance of afeared hazard. Likelihood is based on human factor andexposure. Likelihood is part of the level and risk formulas.

k) Original risk: The degree of risk from three degrees (neg-ligible, significant, unacceptable) of a feared hazardbefore application of security measures whose those ofthe class notation.

l) Process chain: Pieces of equipment which are used, as atechnical chain, to achieve a function.

m) Risk: formula (R). The degree of risk from three degrees(negligible, significant, unacceptable) of a feared hazardafter application of security measures.

n) Security measures: A list of technical or organisationalelements used to reduce probability of appearance offeared hazards. The requirements from this Rule Noteare security measures.


NR 659, Ch 1, Sec 1

o) Users: formula (U). Grade, from 1 to 4, which defines theawaited competencies to successfully counter a fearedhazard. Users is part of the human factor formula.

p) Vital functions is a short list of functions which are vitalfor the vessel's mission. Vital means both regardingoperational objectives of the vessel and regarding thesafety when managed by computer based equipment.

2.3.4 The following abbreviations/acronyms are used inthis Rule Note:AES : Advanced Encryption StandardAPT : Advanced Persistent ThreatCSR : Compliance and Software RegistryCVE : Common Vulnerabilities and ExposureDMZ : Demilitarized ZoneELR : Events and Logs RecorderFIM : File Integrity MonitoringFW : FirewallGUI : Graphical User InterfaceHTTP : Hypertext Transfer Protocol HTTPS : Hypertext Transfer Protocol SecureICS : Industrial Control SystemsIDG : Inspection and Decontamination GateIDS : Intrusion Detection SystemIOC : Indicator Of CompromiseIP : Internet Protocol IPS : Intrusion Prevention SystemIPSEC : Internet Protocol SecurityLAN : Local Area NetworkMAC : Media Access Control AddressNGFW : New Generation FirewallOSI : Open Systems Interconnection modelPLC : Programmable Logic ControllerRADIUS : Remote Authentication Dial-In User ServiceSIEM : Security Information & Event ManagementSNMP : Simple Network Management ProtocolSPI : State-full Packet InspectionSSH : Secure ShellSSL : Secure Sockets LayerTCP : Transmission Control Protocol TLS : Transport Layer SecurityVLAN : Virtual Local Area Network VPN : Virtual Private NetworksWAP : Wireless Access PointWLAN : Wireless Local Area NetworkWPA : Wi-Fi Protected Access.

3 Documentation management

3.1

3.1.1 RolesAll the documents to be delivered are under responsibilityof the vessel integrator which is in charge to identify them,collect them and keep the collection up to date.

3.1.2 Documentation formatDocumentation is provided in an electronic file with ahuman readable format.

3.1.3 Privacy and protection of filesFiles and/or numeric support are to be managed with a highsecurity level. Human readable files contain a header men-tioning the sensitivity level of the document.

Two levels of protection are used. The first level is SENSI-TIVE and the second one is CONFIDENTIAL.

For the SENSITIVE protection mark, the following rulesapply:• the files are not to be transmitted to unauthorized peo-

ple.• the files are not to be shared on public servers, public

cloud storage, internet web mails, internet web address,internet websites, internet file sharing websites or inter-net file repository websites.

For the CONFIDENTIAL protection mark, the followingrequirements apply in addition to those applicable for theSENSITIVE Level:• Files are kept in an encrypted and safe place both

onboard and within Shipowner premises: all materials,documents and elements are encrypted while stored onremovable media, endpoints (workstations, tablets, andsmartphones), servers, file servers or cloud storage.Accesses to those information require identification andauthentication mechanism.

• Files can be transmitted by using encryption procedures.When transferred, documentation is encrypted using astrong and dedicated encryption mechanism. Files arenever sent to internet public web address.

3.1.4 ApplicationVessel integrator is in charge to communicate its protectionpolicy to relevant parties. However each relevant parties isresponsible for the application of the protection policy.

3.1.5 Technical tests file formatTests are provided in an electronic file in a human readableformat (i.e. describing a survey procedure, a documentationto present, a registry to read, a command line test or a step-by-step procedure to follow in a screen interface…). Testsmay also include scripts or tools (in this case, they shall beexplained in the electronic document). Correspondingresults shall be described and explained. In example, a wayto detect generic logical accounts may be to use a com-mand line with grep or awk command-line utilities.

3.1.6 Privacy and protectionDocuments are protected according to [3.1.3].

At SENSITIVE Level:• Cyber Security Policy• Cyber Handbook• Cyber Registry• Equipment Administration Guide• Equipment Operator Guide• CSR User Guide• ELR User Guide.


NR 659, Ch 1, Sec 1

At CONFIDENTIAL Level:

• Cyber Risk Analysis

• Cyber Repository

• Cyber Survey Manual

• Equipment Security Mechanisms

• Vessel Cyber Design

• CSR Security Mechanisms

• ELR Security Mechanisms

• IDG Security Mechanisms.

3.1.7 Suppliers documentation

For Cat. A, Cat. B and Cat. C equipment, different docu-ments are to be provided by the Supplier under control ofthe vessel integrator. A particular attention to the quality ofthe documentation is required.

Moreover those documents are to be followed up by thevessel Integrator in order to get new versions in case of newissue. Equipment documentation writing is under Supplierresponsibility. Specific elements, configuration or modelsused for the Equipment or the System are to be detailed.

3.1.8 Workflow

The following workflow and steps hereafter described (seealso Fig 1) is to be followed in order to grant one of the addi-tional class notation CYBER MANAGED or CYBER SECURE:

• The first step is about Cyber Risk Analysis writing whichis used to output scope of systems to work on. Thisscope is defined by the qualification of Feared Hazardsand Levels of criticality of equipment.

• The second step is to describe the systems and equip-ment in the Cyber Repository document, as defined in[4.1.3]. For the CYBER SECURE notation, it is an interac-tive process as the definition impacts the design andthus, the Equipment.

• The third step consists in collecting information aboutthe maintenance of Equipment, such as guides and pro-cedure.

• The fourth step is to set up the Cyber Security Policy, asdefined in [4.1.2]. This is composed of human, organi-sational and technical procedures to use, protect andmonitor the systems, taking into account the CyberRepository and Cyber Handbook.

• The fifth step, is the Cyber Survey Manual which con-tain step-by-step procedures on systems and monitoringsurveys. This document is to be based on the CyberHandbook procedures.

• The last step is the Cyber Registry delivery which is notdirectly written during the class notation application.This document is empty but filled during vessel's lifeand used during surveys.

Figure 1 : Documentation delivery workflow

CYBER RISKANALYSIS

quality

Feared Hazards(of the vessel)

define

Risk(of Feared Hazards)

Level(of criticality of equipment)

Scope(of systems)

CYBERREPOSITORY

CYBER SECURITYPOLICY

CYBER SURVEYMANUAL

CYBER REGISRY

CYBERHANDBOOK

is described in is managed by

are used by

defineMonitoring

Survey

trace

protect

efficienty control usage control

integrity control


NR 659, Ch 1, Sec 1

4 Documents to be submitted

4.1

4.1.1 Cyber risk analysisThe Cyber Risk Analysis is a document which, when issued,is updated during the whole life of the ship during majormaintenance phase like system upgrades. To add, delete,modify or update an equipment will impact the Cyber RiskAnalysis. The Cyber Risk Analysis is under responsibility ofthe Shipowner.

4.1.2 Cyber security policyCyber Security Policy is the main document for cyber secu-rity and cyber operation of the vessel in operation. This doc-ument is under responsibility of the Shipowner. It detailsrules and roles. It is used as a reference for any action onsystem and equipment by the crew members. The cybersecurity responsible is in charge to check and verify that theCyber Security Policy is in place and applied by crew mem-bers and external partners. This document is to be printedon board and available at any time.

4.1.3 Cyber repositoryThe Cyber Repository contains elements, like securitymechanisms, regarding systems and equipment inventories,expected and unexpected changes regarding hardware orsoftware and configuration to apply on those assets.

The Cyber Repository is under responsibility of the cybersecurity Officer. He is in charge to keep it updated duringthe vessel lifecycle and to check the pertinence, quality andexhaustiveness of information.

The Cyber Repository contains administration tasks whichrequire the highest level of privilege.

Administration tasks are dedicated to administration of theequipment. Administration operations are used in specialcase only like forensic investigation or software update.

The Cyber Repository is stored and managed ashore.

The Cyber Repository is not to be stored onboard.

4.1.4 Cyber handbookThe Cyber Handbook contains procedures regarding cybersecurity management of systems and equipment. It is usedto maintain the ship in a proper cyber state.

The Cyber Handbook procedures are under the responsibil-ity of the cyber security responsible.

The Cyber Handbook contains operator tasks which requirethe intermediate level of privilege.

Operator tasks are dedicated to operational administrationand maintenance of the equipment. Operator actions aretypically account creation, system backup and so on.

The Cyber Handbook is stored and used onboard.

A Cyber Handbook is also to be delivered for ashore systems.

4.1.5 Cyber registryThe Cyber Registry is under the responsibility of the Master.

Each action, event or operation regarding equipment andsystems is recorded and traced in this document.

Maintenance history and issues of Information Technologiesand Operational Technologies Systems and Equipment arerecorded and traced in this document.

The Cyber Registry may be in paper (i.e. logbook) or elec-tronic format (i.e. database), stored onboard and, or, ashore(i.e. in the remote operation centre), searchable onboardand ashore, filled manually (i.e. recording of digital assetsarrivals and departures), semi-automatically (i.e. copy andpaste operations) or automatically (i.e. syslog).

The cyber security responsible is in charge to keep itupdated in operation and to ensure exhaustiveness of infor-mation.

4.1.6 Cyber survey manualCyber Survey Manual contains tests dedicated to the equip-ment and/or its system. Those tests are performed within thevessel to verify both functional requirements and securitymechanisms implementation.

Requirements about Cyber Survey Manual are defined inChapter 4 of this Rule Note.

5 Regulation and standards

5.1

5.1.1 PurposeFor the purpose of application of this Rule Note, the stand-ards listed in [5.1.2] could be used for:• the development of hardware or software of computer

based systems• the connection between systems and the global vessel

integration• the design of the Cyber Risk Analysis• the management of the vessel and the crew members.

5.1.2 List of standards• ANSSI Cybersecurity for Industrial Control Systems:

Classification + Detailed Measures• ANSSI EBIOS (Expression des Besoins et Identification

des Objectifs de Sécurité)• ANSSI-DAT-NT-003-EN/ANSSI/SDE/NP: Recommenda-

tions for securing networks with IPsec• BV-SW-200 / 20170609: Bureau Veritas LIST CEA Tech,

Cybersecurity Guidelines for Software Development &Assessment

• CIS-Benchmarks: Centre for Internet Security guidelinesto protect systems & platforms

• ENISA BS 7799-3 (Information security managementsystems)

• IACS UR E22: International Association of ClassificationSocieties On board use and application of computerbased systems - Rev.2 June 2016

• IACS No. 153 Recommended procedures for softwaremaintenance of computer based systems on board

• IACS No. 154 Recommendation concerning manuallocal control capabilities for software dependentmachinery systems

• IACS No. 155 Contingency plan for onboard computerbased systems


NR 659, Ch 1, Sec 1

• IACS No. 156 Network Architecture• IACS No. 157 Data Assurance• IACS No. 159 Network Security of onboard computer

based systems• IACS No. 160 Vessel System Design• IACS No. 161 Inventory List of computer based systems• IACS No. 162 Integration• IACS No. 163 Remote Update Access• IACS No. 164 Communication and Interfaces• IMO MSC-FAL.1: International Marine Organisation -

Guidelines on Maritime Cyber Risk Management -Circ.3 - 5 July 2017

• ISO/IEC 27005:2008 (Information security risk manage-ment)

• ISO/IEC 15408: Common Criteria for Information Tech-nology Security Evaluation is an international standardfor computer security certification. It is currently in ver-sion 3.1 revision 5

• ISO/IEC 27001: Information Security Standard, part ofthe ISO/IEC 27000 family of standards, of which the lastversion was published in September 2013. It specifies amanagement system that is intended to bring informa-tion security under management control and gives spe-cific requirements

• NIST SP 800-39 (Managing Information Security Risk)

• NIST 800-137: Information Security Continuous Moni-toring (ISCM) for Federal Information Systems andOrganizations as part of a directive from the FederalInformation Security Management Act (FISMA).


NR 659, Ch 1, Sec 2

SECTION 2 CYBER RISK ANALYSIS

1 General

1.1 Framework

1.1.1 Objective

The objective of the Cyber Risk Analysis is to reduce thevolume and the impact of cyber incidents during the wholelife cycle of the vessel.

The application of CYBER MANAGED or CYBER SECUREnotation contributes to the reduction of the identified risks.

The Cyber Risk Analysis does:

• enhance technical and human processes to reduce risks

• contribute to the risk management of the Shipowner.

The Cyber Risk Analysis does not:

• develop nor propose a management solution regardingsecurity of information (as it is already defined in theclass notation)

• certify nor homologate vessel's system

• deliver an information security policy (as it is underShipowner responsibility).

1.1.2 Update

The Cyber Risk Analysis is to be updated with the vesselduring any changes regarding the infrastructure, the archi-tecture, the networks, the physical implementation of anysystem and equipment. The Cyber Risk Analysis lifecycle isintegrated to the Change Management Plan (as required inCh 2, Sec 4, [5.3.1]) in the Cyber Security Policy.

The Cyber Security Policy specifies the need for update asdefined in Ch 2, Sec 4, [1.1.1].

1.1.3 Delivery

The Cyber Risk Analysis document is to be submitted by theShipowner to the Society, for approval.

The Shipowner is responsible of the Cyber Risk Analysisresults, application and mitigation measures.

The Cyber Risk Analysis applies both for IT and OT systems.

The whole vessel is in the scope of the Risk Analysis as eachSystem shall be checked in order to evaluate its complexity,connectivity and, thus, criticality.

The Cyber Risk Analysis can be written:

• by the vessel integrator itself

• by a third-party partner.

1.1.4 Methodology

The Cyber Risk Analysis may be performed in accordancewith the methodology proposed in this Section or thoselisted in [1.1.5].

1.1.5 Other recognized methodologies

The following other methods may be used:

• ANSSI EBIOS (Expression des Besoins et Identificationdes Objectifs de Sécurité)

• ENISA BS 7799-3 (Information security managementsystems)

• ISO/IEC 27005:2008 (Information security risk manage-ment)

• NIST SP 800-39 (Managing Information Security Risk).

However the evaluation of the Level of equipment requiredin [3.6.3] is to be delivered for every equipment included inthe Scope of application defined in [2.3].

1.2 Worlflow

1.2.1 Objective

The Cyber Risk Analysis is divided into 3 steps:

• Context establishment: identifies values on which thescope of the notation strictly apply to (see Fig 1). Aninventory of process chain and equipment is also deliv-ered. This step defines the scope of application of theclassification notation.

• Risk assessment: evaluates threats and security measuresby measuring impacts and likelihoods.

• Risk treatment: identifies either mitigation measures orresidual risks, if any.

Figure 1 : Cyber risk analysis workflow

IDENTIFY Context establishment

EVALUATE Risk assessment

TREAT Risk treatment

FEARED EVENTSPROCESS CHAINSEQUIPMENT

THREATSMEASURES

MITIGATIONDECISION


NR 659, Ch 1, Sec 2

1.2.2 Principle

There are different ways to consider the risk management asit may be used to address different kind of objectives. TheCyber Risk Analysis requested in this notation measures theresidual risks regarding feared hazards and, in conclusion,helps the Shipowner to take a decision about mitigationmeasures to install (see Fig 2).

The entry point is thus the vessel's missions which needvital functions to operate but wish to avoid feared hazards.Vital must be understood here as regarding both operationalobjectives of the vessel and the safety when managed bycomputer based equipment.

Vital functions are achieved through process chains whichare exposed to threats. Threats are ways to exploit thefeared hazards. So, threats affect the risk.

The risks are then reduced by using the already existingsecurity measures listed from:

• organizational and human monitoring proceduresdefined in Cyber Security Policy document whose rulesare shaped from the requirements rules defined in thisdocument.

• survey operations used to control both monitoring oper-ations and equipment themselves. Survey operations are

defined in the Cyber Survey Manual whose requirementsare derived from the requirements defined in this docu-ment for the applicable classification notation.

• When CYBER SECURE notation is assigned:

- equipment monitoring automation which reinforcethe efficiency of monitoring operations

- equipment secured by design and vessel's infrastruc-ture rules which harden IT and OT equipment

- equipment survey increases the level of confidenceregarding the security of the equipment and, at theend, decreases the likelihood of feared hazards

- other vessel or Shipowner security measures, bothtechnical and procedural, which are not included inthe class notation nor in the Cyber Security Policy.

The residual risks are then mitigated by using decisionexplained in the Cyber Risk Analysis.

1.2.3 Table of contents

The Cyber Risk Analysis may be delivered by using theguiding thread of this Section. The guiding thread of thisSection is summarized in Tab 1.

Figure 2 : Cyber risk analysis overview

1CONTEXTESTABLISHMENT

2

RISKASSESSMENTPART A

«THREATS»

3

RISKASSESSMENTPART B

«MEASURES»

4RISKTREATMENT

Vital functionsVessel’s mission

Threats likelihood

Process chain

Scope of systems

RiskFeared hazards

Incident response

Residual risk

needachievethrough

Class Notation Security Measures

CYBERSECURE

{

CYBERMANAGED

Monitoring

define

protect

hardenautomatize

CYBER SECURITYPOLICY

CYBER SURVEYMANUAL

wishto avoid

exploited byconstitute

controlcontrol

rely on

sanitizeshapehandle


NR 659, Ch 1, Sec 2

Table 1 : Table of contents of a cyber risk analysis

2 Context establishment

2.1 Scope

2.1.1 MissionAs an introduction, the Cyber Risk Analysis summarizes stra-tegic elements regarding the context of risk of the vessel:

• define external context of usage (i.e. remote controlled,autonomous systems, remote maintenance, IT manage-ment, passenger WiFi, etc.) and relevant risks regardingconfidentiality, integrity or availability.

• define internal context (i.e. IT & Cyber resources, ITlinks, company strategic objectives, contractual externalactors, identified internal risks, top view of sources ofrisks from IT users, etc.).

The first part is used to identify the challenges to face. Thosechallenges may apply both on OT safety systems using com-puter based equipment (i.e. propulsion) and on IT systemsinstalled onboard and having an impact in term of effi-ciency of the vessel-s mission (i.e. passengers services).

2.1.2 Vital functionsBy using external and internal challenges developed in[2.1.1], vital functions are identified, selected and justifiedby the Shipowner. Those vital functions may for exampleconcern:

• confidential information (i.e. performances, fuel con-sumption)

• OT systems (i.e. propulsion systems)

• personal information (i.e. medical)

• safety systems (i.e. dynamic positioning).

In order to achieve this objective, the study may start withan exhaustive approach of large and general groups, fol-lowed up with a selection of vital functions. The objective isnot to deliver an exhaustive list of functions as vital but todeliver a list of indisputable vital functions whom criticalityhas been established as a priority.

For remote access type of connections, refer to Ch 2, Sec 3,[1.1.1].

Schemes of vital functions workflows may be attached (i.e.remote assistance workflow).

2.2 Inventory

2.2.1 TermsRefer to Sec 1, [2.3.4] for a definition of terms.

2.2.2 Onboard equipmentOnboard equipment listing relies on the software inventoryas detailed in Ship Rules, NR467, Pt C, Ch 3, Sec 3, [4.5].The detailed software inventory is an input for the CyberRisk Analysis.

2.2.3 Onboard systemsWhen an equipment if part of a pre-integrated system (multi-ple equipment as defined in Ship Rules, NR467, Pt C, Ch 3,Sec 3, [8.1]), the system is to be detailed equipment perequipment.

The category of each equipment is to be specified inaccordance with the definition from Sec 1, [2.3.3] defini-tion.

Cat. A equipment used into OT systems (Operational Tech-nology) are inventoried and labelled in one of the three fol-lowing category:

• engineering workstation (mostly stationary computersdedicated to industrial system process engineering)

• operator console (mostly mobile systems involved inindustrial system process engineering and maintenance)

• administration workstation (dedicated to administrationof industrial system, servers, firewalls, switches...).

Each equipment is to be linked to those inventoried in thesoftware registry (Ship Rules, NR467, Pt C, Ch 3, Sec 3about system administration guide).

Tab 2 presents an example of onboard system table.

2.2.4 Ashore equipmentAshore equipment are identified by using Ship Rules,NR467, Pt C, Ch 3, Sec 3, [4.5]. The detailed inventory isbuilt and delivered as an input.

2.2.5 Ashore systemsEquipment installed ashore and used for IT and OT remotecommunications are listed in the same way than onboardsystems [2.2.3].

Ashore systems are to be detailed in a separated table.

Tab 3 presents an example of ashore system table.

Chapter Reference

IDEN

TIFI

CA

TIO

N

Scope

Mission [2.1.1]

Vital functions [2.1.2]

Inventory

Onboard equipment [2.2.2]

Onboard systems and architecture [2.2.3] [2.2.6]

Ashore equipment [2.2.4]

Ashore systems and architecture [2.2.5] [2.2.6]

Process chain [2.3]

RIS

K A

SSES

SMEN

T

Feared hazard

Feared hazards and impacts [3.2.5]

Threats likelihood

Likelihood score [3.3.4]

Level of equipment [3.6.3]

Evaluation

Risk assessment [3.7.5]

Conclusion

Decisions on risks [4.1.2]


NR 659, Ch 1, Sec 2

Table 2 : Example of onboard systems table

Table 3 : Example of ashore systems table

Figure 3 : Example of system architecture

2.2.6 System architecture

For each system, a detailed drawing presents equipmentinstalled within the system. Local connections, externalinterconnections and data transportation over the networksare to be detailed (see Fig 3).

2.3 Process chain

2.3.1 Systems and equipment are linked to the vital func-tions. The objective of process chain is to identify equip-ment which are essential to deliver the services of the vitalfunctions.

A logical and a physical scheme develop the process chainof each vital functions (i.e. ground computer, satellite link,vessel IT router, vessel VLAN over the IP network, OT fire-wall, SCADA computer, automation) (see Fig 4).

Table 4 : Process chain table example

Figure 4 : Process chain example

The chain of equipment is to be detailed in a table by usinga logical chain of succession.

A brief description of the chain is explained. Example pre-sented in Tab 4 could be described as for example like this:“On Some System, the Engineering Workstation retrievesinformation from the PLC every hour. The PLC sends infor-mation to PC via Modbus protocol. Then, the workstationsends information through HTTPS to the DMZ via VLAN 1managed and operator by switch X. In the control center,the secondary display console connects to dedicated switchon VLAN D. It gets through firewall and send HTTPSrequest to DMZ on user demand”.

TypeEquipment category

IT OT

ITServer A -

Client A -

Some system

Switch - B

PLC - C

PC - A

Laptop - A

Remote link

Modem B -

Firewall B -

DMZ A -

Switches B -

... ... -

Type Category

Control center Modem B

Firewall B

Authentication A

VPN A

... ...

PLC x 10

Maintenancelaptop

Engineeringworkstation

Type Category Location

Some system

PLC OT C Onboard

Switch OT B Onboard

PC OT A Onboard

Network Switch X IT B Onboard

Remote link

DMZ IT A Onboard

Firewall IT B Onboard

Modem router IT A Onboard

Control center

Modem router IT B Ashore

Firewall IT B Ashore

Switch VLAN D IT A Ashore

PC Display IT A Ashore

Private network

Firewall

Modem routerVLAN 1

PLC x 10

Engineeringworkstation

VLAN D

Secondarydisplay

OT

Some onboard system

IT

Onboard network

Ashore network

DMZ server

Modem router


NR 659, Ch 1, Sec 2

3 Risk assessment

3.1 Criticality level

3.1.1 DefinitionThe level of criticality of an equipment is referred to as“Level” in this Rule Note.

The Level does not take into account the benefits of securitymeasures applied by the class notation. On the contrary, theamount and the quality of security measures and applicablerequirements to be implemented on the equipment, the sys-tem and, or, the human processes depend on the assignedLevel (see Fig 5).

Figure 5 : Scale of criticality

Levels (Level 1, Level 2 or Level 3) apply to each system anddescribe the critical level of the systems. Level 3 is the high-est Level of criticality. An upper level means more manda-tory rules with required documentation deliveries fromSuppliers, Shipyards and Shipowners.

Level is referred with the following wording: Level 1, Level2 or Level 3.

Each equipment and system is classified by assigning of the3 following levels, depending of their exposure, conse-quences and threat.• Level 1: IT or OT systems for which risk of attack is low.

May be connected. They are supervised.• Level 2: IT or OT for which risk of attack is significant.

Mandatory and specific rules appear.• Level 3: IT and OT systems for which risk of attack is

high. Use of dedicated procedures, systems or functionsappear.

3.1.2 Level assignmentSystems are associated to a Level by using the methodologydescribed in [3.1.3].

Each equipment inside a system inherits the Level of its par-ent system. This rule may be subject to exceptions whendemonstrated to the satisfaction of the Society.

Level 1 rules are generally considered as recommendationor options.

3.1.3 MethodologyThe criticality level (Level 1, Level 2 or Level 3) is calcu-lated depending on 2 parameters: Likelihood and Impact(see Fig 6). • The likelihood considers user access and considered

skill level of the attacker, and is subdivided in the twofollowing indexes:- exposure, taking into account the connectivity and

complexity of the system

- human factor, taking into account the risks comingfrom users and external, malicious users.

• Impact is related to the feared hazards and their conse-quences on the vital functions, as detailed in [3.2].

3.2 Feared hazard

3.2.1 Objective

This step analyses impact on vital functions by developingscenarios of feared hazards and of their consequences inorder to determine the impact index. These scenarios are tobe summarized by means of a table (see Tab 5), to be sub-mitted for information.

3.2.2 Hazards

Each scenario is presented and briefly developed in order tohelp to determine, evaluate and justify score of impact.

Operational and practical situations are preferred to globalor general approaches.

3.2.3 Effects

The Shipowner shall consider the following effects:

• Operational effects

- Impacts on the mission: direct or indirect impactregarding the vessel's mission (i.e. service cannot bedelivered anymore, loss or disclosure of information,loss of control on automation, etc.) at sea or at quay.

- Impacts on command chain: direct or indirectimpact regarding the vessel's control (i.e. unusablesystems, equipment encryption, vessel hijacking,etc.) at sea or at quay.

• Human effects

- Direct or indirect consequence on integrity of thepersons (i.e. divers' injury while undersea, loss ofwalkway stability during people transfer, air-condi-tioning system disruption, etc.).

• Shipping effects:

- Direct or indirect consequence on integrity of thegoods (i.e. loss of containers, loss of safety protec-tion for hazardous materials, etc.).

• Financial effects:

- Direct or indirect financial consequences (i.e. loss ofcorporate image, loss of customers, discounts, fines,insurance premium accrual, etc.)

Figure 6 : Level of criticality components

Critical LEVEL 3

LEVEL 2

LEVEL 1

Significant

Harmless

LEVEL (of criticality, of risk) (L)

Likelihood (K)

Exposure(E)

Human factor(H)

Impact(P)

Connectivity (CY)

Complexity (CX)

User (US)

Attacker (AT)

Fearedhazard


NR 659, Ch 1, Sec 2

3.2.4 Impact (P)The impact index P is determined according to the follow-ing definitions:• Impact 1 (P1): Negligible. system could be shutdown

without any significant effect. No human nor environ-mental impacts are involved.

• Impact 2 (P2): Acceptable. Shutdown of the systemmeans a pointed disrupt of the service. Event could leadto labour disruption because of medical treatment. Envi-ronmental impact is in the standard margin and has noconsequence but to be declared to authorities.

• Impact 3 (P3): Unacceptable. Loss of system activity issignificant. Shipowner request investigations from athird-party committee. Human impact could lead topermanent disability. Environmental impact is limited.

• Impact 4 (P4): High. Loss of system is permanent and nostandard restoration process can help to restart the systemin its operational state. Ship is off. The regulatory asks forinvestigation. Human impact could lead to death. Signifi-cant pollution conducts to people evacuation.

• Impact 5 (P5): Catastrophic. Loss of ship systems or shipitself. Fleet is off due to investigation regarding scope ofcyber-attack. Major pollution with long-term environ-mental consequences and multiple death could appear.

3.2.5 DeliveryA table presenting the following elements is to be submitted(see Tab 5):• feared hazards• location (at sea, at quay)• source of event (people and, or, technologies involved

in the hazard)• effects (as described hereinbefore)• impact (as described hereinbefore).

Table 5 : Hazard impact example

3.3 Threats likelihood (K)

3.3.1 Objective

The threats revealed in impact study of feared hazards arenow evaluated in term of likelihood.

Threats on the process chain are developed in this step.

The objective is to list paths of cyber-attacks on the processchain. Threats may be described in a narrative way or byusing a table. Each threat is to be submitted with:

• one or more source of attack

• a level of likelihood.

Sources of attacks are chosen from predefined list heredelivered (i.e. slack crew member, malicious remote opera-tor, careless maintenance staff member, common virus,script-kiddies passenger, etc.)

Threats are freely chosen.

3.3.2 Llikelihood score

The likelihood describes the odds of being under attack.

The Likelihood (K) is the result of the addition of Exposure(E) and Human Factor (H).

Likelihood = Exposure + Human Factor

K = E + H

To score the Exposure (E), Connectivity (CX) and Complex-ity (CX) of the equipment is determined by using [3.4]. Toscore the Human Factor (H), Users (US) and Attacker (AT)are determined by using [3.5]. See Fig 7.

Figure 7 : Likelihood composition

Table 6 : Threats likelihood delivery example

Hazard Location Threats EffectImpact

(P)

Loss of propulsion

At sea Loss of equipment compliance

DelaysMarine rescue

4

Loss of control

Fulltime Encrypted station (ransonware)

Manual control

4

Passengers doors locked

At sea Private remote control

Panic 5

Likelihood (K)

Exposure(E)

Human factor(H)

Connectivity (CY)

Complexity (CX)

User (US)

Attacker (AT)

Threats source CX CY E US AT H K

Some system “PC OT A”

Loss of equipment compliance Human error 2 2 2 1 2 1 3

Encrypted station Common ransonware 2 2 2 1 3 2 4

Private remote control Targeted attack 2 2 2 1 4 2 4

Note 1:AT : Attackers

CX : ComplexityCY : Connectivity

= E : Exposure= H : Human factor

K : LikelihoodUS : Users


NR 659, Ch 1, Sec 2

3.3.3 Example

“PC OT A” is an OT engineering computer used to controlPLC of “Some System”:

CX : System Connectivity [3.4.2]), is 2 because froma logical point of view, the secondary systemdoesn't connect to the system. All connectionsare initiated by the system to the attention of thesecondary system

CY : System Complexity [3.4.3]), is 2 because it is anICS supervisor

E : Exposure is 2 as determined in [3.4.4]

US : Users [3.5.2]), is 1 because crew is trained andevents are logged

AT : Attackers [3.5.3]), is 2, 3 and 4 depending onthe 3 Sources (Human Error, Malicious Attack,Targeted Attack)

H : Human Factor is 1 and 2 as determined in[3.5.4]

K : Likelihood is, at the end, 3 and 4.

3.3.4 Delivery

Threats are presented in Tab 6 showing, for each of them,sources and likelihood score.

3.4 Exposure (E)

3.4.1 Definition

Calculation of exposure requires to deliver a notation forconnectivity and complexity. The vessel integrator is toevaluate connectivity of each system. To limit rules impactregarding the final Level (1, 2 or 3), vessel integrator mayconsider to adapt design of the vessel by limiting connectiv-ity to meet the needs without excess.

3.4.2 Connectivity (CY)

Connectivity 1:

This grade is only for isolated system. Isolated system meansa system without any network interconnection except thosededicated for the system itself (see Fig 8). Usage of a net-work and a switch without external connection is acceptedfor Connectivity 1.

Figure 8 : Connectivity 1 example


Figure 10 : VPN IPsec


Figure 12 : VPN IPsec public network

PLC

Computing Networking

Closed systemCY1

CY2

PLC


Sensitive system

PLC

ComputingNetworking

Other system

One-way

CY2

PLC

VPNIPsectunnel

Computing Networking Computing Networking

Sensitive system Other system

Computing

CY3

PLC

Networking

Sensitive system

PLC


Other system

One-way

CY3

PLC


Sensitive system

ComputingNetworking

Other system

VPNIPsectunnel


NR 659, Ch 1, Sec 2

Connectivity 2:

• System is interconnected to another system. Intercon-nection means network connection to another system.But, from a logical point of view, the secondary systemdoesn't connect to the system. All connections are initi-ated by the system to the attention of the secondary sys-tem (see Fig 9). connections are managed inside anencrypted tunnel like VPN SSL. Only connections fromthe inside to the outside are authorized. This is typicallyDMZ configuration.

• System is interconnected to another system. Intercon-nection means network connection to another system.There is no restriction regarding way of connection. Butthe traffic is fully encrypted at client level in a Layer 3tunnel (IPsec fully tunnelled).

Connectivity 3:

• Applicable to Connectivity 1 and 2 systems whichemploy and use wireless connections (see Fig 11).

• System interconnected to another system by employingVPN IPsec communication through public network (seeFig 12) in order to trust source.

• System is interconnected to another system. Intercon-nection means network connection to another system.There is no restriction regarding way of connection. Butthe traffic is encrypted in a VPN SSL and there is noother traffic than the one transported through the VPNSSL (see Fig 13).

Connectivity 4:

• System host one or more services which can beaccessed, operated or used from a secondary systemthrough a distant link - like a Local Area Network (LAN).Connections are done by using a private network whichis neither managed nor mastered by one of the two sys-tems (see Fig 14). This could be, for example:

- network services (e.g. data, printing sharing…),

- web services (e.g. web, file transfer server…),

- administration services (e.g. remote administration…),

- maintenance services (e.g. remote engine manufac-turers).

• System is interconnected to another system. Intercon-nection means network connection to another system.There is no restriction regarding way of connection. Butthe traffic is encrypted in a VPN SSL (clientless encryp-tion). Systems are connected to a public network (i.e.Internet) with a traffic disruption (i.e. DMZ or Bastion)see Fig 15.

Connectivity 5:

System deliver services for public access. Clients from pub-lic network can connect to the onboard system (see Fig 16).The public network may be Internet. For example: a Sup-plier using Internet to directly connect to a vessel system,through tunnel VPN SSL.

Figure 13 : VPN SSL


Figure 15 : SSL and disruption


CY3

PLC


Sensitive system

ComputingNetworking

Other system

VPNSSL

CY4

PLC


System 1

PLC

ComputingNetworking

System 2

CY4

PLC

VPN SSL

ComputingNetworking

Sensitive system Disruption

Computing

Networking

Remote system

Bastion

CY5

PLC


Vessel system

PLC

ComputingNetworking

External system

Publicnetwork


NR 659, Ch 1, Sec 2

3.4.3 Complexity (CX)Complexity 1: OT/IT systems have workstations and lightservers (see Fig 17). Restoration procedures of those systemsare easy to apply. Administration level is standard. OT sys-tems are made of sensors, controllers, consoles and controlcommands.

Figure 17 : Complexity 1 areas

Complexity 2: IT systems which host authentication servers,databases servers, calculator or any server sized to answer toreliability purposes (see Fig 18). Administration requires ded-icated skills. OT systems contain supervision or programmingworkstations. For example, this grade applies to maintenancesystems, critical systems or autonomous systems.

Figure 18 : Complexity 2 areas

Complexity 3:

IT and OT systems whose efficiency requires systems dis-patched through remote or distributed architecture (see Fig19). This grade typically applies to unmanned systems,swarm connections or any systems whose availability islinked to a high density of system exchange.

Figure 19 : Complexity 3 example

3.4.4 Exposure scoreThe exposure score is the combination of Complexity (CX)and Connectivity (CY) as defined in Fig 20.• for Complexity 1, the Exposure Score equals the Con-

nectivity Level• for Complexity 2, the Exposure Score equals the Con-

nectivity Level, without being taken less than 2• for Complexity 3, the Exposure Score is 3 for Connectiv-

ity 1−2, 4 for Connectivity 3−4 and 5 for Connectivity 5.

3.5 Human factor (H)

3.5.1 DefinitionHuman Factor (H) is the conjunction of users' level of matu-rity and attackers motivation (see Fig 20). In one hand, userstraining and activity recording in taken into account. Inanother hand, attackers' level is evaluated.

Figure 20 : Exposure score (E)

3.5.2 Users index (US)• Users index is 1 (US1) when users are authorized,

trained and actions are logged.

• Users index is 2 (US2) when users are authorized butnot trained. Actions are partially logged.

• Users index is 3 (US3) when users are not trained andactions are not logged.

• Users index is 4 (US4) when users are unknown.

(See Fig 21).

Figure 21 : User level (US)

3.5.3 Attackers index (AT)The Attack index AT is ranging from 1 to 5, depending onthe level of complexity and skill of the attacker. 1 corre-sponding to the lowest level and 5 to the most advancedattacks. The level is freely selected in accordance with thetarget of evaluation.

• Attackers' index is 1 (AT1) when attackers are consid-ered users having unintentionally and accidentallyintroduced common, untargeted virus and malwares.

• Attackers' index is 2 (AT2) when attackers are users tryingto bypass system security without malicious intention.

• Attackers' index is 3 (AT3) for malicious attackers (at seaor on shore employee, sub-contractor) using hackingtools and technics.

Computing Networking PLC

CX1

CX2

ICS Supervision Administration Database Authentication

PLCComputing

Networking

Autonomous systemCX3

Artificialintelligence

E = CY1

CX1

CX2

CX3

CY2 CY3 CY4 CY5

E1

E2

E3 E3 E4 E4 E5

E2 E4 E5E3

E2 E3 E5E4

CONNECTIVITY

CO

MPL

EXIT

Y

Authorized users Actions recording Trained users

H1

H2

H3


NR 659, Ch 1, Sec 2

• Attackers' index is 4 (AT4) when attackers are usingorganisation means (criminal organisation, competitor)to construct scenarios of attacks.

• Attackers' index is 5 (AT5) when attackers are consid-ered using governmental attacks.

3.5.4 Human factor scoreThe Human Factor score H is calculated from Users index(US) and Attackers index (AT) according to Fig 22.

Figure 22 : Human factor score (H)

3.6 Level (L)

3.6.1 ObjectiveThe Level contributes to determine Rules which will be laterconsidered during the application of the Rules and surveyoperations.

To avoid rules limitation regarding the final Level (1, 2 or 3),vessel integrator may consider to adapt design of the vesselfor systems having a high impact regarding the followinggraduation. Such systems may be limited in term of equip-ment (cost reduction) but also limited in term of connectiv-ity or complexity (exposure and thus likelihood reduction).

3.6.2 Level of equipment (L)Level (1, 2 or 3) is the result of the intersection betweenImpact (P) and Likelihood (K), and is obtained in accord-ance with Fig 23

Figure 23 : Level (of equipment) score table

Table 7 : Equipment level delivery example

3.6.3 DeliveryTo conclude, an intermediate table with Likelihood (K) andImpact (P) indicators for systems and equipment involved isto be provided (see Tab 7). At the end, Level is determinedthanks to the Level Score Table (see Fig 23).

3.6.4 ExampleK and P are taken from Tab 6 and Tab 5. Maximum Likeli-hood and Impact scores are used. As a conclusion, PC Engi-neering used in “Some System” is Level 3.

3.7 Risk calculation

3.7.1 objectiveRisk calculation is the final operation of the risk assessment.

The Cyber Risk Analysis is a dynamic process, an intellec-tual study written under the responsibility of the author, theShipowner. The risk calculation is neither a mathematicalformula nor an automatic system: each situation is to bestudy case by case.

That is the reason why Cyber Risk Analysis is required.

Nevertheless, in order to easily integrate the set of rulesapplicable according to the requested classification nota-tion, a quick and easy way to consider and to calculate riskis proposed in [3.7.2] to [3.7.5] hereafter.

3.7.2 Security measuresSecurity measures are:

• applicable requirements depending of the selected clas-sification notation)

• architecture principles (i.e. DMZ, etc.)

• physical protection (i.e. locked room, optical fibre, etc.)

• specific capabilities of the equipment

• certifications for the equipment

• vessel's infrastructure architecture

• special usage of security solutions

• etc.

From this point, the requirements applicable to the selectedclassification notation are developed and taken intoaccount in the proposed risk process.

It is up to the Shipowner to add its own specific and specialsecurity measures and to write a rationale regarding therisk.

3.7.3 Risk metricsThree degrees of risk are used: negligible, significant andunacceptable:

• Negligible (R1) are risks that are covered by the securitymeasures. Of course, the risk still exist.

• Significant (R2) is a degree for risks covered by the secu-rity measures but which still need to be regularlytracked and presented at board level. Risk treatmentmay be introduced to reduce the risk

• Unacceptable (R3) are risks that are partially covered bythe security measures, but those risks need a dedicatedtreatment in order to reinforce the security and toreduce the risk to a significant (R2) score.

System/equipment K P L

Some system

PC OT 4 5 3

H = US1

AT1

AT2

AT3

US2 US3 US4H0

H1

H1 H2 H2 H3AT4 H2 H2 H3 H3AT5 H2 H3 H3 H4

H1 H2H2H1 H1 H2

USERS

HU

MAN

FAC

TOR

K1

p1

p2

p3

K2 K3 K4 K5

p4

p5

K6 K7+

LIKELIHOOD (K)

IMPA

CT

(p)

LEVEL 1

LEVEL 2

LEVEL 3


NR 659, Ch 1, Sec 2

Thanks to the counter-measures that the class notation willintroduce to identified systems, the average score of risk willdecrease depending of the selected classification notation.

To figure out this, let’s build a diagram with risk measure onordinate axis and on abscissa axis. The score has been cal-culated from different combinations of impacts regardingtrained users versus motivated attackers.

In this example ( Fig 24), without notation, a score of 2,42on 3 is reached. Compliance with CYBER MANAGED nota-tion decreases the risk to 2,2. Note that the average is stillabove the significant (R2) level of risk because CYBERMANAGED relies on human factor and does not requirechanges on infrastructure. In those conditions, with {CYBER SECURE notation, the score drops to 1,8 on 3 whichis an important gap. Considering { CYBER SECURE nota-tion, the score reaches 1,66, a good median on the scale ofour risk metrics.

Figure 24 : Average class notation impact on the risk

Two degrees of risks are established for each feared hazards:• The first one is the degree of risk without security meas-

ures (“before” application of the classification notationrequirements and relevant actions). It is called OriginalRisk (OR) and is detailed in [3.7.4].

• The second one is the residual degree of risk (on whichrisk treatment will work on to decide, for example, toapply mitigation measures). It is simply called risk (R)and detailed in [3.7.5].

3.7.4 Original Risk (OR)The first degree of risk is easy to retrieve: the Level of equip-ment (L) calculated in [3.6.2] is directly reported as adegree of Risk:• Level 3 equipment, means an unacceptable risk (R3)• Level 2 equipment, means an significant risk (R2)• Level 1 equipment, means an negligible risk (R1).

Original risk may be reported and evaluated in an interme-diate table (see Tab 8). The original risk may be reconsid-ered and revaluated with a justification. Shipowner maydecide a risk as overrated or under rated.

Table 8 : Original risk from equipment level

3.7.5 Risk (R)

The second degree of risk takes into account the securitymeasures, thus the application of the requirements from theapplicable classification notation, as described in [3.7.2].

As for original risk, the present risk may be reconsideredand revaluated with a justification even after application ofclassification notation bonuses described hereafter. Ship-owner may decide a risk as overrated or under rated. Spe-cial and dedicated security measures may enter in thisjudgement.

To recalculate this risk, the following bonuses are consid-ered, depending on the selected notation:

• Complexity index CX: as systems and infrastructuredesigns are explained in the Cyber Repository andunder control of the cyber security responsible, Com-plexity index CX is revaluated from CYBER MANAGEDnotation. A reduction of −1 on the initial value isgranted for CYBER MANAGED and −2 for CYBERSECURE.

• Connectivity index CY: connectivity principles are hard-ened from µ CYBER SECURE. A reduction of −1 on theinitial value is granted for this notation and −2 is grantedto { CYBER SECURE.

• Attackers index AT: taking into account equipment mon-itoring, equipment hardening and equipment certifica-tion, the attackers' skills needs to increase. A reductionon the initial value is granted for

−1 for CYBER MANAGED,

−2 for µ CYBER SECURE and

−3 for { CYBER SECURE.

Tab 9 presents those principles.

Threat calculation shall be consolidated by re-using likeli-hood elements from Tab 6 with new elements as developedin Tab 10 and Tab 11.

Table 9 : Risk reduction bonuses

4 Risk treatment

4.1 Residual risks

4.1.1 Selection

As risk treatment has already been applied through theapplication of the Rules and survey operations according tothe classification notation, the Cyber Risk Analysis directlytreat Residual Risks.

Risk at degree 3 (unacceptable) are not accepted and miti-gation measures shall be reconsidered in order to revaluatethe risk in an iterative process.

System/equipment Original risk

Some system

PC OT Unacceptable

3

2,5

2

1,5

1

Without2,42

CYBER MANAGED2,2

• CYBER SECURE1,8

{ CYBER SECURE1,66

EFFORT

RIS

K

CYBER MANAGED

µ CYBER SECURE

{ CYBER SECURE

Complexity (CX) −1 −2 −2

Connectivity (CY) 0 −1 −2

Attackers (AT) −1 −2 −3


NR 659, Ch 1, Sec 2

Risk at degree 2 (significant) are considered residual risks.

Risk already, always and still exist. The objective of theCyber Risk Analysis is no to eliminate those risks, but toidentify them in order to properly prevent them (Level ofEquipment), monitor them and track them at board-level.The residual risk may be reconsidered and revaluated with ajustification. Shipowner may decide a risk as residual or no.

4.1.2 Decision on risksDecisions about risks identified as residual risks need to betaken. The Shipowner decides about the strategy to employin order to cover risks.

The following actions may be used:• Avoid: change the context in order to be disengaged of

the risk.• Reduction: introduce new mitigation measures in order

to cut down impact and, or, likelihood. Mitigationmeasures may be:

- organisational by installing new procedures

- technical by dedicating a cyber security componentlike i.e. a firewall

- physical by introducing i.e. locks, optical fibres orroom controls

- dedicated monitoring: this is of course considered asa security measure

- increased frequency of an already existing monitor-ing procedure.

- quality driven by using certified equipment

- etc.

• Assume: take the risk without any security measure

• Transfer: use a third-party operator to cover the opera-tion and, thus, the risk.

A rationale, in a table or in plain-text, is to be submitted toexplain decisions about risk treatment.

Table 10 : Risk evaluation example

Table 11 : Example of µ CYBER SECURE bonuses

Threats SourceCYBER MANAGED bonuses

P RCX CY E US AT H K

Some system PC OT A

Loss of equipment compliance Human error 1 (2) 2 (2) 2 (2) 1 1 (2) 0 (1) 2 (3) 4 2 (2)

Encrypted station Common ransonware 1 (2) 2 (2) 2 (2) 1 2 (3) 1 (2) 3 (4) 4 2 (3)

Pirate remote control Targeted attack 1 (2) 2 (2) 2 (2) 1 3 (4) 1 (2) 3 (4) 5 3 (3)

Note 1: (Original) Original values are display with parenthesis

Note 2:AT : AttackersCX : Complexity

CY : Connectivity= E : Exposure= H : Human factor

K : LikelihoodP : Impact

R : RiskUS : Users

Threats Sourceµ CYBER SECURE bonuses

P RCX CY E US AT H K

Some system PC OT A

Loss of equipment compliance Human error 1 (2) 1 (2) 1 (2) 1 1 (2) 0 (1) 1 (3) 4 2 (2)

Encrypted station Common ransonware 1 (2) 1 (2) 1 (2) 1 1 (3) 0 (2) 1 (4) 4 2 (3)

Pirate remote control Targeted attack 1 (2) 1 (2) 1 (2) 1 2 (4) 1 (2) 2 (4) 5 2 (3)

Note 1: (Original) Original values are display with parenthesis

Note 2:AT : AttackersCX : Complexity

CY : Connectivity= E : Exposure= H : Human factor

K : LikelihoodP : Impact

R : RiskUS : Users


NR 659, Ch 1, Sec 2


NR 659

Chapter 2

ADDITIONAL CLASS NOTATION CYBER MANAGED

SECTION 1 GENERAL

SECTION 2 EQUIPMENT MANAGEMENT

SECTION 3 SYSTEM INTEGRATION

SECTION 4 VESSEL MANAGEMENT


NR 659, Ch 2, Sec 1

SECTION 1 GENERAL

1 General

1.1 Application

1.1.1 Cyber managed class notationThe CYBER MANAGED notation is a set of requirementsdealing with the following elements:

• Equipment integrity: Software Registry, as defined inShip Rules, NR467, Pt C, Ch 3 Sec 3, is enforced bycompliance procedures used to verify the integrity ofthe critical equipment. The principle is to have a pictureof standard equipment from its initial state, or lastknown as proper.

• Crew training: Roles, responsibilities and training areexplained. Vessel security policy is introduced and applied.

• Perimeter protection: Following the intention to checkcompliance and to train crew members, CYBER MAN-AGED also checks usage of external digital devices onthe ship networks. The objective is to define proceduresin order to verify ingoing equipment such as USB mediaor laptops.

• Change management: A policy is proposed to maintain anacceptable level of security during the whole life cycleof the vessel. Cyber Risk Analysis becomes central.

• Traceability: Manual or automatic registries are in placeto build history of numeric activities in operation andduring maintenance operations.

• Connectivity: A set of network rules provides architec-tural principles regarding cyber security.

1.1.2 ApprovalThe additional class notation CYBER MANAGED is assignedto a ship in order to reflect the fact that a procedure includ-ing periodical and corrective maintenance, as well as peri-odical and occasional inspections of information systems orequipment and ICS or equipment, are dealt with on boardby the crew and at the Owner's offices according toapproved procedures.

The assignment of the notation implies that requirements forassignment of CYBER MANAGED notation have been ful-filled in accordance with:

• equipment are identified, inventoried, categorized (Cat.A, Cat. B or Cat. C), grouped by Level (Level 1, Level 2or Level 3) in conformity with Ch 1, Sec 3 definitions

• equipment inventory and management is in conformitywith the requirements of Sec 2

• network connectivity is in conformance with Sec 3

• vessel cyber risk analysis, security policy, procedures,roles, responsibilities and training are in place in con-formity with Sec 4

• the interested party submits to the Society the relevantdocumentation listed in [2].

Table 1 : Cyber repository

Chapter ReferenceI/A (1)

Survey

General

Updates procedure [2.2.1] I

Compliance identification

Compliance scope Sec 2, [1.1.2] A

Compliance baseline Sec 2, [1.1.3] I

Detailed software inventory

Sec 2, [1.1.4] I

Features configura-tion

Sec 2, [1.1.5] I

Remote access security verification

Sec 3, [1.4.2] A

Network verification Sec 3, [4.1.2] A

Antivirus compliance Sec 2, [2.2] I

Equipment security identification

Accounts security settings

Sec 2, [2.1.3] I Ch 4, Sec 4, [2.1]

Operating systems security settings

Sec 2, [2.1.5] I Ch 4, Sec 4, [2.2]

Features security settings

Sec 2, [2.1.6] I Ch 4, Sec 4, [2.3]

Antivirus software Sec 2, [2.2] I Ch 4, Sec 4, [2.4]

Remote access

Public networks Sec 3, [1.1.2] A

Private networks Sec 3, [1.1.3] A

DMZ architecture Sec 3, [1.2] A

External traffic encryp-tion mechanism

Sec 3, [1.3.1] I

External connections Sec 3, [1.3.2] A

Firewall management Sec 3, [1.3.3] I

Application Firewall management

Sec 3, [1.3.4] I

New-generation firewall management

Sec 3, [1.3.5] I

Intrusion prevention system

Sec 3, [1.3.6] I

DMZ management Sec 3, [1.5.1] A

Networks

Wireless usage Sec 3, [2.1.1] A Ch 4, Sec 3, [2.5]

WLAN security policy Sec 3, [2.1.2] A

Cabled networks Sec 3, [3.1.1] A Ch 4, Sec 3, [2.2]

Cabled networks security equipment

Sec 3, [3.1.2] I

(1) I : For informationA : For approval


NR 659, Ch 2, Sec 1

1.1.3 SurveyThe implementation of the CYBER MANAGED class nota-tion is surveyed by the Society through periodical checks.

The Survey part of CYBER MANAGED is detailed in Chapter4.

1.1.4 ScopeThe following Sections correspond to different scopes ofresponsibilities.

Sec 2, “Equipment Management”, inventories required infor-mation regarding the equipment and lists function to use inorder to achieve CYBER MANAGEMENT objectives. ThisSection applies to Shipyard for new building ships and toShipowner for existing ships. Suppliers may be involved byboth of those two actors in order to deliver appropriate levelof knowledge regarding the management of their Equipment.

Sec 3, “System Integration”, is the reference for vessel inte-grator. Rules regarding remote access, equipment and sys-tem connections are developed. Sec 3 develops CYBERMANAGED notation by applying the same concepts asthose introduced in Sec 2 to networks and connections.

Sec 4, “Vessel Management”, is dedicated to Shipowner. Rolesand procedures are put in place in order to maintain the shipin a proper state. Change management plan and legal proofare introduced. This Section fully applies to Shipowners.

2 Document to be submitted

2.1 Methodology

2.1.1 ApplicationThe vessel integrator is in charge of collecting all the docu-ments.

Sec 2 is about equipment management rules and applies toequipment. Vessel integrators are in charge:

• to identify documentation submission, mechanismsimplementation and minimum conformity of equip-ment. Those information are to be submitted in theCyber Repository.

• to write management and compliance monitoring pro-cedures in the Cyber Handbook.

• to initialise a Cyber Registry to record events.

Sec 3 is about Connectivity and applies to vessel systems,cabled and wireless networks, rooms' architecture andremote access with through shore connection. The Ship-owner is in charge:

• to identify the connectivity implementation and inher-ited cyber security in the Cyber Repository.

• to write management and compliance monitoring pro-cedures in the Cyber Handbook.

Sec. 4 is about the life cycle of the ship. The Shipowner is incharge:

• to deliver a Cyber Risk Analysis

• to write and apply the Cyber Security Policy for the ves-sel in operation by defining rules and roles.

• to submit the format of the maintenance registry. For tracea-bility of events, procedures and emergency situations.

2.1.2 WorkflowTo achieve those objectives, the vessel integrator can followthe workflow proposed in this document as detailed in Fig1.

2.1.3 Table of contentExamples of table of contents for the documents:

• Cyber Security Policy is presented in Tab 3

• Cyber Repository is presented in Tab 1

• Cyber Handbook is presented in Tab 2

• Cyber Registry is presented in Tab 4.

Table 2 : Cyber handbook

Chapter ReferenceI/A (1)

Survey

General

Cyber handbook update

[2.2.2] I

Monitoring

Compliance monitor-ing procedures

Sec 2, [1.2.1] A Ch 4, Sec 2, [2.1]

Compliance availability

Sec 2, [1.2.2] I Ch 4, Sec 2, [2.2]

Equipment accounts monitoring

Sec 2, [2.4.1] I Ch 4, Sec 2, [2.3]

Remote access events Sec 3, [1.4.1] I Ch 4, Sec 2, [2.4]

Network events supervision

Sec 3, [4.1.1] I Ch 4, Sec 2, [2.5]

Remote access events logging

Sec 3, [1.5.3] A Ch 4, Sec 2, [2.4]

Network events logging

Sec 3, [4.2.2] I Ch 4, Sec 2, [2.5]

Maintenance

Maintenance protection

Sec 2, [2.3.1] I Ch 4, Sec 5, [2.3]

Accounts management Sec 2, [2.1.4] I

Compliance monitoring update

Sec 2, [1.3.1] I

Compliance baseline update

Sec 2, [1.3.2] I Ch 4, Sec 5, [2.2]

Antivirus patch management

Sec 2, [2.3.2] I Ch 4, Sec 4, [2.4]

Equipment patch management

Sec 2, [2.3.3] I Ch 4, Sec 4, [2.5]

Remote access patch management

Sec 3, [1.5.2] A

Network patch management

Sec 3, [4.2.1] I Ch 4, Sec 5, [2.4]

Response

Loss of compliance procedures

Sec 2, [1.4.1] I

Backup procedures Sec 2, [2.5.1] I Ch 4, Sec 5, [2.1]



NR 659, Ch 2, Sec 1

2.2 Documentation updates

2.2.1 Cyber repository updateProcedures are to be defined in order to specify workflow toapply in case of:• system or equipment modification• system architecture modification• system level update• compliance scope upgrade• compliance baseline modification.• software installation• features modification• accounts security settings modification• operating systems security settings modification• features security settings modification• maintenance protection modification• antivirus software major modification.

2.2.2 Cyber handbook updateProcedures are to be defined in order to specify the work-flow to apply in case of:• compliance registry usage• compliance monitoring update• non-compliance management update• accounts management modification• compliance maintenance operations• maintenance protection modification.

Workflow to apply may be, for example:• to inform Cyber Security Officer• to use dedicated software• etc.

Note 1: An update procedure is to be delivered with the CyberHandbook.

Table 3 : Cyber Security Policy

Table 4 : Cyber Registry

Chapter Reference I/A (1)

Topics

Cyber risk analysis update Sec 4, [1.1.1] I

Information protection Sec 4, [1.3] I

Roles and responsibilities Sec 4, [2] A

Change management plan Sec 4, [5] I

Physical security

Vessel security Sec 4, [4.2] A

Removable and mobile digital assets

Sec 4, [4.3] A

Cyber operations

Monitoring policy Sec 4, [3.2] I

Maintenance policy Sec 4, [3.2.4] I

Incident response policy

Sec 4, [3.4] I


Chapter Reference

Authorizations and engagements Sec 4, [2]

Roles

Transfer of responsibilities Sec 4, [2.2.6]

Nominations Sec 4, [2.1.1]

Training Sec 4, [2.1.1]

Access control Sec 4, [2.1.1]

Engagements Sec 4, [2.1.1]

Cyber operations: monitoring

Vessel compliance Sec 4, [3.2.2]

Infrastructure integrity Sec 4, [3.2.3]

Compliance availability Sec 4, [3.2.4]

Accounts integrity Sec 4, [3.2.5]

Maintenance

Equipment isolation Sec 4, [3.3.3]

Updates Sec 4, [3.3.4]

Logs management Sec 4, [3.3.5]

Incident response

Non-compliance Sec 4, [3.4.2]

Virus detection Sec 4, [3.4.3]

Post-monitoring events Sec 4, [3.4.4]

Backup operations Sec 4, [3.4.5]

Disaster recovery Sec 4, [3.4.6]

Crisis management Sec 4, [3.4.7]

Cyber incident Sec 4, [3.4.8]

Physical security Sec 4, [4.1.1]

Roles

Outgoings Sec 4, [2.2.2]

Scanning Sec 4, [4.3.3]

Usage Sec 4, [4.3.4]

End of Life Sec 4, [4.3.5]

Change Management

Requests Sec 4, [5.2]

Approbations Sec 4, [5.3]

Homologation Sec 4, [5.4]

Validation Sec 4, [5.5]

Survey Operations Registry

Initial Inspection logs and results Ch 4, Sec 1, Tab 1

Annual Survey logs and results Ch 4, Sec 1, Tab 1

Intermediate Survey logs and results Ch 4, Sec 1, Tab 1

Class renewal Survey logs and results Ch 4, Sec 1, Tab 1


NR 659, Ch 2, Sec 1

Figure 1 : CYBER MANAGEMENT class notation workflow

Cable networks

Wireless networks

Sec 3, [3.1.1]Sec 3, [3.1.2]

Sec 3, [2.1.1]Sec 3, [2.1.2]

N ETWORKChart legend:

Cyberrepository

Cyberhandbook

R EMOTE ACCESSRemote access

architecture Traffic security

Management mode

Sec 3, [1.1.1]Sec 3, [1.1.2]Sec 3, [1.2.1]

Sec 3, [1.3.1]to Sec 3, [1.3.6]

Sec 3, [1.5.1]

Compliance scopeC

Sec 2, [1.1.2]

E QUIPMENTSecurity settings

scope(Cat. A) Operating

system security

(Cat. B + Cat. C)Features configuration

Sec 2, [2.1.2]

Account securitysettings

Sec 2, [2.1.3]

Sec 2, [2.1.5]

Sec 2, [1.1.5]

Sec 2, [2.2.1]

(Cat. A)Antivirus solution

C OMPLIANCE

Network compliance (Cat. A) Detailedsoftware inventory

(Cat. B + Cat. C)Features security

Sec 3, [3.2.1] Sec 2, [2.1.5]

Sec 2, [2.1.6]

Sec 2, [2.2.2]

(Cat. A)Antivirus compliance

Sec 3, [1.4.2]

Remote accesscompliance

Compliance baselineC

Sec 2, [1.1.3]

Sec 2, [1.4.1] Sec 2, [2.5.1]

Backupsprocedures

Loss ofcompliance

M ONITORING

Sec 2, [1.2.1] Sec 2, [1.2.2] Sec 3, [1.4.1]

Compliancesurvey

Complianceavailability

Remote accessmonitoring

Sec 3, [4.1.1] Sec 2, [2.4.1]

Networkmonitoring

Accountmonitoring

Sec 2, [1.3.2]

Sec 2, [2.3.1] Sec 2, [2.1.4] Sec 3, [4.2.1] Sec 3, [4.2.2]

M AINTENANCE

Maintenanceisolation

Accountsmanagement

Networkmaintenance

Networklogging

Sec 2, [2.3.2]Sec 2, [2.3.3]

Sec 2, [1.3.1] Sec 3, [1.5.2] Sec 3, [1.5.3]

Equipmentmaintenance

Maintenance ofcompliance

Remote accessmaintenance

Remote accesslogging

I NCIDENT RESPONSE


NR 659, Ch 2, Sec 2

SECTION 2 EQUIPMENT MANAGEMENT

1 Compliance policy

1.1 Components identification

1.1.1 IntroductionCompliance is defined in Ch 3, Sec 4, [2.1.1].

Compliance of equipment is verified either manually or byusing an automated solution.

1.1.2 Compliance scopeSystems are selected from the scope defined in Ch 1, Sec 2,[2.3] and constitute the compliance scope on which rulesdescribed in the current Section apply to. The compliancescope is defined by the vessel integrator by applying the fol-lowing principles:• equipment used for outgoing connectivity (i.e. routers,

switches) are automatically included• security equipment (i.e. firewalls, authentication serv-

ers) are automatically included• for Level 3 integrated systems using many pieces of

equipment, some pieces only may be selected for com-pliance checking operations. In this case, equipmentwith a score of complexity of 2 or 3 ( Ch 1, Sec 2,[3.6.3]) may be used (i.e. authentication servers, ICScontrollers).

Delivery: Compliance scope is to be detailed, justified andsubmitted for approval in the Cyber Repository.

1.1.3 Compliance baselineCompliance baseline holds a set of hardware and softwareinformation used to define the proper state of equipmentand systems.

Scope of compliance baseline applies to systems includedin the compliance scope [1.1.2].

The compliance baseline defines the following elements:• regarding visually inspections on hardware:

- list of physical identifiers (i.e. barcodes, QR codes(Quick Response codes), passive/active RFID tags(Radio Frequency Identification))

- list of physical protection (i.e. cabinet lockers orlock-in devices for network plugs)

• regarding software and logical elements:- list of elements selected from Ch 3, Sec 2, [4.3].

Delivery: Compliance baseline is to be detailed, justifiedand delivered in the Cyber Repository.

1.1.4 Detailed software registryFor Level 3 equipment Cat. A included in the compliancescope (defined in [1.1.2]), Software preinstalled from oper-ating system, manually installed, developed by third party,provided by software editors or simple off-the-shelf compo-

nent are to be inventoried (name, licence, version, origin,purpose).

Detailed software inventory is to be associated to equip-ment compliance baseline (in [1.1.3]) and detailed in theCyber Repository in a dedicated Section.

Delivery: Information regarding software inventory is to bedetailed, explained and justified in the Cyber Repository.

1.1.5 Features configurationFor IT and OT Level 3 equipment included in the compli-ance scope (defined in [1.1.2]), Cat. B and Cat. C equip-ment, if possible, have a listing of main features runningunder the form of functions, software or services.

For each of them, the following elements, when available,are explained:

• roles (description of needs, objectives and data processing)• connections (listening, outgoing or system only) - listen-

ing means accepting connections, outgoing meansopening outgoing connections from the equipment toanother one, system only refers to internal processes

• access rules (local or remote) - local means that thefunction can only be managed from a local console

• accounts (administration, running, operation) - adminis-tration is the highest privileged access, running is a sys-tem oriented account and operation is linked to anoperational human user.

Delivery: Topics regarding Cat. B and Cat. C features config-urations are to be detailed, explained and justified in theCyber Repository.

1.2 Compliance monitoring

1.2.1 Monitoring proceduresThe objective of compliance monitoring is to run eitherperiodical manual inventories or real-time automatizedcontrols to compare current status of compliance scopedefined in [1.1.2] with the compliance baseline defined in[1.1.3].

Manual and semi-automated procedures to verify compli-ance may be rolled out:• by requiring pervasive human procedures for any ingo-

ing or outgoing equipment from or to the vessel

• by using active scan discovery command-line softwareon both OT and IT networks

• by applying manual procedure to visually control sensi-tive areas and small sized Systems (i.e. switches config-uration)

• by reading Dynamic Host Configuration Protocol (DHCP)history from network equipment

• by checking security events on network equipmentregarding both succeed and failed connection events


NR 659, Ch 2, Sec 2

• by seeking port-based level access control (IEEE 802.1xfor post-based network access control) security eventsabout authentication failure with MAC addresses orRADIUS authenticators

• by executing automated scripted (i.e. bash) to collect,store and compare files on an equipment or over a wholesystem

• by using an active architecture (See Ch 3, Sec 4, [2.1.4])

• by using a passive architecture (See Ch 3, Sec 4, [2.1.5]).

Procedures are to detail who is in charge to apply verifica-tion, when (each week, month, etc), how (script, tools),where (scope of application) and what to do in case of lossof compliance.

Delivery: Procedures about compliance monitoring are tobe submitted for approval in the Cyber Handbook.

1.2.2 Compliance availability

For automated and real-time compliance solutions, proce-dures are in place to test compliance availability, capabili-ties, efficiency and exhaustiveness.

Delivery: Procedures to test compliance functions are to besubmitted in the Cyber Handbook.

1.3 Compliance maintenance

1.3.1 Compliance monitoring update

Procedures to manually or automatically verify the integrityof equipment (see compliance monitoring [1.2.1]) are to bemaintained either by the Supplier, the vessel integrator orthe cyber security officer.

When available, the procedure about how-to get updates isto be delivered.

Delivery: Procedures about compliance monitoring updateare to be submitted in the Cyber Handbook.

1.3.2 Compliance baseline update

Procedures are to be in place to maintain compliance capa-bilities:

• Maintenance of compliance baseline (as explained in[1.1.3]) is linked to maintenance operations, softwareupdates and equipment lifecycle. The procedure is to beexplained.

• The procedure about how-to get and apply equipmentand software updates is also to be delivered.

Cyber security officer is to identify end of life of equipment,meaning that suppliers or manufacturers do not ensuremaintenance of the software anymore: patch delivery forexample. Identified equipment shall receive appropriatedmitigation and protection measures until their replacement,if any. Dedicated controls should also be considered forthose equipment. Cyber risk analysis is to be updatedregarding those new vulnerabilities.

Use of a central service solution is recommended asdefined in Ch 3, Sec 4, [1.1.6].

Delivery: Procedures for the maintenance of complianceoperations are to be delivered in the Cyber Handbook.

1.4 Compliance incident response

1.4.1 Loss of compliance

In case of loss of compliance or any other situation asdescribed in the compliance monitoring, a loss of compli-ance procedure is to be define technical measures to applyto maintain the equipment in safety conditions.

The cyber security officer is to be informed and is in chargeof deciding applicability of procedures.

Depending on the Level of equipment, the procedure mayrequire to disconnect remote link (i.e. router, modem,equipment isolation procedure) for identified OT Level 3.

Physical measures are to be detailed (i.e. cable networkremoval, equipment shutdown).

Procedures are to be simple and designed to be applicableto any crew member and to respond both to emergency andto safety situations.

When an operational anomaly has been identified, a proce-dure is to be defined in order to provide information aboutthe equipment and connections used on board, related con-figurations and software version, useful network servicesport information and in-memory details, to the equipmentSupplier.

Delivery: Loss of compliance procedures are to be submit-ted in the Cyber Handbook.

2 Equipment security

2.1 Equipment security settings

2.1.1 Introduction

The objective of equipment security settings is to introducerequirements to protect and manage equipment by usingfunctionalities already delivered by Suppliers on theirequipment.

As application of following requirements depends onequipment capabilities and implementation of securitymechanisms, it is under responsibility of the vessel integra-tor to find relevant procedures in order to achieve objec-tives detailed hereafter.

2.1.2 Scope

The scope of equipment on which requirements of this Sec-tion apply to, is selected from the scope defined in Ch 1,Sec 2, [2.2] and constitute the scope to which the require-ments described in this article apply to.

2.1.3 Accounts security settings

For Level 2 and Level 3 equipment, access is to be managedin accordance with the following conditions:

• Equipment cannot be accessed without authenticationmechanism (identification and “password”). Exclusionsmust be explained, detailed and justified.

• Generic and default accounts is not to be used unlessduty justified. In that case, it must be explained, detailedand justified.


NR 659, Ch 2, Sec 2

• A list of group of users. The groups are to be dedicated toa specific role from the following list: Administration,everyday maintenance, data backup, operational usages.Each group is justified and role is explained. Groupshave dedicated privileges and limitation.

• Users accounts are part of compliance baseline of theequipment as defined in [1.1.3].

• Passwords are robust. The robustness of a passworddepends on the system and shall be detailed by the sup-plier. The robustness is to be verified through compari-son with password history, usage of a passwordcomplexity test and renewal of password at regularperiod (30, 60, 90 days...) If, for operational, safety orany other demonstrated reason, the system have to beaccessed without authentication, mitigation measuresare to be proposed such as physical access control,operation system hardening or limitation of functions.

Delivery: Security settings for accounts are to be submittedin the Cyber Repository.

2.1.4 Accounts managementEquipment accounts are to be managed through the follow-ing procedures:• equipment has a set of procedures and tools to create,

modify, lock or delete users account and to manageroles and accesses

• equipment provides procedures and tools to reset pass-words.

Delivery: Procedures for accounts management are to besubmitted in the Cyber Handbook.

2.1.5 Operating system security settingsFor Level 3 Cat A. equipment included in the complianceScope (defined in [1.1.2]) security settings for operating sys-tems (Windows, Linux, macOS, Android, iOS) are to bedetailed and explained.

Security Settings are to be associated to equipment compli-ance baseline (in [1.1.3]) and detailed in the Cyber Reposi-tory in a dedicated section.

Security settings may address the following topics: systemservices, accounts, local policies, audit policies, events logsmanagement, file access control list, network interfacesconfiguration, network filtering.

The objective is to master the security mechanisms whichare in place and to be able to propose a way to continu-ously upgrade and enhance security of the equipment.

Security Settings are selected from Ch 3, Sec 2, [4.3].

Note that some of those software elements are susceptibleto change during life cycle of the equipment: minor ormajor updates and other patch management operationschange software elements. But, at this point, those softwareelements must be not be excluded.

In example, here is a non-exhaustive list of elements to relyon:• Files monitoring includes any file system, mounted vol-

umes, directory, files and their access controls list, sizes,time stamps and checksums. Sensitive files are speci-fied: configurations files, environment variables, hivesany other files of interest relevant to operating system.

• Connections monitoring includes network mounted vol-umes, services, protocols, opened ports, listening appli-cations and outgoing connections.

• Serial interface monitoring mechanisms includes USB(Universal Serial Bus) activity, removable media usage,restriction or limitation and any other kind of serial linkusage.

• Memory monitoring handled by the operating systemincludes running processes, memory access controls,process sizes, relevant process time stamps, relevantprocess activity and process hashes.

Delivery: Selected information regarding security of theoperating system are to be detailed, explained and justifiedin the Cyber Repository.

2.1.6 Features security settingsCat. B and Cat. C Features Security Settings are a set of ele-ments of Integrity.

This set of elements is to be delivered by the vessel integra-tor to monitor compliance and reveal any loss of integrity.

Those elements may be, when available:

• features configurations (built on [1.1.5] elements)

• system firmware (used to compare version numbers orchecksums)

• equipment self-tests procedures or any integrated integ-rity checking tool

• equipment physical configuration (OT safety switches)

• equipment configuration:

- Cat. B network equipment such as routers, firewallsmay have a detailed list of expected compliance:

access control list to network, serial interfacesand removable media

configuration files, environment variables

- any other information of interest relevant to networkappliance compliance

• security settings may address the following topics:

- system services

- accounts management

- local policies

- audit policies

- events logs management

- network Interfaces configuration

- network filtering.

Cat. B and Cat. C features security settings are associated toequipment compliance baseline (in [1.1.3]) and detailed inthe Cyber Repository in a dedicated section.

Delivery: Cat. B and Cat. C features security settings are tobe detailed, explained and justified in the Cyber Repository.

2.2 Antivirus software

2.2.1 Antivirus installationLevel 2 and Level 3 Cat. A equipment included in the com-pliance scope (defined in [1.1.2]) are to be fitted with anantivirus solution capable of malicious signatures recogni-tion (anti-key loggers, anti-malware, anti-spyware, anti-


NR 659, Ch 2, Sec 2

virus) and malicious behaviour recognition (heuristic analy-sis).

There are two ways to considerer the notion of antivirussolution.

• Either it is a classic antivirus solution, meaning installedas an application managed by the operating system ofthe equipment.

• Either the antivirus solution is a remote mechanism asthe one described Ch 3, Sec 4, [3.1.3] or directlyinspired by this definition.

In the first case, when installed in the equipment, the fol-lowing requirements are to be followed:

• antivirus cannot be deactivated or uninstalled by users

• antivirus is launched with system rights

• antivirus action or deactivation requires highest admin-istrative privileges

• antivirus is launched with operating system before localor network, user or system access to system.

Delivery: Reference of installed software is to be submittedin the Cyber Repository.

2.2.2 Compliance of antivirusThe antivirus solutions are to be associated to equipmentcompliance baseline (in [1.1.3]) and detailed in the CyberRepository in a dedicated section.

The following elements may be used:

• binary files on disk

• in-memory processes

• alerts management

• signatures or configuration files.

Delivery: Information regarding antivirus compliance are tobe submitted in the Cyber Repository.

2.3 Equipment maintenance

2.3.1 Maintenance protectionFor maintenance operations of Level 3 equipment and sys-tems, the Master is to agree any operation regarding:

• date and time of the start of maintenance operation

• scope of equipment impacted.

• tools and software used for maintenance

• hardware used for maintenance

• estimated date and time of the end of maintenanceoperation.

In case of delay during maintenance operation, the Masteris to be informed (i.e. by phone) about this delay 15 minutesbefore the estimated date and time of the end of the mainte-nance.

Before starting back the equipment, the Master is to apply averification procedure (i.e. to check a control panel in thebridge).

Safety procedures are to include the following considerations:

• service provider selection and use of competent techni-cians

• ensuring secure communications and remote access

• identification of technician(s) form service providercoming on board

• access management for technician(s) from service provider

• avoiding, as far as practicable, direct connection ofuncontrolled equipment to a controlled network

• confirmation from the service provider that any portablecomputers, removable media/storage devices intended tobe used in the maintenance process have been subject toa malware check before the maintenance is carried out.

Delivery: Security procedures regarding maintenance pro-tection are to be submitted in the Cyber Handbook.

2.3.2 Antivirus patch managementThe antivirus solution is to be kept updated in accordancewith the cyber security officer recommendation by using asecure update mechanism ensuring data integrity.

For maintenance operations, antivirus updates are to beavailable from operator level.

A procedure is to be delivered with the equipment for thecyber security responsible attention.

The procedure is to detail step by step actions required toverify the proper state of antivirus in terms of update andavailability.

Delivery: Antivirus update procedures are to be submittedin the Operator Guide.

2.3.3 Equipment patch managementPatch management and software updates are to be consid-ered as a priority for Level 3 equipment

Owner subscribes to supplier’s vulnerability alert lists (CVE)to be informed on the latest vulnerabilities and to getupdates.

Procedure is to be implemented to check patch publicationfrom alerts lists and approve them in accordance with thechange management plan as defined in [5].

Delivery: Inventory of equipment and related patch man-agement procedures are to be detailed, justified and submit-ted for approval in the Cyber Handbook.

2.4 Equipment monitoring

2.4.1 Accounts monitoringFor Level 2 and Level 3 equipment, a procedure is to detailhow to review users' accounts:

• inventory of accounts

• date of creation

• date and time of last connection.

The scope of applicability is:

• equipment identified in [2.1.3]

• operating systems identified in [2.1.5]

• software identified in [1.1.4]

• features identified in [1.1.5].

Delivery: Procedures to audit accounts are to be submittedin the Cyber Handbook.


NR 659, Ch 2, Sec 2

2.5 Equipment incident response

2.5.1 Backup proceduresFor Level 2 and Level 3 equipment, a backup procedure isto explain how to save sensitive files, systems and assets.

The backup plan is to include a restoration procedure usingthe backup data.

After data restoration and restoration procedure application,the equipment is to be ready to operate.

The data restoration plan will be used in case of emergencyor loss of compliance.

The data restoration is limited to the equipment and systemsthat are mandatory to restore safe operation of the vessel.So, it means that a minimum level of equipment from thescope of the security target is considered: a list of minimal

equipment is to be established and delivered. This list isnamed “vital equipment”.

The data restoration is to be simple, as far as practicable,and detailed in order to be applicable by the cyber securityresponsible for the “vital equipment”.

The data restoration is to be stored in a safe place onboard(for local restoration) or onshore (for remote restoration).

Dual systems (used as redundancy solution) may be recog-nized as far as it is proofed that the redundant system can-not be comprised in case of attack of the primary system. Arationale regarding the security of secondary image of dualsystems is to be submitted.

Delivery: Procedure to backup equipment is to be submit-ted in the Cyber Handbook.


NR 659, Ch 2, Sec 3

SECTION 3 SYSTEM INTEGRATION

1 Remote access

1.1 Usages

1.1.1 Type of connections

Remote access covers any access to the ship IT or OT fromremote point like remote operation centre or manufacturerequipment management and supervision or ship to ship. Abasic premise of the remote access point is that its securityis not satisfactory.

Three types of remote connections are to be considered:

• telemetry mode gets or retrieves information by sendingorders without any capacity to modify or to operate ship

• operation mode operates any function of any equipmentor modifies operational configuration of the equipment

• management mode gives full access to any equipmentwith potentially high privileges or administrative rights.

1.1.2 Public network

Public networks are opened to anyone with few or norestriction.

Connection to public networks like internet is source ofthreats and risks. The needs of traffic through public net-work are to be defined and justified. The implementation ofthe limitation of public network traffic is to be explainedand strictly limited to the needs herein before defined.

When remote access to an equipment is achieved throughpublic network, the following applies:

• Telemetry mode is tolerated for Level 2 and Level 3equipment when managed through a DMZ. Telemetrymode is authorized for Level 1 equipment.

• Operation mode for Level 3 equipment is to be submit-ted for approval with motivated exception and mitiga-tion measures (Security Measures). DMZ is mandatoryfor Level 2 and Level 3 equipment. Operation mode isauthorized for Level 1.

• Management mode for Level 2 and Level 3 equipment isbanned without dedicated security solution embeddingprotocol disruption (i.e. Virtual Machines). Managementmode is authorized for Level 1.

For Level 2 and level 3 Systems, accesses from a public net-work to the vessel are to be managed through a Demilita-rized Zone (DMZ).

Delivery: Every remote access usages are to be detailed,explained and justified though a full description in theCyber Repository. A schema of the functional architecture isto be submitted. Elements are to be submitted for approval.

1.1.3 Private networkPrivate networks only accept connections from trusteddevices. Users out of a private network cannot use physicalaccess points and routers. Private networks are physical,secured environment. Because they are virtual, VPN are, inthis case, no to be considered as private networks.

When remote access to an equipment is achieved throughprivate network, the following applies:

• telemetry mode is authorized for Level 3 equipmentwhen managed through a DMZ. telemetry mode isauthorized for Level 2 and Level 1 equipment withoutrestriction

• operation mode is authorized for Level 2 and Level 3equipment when managed through a DMZ

• management mode is authorized for Level 2 and Level 3equipment through a dedicated network (i.e. VLAN)managed through a DMZ

• there is no restriction for Level 1 except the trafficencryption.

Delivery: Every remote access usages are to be detailed,explained and justified though a full description in theCyber Repository. A schema of the functional architecture isto be submitted. Elements are to be submitted for approval.

1.2 Demilitarized Zone (DMZ)

1.2.1 ArchitecturesEquipment in DMZ have a limited connectivity to the ves-sel's equipment. (See Fig 1).

The two basic rules are the following:

• the “vessel” Network pushes information to the “DMZ”Network.

• the “ground” pulls information from the “DMZ” or the“DMZ” pushes information to the “ground”.

Figure 1 : DMZ example

DMZ NETWORK

VESSEL NETWORK VESSELEQUIPMENT

PUBLIC LINK

GROUND

DMZ


NR 659, Ch 2, Sec 3

Authorized points of internal connections (inside “DMZ”and outside “vessel”) are to be declared. Usage of eachpoint of connection is to be linked to a function describedin [1.1.1] and justified.

Authorized points of external connections (inside “DMZ”and outside “Ground”) are to be declared. Usage of eachpoint of connection is to be linked to a function describedin [1.1.1] and justified.

The needs of traffic through DMZ are to be defined. Theimplementation of the limitation of DMZ traffic is to beexplained and strictly limited to the needs hereinbeforedefined.

Protocols and ports number are to be detailed. Standard portsnumber are not to be used. Protocols are to be justified.

DMZ network cables, network equipment and securityequipment when used are to be isolated from the vessel Net-work. The two networks are to be physically independent.

Note 1: For suppliers' case: A single system may also have its ownDMZ integrated by the system's Supplier, offering a tailored level ofprotection. In such a situation, the Supplier is responsible of its ownsecurity and submits elements described in Fig 2.

Figure 2 : Supplier example

Note 2: For ashore case: At the opposite, in term of architecture,the DMZ mechanism may be installed ashore. In this case, theDMZ filters the whole fleet flows. The onshore DMZ uses a privatelink only for ashore connection. See Fig 3.

Delivery: The DMZ architecture is to be detailed,explained, justified and submitted for approval in the CyberRepository.

Figure 3 : Ground DMZ example

1.3 Traffic security

1.3.1 Traffic encryption

Encryption is mandatory for external connections. OSILayer 4 (i.e. TLS) is used on networks. OSI Layer 3 (i.e.IPsec) is to be implemented, when feasible, for connectionsgoing through public networks. (See Fig 4).

Delivery: External traffic encryption mechanism are to besubmitted in the Cyber Repository.

Figure 4 : OSI layers

1.3.2 External connections

External connections include (See Fig 5):

• connections going from the "Ground" to the "DMZ"

• connections going from the "DMZ" to the "Ground".

TCP connections are allowed.

Delivery: External connections are to be detailed, justifiedand submitted for approval trough a full rationale and a net-work implementation map in the Cyber Repository.

Figure 5 : Example of external traffic

1.3.3 Firewall filtering

Firewalls are used to filter OSI Layer 2 through 4 packets.(See Fig 6).

OSI Layer 2 is to be filtered by using data link informationlike MAC address.

OSI Layer 3 is to be controlled by using network informa-tion like IP address.

DMZ NETWORK


PUBLIC LINK

GROUND

DMZ DMZ

SUPPLIEREQUIPMENT

VESSEL NETWORK

DMZ NETWORK

VESSELEQUIPMENT

PRIVATELINK

GROUND

DMZ

Physical

Data link

Network

Transport

Session

Presentation

Frame

Packet

Segment, datagram

Data

1

2

3

4

5

6

7

Med

ias

Hos

ts

Application

OT EQUIPMENT

DMZ

GROUND

VESSEL NETWORK

OT NETWORK


NR 659, Ch 2, Sec 3

Figure 6 : Firewall example

The needs of traffic through Firewall are to be defined.Authorized sources (MAC and IP addresses), protocols andports number are to be mastered and filtered the firewall.

The implementation of the limitation of Firewall traffic is tobe explained and strictly limited to the needs hereinbeforedefined.

To ensure the control of the security, the traffic is to beblocked by default. This is generally achieved by configur-ing the last rule of the access line to deny all packets.

Safety policy (Rules) are to be implemented. The Safety pol-icy (rules) are to be designed to allow passage of data trafficthat is essential for the intended operation of that network.

Delivery: Firewalls models, strategy, security mechanismimplementation and rules (Authorized sources and destina-tions) are to be delivered in the Cyber Repository.

1.3.4 Application firewall filtering

Application firewalls may be used to filter IP Layer 2through 7 packets. Application protocols may be forged inorder to gain privileges or disrupt availability of the system.Application firewalls are to be used:

• between DMZ and outside “Ground”

• between DMZ and inside “vessel”

The application firewall blocks detected intrusions and mal-formed communications.

For example: packets sent to traditional port 80 are checkedby the application firewall to remove any traffic exceptHTTP. Moreover, in order to remove tunnels, data field arealso to be checked regarding predefined compliancy of thesystem. (See Fig 7).

Delivery: If used, the application Firewall model, applica-tion compliance elements and detailed security mechanismsimplementation are to be delivered in the Cyber Repository.

1.3.5 New generation firewall filtering

NGFW should be preferred to old-generation Firewalls. (SeeFig 8).

NGFW already contain Application Firewall and IdentityAwareness.

Delivery: If used, NGFW model and installation are to bedelivered in the Cyber Repository.

1.3.6 Intrusion prevention system

IPS are used to detect attacks based on a number of differenttechniques like the use of threat signatures, known exploitattacks, anomalous activity and traffic behaviour analysis.

If detected, suspected packets are dropped.

Delivery: If used, IPS implementation is to be delivered inthe vessel Cyber Repository.

1.4 Remote access monitoring

1.4.1 Remote access events

A procedure is to be in place to regularly check the eventsautomatically generated by security equipment (i.e. NGFW,ID, IPS). A real-time check is highly recommended.

On public networks like Internet, remote access events are tobe based on comparison between awaited connections (forexample white list of IP address of authorized users; or whitelist of authenticators - login/password, physical device…).

The procedure is to explain how to check events, alertsthreshold and events to look for.

The procedure is to contain elements on when to alertresponsible and on what kind of mitigation measures to applyin case of compromising suspicion.

Delivery: Security organisation regarding events supervisionis to be delivered in the vessel Cyber Handbook.

Figure 7 : Example of dual application FW

Figure 8 : Example of NGFW

DMZ NETWORK


DMZ

FIREWALL

FIREWALL

VESSELEQUIPMENT

VESSEL NETWORK

DMZDMZ NETWORK

FIREWALL

FIREWALL

APPLICATION FW

APPLICATION FW

VESSELEQUIPMENT

VESSEL NETWORK

DMZDMZ NETWORK

NGFW

NGFW


NR 659, Ch 2, Sec 3

1.4.2 Remote access compliance

Networks connections and firewalls are to be verified by theShipowner.

A procedure is to be submitted to explain how to verifycompliance of remote access equipment, DMZ and equip-ment involved in cyber security as described in this [1.1.1].For this reason, those equipment must be inventoried.

The full list of identified equipment is then to be included inthe compliance scope of Sec 2, [1.1.2].

Delivery: Equipment on which security verifications apply areto be submitted for approval in the Cyber Repository under adedicated chapter named “remote access verifications”.

1.5 Remote access maintenance

1.5.1 Management mode

Management mode of:

• DMZ servers (onboard and ashore)

• remote access systems and DMZ security equipment(onboard and ashore)

• remotely accessed equipment (onboard).

is to be done from a dedicated network (i.e VLAN).

Delivery: Management security mechanisms of DMZ are tobe detailed, explained and submitted for approval in theCyber Repository.

1.5.2 Remote access patch management

Patch management and software updates are considered asa priority for:

• all DMZ system and equipment including all networkand security equipment (i.e. modem, switch, firewall).

• Level 2 and Level 3 equipment directly or indirectlyconnected to public networks

• ground equipment using DMZ.

Owner subscribes to supplier’s vulnerability alert lists (CVE)to be informed on the latest vulnerabilities and to getupdates.

Remote access systems software maintenance is to be exe-cuted in conformance with the change management plan asdefined in Sec 4, [5].

Delivery: Inventory of equipment and related patch man-agement procedures are to be detailed, justified and submit-ted for approval in the Cyber Handbook.

1.5.3 Remote access events logging

For Level 2 and Level 3 equipment, a procedure is to be inplace to automatically record connection, authenticationand security events generated by network equipment (i.e.switch, proxy) and security equipment (i.e. NGFW, IPS) incharge of remote access connections and operations.

The procedure is to explain how to manage events logging(storage location, copy, storage duration, etc.).

Delivery: Procedures are to be submitted for approval in theCyber Handbook.

2 Wireless networks

2.1 Wireless identification

2.1.1 Architecture

The needs of traffic through wireless network are to bedefined and justified. The implementation of the limitationof wireless network traffic is to be explained and strictlylimited to the needs as defined in Fig 9.

Figure 9 : Authorized WIFI architecture

As for cable networks, wireless networks are segregated tothe same Level of criticality (i.e. Level 1 to Level 1 is author-ized, Level 1 to Level 2 in prohibited). (See Fig 10).

Figure 10 : Prohibited network connection

Wireless networks are segregated to the same kind of net-work (i.e. OT to OT is authorized, OT to IT is prohibited).(See Fig 11).

Figure 11 : Prohibited WIFI architecture

Wireless usage for management of systems is prohibited.

Usage of wireless networks for Level 3 are to be detailed(endpoints inventory, ports and TCP layers analysis),explained and justified. Security mechanisms are to bedetailed (i.e. hidden network, monitoring).

AUTHORIZED

OT WIREDEQUIPMENT

OT WIRELESSEQUIPMENT

OT ACCESSPOINT

OT NETWORK

OT NETWORK LEVEL 1

OT NETWORK LEVEL 2

PROHIBITED

OT EQUIPMENT

OT DMZ

IT NETWORK

DMZ

Managem

ent

GROUND

PROHIBITED


NR 659, Ch 2, Sec 3

Wireless networks for Level 3 is authorized only if commu-nication:

• is established, and reserved, for the system itself (nointerconnection)

• is not used for critical operation (it means that if the wire-less network is turned off, there is no issue on operation)

• is not an entry point to critical function (as a reboundpoint if an attacker takes control of the network).

Delivery: Wireless usages are to be explained, justified anddetailed. Wireless network map is to be built. Elements areto be submitted for approval in the Cyber Repository.

2.1.2 Wireless Local Area Network (WLAN)

Wireless Local Area Network (WLAN) is a flexible datacommunications system that can use either infrared or radiofrequency technology to transmit and receive informationover the air. (See Fig 12).

Figure 12 : WLAN architecture example

WLAN is to be secure and respond to a WLAN security pol-icy managed by the Wireless Access Point (WAP).

The following is a sample list of basic requirements whichhas to be, at a minimum, implemented in the WLAN secu-rity policy:

• SSID (Service Set Identifier IEEE 802.11b) is not broad-cast for Level 2 or Level 3 networks. Operational orindustrial wireless networks are never broadcast.

• Radio broadcast levels must be reduced and adjusted atthe least need.

• Authentication relies on Wi-Fi Protected Access 3 Enter-prise (WPA3-Enterprise). It imposes a per-user authentica-tion through RADIUS and it far more secure than WPA2passphrase. The WPA3-Enterprise security type usesIEEE 802.1x for the authentication exchange with thebackend. The Advanced Encryption Standard (AES)cipher type is used for encryption. WPA3-Enterprise ismandatory from Level 2. Protocol WPA2 with passphraseis authorized for Level 1 only.

• Certificates are managed by using an authenticationmethod compatible with the Extensible AuthenticationProtocol (EAP) framework. In example: Transport LevelSecurity (EAP-TLS) or Tunnelled Transport Level Security(EAP-TTLS). EAP-MD5, EAP-LEAP are prohibited fromLevel 2.

• From Level 2, wireless networks are dedicated to a sys-tem and cannot be shared.

Delivery: For Level 2 and Level 3 system, WLAN security pol-icy is to be submitted for approval in the Cyber Repository.

3 Cabled networks

3.1 Network identification

3.1.1 Network logical cartography

For Level 2 and Level 3 systems and relevant equipment, anetwork logical cartography scheme presents architecture forIT and OT. Onboard flows and onshore communications areexplained. Cat. A, B, C equipment are relevant to this rule.

Usage of optical, copper networks and transportation proto-cols (i.e. VLAN) is to be detailed, explained and justified.

Delivery: Requested elements are to submitted in a table forapproval in the Cyber Repository.

3.1.2 Security equipment

When used, security equipment (e.g., firewalls, IDS, Inspec-tion and Decontamination Gate (IDG)) are considered Cat. B.

A dedicated inventory of security equipment is built.

Delivery: Security equipment inventory is to be submitted inthe Cyber Repository.

4 Networks

4.1 Network monitoring

4.1.1 Network events supervision

A procedure is to be in place to regularly check the networkevents automatically generated by security equipmentdescribed in [1.1.1].

The procedure explains:

• how to check network events

• how to manage alerts threshold

• what kind of events to look for

• when to alert the Cyber Security Officer

• how to apply mitigation measures in case of compro-mising suspicion.

Delivery: Security organisation regarding network eventssupervision are to be submitted in the Cyber Handbook.

4.1.2 Network verification

Network connections, usages and filtering are to be verifiedby the Shipowner.

A procedure is to explain how to verify compliance of net-works and network equipment involved in cyber security asdescribed in [2.1.1], [3.1.1] and [3.1.2]. For this reason,those equipment are to be inventoried.

The full list of identified equipment is then to be included inthe compliance scope of Sec 2, [1.1.2].

Delivery: Network equipment on which security verifica-tion apply are to be submitted for approval in the CyberRepository under a dedicated chapter named “NetworkSecurity Verification”.

WIRELESSACCESS POINT

WIRELESSEQUIPMENT

AUTHENTICATIONSERVER

WIRED NETWORK


NR 659, Ch 2, Sec 3

4.2 Network maintenance

4.2.1 Network patch managementPatch management and software updates are considered asa priority and equipment, software used for the wireless net-works shall be kept up-to-date with a strong process.

Owner subscribes to supplier's vulnerability alert lists (CVE)to be informed on the latest vulnerabilities and to get updates.

Procedures for network equipment patch management aredelivered in accordance with Sec 4, [5.2.2].

Delivery: Procedures for network maintenance are to besubmitted in the Cyber Handbook.

4.2.2 Network events loggingA procedure is in place to automatically record connections(success and failures), authentication (success and failures)and security events generated by:

• any Wireless Access Point (WAP)

• any Wireless Local Area Network (WLAN)

• any Local Area Network (LAN)

• any firewall

• any application firewall

• any State-full Packet Inspection (SPI)

• any Intrusion Prevention System (IPS)

• any equipment used to identify and authenticate net-work access

• any equipment used to enforce or ensure network security.

The procedure is to explain how to manage events logging(storage location, copy, storage duration and so on).

Delivery: Procedures are to be submitted in the CyberHandbook.


NR 659, Ch 2, Sec 4


1 Governance

1.1 Cyber risk analysis

1.1.1 Update

The Cyber Risk Analysis is to be updated by the Shipownerin case of addition, deletion or modification of:

• any system or equipment using or involved in remoteaccess

• any Level 3 equipment of Cat. A, Cat. B and Cat. C.

Delivery: The Cyber Risk Analysis update procedure is to besubmitted in the Cyber Security Policy.

1.2 Cyber security policy

1.2.1 Application

A Cyber Security Policy is to be established by the Shipowner.

The Cyber Security Policy is to detail the implementation ofevery Rule described in this Section.

In operation, application of the document is under responsi-bility of the Master.

Delivery: The Cyber Security Policy document is to be sub-mitted to the Society by the Shipowner.

1.3 Information protection

1.3.1 Documents management

Documents and files protection and privacy are to be man-aged by respecting rules described in Ch 1, Sec 1, [3.1.3].

Policy of marks and levels of protection rely on levelsdescribed in Ch 1, Sec 1, [3.1.3].

Regarding documents relevant to the class notation, theCyber Security Policy defines levels of protection by usinglevels already described in Sec 1, [2.2.2].

Delivery: Information protection policy is to be submitted inthe Cyber Security Policy.

1.3.2 Encryption policy

The Cyber Security Policy proposes an encryption policywhich defines the scope of encryption (desktop, servers,networks, removable media, communications, on shore sys-tems, email, documents).

Different kind of security levels may be proposed (sensitive,commercial, technical) in minimum respect of Sec 1,[2.2.2].

Algorithms (TLS, AES, DES) and implementation methods(type approved equipment) are defined.

1.3.3 Regulatory requirements

Legal (e.g. GDPR) and regulatory requirements applicableto the ship and regarding cybersecurity, including privacyand civil liberties obligations, are understood and describedin the Cyber Security Policy.

2 Roles and responsibilities

2.1 Management

2.1.1 The Cyber Security Policy well-defines roles andresponsibilities in minimum respect of following definitions.

Each role, nomination, training session, authorization andengagement is to be logged into the Cyber Registry.

For Level 2 and Level 3 equipment, procedures defines howto add, lock, change role, manage level of privileges orremove users in case of arrival and departures.

Delivery: Roles and responsibilities are to be submitted forapproval in the Cyber Security Policy.

2.2 Predefined roles

2.2.1 Cyber security responsible

The cyber security responsible role is defined in accordancewith Ch 1, Sec 1, [2.2.1].

Cyber security responsible ensures:

• application of Cyber Security Policy

• execution of procedures defined in the Cyber Handbook

• usage of history of changes in Cyber Registry.

Cyber security responsible delivers logical access, roles andresponsibilities in application of the principle of least privilegefor both crew members and third parties/external partners.

The principle of least privilege is commonly used in com-puters to limit users' access to resources that are legitimatefor their role. A basic security mechanisms is for examplethe user management and its relevant access control list.

Cyber Security Policy identifies the crew member in chargeof assuming this role.

2.2.2 Cyber security officer

The cyber security officer role is to be defined in accord-ance with Ch 1, Sec 1, [2.2.1].


NR 659, Ch 2, Sec 4

Cyber security officer ensures:• respect of the class notation rules application• update of Cyber Risk Analysis• update of Cyber Security Policy• update of Cyber Repository• maintenance and security of Cyber Security documenta-

tion.

The cyber security officer is in charge to inform board-levelregarding cyber events, cyber risks, threats, issues, cyber sit-uation and equipment vulnerabilities.


NR 659, Ch 2, Sec 4

2.2.3 Board levelBoard-level involvement is measurable with training andregular information about cyber threats, incidents and levelof vulnerability.

Cyber Security Policy identifies elements to be checked atboard-level regarding cyber security of the vessel (weak-nesses, vulnerabilities, security events, mitigation measures,etc.).

The cyber security officer is in charge to deliver elementsrequested at board-level.

2.2.4 Third partySecurity roles and responsibilities for third parties/externalpartners are to be detailed in the Cyber Security Policy.

The Shipowner is in charge to inform third parties regardingtheir responsibilities and cyber security procedures to applywhile in factory, locally or remotely, delivering, updating,maintaining, managing, operating or acceding any systemor equipment.

Regarding cyber security risk and procedures, the third partyis in charge to train technicians involved in maintenance.

The third party is in charge to inform Shipowner regardingany Cyber security issue or any default regarding the CyberSecurity Policy.

For Level 2 and Level 3 equipment, a tracking of third par-ties/external partners' dates of access, roles, nature of oper-ations is to be organized.

2.2.5 Declared crewFor Level 2 and Level 3 equipment, crew members, locallyor remotely accessing hardware and software, are to bedeclared to the cyber security responsible.

2.2.6 Authorized crewFor Level 2 and Level 3 equipment, crew members, locallyaccessing hardware and software, are to be controlled andauthorized by the cyber security responsible.

For Level 2 and Level 3 equipment, crew members,remotely accessing hardware and software, are to be con-trolled and authorized by the cyber security officer.

The cyber security officer may transfer the control andauthorization action to a third-party (i.e. a privilegedadministrator) in order to manage accounts during vessel'soperations. In this case, the third-party is in charge to fill theCyber Registry about this activity.

2.2.7 Crew-membersFor Level 2 and Level 3 equipment, crew members access-ing are to be trained to Cyber Security awareness, risks,administration or operation at sea and on shore.

Cyber Security Policy and Cyber Handbook application arepart of the training process.

For Level 3 equipment, crew members are to be trainedbefore their first access to those systems.

Training certificates are to be delivered in the Cyber Registry.

For Level 2 and Level 3 equipment, crew members, locallyor remotely accessing hardware and software, have signedan engagement of responsibility.

2.2.8 Privileged usersAny privileged access deliverance is to be made underauthority of cyber security officer only.

For Level 2 and Level 3 equipment, privileged users havesigned a specific engagement of responsibility

2.2.9 Remote usersRemote users are users using remote access facilities toaccess vessel's systems and equipment. Comprehensiveprocedures are to be in place in order to authorize anyremote access to the vessel.

Procedures include the following topics:

• Authentication mechanisms are implemented for con-nection: a very robust password policy is to be definedwith a regular process for password change.

• Remote service supplier is to deliver logical access,roles and responsibilities in application of the principleof least privilege.

• Remote users are to use an account for performing allmaintenance work that is separate from their regular,non-privileged account.

• A technical mechanism is to be installed to ensure record-ing of connections (success and failure). Logs are to beregularly verified by the Cyber Security Responsible.

• Time out for connection inactivity is to be defined and aprocedure explains its management. If the connection tothe remote maintenance location is disrupted for somereason, access to the system is to be terminated by anautomatic logout function.

• Ashore systems and equipment used by the remote userare declared to the Shipowner. The remote user pro-vides: flow, protocols and a detailed network cartogra-phy, matrix and addresses plan.

• Remote users are considered as part of the ship's net-work.

• When connected to the vessel, remote users cannot usecomputers connected to a second network: computersused for remote connections are dedicated to the vessel.

• When connected to the vessel through private link,remote users cannot use computers connected to a sec-ond network like, in example, public network or inter-net.

• Remote users delivers their risk analysis and their secu-rity policy regarding their own infrastructure.

• Remote users are to be controlled and authorized by theShipowner.

• Any remote access deliverance is under authority of theShipowner only.

• Remote users are responsible of the proper applicationof security procedures in place to protect the vesselagainst any malicious action, malicious content, andmalicious code injection coming from their system.

• Remote users are to be trained and are to sign a nomina-tive engagement of responsibility.

• Remote accesses are to be submitted by the Shipownerfor a limited amount of months and regularly updatedon demand.


NR 659, Ch 2, Sec 4

3 Cyber operations

3.1 Operations management

3.1.1 The Cyber Security Policy is to define roles, proce-dures and actions regarding cyber operations.For each role, nominations, training sessions, authorizationsand engagements are to be logged into the Cyber Registry.

Cyber operations are to be detailed into 3 domains:• monitoring, to detect cyber security related events.• maintenance, to update systems.• incident response, to manage situations.

Delivery: Cyber operations management policies are to besubmitted in the Cyber Security Policy.

3.2 Monitoring policy

3.2.1 DefinitionMonitoring is about periodical actions and metrics checkingregarding cyber security.

The Cyber Security Policy delivers monitoring policy proce-dures for the following contents. The objective is to have aperiodical way to check:• compliance of the vessel regarding equipment listed in

the compliance scope ( Sec 2, [1.1.2])• network activity over vessel's infrastructure.

Cyber security officer is to be in charge to check securityevents and look for alerts or suspicious behaviour in sys-tems networks and equipment.

Enforced monitoring procedures apply to Level 3 equipment.

3.2.2 Vessel complianceVessel compliance monitoring is to be done by applyingSec 2, [1.2.1] procedures issued in the Cyber Handbook.

Periodicity of monitoring is to be defined in the Cyber Secu-rity Policy for the following situations:• before going to sea: to verify proper state of the systems• after on shore maintenance operations: to check inad-

vertent/wilful modification of sensitive components orintroduction of malicious part of software

• in case of system malfunction: to lift doubts• in case of unexpected changes in equipment: to guaran-

tee the compliance of the vessel• in case of suspicious network communication behaviour

(i.e. networks slow down), the vessel and the ground• in-service: once a week, to log and trace integrity of the

systems and equipment.

Compliance monitoring frequency is to be increased for:• remote access equipment• Level 3 equipment.

Compliance Registry is to be systematically used to recordresults.

Compliance Registry is to be accurate, complete, timelyand auditable.Note 1: Compliance registry events are to be recorded in the CyberRegistry.

3.2.3 Infrastructure integrity

Compliance of any system used for remote connection to avessel is be verifiable from the board and from third partyauthority. This rule applies at any time. Vessel's infrastruc-ture events are checked.

Remote Access infrastructures monitoring policy is to bedefined thanks to Cyber Handbook procedures from Sec 3,[1.4.1] application.

3.2.4 Compliance availability

For Level 3 equipment, Cyber Security Policy is to proposeprocedures to periodically verify the effective functioning ofthe compliance monitoring.

Procedures rely on procedures defined in Cyber Handbookfrom Sec 2, [1.2.2] application.

3.2.5 Accounts integrity

For Level 3 equipment, Cyber Security Policy is to proposeprocedures to periodically test and verify validity of usersand roles. A special attention to privileged accounts is to bebrought.

Procedures rely on Cyber Handbook Sec 2, [2.4.1].

3.3 Maintenance policy

3.3.1 Definition

Maintenance is about everyday operations regarding:

• general security procedures

• updates and patch management

• log and system audits management.

Cyber Security Policy delivers organisation, roles andresponsibilities about vessel's maintenance.

3.3.2 Usage of the cyber registry

For Level 2 and Level 3 equipment, a procedure is toenforce maintenance operations to be registered inside theCyber Registry with the following information: interventiondate, nature of operation, actors, clearances, results andsecurity events if any.

3.3.3 Equipment protection

Cyber Security Policy lists equipment requesting mandatorymaintenance protection. This list can be done by checkingequipment procedures issued in the Cyber Handbook fromSec 2, [2.3.1] application.

Organisation, roles and responsibilities are defined to open,apply, verify and close equipment isolation during mainte-nance operations.

3.3.4 Updates

Cyber Security Policy defines periodicity, organisation, rolesand responsibilities for people in charge to update:

• compliance monitoring procedures (Cyber Handbookfrom Sec 2, [1.3.1])

• compliance baseline (Cyber Handbook from Sec 2,[1.3.2]).


NR 659, Ch 2, Sec 4

Cyber Security Policy also defines roles, tools, proceduresand rules for patch management. References are made toCyber Handbook update procedures for:

• antivirus software, Sec 2, [2.3.2]

• equipment software maintenance, Sec 2, [2.3.3]

• remote access equipment, Sec 3, [1.5.2]

• wireless networks, Sec 3, [1.1.1].

3.3.5 Event logging managementCyber Security Policy defines roles, tools, procedures andrules for event logging management. The objective is toensure good functioning of events recording by using CyberHandbook procedures for:

• remote access equipment, Sec 3, [1.5.3]

• wireless networks, Sec 3, [1.1.1].

3.4 Incident response policy

3.4.1 DefinitionResponse is about special situation, alerts detection andemergency management.

Cyber Security Policy is to deliver organisation, roles andresponsibilities about vessel's incident response.

Security information responsible is to be trained to apply inci-dent response policy through periodic cyber incident drills.

3.4.2 Non-compliance responseIn case of loss of compliance or any other situation asdescribed in the compliance monitoring, the cyber securityresponsible is to be in charge to:

• apply non-compliance response procedures defined inSec 2, [1.4.1]

• add event description in the compliance registry. Suchevents are to be completed with details about the pastand present situations: context of usage, external events,internal events, actions and involved people

• open a dedicated timeline of events in the complianceregistry

• have a step by step trace of those elements

• start any relevant action up to emergency procedures

• alert cyber security officer

• increase the frequency of full compliance monitoring ofthe vessel

• close the event as soon as the situation has beenexplained.

Any detection of unexpected change of compliance of anyLevel 3 equipment or network security component is to behandled with the highest level of priority and information.Master shall be informed of such event.Note 1: Non-compliance management procedures are to be sub-mitted in the Cyber Handbook.

3.4.3 Cyber security event detectionCyber security events are malicious contents like antivirusalert, malware detection, loss of compliance on securityequipment, unauthorized access to equipment.

Discoveries of cyber security events are always to bereported to the cyber security responsible.

Regarding cyber security events detection, the roles andresponsibilities are to be established and well-known fromcrew members.

Cyber security responsible is to be in charge to record cybersecurity events in the Cyber Registry.

Cyber security events are to be disclosed to the Master andthe cyber security officer as soon as possible.

3.4.4 Post processing monitoring proceduresMonitoring results may point new risks, vulnerabilities orthreats. A procedure is to explain how to:• control shutdown, reset and restart of the affected system• conduct an action plan with milestones, mitigation

measures and responsibilities.• update Cyber Risk Analysis.

3.4.5 Backup planFor Level 2 and Level 3 equipment, a backup plan describesperiodicity, roles, responsibilities, backup location and pro-cedures.

Backup actions are to be recorded in the Cyber Registry.

Procedures are to rely on Cyber Handbook Sec 2, [2.5.1].

3.4.6 Disaster recovery planFor Level 2 and Level 3 equipment, a disaster recovery planis to describe roles, responsibilities and procedures.

The disaster recovery plan is to detail procedures to recover sys-tems during or after an event. Restoration of systems and assetsaffected by the event is to be explained in a step by step way.

Procedures are to rely on Cyber Handbook Sec 2, [2.5.1]

3.4.7 Crisis managementCrisis Management is to be documented:• what to do in case of incident• who to alert• who is in charge to coordinate situation• what are the first-aids techniques.

Emergency actions are to be made under authorization andcontrol of cyber security officer or Master.

Legal action are to be managed by the Shipowner.

For Level 3 systems, disaster recovery plan decision is to beunder Master authority.

For Level 3 equipment, emergency procedures is to detailworkflow to alert Board-Level.

3.4.8 Incident reportingCyber incident are to be traced inside the Cyber Registrywith the following information:• identification of equipment• time of begin and end of intervention• people in charge of intervention• technical and functional scope of the intervention• action registry with timeline and actors• description of actions• visual identification of evidences and backup (for foren-

sic usage) done during intervention• list of modified, replaced or removed equipment.


NR 659, Ch 2, Sec 4

4 Physical security

4.1 Management

4.1.1 A set of rules regarding management of the followingis to be delivered in the Cyber Security Policy:

• physical access to the vessel's critical systems andequipment

• removable and mobile digital assets usage onboard.

Delivery: Physical security policy is to be submitted forapproval in the Cyber Security Policy.

4.2 Vessel

4.2.1 Physical access regulationThe needs of physical access to rooms containing network-ing infrastructures, remote access equipment, Level 2 orLevel 3 equipment are to be defined and justified. Theimplementation of those physical accesses are to beexplained and strictly limited to the needs hereinbeforedefined.

Cyber Security Policy refines roles defined in [2] to vessel,systems, infrastructures technical rooms and machinerooms physical accesses.

4.2.2 OutgoingsOutgoing management for the ship is to be defined in theCyber Security Policy. Outgoing crew members shall giveback rooms and cabinet keys or badges to cyber securityresponsible.

Rooms and cabinets passwords, access codes and alarms sys-tems are to be changed by the cyber security responsible.

4.3 Removable and mobile medias

4.3.1 ResponsibilitiesAny connectable digital asset introduced onboard, remova-ble or mobile support, are to be under the responsibility ofMaster and under control of the cyber security responsible.

Roles defined in [2] to removable and mobile digital assetsusage are to be defined in the Cyber Security Policy

4.3.2 AuthorizationUse of removable or mobile digital asset is restrictedaccording to the Cyber Security Policy.

All media are to be identified and authorized.

As far as possible, usage of board only, identified and veri-fied removable or mobile digital assets is to be preferred.

Their identification is to be recorded in the Cyber Registrywith the following information:

• entering date

• user

• usage (i.e. in operation, one-time maintenance)

• restriction of usage (i.e. areas, roles and users, etc.)

• authorisation of usage (attribution)

• authorized system and/or equipment

• authorized/unauthorized usage on public networks (i.e.internet)

• authorized/unauthorized usage on external computers

• authorized/unauthorized usage outside of the vessel

• other specific security rule.

Without specific motivation, Level 2 and Level 3 removableand mobile digital assets are to be:

• consigned on board

• never used on computers connected to Internet network

• dedicated to the system and equipment on whichremovable or mobile operation is needed.

Authorization is to be submitted by the cyber securityresponsible and recorded in the Cyber Registry.

4.3.3 Media scanA policy about malicious software scanning on removableor mobile digital assets is to be defined in the Cyber Secu-rity Policy. The policy is to detail:

• scope of applicability (i.e. usb keys, laptops, etc.)

• context of scanning (i.e. first time onboard, before anytype of action, before maintenance, etc.)

• periodicity (i.e. every day, week, month, etc.)

• responsibilities (i.e. under self-engagement, with cybersecurity responsible authorization, etc.)

• scanning procedure (i.e. dedicated scan station, multi-ple antivirus, single antivirus, sandbox, etc.)

• scanning tools update context (i.e. last update, 48h oldsignature database update, etc.)

• scanning certificate deliverance (i.e. printed paper, bar-code sticker, etc.).

Results of scanning process are to be recorded in the CyberRegistry with:

• reference of scanned asset

• scan certificate

• scanning date

• antivirus version and date number

• antivirus results and any results of incident

• scan user.

4.3.4 UsageDuring maintenance operation, or during any operation outof operational context, accesses to equipment via any exter-nal connection are systematically are to recorded in theCyber Registry.

Usage procedure may include specific regulation (i.e. depotin a locker for unused removable or mobile digital asset,usage of visual colours for authorized media, etc.)

Access procedures to equipment are to be well-known bythe crew:

• procedures details connection rules

• usage of the Cyber Registry is explained, accepted andmandatory

• without authorization or clearance, accesses to externalconnection of each equipment are known banned.


NR 659, Ch 2, Sec 4

4.3.5 End of life

Any information support, removable or static support, iserased, deleted or destroyed according to Cyber SecurityPolicy Cyber Security Policy under Master authority.

End of life operations are to be recorded in the Cyber Registry.

5 Change management plan

5.1 Management

5.1.1 Definition

The Cyber Security Policy delivers a set of rules regardingmanagement of changes for Level 2 and Level 3 equipmenton the vessel.

Change management is a formal and internal workflow fordriving change of any part of vessel using software or com-puter-based hardware Cat. A, B or C.

Modifications of systems, equipment, infrastructures, physi-cal location, rooms access, cabinets and networks configu-ration, system or network architecture are inputs of thisworkflow.

The Cyber Security Policy relies on Shipowners internal pro-cesses.

Change management plan, is under responsibility of Ship-owner and usually reviewed by an internal board, like ITmanagement.

Delivery: Change management plan is to be submitted inthe Cyber Security Policy.

5.1.2 Traceability

History of requests is to be recorded in the “Change Man-agement” Section of the Cyber Registry:

• requests

• approbation (i.e. functional and financial acceptation)

• homologation (pre-implantation acceptation)

• validation (post-implantation verification).

5.1.3 Everyday changes

Everyday changes are minor changes whom implementa-tion is pre-validated without application of the change man-agement plan.

Those exceptions are to be defined, decided and acceptedby the Shipowner. The list of everyday changes is presentedin the change management plan.

Application (failure or success) of everyday changes is sys-tematically recorded in the Cyber Registry.

5.1.4 International safety management

The planned maintenance of equipment should be includedin the safety management system complying with Interna-tional Safety Management (ISM) code requirements. Recordsof maintenance activities should be maintained.

5.2 Change request

5.2.1 Change requestChange of any vessel software or hardware is to berequested through an internal (i.e. Change Advisory Board)and documented workflow. Requests scope cover both reg-ular patch management and vessel upgrade.

The following considerations are to be included in thechange request:

• identification of the need of any changes to operatingprocedures or documentation

• description of how to avoid security risks includingunauthorized access and spread of malware

• identification of the software, computer based system,and network to be maintained

• identification of all computer based system affected dueto their interface connections to other computer systemrequiring the software maintenance

• identification of individual responsibility for the mainte-nance and possible supervision of technician from Sup-plier

• procedures for restoring previous stable software versionin case of failure, error or any other issue during themaintenance

• preparation for remote access, when required during themaintenance

• authorization of appropriate crew member to conductor assist with the maintenance

• authorization of technician from Supplier to conduct themaintenance

• procedures for validating the maintenance after comple-tion

• coordination with the Master for safety of navigation.

5.2.2 Patch managementFor Level 2 equipment, patch management and softwareupdates may be considered as everyday changes.

For Level 3 equipment, patch management and softwareupdates are to be considered through the change manage-ment plan.

5.2.3 Change differentialCurrent version number must be recorded in Cyber Registry.

For Level 3 equipment, history of changes on configurationfiles or physical switches are to be recorded in Cyber Registry.

Before any change, in order to keep trace, compliance stateis to be backup by using compliance monitoring proceduresdefined in Cyber Handbook in Sec 2, [1.2.1].

5.3 Change approbation

5.3.1 Change approvalThe change management plan defines a decision group andrules of processing. cyber security officer is part of this deci-sion group.

For pre-integrated Level 3 systems, version upgrades, patchmanagement are to be approved by the Supplier.


NR 659, Ch 2, Sec 4

When a change impacts connectivity or complexity, CyberRisk Analysis is to be reviewed in order to consider anyimpact on Levels of criticality. Residual risks are presentedto the decision group.

When the Supplier has determined the need for a criticalmaintenance and provided the necessary means, this mainte-nance is to be planned between the Supplier and Shipowneras soon as feasible, with a minimized downtime of theequipment.

A status of changes is to be issued by the decision group:accepted or rejected.

Status of changes are to the recorded in the Cyber Registrywith the relevant date of decision.

5.3.2 Lifecycle integrationSoftware updating enrol the vessel life cycle process witheventual safety testing and procedures.

When impacted, equipment documentation is to be upgraded.

5.3.3 Connectivity updateFor Level 2 and Level 3 equipment, change of configurationof any network configuration are to be specifically author-ized by cyber security officer.

5.4 Change homologation

5.4.1 Change homologationHomologation process is in charge of verification of level ofcyber security of the update.

For Level 2 and Level 3 equipment, before applyingchanges, security requirements from Cyber Security Policyare to be considered by cyber security officer.

5.4.2 Scan for malwaresBefore installation, equipment software files (operating sys-tems as application) are to be inspected by an antivirusmechanism in order to detect malicious parts of software.

A signature ensures the integrity and the authenticity of theupdate. This signature is to be generated by using, for exam-ple, a CRC (Cyclic Redundancy Code) mechanism. A post-update verification is to ensure that the system is performingappropriately.

Digital safety certificate is to be submitted to the cybersecurity Officer.

5.4.3 Preventive backupFor Level 2 and Level 3 equipment, a backup is to be donebefore any change, modification, update or any equipment.

For Level 3 equipment, a rollback strategy is to be deter-mined prior to updating process and previous versions ofsoftware are to be stored and available to be installed inemergency situations. The system in to have the ability torevert simply to earlier revisions in the case of corruption.

5.4.4 Onshore testing

For Level 3 equipment updated during remote maintenanceoperation, changes are to be verified on shore before beingintroduced on board. Verification are to be done throughcopy of systems on shore or virtual machines. A registry ofverification results is to be delivered to the Owner beforeapplication of the up-to-date on board.

5.5 Change validation

5.5.1 Change validation

For Level 2 and Level 3 equipment, after software update, anew compliance proper state is to be generated by using com-pliance monitoring procedures defined in Cyber Handbook.

If the Supplier has confirmed that new functionalities,changes or improvements have been implemented, theShipowner is to ensure that crew familiarization with thecomputer based system is carried out.

For Level 3 equipment, after software update, the followingtests are to be carried out by the Supplier for validation:

• regression tests (regression tests are aimed at verifyingthat no functionality which is expected to be still pres-ent after the maintenance has been impaired)

• new functionalities and/or improvements tests (testingnew functionalities and/or improvements is to verify thatthe software maintenance has had the intended effect)

• load tests (load tests are aimed to verify the behaviour ofthe system under a specific expected load, under bothnormal and peak conditions).

Verifications are to be done by using tests procedure relatedto equipment.

Verification results are to be recorded in the Cyber Registry.

Cyber security officer validation is to be mandatory beforeusing system in operation.

5.5.2 Network update controls

Specific compliance tests are to be done after change ofconfiguration of any network component.

Results are recorded in the Cyber Registry.


NR 659, Ch 2, Sec 4


NR 659

Chapter 3

ADDITIONAL CLASS NOTATION CYBER SECURE

SECTION 1 CYBER SECURE CLASS

SECTION 2 EQUIPMENT DESIGN

SECTION 3 VESSEL DESIGN

SECTION 4 SECURITY SOLUTIONS



NR 659, Ch 3, Sec 1

SECTION 1 CYBER SECURE CLASS

1 General

1.1 Application

1.1.1 Cyber secure class notationThe CYBER SECURE class notation is assigned to ships com-plying with a set of requirements to secure the vessel bydesign, using security mechanisms incorporated in theequipment and networks:

• Equipment are designed by using an approach of sensi-tive components identification, development con-straints, hardened protection, code verification andevaluation integration, secure maintenance, preserva-tion of traces and monitoring interfacing.

• Vessel integrates protection mechanisms in order toconnect vessel's equipment and systems to ashore oper-ation centres.

• Security solutions are inserted into the infrastructure inorder to provide control and reaction tools for cybersecurity management to crew members and remoteexpert teams.

The CYBER SECURE construction marks { [ µ are definedin Ch 1, Sec 1, [1.2.3].

All requirements apply to each CYBER SECURE construc-tion mark.

Specific requirements regarding { CYBER SECURE notationare detailed in each paragraph and sum up in followingtables:

• Tab 1 - Equipment Security Mechanisms

• Tab 4 - vessel cyber design

• Tab 5 - CSR Security Mechanisms

• Tab 7 - IDG Security Mechanisms

• Tab 9 - ELR Security Mechanisms.

1.1.2 SectionsThis Chapter contains:

• Sec 2, “Equipment Design”, inventories required infor-mation regarding the equipment and lists functions touse in order to achieve CYBER SECURE objectives. Thissection is relevant for equipment Supplier.

• Sec 3, “Vessel Design”, is relevant for vessel integrators.Requirements regarding remote access, equipment andsystem connections are developed.

• Sec 4, “Security Solution”, is relevant for security solu-tion suppliers. Requirements are to be detailed in orderto achieve CYBER SECURE objectives

• Sec 5, “Vessel Management”, is relevant for Shipown-ers. Requirements regarding management of cyber secu-rity are developed.

1.2 Ship approval

1.2.1 The additional class notation CYBER SECURE isassigned to a ship when procedures including periodicaland corrective maintenance, as well as periodical andoccasional inspections of its equipment, are in compliancewith this Chapter

The assignment of the µ CYBER SECURE notation impliesthat the requirements of the present Chapter are compliedwith, in particular:

• cyber security analysis is approved by the Society inconformity with Ch 1, Sec 2

• design of relevant equipment is reviewed by the Societyin compliance with requirements of Sec 2

• design of relevant security solution is reviewed by theSociety in compliance with requirements of Sec 4

• vessel management complies with rules described inSec 5

• network connectivity is approved by the Society in con-formity with Sec 3.

The assignment of the { CYBER SECURE notation impliesthat, in addition, the relevant equipment, security solutionsand network equipment are recognized by the Society

1.2.2 Equipment approval

To be fitted onboard a ship having the additional class nota-tion CYBER SECURE, any equipment defined in the scopeof application detailed Sec 2, [1.1.2], is to be approved incompliance with the requirements of Sec 2.

In order to be recognized by the Society, the equipment isto be approved in compliance with the specific require-ments of { CYBER SECURE notation, detailed in Sec 2 andsum up in Tab 1.

1.2.3 Security solution approval

To be fitted onboard a ship having the additional class nota-tion CYBER SECURE, any security solution is to beapproved in compliance with the requirements of Sec 4.

In order to be recognized by the Society, the security solu-tion is to be approved in compliance with the specific

requirements of { CYBER SECURE notation, detailed in Sec4 and sum up either in Tab 5, Tab 7 or Tab 9.


NR 659, Ch 3, Sec 1

Table 1 : Equipment security mechanisms 2 Documents to be submitted

2.1 Documents for equipment

2.1.1 Equipment security mechanisms

Equipment Security Mechanisms guide contains detailed,explained and justified information regarding the imple-mentation of security functions in the equipment. Securitymechanisms are to be submitted for approval to the Society.Example of table of contents is proposed in Tab 1.

2.1.2 Equipment administration guide

Equipment Administration Guide is dedicated to adminis-tration of the equipment with the highest level of privilege.Maintenance operations are used is special case only likeforensic investigation or software update. Example of tableof contents is proposed in Tab 2.

Table 2 : Equipment administration guide

Table 3 : Equipment operator guide

Chapter ReferenceType (1)

Mark

SystemDescription Sec 2, [1.2.1] IArchitecture Sec 2, [1.1.2] I

IdentificationEnvironment Sec 2, [1.3.1] ILevel Sec 2, [1.3.2] AExtension Sec 2, [1.3.3] ISecurity functions Sec 2, [1.3.4] A

DevelopmentRisk analysis Sec 2, [2.2.1] ADevelopment platform Sec 2, [2.2.2] I {Secure development Sec 2, [2.2.3] I {Security assurance plan Sec 2, [2.2.4] AAudits Sec 2, [2.2.5] I {Principle of least privilege Sec 2, [2.3.1] ICode robustness Sec 2, [2.3.2] I {SCADA systems Sec 2, [2.3.3] ISecure lifecycle Sec 2, [2.3.4] ISoftware delivery Sec 2, [2.3.5] I

ProtectionExtensions hardening Sec 2, [3.2.1] A {ICS hardening Sec 2, [3.2.2] AEquipment hardening Sec 2, [2.2.3] A {Accounts and roles Sec 2, [3.3.1] APasswords management Sec 2, [3.3.2] AAuthentication Sec 2, [3.3.3] APhysical acces Sec 2, [3.4.1] AStorage encryption Sec 2, [3.4.2] A {External connections Sec 2, [3.4.3] IRenewable media usage Sec 2, [3.4.4] IIn operation security Sec 2, [3.4.5] ARemotely controlled systems Sec 2, [3.4.6] A

VerificationCompliance and software registry interface

Sec 2, [4.2.1] A {

Elements of integrity Sec 2, [4.3] A

EvaluationAntivirus solution Sec 2, [5.2] A {CommutationArchitacture Sec 2, [6.1.1] AConnection management Sec 2, [6.1.2] IEncryption Sec 2, [6.1.3] AIndustrial control system Sec 2, [6.2.4] I

PreservationLogs strategy Sec 2, [7.1.1] ALogs architecture Sec 2, [7.1.2] A

MonitoringEvents Manager Sec 2, [9.2.3] A {Investigation manager Sec 2, [9.3.1] A {(1) A: For Approval I : For Information.


General

Roles Sec 2, [8.2.1] I

Administration procedures

General procedures Sec 2, [8.2.2] I

Installation procedures Sec 2, [8.2.3] I

Compliance state retrieval Sec 2, [8.2.4] I

CSR usage Sec 2, [8.2.5] I

Vulnerabilities management Sec 2, [8.2.6] I

APT mitigation measures Sec 2, [8.2.7]

Hardened operating systems Sec 2, [8.2.8]

Hardened equipment Sec 2, [8.2.9]

Security events Sec 2, [9.2.1]

Security events thresholds Sec 2, [9.2.2]

(1) A: For Approval I : For Information


General

Roles Sec 2, [8.3.1] I

Maintenance procedures

General procedures Sec 2, [8.3.2] I

Antivirus maintenance Sec 2, [8.3.3] I

Integrity chech Sec 2, [8.3.4] I

Isolation Sec 2, [8.3.5] I

Backup procedure Sec 2, [8.3.6] I

Antivirus usage Sec 2, [8.3.7] I

Equipment update Sec 2, [8.3.8] I



NR 659, Ch 3, Sec 1

2.1.3 Equipment operator guide

Equipment Operator Guide is dedicated to operationaladministration and maintenance of the equipment with themedium level of privilege. Operator actions are typicallyaccount creation, system backup and so on. Example oftable of contents is proposed in Tab 3.

Table 4 : Vessel cyber design

2.2 Documents for the vessel

2.2.1 Vessel cyber design

Vessel cyber design guide contains detailed, explained andjustified information regarding the design of the vessel, thenetworks architecture and the use of security solutions.Cyber design is to be submitted for approval to the Society.Example of table of contents is proposed in Tab 4.

2.3 Documents for security solutions

2.3.1 CSR security mechanisms

The Compliance and Software Registry (CSR) security solu-tion is detailed and its security mechanisms are to bedetailed, explained and justified. Security mechanisms areto be submitted for approval to the Society. Example of tableof contents is proposed in Tab 5.

2.3.2 CSR User Guide

The CSR User Guide contains users' guide about compli-ance management and procedure for maintenance of theCSR. Example of table of contents is proposed in Tab 6.

2.3.3 IDG security mechanisms

The Inspection and Decontamination Gate security solutionis detailed and its security mechanisms are to be detailed,explained and justified. Security mechanisms are to be sub-mitted for approval to the Society. Example of table of con-tents is proposed in Tab 7.

Table 5 : CSR security mechanisms


Mark

Architecture

Scope of application for equipment cybersecurity

Sec 2, [1.1.2] A

Network logical cartography Sec 3, [1.3.1] A

System integration of security solutions

Sec 4, [1.1.6] A

Ashore installations Sec 3, [1.3.4] A

Security mechanisms

ICS demilitarized zone Sec 3, [1.2.1] A

DMS interconnections Sec 3, [1.2.2] A

DMZ ingoing packets Sec 3, [1.2.3] A

External connections Sec 3, [1.2.4] A

Diode usage Sec 3, [1.2.5] A {

Outgoing connections Sec 3, [1.2.6] A

Management Sec 3, [1.2.7] A

Call back mechanism Sec 3, [1.2.8] A

Network

Traffic encryption Sec 3, [2.1.1] A {

Firewall Sec 3, [2.1.2] A {

Non IP traffic Sec 3, [2.1.3] I

Cable passageway Sec 3, [2.1.4] A

OT connectivity Sec 3, [2.1.5] I

Network identification Sec 3, [2.1.6] I

IP sec strategy Sec 3, [2.1.7] A

Switches security policy Sec 3, [2.1.8] I

New generation ferewall Sec 3, [2.2.1] A {

Wireless networks Sec 3, [2.2.2] A

Application firewall Sec 3, [2.2.3] I

Identify management Sec 3, [2.2.4] I

State full packet inspection Sec 3, [2.2.5] I

Intrusion prevention system Sec 3, [2.3] A {

Systems

Cabinet protection Sec 3, [3.1.1] I

Video protection Sec 3, [3.1.2] I

Alarm functions Sec 3, [3.1.3] I



Mark

Architecture

Principle of information collection and processing

Sec 4, [2.1.3] A

Inventory of collected information

Sec 4, [2.1.6] A {

Software architecture A {

Security mechanisms

System reliability mechanisms Sec 4, [2.4.2] I

Rules integrity mechanisms Sec 4, [2.4.3] I

Separated environments Sec 4, [2.4.4] A

System integrity mechanisms Sec 4, [2.4.5] A

Client protection mechanisms Sec 4, [2.4.6] A

Client integrity Sec 4, [2.4.7] A

Storage encryption mechanisms

Sec 4, [2.4.8] I

Network encryption mechanisms

Sec 4, [2.4.9] I

Removable medias protection Sec 4, [2.4.10] I

Access management Sec 4, [2.4.11] I



NR 659, Ch 3, Sec 1

Table 6 : CSR user guide

Table 7 : IDG security mechanisms

Table 8 : IDG User Guide

2.3.4 IDG User GuideThe Inspection and Decontamination Gate User Guide con-tains users' guide about files inspection and procedure formaintenance of the Inspection and Decontamination Gate.Example of table of contents is proposed in Tab 8.

2.3.5 ELR security mechanismsThe ELR (Events and Logs Recorder) security solution is tobe detailed and its security mechanisms are to be detailed,explained and submitted.

Security mechanisms are to be submitted for approval to theSociety. Example of table of contents is proposed in Tab 9.

2.3.6 ELR user guideThe ELR User Guide contains users' guide about logs man-agement and procedure for maintenance of the ELR. Exam-ple of table of contents is proposed in Tab 10.

2.4 Submitter

2.4.1 RolesAll the documents to be delivered are under responsibilityof the vessel integrator which is in charge to identify them,collect them and keep the collection up to date.

Table 9 : ELR security mechanisms

Table 10 : ELR User Guide


Functionalities

Supervision and management Sec 4, [2.2.1] I

Alerting Sec 4, [2.2.2] I

Evaluating Sec 4, [2.2.3] I

Countermeasures Sec 4, [2.2.4] I

Evaluation of the vulnerability level

Sec 4, [2.2.5] I

Equipment qualification Sec 4, [2.2.6] I

CSR integrity Sec 4, [2.2.7] I

Vessel integrity Sec 4, [2.2.8] I

IOC on-demand Sec 4, [2.2.9] I

Maintenance

SYSLOG management Sec 4, [2.3.1] I

Restoration procedures Sec 4, [2.3.2] I

Emergency procedures Sec 4, [2.3.3] I

Storage management procedures Sec 4, [2.3.4] I

Security events description Sec 4, [2.3.5] I

(1) A: For approval I : For information

Chapters ReferenceType (1)

Mark

Architecture

Workflow and architecture Sec 4, [3.1.3] A {

Security mechanisms


System integrity mechanisms Sec 4, [3.4.3] I

Network protection Sec 4, [3.4.4] I



Functionalities

On-demand local scans Sec 4, [3.2.1] I

On-demand remote scans Sec 4, [3.2.2] I

IDG capture points Sec 4, [3.2.3] I

Automated remote scans Sec 4, [3.2.4] I

Extended IDG Sec 4, [3.2.5] I

ELR connection Sec 4, [3.2.6] I

Maintenance

SYSLOG management Sec 4, [3.3.1] I

Restoration procedures Sec 4, [3.3.2] I

Updates Sec 4, [3.3.3] I

Security events Sec 4, [3.3.4] I



Mark

Architecture

Workflow Sec 4, [4.1.2] A {

Architecture Sec 4, [4.1.3] A {

Supervision and management

Sec 4, [4.2.1] I

Alerting Sec 4, [4.2.2] I

Recording Sec 4, [4.2.3] A [

Security mechanisms


Encryption Sec 4, [4.4.3] I

Storage Sec 4, [4.4.4] A

Integrity Sec 4, [4.4.6] A

Source authentication Sec 4, [4.4.7] A

Timeline Sec 4, [4.4.8] A

Events signature Sec 4, [4.4.9] A

Time synchronization Sec 4, [4.4.10] A



Functionalities

Events and logs recording Sec 4, [4.2.1] I

Maintenance

Records management Sec 4, [4.3.1] I

System restoration Sec 4, [4.3.2] I



NR 659, Ch 3, Sec 2

SECTION 2 EQUIPMENT DESIGN

1 General

1.1 Application

1.1.1 Responsibilities

This Section applies to equipment suppliers and definesequipment design in terms of cyber security.

Refer to Ch 1, Sec 1 [1.3.3] for a definition of terms regard-ing systems and equipment.

Vessel integrators are in charge to request rules applicationat equipment at design level, to verify documentation deliv-ery, mechanisms implementation and global conformity ofequipment.

1.1.2 Scope

This Section applies to:

• following categories of equipment defined in the scopeof Cyber Risk Analysis as explained in Ch 1, Sec 2, [2.3]:

- Cat. A equipment except Level 1

- Cat. B equipment except Level 1

- Cat. C equipment except Level 1 and Level 2

• software developed and using network connectiondefined in the scope of Cyber Risk Analysis as explainedin Ch 1, Sec 2, [2.3]

• the security solutions as defined in Sec 4.

Delivery: The scope of application is to be submitted forapproval in the vessel cyber design.

1.2 System integration

1.2.1 Description

When the equipment if part of a pre-integrated system (mul-tiple equipment), the system is to be explained with the fol-lowing elements:

• purpose of the system

• major requirements

• specific features

• connections (with other systems)

• listing equipment per equipment

• requirements regarding pre-integrated systems as definedin Ship Rules, NR467 Pt C, Ch 3, Sec 3, [8.1].

• the network devices for Category II and III systems (asdefined by IACS UR E 22) should be suitable for marineapplication and should be tested to requirements speci-fied in IACS UR E10. Wireless equipment should be

designed and tested as per requirements specified inUR E10.

Delivery: System is to be submitted in the Equipment Secu-rity Mechanisms.

1.2.2 Architecture

A network scheme is to present the system with equipment.

Delivery: Architecture scheme is to be submitted in theEquipment Security Mechanisms.

1.2.3 Management

Rules from Ch 2, Sec 2 are to be applied: relevant deliveriesare to be submitted.

1.3 Identification

1.3.1 Environment

The function of the equipment is briefly explained:

• objectives of equipment

• major functions and services

• major requirements

• if the equipment is part of a system, networking andcommunication are briefly presented:

- interconnections (with equipment inside the system)

- connections (with equipment outside the system)

• category of each equipment is to be chosen from Ch 1,Sec 1, [2.3.1] definition

• onboard equipment listing relies on Ship Rules, NR467Pt C, Ch 3, Sec 3, [4.3] inventory

• the global version number of the equipment is to beprovided.

Delivery: Environment is to be submitted in the EquipmentSecurity Mechanisms.

1.3.2 Level

The Level of the equipment is to be selected, explained andjustified. The Level hereinbefore selected is a way to determinewhich of the requirements from the notation are applicable.

The level of equipment determines its possible utilisationrange.

Delivery: Level is to be submitted for approval in the Equip-ment Security Mechanisms.

1.3.3 Extensions

Extensions of some pieces of equipment are to be deliveredfor use by the security solutions mechanisms:


NR 659, Ch 3, Sec 2

Cat. A equipment extensions are:

• operating system identification

• all applications (developed or off the shelf) and installedon the equipment

• all services (services listening for connections)

• databases (managed, stored and, or, accessed)

• distributed directory information services

• virtual machines and hypervisors

Delivery: Extensions are to be submitted in the EquipmentSecurity Mechanisms.

1.3.4 Security functions

Security functions are groups of security mechanismsimplemented within an equipment itself, a system or aglobal system shared by vessel (see Fig 1).

The implementation of the following security functions isexplained, detailed and justified:

• Development:

Organisation of equipment protection during develop-ment phase.

• Protection:

System hardening in order to manage integrity, confi-dentially and availability of code and related data. Pro-tection apply on logical (operating system, services,application) and physical levels.

• Maintenance:

Workflows and procedures to manage, update andrestore equipment.

• Verification:

Supervision used to check and validate the complianceof the equipment logical processes (operating system,application and services) and ensure they are in aproper state of functioning.

• Evaluation:

Gate used to scan software, scripts and executable partof code for any malicious content.

• Commutation:

Network and system services used to redirect informa-tion from, and to, the equipment to, and from, otherequipment of the system and other systems of the vessel.

• Preservation:

Trace and record logs and events about protection, veri-fication, evaluation, maintenance and commutation.

• Monitoring:

Alerts at the attention of the cyber security officer in thesecurity operation centre (ashore) and, or, the cybersecurity responsible (onboard)

Figure 1 : Equipment security functions

For the security functions detailed hereafter, a rationale is toexplain, detail and justify if the security functions areassumed by the equipment itself, relying on the system orrelying on the vessel systems. Security functions may andshould use, in preference, the global security functions usedfor the vessel (as explained in Compliance and SoftwareRegistry in Sec 4, [2]). Nevertheless if the system or equip-ment cannot exchange or share information with the vesselcentral system, it is to demonstrate that the equipmentensures the functionalities described in Sec 4 for the follow-ing elements:

• verification: Compliance and Software Registry

• evaluation: Intrusion and Decontamination Gate

• preservation: Events and Logs Recorder.

Delivery: Security functions are to be submitted forapproval in the Equipment Security Mechanisms.

2 Development

2.1 Context

2.1.1 The development security functions are dedicated tothe period before the installation and use of the equipmentaboard, both for the first release and the updates.

Development security functions apply to Supplier and,more precisely, to the development platform used in hispremises.

2.2 Development platform

2.2.1 Risk analysisSupplier of the equipment manages a risk analysis for hisdevelopment platform. This risk analysis is reviewed regu-larly in accordance with the security policy of the company.

Delivery: Information regarding the risk analysis, majorthreats and mitigation measures is to be submitted forapproval in the Equipment Security Mechanisms.

Development

Evaluation

Verification

Protection

PreservationMaintenance

Monitoring

Operating system

Services

Application

Commutation

Otherequipment& systems

Equipment


NR 659, Ch 3, Sec 2

2.2.2 Development platformCommissioning processes should be provided by the systemsprovider so that testing can be carried out on live systems.

Equipment supplier ensures cyber security of its develop-ment by using a secured development platform: code repos-itory, workstations update, servers protection, scans formalicious codes, CVE patch management, pen tests...

When cyber security products recognized by the Societyare used (both software and hardware) for the protection ofthe development activity, a brief rationale explains theirmanagement regarding updates and monitoring.

Delivery: A description of development platform security orthe results of audits or a national or an international certifica-tion is to be submitted in the Equipment Security Mecha-nisms.

Note 1: To get { CYBER SECURE notation, development platformis to be recognized by the Society.

2.2.3 Secure developmentDevelopments of the equipment are to be secured thoughthe application of a guideline (i.e. BV-SW-200).

Delivery: A description of development security measures orthe results of audits or a national or international certificationis to be submitted in the Equipment Security Mechanisms.

Note 1: To get { CYBER SECURE notation, cyber security for soft-ware development guideline is to be recognized by the Society.

2.2.4 Security assurance planSupplier provides a security assurance plan giving all thecyber security measures applied during development andmaintenance. This document specifies organisationalaspects, human responsibilities and technical meansinvolved in the cyber security. This document is consideredas a traceable engagement of responsibility from the supplier.

Delivery: Supplier's security assurance plan is to be submit-ted for approval in the Equipment Security Mechanisms.

2.2.5 AuditsSupplier agree to be audited by an authorized third partywhom role will be to proceed to verification of the cybersecurity respect.

Delivery: A result of audit or a national or an internationalcertification is to be submitted in the Equipment SecurityMechanisms.

Note 1: To get { CYBER SECURE notation, audit is to recognizedby the Society.

2.3 Development principles

2.3.1 Principle of least privilegeIn order to limit introduction of vulnerabilities in the soft-ware, the principle of least privilege is systematically to beused:

• regarding interfaces (accounts, opened ports, processesin memory, human interfaces...)

• regarding complexity in the software (use of libraries incascade, unknown parts of software...)

Delivery: A description of application of principle of leastprivilege is to be submitted.

2.3.2 Code robustnessEquipment supplier is to demonstrate how their develop-ment workflow ensure a state of the art in cyber security forthe development themselves. Quality processes are to beexplained. Technical processes used in order to detect mali-cious part of code, vulnerabilities and software securityholes are to be addressed and demonstrated.

Delivery: Tests results regarding robustness of the code areto be submitted.

Note 1: To get { CYBER SECURE notation, technical process, toolsand partners used to check malicious parts of code are to be recog-nized.

2.3.3 SCADA systemsDevelopment good practices are to be defined, applied andverified. Compiler options involved in code improvement(safety and security) are turned on. For SCADA systems,options related to user warnings are activated as theyreduce risk of software vulnerabilities.

Delivery: Compilation rules for SCADA systems are to bedetailed, explained and delivered.

2.3.4 Secure lifecycleRegarding the code developed, the Supplier is to ensuresecurity of the relevant technical documentation, sourcecode during a period up to the end of life of the equipment.It means that vulnerabilities will not be published without acorrective patch, code will not be accessible for a publicusage and technical aspects (interfaces, protocols...) will notbe shared without authorization.

Delivery: Secure lifecycle principles are to be submitted inthe equipment security mechanism.

2.3.5 Software deliveryBefore delivery, equipment software files (installation media,installation packages, operating systems, software) are to beinspected by an antivirus software in order to detect mali-cious parts of software.

Delivery: Software delivery principles are to be submitted inthe equipment security mechanism.

3 Protection

3.1 Context

3.1.1 Protection is defined during design phase of theequipment.Protection of the equipment is in charge to:• keep data in confidentiality.

• warranty the integrity of variables, configuration filesand in-memory parameters

• warranty the integrity of functions (code execution)• deliver the best level of service in term of code availabil-

ity and, thus, the best level of effort in term of bug hunt-ing to reduce the risk of code injection (denial ofattacks, buffer overflows).

The protection applies to: operating system, services, appli-cation.

Protection uses logical or physical security mechanisms.


NR 659, Ch 3, Sec 2

3.2 Hardening

3.2.1 Extensions hardeningFor Level 3 equipment, extensions listed in [1.3.3] are hard-ened in respect of the principle of least privilege:• operating system (i.e. Linux, Windows, etc.)• database (i.e. MySql, Oracle, etc.)• services (i.e. Apache)• desktop application (i.e. any local application)• web browsers (i.e. Internet Explorer)• virtual machines (i.e. Virtualbox, Docker, etc.)• distributed directory information (i.e. LDAP).

Hardening principles cover the following topics:• identification and authentication• users accounts and groups• file system configuration (access control list)• local and remote administration• boot time security mechanisms• services configuration, selection and filtering• network configuration and filtering• auditing policy• logging configuration• maintenance operations• useless components• any other specific topic.

Note 1: CLIP OS or SELinux are two examples of hardened operat-ing systems with implementation of the principle of least privilege.

Delivery: For each extension hardening strategy is to besubmitted for approval in the cyber security mechanisms.

Note 2: To get { CYBER SECURE notation, hardening guides are tobe certified by the Society.

3.2.2 ICS hardeningA particular attention should be done for OT systems hard-ening. For example:• useless software, part of software, services, static or

dynamic libraries, development code, developmentlibraries, test environment are removed

• useless components shall be uninstalled as much aspossible, deactivated: - default accounts, unused physical ports, unused

removable supports, unused system process and ser-vices, debug tools, files, development on worksta-tions and industrial controllers

- unused files and executables on workstations- PDF files and reader on SCADA stations

• SCADA (Servers and System Control And Data Acquisi-tion) are to be submitted with runtime only software andfiles

• if equipment requires development components (e.g.SNCC Control Command), mitigation measures shall besupplied in order to isolate workstation from irrelevantequipment of the network

• operator console have a visual identifier• physical access restriction to CPU and PLC• deactivation of remote programming mode

• client IP address restriction.

Delivery: For ICS systems hardening strategy is to be submit-ted for approval in the cyber security mechanisms.

3.2.3 Equipment hardeningSecurity mechanisms of Cat. A, Cat. B and Cat. C Level 3equipment or system containing the equipment are approvedby a third-party independent authority which ensure verifica-tion of the following topics, as far as possible:

• mechanisms on intrusion detection• connection, communication encryption and firewalling

rules• local data encryption and deletion mechanisms• protection against malwares and malicious codes• equipment administration and supervision procedures• account management, identification, authentication and

access control• physical security.

Delivery: Security target and certificate of security for theCat. B equipment is to be submitted for approval by theSupplier.Note 1: Common criteria evaluation assurance Level EAL3+ is anexample of certification.

Note 2: To get { CYBER SECURE notation, equipment hardening isto be recognized by the Society.

3.3 Access

3.3.1 Accounts and rolesFor any equipment:• Different kinds of accounts are used:

- session accounts are authenticated sessions used toaccess to operating system

- application accounts are used to access to applica-tion, to display information or to do actions

- system accounts are used by applications, services andsystem to authorize sessions, execute software and tomanage data both for storage and communications.

• Session and application accounts have separated rolesdefined for the following functions:

- account administration- system administration- everyday maintenance- data backup- operational usages.

For Level 2 and Level 3 equipment:• Equipment are designed for logical access with the prin-

ciple of least privilege.• Equipment cannot be accessed without authentication

mechanism (identification and “password”).• Equipment have a list of group of users with detailed

privileges, directory access and roles. Each role, privi-lege, network, file and process access shall be justified.

• List of default and predefined accounts and/or groups isto be submitted. Relevant tests are to be submitted sothat, at administrator level, usage of predefined


NR 659, Ch 3, Sec 2

accounts may be detected and action to erase themcommitted.

• Generic accounts shall not be used. When used, usageof generic accounts are justified and submitted forapproval in the Equipment Security Mechanisms.

• Generic accounts with privileges are banned.

Delivery: Rationale about users is to be detailed, explainedand submitted for approval in the Equipment SecurityMechanisms.

3.3.2 PasswordsFor any equipment:

• Password are robust. Robustness of password dependsof the system and shall be detailed by the supplier.Robustness shall be verified through comparison withpassword history, usage of a password complexity testand renewal of password at regular period (30, 60, 90days...) If, for operational, safety or any other demon-strated reason, system have to be accessed withoutauthentication, mitigation measures shall be proposedlike physical access control, operation system hardeningor limitation of functions.

• Equipment furnish procedures and tools to reset pass-words.

For Level 2 and Level 3 equipment:

• Password are encrypted when sent over the network,sent to another process or stored.

Delivery: Password policy is to be detailed, explained andsubmitted for approval in the Equipment Security Mecha-nisms.

3.3.3 AuthenticationFor Level 2 and Level 3 equipment:

• In case of authentication failure, a growing timeout maybe used instead of account locking. This rule is recom-mended, not mandatory.

• Software changes in systems (modification of data byservice) should be secured by two-factor authentication.

For Level 3 equipment:

• A strong authentication shall be applied to equipment(i.e. OTP, smart card).

Delivery: Authentication policy is to be detailed, explainedand submitted for approval in the Equipment SecurityMechanisms.

3.4 Physical security

3.4.1 Physical accessThe following Rules apply to Level 3 equipment.

Hardware traps may be used by attackers in order to logkeystrokes and record password or transmit them throughthe air. Traps are threats which can be covered by physicalcountermeasures and access restriction to hardware con-nectors like USB.

Equipment physical security is taken into account duringdesign phase in order to lower threats like hardware trap-ping, robbery or malicious access to information:

• locked door for tower based computers• locked external connections like usb, Ethernet, local

console• locked box• lock or badge reader for ICS• for light, portable or movable equipment, anti-theft

mechanism shall be considered like anti-theft cable forlaptop, screwed computers, locked cabinet and lockedroom for removable media storage.

Delivery: The following topics are to be submitted forapproval in the cyber security mechanisms:• description of security mechanisms (to the attention of

administrators)• description of mitigation measures (to the attention of

cyber security officer)• operating rules (to the attention of cyber security

responsible and operating crew members).

3.4.2 Storage encryptionPhysical supports and disks of Level 2 and Level 3 equip-ment are encrypted. At least, if file system doesn't handleencryption (ICS for example), sensitive and configurationfiles shall be encrypted or, at least, not clearly written.Delivery: Encryption mechanisms strategy and tools are tobe submitted for approval in the Equipment Security Mech-anisms.

Note 1: To get { CYBER SECURE notation, equipment storageencryption mechanism is to be recognized by the Society.

3.4.3 External connectionsThe following Rules apply to Level 3 equipment.• Each usage of external connection is detailed (e.g. USB,

Ethernet, Bluetooth ports...).

Delivery: External connections are to be detailed and sub-mitted in the Equipment Security Mechanisms.

3.4.4 Renewable media usageThe following Rules apply to Level 3 equipment:• removable media usage is restricted by configuration

and use of operating system level mechanisms, BIOSrestriction, dedicated software or physical locks

• removable media are natively encrypted except in caseof justified operational usage.

Delivery: Removable media usage and policy are to beexplained and submitted in the Equipment Security Mecha-nisms.

3.4.5 In-operation securityThe following rules apply to Level 3 equipment while in-operation:• critical families of operations are defined for equipment.

A control panel is installed on the bridge and linked to thesystem in order to visually status the use of critical equip-ment (i.e. with a red, green signal):• in proper state (usable) - for example green signal• at risk (i.e. loss of compliance) - for example yellow signal• in maintenance (unavailable, cannot be used) - for exam-

ple red signal.


NR 659, Ch 3, Sec 2

During Critical operations:

• any local or remote maintenance operation on theequipment is banned

• onboard, the Master can physically turn off any way togain remote access to the equipment

• during critical operations, the Master turns off remoteaccess to the equipment by using the mechanisms here-inbefore delivered

• after critical operations, the Master turns back onremote access to the equipment.

• mechanisms hereinbefore delivered disconnect any net-work link. The mechanisms is physical and may be anelectrical relay or a manual procedure.

Delivery: Procedures and mechanism regarding mainte-nance during critical operations are to be detailed and sub-mitted for approval in the equipment security mechanism.

3.4.6 Remotely controlled systems

The following rules apply to Level 3 equipment usingremote control system over networks and, in particular, forsoftware dependent machinery systems as defined in IACSRec. No.154.

The objective of this rule is to guarantee the safety of deliv-ery of the service of a system in case of failure or compro-mise of the remote systems used to control the main system:

• remotely controlled systems are to be controlled locallyby the use of a Human Machine Interface (HMI)

• local control systems are to be of a robust design suita-ble for the environmental exposure and the intendedoperation

• local control systems are to be self-contained and notdepend on other systems or external communicationlinks for its intended operation

• facilities for selecting “local” at or near the system is to beprovided. When local control is selected, any control sig-nal(s) from the remote control system are to be ignored.

Note 1: Note regarding propulsion: A single failure in a local con-trol system should not cause loss of the system function. For single-engine plants, this normally implies that component redundancyshall be arranged. For multiple engine plants with independentlocal control systems, the objective could be satisfied providedminimum manoeuvrability for the safe operation of the vessel ismaintained after a single failure.

Note 2: Note regarding auxiliary services: For electrically drivenunits in auxiliary services, the local control should normally bearranged at the motor starter in MCC's and, if applicable, also nearthe EUC. For machinery systems which due to their complexityrequires continuous automatic control, manual control of the indi-vidual EUC's may not be feasible. In such cases, local means shallbe provided to both monitor the concerned process- and to ena-ble/disable any automatic functions / modes (a typical example isthe gas supply system to a gas fuelled engine).

Delivery: Design, mechanisms and procedures regardingremotely controlled systems are to be detailed and submit-ted for approval in the equipment security mechanism.

4 Verification

4.1 Context

4.1.1 Verification cover solutions in charge to check ele-ments from the equipment regarding a previous, accepted,status.

4.2 Equipment compliance

4.2.1 Compliance and software registryCompliance of Level 3 equipment is verified by using anautomated solution.

Compliance in defined in [2.1.1]

The scope of the compliance covers any elements of theequipment and extensions listed in [1.3.3].

Elements of integrity used by the solution rely on thosedefined in [4.3].

Depending of the choice regarding security function for ver-ification [1.3.4], the automated solution may be:

• The compliance and Software Registry solution alreadyinstalled in the vessel under authority of the vessel inte-grator. In that case, equipment guarantees implementa-tion of the CSR mechanism which may be:

- a dedicated service installed in the equipmentwhich sends, upon CSR request, information to thecentral unit in charge to centralize information andmonitor alerts

- a dedicated software installed in-memory of theequipment which sends information to the CSR incharge to centralize information and monitor alerts

- a local classical service dedicated which answers tolocal CSR requests through SSH, SNMP.

• An independent compliance solution designed by theSupplier in respect of Sec 4 Rules regarding Complianceand Software Registry security solution.

For unconnected, standalone Level 3 equipment, an auton-omous, standalone and embedded component installed inthe memory of the equipment which triggers human reada-ble alerts is accepted. In case of loss of compliance, humanreadable alerts could be done:

• through an analogic relay (visual, noisy)

• through a computer screen as long as this screen is reli-able and always turned on.

Delivery: Compliance and Software Registry Interfaces areto be submitted for approval to Society in Equipment Secu-rity Mechanisms.

Note 1: To get { CYBER SECURE notation, equipment is to beinterfaced with a Compliance and Software Registry solution recog-nized by the Society.

4.3 Elements of integrity

4.3.1 DeliveryDelivery: Elements of integrity as explained in [4.3] are tobe submitted for approval to Society in Equipment SecurityMechanisms.


NR 659, Ch 3, Sec 2

4.3.2 Compliance integration

Elements of integrity are defined and selected by the Sup-plier, independently of the solution used onboard to verifycompliance of the equipment.

Elements of integrity are a list of sensitive elements definedby the Supplier on which compliance may rely on in orderto detect unauthorized changes on the equipment.

Elements of integrity is a list of elements which should try tobe exhaustive, independently of how it will be used.

4.3.3 Operating systems

Elements of integrity for operating system are to be submit-ted by the Supplier of Cat. A equipment to master compli-ance monitoring and reveal any loss of integrity at operatingsystem level.

To achieve this, a detailed list of expected compliance foroperating systems, installed components and applications isto be submitted from the following list:

Scope of compliance for hardened systems and application:

• Any element from [3.2].

Scope of compliance for files:

• operating system detailed version number

• desktop applications installed by the operating systemwith their detailed version number

• software preinstalled from operating system, manuallyinstalled, developed by third party, provided by softwareeditors or simple off-the-shelf component: name, instal-lation date, version, file path.

• mounted volumes and filesystem type and information

• filesystem contents, with directories, files, access con-trols, sizes, time stamps and file signatures

• filesystem and files encryption when handled at operat-ing system level.

Scope of compliance for operating system configuration:

• supplier-defined sensitive applications and related exe-cutable files, configuration files, hives (i.e. WindowsRegistry)

• accounts, privileges and groups and all elements rele-vant with access control lists (i.e. file access)

• security and audit policies.

Scope of compliance for network usage:

• network and system services installed by the operatingsystem with their detailed version number.

• connections listed with origin/destination information(i.e. mac ip address, port number,) when they are:

- listening: accepting connections

- outgoing: opening outgoing connections from theequipment to another one

- local only: internal to internal process.

• network shared and mounted volumes

• remotely logged on users

Scope of compliance for physical components (as they areseen from the operating system):

• network interfaces identifiers (i.e. MAC address)

• identifiable physical components (i.e. chipset)

• identifiable physical support installed (i.e. disk drive,removable media)

• identifiable components checksums (i.e. BIOS (BasicInput/Output System), UEFI (Unified Extensible Firm-ware Interface))

• USB (Universal Serial Bus) activity history

• removable media usage

• restriction or limitation and any other kind of serial linkusage.

• locally logged on users.

Scope of compliance for memory usage:

• running processes, memory access controls, processsizes, relevant process time stamps, relevant processactivity and process hashes.

• executed shell commands.

4.3.4 Services

Web Services are process listening for network connections.They can be provided by operating system or installed froma third party software editor, developed and so on.

Compliance of those components is based upon the cleardefinition of elements defined in [4.3.3]:

• version information

• files restrictions

• process restrictions

• network restrictions

• accounts restrictions.

4.3.5 Databases

Database (i.e. mySQL, Oracle...) means any organized col-lection of data.






• accounts restrictions (administrators, operators andbackup operators)

A dedicated section about compliance of databases permis-sions, users and configuration:

• Access Control from User Table

• Encryption and key management

4.3.6 Distributed directory information services

Lightweight Directory Access Protocol (Microsoft ActiveDirectory, Open LDAP...) is the industry standard applica-tion protocol for accessing and maintaining distributeddirectory information services.


NR 659, Ch 3, Sec 2






• accounts restrictions (administrators, operators andbackup operators)

A dedicated section details compliance for additions, dele-tions, and changes in LDAP directory services.

4.3.7 Hardware integrityWhen available, CSR receives SMART (Self-Monitoring,Analysis and Reporting Technology) or SNMP indicatorsfrom equipment to evaluate level of hardware integrity onphysical support.

Physical support installed (i.e. disk drive, removable media)may also be checked as required part of the equipment.

4.3.8 Cat. B equipmentCat. B elements of integrity are to be submitted by the Sup-plier to master compliance monitoring and reveal any lossof integrity of the appliance.

Cat. B equipment may use, for example, configuration pro-files or system firmware by comparing version numbers andchecksums.

Network equipment such as routers, firewalls may have adetailed list of expected compliance:

• access control list to network

• serial interfaces and removable media

• configuration files, environment variables; any otherinformation of interest relevant to network appliancecompliance.

4.3.9 Cat. C equipmentCat. C elements of Integrity are to be submitted by the Sup-plier to master compliance monitoring and reveal any lossof integrity of a single equipment or a whole system.

Cat. C equipment, when available, have a detailed softwarelisting with roles, configuration advices, manufacturers andsecurity management.

The compliance check may use:

• ICS name, brand, model or reference (some devices(e.g.modular PLCs) contain several references

• ICS version of the embedded firmware

• ICS system messages, registry keys

• ICS product version if appropriate

• network interfaces identifiers (i.e. MAC address)

• flow matrix with source, destination

• protocol (i.e. modbus, TCP)

• protocol information (i.e. ports, service)

• programmed support checksums.

4.3.10 Virtual machinesAs a virtual machine is considered as an equipment, equip-ment using virtual machines have to apply the whole scopeof Rules of this Section to each virtual machine.

4.3.11 HypervisorsHypervisors are process managing virtual machines.

Compliance of those components is based upon the defini-tion of elements defined in [4.3.3] applied to the hypervisoritself. In example, compliance of network componentsapply to virtual networks managed by the hypervisor.

For this reason, [4.3.3] fully apply but from an hypervisorpoint of view. Sensitive files take into account:• virtual machines profiles (containing virtual hardware

definition, virtual disk file path)• virtual networks (mounted by the hypervisor to connect:

- virtual machines to virtual machines- virtual machines to external networks.

4.3.12 AntivirusAntivirus are sensitive process which may stay updated andactivated. Any deactivation is detected. Compliance toolshall pay a particular attention to antivirus integrity of thesoftware regarding its binaries, configuration and signaturesfiles on disk and its processes in memory.

Compliance of antivirus is based upon the clear definitionof elements defined in [4.3.3]:• version information• files restrictions• process restrictions• network restrictions• accounts restrictions.

4.3.13 Other referencesThe vessel integrator shall also include the following ele-ments, depending of their availability and impact in case ofloss of integrity:• about network equipment:

any desktop applications information as detailed in ShipRules, NR467, Pt C, Ch 3, Sec 3, [6.3.4]

• about equipment software:any desktop applications information as detailed in ShipRules, NR467, Pt C, Ch 3, Sec 3, [4.5.6]any network and system services information as detailedin Ship Rules, NR467, Pt C, Ch 3, Sec 3, [4.5.7]

• about system hardware:any integrated system component information as detailedin Ship Rules, NR467, Pt C, Ch 3, Sec 3, [8.2.4]

5 Evaluation

5.1 Global

5.1.1 PrincipleWhen introduced in an equipment, transmitted by or exe-cuted by, parts of code and software may contain maliciouspart of code. The evaluation is in charge to check those ele-ments and to protect equipment from those threats.

5.1.2 IDG usageUsage of an Inspection and Decontamination Gate (IDG)depends of the vessel's Integrator as explained in Sec 3,[3.1.3].


NR 659, Ch 3, Sec 2

5.1.3 Antivirus usageUsage of an antivirus solution is mandatory on equipment.

Usage of an antivirus solution is banned on Level 2 andLevel 3 equipment insuring real-time control of criticaloperations. In this case mitigation measures are in place tocontrol the risk of logical access to the equipment.

5.2 Antivirus

5.2.1 DeliveryDelivery: Antivirus mechanisms as detailed in [5.2] are tobe submitted for approval to Society in Equipment SecurityMechanisms.

Note 1: To get { CYBER SECURE notation, equipment is to use aantivirus solution recognized by the Society.

5.2.2 Antivirus softwareEquipment have an antivirus solution capable of malicioussignatures recognition (anti-key loggers, anti-malware, anti-spyware, anti-virus) and malicious behaviour recognition(heuristic analysis).

5.2.3 Antivirus activationAntivirus cannot be deactivated or uninstalled by users.Antivirus is launched with system rights. Antivirus action ordeactivation requires highest administrative privileges.

Antivirus is launched with operating system before local ornetwork, user or system access to system

6 Commutation

6.1 Network policy

6.1.1 Commutation mapFor Level 2 and Level 3 equipment, a map of network con-nection details:

• incoming and outgoing connections

• involved interfaces and networks

• involved processes and services

• list, location and roles of other equipment.

Delivery: Equipment connectivity through cabled or wirelessnetworks is mastered, detailed and submitted for approvalby the Supplier in the equipment security mechanism.

6.1.2 Connection inactivityLevel 3 equipment is to propose a delay to ensure the clientor server a function to close the connection after this periodof inactivity while saving critical resources.

Delivery: Rules about equipment connection managementare to be submitted by the Supplier in the equipment secu-rity mechanism.

6.1.3 Communication encryptionTo defeat packets replay over the network, Level 2 andLevel 3 equipment network communications are encrypted.

Unsecured protocols are banned (HTTP, FTP (File TransferProtocol)...) and replaced by secured one (HTTPS, SFTP

(Secure File Transfer Protocol)…) in order to guaranteeintegrity, confidentiality, non-repudiation and authenticity.

In case of technical constraint, other secured system (i.e.Virtual Private Network) are to be submitted as mitigationmeasures.

Delivery: Equipment network encryption policies is to besubmitted for approval by the Supplier in the equipmentsecurity mechanism.

6.2 Industrial Control Systems (ICS)

6.2.1 Engineering workstationNetwork activities of engineering workstation of OT systemsare dedicated to engineering activities.

6.2.2 Operator consoleNetwork activities of operator consoles of OT systems arededicated to maintenance and operations activities.

Level 2 and Level 3 operator consoles are connected to OTand IT identified networks only.

6.2.3 Administration workstationNetwork activities of administration workstations of OT sys-tems are dedicated to administration of infrastructure equip-ment.

Administration workstation are not used for permanentmonitoring.

6.2.4 DeliveryDelivery: ICS network policy is to be submitted by the Sup-plier in the equipment security mechanism.

7 Preservation

7.1 Context

7.1.1 Logs strategyAt both operating system and application level, equipmentuse an events and logs policy for extensions as defined in[1.3.3].

For Cat. A, Cat B and Cat. C equipment, the following listgives a scope of events to identify:

• authentication (i.e. login failure, success, user log off)

• accounts management (i.e. user add, delete)

• audit records (i.e. use of privileges)

• administrator actions (i.e. sudo)

• services activities (i.e. started, stopped)

• object access denied

• significant operational events (i.e. engine stopped)

• system activity (i.e. storage events)

• traffic events (i.e. blocked, allowed)

• usage information (i.e. PLC relay activation)

• USB usage.

Cat. B equipment, especially security and network appli-ances, feed an uninterrupted logging system of eventsrelated to their own cyber security and to the function forwhich they are designed.


NR 659, Ch 3, Sec 2

Logs and events policy is built in respect of legal regulationsand in respect of privacy.

Delivery: Equipment events and logs management policy isto be submitted for approval by the Supplier in the equip-ment security mechanism.

7.1.2 Architecture

At both operating system level and application level, equip-ment record logs locally.

SYSLOG service is linked to vessel's Events and LogsRecorder (ELR), when available.

Delivery: Equipment events and logs architecture is to besubmitted for approval by the Supplier in the equipmentsecurity mechanism.

8 Maintenance

8.1 Context

8.1.1 Delivery

Two documents are to be submitted by the Suppliers: anadministration and an operator guide.

An Equipment Administration Guide is to be submitted. Thisguide is dedicated to the equipment, or system when inte-grated, and explains administration of the equipment in itsrelevant context. Administration guide discuss about opera-tions with the highest level of privilege like system restora-tion, forensics investigation, software installation.

An Equipment Operator Guide is to be submitted. Thisguide is dedicated to the ship and explain operationalactions for the equipment with the relevant context. Opera-tor guide discuss about operations without the highest levelof privilege: users creation, system backup.

Beyond hereinafter requirements, each guide containsadministration and maintenance procedures relevant to theequipment

Delivery: The Equipment Administration Guide and theEquipment Operator Guide are to be submitted to the Society.

8.2 Administration guide

8.2.1 Administration roles

Administration guide is to detail equipment administrationroles and responsibilities for operation with high level ofprivilege like system restoration, forensics investigation,software installation, etc.

8.2.2 Administration procedures

Supplier is to deliver procedures related to the administra-tion of the equipment.

8.2.3 Installation procedures

Level 2 and Level 3 equipment are to supply proceduresand tools to quickly reinstall system by using pre-installedcomponents (disk images) and installation scripts.

Level 3 equipment are to supply procedure and tools to ver-ify equipment compliance after reinstallation.

8.2.4 Compliance state retrievalLevel 3 equipment are to supply procedure and tools toreinstall equipment at configuration level up to last securedand validated equipment version number.

8.2.5 CSR usageWhen used, Compliance and Software Registry (CSR) is tobe maintained with software updates. The procedure is tobe explained.

Supplier's process and rules update procedure are to besubmitted in the administration guide. The procedure abouthow-to get updates is to be submitted.

8.2.6 Vulnerabilities managementVulnerabilities management take CVE into account and pro-pose a way to properly and securely update systems.

This management is to be explained with manual and auto-mated procedures.

Supplier is to propose a way to inform Shipowner aboutpatch to apply as soon as its equipment, or system, containa published CVE.

Identified vulnerabilities are to be patched when possible(availability of patch) by following the Supplier's prescrip-tions.

8.2.7 Advanced persistent threats mitigation measures

Level 3 equipment have a regular manual control procedurein order to help to reduce the impact of undetectedadvanced persistent threats, performance degradation andremaining vulnerabilities impact.

8.2.8 Hardened operating systemsLevel 3 equipment Cat. A operating system are to be hard-ened with dedicated security rules. Supplier gives proce-dure of control in regard to applied rules. Tests in order toverify hardening are to be described through a step-by-stepprocedure. Procedure may be scripted.

8.2.9 Hardened equipmentSupplier is to provide tests in order to verify hardening by astep-by-step procedure for Level 3 equipment Cat. B andCat. C.

8.2.10 Technical competenciesSupplier is to identify and to provide the necessary techni-cal competencies of the service technicians.

8.3 Operator guide

8.3.1 Maintenance rolesMaintenance guide is to detail equipment maintenanceroles and responsibilities for each operation: backup opera-tions, account create, etc.

8.3.2 Maintenance proceduresEach equipment of vessel's inventory is to propose a dedi-cated and detailed Maintenance Plan.

For maintenance convenience, Supplier contact is to besubmitted with useful internet links to website containingtechnical documentation, data, software maintenance, sup-


NR 659, Ch 3, Sec 2

port and updates. For specific systems, technical contact,email and/or phone number are added.

Supplier is to deliver procedures related to the maintenanceof the equipment.

8.3.3 Antivirus maintenance

Equipment antivirus solution is to be kept updated inaccordance with cyber security officer recommendation byusing a secured update mechanism ensuring integrity ofdata.

For maintenance operations, antivirus updates are to beavailable from operator level.

Access to antivirus may be controlled, incorporating theprinciple of least functionality. A procedure is to be submit-ted with equipment for cyber security responsible attention.It delivers step by step procedure to verify proper state ofantivirus in terms of users' access and privileges.

8.3.4 Integrity check

For Level 2 and Level 3 equipment, procedures for manualverification of the integrity of the equipment are to be sub-mitted. Manual action are to be submitted as script, com-mand lines or software interface checking.

Those procedures may be used, for example, after softwareupdates or to lift doubts of equipment compromising:

• Integrity check is to determine the scope and risks asso-ciated to a software maintenance and identify the objec-tives of testing, the method of testing, the expected timeand resources required for the testing process. It shouldprovide clear information on how the tests are carriedout and how to verify the success or failure of each tests.

• Test cases are to be selected on the basis of require-ments, design specifications, risk analysis and interfacesof the equipment subject to software maintenance.

• The results of the executed tests are to be recorded,including the versions of the software under tests.

8.3.5 Isolation

During Level 3 equipment maintenance operation, crewmembers have a way to be informed not to use the systemor equipment. The way they can be informed may be:

• Organizational: procedures are in place to turn off logi-cal or physical access to the system or equipment.

• Technical: an analog relay is used to unplug the systemor equipment from any user action.

8.3.6 Backup procedure

A backup procedure is to be explained for Level 2 and Level3 equipment in order to save sensitive files, systems andassets. For sensitive information, this procedure is restrictedin terms of account rights for operator: operator shall have abackup profile meaning capability to backup files withoutreading, modifying or written backup files.

8.3.7 Antivirus usage

Maintenance is to use an antivirus solution or the vessel'sIDG in order to verify contents and archive results of theoperation in the vessel maintenance registry.

8.3.8 Urgent update

Procedures and technical functions are to ensure urgentupdate of Level 2 and Level 3 equipment without loose ofoperation in progress. If required by operations, equipmentcould have to be in the same operational state after reboot(without loose of context). For Cat. C equipment, automateoutputs may be in a saved state during software update.

8.3.9 Data providers

When used, usage of data imported from data providers isto be explained. Imported data is to carry out data produc-tion and distribution operations in accordance with a qual-ity system, covering:

• data quality (production, delivery, testing and integration)

• standardization of data import

• means to ensure the continuous availability of datamaintenances

• prevention/detection/protection from unauthorized mod-ification

• prevention of the distribution of malware.

If used, data providers procedures related to the mainte-nance of the equipment are to be delivered.

9 Monitoring

9.1 Architecture

9.1.1 Monitoring solution

Monitoring solution is a security solution used by the Ship-owner, aboard or, and, ashore, in order to supervise securityevents. Monitoring solution rely on two monitoring func-tions installed in the equipment by the Supplier:

• Events Manager is used to log and record events.

• Investigation Manager is used by the monitoring solutionto remotely retrieve logical elements of the equipment.

9.1.2 Events manager

Events Manager term is used hereinafter according to one ofthose definitions:

• equipment send events to ELR when available.

• equipment record events in a local registry

Events Manager is mandatory for Level 2 and Level 3 equip-ment.

9.1.3 Investigation manager

Investigation Manager term is used hereinafter according toone of those definitions:

• equipment use the CSR client application which ensurethe functionalities herein described

• equipment use its own application which ensure thefunctionalities herein described

Investigation Manager is mandatory for Level 3 equipment.


NR 659, Ch 3, Sec 2

9.2 Events manager

9.2.1 Events descriptionLevel 2 and Level 3 equipment are to supply a cleardescription of security events with their code number, diag-nostic description and resolution methodology.

Level 3 equipment extensions (Operating systems, Direc-tory Services, Web services, Databases, Desktop Applica-tion, Hypervisors, Antivirus) are to be submitted with asecurity events referential including code number, diagnos-tic description and resolution methodology.

Scope of alerts is extended to any relevant suspicious net-work activity (e.g. port scan) well-known and handled byactive software of the network facility.

Delivery: Security Events are to be submitted in the Equip-ment Administration Guide.

9.2.2 Security thresholdsScope of events and number of authorized login failuresbefore alert generation are to be defined. Alert means localvisual local alert, potential account freezing, log messageand access blocking (local growing timeout or remote forthe incriminated source).Delivery: Security events are to be submitted in the Equip-ment Administration Guide.

9.2.3 Events recordEvents listed in the scope defined in [9.2.1], are to berecorded to the event Manager defined in [9.1.2].

Delivery: The method used to manage and record events,when available and feasible, is to be submitted for approvalin the Equipment Security Mechanisms.

Note 1: To get { CYBER SECURE notation, events Manager is to beconnected to ELR and ELR is to be recognized by the Society.

9.3 Investigation manager

9.3.1 List of supplied elementsUpon security monitoring request, equipment is to supply:• Software components with a list of:

- firmware version and checksum- component installation timestamps- file repository- version information for operating system or installed

software handled by the operating system components.

• Configuration components with a list of:

- configuration files

- environment variables

- scripts

- registry

- hives for operating system component or installedsoftware handled by the operating system.

• Files components with a list of:

- mounted volumes

- directories

- files names and paths

- files access controls list

- files sizes

- files time stamps

- files checksums.

• Configuration components with a list of:

- network mounted volumes

- opened ports

- listening applications

- outgoing connections.

• Serial interfaces components with a list of:

- Universal serial bus activity history.

• Memory components with a list of:

- running processes

- memory access controls

- process sizes

- process time stamps

- process activity

- process hashes.

- memory dump.

Delivery: The method used to supply, when available andfeasible, elements and list of elements is to be submitted forapproval in the Equipment Security Mechanisms.

Note 1: To get { CYBER SECURE, investigation manager is con-nected to CSR and CSR is to be recognized by the Society.


NR 659, Ch 3, Sec 3

SECTION 3 VESSEL DESIGN

1 Architecture

1.1 Principles

1.1.1 Needs

Networks interconnections represent threats as they aresources of vulnerabilities. Risk must be considered beforeconnecting networks and equipment. IT and OT systems aretraditionally not connected but situation is changing as ICS,for example, are managed remotely.

For those reasons, a network levels plan details physical andlogical segregation of information. Ethernet or fibre dedi-cated cables are identified. Virtual Private Networks (VPN)are explained. Cat. A, B, C equipment are relevant to thisrule. IT and OT connection are to be detailed and securedregarding the rules.

For any system, function which could be ensured in anotherLevel are moved from an equipment to another one.

1.1.2 Software limitation

The needs of software and tools are to be defined and justi-fied. The installation of software and tools is to be explainedand strictly limited to the needs hereinbefore defined.

Unneeded IT tools installed in OT are to be moved to ITnetwork.

Unneeded Level 1 and Level 2 tools installed in a Level 3Equipment are to be moved to Level 2 Equipment.

Unneeded Level 1 tools installed in Level 2 Equipment areto be moved to Level 1 Equipment.

1.1.3 Network access

Access to Level 3 network and equipment is not acceptedout of unsecured area. Access control is mandatory. Thispoint contributes to reliability of the vessel.

1.1.4 Networks segregation

As much as possible, each functional network is to be phys-ically separated with dedicated network equipment. Thispoint contributes to reliability of the vessel. If it is not possi-ble, and demonstrated as being, VLAN are to be consideredas defined in those rules.

Each segment is to have its own range of Internet Protocol(IP) address.

Standard interfaces should be used for data exchangebetween different networks. Each network should bedesigned in compliance with a recognized standard such asIEC Standards - IEC 61158 or IEC 61784, etc.

Segmentation should be such as to prevent loss of essentialsystems upon a single failure for Category III systems, whichrequired redundancy by classification Society.

1.1.5 ICS NetworksFor Level 2 and Level 3 Systems, ICS are to be separatedinto consistent technical and/or functional areas. Thoseareas are segregated.

Distributed ICS, or interconnected ICS, (wide supervision ofindustrial controllers for example) are to use approvedIPSEC VPN implementation. Distributed ICS are identifiableby the fact that they are not physically in the same area.

1.1.6 Functional cohabitationFor IP and non-IP traffic of two distinctive functional areaswhich are physically connected (which is discouraged), alogical partition (e.g. VLAN) is to be used for Level 3 equip-ment.

For example, a VLAN could be considered for each of thefollowing functional areas: servers, operators, administra-tion, remote connection and industrial controllers.Note 1: PLC controllers with dual Ethernet controllers are not con-sidered as a security component and segregation shall not betrusted.

1.1.7 Network connectionsConnections from Level 2 to Level 1 (and from Level 3 toLevel 2) networks are to be avoided as much as possible.This apply as for IT as OT networks.

When needed, connections should be achieved through aunidirectional link only, if feasible. The unidirectional linkuse anti-subversion mechanism as security wrapper ordiode. It does not use direct connection (ssh, ftp) even ifthey are secured or enciphered.

For connections from Level 3 equipment to Level 2 equip-ment:

• connections shall be established by using a gateway(see DMZ) in charge of receiving orders from the out-side and transferring them to the inside part

• operating systems of gateways are to be hardened as anyequipment ( Sec 2)

• inside the gateway, two separated operating systemswith two separated network interface ensure the gate-way process through a shared area limited to dataexchange (pipes, semaphores, file system...)

• usage of a firewall is required.

1.2 Security mechanisms

1.2.1 ICS demilitarized zoneOT systems are not to be directly connected to the DMZ.An internal DMZ, named “OT DMZ”, is dedicated to com-munication from “OT Network” to the ground. The Rulesdeveloped in [1.2], including related documents to be sub-mitted, fully apply to the “OT DMZ”. (See Fig 1).

OT DMZ are mandatory for Level 3.


NR 659, Ch 3, Sec 3

Figure 1 : OT DMZ principle

Figure 2 : Example of internal connection to DMZ

Delivery: OT connections to vessel network and/or groundsystems are to be submitted for approval in the vessel cyberdesign in a dedicated part, including information to be sub-mitted specified in [1.2].

1.2.2 DMZ interconnecxions

To defeat risk of hacked DMZ, the DMZ has no way to con-nect to the vessel Network. However, notice that, the “OTDMZ” needs to connect to “DMZ” through the vessel Net-work (see Fig 2). In this case, connections are authorizedthrough a dedicated VLAN.

TCP (Transmission Control Protocol) connections and UDP(User Datagram Protocol) datagrams are allowed.

Delivery: DMZ interconnections are to be detailed, justifiedand submitted for approval trough a full rationale and a net-work implementation map in the vessel cyber design.

1.2.3 DMZ ingoing packets

When necessary, and for UDP (User Datagram Protocol)datagrams only, traffic is authorized in the reverse way. Asthe protocol is unreliable, it must not be used for safety pur-pose. Error-correction can be achieved by considering UDPencapsulation of SCTP (Stream Control Transmission Proto-col - RFC 6951) (see Fig 3).

Delivery: DMZ ingoing packets are to be detailed, justifiedand submitted for approval trough a full rationale and a net-work implementation map in the vessel cyber design.

Figure 3 : Example of UDP datagrams from DMZ

Figure 4 : Example of external traffic

1.2.4 External connections

External connections include (see Fig 4):

• connections going from the “Ground” to the “DMZ”

• connections going from the “DMZ” to the “Ground”.

TCP (Transmission Control Protocol) connections areallowed.

Perimeter firewall between onboard network and externalnetwork is to be applied.

Delivery: External connections are to be detailed, justifiedand submitted for approval trough a full rationale and a net-work implementation map in the vessel cyber design.

1.2.5 Diode usage

Level 3 OT equipment at risk 3 (see Ch 1, Sec 2, [3.7.5])communicating to ground systems, is to use a “one-way”diode network equipment as a mitigation measure. Thediode installation decrease the connectivity level to index 1(CY1). (See Fig 5).

Diodes are security network equipment designed with ananalogic rupture to enable one-way traffic and disable anypacket feedback or network connection in the other way.

Delivery: OT diode information workflow are to bedetailed, justified and submitted for approval in the vesselcyber design.

Note 1: To get { CYBER SECURE, the diode is to be recognized bythe Society.

OT EQUIPMENT

OT DMZ

DMZ

GROUND

VESSEL NETWORK

OT NETWORK

OT EQUIPMENT

OT DMZ

DMZ

GROUND

EQUIPMENTVESSEL NETWORK

OT NETWORK

VLA

N

OT EQUIPMENT

OT DMZ

DMZ

GROUND

EQUIPMENTVESSEL NETWORK

OT NETWORK

OT EQUIPMENT

OT DMZ

DMZ

GROUND

VESSEL NETWORK

OT NETWORK


NR 659, Ch 3, Sec 3

Figure 5 : Diode usage example

1.2.6 Outgoing connectionsFrom Level 2 Equipment, for outgoing connections, connec-tions from the inside “DMZ” to the outside “Ground” areaccepted with the usage of a reverse proxy or equivalenttechnology in term of flow disruption (see Fig 6).

Delivery: Each outgoing connection, with or without flowdisruption, is to be justified though a detailed descriptionand submitted for approval in the vessel cyber design.

Figure 6 : Reverse proxy example

1.2.7 ManagementManagement, administration, supervision or any actionrequiring a high level of privilege on Level 2 Equipment,Level 3 Equipment or DMZ is to be done from a dedicatednetwork using a NG Firewall.

Administration functions, roles and users with full or highprivilege on any Cat. ABC system of Level 123, are to beisolated from the network by using either a dedicated work-station or a dedicated interface (network card).

The solution is to be connected to a dedicated network whois physically dedicated, or logically partitioned (VLAN).Internet or public access from those points are strictly pro-hibited (see Fig 7).

Delivery: Management security mechanisms of DMZ are tobe detailed and submitted for approval in the vessel cyberdesign.

1.2.8 Call-back mechanismRemote Access shall be confident, identified and authenti-cated by using relevant protocol authentication mechanism(e.g. IPsec) with a encryption key management. If remoteaccess is not trusted, a call-back mechanism is to be used(modem call from ship to shore).

Delivery: When used call-back mechanisms is to be submit-ted in the vessel cyber design.

1.3 Design

1.3.1 Network logical cartography

By respecting [1.1] architecture principles and [1.2] securitymechanisms, the network cartography is to be detailed,explained and justified with four layers:

• Layer 1 presents the network logical cartography: ascheme presents architecture for IT and OT. Onboardflows and onshore communications are explained.

• Layer 2 presents the network address plan which detailseach IT and OT network address for each equipment.

• Layer 3 presents the network physical cartography: ascheme presents IT and OT network implementationonboard. Switches, fibre and copper cables are presented.

• Layer 4 presents the network flow matrix with every ITand OT flows with their source, destination, protocol,encryption and port.

Delivery: The network cartography layers are to be submit-ted for approval in the vessel cyber design.

1.3.2 System integration

Rules from Ch 2, Sec 3 are to be applied: relevant delivera-bles are to be submitted.

1.3.3 Security solution integration

Integration of security solutions are described in Sec 4,[1.1.6] is to be submitted for approval.

1.3.4 Ashore installations

As ashore premises could be a strong vector of attack, theyare considered, in term of security, as an untrusted area.

For connections from ashore to onboard, ashore networkshall be considered as a fully separated network with aneed of filtering and wrapping.

A dedicated study is to be submitted for this particular pieceof connection. Security strategy is explained. Securityevents management is to be detailed.

Delivery: Ashore cartography is to be submitted forapproval in the vessel cyber design.

Figure 7 : DMZ management example

OT NETWORKLEVEL 3

OT DMZ

DIODE

VESSELEQUIPMENT

DMZ

VESSEL NETWORK

DMZ NETWORK

RESERVE

OT EQUIPMENT

OT DMZ

IT NETWORK

DMZ

Managem

ent

GROUND


NR 659, Ch 3, Sec 3

2 Network

2.1

2.1.1 Traffic encryptionAt data level, for each protocol used for external connec-tion, key authentication is mandatory instead of passwordauthentication. Key management is to be submitted.

Delivery: The traffic encryption is to be submitted forapproval in the vessel cyber design.

Note 1: To get { CYBER SECURE notation, traffic encryption is touse solutions recognized by the Society.

2.1.2 FirewallFor remote access security, two firewalls from two differentmanufacturers are to be used on the vessel.

Delivery: The firewalls brand and model are to be submittedfor approval in the vessel cyber design.

Note 1: To get { CYBER SECURE, firewall is to be recognized bythe Society.

2.1.3 Non-IP traffic filteringFor Level 3 equipment, for non-IP traffic between two dis-tinctive areas, firewall shall filter packets by using sourceand address identification. For ethernet non-IP traffic, MACaddresses will be used in respect of the network addressplan.

Delivery: Non-IP traffic implementation is to be submittedfor approval in the vessel cyber design.

2.1.4 CablingNetwork integrity of Level 3 systems is reinforced by usingclosed cable passageway in unsafe areas.

All network cables for category I, II, III systems (as definedby IACS UR E 22) are to be flame retardant and are to bedesigned, manufactured and tested as per relevant nationalor international standards. Cables are to be fire resistanttype where required by classification Society.

The minimum bending radius specified for the cable is tonot exceed, especially for optical cables where it may leadto signal loss.

Delivery: Protected cable passageways implementation andcable types are to be submitted for approval in the vesselcyber design.

2.1.5 OT ConnectivityFor Level 2 and Level 3 systems, OT network are not to beaccessible from any part of the vessel, except the one it isrelevant. No network plug are to be installed out of this lim-ited scope. Network cables are not to be directly accessiblefrom the outside.Delivery: OT connectivity implementation is to be submit-ted in the vessel cyber design.

2.1.6 Network identificationFor Level 3 systems, network are to be visually identifiablefrom any point by using, for example, coloured cables. Net-work plugs are to be clearly and physically identified.

Delivery: Network identification strategy is to be submittedin the vessel cyber design.

2.1.7 IPsec usageWhen used over public networks, IPsec encryption complywith the following implementation:

• Encapsulation Security Payload (ESP) is used in con-formance with RFC 4303 (protocol 50)

• Integrity mechanism are activated

• IPsec is used as a full tunnel mode - transport mode isbanned

• Internet Key Exchange (IKE) comply with Version 2 RFC5996

• Pre-Shared keys (PSK) is deactivated. PKI is (Public KeyInfrastructure) is used

• Infrastructure firewalls only accept IKE, ESP and eventu-ally ICMP

• When Network Address Translation (NAT) is used overinfrastructure, NAT-Traversal (NAT-T) is activated

• Keys are changed regularly (either by using Perfect For-ward Secrecy PFS, either by requesting change everyhour)

• When used MD5 hash, DES encryption and RSA keysare 2048 bits length minimum

• When used AES, SHA-2 and ECDSA keys are 256 bitslength minimum

• Hereinbefore rules are implemented in the “SecurityPolicy Database” of IPsec configuration

• Diffie-Hellman keys algorithms groups 1 and 2 arebanned. Groups 14, 15, 19 or 29 are preferred.

Delivery: IPsec strategy is to be submitted for approval inthe vessel cyber design.

2.1.8 Switches security policyFor Level 2 and Level 3 equipment, Spanning Tree Protocolis to be applied to network switches to prevent networkstorms and network becoming paralyzed.

Safety functions implemented in the integrated network arebe to implemented in dedicated and autonomous hardwareunits (switches, etc.)

Delivery: Switches security policy is to be submitted in thevessel cyber design.

2.2 New-generation firewall

2.2.1 UsageFor Level 2 and Level 3 systems, New Generation Firewall(NGFW) are systematically to be preferred to old-generationFirewalls, see Fig 8.

The following NGFW security functions are turned on:

• firewalling

• application firewall

• identity awareness

• state-full packet inspection

• intrusion prevention system.

Delivery: The NGFW brand and model are to be submittedfor approval in the vessel cyber design.

Note 1: To get { CYBER SECURE notation, is to be recognized bythe Society.


NR 659, Ch 3, Sec 3

Figure 8 : New generation firewall

2.2.2 Wireless networks

Access point of the wireless network is installed behind aNew Generation Firewall (NGFW), see Fig 9.

The application firewall is used to filter IP Layer 2 through 7.

The State-full Packet Inspection (SPI) is used to detect suspi-cious behaviours.

The Intrusion Prevention System (IPS) is tuned and config-ured to detect and drop suspected packets.

Delivery: Firewall rules, application firewall policy, state-full packet inspection mode and intrusion prevention sys-tem settings are to be detailed, justified and submitted forapproval in the vessel cyber design.

Figure 9 : Wi-Fi and firewall example

2.2.3 Application firewall

In NGFW, application firewall is to be configured to filter IPLayer 2 through 7 packets.

When needed, the application firewall are also used tooffload encryption from servers and manage authentication.

Delivery: Application firewall strategy is to be submitted inthe vessel cyber design.

2.2.4 Identity management

For communication from/to Level 3 systems, applicationfirewalls function from NGFW are used to verify identity ofremote connections and to apply dedicated policy regard-ing authorized services, routing tables and TCP ports usage.

For example: Remote monitoring systems requesting highlyprivileges may be authorized through the firewall butblocked by the application firewall, see Fig 10.

Delivery: Identity filtering and authentication mechanismsare to be submitted in the vessel cyber design.

2.2.5 State-full packet inspection

NGFW contains State-full Packet Inspection (SPI) technol-ogy.

For Level 3 Systems, SPI is to be used to check the consist-ency of the transaction regarding the historic data.

For example: Packets not assigned to an existing connectionare dropped, thereby limiting the risk of hacking (intelli-gence and discover operations).

NGFW use dynamic tables to store those data and define astate of the connection.

Delivery: SPI implementation is to be submitted in the ves-sel cyber design.

2.3 Intrusion and prevention system

2.3.1 Scope of application

IPS raise up odds of detection and blocking maliciousbehaviour on networks.

For Level 2 and Level 3 systems, IPS are to be used to detectattacks based on a number of different techniques like theuse of threat signatures, known exploit attacks, anomalousactivity and traffic behaviour analysis: if detected, suspectedpackets are dropped.

As they are actives probes, they are helpful in order to blockattacks or parts of them. IPS are to be installed in accord-ance to network architecture and network levels of critical-ity. IPS systems scope of installation includes virtualnetworks handled by hypervisors.

Instead of an active behaviour, probes may be configured ina passive mode called IDS. In that case, packets are notblocked anymore.

As they could block operational packets, IPS are to bebanned for critical and real-time environment. IDS are to beused if feasible.

IPS usage is mandatory for connected Level 3 equipment.

IPS may be integrated in a NGFW or installed ashore incase of ashore connection.

2.3.2 Delivery

Delivery: IPS and IDS strategy, as detailed in [2.3], is to besubmitted for approval in the vessel cyber design.

Note 1: To get { CYBER SECURE, IPS is to be recognized by theSociety.

Figure 10 : Example of identity verification

VESSELEQUIPMENT

VESSEL NETWORK

DMZDMZ NETWORK

NGFW

NGFW

NGFW

ACCESS POINT WIRELESSEQUIPMENT

AUTHENTICATIONSERVER

WIRED NETWORK

VESSEL NETWORK

APPLICATION FW

DMZMonitor Admin

Operator Admin


NR 659, Ch 3, Sec 3

2.3.3 Wireless IPSFor Level 3 systems using wireless networks, the WirelessIntrusion Prevention System (WIPS) is mandatory. The WIPSdetects rogue access points, unauthorized accesses, MACaddress spoofing, denial of service attacks or any man in themiddle scenarios.

2.3.4 IPS connection to ELRSecurity events issued by IPS (BLOCKED and ALERTS) are tobe sent to ELR when available.

2.3.5 Network activity loggingIPS are to be used to record network activity: origin, desti-nation, timestamps.

2.3.6 NGFW and IPSNGFW contain IPS technology which may be used to coverthe present requirement.

2.3.7 Security events descriptionIPS are to be submitted with a security events referentialincluding code number, diagnostic description and resolu-tion methodology. Scope includes IPS themselves and anysecurity relative events detected by IPS about network behav-iour. Unknown MAC or IP address detected on supervisednetwork shall trigger a security event. Missing MAC or IPaddress on supervised network shall trigger a security event.

2.3.8 Security ThresholdsFor IPS, number of authorized login failures before alertgeneration is to be defined. Alert means ELR message andremote access blocking for the incriminated source.

Vessel integrator delivers IPS with a dedicated tuning aboutrules management. This tuning takes into account networkcartography, traffic and compliance as physical as logical.

IPS messages are to be cleaned from irrelevant noise.

Thresholds policy is to be explained in order to be operated.

3 Systems

3.1 Cabinet protection

3.1.1 Level 3 equipment are to be installed in locked cabi-nets. The protective cases are to be designed for the ambi-ent environment and ease of operation and maintenance ofthe device.

For Level 3 at risk 3 equipment (Ch 1, Sec 2 [3.7.5]), alarmdoors are to be used. Seals are also to be used in order tohelp visual inspections during patrols.

Delivery: Cabinet protection is to be submitted in the vesselcyber design.

3.1.2 Video protection

For critical Level 3 systems installed in protected area, a 24/7video protection system is to record access to the system.

Delivery: Video protection is to be submitted in the vesselcyber design.

3.1.3 Alarm function

When possible, for integrated Level 3 Systems, networksdevice alarm functions are to be configured to detect abnor-mal state changes and notify the user:

• When a link is disconnected or the power is turned offfor a network device or network terminal

• When a link not belonging to the network is connectedor the power is turned on for a network device or net-work terminal

• In case of loss of a network device.

Delivery: When implemented, alarm functions are to besubmitted in the vessel cyber design.


NR 659, Ch 3, Sec 4

SECTION 4 SECURITY SOLUTIONS

1 General

1.1 Application

1.1.1 Scope

Security solution requirements apply to Suppliers of securityequipment, security systems and security services.

1.1.2 Objective

The objective of security solutions is to cover the followingsecurity functions, as required in Sec 2, [1.3.4]:

• Verification:

used to check and validate the compliance of the equip-ment

• Evaluation:

used to scan software, scripts and executable part ofcode for any malicious content

• Preservation:

used to trace and record logs and events.

1.1.3 Definition

The three security solutions are installed onboard and, or,ashore in order to achieve security functions objectives:

• Verification:

covered by the CSR which is an anti-tamper technologyinstalled to prevent changes in operation and/or todetect attacks before/during their occurrence. Definedin Article [2].

• Evaluation:

covered by the IDG (Inspection and DecontaminationGate) which is an anti-malware technology used todetect malicious signatures, suspect behaviours andindicators of compromise during attacks. Defined inArticle [3].

• Preservation:

covered by the ELR (Events and Logs Recorder) which isa forensic technology used to determine paths of attacksand responsibilities after attacks and before during theiroccurrence. Defined in [4].

1.1.4 Grouped hunting

The vessel's cyber strategy shall privilege cyber joined oper-ations for the vessel and the fleet. To achieve this objective,integration of components is decided at design phase withthe following interactions as requirements:

• Compliance and Software Registry sends suspected filesto IDG in order to scan their contents. In return, IDGdelivers an applicable score of risk.

• Compliance and Software Registry sends logs of actions,requests and results to the ELR.

1.1.5 Grouped defence

The three security solutions have to consider their self-pro-tection and interact between each of them in order to com-plete the vessel's cyber strategy:

• IDG and ELR are checked by the CSR as any equipmentand, when compromised, will be detected by the CSRas it.

• IDG and CSR events are traced by the ELR as any equip-ment and, when compromised, will be under investiga-tion by using ELR history.

• CSR and ELR are maintained through the IDG as anyequipment and, when in maintenance, are under evalu-ation of the IDG.

1.1.6 Integrated architecture

The vessel integrator is in charge to develop a strategy ofintegration for the security solutions (see Fig 1) by usinggrouped hunting [1.1.4] and grouped defence [1.1.5] con-cepts.

The strategy consider the scope of elements identified dur-ing the Cyber Risk Analysis for:

• Level 3 equipment

• Network activities of Level 3 systems and remote accessnetworks

• Computers and removable media coming from outsideof the vessel and used for maintenance operations.

Delivery: Integrated architecture of security solutions is tobe submitted for approval by the vessel integrator in the ves-sel cyber design.

Figure 1 : Integration of security solutions

Collect

Cybersupervision

management

Level 3equipment

Maintenancecomputers

Networksactivity

Monitor

Collect Monitor

Collect Monitor

CSR central

ELR

IDG


NR 659, Ch 3, Sec 4

2 Compliance and Software Registry (CSR)

2.1 Mechanisms

2.1.1 DefinitionCompliance verifies that an equipment is in proper statefrom a numeric point of view.

The proper state defines the prerequisite, condition and cri-terions in which hardware, software, variables and datacannot jeopardize functions of the system either for safetyor operational reasons.

Thus, the proper state also defines the prerequisite, conditionand criterions in which hardware, software, variables anddata are known to be in good condition to successfullyaccomplish operational mission in the respect of safety regu-lations.

2.1.2 ObjectivesThe objective of the CSR is to maintain the good shape andthe proper state of the ship digital components embeddedin systems.

The CSR is a central unit, collecting information from clientsand reacting in case of loss of compliance of an equipment.

The CSR is the guardian of the initial, authorized, proper state.

Any alteration on any digital component is sent to the CSRin order to compare, record and raise alerts.

A reliable CSR covers the following cyber challenges:

• FIM (File Integrity Monitoring)

• maintenance operations logging

• configuration compliance monitoring

• process management

• network flows activity

The CSR respect integrated architecture of security solutionsdefined by the vessel integrator in [1.1.6].

2.1.3 WorkflowCSR equipment is used in order to collect equipment com-pliance information and manage the software registry of therelated equipment.

As the main goal of the CSR is to provide a simplified, smartand trusted information at the crew members, the complex-ity scale should go down as we approach end users.

CSR is, ideally, an appliance, onboard and or remote,which is used to receive information from systems duringtheir runtime.

• Ideally, in the first time, equipment suppliers are toharden systems and integrate traceability components asdetailed in Sec 2. Equipment information are sent inCSR database to formalise the related security frame-work: operating systems, services and applications arehardened, sensitive components are highlighted (e.g.system files or configuration values). Then, rules aresupplied. Those rules will be used as a referential byCSR to guarantee the proper upkeep of the classificationnotation: CSR will detect changeovers and raise alerts incase of system tampering.

• In a second time, shipyard is to integrate equipmentwith the CSR solution. It is also a good moment to builda “zero state” of the ship and backup every digital sup-port delivered. “Zero state” is sent to the CSR equipmentin order to handle system modifications. Digital settingis qualified.

• In a third time, covered equipment are in use at sea andthey feed CSR. Changes are to be continuously recordedand changes are computed.

• In the same time, maintenance teams and crew is torespect organisational security rules while using, modify-ing or updating any equipment. Any legitimate and justi-fiable technical modification, update, upgrade oralteration is duly signed by the operator and endorsed bythe CSR.

• In conclusion, before going at sea, and at sea, CSR is todetect any failure. Crew is to be informed in as soon asalert has been raised up. Any alert, even if cleared, is tobe recorded for further maintenance operation at shore.

The compliance flow is structured in order to answer towhat, when, who, where, how and why.

2.1.4 Active architectureImplementation may be under the form of a serviceinstalled on each equipment. Each equipment delivers acompatible flow of information ensuring CSR requirementshereinafter described. This flow comes from a tool, a pro-cess, respecting rules detailed in this Section (see Fig 2):• Cat. A operating systems include a security solution in

charge of feeding the compliance flow towards the CSR.The CSR client sends packets to CSR central by usingUDP transport protocol. A dedicated separate network(i.e. VLAN) is used to collect information.

• CSR management connects to the central by TCP on aseparate network (i.e. VLAN).

Collect and monitor services in the CSR central run in sepa-rated environments (i.e. separated system accounts, sepa-rated virtual machines.)

CSR client furnishes elements to identify integrity of the pro-tected scope. Elements used may be any element of integ-rity as defined for equipment design (see Sec 2, [4.3]).

The active architecture may also address request to Cat. Bequipment such as network switches and firewalls in orderto retrieve information regarding Rules in operation. In thatcase, the collectors use a dedicated separated network (i.e.VLAN) and a secured protocol (i.e. SSH) to connect and getinformation. (See Fig 3).

Figure 2 : Active architecture example

CollectCSRclient

Monitor

CSR centralCat. A Equipment Y

CSRclient

Cat. A Equipment X

Cat. A collectVLAN

SupervisionVLAN

CSRmanagement


NR 659, Ch 3, Sec 4

Figure 3 : Cat. B architecture example

2.1.5 Passive architecture

For Cat C equipment, and particularly for OT automation(i.e. PLCs, remote I/O, sensors, actuators, variable speeddrives, meters, circuit breakers, switches, physical servers),a passive architecture is recommended to retrieve informa-tion regarding the equipment.

The principle of passive discovery probes apply for both OTand IT networks and for Cat. A, cat. B and Cat. C equipment.

Active architecture is unfeasible on OT equipment becauseof their opacity, age or natural limitations. The use of aprobe connected to the network, through a non-intrusivenetwork tap mechanism, deep packet inspection or portspanning implementation, cover the issue (see Fig 4).

Collect and monitor services in the CSR central are to beexecuted in separated environments (i.e. separated systemaccounts, separated virtual machines).

CSR management connects to the central server by TCP ona separate network (i.e. VLAN).

Elements collected through passive architecture may be:

• Any element of integrity defined by the equipment itself(see Ch 3, Sec 2 [4.3]).

2.1.6 Submission

Delivery: Principles of information collection and process-ing, inventory of collected information and CSR architec-ture are to be submitted for approval in the CSR SecurityMechanisms guide.

Note 1: To get { CYBER SECURE notation, collected information,passive and active architecture are provided by a recognized third-party.

2.2 Functionalities

2.2.1 Supervision and management

As described in the workflow [2.1.3], CSR propose an exter-nal interface to supervise and manage assets, software andevery collected information.

Management is to be allowed to request database regardingassets and software for both current and past situations.

Supervision and management functions are proposedthrough a human interface (http, local).

Figure 4 : Passive architecture example

Procedures details, at a minimum:

• how to access software registry information. For exam-ple, procedure to get an inventory of assets; procedureto add a client to the CSR; procedure to export, deleteinformation.

• how to make advanced requests (i.e. like sql language,regular expression). For example, advanced requestsmay be used to get list of computers having such operat-ing system, or to get versions number of such applica-tion or number of assets connected on the network.

• how to manage (list, create, modify, delete) complianceprofiles. For example, procedure to modify a compli-ance profile; procedure to add or to modify files to bechecked; procedure to add or to modify or any other rel-evant information from [2.1.3].

• how to supervise compliance management. For exam-ple, procedure to add or modify rules regarding compli-ance checking; procedure to have rules to enable theearly prevention and/or detection and subsequenttimely reporting of unusual and/or abnormal activitiesthat may need to be addressed.

• how to detect maintenance operations on equipment.

• how to map and monitor network activity.

• how to make requests about alerts. For example, how tosearch for alerts regarding loss of compliance.

Note 1: Software Registry management procedures are to be sub-mitted in the CSR User Guide.

2.2.2 AlertingCSR automatically report any loss of compliance on anyequipment, depending of the configuration done throughthe supervision interface.

Alerts threshold are managed through the same interface.

The reported alerts are, at least, under the following for-mats: on the screen (web page over http), by an email alert,with a sound alert.

Alerts are sent to the vessel's ELR, when available.

Automated alerts are configured through a human interface(http, local).

2.2.3 EvaluatingCSR is linked to the vessel's IDG when available.

If a suspicious binary file or process has been found on anequipment, element is sent to the IDG to evaluate the risk.

Collect Monitor

CSR central

Cat. A collectVLAN

Cat. B collectVLAN

SupervisionVLAN

CSRmanagement

TCP/SSH Cat. B firewallCollect Monitor

CSR central

SupervisionVLAN

ICS networkCSR

management

TCPNETWORK TAP

Cat. CPLC X

Cat. CPLC Y

non-intrusivetraffic copy


NR 659, Ch 3, Sec 4

Suspicious binary files may be unknown patterns like filehash absent from white and black lists.

IDG may propose different typologies of analysis: multiplesources of signatures, threat intelligence, IOC, advancedheuristic probes and behaviour analysis engines.

Procedures is to detail, at a minimum:

• how to detect, how to classify and how to manage sus-picious components - with or without IDG.

• how to connect to the IDG, how to configure transfersover the network, how to retrieve results and how tomanage both automatic and manual processing.

2.2.4 CountermeasuresIn case of loss of compliance, client may be deactivated, dis-connected or banned from the system and/or the network.

Action could also be to block network activity (source, des-tination) from workstation and/or from a linked active net-work facility like IPS or FW.

Procedures details delivered tools on how to manage situa-tion in case of loss of compliance.

2.2.5 Vulnerability levelCSR automatically displays level of threat by using updatedCVE database confronted to equipment operating systemand application version information.

The User Guide contains automatic and manual proceduresto check the level of vulnerability of a single equipment, awhole System or the vessel.

2.2.6 Equipment qualificationCSR can be used to easily check equipment compliance inthe following situations:

• in case of after re-installation of the equipment: CSR isto be used to validate the compliance of the new instal-lation.

• in case of emergency or disaster on an equipment: CSRis to offer a way to validate baseline information fromnew equipment. CSR is to be used to validate that thenew system actually correspond to a safe and securepre-emergency state of equipment.

• in case of software update: CSR is to identify, track andreport successful or rejected changes. CSR is to be usedin the framework of quality with a process of reporting.

2.2.7 CSR integrityCSR detects changes of its own configuration (rules, config-uration, bios). A GUI or command line tool is provided toverify and validate integrity and reliability of:

• CSR central unit

• compliance controls (i.e. daemons, services) installedon Cat. A

• compliance solutions for Cat. BC equipment.

2.2.8 Vessel integrityA function in CSR helps to validate the full scope of equip-ment covered by the compliance process vessel integrity. AGUI proposes to check the compliance for the full scope ofequipment.

2.2.9 IOC on demandIOC templates are to be usable by CSR for on-demanddetection purpose with collected and stored information

2.2.10 Investigation managerElements of the equipment as defined in Sec 2 [9.3.1] maybe retrieved by the CSR Management.

2.2.11 DeliveryDelivery: Procedures regarding functionalities describedhereinbefore are to be submitted in the CSR User Guide.

2.3 Maintenance

2.3.1 SYSLOG managementSecurity events issued by CSR are to be compatible withSYSLOG format.

Security events are both internal events (CSR equipmentsecurity events) and client events (loss of compliance of amonitored equipment).

A procedure explains how to configure, to activate and toroute the SYSLOG events.

2.3.2 System restorationProcedures for diagnostic, reinstallation and restoration ofthe equipment, system or solution are to be written to theattention of operators.

2.3.3 Emergency re-installationShould an actual emergency or disaster occur on CSR, aprocedure is to exist to explain the recovery of the system,the reporting of test results and, according to the results,implementation of an action plan.

2.3.4 Storage managementAn alert is to be raised up to security operation centre, thecyber security officer and the cyber security responsible assoon as the alert threshold of CSR storage capacity isreached.

CSR storage capacity is to be upgradable.

Procedures are to explain, at a minimum, how to manageCSR storage capacities issues at sea, how to upgrade storagecapacity and how to manage alerts regarding storage man-agement.

2.3.5 Security events descriptionCSR is to be submitted with a security events referentialincluding code number, diagnostic description and resolu-tion methodology. Scope includes CSR itself, loss of compli-ance events and any security events.

2.3.6 DeliveryDelivery: Procedures regarding maintenance requirementsdescribed hereinbefore are to be submitted in the CSR UserGuide.


2.4.1 Equipment securityEquipment Security Rules defined in Sec 2 fully apply toCSR.


NR 659, Ch 3, Sec 4

2.4.2 System reliability

CSR is to be reliable. Reliability mechanisms, as hardwareas software, are explained.

2.4.3 Rules integrity

CSR is to embed its own integrity checksum regarding com-pliance information transportation. This checksum is usedby CSR to validate received information integrity.

2.4.4 Separated environments

Collect and monitor services in the CSR central server are tobe executed in separated environments (i.e. separated sys-tem accounts, separated virtual machines.)

2.4.5 System integrity

CSR is to own its integrity checksum. This checksum is to beused by CSR to validate its system integrity.

Audit process is accurate, complete, timely, authorized andauditable.

2.4.6 Client protection

CSR client components installed on Cat. A equipment are tobe installed at kernel-level in a protected process, runningwith independent execution condition.

CSR components installed on Cat. A equipment are to belaunched with operating system before local or network,user or system access to system.

CSR client process are to be activated at any time.

2.4.7 Client integrity

Should an actual emergency or disaster occur on CSR,equipment hosting CSR client process is to have a cacheand retry mechanisms.

2.4.8 Protected storage

CSR data storages are to be enciphered with a strongencryption mechanism.

2.4.9 Network protection

CSR network protocol is to use a strong encryption mecha-nism. Encryption keys are managed by the CSR solutionitself. Keys are never to be shared on any other equipment.

2.4.10 Removable media protection

CSR removable media are to be protected and their userestricted according to media restriction rules described inrelevant chapter. CSR removable media usage is to berestricted by configuration and use of operating system levelmechanisms, BIOS restriction, dedicated software or physi-cal locks.

2.4.11 Access protection

Number of authorized login failures to the facility beforealert generation is to be defined.

Alert means security event generation, message andlocal/remote access locking for the incriminated source.

3 Inspection and Decontamination Gate (IDG)

3.1 Mechanisms

3.1.1 Definition

The IDG is used to scan any equipment for malware andmalicious behaviours.

Scope of application is:

• equipment processes

• equipment virtual machines processes

• removable media

• maintenance laptops, computers.

3.1.2 Objectives

IDG is to be proposed onboard in order to inspect anyequipment before their use on onboard (i.e. maintenancelaptops, BYOD (Bring Your Own Device)):

• through a cabled or wireless network connection (lap-top, computers, mobile phones or tablets, diagnostictools)

• with a physical and local connection on equipment (usbkeys, removable media, hard drives).

• the IDG respects Integrated Architecture of SecuritySolutions defined by the vessel integrator [1.1.6].

3.1.3 Workflow

IDG can be developed under different formats of logicaland physical architecture. The objective is to propose a wayto cover a selection of workflows from the following list:

• Requests for analyse which come from the network:

Analyse may connect to a mounted point, a file direc-tory, one or more files, a process. Elements may be filessignatures (hashes) or files themselves:

- from compliance and registry: automatically (i.e. apimode)

- from an equipment: automatically (i.e. script mode)or on-demand (i.e. web interface).

• On the fly analyse of network packet:

A network tapping device gets flow of information onthe network and, by using deep packet analyse, extractsbinary contents and patterns for analyse (see Fig 5).

• Requests for analyse directly issued by physical inter-face of an equipment:

Elements may be USB keys, DVD, memory cards, USBdisk, Hard disk and solid state drives (see Fig 6).

3.1.4 Submission

Delivery: Workflows and IDG Architecture are to be sub-mitted for Approval in the IDG Security Mechanisms Guide.

Note 1: To get { CYBER SECURE, workflows and architecture areprovided by a recognized third-party.


NR 659, Ch 3, Sec 4

Figure 5 : IDG active and passive a IDG architecture

3.2 Functionalities

3.2.1 On demand local scansFor local media scanning (i.e. USB keys, see Fig 6), duringinspection, a scoring is to be displayed on a screen and/orprinted on a certificate in order to evaluate risk of infectioncontained on the media.

A decontamination process is to be proposed to the userthrough a GUI.

If accepted, IDG will try to clean/remove infected files.

At the end, a new inspection process is to be launched.Cleaned and removed files are to be saved in quarantinespace on IDG system.

3.2.2 On demand remote scansA secure web interface is to be proposed on the IDG toremotely send files or mounted volumes for Inspection.

After Inspection, a scoring to evaluate risk of infection con-tained files is to be displayed on the interface.

3.2.3 IDG capture pointsIDG capture points are facilities which deliver on the flyfiles inspection services. Files are to be analysed over thenetwork through a deep inspection packet process whichlooks for malware signatures and malicious behaviour.

3.2.4 Automated remote scansA secure network interface is to be proposed on the IDG toremotely send files for Inspection. Request may come froman IDG capture point or the CSR Central (see Fig 5).

After Inspection, a scoring to evaluate risk of infection con-tained files is sent to the emitter.

3.2.5 Extended IDGIDG is to propose an enhanced surface of detection:

Multiple probes (antivirus software) or sandboxes or behav-iour detection tools could be used. In cyber operations, filesand processes are typically sorted in black and white lists:

• the white ones are well-known and are trusted

Figure 6 : IDG on-demand scanning

• the black ones are well-known as being threats, mal-wares or virus

• a third category appears, grey signatures, which are notyet categorized.

The not yet categorized shall be inspected through differentways in order to score them and evaluate the situation.

Onboard, such analysis is possible by using online or offlinemultiple antivirus probe systems (i.e IRMA). Those probes,may contain multiple antivirus systems.

Endpoint or network sandbox may join the IDG to open upunknown files and check behaviour. Based on what they see,network sandboxes will block, allow or quarantine the files.

Analyse workflow may be linked.

3.2.6 ELR connectionSecurity events (success, alerts) issued by the IDG are to besent to ELR when available.

3.2.7 DeliveryDelivery: Procedures regarding functionalities describedhereinbefore are to be submitted in the IDG User Guide.

3.3 Maintenance

3.3.1 SYSLOG managementSecurity events issued by IDG are to be compatible withSYSLOG format.

Security events are both internal events (IDG equipmentsecurity events) and client events (i.e. virus detection).

A procedure is to explain how to configure, to activate andto route the SYSLOG events.

3.3.2 System restorationProcedures for diagnostic, reinstallation and restoration ofthe equipment, system or solution are to be written to theattention of operators.

3.3.3 IDG updatesProcedures for automated and manual updates of IDG areto be submitted.

3.3.4 Security eventsIDG is to be submitted with a security events referentialincluding code number, diagnostic description and resolu-tion methodology.

Scope includes IDG itself and any security relative eventsdetected by IDG about binaries, known risks, unknownrisks or suspicious system activity.

CollectCSR

central

AnalyseIDGLevel 3

equipment

Networkfiltering

IDGcapture point

1

3

2

4

5

Send newsignatures

Scan new files

Scan packetscontents

Connects toLevel 3 equipment

Any maintenancecomputer

Authorizepackets

MaintenanceVLAN on dedicated plug ordedicated network

EquipmentVLAN

AnalyseLevel 3equipment On-demand files

scanningthrough network

On-demand local mediasscanning

IDG


NR 659, Ch 3, Sec 4

3.3.5 DeliveryDelivery: Procedures regarding maintenance requirementsdescribed herein before are to be submitted in the IDG UserGuide.


3.4.1 Equipment securityEquipment Security Rules defined in Sec 2 fully apply toIDG.

3.4.2 Separated environmentsIDG connectors used to collect information, probes used foranalyse and supervision interface are to use strong sepa-rated and safe logical environments (i.e. separated virtualmachines).

3.4.3 System integrityIDG is to own its integrity checksum. This checksum is to beused by IDG to validate its system integrity.

Audit process is to be accurate, complete, timely, author-ized and auditable.

3.4.4 Network protectionIDG network protocol is to use a strong encryption mecha-nism. Encryption keys are to be managed by the IDG solu-tion itself. Keys are not shared by any equipment.

3.4.5 SubmissionDelivery: Procedures regarding security mechanismsdescribed hereinbefore are to be submitted for approval inthe IDG Security Mechanisms Guide.

4 Events and Logs Recording (ELR)

4.1 Mechanisms

4.1.1 DefinitionThe objective of the ELR is to record security events, activityevents and systems logs coming from Cat. A, Cat. B orCat. C equipment and systems. Logs are to be stored with ahigh level of security in order to have a legal proof in caseof investigation during any security event.

A reliable ELR is to cover most of the following cyber chal-lenges:

• access and security events

• system life logs

• maintenance operations logs

• compliance events.

Events are important sensitive events regarding known andexpected situations (i.e. authorized or refused login).

Logs are important traces about activities which may coversituations which are not traced by Events (i.e. identificationbypass through code injection).

4.1.2 WorkflowEvents and logs are generated and delivered by many equip-ment. The most popular protocol used for logs transmissionis SYSLOG, a standard for message logging. The objective

of ELR is not to reinvent the wheel but to propose a centralunit (i.e. using SYSLOG) to equipment onboard in order tocollect equipment events.

When stored, events and logs may be used:

• locally by the cyber security responsible

• remotely, from a remote operation centre by the cybersecurity officer

• remotely, when stored in a SIEM (Security Informationand Event Management)

• regularly, events and logs are copied in a safe placeashore.

Events and logs are then used in case of:

• suspicious of cyber event

• malicious attack discovery

• major advanced persistent threat.

The purpose of events and logs is:

• technical investigations

• responsibilities identification.

4.1.3 Architecture

The ELR architecture is simple in term of collect as it onlyrequire to receive information from any equipment. Theonly point is that events and logs shall be copied in a safefrom a remote location, in preference (see Fig 7).

Figure 7 : Example of ELR architecture

4.1.4 Submission

Delivery: Workflows and ELR architecture are to be submit-ted for Approval in the ELR Security Mechanisms Guide.

Note 1: To get { CYBER SECURE, workflow and architecture areprovided by a recognized third-party.

4.2 Functionalities

4.2.1 Supervision and management

The ELR is to propose an external interface to supervise andmanage every collected events.

Management is to be allowed to configure ELR behaviour.

Supervision and management functions are proposed througha human interface (http, local).

Collect Monitor

ELR central

SupervisionVLAN

EquipmentVLAN

CSRmanagement

TCPUDP

Operating system

ServicesApplication

Cat. Aequipment

Application

Application

Cat. B equipment

Cat. C PLC


NR 659, Ch 3, Sec 4

Procedures are to detail, at a minimum:

• how to access events

• how to make advanced requests (i.e. like sql language,regular expression). For example, advanced requestsmay be used to get list of such event).

• how to supervise events collections. For example, pro-cedure to add or modify rules regarding sources ofacquisition and file formats.

• how to set up levels and threshold for alerts. For exam-ple, how to send an alert regarding such event.

Note 1: Events and Logs Recorder procedures are to be submittedin the ELR User Guide.

4.2.2 Alerting

The ELR automatically is to report any kind of event asdetermined at supervision level for any equipment.

The reported alerts are to be, at least, under the followingformats: on the screen (web page over http), by an emailalert, with a sound alert.

Note 1: Events and Logs Recorder procedures are to be submittedin the ELR User Guide.

4.2.3 Recording

ELR is to receive all events and logs feeds from all theequipment and record them in a way they can be easilyanalysed by standard logs analyse systems.

4.2.4 Delivery

Delivery: Procedures regarding functionalities describedhereinbefore are to be submitted in the ELR User Guide.

Note 1: To get { CYBER SECURE, file format used to record eventsis to be recognized by the Society.

4.3 Maintenance

4.3.1 Records management

ELR storage is to be copied in a safe place. A function is toexplain how to proceed to copy and to verify integrity of theimages.

Copies may be done in a remote location through networkconnection at quay, or by using a box extraction systemwith a rotation of storage between the vessel and ashoreoperation centre (i.e. removable media).

4.3.2 System restoration

Procedures for diagnostic, reinstallation and restoration ofthe equipment, system or solution are to be written to theattention of Operators.

4.3.3 Emergency procedures

Procedures for emergency extraction of records are to bedetailed with location to the equipment.

4.3.4 Delivery

Delivery: Procedures regarding maintenance requirementsdescribed hereinbefore are to be submitted in the ELR UserGuide.


4.4.1 Equipment securityEquipment security rules defined in Sec 2 fully apply to ELR.

4.4.2 Separated environmentsELR connectors used to collect information and supervisioninterface are to use strong separated and safe logical envi-ronments (i.e. separated virtual machines.)

4.4.3 Encryption

ELR uses approved encryption mechanism in order toensure confidentially and integrity of the storage. As muchas possible, in order to ensure integrity of information trans-fer, events and logs are to be encrypted during networktransmission.

4.4.4 StorageELR is to use a storage mechanism in order to manage stor-age space issues and backup of history.

4.4.5 Visual identificationCentral unit containing recorders is visually identifiable (i.e.orange coloured box).

Removable media location is visually identifiable (i.e. blackarrows with safety message).

4.4.6 IntegrityELR is to guarantee safety of recorded information. The pro-cess in charge of writing files is to be at system level.

Nor administration profiles nor operators profiles shall haveother access right than read access.

Backup operator is not to have read access right.

4.4.7 Source authentication

ELR is to use an approved authentication mechanisms inorder to guarantee origin of information.

4.4.8 TimelineELR is to monitor the IT infrastructure and store events logsto enable the reconstruction, review and examination of thetime sequences of operations and the other activities sur-rounding or supporting operations.

4.4.9 Events signatureRecorded information from ELR are to be used as a legalproof in case of need. Recording events are hashed, build-ing a sealed signature.

Events signature and related timestamps are to be recordedin a safe place, assuring authenticity of the events and logsrepository.

4.4.10 Time synchronization

ELR is to use approved, synchronized and independent timefeed in order to guarantee logs and events timestamp.

4.4.11 SubmissionDelivery: Procedures regarding security mechanismsdescribed hereinbefore are to be submitted for approval inthe ELR Security Mechanisms Guide.


NR 659, Ch 3, Sec 5


1 General

1.1 Management

1.1.1 Rules from Ch 2, Sec 4 are to be applied: relevantdeliverables are to be submitted.

1.2 Forensics

1.2.1 Forensics capabilities

A procedure is to explain how to use CSR for testing andmonitoring of the security implementation on Level 3 sys-tems and equipment in a proactive way. A timeline withevents, changes and alerts is proposed.

1.2.2 Forensic timeline

A procedure is to explain how to control Level 3 systemsand equipment with a forensic approach: recovery of his-tory and useful information during investigation

1.2.3 Forensic toolboxForensic tools used for emergency operations have to beinventoried, validated and kept up-to-date by cyber securityofficer.

1.2.4 Remote forensics toolsRemote Forensics tools used by security operation centre toremotely investigate alerts could be included to endpoint.Their implantation is to be described and procedure regard-ing their usage is to be submitted.

1.2.5 Manufacturers forensic toolsLevel 1 and Level 2 may welcome manufacturer dedicatedforensic tools after authorization of cyber security officer.Authorization is to be recorded in the Cyber Registry. Toolsare scanned by using an IDG. A procedure is to be detailedin the Cyber Handbook.

1.2.6 DeliveryDelivery: Procedures regarding Forensics Usage describedhereinbefore are to be submitted in the Cyber Handbook.


NR 659, Ch 3, Sec 5


NR 659

Chapter 4

SURVEY OPERATIONS

SECTION 1 GENERAL

SECTION 2 MONITORING SURVEY

SECTION 3 INFRASTRUCTURE SURVEY

SECTION 4 EQUIPMENT SURVEY

SECTION 5 MAINTENANCE PROCEDURES SURVEY


NR 659, Ch 4, Sec 1

SECTION 1 GENERAL

1 General

1.1 Survey

1.1.1 Purpose

The purpose of this Chapter is to give details on the scope ofsurveys of CYBER MANAGED and CYBER SECURE shipswhich need specific requirements to be verified for themaintenance of class.

1.1.2 Documentation on board

The vessel integrator is to obtain, supply and maintain doc-umentation as specified in this Chapter.

The requested document is to be readily available for exam-ination by the Surveyor.

The documentation is to be kept on board for the lifetime ofthe ship.

1.1.3 Cyber registry usage

Surveys are to be systematically recorded in the Cyber Reg-istry: date, actors, tests performed, results and conclusions.

1.1.4 Materials

Required materials for the survey operations are:

• Cyber Survey Manual

• Cyber Handbook

• Cyber Repository

• Cyber Security Policy.

1.1.5 ReferencesThe following references are to be submitted in the CyberRepository:• compliance baseline, requested in: Ch 2, Sec 2, [1.1.3]

for CYBER MANAGED class notation• compliance scope, requested in: Ch 2, Sec 2 [1.1.2] for

CYBER MANAGED class notation.

1.1.6 Survey workflowThe survey procedure and test cases are written in accord-ance with this Chapter by the Shipowner in the Cyber Sur-vey Manual.

The Cyber Survey Manual is to be submitted for approval bythe Shipowner.

Under request of the Society, the survey procedure isapplied onboard under responsibility of the Shipowner by:• Shipowner teams• Third-party partner

• Recognized third-party (mandatory for { CYBERSECURE).

The tests hereinbefore detailed are to be carried out by theCyber Security responsible, the report of which is to bedelivered for verification during the survey.

Test results are to be submitted by the Shipowner in theCyber Registry.

See workflow as presented in Fig 1.

1.2 Cyber survey manual

1.2.1 ResponsibilitiesVessel integrator is in charge to deliver survey proceduresand relevant tools in the Cyber Survey Manual.


NR 659, Ch 4, Sec 1

Figure 1 : Survey workflow

1.2.2 Application

The scope of application depends on:

• technical scope which may be: Remote access systems,Level 1 systems, Level 2 systems, Level 3 systems, wire-less networks or cabled infrastructure. The scope ofapplication covers every equipment connected, con-nectable or involved as for management, administra-tion, operating or use.

• class notation (CYBER MANAGED or CYBER SECURE)

• survey type (initial, annual, intermediate or renewal) -survey operations are required by class notation.

• auditing type (weekly, monthly, half-year) - auditingoperations are under Shipowner responsibility.

1.2.3 Scope of survey

The scope of survey is defined from the compliance scopeand refined in Chapters dedicated to Initial Testing, AnnualSurvey, Intermediate Survey and Class Renewal Survey.

Depending of the context, the surveys may:

• define test case which address only a representativesample of the scope of survey

• apply to the full scope of survey.

1.2.4 Submission

Survey procedures are to be detailed and submitted forapproval in the Cyber Survey Manual.

The requested topics are summarized in Tab 1 and detailedin this Chapter.

2 Initial inspection

2.1 Scope of survey

2.1.1 Documents to be submittedThe following documents are to be submitted:• Cyber Risk Analysis• Cyber Security Policy• Cyber Repository• Cyber Handbook• Cyber Registry• Cyber Survey Manual.

2.1.2 SurveysThe surveys for initial inspection are summarized in Tab 1and detailed in this Chapter.

3 Annual survey

3.1 Scope of survey

3.1.1 Documents to be updatedRegarding Level 3 equipment only, the following docu-ments are to be updated:• Cyber Risk Analysis.

3.1.2 Documents to be deliveredThe following documents are to be submitted:• Cyber Registry• Cyber Repository, if modified• Cyber Handbook, if modified• Cyber Survey Manual, if modified.

3.1.3 SurveysThe annual surveys are summarized in Tab 1 and detailed inthis Chapter.

SURVEYPROCEDURES TEST CASE

CLASSEVALUATION

TEST RESULTS

SURVEYOPERATION

CYBER SURVEYMANUAL

CYBER REGISTRYShipowner

Shipowner

Observer: Surveyor

Surveyor

Submitted for approvalSurvey calendar

Class Society


NR 659, Ch 4, Sec 1

4 Intermediate survey

4.1 Scope of survey

4.1.1 Documents to be updatedRegarding Level 3 equipment only, the following docu-ments are updated:

• Cyber Risk Analysis

• Cyber Repository (systems identification part)

4.1.2 Documents to be deliveredThe following documents are to be submitted:

• Cyber Registry

• Cyber Handbook, if changed

• Cyber Survey Manual, if changed.

4.1.3 Surveys

The intermediate surveys are summarized in Tab 1 anddetailed in this Chapter.

5 Class renewal survey

5.1 Scope of survey

5.1.1 Documents to be updatedThe following documents are updated:• Cyber Risk Analysis

Regarding Level 2 and Level 3 equipment only, the follow-ing documents are updated:• Cyber Repository (systems identification part).

5.1.2 Documents to be deliveredThe following documents are to be submitted:• Cyber Registry• Cyber Handbook, if changed• Cyber Survey Manual, if changed

5.1.3 SurveysThe class renewal surveys are summarized in Tab 1 anddetailed in this Chapter.

Table 1 : Cyber survey manual summary and survey calendar

Chapter Reference Type CN Survey operations calendar

Survey of monitoring operations

Compliance testing Sec 2, [2.1] S M/S II AS IS CRS

Compliance availability testing Sec 2, [2.2] S S II CRS

Equipment accounts testing Sec 2, [2.3] S M/S II IS CRS

Remote access events testing Sec 2, [2.4] S M/S II AS IS CRS

Wireless events testing Sec 2, [2.5] S M/S II IS CRS

Survey of infrastructure

White box testing Sec 3, [2.1] S S II AS IS CRS

Cabled networks Sec 3, [2.2] S M/S II IS CRS

Remote access robustness Sec 3, [2.3] S M/S II AS IS CRS

Remote access logging Sec 3, [2.4] S M/S II AS IS CRS

Wireless networks robustness Sec 3, [2.5] S M/S II AS IS CRS

Black box penetration tests Sec 3, [2.6] D S II AS

Survey of equipment

Accounts security settings Sec 4, [2.1] D M/S II

Operating systems security settings Sec 4, [2.2] D S II

Features security settings Sec 4, [2.3] D M/S II

Antivirus solution Sec 4, [2.4] D M/S II

Software maintenance Sec 4, [2.5] D M/S II AS

Survey of maintenance procedures

Recovery plan testing Sec 5, [2.1] D M/S II CRS

Compliance update Sec 5, [2.2] D S II

Note 1:Type: S : Submitted for approvalD : Delivered

Calendar: II : Initial Inspection AS : Annual Survey IS : Intermediate Survey CRS : Class Renewal Survey

CN Class notation:M : CYBER MANAGEDS : CYBER SECURE


NR 659, Ch 4, Sec 1

Maintenance protection tests Sec 5, [2.3] D M/S II AS IS CRS

Wireless patch management Sec 5, [2.4] D M/S II AS

Chapter Reference Type CN Survey operations calendar

Note 1:Type: S : Submitted for approvalD : Delivered

Calendar: II : Initial Inspection AS : Annual Survey IS : Intermediate Survey CRS : Class Renewal Survey

CN Class notation:M : CYBER MANAGEDS : CYBER SECURE


NR 659, Ch 4, Sec 2

SECTION 2 MONITORING SURVEY

1 General

1.1

1.1.1 DefinitionMonitoring procedures are procedures used onboard by thecyber security officer and, or, cyber security responsible tocheck security of the systems.

Those procedures are to be detailed in the Cyber SecurityPolicy document as described in Ch 2, Sec 4 [3.2] and relyon Cyber Handbook.

The objective of this survey is to verify the good functioningof monitoring procedures and the relevance of those results.

2 Surveys

2.1 Compliance testing

2.1.1 ContextCompliance of the systems is checked by the cyber securityOfficer by using compliance monitoring procedures.

Compliance monitoring procedures are part of “Monitor-ing” Section of the Cyber Handbook.

2.1.2 Technical scopeDefined by the compliance monitoring procedures.

2.1.3 Test caseFor targeted equipment a set of trials (called the test case) isto be defined in order to verify properness of detectionregarding loss of compliance.

Test case is non-destructive.

The test case is defined by:

• selecting some equipment from the survey scope

• selecting some compliance baseline elements (i.e.accounts, system files, configuration elements, connec-tion filtering, automation part of code, etc.) from theequipment selection

• selection of types of operations: creation (add), suppres-sion (del), modification, unauthorized access, failures,success, etc.

2.1.4 Test resultsThe following processing steps are described:

• Backup of the initial state of the test case elements by,for example:

- making a backup of the files on a safe place (i.e.reserved disk space, removable media, etc.)

- taking pictures or screenshots of configurations

- writing down modified elements.

• First strict application of the compliance monitoring pro-cedures: survey is opened when the compliance state issuccessful for equipment covered by the test case. If thecompliance state is unsuccessful, survey is aborted.

• Modification of equipment by applying the test case.

• Second, strict application of the compliance monitoringprocedures:

- survey is successful when the test case edits aredetected during application of the compliance mon-itoring procedures.

- In any other case, survey is a failure.

• Restoration of the initial state for the test case elements.

• Third and last strict application of the compliance moni-toring procedures: survey is closed when the compli-ance state is restored.

2.1.5 Class evaluation

Survey is successful when the test case edits are detectedduring application of the compliance monitoring procedures.

2.2 Compliance availability testing

2.2.1 Context

A compliance solution is in place to detect changes onequipment.

When the compliance solution uses real-time part of soft-ware or automated software, the availability of the herein-before solution is tested.

In the “Monitoring” Section of the Cyber Handbook, a“Compliance Availability” procedure details availability,capabilities, efficiency and exhaustiveness verification asdefined in Ch 2, Sec 2, [1.2.2].

2.2.2 Technical scope

Compliance solution.

2.2.3 Test case

The survey is to propose a scenario to apply the procedurein:

• correctly operating and running condition and

• stopped condition with unavailability of the compliancesolution.

2.2.4 Test result

The states of the compliance solution are to be verified forboth correctly operating and stopped conditions.


The survey is successful when the hereinbefore procedurecorrectly detect both states of the test.


NR 659, Ch 4, Sec 2

2.3 Equipment accounts testing

2.3.1 Context

Accounts monitoring are part of cyber security responsibleduties.

In the “Monitoring” Section of the Cyber Handbook, an“Equipment Accounts Monitoring” procedure details howto review users' accounts as defined in Ch 2, Sec 2, [2.4.1].

The objective of the Survey is to verify consistency of thehereinbefore procedure.


The scope of this Survey apply to Level 3 Equipment only.

2.3.3 Test case

The survey is to define a way to verify accuracy of the infor-mation by confronting the Equipment Accounts Monitoringprocedure with another procedure (i.e. manual operationfrom a local console and visual comparison of the results).

2.3.4 Test result

Cyber Handbook procedures and survey operation are to becompared and gaps are to be highlighted.


The survey is successful when the comparison reveals nogap between Cyber Handbook procedures and Surveyoperation.

2.4 Remote access events testing

2.4.1 Context

The remote access systems and equipment are defined inthe Cyber Repository in the “Remote Access” Section asdefined in Ch 2, Sec 3, [1.5.3]

Depending of the architecture, the technologies and thethreats, security events are recorded.

Monitoring of “Remote Access Events” records is explainedin the Cyber Handbook in the Section “Monitoring”.

The objective of this Survey is to validate the good function-ing regarding the entire scope of events detailed in the here-inbefore procedure.


This Survey applies to Level 3 Equipment only.

2.4.3 Test case

The Cyber Survey Manual is to deliver a test case.

Test case is to propose one or more test for each type ofevent.

Tests may use current Equipment or external testing Equip-ment in order to send packets on the network for example.

Test case is to be non-destructive.

2.4.4 Test result

Those tests are to be applied during the survey operation.

Then the events are to be checked by using the “RemoteAccess Events” procedure of Cyber Handbook “Monitoring”Section as defined in Ch 2, Sec 3, [1.5.3].


The Survey is successful when a relevant event is present foreach played tests of the test case.

2.5 Wireless events testing

2.5.1 Context

The wireless systems and equipment are listed in the CyberRepository document under “Network” Section.

Depending of the architecture, the technologies and thethreats, security events are recorded.

Monitoring of “Network Events” records is explained in theCyber Handbook in the Section “Monitoring” as defined inCh 2, Sec 3, [4.2.2].

The objective of this Survey is to validate the good function-ing regarding the entire scope of events detailed in the here-inbefore procedure.


This Survey applies to Level 3 Equipment only.

2.5.3 Test case

The Cyber Survey Manual is to deliver a test case.

Test case is to propose one or more test for each type ofevent.

Tests may use current equipment or external testing equip-ment in order to send packets on the network for example.


2.5.4 Test result

Those tests are to be applied during the survey operation.

Then the events are to be checked by using the “NetworkEvents” procedure of Cyber Handbook under “Monitoring”Section.


The Survey is successful when a relevant event is present foreach played tests of the test case.


NR 659, Ch 4, Sec 3

SECTION 3 INFRASTRUCTURE SURVEY

1 General

1.1

1.1.1 DefinitionInfrastructure procedures are procedures used onboard bythe Surveyor to verify the level of cyber security of the ves-sel and to confirm the class notation.

2 Surveys

2.1 White box testing

2.1.1 ContextObjective of white box testing is to deliver a health check-upof systems and equipment by using all the information regard-ing the vessel (i.e. Cyber Repository) in one hand and, inother hand, to use cyber expertise and knowledge of testers.

2.1.2 Technical scopeThe technical scope of white box testing applies to:• any system or equipment using or involved in remote

access• any system or equipment using or involved in wireless

networks• any system or equipment involved in the network man-

agement and security of cabled networks• any Level 3 equipment of Cat. A, Cat. B and Cat. C.

2.1.3 Test caseBy using Cyber Repository information, a procedure of testsis to be written to:• check exposure to Common Vulnerabilities and Expo-

sures on operating systems, applications, automationand all network equipment.

• detect presence of known indicators of compromise onCat. A, Cat B and Cat. C equipment.

• verify integrity of system architecture (i.e. authorizedequipment, number of automation, version, etc.)

• search for configuration errors in networks filtering androuting.

Tests are to be non-intrusive and non-destructive. Tests areto be submitted and approved by Society.

2.1.4 Test resultsTests results details applied procedures, tools and methods.An evaluation of the level of security is to be submitted.

2.1.5 Class notationThe Society evaluates the success of the test regarding thetechnical scope, the effort (I.e. number of tests), the quality(i.e. technics and tools) and the results.

2.2 Cabled networks

2.2.1 Context

Cabled networks are living part of the infrastructure:

• every day, equipment are connected, disconnected,added, deleted, moved.

• during maintenance operation, network configurationsmay be changed.

This survey propose tests to compare onboard cabled net-works installation with elements declared in the CyberRepository.


The technical scope of cabled network testing applies toany Level 2 and Level 3 system and identified in the processchain in the Cyber Risk Analysis (defined in Ch 1, Sec 2,[2.3]).

In the same scope, equipment involved in the network man-agement and security of cabled networks are considered inthis trial.

2.2.3 Test case

The test case is to rely on the network cartography deliveredin the Cyber Repository as defined in Ch 2, Sec 3, [3.1.1].

Test case is to propose an active network scanning (i.e. net-work scanners or penetration tests) conducted in the cablednetworks to ensure that the principles of isolation defined inthe architecture are respected.

Tests may use tools, be scripted, or written with a check listof commands to type in console mode during the survey.

Tests are to be launched from different location of the sys-tem in order to survey the different paths of weakness andattacks (i.e. in front of and behind a firewall).


2.2.4 Test results

Results are to be compared with the network cartography ofthe Cyber Repository in order to find consistency betweenthe two documents.

2.2.5 Class notation

Survey is successful when network cartography of the CyberRepository is consistent with the Results.

Survey is unsuccessful when one or more element of theNetwork Cartography of the Cyber Repository is not consist-ent with the results.


NR 659, Ch 4, Sec 3

2.3 Remote access robustness

2.3.1 Context

Remote access equipment are used as a remote entry pointfor the vessel systems and equipment. From an attackerpoint of view, it represents a key target.

This survey propose tests to compare ashore and onboardremote access installation with elements declared in theCyber Repository.


The technical scope of remote access robustness testingapplies to any ashore and onboard Level 2 and Level 3 sys-tem and identified in remote access usage in the CyberRepository (defined in Ch 2, Sec 3, [1]).

2.3.3 Test case

The test case is to rely on the remote access usage deliveredin the Cyber Repository as defined in Ch 2, Sec 3, [1].

Test case is to propose:

• trials to demonstrate encryption on the networks (i.e.packet sniffing) - defined in Ch 2, Sec 3, [1.3.1]

• active network scanning (i.e. network scanners or pene-tration tests) conduct outside the vessel, in order toensure that the DMZ respect the Cyber Repository asdefined in Ch 2, Sec 3, [1.3.2]

• active network scanning (i.e. network scanners) conducton each side of firewalls, in order to ensure that the fire-wall respect its filtering policy. As defined in Ch 2, Sec3, [1.3.3], Ch 2, Sec 3, [1.3.4], Ch 2, Sec 3, [1.3.5]

• active network scanning (i.e. network scanners or pene-tration tests) are conduct ashore, in order to ensure thatashore systems respect the Cyber Repository

• active tests on IPS, when they exist, to ensure that theIPS blocks malicious packets as defined in Ch 2, Sec 3,[1.3.6].


Tests are to be launched from different location of the sys-tem in order to survey the different paths of weakness andattacks (i.e. in front of and behind a firewall).


2.3.4 Test results

The test case is to propose a way to compare remote accessusage delivered in the Cyber Repository as defined in Ch 2,Sec 3, [1] in order to:

• check the proper functioning of traffic encryption

• check the good state of DMZ principles

• check the proper functioning of firewalls traffic filtering

• check the good state of ashore systems

• check the proper functioning of traffic blocking.


Survey is successful when remote access usage of the CyberRepository is consistent with the results

Survey is unsuccessful when one or more element of theremote access usage of the Cyber Repository is not consist-ent with the results.

2.4 Remote access logging

2.4.1 Context

Remote access equipment are used as a remote entry pointfor the vessel systems and equipment. From an attackerpoint of view, it represents a key target.

This survey propose tests to check DMZ events logging cov-erage and efficiency.


The technical scope of remote access logging testing appliesto any ashore and onboard Level 2 and Level 3 system andidentified in remote access usage in the Cyber Repository(defined in Ch 2, Sec 3, [1].

2.4.3 Test case

The test case is to rely on Ch 2, Sec 3, [1.5.3] whichdescribes needs on remote access logging.

The test case is to identify the different points of authentica-tion, connection and traffic logging. Then, tests are pro-posed with the following steps:

• check of the initial state of the logs by using the proce-dure described in the Cyber Security Policy.

• run different kind of trials with the following logic:

- identify sources and destinations points, from the out-side to the vessel and from the vessel to the outside

- identify different scenarios of accepted and rejectedconnections

- identify authenticators.

• check of the final state of the logs by using the proce-dure described in the Cyber Security Policy.



2.4.4 Test results

The test case is to confront the initial state of the logs withthe final one. Awaited results of hereinbefore test cases areto be submetted.


Survey is successful when the final state of the logs containa full record of events executed by the test case.

Corrections are to be implemented or mitigations measuresare to be adopted when elements are missing.

Survey is unsuccessful when events about accepted andrejected connections are missing.


NR 659, Ch 4, Sec 3

2.5 Wireless networks robustness

2.5.1 Context

Wireless networks represent a vulnerability as they may belistened from a distance and, by resulting, taken in controlby a remote attacker.

This survey propose tests to compare wireless installationwith elements declared in the Cyber Repository.


The technical scope of wireless networks robustness testingapplies to any Level 3 wireless system identified in wirelessarchitecture in the Cyber Repository as defined in Ch 2, Sec3, [2.1.1].

2.5.3 Test case

The test case is to rely on wireless architecture ( Ch 2, Sec 3,[2.1.1]) and wireless LAN ( Ch 2, Sec 3, [2.1.2]).

The test case is to propose test to:

• check proper network traffic encryption

• check segregation of the network (physical and logical)

• check transmission range

• check wireless network architecture by using active net-work scanning (i.e. network scanners or penetration tests).



2.5.4 Test results

Survey is successful when wireless architecture of the CyberRepository is consistent with the results

Survey is unsuccessful when one or more element of thewireless architecture of the Cyber Repository are not con-sistent with the results.

2.6 Black box penetration tests

2.6.1 Context

Objective of black box penetration testing is to deliver ahealth check-up of systems and equipment by using an “outof the box” approach.

Black box penetration tests are here to find paths in the sys-tem which are undocumented, unknown and, thus, unde-fined in the test case.

Those tests make sense during the initial inspection as thevessel in not yet in operation.

A recognized partner is recommended and is required toget the CYBER SECURE notation.

2.6.2 Technical scopeThe technical scope of white box testing applies to:• any system or equipment using or involved in remote

access• any system or equipment using or involved in wireless

networks• any system or equipment involved in the network man-

agement and security of cabled networks• any Level 3 equipment of Cat. A, Cat. B and Cat. C.

2.6.3 Test caseBy using Cyber Repository information, a procedure of testsis to be written with the following restrictions:• code injection is authorized on operating systems,

applications, automation and all network equipment• hardware security analysis is authorized• depending of the scope, the need and the target of eval-

uation, software and hardware hacking tools may beemployed during black box penetration tests. (i.e. vul-nerability exploitation tools, maintaining access tools,reverse engineering tools, remote access control tools,password crackers, rootkits, sniffing, fuzzing, denial ofservices, packet crafting, tunnelling, proxies, man in themiddle, USB implant tools, network implants embed-ding remote access, wifi pineapple, etc.)

• equipment forensics may be used to reveal useful infor-mation for attackers.

While conducted, black box penetration tests are to bestrictly traced and recorded.

Tests are to be intrusive and potentially destructive. Tests areto be submitted and approved by Society.

2.6.4 Test resultsTests results are to detail applied procedures, tools andmethods. An evaluation of the level of security is to be sub-mitted.

2.6.5 Class notationThe Society evaluates the success of the test regarding:• the technical scope (which is to be exhaustive regarding

equipment)• the efficiency of test cases (technics and tools are to be

updated)• the results.


NR 659, Ch 4, Sec 4

SECTION 4 EQUIPMENT SURVEY

1 General

1.1

1.1.1 Definition

Equipment procedures are procedures used onboard by theSurveyor to verify the level of cyber security of specificequipment involved in the evaluation of the class notation.

2 Surveys

2.1 Account security settings

2.1.1 Context

Accounts are entries points of the systems. The correctapplication of the policies applicable on those systems isfundamental. For this reason, the Surveyor will verify con-sistency between Rules and onboard equipment. Rules torefer to are those defined in Cyber Repository.


The technical scope apply to each Level 2 and Level 3equipment identified in the process chain in the Cyber RiskAnalysis as defined in Ch 1, Sec 2, [2.3].

2.1.3 Test case

In order to verify proper implementation of accounts secu-rity settings (see Ch 2, Sec 2, [2.1.3]), relevant tests are to besubmitted.

Robustness of password is to be verified with a procedurewhich try to create an account, in order to check that thepolicy is applied. At the end of the survey, the createdaccount is to be deleted through a relevant procedure.

Tests are to be written in accordance with the topicsdetailed in the Cyber Repository. Tests will try different pat-tern to verify a list of cases.

2.1.4 Test results

Tests case is to contain awaited results for each case.


Survey is successful when all test successfully achieved.

Corrections are to be implemented or mitigations measuresare to be adopted for tests identifying non-conformances.survey is systematically unsuccessful when:

• equipment can be accessed without authenticationmechanism (identification and “password”)

• generic and default accounts are be used

• one or more password is weak.

2.2 Operating systems security

2.2.1 Context

Operating systems are the core of equipment. For equip-ment with a high level of Risk (Level 3), operating systemssecurity settings are checked in accordance with the infor-mation delivered in the Cyber Repository.


The technical scope apply to each Cat. A Level 3 equipmentidentified in the process chain in the Cyber Risk Analysis asdefined in Ch 1, Sec 2, [2.3].

2.2.3 Test case

In order to verify proper implementation of operating sys-tems security settings, relevant tests are to be submitted.Tests are to be written in accordance with the topicsdetailed in the Cyber Repository.

Depending of the contents of the rules detailed in the CyberRepository Test may address: system services, accounts,local policies, audit policies, events logs management, fileaccess control list, network interfaces configuration, net-work filtering, etc.

At a minimum, the test will check: connections (listeningand outgoing), in-memory processes, in-operation servicesand ran applications.


2.2.4 Test results



Survey is successful when the tests do not show any incon-sistency between the equipment and the Rules delivered inthe Cyber Repository.

Corrections are to be implemented or mitigations measuresare to be adopted for tests identifying non-conformances.survey is systematically unsuccessful when:

• unexpected connection, process, service or applicationhave been detected

• events logs management is off or inefficient.

2.3 Features security settings

2.3.1 Context

Features security settings are elements installed on Cat. Band Cat. C equipment used to deliver or help securitymechanisms. Features are predefined in the Cyber Reposi-tory. The Surveyor is in charge to check the accuracy of theirimplementation.


NR 659, Ch 4, Sec 4


The technical scope apply to each Cat. B and Cat. C Level 3equipment identified in the process chain in the Cyber RiskAnalysis (defined in Ch 1, Sec 2, [2.3]).

2.3.3 Test case

In order to verify proper implementation of features securitysettings, relevant tests are to be submitted. Tests are to bewritten in accordance with the topics detailed in the CyberRepository.

When detailed in the Cyber Repository, the following are tobe tested:

• equipment self-tests procedures or any integrated integ-rity checking tool

• equipment physical configuration (OT safety switches).

• equipment system services, accounts policies, eventslogs management, network interfaces configuration,network filtering.

Tests may use manual operation, numeric tools, scripts or acheck list of command line to type in console mode duringthe survey.

2.3.4 Test results



Survey is successful when the tests do not show any incon-sistency between the equipment and the Rules delivered inthe Cyber Repository.

Corrections are to be implemented or mitigations measuresare to be adopted for tests identifying non-conformances.Survey is systematically unsuccessful when:

• OT safety switch is in a wrong position

• unexpected connection, process, service or applicationhave been detected

• events logs management is off or inefficient.

2.4 Antivirus solution

2.4.1 Context

The antivirus solution represent a first barrier against virusesand malwares. This first-aid tool is also a path of weaknessas it needs to be periodically updated, properly launchedand correctly installed.

The survey demonstrate the good coverage of the antivirussolution.


The technical scope apply to each Cat. A Level 3 equipmentidentified in the process chain in the Cyber Risk Analysis(defined in Ch 1, Sec 2, [2.3]).

2.4.3 Test case

Trials are to propose procedures to:

• proof installation of antivirus software ( Ch 2, Sec 2,[2.2.1]).

• warranty efficiency on operation: an example of fakevirus signature is often proposed by the antivirus ven-dors in order to verify detection systems

• check availability of the antivirus solution ( Ch 2, Sec 2,[2.2.1]): tests are to be done without restarting theequipment, in order to take into account the duration ofrun of the equipment and thus the ability of the antivirussolution to be up after a large amount of time

• demonstrate detection of loss of antivirus compliance:this test can rely on the survey already described in Sec2, [2.1]

• verify update capabilities of the antivirus solution ( Ch2, Sec 2, [2.3.2].

Tests may use manual operation, numeric tools, scripts or acheck list of command line to type in console mode duringthe survey.

2.4.4 Test resultsTests case is to contain awaited results for each case.

2.4.5 Cyber registry periodical surveysThe Cyber Registry contains events regarding updates of theantivirus solution.

2.4.6 Class notationSurvey is successful when the tests are perfectly successful.

Corrections are to be implemented or mitigations measuresare to be adopted for tests identifying the following:

• results are unsuccessful.

• the equipment manufacturer do not publish updates any-more for the antivirus solution (i.e. unsupported version).

Survey is systematically unsuccessful when:

• antivirus solution is not present or not available

• antivirus solution was not successfully updated

• Cyber Registry contain no trace of regularly applicationof updates

2.5 Software maintenance

2.5.1 ContextThe software maintenance through patch managementdirectly contributes to assurance of cyber security.

The survey demonstrates the regular, correct and in timeapplication of patches delivered by software editors.

2.5.2 Technical scopeThe technical scope apply to each Cat. A, Cat. B and Cat. CLevel 3 equipment identified in the process chain in theCyber Risk Analysis as defined in Ch 1, Sec 2, [2.3].

2.5.3 Test caseTrials are to propose procedures to:

• proof usage of patch management ( Ch 2, Sec 2, [2.3.3])

• proof follow up of supplier's corrective patches

• check Cyber Registry for updates.

Tests may use manual operation, numeric tools, scripts or acheck list of command line to type in console mode duringthe Survey.


NR 659, Ch 4, Sec 4

2.5.4 Test resultsTests case is to contain awaited results for each case.

2.5.5 Cyber registry periodical surveysThe Cyber Registry contains events regarding updates of thesoftware and application of its patches.

2.5.6 Class notationSurvey is successful when the tests are perfectly successful.

Corrections are to be implemented or mitigations measuresare to be adopted for tests identifying the following:

• results are unsuccessful.

• the equipment manufacturer do not publish updatesanymore for the equipment (i.e. unsupported version).

Survey is systematically unsuccessful when:

• patch management is not available or unused

• equipment was not successfully updated

• Cyber Registry contain no trace of regularly applicationof updates.


NR 659, Ch 4, Sec 5

SECTION 5 MAINTENANCE PROCEDURES SURVEY

1 General

1.1

1.1.1 DefinitionMaintenance procedures are procedures used onboard bythe cyber security responsible to maintain level of cybersecurity of the systems.

Those procedures are to be detailed in Cyber Security Pol-icy document and rely on Cyber Handbook.

The objective of this survey is to verify the good functioningof maintenance procedures and their efficiency.

2 Surveys

2.1 Recovery plan testing

2.1.1 ContextRecovery plan usually rely on equipment maintenanceguides, backups and last known configurations, states andparameters. Recovery plan is the only solution to comeback in a safe situation. As recovery plans are used in emer-gency response to incident, there is no place for impreci-sion, lack of information or crew's autonomy. The Surveyorchecks that the procedure works on the first time, withoutany issue and with a successful return in operation.

Restoration of data backup conduct in Ch 2, Sec 4, [3.4.5]must be tested on a representative scale of IT and OT sys-tems.

Procedures described in Ch 2, Sec 4, [3.4.6] are applied.

2.1.2 Technical scopmeThe technical scope of recovery plan testing applies to:• any system or equipment using or involved in remote

access• any Level 3 equipment of Cat. A, Cat. B and Cat. C.

2.1.3 Test caseFor targeted equipment a set of trials (the test case) is to bedefined in order to verify efficiency of the recovery plan.


The survey procedure is to present a way to follow this step-by-step actions:• identification of disaster recovery plan from the Cyber

Security Policy as defined in Ch 2, Sec 4, [3.4.6]• selection of equipment from the survey scope • identification of critical functionalities of the equipment• definition of the non-regression tests. non-regression

tests explain how to verify the correct functioning ofidentified critical functionalities

• use of non-regression tests and record of results, behav-iours and any information regarding the good functioning

• when possible, backup of the equipment by, for example:

- making a backup of the files on a safe place (i.e.reserved disk space, removable media, etc.)

- taking pictures or screenshots of configurations

- writing down sensitive elements regarding configuration• modification, and trace, of the equipment.

2.1.4 Test resultThe following processing steps are to be described:

• application of the recovery plan procedure. The surveyis to trace results of this application:

- convenience of the procedure- ease of reading

- inconsistencies in the procedure

- errors during application of the procedure• if recovery plan is successfully finished, the equipment

is to be restarted. Survey is to trace restart events, check-ing for warnings, abnormalities or errors

• presence of modifications operated before applicationof the recovery plan is done. If those modifications aremissing, the survey may continue

• use of non-regression tests and record of results, behav-iours and any information regarding the good functioning.

2.1.5 Class notationSurvey is successful when this last step is successfullyachieved.

Corrections are to be implemented or mitigations measuresare to be adopted in case of any trouble during the applica-tion of the recovery plan.

2.2 Compliance update

2.2.1 ContextThe efficiency of the compliance monitoring at sea rely onthe capacity to compare the current state of the equipmentto a state of reference, known as accepted.

In case of equipment modification, or any update, upgradeand change, the state of reference shall be maintained.

Surveyor verifies that the compliance procedures exist andthat updates have been applied periodically.

2.2.2 Technical scopeThe technical scope of compliance update testing applies to:

• any system or equipment using or involved in remoteaccess

• any system or equipment using or involved in wirelessnetworks

• any system or equipment involved in the network man-agement and security of cabled networks

• any Level 3 equipment of Cat. A, Cat. B and Cat. C.


NR 659, Ch 4, Sec 5

2.2.3 Test case

The survey procedure is to present a way to follow this step-by-step actions:

• identification of compliance update procedures fromthe Cyber Security Policy defined in Ch 2, Sec 4, [3.3.4]

• identification of a scope of testing

• identification of application of those procedures withpast updates in the Cyber Registry.

2.2.4 Test resultsOn the identified scope of testing, update procedures are tobe applied. Survey trace results of this trial:

• convenience of the procedure

• ease of reading

• inconsistencies in the procedure

• errors during application of the procedure

2.2.5 Cyber registry periodical surveysThe Cyber Registry is to contain events regarding updates ofthe compliance of equipment.


Survey is successful when:

• tests of compliance update achieved successfully

• the Cyber Registry contains successful update operationin accordance with the update procedure.

2.3 Maintenance protection tests

2.3.1 Context

The protection of maintenance operation increase safetyand reduce risk of misuse of an equipment during its main-tenance.

Surveyor is in charge to control applicability and good func-tioning of procedures and technical solution used to protectan equipment during its maintenance.

2.3.2 Technical scopeThe technical scope of maintenance protection testingapplies to any Level 3 system or equipment using orinvolved in remote access.

2.3.3 Test case

The test case is to propose:

• a non-destructive set of tests

• an exhaustive identification of systems impacted by iso-lation procedure during their maintenance

• a test case procedure per equipment.

Each test case is to contain:

• a rationale about the risks covered by the procedure

• the reference to the procedure detailed in the CyberSecurity Policy as defined in Ch 2, Sec 4, [3.2.4]

2.3.4 Tests results

The test case is to give a way to determine a result for eachof those actions:

• verify that equipment is running before application ofthe protection procedure

• apply the protection procedure from the Cyber SecurityPolicy

• verify that equipment cannot be used from the bridgeduring application of the protection procedure

• apply the restart procedure of the protection procedurefrom the Cyber Security Policy

• verify that equipment is available.



• the identified systems match the systems described inthe Cyber Repository in the “Equipment Security Identi-fication” Chapter.

• The test results scored a successful result for each step ofeach system.

2.4 Wireless patch management

2.4.1 Context

Wireless network security partially rely on the efficiency ofits updates. The Surveyor is in charge to check that:

• the updates patch management process is usable

• updates are periodically applied

• the equipment manufacturer publish updates

• the last updates have been applied.


The technical scope of compliance update testing applies toany system or equipment using or involved in wireless net-works.

2.4.3 Test case

The survey procedure is to present a way to follow this step-by-step actions:

• identification of wireless update procedures from theCyber Security Policy defined in Ch 2, Sec 4, [3.3.4]

• identification of a scope of testing

• by using the update procedures, identification of manu-facturers sources of updates (i.e. websites)

• identification of application of those procedures withpast updates in the Cyber Registry.

2.4.4 Test results

On the identified scope of testing, update procedures are tobe applied. Survey is to trace results of this trial:

• convenience of the procedure

• ease of reading

• inconsistencies in the procedure

• errors during application of the procedure.

2.4.5 Cyber registry periodical surveys

The Cyber Registry is to contain events regarding periodicalupdates of wireless equipment.


NR 659, Ch 4, Sec 5



• update patch procedure has been successfully appliedwith the last updates

• updates have been regularly applied

• the equipment manufacturer regularly publish updates.

Corrections are to be implemented or mitigations measuresare to be adopted if the two first conditions have been suc-cessfully achieved but the Equipment manufacturer do notpublish updates anymore for the Equipment (i.e. because ofend of life of the product).

Survey is unsuccessful if one of the two first conditions isunsuccessful.


Marine & Offshore Le Triangle de l’Arche - 8 Cours du Triangle - CS 50101

92937 Paris La Defense Cedex - France Tel: + 33 (0)1 55 24 70 00

https://marine-offshore.bureauveritas.com/bv-rules © 2020 Bureau Veritas – All rights reserved