MARITIME Y ERSE URITY PROJE T · Maritime Cybersecurity Project 1 1. Introduction In July of 2016,...

MARITIME CYBERSECURITY PROJECT

1. Risk-Based Performance Standards Recommendation2. Framework for Cyber Policy

3. Critical Points of Failure

4. Requirements for Maritime Cyber Range

5. Framework for Point of Failure Detection Methodology

6. Maritime Cyber Deterrent Strategy Effectiveness

MARCH 9, 2018

This material is based upon work funded by the U.S. Department of Homeland Security under Cooperative Agreement No. 2014-ST-061-ML0001. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied, of the U.S. Department of Homeland Security.

Maritime Cybersecurity Project

i

Contents 1. Introduction .......................................................................................................................................... 1

1.1. Intended Audiences ...................................................................................................................... 1

1.2. Intended Processes ....................................................................................................................... 2

1.3. Guiding Principles ......................................................................................................................... 2

2. U.S. Marine Transportation System (MTS) ........................................................................................... 2

3. Analytical Scope .................................................................................................................................... 5

3.1. Asset Classes ................................................................................................................................. 5

3.2. Systems ......................................................................................................................................... 6

3.3. Threats ........................................................................................................................................ 10

3.4. Vulnerabilities ............................................................................................................................. 10

3.5. Consequences ............................................................................................................................. 10

4. Common IT/OT Systems ...................................................................................................................... 10

4.1. Vessel Systems ............................................................................................................................ 10

4.2. Facility/Infrastructure Systems ................................................................................................... 11

5. Literature Review ................................................................................................................................ 12

6. NIST Framework Core Mapping .......................................................................................................... 40

7. Recommended Risk-based Performance Standards (RBPSs) .............................................................. 44

7.1. Owner/Operator Has Not Yet Developed a Cybersecurity Program .......................................... 44

7.2. Owner/Operator Has Implemented an IT Cybersecurity Program ............................................. 45

7.3. Owner/Operator Has Implemented an IT/OT Cybersecurity Program ....................................... 46

8. Regulatory Oversight .......................................................................................................................... 50

8.1. Security Management Systems ................................................................................................... 52

8.2. Safety Management Systems ...................................................................................................... 55

9. Framework for Point of Failure Detection Methodology ................................................................... 59

9.1. Background ................................................................................................................................. 59

9.2. Engineering Principles ................................................................................................................. 60

9.3. Framework .................................................................................................................................. 61

9.3.1. Cyber Complexity ................................................................................................................ 62

9.3.2. Business Attributes ............................................................................................................. 63

9.3.3. Cybersecurity Documentation Attributes ........................................................................... 64

10. Critical Points of Failure ................................................................................................................. 67


ii

10.1. Background ............................................................................................................................. 67

10.2. Risk Assessment ...................................................................................................................... 70

10.2.1. Security Risk Assessment Methodologies ........................................................................... 70

10.2.2. Challenges in Cybersecurity Risk Assessment ..................................................................... 72

10.3. Reference Model ..................................................................................................................... 74

10.3.1. Triads ................................................................................................................................... 74

10.3.2. Taxonomy ............................................................................................................................ 75

10.4. Calculation............................................................................................................................... 79

10.4.1. Special Case of the VLN Connection .................................................................................... 79

10.5. Application .............................................................................................................................. 88

10.6. Conclusion ............................................................................................................................... 89

11. Maritime Cyber Deterrent Strategy Effectiveness ......................................................................... 90

11.1. USCG Risk Assessment Models ............................................................................................... 90

11.1.1. Port Security Risk Assessment Tool (PSRAT) ....................................................................... 91

11.1.2. National Risk Assessment Tool (NRAT) ............................................................................... 91

11.1.3. National Maritime Strategic Risk Assessment (NMSRA) ..................................................... 92

11.1.4. MSRAM ............................................................................................................................... 93

11.1.5. Layered Return-on-Investment (L-ROI) Model ................................................................... 93

11.1.6. PWCS Risk-Based Performance Model ............................................................................... 94

11.2. Cyber Decision Support Requirements ................................................................................... 94

11.2.1. Needed Information ............................................................................................................ 96

11.3. Application .............................................................................................................................. 96

11.4. Model ...................................................................................................................................... 97

11.4.1. Scenarios ............................................................................................................................. 97

11.4.2. Threat ................................................................................................................................ 100

11.4.3. Vulnerability ...................................................................................................................... 101

11.4.4. Consequences ................................................................................................................... 104

11.4.5. Types of Consequences & Results..................................................................................... 104

11.4.6. Outputs & Results ............................................................................................................. 105

11.4.7. Cyber Deterrent Strategy Development ........................................................................... 107

12. Requirements for Maritime Cyber Range .................................................................................... 107

12.1. Strategic Priorities ................................................................................................................. 107

12.2. Cyber Ranges ......................................................................................................................... 108


iii

12.2.1. Government Cyber Ranges ............................................................................................... 109

12.2.2. Academic Cyber Ranges .................................................................................................... 111

12.2.3. Commercial Cyber Ranges ................................................................................................ 112

12.3. Mission Support Use Cases ................................................................................................... 112

12.3.1. Use Case #1: Protection of USCG Networks & Assets. ...................................................... 112

12.3.2. Use Case #2: MTSA-regulated assets ................................................................................ 113

12.4. Conclusion ............................................................................................................................. 114

A. Appendix. Updated NIST Framework Mapping ................................................................................ A-1

B. Appendix. Supply Chain References .................................................................................................. B-1

C. Appendix. Security Management System Regulations (New) ........................................................... C-1

D. Appendix. Safety Management System Regulations (New) ............................................................. D-1

E. Appendix. Point of Failure Detection Worksheets ............................................................................. E-1

F. Appendix. USMC CSR Questionnaire ................................................................................................. F-1


iv

Tables

Table 1. Research Topics and Questions ....................................................................................................... 1

Table 2. Common Vessel Systems ............................................................................................................... 11

Table 3. Common Facility/Infrastructure Systems ...................................................................................... 11

Table 4. Literature Review .......................................................................................................................... 12

Table 5. Reference Summaries ................................................................................................................... 13

Table 6. NIST Framework Functions and Categories .................................................................................. 40

Table 7. Updated NIST Framework Core Mapping ..................................................................................... 41

Table 8. Federal and International Regulatory Agencies ............................................................................ 50

Table 9. Security Management System Regulations ................................................................................... 52

Table 10. Safety Management System Regulations and Standards ........................................................... 56

Table 11. Cybersecurity Risk Taxonomy Elements ...................................................................................... 78

Table 12. Cyber Scenario Framework ......................................................................................................... 98

Table 13. Example Exposure Window Assignments ................................................................................. 101

Table 14. Connectedness Assignments by Asset Class and Function ....................................................... 102

Table 15. Example Non-Cyber Mitigation Assignment ............................................................................. 104

Figures

Figure 1. Example Port with Common MTS Components............................................................................. 4

Figure 2. IT/OT Cybersecurity Overview ....................................................................................................... 9

Figure 3. Literature Review Summary ......................................................................................................... 39

Figure 4. Recommended Performance Standards – Facility Decision Tree ................................................ 47

Figure 5. Recommended Performance Standards – MTSA-Regulated Vessel Decision Tree ..................... 48

Figure 6. Recommended Performance Standards – ISPS-Regulated Vessel Decision Tree ........................ 49

Figure 7. Regulatory Oversight for Common MTS Components ................................................................ 51

Figure 8. Components of Maritime Cybersecurity ...................................................................................... 61

Figure 9. Framework Basis .......................................................................................................................... 61

Figure 10. Point of Failure Detection Framework Worksheet (Drill Ship or MODU) .................................. 66

Figure 11. References to risk in Maturity Model References ..................................................................... 69

Figure 12. Fundamentals of Risk Understanding ........................................................................................ 70

Figure 13. MSRAM Risk Methodology ........................................................................................................ 71

Figure 14. MSRAM Risk Levels .................................................................................................................... 72

Figure 15. The Fire Triangle......................................................................................................................... 74

Figure 16. Security Risk Triangle ................................................................................................................. 75

Figure 17. Cybersecurity Risk Triangle ........................................................................................................ 75

Figure 18. Cybersecurity Risk Assessment Reference Model ..................................................................... 76

Figure 19. CRI Calculation ........................................................................................................................... 80

Figure 20. Virtual Asset Diagram................................................................................................................. 81

Figure 21. Example 1: Segmented Architecture ......................................................................................... 82

Figure 22. Example 2: Integration of Safety-critical OT Systems ................................................................ 83

Figure 23. Example 3: Inadvertent Integration of IT and OT Systems ........................................................ 84

Figure 24. Populated Spreadsheet Evaluation Tool for Example Architectures 1, 2, & 3 ........................... 86


v

Figure 25. CRI for Each Function Set ........................................................................................................... 87

Figure 26. CRI for Each Functions ............................................................................................................... 88

Figure 27. Evolution of USCG Risk Models .................................................................................................. 91

Figure 28. Threat Sub-factors ................................................................................................................... 100

Figure 29. Vulnerability Components ....................................................................................................... 102

Figure 30. Consequence Components ...................................................................................................... 105

Figure 31. Exceedance Probability Curve Example ................................................................................... 106

Figure 32. AAL Example ............................................................................................................................. 106

Figure 33. USMC CSR Connectivity Diagram ............................................................................................. 109

Figure 34. NCR Overview .......................................................................................................................... 110

Acronyms

AAL Average Annual Loss

ABS American Bureau of Shipping

AIS Automatic Identification System

APT Advanced Persistent Threat

BIMCO Baltic And International Maritime Council

BNWAS Bridge Navigational Watch Alarm System

BSEE Bureau of Safety & Environmental Enforcement

C2M2 Cybersecurity Capability Maturity Model

CART Common Assessment and Reporting Tool

CCS Council on Cyber Security

CDC Certain Dangerous Cargo

CEM Consequence Equivalency Matrix

CFATS Chemical Facility Anti-Terrorism Standards

CFR Code of Federal Regulations

CG-5P U.S. Coast Guard Assistant Commandant for Prevention Policy

CG-791 U.S. Coast Guard Office of Cyber & Intelligence Forces

CG-CVC U.S. Coast Guard Office of Commercial Vessel Compliance

CGCYBERCOM U.S. Coast Guard Cyber Command

CG-DCO-81 U.S. Coast Guard Office of Performance Management and Assessment

CG-ENG U.S. Coast Guard Office of Design & Engineering Standards

CG-FAC U.S. Coast Guard Office of Port & Facility Compliance

CG-INV U.S. Coast Guard Office of Investigations & Analysis

CG-OES U.S. Coast Guard Office of Operating & Environmental Standards

CG-PSA-2 U.S. Coast Guard Domestic Port Security Evaluation Division

CG-RDC U.S. Coast Guard Research & Development Center

CG-REG U.S. Coast Guard Office of Standards Evaluation & Development

CKEI Cyber Kinetic Effects Integration

CMMI Capability Maturity Model Integration

CMU Carnegie Mellon University

CNCI Comprehensive National Cybersecurity Initiative


vi

COBIT Control Objectives for Information and Related Technology

CODE Cyber Operations, Development and Evaluation

CRI Cybersecurity Risk Index

CRR Cyber Resilience Review

CS&C Office of Cybersecurity & Communications

CSC Critical Security Control

CSO Company Security Officer

CsO Cybersecurity Office

CSR Cyber Security Range

DC Data Confidentiality

DCS Distributed Control System

DHS Department of Homeland Security

DIA Defense Intelligence Agency

DoD Department of Defense

DoDIN DoD Information Network

DOE Department of Energy

DoS Declaration of Security

DOT Department of Transportation

EO Executive Order

EPA Exceedance Probability

EPA Environmental Protection Agency

ERP Enterprise Resource Planning

FCI Functions-Connections-Identities

FDD Functional Description Document

FRs Foundational Requirements

FSA Facility Security Assessment

FSO Facility Security Officer

FSP Facility Security Plan

GDP Gross Domestic Product

GIS Geographic Information System

GMDSS Global Maritime Distress & Safety System

GPS Global Positioning System

HMI Human Machine Interface

HQ Headquarters

IAC Identification and Authentication Control

IACS Industrial Automation and Control System

ICC Intelligence Coordination Center

ICS Industrial Controls System

IMO International Maritime Organization

IoT Internet of Things

IP Internet Protocol

IRT Incident Response Team

ISA International Society for Automation


vii

ISACA Information Systems Audit and Control Association

ISCD Infrastructure Security Compliance Division

ISM International Safety Management

ISO International Organization for Standardization

ISPS International Ship and Port Facility Security

ISRA Information Security Risk Analysis

ISSC International Ship Security Certificate

IT Information Technology

JCTL Joint Cyber Training Lab

L-ROI Layered Return-On-Investment

LNG Liquefied Natural Gas

LSU Louisiana State University

MAPLE Multi-Application Practical Learning Environment

MARSEC Maritime Security

MCR University of Michigan Cyber Range

MIL Maturity Indicator Levels

MoC Management of Change

MODU Mobile Offshore Drilling Unit

MSC Maritime Security Center

MSRAM Maritime Security Risk Analysis Model

MTS Marine Transportation System

MTSA U.S. Maritime Transportation Security Act

NCR National Cyber Range

NIST National Institute of Standards and Technology

NMSRA National Maritime Strategic Risk Assessment

NRAT National Risk Assessment Tool

NSTIC National Strategy for Trusted Identities In Cyberspace

NVIC Navigation and Vessel Inspection Circular

OCS Outer Continental Shelf

OSHA Occupational Safety & Health Administration

OT Operational Technology

PFSOs Facility Security Officers

PHA Process Hazard Analysis

PIC Person-In-Charge

PLC Programmable Logic Controller

PMS Property Management System

PSM Process Safety Management

PSRAT Port Security Risk Assessment Tool

PSS Port Security Specialist

PWCS Ports, Waterways, and Coastal Security

RA Resource Availability

RBDM Risk-Based Decision-Making

RBPS Recommended Risk-Based Performance Standard


viii

RDF Restricted Data Flow

RIN Risk Index Number

S&T Science & Technology

SCADA Supervisory Control and Data Acquisition

SEI Software Engineering Institute

SI System Integrity

SIT Stevens Institute of Technology

SLs Security Levels

SMS Safety Management System

SOLAS Safety of Life at Sea

SP Special Publication

SSAS Shipboard Security Alarm Systems

SSE Systems Security Engineering

SSO Ship Security Officer

SSP Site Security Plan

STIG Security Technical Implementation Guides

SVA Security Vulnerability Assessments

TEU Twenty-Foot Equivalent Unit

TRE Timely Response to Events

TSI Transportation Security Incident

TVC Threat-Vulnerability-Consequence

UC Use Control

US-CERT United States Computer Emergency Readiness Team

USB Universal Serial Bus

USCG United States Coast Guard

USMC U.S. Marine Corps

UTM Unified Threat Management

VDR Voyage Data Recorder

VLN Very Large Number

VOIP Voice Over Internet Protocols

VSA Vessel Security Assessment

VSO Vessel Security Officer

VSP Vessel Security Plan

WLAN Wireless Local Area Network


1

1. Introduction In July of 2016, the Maritime Security Center (MSC) Center of Excellence at the Stevens Institute of

Technology (SIT) sponsored the American Bureau of Shipping (ABS) team to conduct a project on

Maritime Cyber Security. The project is focused on six separate topic areas as shown in Table 1.

Table 1. Research Topics and Questions

Topic Area Research Questions

1 Risk-Based Performance Standards

What risk-based performance standards can be developed for cyber risk management of the Marine Transportation System (MTS)? How would performance standards inter-relate with other infrastructure sectors and their performance standards? How would performance standards inter-relate with existing safety and security management systems?

2 Framework for Cyber Policy

What type of criteria should be utilized to develop an academically rigorous framework for Cyber Policy for the MTS?

3 Critical Points of Failure

Based on a multi-node analysis, what are the critical Points of Failure within the cyber system supporting the MTS?

4 Requirements for Maritime Cyber Range

What are the critical requirements that should be considered when developing an academically rigorous and multi-use Maritime Cyber Range?

5 Framework for Point of Failure Detection Methodology

What methodologies can be utilized or invented to develop a framework to analyze a point of Failure Detection Methodology?

6 Maritime Cyber Deterrent Strategy Effectiveness

What methodologies can be employed to conduct a quantitative analysis of maritime cyber deterrent strategy effectiveness?

1.1. Intended Audiences The primary intended audiences for this research are the broad range of government stakeholders with

cybersecurity roles and responsibilities, specifically:

• United States Coast Guard (USCG) and Department of Homeland Security (DHS) headquarters

(HQ) offices responsible for the development of cybersecurity-related regulations, policies, and

communications:

o Assistant Commandant for Prevention Policy (CG-5P)

o Port & Facility Compliance (CG-FAC)

o Design & Engineering Standards (CG-ENG)

o Standards Evaluation & Development (CG-REG)

o Cyber Command (CGCYBERCOM)

o DHS Office of Cybersecurity and Communications (CS&C)

• USCG Area, District, and Sector units responsible for interacting with industry to provide

awareness of cyber concerns and government cybersecurity-related policy

• USCG and DHS centers who perform research in maritime cybersecurity:

o Research & Development Center (CG-RDC)


2

o DHS Science & Technology (S&T) Cyber Security Division

• Other DHS and USCG HQ offices with roles associated with maritime cybersecurity

o Domestic Port Security Evaluation Division (CG-PSA-2)

o Investigations & Analysis (CG-INV)

o Commercial Vessel Compliance (CG-CVC)

o Operating & Environmental Standards (CG-OES)

o Cyber & Intelligence Forces (CG-791)

o DHS Infrastructure Security Compliance Division (ISCD)

1.2. Intended Processes The research is intended to inform government stakeholders in the development of cybersecurity-

related regulations and policies. In addition, the research should support interactions with industry to

improve awareness of cyber threats and provide actionable guidance to improve cybersecurity by

addressing vulnerabilities.

1.3. Guiding Principles In the performance of this project, the research team was guided by the following principles:

• Strong collaboration with SIT and government stakeholders to ensure that the deliverables are

addressing key areas of need

• Leverage established standards and guidance to ensure that the products are academically

rigorous and address the scope of maritime industries and assets

• Develop practical products tailored to the intended audiences and processes

• Actionable, understandable, and backed by evidence

2. U.S. Marine Transportation System (MTS) The U.S. MTS is a sophisticated network of waterways, ports, and intermodal connections that facilitates

the movement of people and goods on the water and supports recreational use by the public. It is also a

critical pathway to mobilize military forces. The MTS is a highly complex system of systems where many

types of facilities, vessels, barges, and infrastructure components operate every day to ensure safe and

efficient maritime commerce. The MTS1 includes the following elements:

• 25,000 miles of navigable channels

• 238 locks at 192 locations

• Over 3,700 marine terminals

• Numerous recreational marinas

• Over 1,400 designated intermodal connections

The MTS is a strategically important system that contributes significantly to the Nation’s economy1:

• 99% of the volume of overseas trade (62% by value) enters or leaves the U.S. by ship

• Waterborne cargo and associated activities contribute more than $649 billion annually to the

U.S. gross domestic product (GDP), sustaining more than 13 million jobs

1 https://www.marad.dot.gov/ports/marine-transportation-system-mts/


3

• MTS activities contribute over $212 billion in annual port sector federal, state, and local taxes

• Over 45 million twenty-foot equivalent units (TEUs) and 1.5 billion tons of foreign traffic were

handled in 2006, with a value of nearly $1.3 trillion dollars

The MTS is instantiated through a diverse set of ports and waterways throughout the U.S. Each port is

different with unique geographic and hydrographic features as well as a unique mix of industries and

operators. There are a wide variety of users within the MTS, including: facility owner/operators,

domestic vessel operators, foreign vessel operators, public boaters, military, and federal/state/local

government agencies.

From a systems perspective, the MTS has a network of maritime operations that interface with shore side

operations at intermodal connections as part of global supply chain and domestic commercial operations. The MTS

includes international and domestic passenger transportation (ferry and cruise) operations that connects to other

forms of passenger transportation through U.S. ports. There are many types of infrastructure, including: bridges,

tunnels, dams, locks, levees, power plants, and pipelines, that are part of or border on the MTS. Furthermore, the

MTS includes recreational use by a large, nationwide boating community and use by military and other government

vessels to carry out their missions. Finally, there are thousands of commercial waterfront facilities, attractions, and

buildings that are not explicitly part of the MTS, but which can impact MTS operations. Figure 1 provides an

example representation of a port, highlighting the MTS components in yellow.


4

Figure 1. Example Port with Common MTS Components


5

3. Analytical Scope Assessing cyber vulnerabilities and consequences for a system as complex as the U.S. MTS is inherently

difficult. The industries and assets operating within the MTS are broad and diverse, and the array of

cyber threats are innumerable and evolving. Adversaries have a wide range of capabilities and

objectives in their attacks. To help focus on the most important areas, the research team worked with

project sponsors and stakeholders from the USCG and DHS to define analytical boundaries of this

research.

The research team will primarily focus on cyber scenarios involving MTS assets’ technology systems that,

if compromised, could result in physical consequences (e.g., deaths, injuries, spills, property damage,

port commerce impacts). The team will also consider cyber-attacks employed in concert with physical

attacks to increase the probability of attack success or consequences.

The study will not address cyber scenarios focused solely on impacting businesses, such as through the

theft of propriety business data or the disruption of business systems.

The following sections further refine the team’s analytical scope by exploring a variety of scenario

attributes.

3.1. Asset Classes The team will focus its research on asset classes that typically operate within the U.S. MTS, including:

vessels, barges, facilities, and offshore platforms. The primary focus will be on assets that are regulated

under the U.S. Maritime Transportation Security Act (MTSA) 2or the International Maritime

Organization’s (IMO) International Ship and Port Facility Security (ISPS), specifically:

• U.S. flagged vessels (MTSA, Part 104)

• Foreign flagged vessels (ISPS)

• Facilities (MTSA, Part 105)

• Offshore platforms (MTSA, Part 106)

In addition, the team will evaluate the following asset classes that are not regulated under MTSA, but if

compromised, could significantly impact MTS operations:

• Maritime infrastructure (e.g., bridges, dams/locks)

• Smaller commercial vessels (e.g., tugs, fishing boats)

• Maritime facilities (e.g., marinas)

The following asset classes are out of scope for this research project:

• Military facilities and vessels

• Government systems related to the MTS (e.g., vessel traffic system, automated identification

system)

• Recreational boats

• Non-maritime commercial assets that border the MTS (e.g., stadiums, attractions, buildings)

• Water crossings (e.g., pipelines, cables)

2 https://www.congress.gov/107/plaws/publ295/PLAW-107publ295.pdf


6

• Non-maritime infrastructure that border the MTS (e.g., waterside power plants)

3.2. Systems This research project will consider exploitation of both information technology (IT) and operational

technology (OT) systems.

Gartner defines information technology (IT)3 as the entire spectrum of technologies for information

processing, including software, hardware, communications technologies and related services. In general,

IT does not include embedded technologies that do not generate data for enterprise use.

Gartner defines operational technology (OT)4 as hardware and software that detects or causes a change

through the direct monitoring and/or control of physical devices, processes and events in the enterprise.

OT includes industrial controls systems (ICSs), and section 2 of the National Institute of Standards and

Technology (NIST) Special Publication (SP) 800-825 provides a useful overview of ICSs:

ICS, which is a general term that encompasses several types of control systems, including supervisory

control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control

system configurations such as Programmable Logic Controllers (PLC) often found in the industrial

sectors and critical infrastructures. An ICS consists of combinations of control components (e.g.,

electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective

(e.g., manufacturing, transportation of matter or energy). The part of the system primarily

concerned with producing the output is referred to as the process. The control part of the system

includes the specification of the desired output or performance. Control can be fully automated or

may include a human in the loop. Systems can be configured to operate open-loop, closed-loop, and

manual mode. In open-loop control systems the output is controlled by established settings. In

closed-loop control systems, the output has an effect on the input in such a way as to maintain the

desired objective. In manual mode, the system is controlled completely by humans. The part of the

system primarily concerned with maintaining conformance with specifications is referred to as the

controller (or control). A typical ICS may contain numerous control loops, Human Machine Interfaces

(HMIs), and remote diagnostics and maintenance tools built using an array of network protocols.

IT and OT systems are very different. They exist for different purposes, use different technologies, and

protocols. They also have very different consequences if they fail. Scenarios involving IT system

exploitation are likely to impact business communications or the confidentiality of data. Successful

attacks can impact a company’s bottom line, compromise private information, or effect the

performance of a variety of key business functions. Examples of high-profile IT system scenarios include:

• Email hacks on the Democratic National Committee and Sony Pictures

• Major data breaches from Target, Yahoo, and U.S. Office of Personnel Management

• Ransomware attacks against numerous U.S. hospitals

• Denial of Service attacks against GitHub, the British Broadcasting Corporation, and Facebook

3 http://www.gartner.com/it-glossary/it-information-technology/ 4 http://www.gartner.com/it-glossary/operational-technology-ot/ 5 http://csrc.nist.gov/publications/drafts/800-82r2/sp800_82_r2_second_draft.pdf


7

OT failures can result in the loss of control of operational processes, which can result in economic

impacts, physical consequences, structural damage to equipment or facilities, and environmental

ramifications. Examples of high-profile OT scenarios include:

• Equipment damage due to Stuxnet malicious worm causing PLCs within Iran’s nuclear centrifuges to spin too quickly and tear themselves apart

• Safety issue when diver tender station-keeping system on an offshore asset “blue screened” and drifted away, severing the diver umbilical

• Operation downtime when tidal turbine was hacked, and its operating software was encrypted. The utility was held for ransom resulting in a 15-day delay.

• Property damage when a German steel mill’s ICS was hacked, disabling the ability to shut down a blast furnace and subsequently resulting in an explosion causing major damage to the facility

Because they exist for different purposes, IT and OT systems have nearly the opposite priorities. OT

systems emphasize availability, integrity, and confidentiality in that order, whereas, IT prioritizes

confidentiality, then integrity, and then availability.

Consider the following availability example: Does a 1-minute delay in an IT email server’s performance

result in serious consequences? No. Whereas, a 1-minute delay in an OT system signal can cause

process impacts leading to: equipment damage, safety issues, environmental spills, product loss, or

critical mission delays.

Historically, OT systems have often been isolated, whether virtually or physically, from IT networks. OT

systems are often managed by engineering or operations departments that are primarily concerned with

ensuring that the systems are “up-and-running” and maintaining control over operations. These

systems are designed to be simple and reliable with a much longer lifespan (e.g., 30 years) when

compared to IT systems (e.g., 6-10 years). The isolation of OT has traditionally been viewed as the

ultimate safeguard against outside threats, but the days of OT isolation are coming to an end.

There are a number of emerging business needs to integrate OT with IT systems to improve operational

efficiency to remain competitive, such as:

• Enterprise Resource Planning (ERP). Passing data between OT and ERP IT systems to support a

variety of business functions, including: supply chain management, inventory control, and

customer billing, while reducing costs and redundant tasks, such as duplicate data entry.

• Vessel Routing and Fuel Management Systems. Monitoring and reporting fuel consumption

data and performing analytics to optimize fuel usage to increase operational efficiency.

• Software Upgrades. Providing remote access to vendors to enable software management to

minimize cost and downtime.

• Predictive Maintenance. Condition monitoring of equipment to proactively identify potential

failures to inform predictive maintenance activities.

Many companies are beginning to weigh the pros and cons of IT/OT integration, but many see this

integration as inevitable. Since OT system exploitation is far more likely to result in the physical

consequences, the team will focus on OT system exploitation scenarios. IT system exploitation will

primarily be considered only as a potential threat vector to OT systems, if the systems are integrated.


8

Figure x provides examples of common IT/OT components and introduces issues and challenges

associated with an enterprise’s cybersecurity for both IT/OT systems.


9

Figure 2. IT/OT Cybersecurity Overview


10

3.3. Threats The research team will consider two major threat categories to IT and OT systems:

Cybersecurity threats involve the intentional disruption or exploitation of a computer network or

control system by adversaries. The skills and techniques of the adversaries can vary dramatically from

low-level hackers to Advanced Persistent Threats (APTs) with coordinated attacks by organized crime or

nation states. APTs are decidedly more capable in assembling a multidisciplinary team with the full set

of knowledge and skills necessary to carry out the attack.

Cybersafety threats involve the accidental corruption or misuse of cyber systems by owner/operator

personnel or third parties, such as vendors or guests.

3.4. Vulnerabilities The team was considering a wide variety of potential system vulnerabilities spanning several areas and

disciplines. For consistent accounting and communication of vulnerabilities, team will leverage the

vulnerability or predisposing condition taxonomy from Appendix C of NIST SP 800-82. The major

categories are:

• Policy and procedure

• Architecture and design

• Configuration and maintenance

• Physical

• Software development

• Communication and network configuration

3.5. Consequences The traditional emphasis of cybersecurity has been IT-focused: prevention of proprietary/personal

information theft and ensuring the integrity of business systems (e.g., corporate Websites, accounting

systems). This project is focused on scenarios that could result in or contribute to physical

consequences. Specifically, the team will focus on scenarios that could result in or contribute to a

security incident resulting in a significant loss of life, environmental damage, or disruption to the MTS.

4. Common IT/OT Systems Section 3 introduced the many different classes of assets that operate in the U.S. MTS. Due to the wide

range of missions and activities performed by these assets, it should be no surprise that there is a vast

collection of diverse IT and OT systems employed to support these functions. The roles of the systems

are diverse: mission-specific control functions, security systems, communications, and business. The

assortment of systems is increasing each year as automation becomes more ubiquitous and manual

functions are replaced or augmented by systems.

4.1. Vessel Systems The literature references that are specifically associated with vessels, BIMCO (Table 4, Reference #9),

IMO (Table 4, Reference #10), and ABS (Table 4, Reference #11), each provide a list or table of common

vessel systems. The research team reviewed each of these references, read other publicly available

sources, and interviewed maritime experts to develop a simple consolidated list of vessel systems (Table


11

2). This list is not comprehensive, but is meant to represent the range of IT/OT systems that is

commonly found on commercial vessels.

Table 2. Common Vessel Systems

Communication Systems Access Control Systems

Satellite Communication Equipment Surveillance Systems

Voice Over Internet Protocols (VOIP) Equipment Bridge Navigational Watch Alarm System

Wireless Local Area Network (WLAN) Shipboard Security Alarm Systems

Public Address and General Alarm Systems Electronic “Personnel-On-Board” Systems

Bridge Systems Passenger Servicing and Management Systems

Positioning Systems Property Management System (PMS)

Electronic Chart Display Information System Medical Records

Automatic Identification System (AIS) Ship Passenger/Seafarer Boarding Access Systems

Global Maritime Distress & Safety System (GMDSS) Passenger-Facing Networks

Radar Equipment Passenger Wi-Fi or LAN Internet Access

Voyage Data Recorders (VDRs) Guest Entertainment Systems

Cargo Management Systems Communication

Propulsion, Machinery, & Power Control Systems Core Infrastructure Systems

Alarm System Administrative & Crew Welfare Systems

Emergency Response System Administrative Systems

Crew Wi-Fi or LAN

4.2. Facility/Infrastructure Systems The research team reviewed numerous publicly available sources and held discussions with numerous

internal facility experts to develop a simple consolidated list of systems commonly found at maritime

facilities and infrastructure components (Table 3). Again, this list is not comprehensive, but is meant to

represent the range of IT and OT systems that is commonly found at facilities and infrastructure.

Table 3. Common Facility/Infrastructure Systems

Operational Control Systems Miscellaneous Systems

Distributed Control Systems Digital Signage Systems

Ramp Control Systems Laboratory Instrument Control Systems

Terminal Operating Systems Renewable Energy Geothermal Systems

Independent Safety Systems Renewable Energy Photo Voltaic Systems

Alarm Systems Shade Control Systems

Fire Protection Systems Advanced Metering Infrastructure

Environmental Protection Systems (Spill Control) Business Systems

Emergency Shut Down Systems Passenger Check-In Systems

Building Management Control Systems Telecommunication

Building Automation Systems Email

Vertical Transport System (Elevators and Escalators) E-Commerce

Interior Lighting Control Systems Enterprise Resource Planning

Digital Video Management Systems Sales

Energy Management Systems Procurement

Exterior Lighting Control Systems Inventory Control

HVAC Systems Production

Building Safety Systems Distribution

Fire Alarm Systems Accounting


12

Fire Sprinkler Systems Human Resource

Gas Detectors Performance Management

Public Safety/Land Mobile Radios Custom Relationship Management

Smoke and Purge Systems Enterprise Asset Management

Emergency Management Systems Business Intelligence

Security Systems Physical Access Control Systems Intrusion Detection Systems Surveillance Systems Screening Systems Police Dispatch

5. Literature Review The team performed a broad literature review of authoritative sources related to maritime and critical

infrastructure cybersecurity to inform execution of this project. USCG and DHS stakeholders identified

several references to review.

USCG Rear Admiral Paul Thomas (CG-5P) has stressed the importance of and USCG’s commitment to the

use of national and international standards, such as the NIST Framework for Improving Critical

Infrastructure Cybersecurity, the Department of Energy’s (DOE's) Cybersecurity Capability Maturity

Model (C2M2), various International Organization for Standardization (ISO) standards, and others6.

Because of the international and cross-industry nature of the MTS, an overarching framework,

specifically, the NIST Framework, must be used as a basis to realize any practical application and

acceptance of cyber policy. The NIST Framework which provides mapping to several recognized

standards is the central reference for this work.

Table 4 documents the collection of references that were reviewed.

Table 4. Literature Review

# Organization Title Release Date

1

Framework for Improving Critical Infrastructure Cybersecurity

February 2014

2

SP 800-82 Revision 2, Guide to Industrial Control Systems Security

February 2015

3

ISO 27001: Information Security Management Standard (Link not available)

October 2013

4

C2M2 February 2014

5

Industrial Network and System Security (ISA 62443) (Link not available)

November 2011

6

SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations

February 2005

6 U.S. Congress, House. Committee on Homeland Security. Border & Maritime Security Subcommittee. Testimony of Rear Admiral Paul Thomas, Assistant Commandant for Prevention Policy, on Cybersecurity in U.S. Ports, Oct. 8, 2015

https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf

https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf

http://csrc.nist.gov/publications/drafts/800-82r2/sp800_82_r2_second_draft.pdf

http://csrc.nist.gov/publications/drafts/800-82r2/sp800_82_r2_second_draft.pdf

http://energy.gov/sites/prod/files/2014/03/f13/C2M2-v1-1_cor.pdf

http://disa.mil/services/dod-cloud-broker/~/media/files/disa/services/cloud-broker/nist-sp80053-securityandprivacycontrols.pdf

http://disa.mil/services/dod-cloud-broker/~/media/files/disa/services/cloud-broker/nist-sp80053-securityandprivacycontrols.pdf


13

# Organization Title Release Date

7

Instruction 8500.01, Cybersecurity March 2014

8

Transportation Systems Sector Cybersecurity Framework Implementation Guidance

June 2015

9

The Guidelines on Cyber Security Onboard Ships February 2016

10

Interim Guidelines on Maritime Cyber Risk Management

June 2016

11

Guidance Notes on the Application of Cybersecurity Principles to Marine and Offshore Operations

September 2016

12

Control Objectives for Information & Related Technology (COBIT) 5 A Business Framework for the Governance and Management of Enterprise IT

April 2012

13

Top 20 Critical Security Controls (CSC) August 2016

14

SP 800-160, Systems Security Engineering May 2016

15

USCG Cyber Strategy June 2015

16

National Strategy for Trusted Identities in Cyberspace (NSTIC)

April 2011

17

Maritime Bulk Liquids Transfer Cybersecurity Framework Profile

November 2016

The set of references listed in Table 4 were created for a range of purposes and audiences; so, to help

stakeholders better understand the scope, nature, and potential applications of each reference, the

research team provided summaries for all references in Table 5, which include:

• Basic document attributes: title, authoring organization, release date, document type, and page

count

• Applicability to: IT/OT systems, government/commercial, U.S./International, and Facilities,

Vessels, & Offshore

• Relative percentage of content (based on page count percentage) focused on providing

understanding of cybersecurity issues vs. providing implementation guidance to improve

• High-level description of the contents

• Research team commentary on application to the project

Table 5. Reference Summaries

#1. Framework for Improving Critical Infrastructure Cybersecurity

Organization NIST Release Date February 2014

http://www.dtic.mil/whs/directives/corres/pdf/850001_2014.pdf

https://www.dhs.gov/sites/default/files/publications/tss-cybersecurity-framework-implementation-guide-2016-508v2_0.pdf

https://www.dhs.gov/sites/default/files/publications/tss-cybersecurity-framework-implementation-guide-2016-508v2_0.pdf

https://media.scmagazine.com/documents/194/guidelines_on_cyber_security_o_48328.pdf

http://www.safety4sea.com/wp-content/uploads/2016/06/IMO-MSC1-Circ1526-Interim-Guidelines-on-Maritime-Cyber-Risk-Management-2016_06.pdf

http://www.safety4sea.com/wp-content/uploads/2016/06/IMO-MSC1-Circ1526-Interim-Guidelines-on-Maritime-Cyber-Risk-Management-2016_06.pdf

http://ww2.eagle.org/content/dam/eagle/rules-and-guides/current/other/250_cybersafetyV1/CyberSafety_V1_Cybersecurity_GN_e.pdf



http://www.isaca.org/COBIT/Pages/Product-Family.aspx

http://www.isaca.org/COBIT/Pages/Product-Family.aspx

https://www.cisecurity.org/critical-controls/

http://csrc.nist.gov/publications/drafts/800-160/sp800_160_second-draft.pdf

https://www.uscg.mil/seniorleadership/DOCS/cyber.pdf

https://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf

https://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf

https://www.uscg.mil/hq/cg5/cg544/docs/Maritime_BLT_CSF.pdf

https://www.uscg.mil/hq/cg5/cg544/docs/Maritime_BLT_CSF.pdf


14

Type Framework Page Count 41

Audience C-level executives, upper- and mid-level operations managers, implementation teams, assessors, consultants, and others interested in understanding the cybersecurity domain

Content Focus

Applicability

Primary Domains Stakeholders Geography Asset Types

✓ IT ✓ OT

✓ Commercial ✓ Government

✓ U.S. ✓ International

✓ Facilities ✓ Offshore ✓ Vessels

Description

The Framework focuses on using business drivers to guide cybersecurity activities and considers cybersecurity risks as part of the organization’s risk management processes. The Framework consists of three parts: the Framework Core, the Framework Profile, and the Framework Implementation Tiers. The Framework Core is a set of cybersecurity activities, outcomes, and informative references that are common across critical infrastructure sectors. The Core provides detailed guidance for developing individual organizational Profiles. A case-specific Profile is developed by the organization to guide the alignment of its cybersecurity activities with its business requirements, risk tolerances, and resources. The Tiers provide an implementable reference model that enables an organization map and measure the relative coverage of its implementation against the cybersecurity Framework. This approach mimics a common closed-loop control system that enables the structured design, implementation, and measurement of a maritime cybersecurity system. The Framework enables organizations – regardless of size, degree of cybersecurity risk, or cybersecurity capabilities sophistication – to uniformly apply risk management principles and best practices to improvement of critical infrastructure security and resilience. The Framework organizes and structures multiple effective cybersecurity standards, guidelines, and practices that are working effectively in industry today. Moreover, because it references globally recognized standards for cybersecurity, the Framework can also be applied internationally and serve as a model for international cooperation to strengthen critical infrastructure cybersecurity. The Framework is not a one-size-fits-all approach to managing cybersecurity risk for critical infrastructure. Organizations will continue to have unique risks – different threats, different vulnerabilities, and different risk tolerances. Therefore, how they implement the practices in the Framework will also vary. The Framework is intended to help better manage cybersecurity risks, optimize security investments, and protect critical services.

Commentary


15

This document is a result of a presidential Executive Order (EO) to develop a voluntary risk-based cybersecurity framework. While the Framework is described as a set of industry standards and best practices, it is arguably much more. It is an understandable, approachable reference model that organizes the highly complex cybersecurity domain in a way that facilitates discussion, establishes design principles, and facilitates security program implementation metrics. The Framework owes much its universal acceptance as a canonical cybersecurity reference document to its structural clarity, domain coverage, real-world usefulness, and support of related national and global standards.

The Framework is designed for use as a strategic reference model, not an implementation model. That is not to say that it cannot be used as an implementation guide – it can. It contains sufficient general cybersecurity implementation content to fill that need. However, its structure and relative simplicity are more suited to other critical purposes. It provides a tractable mental map in its Core—Tier—Profile structure that is extremely well suited for:

• Executive understanding of security system design goals/outcomes

• Executive understanding of implementation coverage

• Comparative analysis of a security implementation against a norm

• Implementation baselines that promote and encourage economically and supportable development and progressive improvement

• Preparing an “elevator speech” for when a senior executive asks the cybersecurity program director: “Are we secure or how does our program stack up against the competition?

When used for these purposes, the Framework is remarkably elegant and clear, especially for a 17-page treatment of the cybersecurity domain. But when managers and directors attempt to apply the Framework for detailed implementation, it is less useful because:

• The Framework Core is constructed as a “strategic view”

• The Framework’s “five concurrent and continuous Core Functions” require implementation activities across multiple technical and organizational disciplines, making the structure challenging for work distribution and assessment

• The Framework’s functions, categories and subcategories represent a number of levels of logical implementation abstraction (e.g., PR.PT-2 “removable media is protected” vs. ID.RM-2 “organizational risk tolerance is determined and clearly expressed”) that can undermine implementation and assessment activities

The Framework’s simplicity and clarity is attractive to executives and implementation managers alike; however, implementation managers are cautioned to thoughtfully consider its strategic view, its distribution of technologies and competencies across all Core Functions, and its presentation of its Functions, Categories, and Subcategories at multiple levels of abstraction before using it as a primary implementation approach. It provides an exceptional strategic reference model, and outlines a useful (and possibly universal) measurement approach to cybersecurity program capability.

#2. SP 800-82 Revision 2, Guide to Industrial Control Systems Security


Type Standard Page Count 249

Audience Upper- and mid-level management, ICS security engineers, and system administrators


16

Content Focus

Note: The implementation-focused pages are contained in 67 pages of Appendix G, which is especially useful in planning for the tailoring that may be needed to adjust even a sophisticated IT security program into an ICS security program.

Applicability


✓ IT ✓ OT




Description

NIST SP 800-82 focuses on guidance for establishing secure ICSs. These ICSs are typically used in industries such as electric, water and wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing. Various systems can control dispersed assets using centralized data acquisition and supervisory control, control production systems within a local area such as a factory using supervisory and regulatory control, and discrete control for specific applications and generally provide regulatory control. ICSs are vital to the operation of the U.S. critical infrastructures that are often highly interconnected and mutually dependent systems. This document provides: (1) an overview of these ICSs and typical system topologies, (2) typical threats and vulnerabilities to these systems, and (3) recommended security countermeasures to mitigate the associated risks. In the past, ICSs had little resemblance to IT systems; however, low-cost Internet Protocol (IP) devices are now replacing legacy ICS proprietary solutions. The document explains why securing these IT systems have become part of the ICS environment. In some cases, new security solutions are needed that are tailored to the ICS environment.

Commentary

This paper is arguably the canonical reference for ICS cybersecurity in the U.S., and a primary resource globally. The sheer length of the document can make it daunting to approach; however, it is exceptionally well organized, and its information density is notable. The 4-page Executive Summary is a baseline “must read” for level-setting on the nature of both cybersecurity issues and solutions. Key content within the reference include:

• Page 2-1, 18 pages: Descriptive overview of the uniqueness of the ICS environment. Excellent architectural descriptions are provided with IT/OT comparisons and contrasts

• Page 3-1, 7 pages: Descriptive overview of the ICS risk environment. Included are useful discussions about risk management, assessment, impacts, and controls with respect to both technical and human assets.

• Page 4-1, 8 pages: Descriptive overview of the basic process for developing a security program. Included are discussions concerning the business case, staffing, and general project activities for building a cybersecurity program.

• Page 5-1, 25 pages: Descriptive overview of ICS security architectures. Included is a caution concerning the need for network design that facilitates security, with special attention given to the increasingly required link between ICSs and the corporate network. Excellent graphics and descriptions are provided that clarify common network architectures and security controls.


17

• Page 6-1, 47 pages: Descriptive overview of cybersecurity legislation and resulting risk management processes developed for use by governmental and other organizations. The material in this section is certainly useful for the development of cybersecurity policies (“What to do”), and offers references (typically in the NIST SP 800 series of documents) useful for the development of procedures (“How to do it”).

• Page A-1, 135 pages: Appendices that, in aggregate, provide a primer for cybersecurity. The appendices provide a desk-top reference for navigating the NIST SP 800 series. Appendix G is useful for guiding the establishment of relative baseline levels of security control “strength” for ICS cybersecurity program conditions and activities. It is contained in NIST SP 800-53 for “general” IT systems, and included here as a preliminary draft ICS overlay.

#3. ISO 27001: Information Security Management Standard

Organization ISO Release Date October 2013

Type Best Practice Page Count 29

Audience Upper- and mid-level leadership responsible for cybersecurity program organization and implementation

Content Focus

Note: Appendix A, Table A.1 is useful for creating a project plan for implementing capabilities required by the standard.

Applicability


✓ IT OT




Description

ISO 27001 provides requirements for establishing, implementing, maintaining, and continually improving an information security management system. The information security management system helps companies implement a framework for managing the security of their information assets including: financial information, intellectual property, and employee details, or information entrusted to them by customers or third parties. Information security management system implementation is influenced by the organization’s needs and objectives, security requirements, the organizational processes used and the size and structure of the organization. All of these influencing factors are expected to change over time. The information security management system applies a risk management process and gives confidence to interested parties that risks are adequately managed. ISO 27001 can be used by internal and external parties to assess the organization's ability to meet the organization’s own information security requirements. The order in which requirements are presented in ISO 27001 does not reflect their importance or imply the order in which they are to be implemented.

Commentary


18

The document specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in this international standard are generic and are intended to be applicable to all organizations, regardless of type, size or nature. The document is organized in sections 4 – 10 as “domain” requirements:

• Organization

• Leadership/Commitment

• Support

• Operation

• Performance Evaluation The requirements in the document text are presented at multiple levels of abstraction, some of which are not readily assessable for compliance (e.g., select appropriate information security risk treatment options, taking account of the risk assessment results) without additional clarification.

Other requirements are highly prescriptive and detailed. The requirements are a mix of “what to do” and “how to do it.” Appendix A, Table A.1 provides detailed standards compliance instructions, many of which require organization-specific interpretation, and therefore, experienced and knowledgeable assessment for compliance. Interpretation is needed to map the domains presented in the text to the domains in the Table, which are:

• Information security policies

• Organization of information security

• Human resource security

• Asset management

• Access control

• Cryptography

• Physical and environmental security

• Operations security

• Communications security

• System acquisition, development and maintenance

• Supplier relationships

• Information security incident management

• Information security aspects of business continuity management

• Compliance

#4. C2M2

Organization DHS and DOE Release Date February 2014


Audience Executives, operational managers, support staff, and assessors (facilitators). The authors recommend focus on content as follows:

• Executives – Sections 1, 2

• Operational Managers – Sections 1, 2, 3

• Support Staff/Assessors – All sections 1, 2, 3, 4, 5


19

Content Focus

Notes: Directly-applicable implementation material begins on page 15

Applicability


✓ IT ✓ OT




Description

The C2M2 helps organizations of all sectors, types, and sizes evaluate and make improvements to their cybersecurity programs. The C2M2 model is used to: strengthen cybersecurity capabilities, enable organizations to effectively and consistently evaluate and benchmark cybersecurity capabilities, share knowledge, best practices, and relevant references across organizations and enable organizations to prioritize actions and investments. The C2M2 is designed for use with a self-evaluation methodology and toolkit for an organization to measure and improve its cybersecurity program. The C2M2 model can also inform the development of a new cybersecurity program. The model content is presented at a high level of abstraction, so that it can be interpreted by organizations of various types, structures, sizes, and industries. Broad use of the model by a sector can support benchmarking of the sector’s cybersecurity capabilities. These attributes also make the C2M2 an easily scalable tool for implementing the NIST Framework.

Commentary

C2M2 focuses on cybersecurity implementation and management practices for IT and OT systems, and assumes that the reader understands the difference. It is to be used to strengthen, organize, and evaluate cybersecurity organization, to facilitate information sharing, and to prioritize actions and investments. It is descriptive instead of prescriptive, and is presented at a high level of abstraction making it more applicable to understanding than to implementation, even though it states it is intended for implementation. An experienced software engineer might recognize the pattern of the C2M2 approach/concept and document after similar materials offered by Carnegie Mellon University’s (CMU’s) Software Engineering Institute’s (SEI’s) Capability Maturity Model Integration (CMMI). The document states, “[a] maturity model is a set of characteristics, attributes, indicators, or patterns that represent capability and progression in a particular discipline.” Further, such a model is used to provide a benchmark for evaluative purposes and to measure progression toward a defined set of capabilities. The model offers 10 domains (p. 7) to organize proposed essential capabilities or best practices. It also offers a scaling method for establishing the assessed capabilities state (p. 9), and a detailed process for using the model (p. 15). Beginning on page 19, the document presents each of the 10 modeled domains in a uniformly logical manner:

• Purpose of the domain


20

• Reasoning about the importance of the domain to cybersecurity

• Capabilities domain implementation examples (sidebar blue text box)

• Best practice behaviors/capabilities commonly attributed to the domain

• Assignment of the behaviors/capabilities to a modeled level of proficiency achievement (a measurement scale)

The detailed presentation of the domains is contained in 30 pages of the 48-page document. The balance of the 71-page document provides references, a tabular glossary, a list of acronyms, and notices. The document is very well organized, and the concepts are thoughtful and clearly presented. It is useful on a number of levels:

• Development of a user-specific cybersecurity implementation model

• Development of a cybersecurity program/project implementation plan

• Development of a risk assessment and risk management plan

• Development of cybersecurity policies and procedures

• Development of a corporate cybersecurity readiness gauging method

#5a. Industrial Network and System Security (ISA 62443-2.1) Establishing an industrial automation and control system security program

Organization ISA/IEC Release Date November 2011


Audience Mid to lower-level management and policy makers

Content Focus

Notes: Requirements for each element in the document provide specific implementation guidance and are distributed throughout the content. Based on experience and judgment, this assessor allocates 40% of the document to implementation-focused materials, and 60% to understanding-focused materials. This distribution can be honestly argued 20 percentage points in either direction.

Applicability


IT ✓ OT

✓ Commercial Government



Description

This document provides an overview of the OT cybersecurity domain and detailed cybersecurity management fundamentals as organized in 3 categories:

• Risk recognition/analysis

• Addressing or reducing risk using a cybersecurity management system

• Monitoring risk conditions using a cybersecurity management system, and iteratively improving the system based on system-induced learning

The document further details (decomposes) each category into “elements”. The content contained under each element is further categorized as…

• The objective of the element;


21

• A description of the element;

• The reason that the element is included in the treatment presented; and,

• The requirements of the element.

Commentary

Possible uses of the document include policy development, procedure development, best practice implementation recommendations, and personnel leadership/guidance. The document is a quick and useful read as a catalogued reference document (with an outstanding glossary of terms), by looking up a cybersecurity category of interest, reading the objective/description/rationale text, and adapting the presented requirements to the special implementation case at hand. The requirements presented can be used both as case-specific policy requirements and pointers to detailed requirements implementations. The document neither intends to, nor provides procedures. It focuses on “what to do”, and leaves “how to do it” to the reader.

#5b. Industrial Network and System Security (ISA 62443-2.4) Security Program Requirements for IACS Service Providers



Audience Mid- to lower-level management and policy-makers, security system architects, procurement officers, security system designers, and staff responsible for justifying approvals for capital authorizations for security systems

Content Focus

Notes: Table A.1 is focused on implementation, and the implementation percentage may be as high as 90%.

Applicability


IT ✓ OT




Description

This document contains two sections (Sections 4 and 5) that provide guidance for service providers (suppliers to the industry), as well as guidance for owners and operators engaged in cybersecurity and software supply chain management. As is typical of IEC 62443 documents, these content-rich sections are preceded by useful lists of terms, definitions, abbreviations, and acronyms.

Commentary

Section 4 of this document describes how service providers (including integration and maintenance providers) and asset owners might practically apply the contents of the documents. It also provides a section on how the guidance might be applied to direct negotiations between owners/operators and services providers (sec. 4.1.3). At the end of the section, Table 1 compares 62443 capability levels (1-4) to long-established SEI CMMI capability levels with explanations. Practitioners of CMMI might find this particularly useful as frame of reference when working to grasp the 62443 model. Section 5 begins with instructions for comprehending the requirements content delivered in Annex A, Security requirements, Table A.1. This table is characterized by columns, that in turn contain:

• A requirements alpha-numeric ID


22

• A basic requirement (BR) or requirement enhancement (RE) designation

• A functional area arguably impacted by the requirement

• A specific topic addressed by the requirement

• A determination of whether or not the requirement is evidenced by documentation

• A comprehensive description of the requirement

• A rationale for the requirement Table A.1 begins on page 22 and continues through page 85 (64 pages). It provides highly detailed information useful for procurement requirements, system architecture development, system design, policy development, and system justification.

#5c. Industrial Network and System Security (ISA 62443-3-3) System Security Requirements and Security Levels



Audience Mid to lower-level management, IACS cybersecurity architects and designers, and policy-makers

Content Focus

Applicability


IT ✓ OT




Description

This document extends the model presented in IEC 62443-1-1 that describes detailed technical control system requirements (SRs) that are associated with 7 foundational requirements (FRs):

• Identification and authentication control (IAC)

• Use control (UC)

• System integrity (SI)

• Data confidentiality (DC)

• Restricted data flow (RDF)

• Timely response to events (TRE)

• Resource availability (RA)

The document also provides a set of 4 security control system capability security levels (SLs) for each FR listed above. As the SL increases from SL-1 through SL-4, asserting an increase in overall control system security when implemented. Annex A in the document provides a full explanation of the “SL vector” concept.

The document is organized into FR sections, each of which provide:

• An FR number and name o Purpose description o SL level descriptions recommended for the FR


23

o Reason for inclusion (rationale) o Multiple (in most cases) SRs for each FR, with an SR number and name

▪ SR requirement description ▪ SR rationale description ▪ SR supplemental guidance ▪ SR requirements “enhancements” (recommended best practices)

Commentary

The system for organizing the multiple nested categories is complex and difficult to follow at times, but complexity is arguably justified by the complexity of the subject matter. The guidance is highly detailed dense. Nevertheless, the rationale and supplemental guidance sections are useful for gaining a rich understanding of cybersecurity practices, and provides useful implementation education and guidance.

#6. SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations



Audience Diverse federal audience of information system and information security professionals

Content Focus

Applicability


✓ IT OT

Commercial ✓ Government

✓ U.S. International

✓ Facilities Offshore Vessels

Description

SP 800-53 provides guidelines for selecting and specifying security controls for organizations and information systems supporting the executive agencies of the federal government to meet the requirements of Federal Information Processing Standard (FIPS) Publication 200, Minimum Security Requirements for Federal Information and Information Systems. The guidelines apply to all components of an information system that process, store, or transmit federal information. They were developed to achieve more secure information systems and effective risk management within the federal government. Per the introduction, they do this by:

• Facilitating a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems and organizations

• Providing a stable, yet flexible catalog of security controls to meet current information protection needs and the demands of future protection needs based on changing threats, requirements, and technologies

• Providing a recommendation for security controls for information systems categorized in accordance with FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems

• Creating a foundation for the development of assessment methods and procedures for determining security control effectiveness


24

• Improving communication among organizations by providing a common lexicon that supports discussion of risk management concepts

The publication also: (1) provides a set of information security program management controls that are typically implemented at the organization level and not directed at individual organizational information systems; (2) provides a set of privacy controls based on international standards and best practices that help organizations enforce privacy requirements derived from federal legislation, directives, policies, regulations, and standards; and (3) establishes a linkage and relationship between privacy and security controls for purposes of enforcing respective privacy and security requirements which may overlap in concept and in implementation within federal information systems, programs, and organizations.

Commentary

This document is a general-purpose guideline governing the selection and specification of security controls that support executive agencies in the US federal government. It is general purpose in that it applies to all components of an information system that processes, stores, or transmits federal information. The organization of the document is as follows:

• Chapter 1 describes why security controls are needed within executive agencies, applicability, and organizational responsibilities

• Chapter 2 provides a high-level treatment of: o A recommended structure of 17 security control “Families” (with abbreviated

identifiers), subcategorized as 3 security control “Classes”, including management, operational, and technical classes.

o A security control structure consisting of three components: (1) a specific recommended security capability, (2) related supplemental guidance, and (3) capability enhancements to security capability “strength”.

o Common, information system security control best practices including buy-in and ownership, management practices, concepts in security control assurance, design tips, and system evolution.

• Chapter 3 discusses formal security risk recognition and assessment practices in support of developing a 9-phase security program design and implementation project. The chapter frequently cites FIPS 199 as an implied canonical reference.

• Appendix D (Minimum Security Controls Summary – 6 pages) is useful for establishing initial control levels (low, moderate, high) for the structure of 17 security control categories (not to be confused with the aforementioned 17 security control “Families” – they are different).

• Appendix F (Security Control Catalog – 64 pages) presents information for developing policies and possibly implementation checklists useful as basic capabilities requirements for securing an IT system, with some cross-cutting applicability to OT systems. It is exactly as stated, a “catalog” for possibly application security control methods and mechanisms for IT systems. The control baseline (recommended initial L/M/H level) for the controls presented in Appendix F are mapped to the 17 security control categories (and detailed controls) listed in in Appendix D.

The primary use of this document is for the development of an IT system security program, architecture, and capabilities specification for development or procurement.

#7. Instruction 8500.01, Cybersecurity

Organization Department of Defense (DoD) Release Date March 2014

Type Policy Page Count 59


25

Audience Senior DoD officials with cybersecurity responsibility (e.g., CIO)

Content Focus

Applicability


✓ IT OT

Commercial ✓ Government


✓ Facilities Offshore Vessels

Description

Cybersecurity ensures that IT can be used in a way that allows mission owners and operators to have confidence in the confidentiality, integrity, and availability of IT and DoD information, and to make choices based on that confidence. The Defense cybersecurity program supports DoD’s vision of effective operations in cyberspace where:

• DoD missions and operations continue under any cyber situation or condition

• The IT components of DoD weapons systems and other defense platforms perform as designed and adequately meet operational requirements

• The DoD Information Enterprise collectively, consistently, and effectively acts in its own defense

• DoD has ready access to its information and command and control channels, and its adversaries do not

• The DoD Information Enterprise securely and seamlessly extends to mission partners

Commentary

This is a DoD-centric document that lays establishes DoD’s cybersecurity program and lays out clear internal responsibilities to protect and protect DOD IT systems. It has very limited applicability to this project’s analytical scope.

#8. Transportation Systems Sector Cybersecurity Framework Implementation Guidance

Organization DHS Release Date June 2015 Page Count 16

Audience Upper- to mid-level cybersecurity management, and incident response analysis teams aiming to advise cybersecurity management on resource deployment to “maturity domains” as offered by the U.S. Computer Emergency Readiness Team (US-CERT) Cyber Resilience Review (CRR) or the CMMI.

Content Focus

Notes: The tabular analysis techniques offer subjective implementation guidance to personnel providing post incident/breach resource redeployment advice to senior executives.

Applicability


✓ IT ✓ Commercial ✓ U.S. ✓ Facilities


26

✓ OT ✓ Government International ✓ Offshore ✓ Vessels

Description

This reference provides guidance to the Transportation Systems Sector guidance, resource direction, and a directory of options to assist a TSS organization in adopting the NIST Framework. The implementation guidance may be used by organizations to accomplish the following:

• Characterize their current and target cybersecurity posture.

• Identify opportunities for evolving their existing cybersecurity risk management programs.

• Recognize existing sector tools, standards, and guidelines that may support Framework implementation.

• Assess and communicate their risk management approach to both internal and external stakeholders.

This implementation guidance can be incorporated into an organization’s culture regardless of the organizations current cybersecurity maturity level. For organizations that do not have a formal cybersecurity risk management program, this implementation guidance can help them to comprehend, evaluate, and establish the organizations cyber risk priorities. For those organizations that have a formal risk management office or program in place, this guidance provides additional mechanisms to review existing programs and identify areas for improvement, while aligning current efforts to the NIST Framework.

Commentary

The paper recommends that an organization:

• Assess its technical and cultural vulnerabilities, as well as its security capabilities and implementations

• Assess external threat pertinence and resulting applicability to an organizational risk profile

• Establish protections based on references in an appendix: DHS Cyber Resilience Review, DOE C2M2 model, NIST 800-53/800-82, and ISO/IEC 27001:2013

This paper also reframes the NIST Framework with respect to five (5) DHS/TSS strategy goals:

• Define conceptual environment

• Increase voluntary participation

• Maintain cybersecurity awareness

• Enhance intelligence sharing

• Ensure sustained coordination and implementation Finally, the paper recommends (or offers as a sample) a subjective approach for adjusting enterprise “Maturity Indicator Levels” (MIL) to generate a level of Impact analysis should a breach occur. It bases adjustments on a post-incident analysis.

#9. The Guidelines on Cyber Security Onboard Ships

Organization Baltic and International Maritime Council (BIMCO)

Release Date February 2016

Type Best Practices Page Count 36

Audience Ship owners and operators

Content Focus


27

Notes: Approximately 10 of the 36 pages are implementable in that they provide a high-level description of generally accepted best practices and recommendations. These descriptions could be used to outline a cybersecurity program or policies. They are not uniformly useful for procedures in that they lack sufficient detail. 13 pages of appendices are provided for additional understanding of the cybersecurity environment, including the NIST Framework.

Applicability


✓ IT ✓ OT



Facilities Offshore

✓ Vessels

Description

This reference focuses on the unique issues facing the shipping industry onboard ships. The document offers guidance to ship owners and operators on how to assess their operations and put in place the necessary procedures and actions to maintain the security of cyber systems onboard their ships. That being said the document is not intended to provide a basis for auditing or vetting the individual approach to cybersecurity taken by companies and ships. The document explores the measures to reduce cybersecurity risk which include:

• How to raise awareness of the safety, security and commercial risks for shipping companies if no cybersecurity measures are in place

• How to protect shipboard OT and IT infrastructure and connected equipment

• How to manage users, ensuring appropriate access to necessary information

• How to protect data used onboard ships, according to its level of sensitivity

• How to authorize administrator privileges for users, including during maintenance and support on board or via remote link

• How to protect data being communicated between the ship and the shore side

Commentary

This paper focuses on cybersecurity for cargo and passenger vessels, and therefore limits its cybersecurity discussion to protecting ship handling, cargo management, and passenger support system as OT systems. The paper presents a graphical model that decomposes and combines the five NIST steps as in the graphic below.

ProtectIden fy Detect Respond Recover

Iden fyVulnerabili es

Iden fyThreats

AssessRisks

ProtectandDetect

EstablishCon ngencyPlans

RespondtoIncidents ?

NIST

BIMCO


28

The paper provides a high-level description of its model; however, the content only loosely follows the model as it describes the cybersecurity best practices and recommendations in the text.

#10. Interim Guidelines on Maritime Cyber Risk Management

Organization IMO Release Date June 2016


Audience Maritime risk managers

Content Focus

Applicability


✓ IT ✓ OT




Description

These guidelines provide high-level recommendations for maritime cyber risk management. They recognize that risk management has traditionally been focused on operations in the physical domain, but greater reliance on digitization, integration, automation and network-based systems has created an increasing need for cyber risk management in the shipping industry. It provides recommendations that can be incorporated into existing risk management processes. In this regard, it is complementary to IMO’s published safety and security management practices.

The document is intended for all organizations in the shipping industry and is designed to encourage safety and security management practices in the cyber domain. It recognizes that no two organizations in the shipping industry are the same; so, they are expressed in broad terms for widespread application.

It presents the functional elements that support effective cyber risk management, which all should be continuous and concurrent, including:

• Identify: Define personnel roles and responsibilities for cyber risk management and identify the systems, assets, data and capabilities that, when disrupted, pose risks to ship operations

• Protect: Implement risk control processes and measures, and contingency planning to protect against a cyber event and ensure continuity of shipping operations

• Detect: Develop and implement activities necessary to detect a cyber event in a timely manner

• Respond: Develop and implement activities and plans to provide resilience and to restore systems necessary for shipping operations or services impaired due to a cyber event

• Recover: Identify measures to back-up and restore cyber systems necessary for shipping operations impacted by a cyber event

Commentary

The paper recognizes and elevates cybersecurity as a fundamental consideration for the maritime industry. It extends the coverage of cybersecurity beyond ICSs to bridge, passenger servicing and management systems, and passenger facing public networks. This paper is an endorsement of the importance of maritime cybersecurity and a pointer to useful cybersecurity program planning references. It includes very brief treatment of:


29

• The difference between IT and OT systems

• The recognition of increasing computerized communications as an inevitability in the maritime industry

• The risk to security presented by both malicious and benign actions/activities

• The connected nature of vulnerabilities

• The mutating nature of threats

• The multiplicity of control options The paper specifically references the NIST Framework for use as a cybersecurity planning/design model. It also points the reader to several other references (e.g., BIMCO, ISO/IEC 27001, and the NIST framework).

#11. Guidance Notes on the Application of Cybersecurity Principles to Marine and Offshore Operations

Organization ABS Release Date February 2016


Audience Maritime and offshore organizations implementing cybersecurity systems on ships, platforms, vessels of any type, and support facilities.

Content Focus

Note: Primarily useful for incrementally (Basic, Developed, Integrated) establishing a set of IT capabilities needed to support the development of a sophisticated OT security program.

Applicability

Systems Stakeholders Geography Asset Types

✓ IT ✓ OT




Description

ABS provides actionable guidance that clearly delineates and differentiates cybersecurity implementation strategies and tactics for IT and OT environments in the maritime and offshore industry. Included are checklists conformant to OT-specific standards and tested on marine and offshore assets to help owners and operators identify gaps in their cyber cybersecurity protections. It also describes a method for evaluating cybersecurity risk management practices that helps owners gauge operational preparedness/readiness with regard to cybersecurity. The availability of actionable guidance, checklists, and a readiness/capability score described in the ABS guidance provides an owner with a uniform reference by which cybersecurity due diligence can be performed and documented.

Commentary

This document presents a maritime and offshore specific reference model for establishing organizational cybersecurity capabilities. Key content within the reference include:

• Extended definitions of high-level terms often used in cybersecurity discussions, including definitions of IT, OT, and smart assets.

• The structure of the ABS CyberSafety set of guidance documents.


30

• A graphical (page 7) and descriptive model for progressive organizational development of cybersecurity capabilities: basic (9 categories), developed (14 categories), and integrated (14 categories).

• Page 9, 17 pages: Basic capabilities are listed and illuminated by key cybersecurity capabilities and/or behaviors that characterize an organization that is beginning to implement security protections.

• Page 17, 11 pages: Developed capabilities are listed and illuminated by key cybersecurity capabilities and/or behaviors that characterize an organization that has developed a fully operational security system and support team.

• Page 28, 12 pages: Integrated Capabilities are listed and illuminated by key cybersecurity capabilities and/or behaviors that characterize an organization that has linked it security protection systems throughout the organization as part of the corporate culture, and includes proactive protective analytics and management procedures.

Each capability category is followed by a set of 5-10 implementation outcomes. The outcomes are useful examples of protective processes from which security policies may be developed. The outcomes under each capability category are following by an instructive explanation of the purpose behind the outcomes, and references for additional explanation. It is a scholarly paper useful for both IT and OT environments.

#12. COBIT 5 A Business Framework for the Governance and Management of Enterprise IT

Organization Information Systems Audit and Control Association (ISACA)

Release Date April 2012


Audience Upper (not executive) to mid-level managers responsible for building an IT organization and infrastructure in medium to large scale enterprises

Content Focus

Note: The content is primarily conceptual in nature. Applicability


✓ IT OT




Description


31

COBIT 5 provides a comprehensive framework that assists enterprises in achieving their objectives for the governance and management of enterprise IT. Simply stated, it helps enterprises create optimal value from IT by maintaining a balance between realizing benefits and optimizing risk levels and resource use. COBIT 5 enables IT to be governed and managed in a holistic manner for the entire enterprise, taking in the full end-to-end business and IT functional areas of responsibility, considering the IT-related interests of internal and external stakeholders. COBIT 5 is generic and useful for enterprises of all sizes, whether commercial, not-for-profit or in the public sector. It is based on five key principles for governance and management of enterprise IT:

• Principle 1: Meeting Stakeholder Needs

• Principle 2: Covering the Enterprise End-to-end

• Principle 3: Applying a Single, Integrated Framework

• Principle 4: Enabling a Holistic Approach

• Principle 5: Separating Governance from Management COBIT 5 provides the next generation of ISACA’s guidance on the enterprise governance and management of IT. It builds on more than 15 years of practical usage and application of COBIT by many enterprises and users from business, IT, risk, security and assurance communities.

Commentary

The document describes a reference model and method for building an IT organization and architecture. It is not highly pertinent to maritime and offshore cybersecurity, except that a rigorous, well-documented IT architecture is foundational to a successful cybersecurity program. The chapters are a tutorial on the COBIT concept for creating and managing a rigorous and sophisticated IT infrastructure within an enterprise. Little specific treatment is given to security, but it is acknowledged in the materials. The appendices provide structured implementation templates and best practices for the COBIT 5 architectural reference model. The model is heavy for smaller organizations. The document is instructive for general IT use and can arguably be applied to industrial OT systems through interpretation.

#13. Top 20 CSCs

Organization Council on Cyber Security (CCS) Release Date August 2016


Audience High- to mid-level management and implementation staff

Content Focus

Note: Very useful for IT and OT security management endeavors. Applicability


✓ IT ✓ OT




Description

The CSCs is an international community activity to:


32

• Share insight into attacks and attackers, identify root causes, and translate that into classes of defensive action

• Document stories of adoption and the use of tools to solve problems

• Track the evolution of threats, the capabilities of adversaries, and current vectors of intrusions

• Map the controls to regulatory and compliance frameworks and bring collective priority and focus to them

• Share tools, working aids, and translations

• Identify common problems (like initial assessment, building implementation roadmaps) and solve them as a community instead of alone

The activities ensure that the CSCs are not just another list of good things to do, but a prioritized, highly focused set of actions that have a community-wide support network to make them implementable, usable, scalable, and compliant with all industry or government security requirements.

Top organizational experts pool their extensive first-hand knowledge from defending against actual cyber-attacks and develop a consensus list of the best defensive techniques to prevent or track them. This ensures that the CSCs are the most effective and specific set of technical measures available to detect, prevent, respond, and mitigate damage from the most common to the most advanced of those attacks.

Commentary

This is an excellent reference document. The document is a compendium of compiled best practices, tips, and hints provided by security practitioners from every part of the ecosystem, every role in the security management field, and many private and public sectors. The recommended best practices are ostensibly field-tested, and clearly stated in 20 implementation domains. The domains provided are at a level of abstraction to support high- to mid-level management understanding and hands-on implementation. The document is adaptable to OT security policy and procedure development, system design, and implementation. The appendix is a useful listing of attack types and criticality gauge numbers.

#14. SP 800-160. Systems Security Engineering

Organization NIST Release Date May 2016


Audience Systems engineering personnel at all levels, software engineering personnel at all levels, risk management/governance professionals, test/verification and validation (V&V) assessment and inspection personnel, security administrators, security product and services suppliers, and institutions of higher learning

Content Focus

Notes: Chapter 3 is arguably implementation guidance, as are the appendices. The page count for Chapter 3 (146 pages), plus the appendices (90 pages) is 236 pages. The authors indicate this document is actionable. Therefore, the implementation metric is set at 90%.

Applicability



33

✓ IT ✓ OT




Description

NIST SP 800-160 introduces the rigor of the natural sciences to cybersecurity. The publication applies more methodical, engineering-based approaches to information security solutions to address the dynamic, complex, and interconnected systems and systems-of-systems, such as the Internet of Things (IoT), that run the modern world. The level of trust that an organization can place in a system is dependent on how that system is expected to perform across a range of activities and how it actually performs in reality. The framework provided unites expectations, constraints, limitations, and uncertainties into security concerns and aids the user in addressing those concerns in a manner that builds confidence that the system will function as intended across the spectrum of disruptions, hazards, and threats.

It details the engineering-driven processes necessary to develop more defensible, resilient, and survivable systems. It aims to focus on imbuing trust and security in systems in consideration of the difficulties and challenges presented by reality through the implementation of a lifecycle driven, applied system engineering framework that is built upon established standards and processes. It has the following objectives:

• Formalize a disciplined basis for security engineering in terms of principles, concepts, and activities

• Promote a common security development mentality that applies to any system, regardless of its scope, size, complexity, or stage in the lifecycle.

• Provide considerations and demonstrations of the ways that principles, concepts, and activities can be applied to the systems engineering process.

Commentary

This document gives evidence that the understanding of cybersecurity is maturing and evolving rapidly. It is an exceptional tutorial on the dependencies of system security on robust system engineering, and characterizes cybersecurity as a smaller subset of systems security engineering (SSE). This is an important and possibly pivotal recognition that sets this document apart from most others reviewed during this project. The 6-page Forward and 7-page Introduction should be required reading for personnel being introduced to cybersecurity. Finally, the document provides a 129-page catalog of security system life cycle processes (i.e., SSE best practices, desired outcomes, and supporting rationale) that are user-friendly implementation information.

The document is organized clearly and simply in 3 chapters:

• Chapter 1 discusses the purpose of the publication, which can be co-opted and tailored as a mission statement by any sophisticated security organization. This is highly-recommended reading applicable to this project.

• Chapter 2 discusses foundational concepts in systems engineering, relates those concepts to system integrity, and draws the connections to system trustworthiness and security.

• Chapter 3 discusses application of SSE to system lifecycle processes. It identifies 30 system lifecycle processes that are categorized in 4 process families: — Agreement processes (2) — Organization process-enabling processes (6) — Technical management processes (8)


34

— Technical processes (14)

It is interesting to note that over 50% of the processes are managerial in nature, yet are assigned to the SSE domain. This engineering/management is a defining characteristic of SSE. The processes are listed as shown below.

The chapter then provides the following information for each process in a consistent, uniform, easily readable format:

1) Purpose: The primary goals and objectives of each process. 2) Outcomes: The intended/anticipated outcomes derived from the implementation of

each process. 3) Activities and Tasks: The work to be performed to actualize each process. 4) Elaborations: Background information that provides practical guidance and rationale for

Activities and Tasks.

• Appendix D: This appendix provides 4 useful tables summarizing each of the families of system security life cycle processes detailed in chapter 3.

• Appendix E: This appendix is a detailed position description of a systems security engineer.

• Appendix F: This appendix provides a clear taxonomy of 32 security (system) design principles, with supporting explanations of each principle.

• Appendix G: This appendix provides a clear tutorial of sound SSE principles that frame security system activities as being guided by those principles.

This document is exceptional in its content and presentation. It is highly recommended as a canonical reference document for all cybersecurity professional and practitioners.

#15. Cyber Strategy

Organization USCG Release Date June 2015 Page Count

Organization USCG Release Date June 2015


Audience USCG command and line staff, commercial providers supporting USCG cyber providers, and civilian oversight and governance organizations

Content Focus

Note: This is a strategic document not intended for implementation. It provides useful insights into the USCG’s operational and protective challenges with respect to cyber space.


35

Applicability


✓ IT ✓ OT




Description

This strategy recognizes the USCG must fully embrace cyberspace as an operational domain. The strategy aligns with the DHS and DoD plans and will guide the service’s efforts in the cyber domain for the next 10 years. This reference identifies three distinct strategic priorities crucial to the service’s mission:

• Defending Cyberspace: To ensure mission success as effectively and efficiently as possible, the USCG will protect information infrastructure and build a more resilient USCG network.

• Enabling Operations: Cyberspace operations – both in and out of USCG information and communications networks and systems – help detect, deter, disable and defeat adversaries. Robust intelligence, law enforcement and maritime and military cyber programs are essential to the effectiveness of USCG operations and deterring, preventing and responding to malicious activity targeting critical maritime infrastructure.

• Protecting Infrastructure: The MTS, and its associated infrastructure, is vital to America’s economy, security and defense. While cyber systems enable the maritime transportation system to operate with unprecedented speed and efficiency, those same systems also create potential vulnerabilities

The final two sections of the document discuss the long view of a successful cyber strategy and conclusions. The document articulates its roles in sustaining a cyber operational advantage and leadership in protecting maritime critical infrastructure.

Commentary

This document offers the reader:

• A view of the USCG’s historical and current role in protecting US waters in both a military and law enforcement role

• A review of the challenges presented by cyber threats

• A description of its strategic priorities and rationale behind those priorities

• A background discussion of USCG cyberspace operations and responsibilities

• A detailed statement of the USCG’s cyber goals, supporting objectives, and specific measureable execution strategies

#16. National Strategy for Trusted Identities in Cyberspace (NSTIC)

Organization White House Release Date April 2011


Audience Public and private sector enterprises, individuals, organizations, networks, services, and devices involved in online transactions

Content Focus


36

Note: Identity management is a key component of marine and offshore cybersecurity that is commonly only addressed in terms of access control. This document expands that concept to broader identity trust that is critical to cybersecurity.

Applicability


✓ IT ✓ OT




Description

The NSTIC is an initiative to improve the privacy, security and convenience of sensitive online transactions through collaborative efforts with the private sector, advocacy groups, government agencies, and other organizations. The strategy casts a vision of an online environment where individuals and organizations can trust each other because they identify and authenticate their digital identities and the digital identities of organizations and devices. It offers, but does not mandate, stronger identification and authentication while protecting privacy by limiting the amount of information that individuals must disclose. The strategy was developed with input from the private sector, including organizations representing 18 business groups, 70 nonprofit and federal advisory groups, and comments and dialogue from the public. It has four guiding principles:

• Privacy-enhancing and voluntary

• Secure and resilient

• Interoperable

• Cost-effective and easy to use

Commentary

The strategy describes an identity ecosystem framework in which an overarching set of interoperability standards, risk models, privacy and liability policies, requirements, and accountability mechanisms provide structure to extend broad identity trust to all entrants/subscribers, thereby reducing the burden of identity proof at the user interfaces. The document also promotes a baseline set of standards and policies that apply to all of the participating trust frameworks. This baseline is more permissive at the lowest levels of assurance, to ensure that it does not serve as an undue barrier to entry, and more detailed at higher levels of assurance, to ensure that participants have adequate protections.

The goals of the identity ecosystem strategy are to: 1. Develop a comprehensive Identity Ecosystem Framework 2. Build and implement interoperable identity solutions 3. Enhance confidence and willingness to participate in the Identity Ecosystem 4. Ensure the long-term success and viability of the Identity Ecosystem

Clear subordinate strategy objectives are also contained in the document. The final pages of the document are dedicated to a call-to-action for the sectors to be services, including the private and government sectors. In that rigorous identity management combined with organizational and asset-centered protections are fundamental to cybersecurity, marine and offshore enterprises are well-advised to consider themselves major players in the private sector of the identity ecosystem.

#17. Maritime Bulk Liquids Transfer (MBLT) Cybersecurity Framework Profile


37

Organization NIST Release Date November 2016


Audience Executives, risk managers, cybersecurity professionals, vessel and facility operators, and others having a cybersecurity role within the MLBT industry

Content Focus

Notes: The tables, figures and appendices are implementation materials. The references for the NIST Subcategories are helpful to support regulatory compliance questions, but give evidence to the potentially burdensome nature of implementing a cybersecurity program and system – hundreds to thousands of pages of support/reference information.

Applicability


✓ IT ✓ OT




Description

This document is a NIST Cybersecurity Framework industry-specific profile for the MBLT industry. As expected, the document closely follows the NIST Framework reference model, and presents objectives and approaches unique to the MBLT industry. The content material is presented in 6 brief sections, and relies primarily on tables and graphics presented in the supplemental materials to provide details for the MBLT Profile. It is appropriate to note that the MBLT industry needs to integrate assessment, mitigation, and recovery activities and protections for its interdependent IT and OT systems. The document also notes that it works closely with the USCG under Code of Federal Regulations (CFR) 33 CFR 154, 155, and 156.

Commentary

This document’s 6 content sections are organized as follows:

• Section 1: Foundations of the MBLT Profile in the NIST Framework, 8 profile mission objectives, and the document layout

• Section 2: Recognition of the cyber threat, the importance of cybersecurity in the MBLT domain, and the importance of an IT/OT integrated approach to both threats and security

• Section 3: How the NIST Framework was used to structure the MBLT Profile

• Section 4: The industry-specific determinations and criteria that were used to tailor the general NIST Profile map to the MBLT industry, including specific guidance documents and regulatory references

• Section 5: A very brief, general plan to guide industry users in the application of the Profile to their enterprises

• Section 6: A tabular mapping of NIST Framework’s categories and sub-categories of security practices to the MBLT’s 8 mission objectives, and MBLT implementation priorities for those categories and subcategories

The balance of the document contains detailed information for:

• Implementation cybersecurity program planning

• Federal regulations (i.e., 33 CFR 154, 155, and 156)

• A table of specific recommended MBLT Profile implementation activities, with anticipated outputs, and a table of explaining the NIST Framework’s subcategories of security practices


38

Figure 3 summarizes the literature review described in Table 4, where each reference is plotted on a

matrix indicating its type (policy, best practice, standard, or framework) vs. its applicability to IT, OT, or

both. The size of each reference’s donut chart indicates its page count and the color indicates the

reference’s percentage focus on implementation (orange) vs. understanding (blue). References that

explicitly address maritime issues are identified with an anchor icon.


39

Figure 3. Literature Review Summary


40

6. NIST Framework Core Mapping As mentioned in Section 4, the NIST Framework is the central reference for this project. The Framework

was released in February 2014 and consists of three parts: Framework Core, Framework Profile, and

Framework Implementation Tiers. The Framework Core provides a three-level hierarchy of (1)

functions, (2) categories, and (3) subcategories that describe common activities for managing

cybersecurity risk. Table 6 introduces the first 2 levels of the hierarchy.

Table 6. NIST Framework Functions and Categories

Function Category

Identify (ID) ID.AM - Asset Management

ID.BE - Business Environment

ID.GV - Governance

ID.RA - Risk Assessment

ID.RM - Risk Management Strategy

Protect (PR) PR.AC - Access Control

PR.AT - Awareness and Training

PR.DS - Data Security

PR.IP - Information Protection Processes and Procedures

PR.MA - Maintenance

PR.PT - Protective Technology

Detect (DE) DE.AE - Anomalies and Events

DE.CM - Security Continuous Monitoring

DE.DP - Detection Processes

Respond (RS) RS.RP - Response Planning

RS.CO - Communications

RS.AN - Analysis

RS.MI - Mitigation

RS.IM - Improvements

Recover (RC) RC.RP - Recovery Planning

RC.IM - Improvements

RC.CO - Communications

To help aid in implementation, NIST mapped six globally recognized standards for cybersecurity to the

Framework Core’s subcategories (Level 3) providing a cross reference from the Framework Core’s

subcategory to the associated chapter or section in the mapped reference. The six mapped references

were:

• ISO/IEC 27001 (Table 4, Reference #3)

• ISA 62443-2-1:2009 & ISA 62443-3-3:2013 (Table 4, Reference #5)

• NIST SP 800-53 (Table 4, Reference #6)

• COBIT 5 (Table 4, Reference #12)

• CCS CSC (Table 4, Reference #13)

The NIST Framework was intended to be a living document to be updated as industry feedback is

provided. The NIST Framework did not map every cybersecurity standard (e.g., C2M2, NIST SP 800-82)


41

available at that time, and since then, several additional relevant standards and guidance documents

have been released. So, the research team mapped six additional, globally-recognized references to the

Framework subcategories:

• NIST 800-82 (Table 4, Reference #2)

• C2M2 (Table 4, Reference #4)

• DHS TSS (Table 4, Reference #8)

• BIMCO (Table 4, Reference #9)

• IMO (Table 4, Reference #10)

• ABS (Table 4, Reference #11)

Table 7 provides a simple, summary heat map of the team’s mapping that illustrates the coverage of the

references. If the reference addresses the requirements in the Framework Core subcategory, an “x” is

included in a green cell. If not, the gray cell is blank. The new references mapped by the team are in the

left, dark blue columns while the original NIST mapping are in the right, light blue columns.

Appendix A provides the detailed cross references from the Framework Core’s subcategories to the

associated chapter or section in the mapped references.

Table 7. Updated NIST Framework Core Mapping

Function

Category

Subcategory

New Mapping Original Mapping

IMO

BIM

CO

AB

S

C2

M2

NIS

T 8

00

-82

DH

S TS

S

CC

S C

SC

CO

BIT

5

ISA

62

44

3-2

-1

ISA

62

44

3-3

-3

ISO

/IEC

27

00

1

NIS

T SP

80

0-5

3

Communications

Asset Management

ID.AM-1 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.AM-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.AM-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.AM-4 ✓ ✓ ✓ ✓

✓ ✓

✓ ✓

ID.AM-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.AM-6 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Business Environment

ID.BE-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.BE-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.BE-3 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.BE-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.BE-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

Governance

ID.GV-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.GV-2 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.GV-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.GV-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

Risk Assessment

ID.RA-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.RA-2 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

ID.RA-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.RA-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓


42

Function

Category

Subcategory


IMO

BIM

CO

AB

S

C2

M2

NIS

T 8

00

-82

DH

S TS

S

CC

S C

SC

CO

BIT

5

ISA

62

44

3-2

-1

ISA

62

44

3-3

-3

ISO

/IEC

27

00

1

NIS

T SP

80

0-5

3

ID.RA-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.RA-6 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

Risk Management Strategy

ID.RM-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.RM-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

ID.RM-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓

Protect

Access Control

PR.AC-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AC-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

PR.AC-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AC-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AC-5 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

Awareness and Training

PR.AT-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AT-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AT-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AT-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.AT-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Data Security

PR.DS-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-6 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.DS-7 ✓ ✓

✓

✓

✓

✓ ✓

Information Protection Processes and Procedures

PR.IP-1 ✓

✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

PR.IP-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

PR.IP-6 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-7 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

PR.IP-8 ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-9 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.IP-10 ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓

PR.IP-11 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

PR.IP-12 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Maintenance

PR.MA-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.MA-2 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Protective Technology


43

Function

Category

Subcategory


IMO

BIM

CO

AB

S

C2

M2

NIS

T 8

00

-82

DH

S TS

S

CC

S C

SC

CO

BIT

5

ISA

62

44

3-2

-1

ISA

62

44

3-3

-3

ISO

/IEC

27

00

1

NIS

T SP

80

0-5

3

PR.PT-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.PT-2 ✓

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

PR.PT-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

PR.PT-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Detect

Anomalies and Events

DE.AE-1 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.AE-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.AE-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

DE.AE-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.AE-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Security Continuous Monitoring

DE.CM-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

✓

DE.CM-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.CM-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.CM-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.CM-5 ✓

✓ ✓ ✓ ✓ ✓ ✓

DE.CM-6 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.CM-7 ✓ ✓ ✓ ✓ ✓ ✓

DE.CM-8 ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

Detection Processes

DE.DP-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.DP-2 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

DE.DP-3 ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓

DE.DP-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

DE.DP-5 ✓ ✓ ✓

✓ ✓ ✓

✓ ✓

Respond

Response Planning

RS.RP-1 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

Communications

RS.CO-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.CO-2 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.CO-3 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.CO-4 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.CO-5 ✓ ✓ ✓ ✓ ✓ ✓ ✓

Analysis

RS.AN-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.AN-2 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

RS.AN-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.AN-4 ✓ ✓ ✓

✓ ✓

✓ ✓

Mitigation

RS.MI-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RS.MI-2 ✓ ✓ ✓ ✓ ✓

✓ ✓

RS.MI-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓


44

Function

Category

Subcategory


IMO

BIM

CO

AB

S

C2

M2

NIS

T 8

00

-82

DH

S TS

S

CC

S C

SC

CO

BIT

5

ISA

62

44

3-2

-1

ISA

62

44

3-3

-3

ISO

/IEC

27

00

1

NIS

T SP

80

0-5

3

Improvements

RS.IM-1 ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

RS.IM-2 ✓ ✓ ✓ ✓ ✓

Recover

Recovery Planning

RC.RP-1 ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Improvements

RC.IM-1 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

RC.IM-2 ✓ ✓ ✓ ✓ ✓ ✓

✓

Communications

RC.CO-1 ✓ ✓ ✓ ✓ ✓ ✓

RC.CO-2 ✓ ✓ ✓ ✓ ✓ ✓

RC.CO-3 ✓ ✓ ✓ ✓ ✓ ✓ ✓

7. Recommended Risk-based Performance Standards (RBPSs) There are many relevant widely recognized standards and best practices that are applicable to maritime

cybersecurity, but the sheer number of references can make it difficult for organizations to choose the

best option(s) for them. This section provides specific recommendations for owners/operators of

vessels and maritime facilities that are interested in pursuing the development of certification of a

cybersecurity program

The first factor to consider is the maturity of a company’s cybersecurity program, which the research

team has defined in three major categories:

1. Owner/operator has not yet developed a cybersecurity program

2. Owner/operator has implemented an IT cybersecurity program

3. Owner/operator has implemented an IT/OT cybersecurity program

The following three subsections recommend references for each of these categories, respectively.

7.1. Owner/Operator Has Not Yet Developed a Cybersecurity Program The following listed publications are recommended reading for organizations contemplating the

implementation of a cybersecurity program, but are not clear on how to begin. If justification of a

program is needed, these documents provide useful insights for program planners. At the executive

level, the introductions of the documents are useful for gaining a general understanding of the

importance and overall scope of a cybersecurity program. The content of these documents provides

guidance for structuring a program, without getting excessively detailed with respect to

implementation.

1. NIST Framework is designed for use as a strategic reference model and not an implementation

model. That is not to say that it cannot be used as an implementation guide – it can. It contains

sufficient general cybersecurity implementation content to fill that need. However, its structure


45

and relative simplicity are more suited to a broader understanding of the cybersecurity domain

at executive and senior management levels. The publication provides insights on security

system design goals/outcomes; program implementation coverage; an approach to comparative

analysis of a security implementation against a norm; and implementation baselines that

promote and encourage economic development and progressive improvement for a

cybersecurity program.

2. NIST SP 800-82 is arguably the canonical reference for control system cybersecurity in the

United States and is a primary resource globally. The length of the publication makes it difficult

to approach; however, it is exceptionally well-organized, and its information density is notable.

The four-page Executive Summary is beneficial for level-setting the natures of cybersecurity

issues and solutions. In addition, the appendices provide a useful desktop reference for

navigating the entire NIST SP 800 series.

3. NIST 800-160 gives evidence that understanding of the cybersecurity is maturing and evolving

rapidly. It is an exceptional tutorial on the dependencies of system security on robust system

engineering and characterizes cybersecurity as a smaller subset of “systems security

engineering,” or SSE. Although much of the NIST 800-160 presents implementation activities,

the six-page Forward and seven-page Introduction are recommended reading for all personnel

being introduced to cybersecurity.

4. NSTIC fills a gap in cybersecurity reference papers by introducing and defining an “Identity

Ecosystem.” Rigorous identity management of people and machines that are granted cyber

access to marine and offshore assets is arguably foundational to cybersecurity; however, the

topic receives limited attention in other publications. The publication provides a U.S. strategy

for establishing a cyber environment in which organizations can implement secure, efficient,

user-friendly, and plug-and-play identity solutions. NSTIC also describes an Identity Ecosystem

Framework in which “interoperability standards, risk models, privacy and liability policies,

requirements, and accountability mechanisms” can be implemented to improve identity trust to

all authorized users and reduce identity proof procedures at the user interfaces.

5. BIMCO publication focuses on cybersecurity for cargo and passenger vessels, and therefore

limits its cybersecurity discussion to protecting ship handling, cargo management, and

passenger support systems as OT systems. The document provides a high-level description of

generally accepted best practices and recommendations. These descriptions could be used to

outline a cybersecurity program or policy.

7.2. Owner/Operator Has Implemented an IT Cybersecurity Program The following list of references is recommended reading for organizations that have established an IT

cybersecurity program, but want additional information on extending the program to purpose-built OT

systems (e.g., ICSs). These organizations are advised to also review the references listed in Section 7.1,

as well as those listed below:

1. NIST SP 800-82* specifically differentiates industrial control systems from IT systems and

discusses security solutions for OT. The 67 pages of “implementable” information presented in

Appendix G describe OT-related security processes that are especially useful in “tailoring” and

may be needed to adjust robust IT security program to accommodate ICS security.

2. NIST 800-160* is an exceptional tutorial on the dependencies of system security on robust

system engineering and characterizes cybersecurity as a smaller subset of “systems security


46

engineering,” or SSE. The concepts and implementation guidance presented are useful for

strengthening an existing IT system security program or developing an OT security program.

3. ISO/IEC 62443-2-1 provides an overview of the OT cybersecurity domain and detailed

cybersecurity management fundamentals as organized as risk recognition/analysis, risk

reduction, risk monitoring, and improvement. It further details each category into objectives,

descriptions, reasons for inclusion, and requirements to support implementation activities. The

implementation guidance is useful for defining policies and scope for an OT security program.

*NIST 800-82 and 800-160 are to be reviewed in full, rather than just as introductory guidance as

recommended in Section 7.1.

7.3. Owner/Operator Has Implemented an IT/OT Cybersecurity Program If companies have already implemented an IT/OT cybersecurity program, but would like to determine

either the standard(s) to which they should certify their programs or best practices to which they should

assess their programs, there are a number of factors that should be considered when choosing which

standards and best practices to consider. These include, but are not limited to:

• Regulatory requirements

• Based in the U.S. or internationally

• Risk level

• Functions performed by the asset

• Extent of integration between IT/OT

• Level of IT/OT complexity

• Reliance on OT to perform safety-critical functions

The research team developed decision trees that present a series of yes/no questions related to these

factors. Answering these simple questions in sequence will categorize an asset and identify all

applicable (light-green cell and a gray circle) and recommended standards/best practices (bright-green

cell and a white checkmark). Non-applicable references are noted with a gray cell.

Figures 4 through 6 present the decision trees for U.S. maritime facilities, U.S. vessels regulated under

USCG MTSA, and international vessels regulated under IMO ISPS, respectively.


47

*Recommend supply chain-specific requirements (see Appendix B for details)

Figure 4. Recommended Performance Standards – Facility Decision Tree


48


Figure 5. Recommended Performance Standards – MTSA-Regulated Vessel Decision Tree


49


Figure 6. Recommended Performance Standards – ISPS-Regulated Vessel Decision Tree


50

8. Regulatory Oversight Based on the asset classes within the scope of the analysis, there are a number of Federal, International,

and state/local agencies responsible for oversight of industry’s safety and/or security programs. Table 8

lists the relevant Federal and international agencies and briefly describes their mission.

Table 8. Federal and International Regulatory Agencies

Agency Mission

USCG In the execution of its Marine Safety mission, the USCG provides

clear and timely regulations, policy and direction to maritime

stakeholders to achieve maritime safety, maritime security and

environmental stewardship.

Bureau of Safety &

Environmental

Enforcement (BSEE)

BSEE is responsible for promoting safety, protecting the

environment, and conserving resources offshore through

regulatory oversight and enforcement.

DHS ISCD DHS ISCD oversees the Chemical Facility Anti-Terrorism Standards

(CFATS) program which identifies and regulates high-risk chemical

facilities to ensure they have security measures in place to reduce

risks.

Department of

Transportation (DOT)

Pipeline and Hazardous

Materials Safety Administration

(PHMSA)

PHMSA’s mission is to protect people and the environment by

advancing the safe transportation of energy and other hazardous

materials that are essential to our daily lives. To do this, the

agency establishes national policy, sets and enforces standards,

educates, and conducts research to prevent incidents.

Environmental

Protection Agency

(EPA)

The EPA's basic mission is to protect human health and the

environment -- air, water, and land. EPA, state, local and tribal

agencies work together to ensure compliance with environmental

laws passed by Congress, state legislatures and tribal

governments

IMO The IMO is the United Nations' specialized agency responsible for

improving maritime safety and preventing pollution from ships.

Occupational Safety &

Health Administration

(OSHA)

The OSHA’s mission is to assure safe and healthful working

conditions for working men and women by setting and enforcing

standards and by providing training, outreach, education and

assistance.

In addition, there are numerous state and local agencies with oversight over select assets; and while not

regulatory in nature, for DoD vessels and facilities, there are numerous internal standards and policy

documents addressing cybersecurity and cybersafety issues. Figure 7 illustrates the regulatory oversight,

both from a safety and security perspective, of many asset types that typically operate in the U.S. MTS.


51

Figure 7. Regulatory Oversight for Common MTS Components


52

8.1. Security Management Systems Table 9 summarizes each of the key Federal and international regulations and/or standards that

collectively require security management systems for major assets that operate with the U.S. MTS.

Appendix C provides further details on the requirements and how they address cyber issues.

Table 9. Security Management System Regulations

33 CFR Subchapter H, Part 104 – Maritime Security: Vessels Release Year: 2003

Asset Applicability

Part 104 has provisions that applies to commercial vessels that operates in the U.S. MTS

• Specific requirements for U.S. commercial vessels, including: passenger vessels , cargo vessels, tank ships, barges, towing vessels, and mobile offshore drilling units (MODUs)

• Incorporates IMO’s ISPS by reference to ensure that all foreign commercial comply with equivalent security requirements

Description

This regulation provides performance standards to assist vessel owners/operators with performing

vessel security assessments (VSAs) and developing vessel security plans (VSPs) that comport with

national maritime security initiatives. The regulations identify 23 vessel security requirements

spanning organizational requirements, personnel roles/responsibilities, training, drills, exercises,

communications, recordkeeping, and a variety of security measure categories.

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements are worded broadly and could be interpreted to include cybersecurity in addition to physical security. Requirements related to the following, are of specific interest:

• §104.200 Owner or operator

• §104.210 Company Security Officer (CSO)

• §104.215 Vessel Security Officer (VSO)

• §104.220 Company or vessel personnel with security duties

• §104.225 Security training for all other vessel personnel

• §104.230 Drill and exercise requirements

• §104.260 Security systems and equipment maintenance

• §104.270 Security measures for restricted areas

• §104.275 Security measures for handling cargo

• §104.280 Security measures for delivery of vessel stores and bunkers

• §104.285 Security measures for monitoring

• §104.290 Security incident procedures

• §104.300 General

• §104.305 VSA requirements

• §104.405 Format of the VSP

33 CFR Subchapter H, Part 105 – Maritime Security: Facilities Release Year: 2003

Asset Applicability

Part 105 applies to facilities that receive commercial vessels to transfer cargo or passengers, facilities used for military purposes, barge fleeting areas, and facilities that perform/support oil and natural gas production, exploration, or development.

http://www.ecfr.gov/cgi-bin/text-idx?node=33:1.0.1.8.52

http://www.ecfr.gov/cgi-bin/text-idx?SID=f188995fefa661aea73cc396bc313e80&mc=true&tpl=/ecfrbrowse/Title33/33cfr105_main_02.tpl



53

Description

This regulation provides performance standards to assist facility owners/operators with performing facility security assessments (FSAs) and developing facility security plans (FSPs) that comport with national maritime security initiatives. The regulations identify 22 facility security requirements spanning organizational requirements, personnel roles/responsibilities, training, drills, exercises, communications, recordkeeping, and a variety of security measure categories.

Cyber Commentary



• §105.205 Facility Security Officer (FSO)

• §105.210 Facility personnel with security duties

• §105.215 Security training for all other facility personnel


• §105.235 Communications



• §105.265 Security measures for handling cargo



• §105.300 General

• §105.305 FSA requirements

• §105.310 Submission requirements

• §105.405 Format of the FSP

33 CFR Subchapter H, Part 106 – Maritime Security: Outer Continental Shelf (OCS) Facilities Release Year: 2003

Asset Applicability

Part 106 applies to fixed or floating facilities engaging in the exploration, development, or production of oil, natural gas, or mineral resources in the U.S. OCS.

Description

This regulation provides performance standards to assist facility owners/operators with performing OCS FSAs and developing FSPs that comport with national maritime security initiatives. The regulations identify 19 OCS facility security requirements spanning organizational requirements, personnel roles/responsibilities, training, drills, exercises, communications, recordkeeping, and a variety of security measure categories.

Cyber Commentary



• §104.205 CSO

• §106.210 OCS FSO

• §106.215 Company or OCS facility personnel with security duties

• §106.220 Security training for all other OCS facility personnel




54


• §106.240 Communications



• §106.270 Security measures for delivery of stores and industrial supplies



• §106.300 General

• §106.305 FSA requirements

• §106.405 Format of the FSP

6 CFR 27 - Chemical Facility Anti-Terrorism Standards Release Year: 2007

Asset Applicability

Facilities that possess any chemical on the CFATS Appendix A: DHS Chemicals of Interest List at or above the listed screening threshold quantity. The collection of regulated facilities spans many industries, including: chemical manufacturing, storage and distribution, energy and utilities, agriculture and food, paints and coatings, explosives, mining, electronics, plastics, and healthcare.

Description

CFATS establishes eighteen RBPSs that identify the areas for which a facility’s security posture will be examined, such as perimeter security, access control, personnel surety, and cybersecurity. To meet the RBPSs, covered facilities can develop security programs they deem appropriate as long as they achieve the requisite level of performance in each applicable area. The programs and processes that a high-risk facility ultimately chooses to implement to meet these standards must be described in the Site Security Plan (SSP) that every high-risk chemical facility must develop pursuant to the regulations. It is through a review of the SSP, combined with an on-site inspection, that DHS will determine whether or not a high-risk facility has met the requisite levels of performance established by the RBPSs given the facility’s risk profile.

Cyber Commentary

Cyber is specifically addressed in this CFR in §27.230 (a8) Deter cyber sabotage, including by preventing unauthorized onsite or remote access to critical process controls, such as SCADA systems, DCS, PCS, ICS, critical business system, and other sensitive computerized systems. The requirements: §27.215 security vulnerability assessments (SVA) and §27.225 site security plans are worded broadly and should consider cyber as well as physical security issues.

Safety of Life at Sea (SOLAS) Chapter XI-2: International Ship and Port Facility Security (ISPS) Code Release Year: 2004

Asset Applicability

Commercial ships on international voyages (including passenger ships, cargo ships, and MODUs) and the port facilities serving these ships

Description

The main objectives of the ISPS Code include:

• establishment of an international framework that fosters cooperation between Contracting Governments, Government agencies, local administrations and the shipping and port industries, in assessing and detecting potential security threats to ships or port facilities used

http://www.ecfr.gov/cgi-bin/text-idx?SID=d865432469e288d339bedda7395cb50b&mc=true&node=pt6.1.27&rgn=div5

https://www.dhs.gov/publication/cfats-coi-list


55

for international trade, so as to implement preventive security measures against such threats;

• determining the respective roles and responsibilities of all parties concerned with safeguarding maritime security in ports and on-board ships, at the national, regional and international levels;

• to ensure that there is early and efficient collation and exchange of maritime security-related information, at national, regional and international levels;

• to provide a methodology for ship and port security assessments, which facilitates the development of ship, company and port facility security plans and procedures, which must be utilized to respond to ships' or ports' varying security levels; and

• to ensure that adequate and proportionate maritime security measures are in place on board ships and in ports.

In order to achieve the above objectives, SOLAS contracting governments, port authorities and shipping companies are required, under the ISPS Code, to designate appropriate security officers and personnel, on each ship, port facility and shipping company. These security officers, designated Port Facility Security Officers (PFSOs), Ship Security Officers (SSOs) and CSOs, are charged with the duties of assessing, as well as preparing and implementing effective security plans that are able to manage any potential security threat. IMO is able to provide support to Member states in need of assistance in implementing the Code, by way of national and regional workshops, seminars, needs assessment missions, etc.

Cyber Commentary

Cyber considerations are not explicitly addressed in the code; however, many of the requirements are worded broadly and could be interpreted to include cybersecurity in addition to physical security. Requirements related to the following, are of specific interest:

Part A

1 - General 4 - Responsibilities of Contracting Governments 5 - Declaration of Security 7 - Ship Security 8 - Ship Security Assessment 9 - Ship Security Plan 11 - CSO 12 - SSO 13 - Training, Drill and Exercises on Ship Security 14 - Port Facility Security 15 - Port Facility Security Assessment 16 - Port Facility Security Plan 17 - PFSO 18 - Training, Drills and Exercises on Port Facility Security

Part B

1 – Introduction 4 - Responsibilities of Contracting Governments 5 - Declaration of Security 8 - Ship Security Assessment 9 - Ship Security Plan 13 - Training, Drills and Exercises on Ship Security 15 - Port Facility Security Assessment 16 - Port Facility Security Plan 18 - Training, Drills and Exercises on Port Facility Security

8.2. Safety Management Systems Table 10 summarizes each of the key Federal and international regulations and/or standards that

collectively require safety management systems for major assets that operate with the U.S. MTS.

Appendix D provides further details on the requirements and how they address cyber issues.


56

Table 10. Safety Management System Regulations and Standards

33 CFR 96, Subpart B - Rules for the Safe Operation of Vessels and Safety Management Systems: Company and Vessel Safety Management Systems Release Year: 2003

Asset Applicability

Applies to commercial vessels that operate in the U.S. MTS:

• U.S. commercial vessels engaged in foreign voyages

• U.S. flag vessels

• Public vessels

• Incorporates IMO’s SOLAS Chapter IX by reference to ensure that all foreign commercial comply with equivalent safety requirements

Description

This subpart establishes the minimum standards that the safety management system of a company and its U.S. flag vessel(s) must meet to comply for certification to comply with the requirements of 46 U.S.C. 3201-3205 and Chapter IX of SOLAS, 1974. It also permits companies with U.S. flag vessels that are not required to comply with this part to voluntarily develop safety management systems which can be certificated to standards consistent with Chapter IX of SOLAS.

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements are worded broadly and could be interpreted to include cyber-related impacts to vessel safety. Specifically, requirements related to personnel knowledge of the SMS, operation of safety critical equipment and systems, safety training, drills, exercises, and maintenance of critical systems.

SOLAS Chapter IX: International Safety Management (ISM) Code

Release Year: 1994

Asset Applicability

Commercial ships on international voyages (including passenger ships, cargo ships, and MODUs) and the port facilities serving these ships

Description

The purpose of this Code is to provide an international standard for the safe management and

operation of ships and for pollution prevention. The Code establishes safety-management objectives

and requires a SMS to be established by "the Company", which is defined as the ship owner or any

person, such as the manager or bareboat charterer, who has assumed responsibility for operating

the ship.

The Company is then required to establish and implement a policy for achieving these objectives.

This includes providing the necessary resources and shore-based support. Every company is

expected "to designate a person or persons ashore having direct access to the highest level of

management".

Cyber Commentary

Cyber considerations are not explicitly addressed in the Code; however, many of the requirements are worded broadly and could be interpreted to include cyber-related impacts to vessel safety. Specifically, requirements related to safety and environmental protection policy, designated persons, resources and personnel, shipboard operations, emergency preparedness, and maintenance of the ship and equipment

http://www.ecfr.gov/cgi-bin/text-idx?SID=bec3983b7128a73d86174deba4c4a22b&mc=true&node=pt33.1.96&rgn=div5


57

30 CFR Part 250, Subpart S - Safety and Environmental Management Systems (SEMS) Release Year: 2010

Asset Applicability

Assets involved in oil, gas, and sulphur exploration, development, and production operations on the U.S. OCS

Description

The SEMS is a nontraditional, performance-focused tool for integrating and managing offshore

operations. The purpose of SEMS is to enhance the safety of operations by reducing the frequency

and severity of accidents. There are four principal SEMS objectives:

• focus attention on the influences that human error and poor organization have on accidents;

• continuous improvement in the offshore industry's safety and environmental records;

• encourage the use of performance-based operating practices; and

• collaborate with industry in efforts that promote the public interests of offshore worker

safety and environmental protection.

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements could be expanded to include cyber-related impacts to OCS assets. Specifically, requirements related to:

• §250.1911 What hazards analysis criteria must my SEMS program meet?

• §250.1915 What training criteria must be in my SEMS program?

40 CFR 68 – Chemical Accident Prevention Provisions Release Year: 1994

Asset Applicability

Chemical facilities with hazardous chemical inventories above specified threshold quantities.

Description

These regulations require companies that use certain listed regulated flammable and toxic substances to develop a risk management program, which includes a(n):

• Hazard assessment that details the potential effects of an accidental release, an accident history of the last five years, and an evaluation of worst-case and alternative accidental releases scenarios;

• Prevention program that includes safety precautions and maintenance, monitoring, and employee training measures; and

• Emergency response program that spells out emergency health care, employee training measures and procedures for informing the public and response agencies (e.g., the fire department) should an accident occur.

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements could be expanded to include cyber-related issues for chemical facilities. Specifically, requirements related to §68.50 Hazard review and §68.54 Training.

29 CFR 1910.119 – Process Safety Management (PSM) of Highly Hazardous Chemicals Standard Release Year: 1992

Asset Applicability

http://www.ecfr.gov/cgi-bin/text-idx?SID=b3f17718934c7deb8cae7e5137fd56b8&mc=true&node=pt30.2.250&rgn=div5

http://www.ecfr.gov/cgi-bin/text-idx?SID=b3f17718934c7deb8cae7e5137fd56b8&mc=true&node=pt30.2.250&rgn=div5

http://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title40/40cfr68_main_02.tpl


http://www.ecfr.gov/cgi-bin/text-idx?rgn=div8&node=29:5.1.1.1.8.8.33.13

http://www.ecfr.gov/cgi-bin/text-idx?rgn=div8&node=29:5.1.1.1.8.8.33.13


58

Chemical facilities with processes that contain toxic, reactive, flammable, and explosive chemicals above specified threshold quantities.

Description

This standard contains requirements for the management of hazards associated with processes using

highly hazardous chemicals. The PSM standard emphasizes the management of hazards associated

with highly hazardous chemicals and establishes a comprehensive management program that

integrates technologies, procedures, and management practices across 14 elements:

• Process Safety Information

• Process Hazard Analysis (PHA)

• Operating Procedures

• Training

• Contractors

• Mechanical Integrity

• Hot Work

• Management of Change

• Incident Investigation

• Compliance Audits

• Trade Secrets

• Employee Participation

• Pre-startup Safety Review

• Emergency Planning and Response

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements could be expanded to include cyber-related issues for chemical facilities. Specifically, requirements related to (e) PHA and (g) Training.

49 CFR 193 – Liquefied Natural Gas (LNG) Facilities: Federal Safety Standards Release Year: 2006

Asset Applicability

LNG facilities

Description

These standards govern siting, design, construction, equipment, operations, maintenance, personnel, fire protection, and security of LNG facilities. Based on the broad scope, they address both safety and security requirements.

Cyber Commentary

Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements could be expanded to include cyber-related issues for LNG facilities. Specifically, requirements related to: Cyber considerations are not explicitly addressed in the CFR; however, many of the requirements could be expanded to include cyber-related issues for chemical facilities. Specifically, requirements related to:

• §193.2715 Training: security

• §193.2903 Security procedures

• §193.2913 Security monitoring



59

9. Framework for Point of Failure Detection Methodology Over the past few years, the maritime industry has been increasingly engaged in cybersecurity

implementation; however, the best practices are still being formed and many programs are not

adequately focused on solid principles of design and implementation. Clear design concepts and

effective tools that focus maritime cybersecurity efforts are needed. This section begins reducing

cybersecurity implementation guidance confusion by establishing a framework for evaluating an asset’s

potential points of failure.

9.1. Background There are many facets that make designing implementing robust cybersecurity programs for maritime

companies and assets difficult. These include, but are not limited to:

Varying Levels of Automation. There are a myriad of industries and asset types operating within the

U.S. maritime domain, and expectedly, these assets have varying levels of reliance on IT and OT systems,

ranging from purely manual to highly automated. Some of the most highly automated assets include:

offshore drill ships, MODUs, cruise ships, chemical plants, petroleum refineries, LNG facilities, LNG

carriers, and container terminals. Other assets control operations through mostly manual processes,

relying on simple, isolated OT systems, or in some cases antiquated analog control systems.

Asset Mobility and Connectivity. Maritime transportation assets are primarily focused on heavy

mechanical vessels and offshore assets that are highly mobile and operate in remote environments.

Even so, critical equipment systems on marine and offshore assets are increasingly connected. This

reliance on highly connected software controls makes these systems vulnerable to cyber-related

failures.

Dependence on Suppliers. As the number and sophistication of IT/OT systems have increased,

companies have become increasingly dependent on equipment vendors to maintain and upgrade their

systems. Maintenance and instrumentation departments often rely on vendor technicians to

troubleshoot and fix OT issues. For the most highly automated assets, there is often integration among

OT systems spanning multiple vendors, introducing the possibility for operational upsets as changes to

one system can affect the performance of others.

Emerging Cybersecurity Culture. Cybersecurity is commonly viewed by the maritime industry as the

domain of IT specialists who speak a specialized language and deal in obscure concepts. Further, the

volume of cybersecurity-related reference materials is massive. Industry leaders in the cybersecurity

domain are primarily business, financial, and IT-centric enterprises that project sophisticated, complex,

and expensive solutions. The maritime industry is somewhat (understandably) confused about the

applicability of such solutions to its cybersecurity needs, especially in the context of OT systems

Confusing or Non-Applicable Cybersecurity Guidance. Constant media reports of cyber threats and

incidents are troubling to maritime industry leaders and managers, but they often struggle to

understand how the reported incidents and potential solutions might pertain to their business.

Mounting incident information without pertinent, clarifying, and actionable knowledge can be more

confusing than helpful. Even “guidance” provided for the maritime industry is often focused on

problems and solutions that are not relevant to maritime OT systems. So, the maritime industry is being

offered large amounts of information on how to improve cybersecurity that are not based on solid


60

engineering fundamentals that enable development of a cybersecurity program based on the specific

needs of an individual organization.

9.2. Engineering Principles The maritime industry needs to understand cybersecurity can be implemented based on proven

engineering principles. Software applications and computer technologies are often the targets of cyber-

attacks designed to degrade or compromise their functionality. Systems are designed for a specific set

of functions; so, the research team developed a reference model based on common safety-critical

functions performed by maritime assets.

Since the information management system is real, but mostly unseen, the research team coined the

phrase virtual asset to represent the structure and behavior of the collection of systems on an asset. The

virtual asset is the aggregation of the software applications and computerized technologies control

mechanical systems that fulfill safety-critical functions. For an oil tanker, these might include ship

handling activities (e.g., propulsion, navigation, ballast) and mission-oriented activities (e.g., cargo

management). For the near future, human operators will interact with the virtual asset introducing

variability to the system and the capability to handle exceptional events. This virtual asset concept is

important because it enables the establishment of dimensions that can be discussed in connection to

cybersecurity implementations.

A basic engineering approach is decomposing complex systems into well-understood components that

can be described and measured. The research team has decomposed the virtual asset into three

components:

1. Functions. Software applications that control machines aboard the physical asset.

2. Connections. Nature and number of digital interfaces are measurable characteristics indicating

cybersecurity complexity.

3. Identities. Endpoints or nodes (humans or machines) that send or receive data by means of the

digital interfaces.

By observing the behaviors and interactions of a virtual asset’s (1) functions, (2) connections, and (3)

identities, a foundational understanding of cybersecurity requirements and points of failure is possible

from an engineering perspective (Figure 8).

A fundamental cybersecurity concept is trust. The intent of a cybersecurity program is to establish trust

with respect to functions, connections, and identities. If the behaviors of all three of the basic

components of the virtual asset are trusted, then the asset is secure. If any behavior of one of the three

components is not trusted, then the asset is not secure.


61

Figure 8. Components of Maritime Cybersecurity

Another basic engineering principle is experimental observation and measurement. With respect to

cybersecurity, determining which things to measure may not be obvious, because the virtual asset can

be somewhat abstract. But, when contemplated in terms of functions, connections, identities, business

attributes, and documentation attributes, the measurement of a number of useful cybersecurity system

characteristics emerges, as does important understanding about the potential point of failure. The

collection of useful data depends on (1) measuring the breadth and depth of the virtual asset and (2)

subsequently collecting data concerning the attributes of functions, connections, and identities.

By describing the virtual asset, and subsequently collecting and measuring related data, it is possible and

essential to impose risk-based standards into the design, implementation, and improvement of a

cybersecurity system for maritime assets.

9.3. Framework The research team developed the framework by identifying a simple set

of virtual asset attributes that are essential to understanding potential

points of failure. The sheer diversity of maritime asset types calls for a

general use cybersecurity framework that can be easily tailored to be

applied to any single asset instance. Using the framework to assess a

given asset will provide useful information to assess its cybersecurity

profile and focus subsequent assessments and improvement actions.

The general framework is based on an understanding of the virtual

asset’s breadth and depth (Figure 9). Figure 9. Framework Basis


62

Virtual Asset Breadth is defined by the number of critical cyber-related functions on an asset. As a

practical matter, these are commonly the functions that are critical for safety of people on the asset, the

integrity of the asset itself, and/or the protection of the surrounding environment. To define the

breadth, it is necessary to identify (inventory) each of the safety-critical functions on the asset. The

framework defines two major categories for asset functions:

1. Ship Handling functions are for vessel assets only and address those functions required to

ensure safe movement of the vessel and prevent collisions, allisions, groundings, etc.

Common ship handling functions include: navigation, propulsion, ballast, power, and

communication.

2. Mission-oriented functions are defined by the purpose or mission of the specific asset. If

the asset is a cargo vessel, these functions will include cargo management and vapor

control. For a drill ship, these functions will include drilling and well control.

Virtual Asset “Depth” is defined by complexity of the asset functions, business attributes, and the

completeness of the system documentation. Depth is assessed by inventorying (1) the cyber complexity

of the safety-critical functions, (2) the business constraints and capabilities of the enterprise, and (3) the

availability of cybersecurity documentation that demonstrates the engineering rigor and execution

within the enterprise. Further segmentation on the depth categories are:

1. Cyber Complexity Attributes Inventory

• Functions: Criticality of functions to safe operation

• Connections: Complexity of connections

• Identities: Accessing identities 2. Business Attributes Inventory

• Regulatory imperatives

• OT deployment strategy

• Cybersecurity governance 3. Cybersecurity Documentation Inventory

• Security responsibility evidence

• Design knowledge evidence

• Security control process evidence

9.3.1. Cyber Complexity The research team developed a series of questions for each of the functions identified for the asset. The

type of answer for each question is identified in parentheses at the end of the question. Note: questions

are worded so that affirmative responses for Yes/No questions indicate higher potential cybersecurity

vulnerability.

1. This function is deployed on one or more assets within the enterprise (Number of Instances). For each ship handling and mission-oriented function, indicate whether multiple instances of the function are installed at multiple assets or locations. This information is used to determine whether


63

functions are copied exactly from location to location when designing protection systems. This can present opportunities for economy-of-scale protection or assessment considerations.

2. This function is critical to safe operation (Yes/No). Indicate whether degradation of performance or failure of the function can result in injury or loss of life to personnel, damage to or loss of the asset, and damage to the marine or surrounding environment.

3. This function communicates using a well-understood connection type (Control Connection Type). For each function, determine if the control system communicates by means of a discrete, simple, complex, or very large number (VLN) connection.

• This function's control connection is "Discrete.” This type of connection may be characterized as a "1:1" connection in which the equipment is linked to its control connection only. This connection type communicates only with the equipment under its control, and is not connected to any other systems on the asset.

• This function's control connection is "Simple." This type of connection may be characterized as a "1:Few" connection in which the equipment is linked to multiple other control connections directly and without a network.

• This function's control connection is "Complex." This type of connection may be characterized as a "1:Many" connection in which the equipment is linked to multiple on-asset control connections through a network.

• This function's control connection is "VLN." This type of connection may be characterized as a "1:VLN" in which the equipment is linked to the Internet, often by means of a network, and is therefore potentially connected to a VLN of off-asset nodes.

4. This function is managed by the provider of the equipment and/or control system provider (Yes/No). Indicate whether (1) the equipment and/or control system is managed as a service and (2) the service includes cybersecurity monitoring and protection.

5. This function does not have supplier-provided control system documentation (Yes/No). Indicate whether the equipment and control system are accompanied by a functional description document (FDD) that clearly explains the functionality of the equipment, diagrams the control system, describes its interfaces, defines its failure states, etc.

6. This function's control system is protected by the system supplier's cybersecurity system (Yes/No). Indicate whether the supplier of the control system has provided its own proprietary cybersecurity system with the control system, and if it is excluded from the widely installed security systems on the asset.

9.3.2. Business Attributes The research team developed a series of Yes/No questions to be answered to describe the business

attributes of the asset and enterprise. Note: questions are worded so that affirmative responses indicate

higher potential cybersecurity vulnerability.

1. The asset is not MTSA-regulated (Yes/No). Indicate whether controls required by MTSA are in place on one or more assets within the enterprise, indicating full adherence to the requirements of that regulation.

2. The asset is not registered with a classification society that has cybersecurity guidance (Yes/No). Indicate whether classification society "rules" are implemented on the asset and may provide additional requirements for a cybersecurity implementation. Note: this question does not apply to facilities.

3. Land-based IT or OT systems communicate to the asset's OT systems (Yes/No). Indicate whether internal or 3rd-party land-based computerized systems communicate directly to a control system on the asset or to a network to which OT system or systems are connected.


64

4. Some assets are identically equipped (Yes/No). Indicate whether OT system designs (architectures) are duplicated (i.e., exact copies) within the fleet (clarification will be needed from the client), and may therefore offer opportunities for economy-of-scale with respect to design, implementation, maintenance, and assessment/notation.

5. The company has not developed policy governing IT cybersecurity (Yes/No). Indicate whether IT system security policies and procedures are documented, fully implemented, and available for review, indicating that the enterprise recognizes the importance of cybersecurity policies and procedures for business systems.

6. The company has not developed policy governing OT cybersecurity (Yes/No). Indicate whether OT system security policies and procedures are documented, fully implemented, and available for review, indicating that implementation of a fully capable OT cybersecurity program is planned, in progress, and may require only minimal additional assistance to complete.

7. OT cybersecurity is provided by a 3rd-party supplier (Yes/No). Indicate whether a cybersecurity solution provider (3rd-party provider) is the primary resource for detailed information about monitoring and protections, indicating that the cybersecurity implementation team and assessment team will have to support additional collaborations to perform activities; further, support from both internal purchasing and legal resources might be required for program implementation.

9.3.3. Cybersecurity Documentation Attributes The research team developed a series of Yes/No questions to be answered to describe the cybersecurity

documentation attributes of the asset and enterprise. Note: questions are worded so that affirmative

responses indicate higher potential cybersecurity vulnerability.

1. IT Cybersecurity Office (CsO) responsibilities are not documented (Yes/No). Indicate whether an office or named individual is responsible for security of IT systems. An internal authority indicates commitment to a culture of IT cybersecurity and provides an internal resource to support assessment activities.

2. OT CsO responsibilities are not documented (Yes/No). Indicate whether an office or named individual is responsible for security of OT systems. An internal authority indicates commitment to a culture of OT cybersecurity and provides an internal resource to support assessment activities.

3. Incident Response Team (IRT) responsibilities are not documented (Yes/No). Indicate whether an office or named individual is responsible for supervising the response to security incidents related to OT systems. A commitment to this function indicates that the enterprise is fully aware of the liabilities associated with a cyber incident and is organized for a rapid response and mitigation effort.

4. An OT FDD has not been developed (Yes/No). Indicate whether the OT systems being protected are inventoried and described in a client-generated, asset-specific design document, indicating that the enterprise understands that an engineering description of the functions requiring cyber protection is essential to the requirements development of a cybersecurity system and has invested in developing that description. The FDD also provides the foundation for an expeditious cybersecurity assessment or inspection by classification societies and regulators. See Appendix A for additional explanation of the OT FDD.

5. A compiled cybersecurity FDD is not available (Yes/No). Indicate whether the cybersecurity systems providing protection are inventoried, described, and made available in a client-generated, asset-specific design document, indicating that the cybersecurity system is designed, implemented, maintained, and evolved as a rigorously designed and documented critical function and is subjected to rigorous change management control.


65

6. Management of Change (MoC) documents are not available (Yes/No). Indicate whether all changes to the OT and cybersecurity systems are rigorously controlled and governed by policy, procedures, and archived MoC documentation, indicating that the enterprise comprehends the evolving nature of cyber threats and the need to embrace and rigorously manage that evolution.

7. Cybersecurity Training documents are not available (Yes/No). Indicate whether home office and on-asset cybersecurity training is rigorously performed, managed, and governed by policy and procedure, indicating that the enterprise is embedding cybersecurity awareness and capabilities in the organization at all levels. Robust training practices also give indications of management commitment to do what is reasonable and prudent to protect lives, assets, and the environment from hazards potentially created by cybersecurity incidents.

Figure 10 presents an example of the point of failure detection framework worksheet tailored to the functions of a drill ship or MODU. Appendix E presents a collection of worksheets for asset classes with high consequence potential. The research team believes that this framework is useful because it provides a method for determining

points of failure of an asset’s cybersecurity based on unprotected functions, connections, and identities;

where the notion of “point of failure” includes the system lifecycle process considerations to include

agreement processes, an organization’s enabling processes, technical management processes, and

technical processes.7 This approach is extensible for the development of a qualitative or qualitative

measure of an asset’s cybersecurity profile. This measure (1) can be derived from the responses to the

statements posed in the virtual vessel breadth and depth assessment and (2) could be associated with

C2M2 MILs to characterize the maturity of the asset’s cybersecurity:

Level 3: Managed

Level 2: Performed

Level 1: Initiated

Level 0: Not Performed

7 NIST Draft Special Publication 800-160, 2016


66

Figure 10. Point of Failure Detection Framework Worksheet (Drill Ship or MODU)


67

10. Critical Points of Failure I often say that when you can measure what you are speaking about,

and express it in numbers, you know something about it; but when

you cannot measure it, when you cannot express it in numbers, your

knowledge is of a meagre and unsatisfactory kind.

William Thomson, 1st Baron Kelvin, a.k.a. Lord Kelvin, 1824 – 1907

This section presents a reference model and methodology that generates quantitative risk

results of sufficient quality to inform critical decisions in the design, assessment, and

management of cybersecurity programs for maritime companies. The results are also sufficient

to provide information to cybersecurity regulators (e.g., USCG) to support their regulatory

development and enforcement activities.

The results of this research are designed to support a variety of key functions for cybersecurity

personnel including:

• Identify and understand potential points of failure

• Prioritize issues to address

• Control, manage, and improve risk profile through implementation of security measures

• Measure impact of implemented security measures

• Determine when program has reached diminishing returns

The research presented in this section applies the fundamental components of cybersecurity:

functions, connections, and identities (introduced in Section 9.2) at the next level of detail to

enable systematic accounting and simple assessment of these components as a means of

quantitatively expressing an asset’s risk.

Every maritime asset is unique based on the materials of construction, layout, and the chosen

equipment. Similarly, the “virtual asset” which is made up of IT and OT components, systems

and networks are unique. No two virtual assets are identical. They have different attributes

based on how they are designed and architected; so, the model and methodology focuses on

the fundamental building blocks on which every virtual asset is built: functions, connections, and

identities. Using these building blocks, the model can be configured to represent any virtual

asset and can be assessed to generate relative cybersecurity risk scores that enable consistent

risk comparison of disparate assets using same measuring stick.

10.1. Background Current methods for cybersecurity system and program assessment are based on observing

documented designs and procedures, staff behaviors, and physical indications (i.e., evidence) of

specific implemented practices and protections within multiple cybersecurity “domains.” The

approach is binary in that regulators and certification assessors look for indications of protection

and remediation capabilities in programs and aboard assets. The assessment is basically a

“go/no-go” situation in that it determines if a protection or procedure is in place and observed,

or not. There is minimal supportive guidance for questions such as, “How bad is it? How great

is the risk? What do I need to fix or add? What is most at risk? What should I do to meet


68

standard or certification criteria? Can you help me?” Answers to those questions are now

within reach.

In practice, cybersecurity programs are designed and implemented based on case-specific

(parochial) understandings, perceived needs, and available resources. Real-world programs are

not typically designed to accommodate maturity levels, but are instead designed based on

interpretations of available guidance, mandated regulations, contract requirements, and

internal resources. Such programs exemplify pragmatic selection of specific capabilities

associated with all domains and all levels of program maturity. As a result, regulators and

assessors are hard pressed to reach a formulation that will identify a program implementation

as belonging in single achievement or maturity level. Pass/fail requirements criteria simply do

not provide sufficient problem measurement resolution to yield answers to the questions posed

above. Further, the summary result of such assessments does not provide clear insight into the

overall cybersecurity preparedness of an organization or asset.

At the core of this problem is the notion of clearly understood and quantifiable risk. When

referencing the SEI CMMI and the C2M2, clarifications of cybersecurity domain descriptions

include specific “Approach Objectives” and “Management Objectives” with detailed

implementation guidance. The larger cybersecurity problem is nicely decomposed and

presented. And, a strikingly obvious foundational requirement for satisfying the requirements

provided within each domain to all the domains presented. It is a deep understanding of the

cybersecurity risk associated with each domain as associated with an organization, asset, and

function.

Consider, the summary descriptions of the 10 C2M2 domains are excerpted below, with specific

references to scaling solutions to levels of “risk” highlighted in red text. The ability to scale to

risk and in turn scale programs to manage risk is a critical need in cybersecurity. This research

specifically reacts to that need.


69

Figure 11. References to risk in Maturity Model References

It is noteworthy that of the ten 10 domain descriptions presented in C2M2:

• Nine make references to managing or understanding risk

• Six contain a reference to “commensurate with risk.” Domain #4 is especially important in that it provides guidance for threat and vulnerability management: Establish and maintain plans, procedures, and technologies to detect, identify, analyze,

manage, and respond to cybersecurity threats and vulnerabilities, commensurate with the

risk to the organization’s infrastructure (e.g., critical, IT, operational) and organizational

objectives.

• Domain #1 is specifically about risk management, and reads: Establish, operate, and maintain an enterprise cybersecurity risk management program to

identify, analyze, and mitigate cybersecurity risk to the organization, including its business

units, subsidiaries, related interconnected infrastructure, and stakeholders.

Additionally, the C2M2 provides a definition of and use for a risk taxonomy”:

• Definition: The collection and cataloging of common risks that the organization is subject to and must manage.

• Use: The risk taxonomy is a means for communicating these risks and for developing mitigation actions specific to an organizational unit or line-of-business if operational assets and services are affected by them.


70

The imperative to identify, analyze, and mitigate risk requires that risk be countable and

calculable. Even so, further guidance for approaches identifying, describing, or managing

threats and vulnerabilities is absent. It is left to the user to develop a representative risk

taxonomy that is essential to appropriately developing capabilities in all 10 domains, and

develop a method of scaling risk.

The research presented in this section attempts to close this critical gap for maritime

cybersecurity by providing a risk taxonomy model and associated implementation tools that

express threats, vulnerabilities, and consequences in countable and calculable terms. This

enables users of various cybersecurity models, standards, and procedures to gauge and

characterize the relative effectiveness of specific implementations during design, operation, and

improvement activities. It adds meaning to a risk management plan and fully enables users to

make cybersecurity decisions “commensurate with the risk” as required by C2M2 and similar

industry guidance.

10.2. Risk Assessment Risk information fundamentally seeks to improve decision-makers’ understanding by answering

the three questions illustrated in Figure 12.

Figure 12. Fundamentals of Risk Understanding

Risk identification, assessment, and management can cover a wide range of approaches from

very simple screening approaches to quite sophisticated quantitative/qualitative modeling

approaches. The key is to always fit the complexity of the modeling approach to the level of

information needed by decision makers; this information is typically derived from a combination

of (1) historical experience, (2) analytical methods, and (3) knowledge of experts.

This section will explore how these concepts are typically applied for security risk assessment

and the challenges of applying them within the cyber domain.

10.2.1. Security Risk Assessment Methodologies In 2006, the USCG established the Maritime Security Risk Analysis Model (MSRAM) program.

MSRAM is a terrorism risk management tool and supporting process deployed annually to local

Port Security Specialists (PSSs) in major ports across the country. MSRAM requires PSSs to

perform a detailed risk analysis for all the significant potential terrorism targets (vessels,

facilities, and offshore platforms) operating within their area of responsibility across a spectrum

of physical attack modes.


71

Risk within MSRAM is assessed for scenarios, which represents a combination of a target and

attack mode. For each scenario, analysts score numerous threat, vulnerability, and

consequence factors to estimate the risk. Figure 13 illustrates the MSRAM risk methodology.

Figure 13. MSRAM Risk Methodology

The MSRAM methodology requires analysts to score several factors in three major categories:

• Threat (relative likelihood of attempt). Intelligence analysts from the USCG Intelligence

Coordination Center (ICC) develop quantitative, relative threat estimates for each

unique combination of asset class and attack mode for each USCG Sector, providing

geographic differentiation.

• Vulnerability (probability of a successful attack, given an attempt). Sector PSSs estimate

the vulnerability of each target to each attack using several factors, including the innate

difficulty of the attack, the protections offered by the owner/operator, local law

enforcement, and USCG forces, and the ability of the target to withstand the attack.

Vulnerability is defined as the probability of a successful attack, given an attempt.

• Consequence (consequence points). Sector PSSs estimate the reasonable worst-case

consequences that could result from a successful attack on each target from each attack

by scoring a spectrum of potential impacts: deaths/injuries, primary economic impacts,

environmental impacts, national security impacts, symbolic impacts, and the effects on

the national economy. They also estimate emergency response mitigation of


72

consequences based on the capabilities of the owner/operator, local first responders,

and the USCG.

MSRAM calculates the risk for each scenario as a product of threat,

vulnerability, and consequence factor scores. The result is a

relative expected loss risk score, expressed in units of Risk Index

Number (RIN), for each scenario. Scenarios are then mapped into

one of five risk levels (Figure 14) based on their risk scores. Risk

levels are used in many applications to help the USCG and its

partners focus their resources on very high and high risk scenarios.

The results of the MSRAM process yield a robust national dataset currently containing risk

information for over 48,000 assets and 150,000 scenarios. This dataset is leveraged to inform a

wide variety of risk management decisions, both inside and outside the USCG, at the local,

regional, and national levels.

10.2.2. Challenges in Cybersecurity Risk Assessment Developing accurate risk estimates for physical security assessments is very difficult, but doing

so for cybersecurity is even more challenging. Technology changes quite rapidly and threats in

the cyber environment are extensive and multifaceted.

Applying the MSRAM approach to cyber risk assessment is challenging and could possibly be

misleading:

• Is “Threat” a person, a type of attack, the named intrusive software application, or a

specific line of code?

• Is “Vulnerability” a point in a network at which malware can intrude, an open USB port,

or a misconfigured firewall?

• Is a “Consequence” a description of the event caused by a cyber incident, or is it lost

money?

In a 2010 article, Jeff Lowder8 wrote that applying the T*V*C risk equation in information

security risk analysis (ISRA) is “mathematical nonsense”. He summed up his discussion by

commenting:

“the formula is not literally intended to be used as a mathematical formula; rather, the formula

is just an informal way of stating that security risk is a function of threats, vulnerabilities, and

potential impact.”

If that is so, the MSRAM risk equation is marginally useful to a cybersecurity practitioner.

When contemplating the issue of describing risk more precisely, research shows that much of

cybersecurity is focused on threat versus risk management. Security processes and procedures

tend to focus on threat recognition, resolution, and removal. A market analysis of commercial

8 http://www.bloginfosec.com/2010/08/23/why-the-risk-threats-x-vulnerabilities-x-impact-formula-is-mathematical-nonsense/

Risk Level Criteria

Very High >10K RIN

High 500 to 10K RIN

Medium 100 to 500 RIN

Low 10 to 100 RIN

Very Low 0 to 10 RIN

Figure 14. MSRAM Risk Levels


73

cybersecurity products and services reveals the market’s focus on unified threat management

(UTM).

The difficulty with focusing on threat is that real-life expressions of a threat may not

recognizable until the threat has manifested (e.g., “The X-virus was discovered on our system

today and infected 35 computers on two networks.”)

Also, the current understanding of threat does not lend itself to quantification. Threats are often

characterized qualitatively as:

1. The penetration mode: how the threat enters a computer) or

2. The carrier of the threat (i.e., email) or

3. The name of the threat: Stuxnet, ILOVEYOU, GoldenEye, etc.

None of these characteristics readily lend themselves to being expressed mathematically in a

risk equation. This in turn makes the result of the risk equation a subjective number that

provides limited uses for comparison to other subjective results based on similar assumptions.

Even with these concerns understood, the risk equation remains useful as a tidy mental model

for intuitively understanding that risk is “made up” of three components. Adding to this general

utility, it also infers that if just one of those three things is removed from the equation, risk can

be eliminated.

These are important concepts, but the research team challenged the assumption that the

removal of threat, vulnerability, or consequence does, in fact, eliminate risk. The underlying

notion of these three components combining to create risk is an accepted premise. However,

the question remains: Does removal or reduction of just one of those conditions reduce or

eliminate risk in practice? The research team’s answer is: probably.

For example, reduction or elimination of consequences of a successful attack makes a system an

unattractive target to attackers, and probably not worth protecting from malicious or

unintentional system corruption. If the consequence of loss or damage is eliminated, why

bother to protect it?

Reduction or elimination of vulnerability makes the system unavailable to a threat through a

path; thereby, eliminating risk. Finally, reduction or elimination of threat logically reduces risk,

because if there is no adversary attempting to exploit a system, there is no risk to the system.

So, the research team believes the classic risk equation makes logical sense, and the reduction

or removal of any one of the three elements does reduce risk. Combination of threats,

vulnerabilities, and consequences do appear to be necessary and sufficient to yield risk.

Next, the research team considered the potential conflict of the utility of the classic risk

equation as a useful logical model versus the issue that, when applied quantitatively, it might

result in “mathematical nonsense”.

Ultimately, cybersecurity stakeholders need a quantitative risk estimate to determine relative

risk between assets or between alternative security solutions. So, the research team developed

an approach to this simple question:


74

How can the classic risk equation be logically expressed based on closely-related real-world cybersecurity elements that can be quantified using available technological and management solutions?

Put simply, can a useful approach be developed for maritime cybersecurity that is (1) consistent,

(2) clarifying, and (3) countable?

10.3. Reference Model The research team recognized a familiar concept when considering the components of the

MSRAM risk model separate from its mathematical formulation. Cybersecurity risk appears to

have probabilistic and set theory characteristics. Lowder reinforces this notion when he states:

“…risk analysis, including ISRA, has its roots in decision theory, especially expected value (or

utility) theory. The expected value or utility of an action may be thought of as a weighted

average. It can be calculated by defining a set of mutually exclusive and jointly exhaustive

possible outcomes from a particular course of action, and then multiplying the probability of

each possible outcome by its utility. The formula is very clear and mathematically rigorous.”

That is a strong indictment of applying the standard security risk formula to cybersecurity. The

research team agrees with Lowder’s conclusion, but believes that the underlying relationships

are powerful, logically (if not mathematically) supportable, and arguably useful.

10.3.1. Triads Conceptual triads are easy to find in science,

engineering, and philosophy. In researching

conceptual triads, a comparable construct was

identified: the Fire Triangle (Figure 15). The

conceptual abstraction as represented by the risk

equation is remarkably similar in nature to the fire

triangle elements – even directly analogous in ways.

• Fuel represents the material consumed by

the fire

• Oxygen represents the enabling

environment for starting and sustaining fire

• Heat represents the incidental condition

that causes fire

Logically, the components of the security risk equation can replace the fire triangle elements

(Figure 16).

Figure 15. The Fire Triangle


75

Consequence replaces fuel as the end goal of a

cyber-attack. Without an attractive target, the

attack is random and purposeless. So, the presence

of consequence fuels and is ultimately consumed by

the cyber-attack.

Vulnerability replaces oxygen as the environment

variable. As oxygen supports fire, vulnerabilities

enable and “feed” a cyber attack

Threat replaces heat as the initiator of the

unwanted event. As oxygen and fuel peacefully

coexist until Heat enters the system, vulnerability

and consequence coexist without risk until threat is

present.

The similarities in these models for two very different systems are interesting and possibly

useful. But, the issue remains that consequence, vulnerability, and threat, are not readily

countable.

To take it one step further, these models can be

extended to the basic elements of cybersecurity

(functions, connections, and identities) introduced in

Figure 8.

Functions, if compromised, can result in negative

consequences including safety, economic, and

environmental impacts.

Connections, if not properly controlled, create an

environment that enables or foments malicious or

careless activity

Identities, if untrusted, can intentionally or

accidentally introduce threats into the system.

Reconceiving the security risk triangle in this way has merit, because it is: (1) consistent with the

components of the standard security risk equation, (2) analogous to a ubiquitous and well

understood mental model, and (3) countable which enables quantification of risk.

10.3.2. Taxonomy By representing consequence as impacted functions, vulnerability as connections, and threat as

identity, the security risk equation becomes tractable for a variety of applications. By

systematically identifying, counting, and assessing functions, connections, and identities,

cybersecurity stakeholders can dramatically improve their decision making.

• Cybersecurity system designers can rapidly develop a specialized taxonomy of “things to

understand.”

Figure 16. Security Risk Triangle

Figure 17. Cybersecurity Risk Triangle


76

• Auditors/assessors can develop a specialized taxonomy of “things to observe and

review.”

• Risk managers to develop a specialized taxonomy of “things to control, manage, and

improve.”

• Regulators to develop a specialized taxonomy of “things to look for or require.”

Figure 18. Cybersecurity Risk Assessment Reference Model

Functions

All ship handling and mission-oriented functions9 residing within the protective sphere of

cybersecurity must be identified for a maritime asset. This includes OT systems linked through

communicating connections. Each function should be assessed as either (1) consequential or (2)

inconsequential. The specific criteria and threshold for these categories must be determined by

each organization to align with organizational risk tolerances. At a minimum, based on USCG

policy guidance, any compromised function that could result in deaths, injuries, environmental

spills, or major disruption to port operations should be considered consequential. Most

organizations will also be interested in compromised functions that could result in major data

loss, compliance violations, or significant business interruptions.

Connections

Connections for each consequential function should be categorized as one of the following:

1. Discrete – A single (1:1) digital connection only between a single equipment controller

and a single piece of controlled equipment.

2. Simple – More than one connection between a single equipment controller and more

than one other equipment controllers, but NOT through a network.

9 Note: A “Function” can be characterized with a quantitative “if-lost” value. For example, if-lost value can be the replacement or repair cost of the function alone, or a combination of derivative costs such as lost production, civil lawsuits due to loss of life, environment damage fines and remediation, etc.


77

3. Complex – More than one digital connection to a network linking only equipment

controllers and associated interfaces.

4. VLN – Any of the above type connections that are also connected to the Internet or any

potentially accessible proprietary wireless connection.

These connections are further assessed to identify nodes that are accessible by an identity

(vulnerable), or not (invulnerable). Examples of invulnerable connections, include:

• A physical blocking device,

• A compensating protection (i.e., a locked room),

• A software security application that monitors digital activity, recognizes any

unauthorized activity as anomalous and potentially threatening, and blocks the activity

and/or generates an alert so that a responder can positively react to protect the

connected system from intrusion. Examples of anomalous activity include, but are not

limited to:

• Multiple failed logon attempts,

o Out-of-pattern repeated logons

o Out-of-pattern logged on durations

o Out-of-pattern messaging activity

Identities

Lastly, the model calls for observing all identities having interactions with the communications

nodes, and designating those identities as “Threatening” or “Non-threatening”. In common

cybersecurity terms, this mean trusted or untrusted identities. The issue of determining the

constraints or parameters for designating an identity as threatening or non-threatening calls for

deeper research; however, in practice this issue can initially be resolved by observing the

identities of people who have authorized access to protected system, and the machines10 that

are authorized to communicate with the protected system.

The underlying question needing deeper research is, “Are the trust/threat-indicator

requirements placed on humans and machines that are authorized to access critical vessel and

port operational technology functions sufficient?” Additionally, the designation of human

identities as “untrusted” should be defined as untrusted and capable of malicious intent, and/or

untrusted due to inadequate security training and supervision.

A digital machine or human identity is considered non-threatening or trusted if it is recognized

in formal access documentation as an identity authorized to access defined (named) access

points, and is provisioned with appropriate access credentials. Examples of access credentials

include, but are not limited to:

• Managed and protected passwords

• Identification credentials (badge, inventory identification, digital identification, etc.)

• Multifactor access credentials or tokens

• Trained in cybersecurity policies and procedures

10 This research argues in favor of classifying the Internet as a virtual “Machine” being accessed by billions of untrusted identities.


78

• Temporary access authorization credentials (e.g., permissions for suppliers)

All other connection identities are considered threatening or untrusted.

Research indicates that human identities who are (or should be) considered untrusted by

inadequate training are implicated in more security events than are unauthorized (malicious)

actors. These nuanced issues are not addressed in this research, therefore the designation of

“threatening” or non-threatening” is judgmental and subjective, but the indicators for a

practical determination are not. If the identity is provided access based on access permissions

policy and procedures and is on the authorized list of identities, then the identity is considered

trusted, and therefore “Non-threatening”

However, if the identity is designated as trusted by being on the authorized list of identities, but

is not on the list of identities trained in security procedures, then that identity may be deemed

as untrusted/threatening because it may promote a security incident due to careless or

untrained procedural execution.11

Summary

The basic structure of the taxonomy is summarized in Table 11.

Table 11. Cybersecurity Risk Taxonomy Elements

Component Categories Values

Functions • Ship Handling

• Mission-oriented

• Consequential

• Inconsequential

Connections • Discrete

• Simple

• Complex

• VLN

• Vulnerable

• Invulnerable

Identities • Human

• Machine

• Threatening

• Non-threatening

It is important to observe that all the risk taxonomy elements can be counted and characterized

with a binary condition. This is a major simplifying characterization that is intentional in that it

allows for a more transparent, more understandable calculation. It also yields to an assumption

that dealing in probabilistic characteristics does not significantly improve the usefulness.

Further, assigning values to indicate degree of risk associated with increasing or decreasing

counts of the elements is experience-based and should be validated with “real-world” data.

However, in that the model and related calculations resolve as an index, the values driving

degree of risk can be altered based on both empirical data and modeling convenience.


79

10.4. Calculation Section 10.310.3.2 introduced the fundamentals of a Cybersecurity Risk Index (CRI) taxonomy.

This section provides a way to apply the taxonomy as a calculation based on the standard

security risk equation to generate a risk index.

Cybersecurity Risk Index = Functions x Connections x Identities

where:

Functions: critical functions connected through digital communications links, considering:

• Function critical to preventing consequential impacts (e.g., critical to safe operations)

• Digital communication architecture linking functions as function sets

• Cardinality of linked function sets

Connections: digital access points (nodes) associated with function sets

• Access points penetrable by digital devices

• Access points penetrable by humans

Identities: Machine and human identities that can access a node

• Untrusted human identities

• Untrusted machine identities

To treat these variables mathematically, each is expressed numerically by counting the number

of instances of each within a virtual asset.

10.4.1. Special Case of the VLN Connection An important idea within this risk taxonomy is the idea of the VLN connection type. When

describing or reviewing the virtual asset architecture, any VLN connection to a function or

function set should be identified. This is important because when the VLN connection is added

to any other connection type, that connection type adopts VLN computational risk

characteristics and therefore becomes a VLN connection.

Although the VLN is listed as a Connection, it also bears consideration as an Identity because of

the threat posed by the potential for a very large number of unauthorized (i.e., untrusted)

identities accessing connected system each time an onboard identity logs on to a website

located on the Internet or any other wireless network. Further, even though connection with a

very large number of unauthorized wireless network identities is possible, the user realistically

connects with one (or a relatively small number of) machine identity at a time. This idea is

captured computationally in the taxonomy model by adding one unauthorized machine identity

for each authorized or unauthorized onboard identity that can connect through the VLN. The

mathematical influence within the model is to raise risk for each onboard identity that can

connect with a mirrored unauthorized identity through a VLN connection.

This approach is recognized as a simplistic treatment of risk created by a VLN connection. It

certainly deserves more research. But in the model as presented with this approach


80

accomplishes the purpose of directing the attention of a model user to the connections and

identities associated with the VLN connection.

The calculation shown in Figure 19 generates a relative risk score for each function set and an

overall score for the virtual asset itself.

Figure 19. CRI Calculation

Figure 20 illustrates several representative functions for a tank ship, and how they are

implemented using various onboard networks. This example tank ship will be used to illustrate

how the risk varies for different architecture options for the same functions (shown in upper

right corner of each figure).

Example 1: Segmented Architecture (Figure 21). Nearly all safety-critical functions (except the

Navigation System) are controlled by simple control systems that are isolated from the IT &

Crew Welfare Network and the internet. Access to safety-critical system components requires

physical connections through serial or Universal Serial Bus (USB) ports. This type of architecture

has lower risk exposure than those that are more integrated.

Example 2: Integration of Safety-critical OT Systems (Figure 22). In this architecture option, the

Propulsion & Steering, Ballast, and Power Systems have been integrated through an alarm

management system to provide automated monitoring and alarms to crew. All the safety-

critical functions are still isolated from the IT & Crew Welfare Network and the internet.

Example 3: Inadvertent Integration of IT & OT Systems (Figure 23). This architecture

demonstrates how cyber risk can be inadvertently introduced through improper configuration.

A printer is connected to the power system to periodically generate logs of system performance.

The printer’s wireless is not disabled resulting in an inadvertent connection to the IT & Crew

Welfare Network. Based on the methodology, this connection results in adding the Propulsion &

Steering, Ballast, and (3) Power Systems to the IT & Crew Welfare Network function set, which is

categorized as VLN. This significantly increases cyber risk to the virtual asset


81

Figure 20. Virtual Asset Diagram


82

Figure 21. Example 1: Segmented Architecture


83

Figure 22. Example 2: Integration of Safety-critical OT Systems


84

Figure 23. Example 3: Inadvertent Integration of IT and OT Systems


85

The research team developed a spreadsheet evaluation tool to observe attribute inputs and perform the

risk calculations. The tool enables capture of the following inputs:

• Categorization and counts of essential functions

• Connection categorization of digital network architectural designs that enable communications

among those Functions

• Counts of Function Sets as defined by Connection types

• Counts of cardinal members of each Function Set

• Counts of vulnerable and invulnerable Connection access points

• Counts of trusted and untrusted digital and human identities

Based on these inputs, the tool generates a variety of outputs to help users understand the virtual asset

and its risk profile:

• Number of vulnerable and invulnerable connection access points onboard the asset

• Average cardinality of function sets onboard the asset

• Total functions onboard the asset

• Risk for each function onboard the asset (best used for troubleshooting security of each

function)

• Average risk for each function onboard the asset

• Risk for each function set onboard the asset

• Average risk for each function set onboard the asset (best used to establish the overall asset

risk)

Figure 24 illustrates the spreadsheet evaluation tool populated with the assessment data for the three

example architectures.


86

Figure 24. Populated Spreadsheet Evaluation Tool for Example Architectures 1, 2, & 3

Outputs of the worksheet calculations are useful for various cybersecurity system remediation and

design purposes. The two histograms are the resultant risk profiles for the three example architectures

Figure 25 shows the relative risk for each function set for Example 1. Each bar is the summation of the

risk for the member functions categorized by the function sets. These values can be used to prioritize

potential remedial action for functions in the set, the network linking the functions within the set, the

nodes providing access to the set, or the identities accessing the set. The observer can use the

worksheet to analyze specific results and determine if the value(s) contributing to the overall result is an

operational problem (e.g., untrusted identities) and/or a protection problem (e.g., unprotected nodes) –

or, is a design problem such as large set sizes, complex connection types, or untrusted digital identities,

such as mobile devices or the Internet. With minimal interpretation, analysts can identify and focus on

potential corruption vectors and apply solutions to reduce risks.


87

Figure 25. CRI for Each Function Set

Figure 26 provides risk results at the next level of detail for individual Functions. The example below

provides very clear indication of which individual functions contribute the most risk to the control

system, and should therefore be given priority in a security improvement program. By focusing on only

15% – 23% of the control system functions, the overall security of the system can be improved

significantly. For example, by looking at the detailed data, an analyst can quickly recognize that the

number of untrusted identities that can access the function, only a single access point that is vulnerable,

and membership in a 7-Function Set make that Function a high risk to the system. Close inspection of

the function may provide insights that justify the design and operational choices; however, management

is alerted to the potential risk inherent in those choices and can make an informed decision about

remedial actions.


88

Figure 26. CRI for Each Functions

10.5. Application The risk metrics presented above provide a few examples of how countable indicators of risk can be

applied, but there are many other applications. The model elements of Functions-Connections-

Identities can be further deconstructed to yield more specific (and arguably useful) types of information.

The simplistic view of function sets can be supplanted by set theory calculations that could include set

ordinals ranked based on relative criticality of each set member, and therefore prioritize

countermeasure expenditures on protections within sets. With more research and empirical validation,

the risk values associated with nodes can be varied based on node types (e.g., HMI, serial port, USB port,

or wireless). The same is true for connection types. The relative risk factor selections associated with

connection types in the example case should be subjected to real-world examples and experimentation.

Complex and VLN Connection types may be far riskier than the current multiplier factors examples

indicate. Research and experimentation is needed to refine the factors.

Lastly, the notion of “Identity-as-Threat” merits much more research. When critically reviewed, the

MTSA regulation stresses the need for strict identity management of humans, vessels, and cargo.

However, the regulations offer little guidance for human-related identity management parameters that

clarify the meaning of “trusted identities” for personnel, and provides no guidance on management

parameters for machine trusted identities.

In the simple form presented in this research, the notion of human identity is binary at only two

evidential observation points. At the first point, trust is defined by the question, “Is the accessing

person on the authorized access list, or not?” At the second point, trust is further defined by the

question, “Is the person in the learning management system record as having been trained in

cybersecurity, or not?” If those questions are both answered affirmatively, the human identity is

declared to be trusted; but, this simple model provides no guidance or deeper insight into trust


89

verification and validation points based on role (need to access), background checks, access

minimization, access profiling, etc. Further, the implications of Identity-as-Threat are sufficiently

important now, when human identity trust determination is mostly referring to onboard crew. As

autonomous vessels come into widespread use, and as identity security becomes more of a shore-based

issue, these and other identity management issues will become even more critical.

Equally critical are machine or digital identity issues. At the top of machine identity risk is arguably the

Internet. It is best understood as a virtual machine containing billions of untrusted identities. It

increasingly accesses vessels and OT systems. Vendors may connect to assets over the internet for

remote condition monitoring and maintenance. Mobile wireless devices can access vessel functions and

the internet. The lowest level of machine identity is possibly a USB drive. It represents a machine

identity that can, and frequently has, bridged the air gap between systems.

From the Internet to the USB memory stick, digital machines must be trusted or regarded as threats and

excluded from accessing critical systems. As with humans, machine identities must be trusted, or

considered a threat.

10.6. Conclusion In conclusion, the taxonomy and tool presented in this section are useful; but, deeper research and real-

world application is needed to refine the approach. The model provides traction for continued

development of quantifiable and actionable information to decision makers. It is intended to focus

cybersecurity research and practice on patterns and potential sources of readily observable

characteristics of the virtual asset, but even more importantly, it is intended to provide a consistent,

clarifying, and countable method for organizing thinking about maritime cybersecurity risk.


90

11. Maritime Cyber Deterrent Strategy Effectiveness This section introduces a methodology and model to conduct a quantitative risk analysis of a wide

portfolio of assets spanning multiple asset classes, including vessels and facilities of different types. The

methodology was primarily designed for use by the USCG in their regulatory role but could be useful for

owners/operators of large and diverse fleet of assets to help understand this risk exposure and evaluate

different courses of action to manage the risk.

11.1. USCG Risk Assessment Models

The foundation of the methodology in this section is risk analysis; so, the team researched other risk

models the USCG has previously developed. The USCG has been steadily building, over the course of

many years, its risk analysis and risk management capabilities – beginning with the roll-out of the USCG

Risk-based Decision-making (RBDM) Guidelines. RBDM is a process that organizes information about the

possibility for one or more unwanted outcomes into an orderly structure that helps decision makers

make more informed choices.

The RBDM Guidelines were foundational research that provides a comprehensive set of methods, tools,

training, and supporting materials designed to support a variety of decision making activities, including

developing regulations and conducting compliance inspections. The wide array of risk methods and

tools covered in the RBDM Guidelines provides USCG personnel with a variety of risk methods and tools

designed for specific decisions that need to be made.

The USCG continued to evolve its risk management capability and has been consistently recognized as a

leader in DHS and the federal government in the area. The following sections will highlight several risk

management studies/programs, many of which are related to physical security (e.g., maritime terrorism

issues). Collectively, they represent an evolutionary cycle that can be emulated to understand and

manage cybersecurity risk. Figure 27 illustrates the agency’s evolution through 6 of its select risk

models. These models fall into three categories: (1) asset-specific physical security risk models, (2)

strategic physical security risk models, and (3) strategic all-hazard risk models. The following sections

will describe each model in more detail


91

Figure 27. Evolution of USCG Risk Models

11.1.1. Port Security Risk Assessment Tool (PSRAT)

Date

November 2001

Sponsors

• USCG Research & Development Center

• LANTAREA

Purpose

PSRAT was developed shortly after the attacks of September 11th, 2001 to inform decisions in the

execution of the Ports, Waterways, and Coastal Security (PWCS) mission. PSRAT was deployed to USCG

field units across the country to evaluate the assets operating within the AORs against an array of

potential terrorist attacks. The results of the initial PSRAT analysis were used to identify maritime

critical infrastructure to focus USCG activities. While the PSRAT methodology included the ability to

evaluate risk across multiple missions, the analysis was focused almost solely on the PWCS Mission by

evaluating the risk of a variety of potential terrorist attack scenarios. A scenario in PSRAT was defined as

an attack against a specific asset operating in the U.S. maritime domain.

11.1.2. National Risk Assessment Tool (NRAT)

Date

March 2002


92

Sponsor

USCG Commandant Planning & Policy (Resource Director) (G-CPP)

Purpose

NRAT was developed to support the USCG budget build process. Specifically, NRAT was a strategic

maritime terrorism risk profile. This risk profile was used to screen PWCS-related resource proposals as

part of the budget build process. This process mapped the relationships between resource proposals and

maritime terrorism risk and identified resource proposals with strong risk reduction potential.

The analysis was focused almost entirely on physical security by evaluating the risk of a variety of potential

terrorist attack scenarios. A scenario in NRAT was defined as an attack against representative assets

operating (e.g., Commercial Passenger Vessels: Ferry boats) in the U.S. maritime domain.

11.1.3. National Maritime Strategic Risk Assessment (NMSRA)

Date

2004, 2006, 2009, 2012, 2014, 2015, 2016, & 2017

Sponsor

Office of Performance Management and Assessment (CG-DCO-81)

Purpose

The NMSRA is a broad horizontal risk assessment across the USCG’s enduring roles of Safety, Security and

Stewardship and inclusive of all missions that analyzes:

• USCG Risk Reduction: the risk that is avoided due to USCG activities

• Residual Risk: the risk (expected societal loss) that remains after the USCG has performed all of

its activities.

The NMSRA process has evolved with each cycle by: (1) increasing the scope of the assessment, (2)

improving the quality of the risk information, and (3) reducing the amount of analysis effort required to

perform the assessment.

Objectives

The NMSRA meets the following high-level objectives:

• Develop comprehensive risk profile that can be used to inform a wide variety of resource

allocation decisions within and across missions.

• Provide an alternatives evaluation capability which enables analysts to assess risk management

strategy options

• Identify data sources used to inform risk assessment that are not stored in authoritative USCG

databases

Scope

The analytical boundaries of the NMSRA are:

• All Hazards. The NMSRA evaluates a broad set of undesirable incidents and scenarios spanning

the entire USCG mission set. The analytical scope addresses all hazards that the USCG has a role

in mitigating considering governing statutes, mandates, roles and missions.


93

• National Level. Risk profiles are developed at the national level, and for most missions, profiles

are not broken down geographically (e.g., Districts).

• Strategic Timeline. Since the results are primarily intended to inform mid/long-term resource

allocation decisions, the NMSRA analyzes risk 5 years into the future to inform the 5-year Future

Years Homeland Security Program (FYHSP) budgetary cycle.

• Low Fidelity. The NMSRA process generates coarse estimates of risk. The risk profiles are

accurate but are not generated with high precision. Therefore, NMSRA data is often unsuitable

for performing incremental analysis for small scale resource allocation options. For instance, since

reprogramming individual assets rarely affects any national risk profile; NMSRA does not have the

fidelity to measure the impact.

11.1.4. MSRAM

Date

2005 – Current: conducted through annual cycles

Sponsor

Domestic Port Security Division (CG-PSA-2)

Purpose

MSRAM is a terrorism risk management tool and process deployed to USCG analysts across the country

enabling them to perform a detailed risk analysis for their area of responsibility. The results of this

process are used to support a variety of risk management decisions at the strategic, operational, and

tactical levels.

The execution of the MSRAM process across the country yields an extensive national dataset containing

risk evaluations of a wide array of scenarios for all of the significant assets operating in the U.S. maritime

domain. MSRAM offers a dynamic analysis interface capable of generating tailored results to support a

variety of decisions. Results include:

• Risk-ranked lists of targets and scenarios

• Counts of targets and scenarios at similar risk levels

• Comparisons of scenario risk with and without government contributions

• Risk reduction value of maritime security stakeholders, including owners/operators, local law

enforcement, first responders, and the USCG\

• Geographic Information System (GIS) layers displaying maritime terrorism risk

11.1.5. Layered Return-on-Investment (L-ROI) Model

Date

2005 – 2009: conducted through annual cycles

Sponsor

Office of Performance Management & Assessment (DCO-81)

Purpose

Based on strategic guidance to use risk analysis and risk management, DCO-81 developed a proxy measure

of USCG performance using scientifically valid probabilistic risk assessment techniques. Beginning in 2005,


94

the USCG developed the approach and supporting L-ROI model to estimate USCG risk reduction

performance in the PWCS mission. LROI is a simplified, scenario-based, event tree model used to:

• Illustrate the layered security strategy that the USCG provides against each meta-scenario to

prevent, protect, respond, and recover

• Define the roles of USCG activities and how they relate to one another (e.g., detection,

intervention)

• Calculate the magnitude of risk that is being reduced by the layered security strategy (outcome

measure for the PWCS Mission)

• Provide a mechanism for estimating the risk reduction importance of individual activities within

the layered security strategy for a scenario

From 2005-2009, the outputs of the L-ROI model were promulgated as the official measure for USCG

performance in the PWCS mission. Specifically, the outcome measure reported (1) percent of USCG risk

reduction of USCG-owned risk, as well as USCG risk reduction with respect to (2) threat, (3) vulnerability,

and (4) consequence.

11.1.6. PWCS Risk-Based Performance Model

Date

2010 – Current: conducted through annual cycles

Sponsor

Office of Performance Management & Assessment (DCO-81)

Purpose

Beginning in April 2010, DCO-81 initiated an effort to make improvements to the L-ROI model and

processes the USCG has developed to (1) assess risk in the PWCS mission, (2) evaluate USCG performance

within the mission, and (3) evaluate the effectiveness of USCG planning, programming and budgeting

recommendations in terms of risk reduction.

Specifically, the effort involved improving the L-ROI model and process to make them more:

• Institutionalized by being integrated within the USCG’s enterprise PWCS risk management system

of record, the MSRAM

• Transparent to data analysts and decision makers

• Repeatable to generate consistent year-to-year results

• Auditable by third parties

• Sensitive to smaller changes in USCG performance

• Usable by a wider array of USCG analysts

11.2. Cyber Decision Support Requirements Congress passed the MTSA giving the USCG the authority to regulate security for vessels, facilities, and

OCS facilities operating on or adjacent to the U.S. MTS. The USCG later promulgated MTSA’s

implementing regulations (33 CFR Parts 101-106). The key requirements for the different types of assets

are addressed in the following parts:

• U.S. flagged vessels (33 CFR Part 104)


95

• Facilities (33 CFR Part 105)

• Offshore platforms (33 CFR Part 106)

There are numerous requirements described in these parts covering a wide array of security program

facets (e.g., training, recordkeeping, incident reporting). Of particular interest to this research are the

requirements mandating that a MTSA-regulated vessel/facility complete a VSA or FSA. The assessment

must identify and evaluate critical assets, potential threats, and general security vulnerabilities. The

vessel/facility must then develop and submit a VSP or FSP to the USCG that addresses the vulnerabilities

identified in the VSA/FSA.

The MTSA regulations do not explicitly address cyber; so, to clarify, in July 2017, the USCG issued draft

policy in Navigation and Vessel Inspection Circular (NVIC) 05-17, titled: Guidelines for Addressing Cyber

Risks at MTSA Regulated Facilities. The NVIC clarifies existing regulatory requirements in 33 CFR parts

105 and 106 to explicitly address cybersecurity measures in the facility security assessment and facility

security plan.

In accordance with 33 CFR parts 105 and 106, MTSA-regulated facilities are instructed to analyze

vulnerabilities with computer systems and networks in their FSA. This NVIC will assist FSOs in

completing this requirement. Additionally, this NVIC provides guidance and recommended

practices for MTSA regulated facilities to address cyber related vulnerabilities. Until specific

cyber risk management regulations are promulgated, facility operators may use this document

as guidance to develop and implement measures and activities for effective self governance of

cyber vulnerabilities.

The NVIC assists the owner/operator in identifying cyber systems that are related to MTSA regulatory

functions, or whose failure or exploitation could cause or contribute to a Transportation Security

Incident (TSI). A TSI is defined as: a security incident resulting in a significant loss of life, environmental

damage, transportation system or economic disruption. The traditional emphasis of cybersecurity is the

prevention of information theft and ensuring the integrity of business systems (e.g., corporate

Websites, accounting systems) where TSIs are focused on scenarios that could result in or contribute to

physical consequences or port disruptions.

While the NVIC is focused on shore side and OCS facilities, the USCG is working in coordination with the

IMO to address cybersecurity for vessels as well. IMO has given vessel owners/operators until January

1, 2021 to incorporate cyber risk management into their safety management systems.

So, the NVIC cements the USCG’s role in cybersecurity is one of regulatory oversight for assets that

operate in the U.S. MTS to ensure that owner/operator of these assets have identified and addressed

vulnerabilities that could cause or contribute to a TSI.

The question going forward is how can USCG offices responsible for development of cybersecurity

policies (and potentially regulations) develop strategies that best reduce maritime cybersecurity risk

while balancing cost of implementation.

These offices need the ability to (1) understand the relative risk priorities of potential cybersecurity

scenarios, (2) contextualize and prioritize the risk of cybersecurity within the USCG’s PWCS mission and

ultimately within the enterprise risk portfolio which spans the 11 statutory missions, and (3) assess the

impact of potential deterrent strategies on the cybersecurity risk profile.

https://www.regulations.gov/document?D=USCG-2016-1084-0002

https://www.regulations.gov/document?D=USCG-2016-1084-0002


96

While qualitative information can help guide policy and regulatory decisions, quantitative results are

preferable, and ultimately required, if the USCG wishes to promulgate new cybersecurity regulations.

To date, there has not been a cyber-initiated TSI in the U.S.; so, the USCG lacks sufficient data on which

to make these decisions. So, a strategic model is needed. One that rises above the assessment of risk

for individual assets or even fleets to considering cybersecurity risk in the entire U.S. maritime domain.

11.2.1. Needed Information Decision makers need a cyber risk model that generates results with the following attributes:

• Quantified. Cyber risk must be quantified to enable comparison with other security and non-

security incidents in the USCG (and DHS) mission space. Risk expressed as an absolute expected

annual loss is an ideal metric to enable comparison with other security and non-security

missions. Relative risk metrics can also be useful for establishing policy that targets certain asset

types.

• Consequence-informed. The relative risks generated by the model described in Section 10 of

this document are useful for prioritization of similar assets for inspection and/or mitigation, but

a quantification of consequence potential is needed to prioritize across asset types. For

example, failure of a cargo management system can result in very different consequences for a

chemical tanker vs. an oil tanker.

• Security and Safety. The model must consider both intentional (e.g., cybersecurity) and

accidental (e.g., cybersafety) events

• Residual Risk and Risk Reduction. The model must characterize owner/operator risk reduction

as well as residual risk.

• Asset Classes and Functions. The risk profiles must be able to be viewed by asset and function

to develop and prioritize strategy alternatives.

• Impact of alternative strategies. Methodology must support characterizing the impact (in

terms of risk reduction) of alternative strategies to help decision makers choose those with the

best return-on-investment potential

o Ideally, show X amount of residual risk in the mission set.

o Option 1: risk is reduced by Y amount

o Option 2: risk is reduced by Z amount

11.3. Application The development and steady evolution of the risk models described in section 11.1 provides a blueprint

that could be employed to establish and steadily improve the USCG’s understanding of cybersecurity

risk as well. The model presented in the following sections build off of the functions-connections-

identities (FCI) concepts presented in sections 9 and 10 of this report to a higher level of abstraction.

The relative risk index presented in section 10 is analogous to PSRAT and its successor MSRAM which

focus on individual assets. The model presented in this section is a method for a national, strategic

assessment analogous to the L-ROI and PWCS Risk-Based Performance Model and ultimately, the

NMSRA.


97

11.4. Model The strategic model described in this section follow the approach and evolution of the physical security

models by estimating risk for asset classes vs. individual assets. The model employs a stochastic

approach to account for the wide variability in expected outcomes. By representing different potential

random outcomes using probability distributions, model results better account for the fact that various

real-world situations are rarely the same. By running a model over a large number of iterations with

each iteration drawing different results from defined probability distributions allows a user to better

understand trends and expected outcomes over time.

Stochastic modeling is particularly relevant when multiple factors exhibit variability and there is a desire

to understand how these fluctuations interact to produce results. As an example, in the instance of

cyber modeling, probability distributions may represent observed differences in connectedness within

an asset class as well as the distribution of different consequences should a cyber incident occur.

Repeatedly running the model, taking into account the “dice roll” results for each probability

distribution, and then consolidating the final results provides the analyst with a sense of “spread” for

those results and allows use of statistical techniques (e.g. mean, median, standard deviation) to

interpret the modeling outputs.

The model includes threat, vulnerability, and consequence (TVC) risk factors aligned to the FCI elements.

The various nuances of maritime cyber risk require the designation of several sub-factors for threat,

vulnerability, and consequence. Each sub-factor has a distribution of values associated with it. In early

iterations, the distributions should be representative of experts understanding of the current state of

maritime industry based on experience reviewing and assessing maritime assets. Over time, these

distributions could be developed based on data collected from assessment of individual assets using the

model from Section 10.

11.4.1. Scenarios In the model, scenarios should be defined as exploitation of safety-critical functions that could credibly

lead to a TSI. Table 12 lists the scenario set based on the team’s identification of the common functions

of various vessel and facility asset classes. Scenarios are defined as combinations of the first two

columns, for example:

• Exploitation of Propulsion System/Freight Ship

• Exploitation of Cargo Management System/Tank Ship

• Exploitation of ICS/Waterfront Facility


98

Table 12. Cyber Scenario Framework

Asset Classes Incidents: Safety-critical Function Exploitation Event Potential Consequences

Commercial Vessel Communities: Systems found on most commercial vessels

• Freight Ship

• Industrial Vessel

• Mobile Offshore Drilling Unit

• Offshore Supply Vessel

• Passenger (More Than 6)

• Public Tankship/Barge

• Public Vessel, Unclassified

• Research Vessel

• School Ship

• Tank Ship

• Towing Vessel

Propulsion System: Increase or decrease speed at critical moments during port transit or extreme weather at sea

• Grounding

• Collision/Allision

• Flooding/Sinking

• Loss of life/injuries to crew and passengers

• Vessel damage

• Spill of fuel oil

• Channel blockage Steering/Maneuvering Control System: Take vessel off course at critical moments during port transit or extreme weather at sea

Navigation Systems: Take vessel off course at critical moments during port transit

Power Management System: Lose power or overpower vessel at critical moments during port transit or extreme weather at sea

Ballast Control System: Facilitate improper loading, causing listing or potentially exceeding hull loading limits

Tank Ship Cargo Management System: Open valves to release of oil, refined product, or certain dangerous cargo (CDC) during port transit

• Oil, refined product, or CDC spill

• Spill of oil, refined product, or CDC

• Navigation restriction

• Loss of life to crew and nearby populations

• Evacuation of port areas


Mobile Offshore Drilling Unit

Dynamic Positioning System: Take MODU off station at critical moments during drilling operations

• Emergency disconnects

• Loss of well control

• Spill of oil and drilling mud in the riser


• Loss of life/injuries to crew Drilling Control System: Affect drilling system performance at critical moments during drilling operations

Vessel Management System: Effect MODU ballast, causing vessel to go off station at critical moments during drilling operations

Waterfront Facility (Bulk Liquid) ICS: Open valves to release oil, refined product, or CDC from facility’s processing or storage equipment

• Oil, refined product, or CDC spill

• Spill of oil, refined product, or CDC



99

Asset Classes Incidents: Safety-critical Function Exploitation Event Potential Consequences

• Loss of life to crew and nearby populations

• Evacuation of port areas


Waterfront Facility (Container Terminal)

Crane Control System: Affect crane system performance at critical moments during container loading/unloading operations

• Container drop

• Crane damage

• Loss of life/injuries to workers

• Crane damage, resulting in reduced port throughput

Terminal Operating System: Unavailability of terminal operating system or corruption of data. Improper loading of container, affecting ship stability

• Inability to load or unload cargo

• Port disruption


100

11.4.2. Threat To model and quantify threat, the research team chose four sub-factors shown in Figure 28 and

described below.

Figure 28. Threat Sub-factors

Asset Class Size

Asset Class size is a scaling sub-factor designed to account for the estimated number of assets in a given

class. This represents the number of opportunities for system exploitation, commensurate with a class’s

size. For example, with all factors being equal, if there are many more tank ships than MODUs, then a

safety-critical functional failure is more likely to occur on a tank ship as opposed to a MODU because

there are more opportunities. This value is the count of assets in a class divided by the total number of

assets across all asset classes. Class data can be derived from a number of authoritative government

data sources:

• USCG MISLE vessel registries for domestic vessels

• USCG Ship Arrival Notification System for foreign vessels

• MSRAM for waterfront facilities

• BSEE platform structures for platforms and mobile offshore drilling units

Target Attractiveness

The target attractiveness sub-factor is designed to capture attacker preference’s for attacking certain

asset classes. This sub-factor applies values ranging from zero to one providing relative measure for how

likely an adversary is to target an asset class. This can be assigned based on specific threat data, if

available.

Function Attractiveness

Function attractiveness is designed to quantify and capture the adversarial capability to exploit a given

safety-critical function; that is, the capability required to successfully cause a functional failure for a

given class via digital attack vectors. This value is function-specific and uses a zero to one scale to

account for the relative attractiveness of each function to an adversarial.

For example, if a terminal operating system requires less technical expertise to exploit than a drilling

control system, attackers may be more likely to attempt an attack on a terminal operating system. It is

important to note that the research team has not yet found a reliable data source for this value; it may

be an area for future data exploration in future iterations of the model.


101

Exposure Window

To achieve a TSI-level of consequences for a particular scenario, most attacks must occur within a time-

sensitive window. For example, if a navigation function is compromised, an incident such as a grounding

or collision will be more likely to occur, and with greater consequences, in restricted waters as opposed

to open ocean.12

The model should assign an exposure window category or distribution to each asset class/safety-critical

function pair. Consider the simple example below, where exposure windows are defined in three

categories:

• High (90%): attack does not require precise attack timing or systems are susceptible to TSI

consequences with passive corruption

• Medium (50%): attack requires specific attack timing

• Low (10%): attack requires precise attack timing or requires persistent remote connection

Table 13 provides example exposure window assignments for several asset class/safety-critical function

pairs:

Table 13. Example Exposure Window Assignments

Function Asset Class Exposure Window

Propulsion Freight Ship Low

Steering Freight Ship Low

Navigation Freight Ship Low

Propulsion Passenger (more than 6) Medium

Steering Passenger (more than 6) Medium

Navigation Passenger (more than 6) Medium

Terminal Operating Waterfront Facility High

ICS Waterfront Facility Medium

Drilling MODU Medium

Threat Results

The model selects a value for target attractiveness and function attractiveness, each of which are fixed

between zero and one, and then multiplies the selected values by the asset class size and exposure

window values, which are scenario-specific, in order to arrive at the threat value. This random-value

selection and calculation process is repeated a number of times to arrive at a predicted threat value for

the final risk calculation.

11.4.3. Vulnerability Vulnerability assessment accounts for two primary sub-factors: system connectedness and non-cyber

mitigating factors, as shown in Figure 29.

12 The exposure window conceptual framework was developed through interviews with industry and input from ABS SMEs who have performed many cyber assessments on a wide range of maritime assets.


102

Figure 29. Vulnerability Components

Connectedness

Connectedness captures the risk posed by the degree to which digital systems – especially those that

govern safety-critical functions – are linked. Each safety-critical function is enabled by a system or set of

systems. These systems exhibit varying degrees of connectedness. Generally, the more connected a

system is, the higher the vulnerability. The model uses four connectedness categories presented in

Section 9:

1. Discrete – A single (1:1) digital connection only between a single equipment controller and a

single piece of controlled equipment

2. Simple – More than one connection between a single equipment controller and more than one

other equipment controllers, but not through a network

3. Complex – More than one digital connection to a network linking only equipment controllers

and associated interfaces

4. VLN – Any of the above type connections that are also connected to the Internet or any

potentially accessible proprietary wireless connection

Table 14 provides several examples of connectedness assignments for asset class/ function pairs based

on input from ABS maritime cybersecurity assessors:

Table 14. Connectedness Assignments by Asset Class and Function

Asset Class Function Simple Discrete Complex VLN

Freight Ship Propulsion 80% 19% 1% 0%

Mobile Offshore Drilling Unit Propulsion 5% 70% 23% 2%

Offshore Supply Vessel Propulsion 60% 35% 5% 0%

Passenger (More Than 6): Cruise Propulsion 5% 20% 40% 35%

Tank Ship Propulsion 80% 19% 1% 0%

Freight Ship Steering/Maneuvering 5% 70% 25% 0%

Tank Ship Steering/Maneuvering 15% 60% 25% 0%

Towing Vessel Steering/Maneuvering 45% 50% 5% 0%

Freight Ship Navigation 5% 60% 33% 2%

Mobile Offshore Drilling Unit Navigation 0% 10% 90% 0%


103

Asset Class Function Simple Discrete Complex VLN

Passenger (More Than 6): Cruise Navigation 0% 10% 70% 20%

Tank Ship Navigation 5% 60% 33% 2%

Freight Ship Power Management 60% 30% 5% 5%

Mobile Offshore Drilling Unit Power Management 10% 30% 55% 5%

Passenger (More Than 6): Cruise Power Management 0% 30% 65% 5%

Tank Ship Power Management 60% 30% 5% 5%

Freight Ship Ballast Control 5% 50% 45% 0%

Mobile Offshore Drilling Unit Ballast Control 5% 40% 55% 0%

Passenger (More Than 6): Cruise Ballast Control 0% 45% 45% 10%

Tank Ship Ballast Control 5% 50% 45% 0%

Tank Ship Cargo Management 5% 75% 20% 0%

Freight Ship Cargo Management 5% 75% 20% 0%

Mobile Offshore Drilling Unit Dynamic Positioning 0% 0% 95% 5%

Mobile Offshore Drilling Unit Drilling Control 0% 10% 70% 20%

Waterfront Facility: Bulk Liquid Industrial Control 20% 70% 10% 0%

Container Terminal Terminal Operating 0% 0% 0% 100%

Container Terminal Crane control 90% 8% 2% 0%

Industrial Vessel Dynamic Positioning 0% 40% 60% 0%

Offshore Supply Vessel Dynamic Positioning 0% 60% 40% 0%

Passenger (More Than 6): Cruise Dynamic Positioning 0% 0% 80% 20%

Research Vessel Dynamic Positioning 0% 60% 40% 0%

Non-Cyber Mitigation Measures

If an asset’s vulnerabilities are exploited, there are often actions that personnel may take to compensate

for the loss of automated functions to avoid an incident or mitigate consequences upon discovery of a

problem. These capabilities are often highly effective at mitigating a successful system exploitation or

functional compromise. Examples of these capabilities include13:

• Ship Handling Functions involve humans-in-the-loop, and there are manual overrides for critical

vessel functions on the bridge, in the engine room, or in the steering compartment. The crew

can switch automated functions to manual mode to pilot the vessel to safety.

• Local Pilots are aboard foreign commercial vessels when navigating U.S. ports. These pilots are

intimately familiar with their port environments making them far more likely to recognize

anomalies in the vessel’s navigation system due to cyber exploitation.

• Material Transfer Operations to/from vessels are required by USCG regulations to involve

persistent oversight by a facility and a vessel person-in-charge (PIC). The PICs each monitor their

systems and coordinate actions throughout the transfer process via handheld radio. Often

13 Examples are based on extensive interviews with industry and input from ABS SMEs who have performed many cyber assessments on a wide range of maritime assets.


104

facilities will have another operator in the field monitoring tank level (e.g., local tank level

indicators) and flow rates.

The model should assign a category or distribution to each asset class/safety-critical function pair.

Consider the simple example below, where non-cyber mitigation capability is defined in three

categories:

• High (10%): Ample time to recognize functional failures and capability to manually perform

automated functions or place asset in a safe status

• Medium (50%): Limited capability to recognize functional failures with some capability to

manually perform automated functions or place asset in a safe status

• Low (90%): Limited/no capability to manually perform automated functions or place asset in a

safe status

Table 15 provides example assignments for several function/asset class pairs:

Table 15. Example Non-Cyber Mitigation Assignment

Function Asset Class Non-Cyber Mitigation

Propulsion Freight Ship High

Steering Freight Ship High

Navigation Freight Ship Medium

Terminal Operating Waterfront Facility Low

ICS Waterfront Facility High

Drilling MODU Medium

11.4.4. Consequences Since few cyber-initiated events have significantly impacted U.S. maritime assets at the time of writing,

the research team applied consequence assessments based on the results of historical non-cyber

incidents relating to each asset class and function pairing.

The USCG’s MISLE system documents incident data going back for decades which informs the frequency

and magnitude of consequences that could result from successful cyber attacks.

MISLE incident investigation data can be used to construct consequence distributions for the set of

scenarios. This data is gathered after a marine incident and documented the amount of oil and/or

chemicals spilled, the estimated property damaged resulting from the incident, and the number of

people injured, missing, or dead.

To capture the effect of obstructed or closed waterways as the result of an incident, data can be applied

from the USCG’s Common Assessment and Reporting Tool (CART) system, which is used to manage

incidents impacting the MTS. CART data provides a historical record allowing capture of the cause,

severity, and duration of waterway closures.

11.4.5. Types of Consequences & Results The model includes assessments for the following consequences caused by TSI:

• Environmental consequences – oil and/or chemicals spilled, in gallons


105

• Economic consequences – property damage, in dollars

• Death and Injury consequences – the number of people injured, missing, or dead

• Mobility consequences – disruption to waterway traffic

Each set of consequence evaluations is measured using consequence points based on the USCG

Consequence Equivalency Matrix (CEM). The consequence scores are then summed across impact types

to arrive at a total consequence vale for the risk calculation, as outlined in Figure 30.

Figure 30. Consequence Components

The consequence values for the four consequence types are determined by randomly selecting a value

from a Poisson (P(λ)) distribution, where the input λ is the mean value from the comparable scenario set

of MISLE incident data. That is, the team calculated the λ-value for the Poisson distribution by taking the

weighted average of the number of gallons of oil/chemicals spilled, the amount of property damage

caused, the number of people killed or injured, and the level of waterway impacts resulting from a

navigational failure aboard an OSV; each time the model runs, it randomly selects a value in the

distribution determined by P(λ). The idea is that since the model runs and performs these selections

many times (1000 times), the resulting modeled consequences will approach a “true” value.

11.4.6. Outputs & Results The model could multiple output measures and visualizations. Risk assessments may be viewed by

function, by asset class, and through various aggregations/combination assessments.

Exceedance Probability Curves

The model output includes exceedance probability (EP) curves for each scenario. An EP curve describes

the probability that various levels of loss will be exceeded. This is consistent with the USCG’s multi-

mission risk analysis approach. Figure 31 provides an example exceedance probability curve result.


106

Figure 31. Exceedance Probability Curve Example

Average Annual Loss

Average Annual Loss (AAL) is the mean value of an EP curve, and represents the expected loss per year,

as assessed over the outputs of many model iterations. This value gives an idea of the absolute

“riskiness” of cyber given the modeled asset classes, functions, and related system factors. The set of EP

curves aims to provide insight as to what is driving risk to the given asset class. Figure 32 provides an

example AAL result.

Figure 32. AAL Example


107

11.4.7. Cyber Deterrent Strategy Development The baseline risk profile generated by the model provides USCG policy makers with a portfolio-level view

of cybersecurity risk. By exploring this profile, analysts can identify high risk segments to develop cyber

deterrent strategy options. The model sub-factors and distributions can be adjusted by analysts to

reflect the impact of various policy options. This adjustment could be performed at any level of detail.

For example, policies or regulations may focus primarily on select asset classes or specific safety-critical

functions. So, analysts could make adjustments to the distributions and re-run the model to generate

risk results for each option, which could be compared to the baseline profile to characterize the

potential risk reduction.

Risk reduction estimates combined with implementation cost estimates are essential for the

development and selection of new regulations and policies.

12. Requirements for Maritime Cyber Range A well designed and implemented cyber range is a valuable capability for an organization to have to

simulate their networks and applications, spanning both IT and OT, to improve their cybersecurity

posture. Organizations can use ranges for a wide variety of purposes from application testing to

vulnerability identification and mitigation.

These simulated environments provide a safe and secure environment to assess their capabilities and

learn and optimize performance of cybersecurity measures. They are an essential part of research and

development where new monitoring strategies can be conceived and tested for efficacy. They can

simulate cyber events for exercises to train personnel-in real time response and recovery actions.

The scale of cyber ranges can vary dramatically from small-scale representations of systems to simulated

environments of the entire enterprise. They can include actual or virtual hardware and software

components, and depending on the scope, they can simulate network services and internet traffic.

The following sections will identify potential applications of cyber ranges to support USCG strategic

priorities, identify and summarize the capabilities of several relevant cyber ranges in operation, and

provide recommendations for the USCG going forward.

12.1. Strategic Priorities In its Cyber Strategy, which was published in June 2015, the USCG identified three strategic priorities

crucial to the service’s mission:

1. Defending Cyberspace. Secure and resilient USCG IT systems and networks are essential for

overall mission success. To ensure the full scope of USCG capabilities are as effective and

efficient as possible, the USCG must serve as a model agency in protecting information

infrastructure and building a more resilient USCG network.

2. Enabling Operations. To operate effectively within the cyber domain, the USCG must develop

and leverage a diverse set of cyber capabilities and authorities. Cyberspace operations, inside

and outside USCG information and communications networks and systems, can help detect,

deter, disable, and defeat adversaries. Robust intelligence, law enforcement, and maritime and

military cyber programs are essential to enhancing the effectiveness of USCG operations, and

deterring, preventing, and responding to malicious activity targeting critical maritime

https://www.uscg.mil/seniorleadership/DOCS/cyber.pdf


108

infrastructure. USCG leaders must recognize that cyber capabilities are a critical enabler of

success across all missions, and ensure that these capabilities are leveraged by commanders and

decision-makers at all levels.

3. Protecting Infrastructure. Maritime critical infrastructure and the MTS are vital to our economy,

national security, and national defense. The MTS includes ocean carriers, coastwise shipping

along our shores, the Western Rivers and Great Lakes, and the Nation’s ports and terminals.

Cyber systems enable the MTS to operate with unprecedented speed and efficiency. Those

same cyber systems also create potential vulnerabilities. As the maritime transportation Sector

Specific Agency (as defined by the National Infrastructure Protection Plan), the USCG must lead

the unity of effort required to protect maritime critical infrastructure from attacks, accidents,

and disasters.

Strategic priority 1 could benefit from a cyber range capable of simulating USCG systems and networks.

In such an environment, personnel from USCG CYBERCOM and other relevant offices could establish and

evaluate cybersecurity capabilities, exercise proposes and polices and procedures and train system and

network administrators in the test environment. Ideally, this environment could extend to address not

only IT networks, but also critical OT systems on cutters, boats, and aircraft.

Strategic priority 3 could be supported by a cyber range through simulation of common systems and

networks among regulated vessels, facilities, and platforms. In this test environments, government,

commercial, and academic researchers could test various configurations to determine critical

vulnerabilities to support policy and regulatory recommendations.

12.2. Cyber Ranges There are numerous government, academic, and commercial cyber ranges and cyber range solutions

that are already in operation. The team identified several and performed an in-depth review of those

most relevant to potential USCG application. They are introduced and described below based on

available literature and discussion with representatives, and visits by ABS personnel.


109

12.2.1. Government Cyber Ranges

U.S. Marine Corps (USMC) Cyber Security Range (CSR)

The USMC CSR, located in Stafford, Virginia, was chartered and funded by the

Comprehensive National Cybersecurity Initiative (CNCI) to develop and host a realistic

simulation of the DoD Information Network (DoDIN). The CSR is a fully accredited

environment for conduct of cyber training, testing and exercises to reduce risk to DoD

networks and systems. The CSR is capable of emulating complex DoD environments and

can be accessed onsite or remotely via a secure VPN tunnel.

The CSR can be used at no cost to the DoD customer, which

includes the USCG. CSR staff do not conduct actual testing,

evaluations or develop and deliver customer training. Rather,

these functions are performed by customers while CSR personnel

operate and maintain the environments required to execute

effective cyber tests and training.

The CSR provides a robust simulation capability with a wide array

of capabilities, including modular architecture constructs that

offer customer-configurable Security Technical Implementation

Guides (STIG) and non-STIG enclave machines running multiple

operating systems/patch levels. Tier 1 DoDIN replication with

multi-protocol support, Tier 2 boundary suites with industry

leading connection appliances, and Tier 3 interactive bases using

industry standard models (Core, Distribution, Access) are

offered.

Other capabilities include:

• Enterprise Information Assurance and Computer

Network Defense tools

• Network services

• Traceable and relevant traffic generation and threat injection enabling cyber forensics

• Virtual interactive Internet with 5000+ malicious and benign sites

• Accessible on-site in Stafford, VA and remotely

• Interoperable with other lab environments (National Cyber Range)

The DoD Cyber Security Range has supported missions for the USMC, Army, Navy, Air Force, Defense

Intelligence Agency, Defense Information Systems Agency, and the National Security Agency. The

research team visited the CSR and documented detailed questions and answers in Appendix F.

Air Force Multi-Application Practical Learning Environment (MAPLE)

The Air Force’s MAPLE range is a realistic network training range. Comprised of virtual

machines simulating a network enclave complete with a firewall, intrusion detection

software, and typical network web and email traffic. Malicious and unauthorized traffic

also transits the simulated network. Teams of operators can utilize monitoring tools to

detect, identify and mitigate the malicious and/or unauthorized traffic on the friendly

network while maintaining the legitimate web and email traffic.

Figure 33. USMC CSR Connectivity Diagram


110

MAPLE’s white force controllers monitor the range and provide support to the participants throughout

test and exercise activities. They will provide debrief of the team’s performance detailing traffic that

traversed the network and actions taken by the team. This is done to highlight best practices and lessons

learned that the team members can then apply to real world operations.

The MAPLE range is a training environment designed to emulate a realistic network where teams can

safely exercise the following:

• Detect malicious/unauthorized network traffic

• Identify the source of the ‘red’ traffic, and act to

• Mitigate the threat traffic while maintaining essential ‘blue’ web and email services.

The range is tool agnostic and encourages team members to rely on DCO techniques as opposed to tool

capabilities. Teams are not allowed to import their own tools onto the range. They are given an IDS, a

software firewall, and a network monitoring tool to meet their assigned objectives.

National Cyber Range (NCR)

The NCR provides the ability to conduct realistic cybersecurity testing, evaluation, and

training. The four key components of the NCR are: a secure facility, a unique security

architecture, integrated tools for cyber testing, and a multi-disciplinary staff. The NCR,

which is accredited by the Defense Intelligence Agency (DIA), provides an efficient and

affordable cybersecurity test infrastructure. Figure 34 provides a high-level overview of

the NCR.

Figure 34. NCR Overview


111

The NCR can represent complex network topologies with sufficient realism to portray a variety of

current and anticipated attack strategies. The NCR can rapidly configure a variety of complex network

topologies and scale up to 40,000 nodes. These nodes can include high-fidelity realistic representations

of the public internet infrastructure including highly detailed supporting web and email servers and

clients.

12.2.2. Academic Cyber Ranges

Louisiana State University (LSU) Joint Cyber Training Lab (JCTL)

The JCTL is focused on enhancing security IT and OT networks to minimize risks to

critical infrastructure. The JCTL provides tier III cyber range comprised of actual and

virtual hardware, software, and network devices that can simulate large-scale

networks. It was designed to incorporate State and Federal cyber response frameworks and programs

with a focus on critical infrastructure industries and private sector training. The JCTL was designed to

achieve the following objectives:

• Establish a Cyber Lab that replicates specific Industrial Control Systems, DoD and Non-DoD

Networks.

• Conduct Cyber Attack and Incident Response Exercises

• Offer Industry Specific Cybersecurity and Standards and Certification Coursework

University of Michigan Cyber Range (MCR)

The MCR is an unclassified private cloud operated by Merit. The MCR delivers

cybersecurity classes and exercises and enables product development and testing to

clients. The MCR leverages Merit’s network to conduct cybersecurity certification

courses, hold training exercises, and operate its Secure Sandbox service. Some of the

training and workshops offered by the MCR, include:

• Ethical Computer Hacking

• Digital and Network Forensics

• Network Penetration Testing

• Intro to Applied Cyber Security

Carnegie Mellon SEI Cyber Kinetic Effects Integration (CKEI)

The CKEI system combines a mature cyber simulator and a mature

kinetic simulator in a way that allows effects in one environment to

propagate to the other. This integration enables "whole-force training" in which cyber operators can

learn to support live missions, while dealing with the realities of operating in contested networks and

environments.

Within CKEI, systems can be attacked in cyberspace to produce a physical effect that provides a tactical

advantage to the kinetic operators. Conversely, kinetic operators can damage or destroy systems within

the kinetic simulator to deny cyber operators use of those systems in cyberspace.


112

12.2.3. Commercial Cyber Ranges

Mile2

Mile2 cyber range allows students to access the range online from anywhere and

experience a live simulated environment. This commercial application supports

cybersecurity exercises that simulate real world cyber security events. This capability

can train personnel on a wide variety of cybersecurity disciplines, including: penetration testing,

ethical hacking, incident handling, forensics, web application, virtualization and cloud computing

lab exercises. The platform provides the ability to use a wide variety of commercial and open source

tools.

IBM xForce

IBM xForce is a fully operational cyber range that simulates real-world attacks to train

cybersecurity personnel on how properly prepare for, respond to, and manage a wide array

of threats. The range uses live malware, ransomware and other real-world exploits culled

deliver realistic cyber-attack experiences. The facility features an air-gapped network of a

fictitious corporation, used for simulated attacks, consisting of one petabyte of information,

more than 3,000 users and a simulated version of the internet.

Raytheon Cyber Operations, Development and Evaluation (CODE) Center

The CODE Center is a cyber range used to test existing and future mission-

critical systems against cyber-attacks. It offers several relevant capabilities to

improve cybersecurity by enabling:

• Test and evaluate advanced technologies

• Conduct force-on-force cyber games/exercises

• Provide an engineering environment to integrate technologies

• Provide cyber professional training and exercises

12.3. Mission Support Use Cases

12.3.1. Use Case #1: Protection of USCG Networks & Assets. The need for non-invasive technologies to test, prove, and disprove protections of USCG networks and

assets may be met with the utilization of a cyber range. Cyber ranges may be comprised of many

different levels of fidelity, or depths of simulation. Cyber range fidelity can vary from a web presence, or

a desktop apparatus to a fully functional data center environment. Choices the USCG must make in

using a cyber range to test USCG networks and assets start with the “fidelity” question and are directly

related to the amount of budget - including facility and personnel expertise requirements to host a

cyber range.

Selection of an existing range is highly recommended as most existing cyber ranges have multi-year

investments in people, infrastructure, and learning. Mature desktop ranges are offered by at least one

university and the USMC high-fidelity cyber range demonstrated a high-level of process and setup/tear-

down automation in operating a range. The USMC range could “spin-up” an entire range in a matter of

minutes that had a high level of simulation including simulation of a military base including traffic

streams.


113

For USCG networks and assets, such as IT networks and the operational technologies aboard ships,

cutters, boats, and aircraft, a cyber range could provide out-of-band or offline cybersecurity testing of

critical systems. For example, a ship’s bridge systems could be fixtured in a cyber range and provide a

non-consequential platform as a basis for red/blue team activities or host crew incident response

training. A low-fidelity implementation could be entirely online. Or, a high-fidelity implementation

could include an actual electronic chart display, ship steering stand, radar, Global Positioning System

(GPS), voyage data recorder and other physical systems on a bridge.

• Users: CYBERCOM, CG-6, CG-9

• Scope: Simulating to varying levels of fidelity (asset, network, full scale) the network, network

traffic, and attacks/exploits, varying levels of fidelity (e.g., hardware vulnerabilities, commercial-

off-the-shelf and specialized applications, network configurations, monitoring)

• Applications: Red team/blue teaming, vulnerability assessments, performance testing

• Covered assets:

o USCG IT network

▪ Application servers

▪ Email servers

▪ Web servers

▪ Desktops

▪ Database servers

▪ Printers

o Cutters: IT and OT systems

o Boats: IT and OT systems

o Aircraft: IT and OT systems

• Recommendations:

o Document USCG usage requirements and leverage the infrastructure and learnings of

the USMC cyber range

o Instantiate simple scenarios in the USCG cyber range that encompass widely-known

threat vectors into USCG systems (e.g., phishing, USB, GPS spoofing) and train USCG

personnel in these actions and defenses

o Use the USMC cyber range to perform after-the-fact analysis of breaches or exploits to

gain new understanding of protections, controls, and defenses

o Use the USMC cyber range to train USCG cyber personnel (red/blue/white teams)

o Identify the inflection point where USCG should build their own cyber range

12.3.2. Use Case #2: MTSA-regulated assets The value of a cyber range to MTSA regulated community assets may rely on how the community

organizes and funds the development and ongoing costs associated with maintaining a cyber range.

There may be value in developing a specific, low-fidelity and/or specific use case cyber range to

understand vulnerabilities in the vessels, facilities, and platforms and possibly the interactions between

these entities to drive understanding for eventual inclusion in policy or regulatory work. Effort would

need to be applied to developing an “eco-system” for the use of a cyber range in this case.

One opportunity may be for the USCG to fund the development of a cyber range for use by Area

Maritime Security Committees to demonstrate vulnerabilities that could affect the members. For


114

example, a table-top range could simulate basic ship tracking utilizing Automated Information Services,

GPS, and ECDIS. Vulnerabilities in these systems could be exploited and demonstrate the effects of the

failures raising awareness. Any cyber range utilized in this manner would need to be generic in nature

as the specifications of most ship-board systems are highly engineered.

• Users: CYBERCOM, CG-FAC, CG-RDC, port tenants

• Scope: Simulating to low levels of fidelity (functional systems of an asset) for a commercial

asset: the network, network traffic, and attacks/exploits, low levels of fidelity (network

configurations, monitoring)

• Applications: Vulnerability assessments or demonstrations w/ results to inform awareness and

policy/regulatory development

• Covered assets:

o Vessels: IT & OT

o Facilities: IT & OT

o Platforms: IT & OT

12.4. Conclusion With so much variation asset to asset, company to company, and the availability of many DoD and

commercial ranges, there is not much value in the USCG pursuing building their own cyber range. The

availability of the USMC CSR at no cost and the high correlation between the USMC CSR capabilities and

perceived USCG requirements substantially reduces cyber range risk.

The USCG should encourage industry to develop their own cyber ranges and test environments,

particularly for operational technology to test and demonstrate cyber vulnerabilities.


A-1

A. Appendix. Updated NIST Framework Mapping Table A1 provides the detailed cross references from the Framework Core’s subcategories to the associated chapter or section in the mapped references. Dark blue columns are the newly-mapped references.

Table A1. NIST Framework Mapping

Subcategory IMO BIMCO ABS C2M2 NIST

800-82 DHS TSS CCS CSC COBIT 5

ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

Identify

Asset Management

ID.AM-1: Physical devices and systems within the organization are inventoried

3.5.1 3.4.1 ACM-1a ACM-1c ACM-1e ACM-1f

3.3.2 G1 1 BAI09.01, BAI09.02

4.2.3.4 SR 7.8 A.8.1.1, A.8.1.2

CM-8

ID.AM-2: Software platforms and applications within the organization are inventoried

3.5.1 P2 3.4.1 ACM-1a ACM-1c ACM-1e ACM-1f

3.3.2 G1 2 BAI09.01, BAI09.02, BAI09.05

4.2.3.4 SR 7.8 A.8.1.1, A.8.1.2

CM-8

ID.AM-3: Organizational communication and data flows are mapped

3.5.1 P5 3.4.1 RM-2g ACM-1e

3.3.2 G1 1 DSS05.02 4.2.3.4 A.13.2.1 AC-4, CA-3, CA-9, PL-8

ID.AM-4: External information systems are catalogued

3.5.1 P3 3.4.1 EDM-1a EDM-1c EDM-1e EDM-1g RM-1c

G1 APO02.02 A.11.2.6 AC-20, SA-9

ID.AM-5: Resources (e.g., hardware, devices, data, and software) are prioritized based on their classification, criticality, and business value

3.5.1 P3 1.4.2 ACM-1a ACM-1b ACM-1c ACM-1d

3.3.2 G1 APO03.03, APO03.04, BAI09.02

4.2.3.6 A.8.2.1 CP-2, RA-2, SA-14

ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established

3.5.1 P2, P3 1.4.1.1.2 WM-1a WM-1b WM-1c

2.4 G1 APO01.02, DSS06.03

4.3.2.3.3 A.6.1.1 CP-2, PS-7, PM-11

Business Environment


A-2



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

ID.BE-1: The organization’s role in the supply chain is identified and communicated

3.5.1 P2 3.4.2.3 EDM-1b EDM-1d EDM-1f EDM-1g RM-1c

2.4 G5 APO08.04, APO08.05, APO10.03, APO10.04, APO10.05

A.15.1.3, A.15.2.1, A.15.2.2

CP-2, SA-12

ID.BE-2: The organization’s place in critical infrastructure and its industry sector is identified and communicated

3.5.1 P1 1.4.2.1 EDM-1b EDM-1d EDM-1f CPM-1c EDM-1g RM-1c

4.1 G5 APO02.06, APO03.01

PM-8

ID.BE-3: Priorities for organizational mission, objectives, and activities are established and communicated

3.5.1 1.4.2.1 RM-3b RM-1c

4.1 G5 APO02.01, APO02.06, APO03.01

4.2.2.1, 4.2.3.6

PM-11, SA-14

ID.BE-4: Dependencies and critical functions for delivery of critical services are established

3.5.1 P3 1.4.2.2 ACM-1a ACM-1b EDM-1a ACM-1c ACM-1d EDM-1c EDM-1e ACM-1e ACM-1f RM-1c EDM-1g

2.3.1, 3.3.2, 3.3.6

G5 A.11.2.2, A.11.2.3, A.12.1.3

CP-8, PE-9, PE-11, PM-8, SA-14

ID.BE-5: Resilience requirements to support delivery of critical services are established

3.5.1 P3, P5 1.4.2.4, 2.4.1 IR-4a IR-4b IR-4c IR-4e

2.1 G5 DSS04.02 A.11.1.4, A.17.1.1, A.17.1.2, A.17.2.1

CP-2, CP-11, SA-14

Governance

ID.GV-1: Organizational information security policy is established

3.5.1 P2 ALL CPM-2g CPM-5d RM-3e

4.3, 4.4 G5 APO01.03, EDM01.01, EDM01.02

4.3.2.6 A.5.1.1 -1 controls from all families

ID.GV-2: Information security roles & responsibilities are coordinated and aligned with

3.5.1 1.4.1.1.2, 2.4.2.1, 2.4.3.1, 2.4.3.3

WM-1a WM-1b WM-1c WM-2d WM-5b

3.3.3 G5 APO13.12 4.3.2.3.3 A.6.1.1, A.7.2.1

PM-1, PS-7


A-3



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

internal roles and external partners

ISC-2b WM-1e WM-1f WM-1g

ID.GV-3: Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed

3.5.1 P1 12.4.2.1 CPM-2k IR-3n RM-3f ACM-4f IAM-3f TVM-3f SA-4f ISC-2f IR-5f EDM-3f WM-5f

4.3 G5 MEA03.01, MEA03.04

4.4.3.7 A.18.1 -1 controls from all families (except PM-1)

ID.GV-4: Governance and risk management processes address cybersecurity risks

2.1.6, 3.4, 3.5.1

P3 2.4.2, 2.4.3, 2.4.4

RM-2a RM-2b RM-2h RM-3e RM-1c RM-1e

3.1 G5 DSS04.02 4.2.3.1, 4.2.3.3, 4.2.3.8, 4.2.3.9, 4.2.3.11, 4.3.2.4.3, 4.3.2.6.3

PM-9, PM-11

Risk Assessment

ID.RA-1: Asset vulnerabilities are identified and documented

2.1.4, 3.5.1 P5; Section 2.1

3.4.1.3, 3.4.1.4, 3.4.1.5

TVM-2a TVM-2b TVM-2d TVM-2e TVM-2f RM-1c RM-2j TVM-2i TVM-2j TVM-2k TVM-2l TVM-2m

Appendix C G1, P1-1 4 APO12.01, APO12.02, APO12.03, APO12.04

4.2.3, 4.2.3.7, 4.2.3.9, 4.2.3.12

A.12.6.1, A.18.2.3

CA-2, CA-7, CA-8, RA-3, RA-5, SA-5, SA-11, SI-2, SI-4, SI-5

ID.RA-2: Threat and vulnerability information is received from information sharing forums and sources

3.5.1 P5; Section 1, 2.1

1.4.3.2, 3.4.2.3, 6.4.1, 6.4.2

TVM-1a TVM-1b TVM-2a TVM-2b TVM-2d

4.1.3, D-2, D-4

G1, P1-1, P1-2

4.2.3, 4.2.3.9, 4.2.3.12

A.6.1.4 PM-15, PM-16, SI-5


A-4



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

ID.RA-3: Threats, both internal and external, are identified and documented

2.1.4, 3.5.1 P3; Section 1 3.4.1, 4.4.1, 5.4.1, 6.4.1, 7.4.1, 8.4.1, 9.4.1, 10.4.1, 12.4.2.1.2, 13.4.2

TVM-1a TVM-1b TVM-1d TVM-1e RM-2j TVM-1j

3.2 G1 APO12.01, APO12.02, APO12.03, APO12.04

4.2.3, 4.2.3.9, 4.2.3.12

RA-3, SI-5, PM-12, PM-16

ID.RA-4: Potential business impacts and likelihoods are identified

2.1.6, 3.5.1 P3; Section 2.2, 2.3

1.4.1.1.3, 1.4.2

TVM-1d TVM-1f RM-1c TVM-1i

3.2 G1, P1-2 DSS04.02 4.2.3, 4.2.3.9, 4.2.3.12

RA-2, RA-3, PM-9, PM-11, SA-14

ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk

2.1.4, 2.1.6, 3.5.1

P3; Section 2.2, 2.3

1.4.1 RM-1c RM-2j TVM-2m

3.2 G1 APO12.02 A.12.6.1 RA-2, RA-3, PM-16

ID.RA-6: Risk responses are identified and prioritized

3.4, 3.5.1 P3; Section 3 2.4.1.8, 2.4.2, 2.4.3

RM-2e TVM-1d RM-1c RM-2j IR-3m

3.2 G1 APO12.05, APO13.02

PM-4, PM-9

Risk Management Strategy

ID.RM-1: Risk management processes are established, managed, and agreed to by organizational stakeholders

2.1.4, 3.5.1 P3; Section 3 All RM-2a RM-2b RM-1a RM-1b RM-2c RM-2d RM-2e RM-2g RM-3a RM-3b RM-3c RM-3d RM-1c RM-1d RM-1e RM-2h RM-2j RM-3g RM-3h RM-3i

4.1.1 G1, P1-1 APO12.04, APO12.05, APO13.02, BAI02.03, BAI04.02

4.3.4.2 PM-9


A-5



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

ID.RM-2: Organizational risk tolerance is determined and clearly expressed

3.4, 3.5 1 P3 2.4.1 RM-1c RM-1e

4.1.1 G1, P1-1 APO12.06 4.3.2.6.5 PM-9

ID.RM-3: The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis

3.5.1 P3 2.4.1 RM-1b RM-1c

4.1.1, 4.1.2 G1, P1-1 PM-8, PM-9, PM-11, SA-14

Protect

Access Control

PR.AC-1: Identities and credentials are managed for authorized devices and users

3.5.2 4.4.1 IAM-1a IAM-1b IAM-1c IAM-1d IAM-1e IAM-1f RM-1c IAM-1g

5.15, 6.2, 6.2.7.4

G1 16 DSS05.04, DSS06.03

4.3.3.5.1 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9

A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3

AC-2, IA Family

PR.AC-2: Physical access to assets is managed and protected

3.5.2 2.4.11, 10.4 IAM-2a IAM-2b IAM-2c IAM-2d IAM-2e IAM-2f IAM-2g

5.4. 6.2, 6.2.11

G1 DSS01.04, DSS05.05

4.3.3.3.2, 4.3.3.3.8

A.11.1.1, A.11.1.2, A.11.1.4, A.11.1.6, A.11.2.3

PE-2, PE-3, PE-4, PE-5, PE-6, PE-9

PR.AC-3: Remote access is managed

3.5.2 5.4 IAM-2a IAM-2b IAM-2c IAM-2d IAM-2e IAM-2f IAM-2g

2.4, 5.3, 5.8.6, 5.10.2, 6.2.1

G1 APO13.01, DSS01.04, DSS05.03

4.3.3.6.6 SR 1.13, SR 2.6

A.6.2.2, A.13.1.1, A.13.2.1

AC-17, AC-19, AC-20

PR.AC-4: Access permissions are managed, incorporating the principles of least privilege and separation of duties

3.5.2 4.4.1.1 IAM-2d 6.2.1.1 G1 12, 15 4.3.3.7.3 SR 2.1 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4

AC-2, AC-3, AC-5, AC-6, AC-16

PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate

3.5.2 P5 3.4.1.4, 3.4.1.5, 3.4.2

CPM-3a CPM-3b CPM-3c CPM-3d

5.1, 5.5, 5.5.6

G1 4.3.3.4 SR 3.1, SR 3.8 A.13.1.1, A.13.1.3, A.13.2.1

AC-4, SC-7


A-6



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

Awareness and Training

PR.AT-1: All users are informed and trained

3.3, 3.5.2, 3.5.7

P3 7.4 WM-3a WM-4a WM-3b WM-3c WM-3d WM-3g WM-3h WM-3i

6.2.2 G3, P1-1 9 APO07.03, BAI05.07

4.3.2.4.2 A.7.2.2 AT-2, PM-13

PR.AT-2: Privileged users understand roles & responsibilities

3.5.2 P3 7.4.1.2 WM-1a WM-1b WM-1c WM-1d WM-1e WM-1f WM-1g

3.3.1, 4.1.4, 4.2, 6.2.2

G3 9 APO07.02, DSS06.03

4.3.2.4.2, 4.3.2.4.3

A.6.1.1, A.7.2.2

AT-3, PM-13

PR.AT-3: Third-party stakeholders (e.g., suppliers, customers, partners) understand roles & responsibilities

3.5.2 P3 7/4/1, 1.4.1.2

WM-1a WM-1b WM-1c WM-1d WM-1e WM-1f WM-1g

3.3.1 G3, P1-1 9 APO07.03, APO10.04, APO10.05

4.3.2.4.2 A.6.1.1, A.7.2.2

PS-7, SA-9

PR.AT-4: Senior executives understand roles & responsibilities

3.3, 3.5.2 P3 7.4.1.2, 2.4.2.2

WM-1a WM-1b WM-1c WM-1d WM-1e WM-1f WM-1g

4.1.4 G3 9 APO07.03 4.3.2.4.2 A.6.1.1, A.7.2.2,

AT-3, PM-13

PR.AT-5: Physical and information security personnel understand roles & responsibilities

3.5.2 P3 7.4.1.3 WM-1a WM-1b WM-1c WM-1d WM-1e WM-1f WM-1g

3.3.1 G3, P1-1 9 APO07.03 4.3.2.4.2 A.6.1.1, A.7.2.2,

AT-3, PM-13

Data Security

PR.DS-1: Data-at-rest is protected

2.1.2, 3.5.2 P5 13.4.6 TVM-1c TVM-2c

5.14 G4 17 APO01.06, BAI02.01, BAI06.01, DSS06.06

SR 3.4, SR 4.1 A.8.2.3 SC-28


A-7



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

PR.DS-2: Data-in-transit is protected

2.1.2, 3.5.2 P5 3.4.1.4 TVM-1c TVM-2c

5.14 G4 17 APO01.06, DSS06.06

SR 3.1, SR 3.8, SR 4.1, SR 4.2

A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3

SC-8

PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition

3.5.2 P5 12.4.2 ACM-3a ACM-3b ACM-3c ACM-3d ACM-4a ACM-4b ACM-4c ACM-4d ACM-3f ACM-4e ACM-4f ACM-4g

ref to ISO27001, 5.10.1

G4 BAI09.03 4. 4.3.3.3.9, 4.3.4.4.1

SR 4.2 A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3, A.11.2.7

CM-8, MP-6, PE-16

PR.DS-4: Adequate capacity to ensure availability is maintained

3.5.2 P5 2.4.1 TVM-1c TVM-2c CPM-3b

6.2.3, 2.3.1, 2.4

G4 APO13.01 SR 7.1, SR 7.2 A.12.3.1 AU-4, CP-2, SC-5

PR.DS-5: Protections against data leaks are implemented

2.1.2, 3.5.2 P5 3.4.1.4, 3.4.2.2.2

TVM-1c TVM-2c CPM-3b TVM-2n

5.14 G4 17 APO01.06 SR 5.2 A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4,

AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4


A-8



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

A.14.1.2, A.14.1.3

PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity

3.5.2 P5 13.4 SA-2e SA-2i

2.4, 6.2.17 G4 SR 3.1, SR 3.3, SR 3.4, SR 3.8

A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3

SI-7

PR.DS-7: The development and testing environment(s) are separate from the production environment

3.5.2 P2, P3 ACM-3c ACM-3e

G4 BAI07.04 A.12.1.4 CM-2

Information Protection Processes and Procedures

PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained

3.4, 3.5.2 1.4.2.1, 2.4.1, 3.4.1, 3.4.2

ACM-2a ACM-2b ACM-2c ACM-2d ACM-2e

G1, P1-1 3, 10 BAI10.01, BAI10.02, BAI10.03, BAI10.05

4.3.4.3.2, 4.3.4.3.3

SR 7.6 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4

CM-2, CM-3, CM-4, CM-5, CM-6, CM-7, CM-9, SA-10

PR.IP-2: A System Development Life Cycle to manage systems is implemented

3.5.2 P5 3.4.2.4 ACM-3d 6.2.12 G1 APO13.01 4.3.4.3.3 A.6.1.5, A.14.1.1, A.14.2.1, A.14.2.5

SA-3, SA-4, SA-8, SA-10, SA-11, SA-12, SA-15, SA-17, PL-8

PR.IP-3: Configuration change control processes are in place

3.5.2 P2 13.4 ACM-3a ACM-3b ACM-3c ACM-3d ACM-4a ACM-3e ACM-3f ACM-4e

6.2.5 G1 BAI06.01, BAI01.06

4.3.4.3.2, 4.3.4.3.3

SR 7.6 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4

CM-3, CM-4, SA-10

PR.IP-4: Backups of information are conducted, maintained, and tested periodically

3.5.2 P5 13.4.5.1, 13.4.6

IR-4a IR-4b 6.2.6, 6.2.6.2 G1 APO13.01 4.3.4.3.9 SR 7.3, SR 7.4 A.12.3.1, A.17.1.2A.17.1.3, A.18.1.3

CP-4, CP-6, CP-9


A-9



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

PR.IP-5: Policy and regulations regarding the physical operating environment for organizational assets are met

3.5.2 P2 10.4 ACM-4f RM-3f

3.2, 6.2.11 G1 DSS01.04, DSS05.05

4.3.3.3.1 4.3.3.3.2, 4.3.3.3.3, 4.3.3.3.5, 4.3.3.3.6

A.11.1.4, A.11.2.1, A.11.2.2, A.11.2.3

PE-10, PE-12, PE-13, PE-14, PE-15, PE-18

PR.IP-6: Data is destroyed according to policy

3.5.2 ACM-3d 6.2.10, 6.2.14

G1 BAI09.03 4.3.4.4.4 SR 4.2 A.8.2.3, A.8.3.1, A.8.3.2, A.11.2.7

MP-6

PR.IP-7: Protection processes are continuously improved

3.5.2 P3 1.4.3, 1.4.3.1, 1.4.3.3

CPM-1g 3.1, 4.1.4 G1, P1-2 APO11.06, DSS04.05

4.4.3.1, 4.4.3.2, 4.4.3.3, 4.4.3.4, 4.4.3.5, 4.4.3.6, 4.4.3.7, 4.4.3.8

CA-2, CA-7, CP-2, IR-8, PL-2, PM-6

PR.IP-8: Effectiveness of protection technologies is shared with appropriate parties

3.5.2 1.4.1.2, 1.4.2.5, 1.4.2.6, 1.4.3, 1.4.3.1

ISC 1a ISC-1b ISC-1c ISC-1d ISC-1e ISC-1f ISC-1g ISC-2b ISC-1h ISC-1i ISC-1j ISC-1k ISC-1l

6.1.6, ref SP 800-40

G1 A.16.1.6 AC-21, CA-7, SI-4

PR.IP-9: Response plans (Incident Response and Business Continuity) in place and managed

3.5.2 2.4 IR-4c IR-3f IR-4d IR-4f IR-5a IR-5b IR-5d TVM-1d IR-3k IR-3m IR-4i IR-4j IR-5e IR-5f IR-5g IR-5h IR-5i RM-1c

6.2.8 G1 DSS04.03 4.3.2.5.3, 4.3.4.5.1

A.16.1.1, A.17.1.1, A.17.1.2

CP-2, IR-8

PR.IP-10: Response and recovery plans are tested

3.5.2 1.4.3.1 IR-3e IR-4f IR-3k IR-4i IR-4j

G1 4.3.2.5.7, 4.3.4.5.11

SR 3.3 A.17.1.3 NIST SP 800-53 Rev.4 CP-


A-10



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

4, IR-3, PM-14

PR.IP-11: Cybersecurity is included in human resources practices (e.g., deprovisioning, personnel screening)

3.5.2 1.4.1.1, 1.4.2.5, 1.4.3

WM-2a WM-2b WM-2c WM-2d WM-2e WM-2f WM-2g WM-2h

G1 APO07.01, APO07.02, APO07.03, APO07.04, APO07.05

4.3.3.2.1, 4.3.3.2.2, 4.3.3.2.3

A.7.1.1, A.7.3.1, A.8.1.4

PS Family

PR.IP-12: A vulnerability management plan is developed and implemented

3.5.2 P3, P5 1.4 TVM-3a TVM-3e

6.2.17.3 G1 A.12.6.1, A.18.2.2

RA-3, RA-5, SI-2

Maintenance

PR.MA-1: Maintenance and repair of organizational assets is performed and logged in a timely manner, with approved and controlled tools

3.5.2 P3 13.4.7 ACM-3b ACM-4c ACM-3f

5.16 G1 BAI09.03 4.3.3.3.7 A.11.1.2, A.11.2.4, A.11.2.5

MA-2, MA-3, MA-5

PR.MA-2: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access

3.5.2 8.4 SA-1a IR-1c IAM-2a IAM-2b IAM-2c IAM-2d IAM-2e IAM-2f IAM-2g IAM-2h

5.16, 5.10.2, 6.2.1

G1 DSS05.04 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.4.4.6.8

A.11.2.4, A.15.1.1, A.15.2.1

MA-4

Protective Technology

PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy

3.5.2 P2 4.4.3.2, 4.4.3.3, 3.4.2.2.1, 3.4.2.2.4

SA-1a SA-2a SA-1b SA-1c SA-2e SA-4a SA-1d SA-1e 3dSA-4e SA-4f SA-4g

5.16, 6.2, 6.2.3

G3 14 APO11.04 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4

SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12

A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1

AU Family

PR.PT-2: Removable media is protected and its use restricted according to policy

3.5.2 8.4 IAM-2a IAM-2b IAM-2c

6.2.10, 6.2.14

G3 DSS05.02, APO13.01

SR 2.3 A.8.2.2, A.8.2.3, A.8.3.1,

MP-2, MP-4, MP-5, MP-7


A-11



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

IAM-3e IAM-3f

A.8.3.3, A.11.2.9

PR.PT-3: Access to systems and assets is controlled, incorporating the principle of least functionality

3.5.2 P5 4.4.1.1 IAM-2a IAM-2b IAM-2c IAM-2d IAM-2e IAM-2f IAM-2g IAM-2h IAM-2i

G-28 CM-7 G3 DSS05.02 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4

SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7

A.9.1.2 AC-3, CM-7

PR.PT-4: Communications and control networks are protected

3.5.2 P3 3.4.2.2 CPM-3a CPM-3b CPM-3c CPM-3d

3, 3.3.6, 4, 5, 6

G3 7 DSS05.02, APO13.01

SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6

A.13.1.1, A.13.2.1

AC-4, AC-17, AC-18, CP-8, SC-7

Detect

Anomalies and Events

DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed

3.5.3 3.4.1, 3.4.2.1 SA-2a 5.7 G4, P1-2 DSS03.01 4.4.3.3 AC-4, CA-3, CM-2, SI-4


A-12



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

DE.AE-2: Detected events are analyzed to understand attack targets and methods

3.5.3 P5 2.4.4 IR-1f IR-2i IR-3h

5.3, 6.2.8, ref SP 800-94

G4, P1-2 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8

SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12, SR 3.9, SR 6.1, SR 6.2

A.16.1.1, A.16.1.4

AU-6, CA-7, IR-4, SI-4

DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors

3.5.3 P5 2.4.4.5, 4.4.3.3, 5.4.2.4

IR-1e IR-1f IR-2i

Appendix E-Intrusion Detection and Prevention

G4 SR 6.1 AU-6, CA-7, IR-4, IR-5, IR-8, SI-4

DE.AE-4: Impact of events is determined

2.1.6, 3.5.3 P3 1.4.2.3, 2.4.1.2, 2.4.1.3, 2.4.4.5

IR-2b IR-2d TVM-1d IR-2g RM-2j

3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6

G4, P1-2 APO12.06 CP-2, IR-4, RA-3, SI -4

DE.AE-5: Incident alert thresholds are established

3.5.3 P5 1.4.2.1, 2.4.1.2, 2.4.1.3, 2.4.4.2

IR-2a IR-2d TVM-1d SA-2d IR-2g RM-2j

5.2, 6.2, 6.2.3, 6.2.17

G4, P1-2 APO12.06 4.2.3.10 IR-4, IR-5, IR-8

Security Continuous Monitoring

DE.CM-1: The network is monitored to detect potential cybersecurity events

3.5.3 2.4.4.2, 5.4.2, 9.4.2

SA-2a SA-2b SA-2e SA-2f TVM-1d SA-2g SA-2i

5.16 G4 14, 16 DSS05.07 SR 6.2 AC-2, AU-12, CA-7, CM-3, SC-5, SC-7, SI-4

DE.CM-2: The physical environment is monitored to detect potential cybersecurity events

3.5.3 10.4.1.3, 10.4.1.4.1

SA-2a SA-2b SA-2e SA-2i

3.3, 3.3.5, 5.2

G4 4.3.3.3.8 CA-7, PE-3, PE-6, PE-20

DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events

3.5.3 6.4.1.3, 6.4.1.4, 6.4.1.5

SA-2a SA-2b SA-2e SA-2i

6.2.13, 6.2.3 G4 SR 6.2 A.12.4.1 AC-2, AU-12, AU-13, CA-7, CM-10, CM-11

DE.CM-4: Malicious code is detected

3.5.3 5.4.2.1, 8.4.1, 12.4.2.2

SA-2a SA-2b SA-2e CPM-4a SA-2i

6.2, 6.2.17, Appendix E

G4 5 DSS05.01 4.3.4.3.8 SR 3.2 A.12.2.1 SI-3


A-13



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

DE.CM-5: Unauthorized mobile code is detected

3.5.3 SA-2a SA-2b SA-2e SA-2h SA-2i

ref to SP 800-28

G4 SR 2.4 A.12.5.1 SC-18, SI-4. SC-44

DE.CM-6: External service provider activity is monitored to detect potential cybersecurity events

3.5.3 4.4.2.3, 4.4.3.3, 5.4.2.1, 5.4.2.4, 6.4.1.3, 6.4.1.4

EDM-2a SA-2a SA-2b SA-2e EDM-2j EDM-2n

5, 5.2 G4 APO07.06 A.14.2.7, A.15.2.1

CA-7, PS-7, SA-4, SA-9, SI-4

DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed

3.5.3 2.4.4.1, 5.4.2, 6.4.1.3, 6.4.1.4, 6.4.1.5, 9.4.2.6

SA-2a SA-2b SA-2e SA-2f TVM-1d SA-2g SA-2i

6.2.11 G4 AU-12, CA-7, CM-3, CM-8, PE-3, PE-6, PE-20, SI-4

DE.CM-8: Vulnerability scans are performed

3.5.3 5.4.2 TVM-2e TVM-2i TVM-2j TVM-2k RM-1c

G-51 RA-5 G4 BAI03.10 4.2.3.1, 4.2.3.7

A.12.6.1 RA-5

Detection Processes

DE.DP-1: Roles and responsibilities for detection are well defined to ensure accountability

3.5.3 P3 2.4.2.1, 2.4.3, 4.4.1.1, 4.4.1.4, 4.4.2

WM-1a WM-1d WM-1f

6.2.3 , 6.2.6.2

G4 5 DSS05.01 4.4.3.1 A.6.1.1 CA-2, CA-7, PM-14

DE.DP-2: Detection activities comply with all applicable requirements

3.5.3 P5 1.4.3.1, 5.4.1, 12.4.1.2, 12.4.1.3

IR-1d IR-5a TVM-1d IR-1g IR-5f RM-1c RM-2j

6.2.3 G4 4.4.3.2 A.18.1.4 CA-2, CA-7, PM-14, SI-4

DE.DP-3: Detection processes are tested

3.5.3 P2, P3, P5 2.4.4.3 IR-3e IR-3j

G4 APO13.02 4.4.3.2 SR 3.3 A.14.2.8 CA-2, CA-7, PE-3, PM-14, SI-3, SI-4


A-14



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

DE.DP-4: Event detection information is communicated to appropriate parties

3.5.3 2.4.4.4, 2.4.4.5, 11.4.2.10, 12.4.2.3

IR-1b IR-3c ISC-1a ISC-1c ISC-1d IR-3n ISC-1h ISC-1j

2.4, 3.1, 3.3.6

G4 APO12.06 4.3.4.5.9 SR 6.1 A.16.1.2 AU-6, CA-2, CA-7, RA-5, SI-4

DE.DP-5: Detection processes are continuously improved

3.5.3 1.4.3.3, 11.4.1, 11.4.2.3, 12.4.1.4, 12.4.2.2

IR-3h IR-3k G4 APO11.06, DSS04.05

4.4.3.4 A.16.1.6 CA-2, CA-7, PL-2, RA-5, SI-4, PM-14

Respond

Response Planning

RS.RP-1: Response plan is executed during or after an event

3.5.4 2.4.4, 2.4.4.1, 2.4.4.3

IR-3d 5.17, 6.2.8 G1 18 BAI01.10 4.3.4.5.1 A.16.1.5 CP-2, CP-10, IR-4, IR-8

Communications

RS.CO-1: Personnel know their roles and order of operations when a response is needed

3.5.4 P3 2.4.3.1 IR-3a IR-5b

6.2.11 G2 4.3.4.5.2, 4.3.4.5.3, 4.3.4.5.4

A.6.1.1, A.16.1.1

CP-2, CP-3, IR-3, IR-8

RS.CO-2: Events are reported consistent with established criteria

3.5.4 P2 2.4.4.5 IR-1a IR-1b 6.2, 6.2.4, ref SP 800-61

G2 4.3.4.5.5 A.6.1.3, A.16.1.2

AU-6, IR-6, IR-8

RS.CO-3: Information is shared consistent with response plans

3.5.4 2.4.4.3 ISC-1a ISC-1b ISC-1c IR-3d ISC-1c ISC-1d IR-3i IR-3l

6.2, 6.2.4, ref SP 800-61

G2 4.3.4.5.2 A.16.1.2 CA-2, CA-7, CP-2, IR-4, IR-8, PE-6, RA-5, SI-4

RS.CO-4: Coordination with stakeholders occurs consistent with response plans

3.5.4 P3 2.4.3.2 IR-3d IR-5b 6.2.8, 6.2.14 G2 4.3.4.5.5 CP-2, IR-4, IR-8

RS.CO-5: Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness

3.5.4 P3 2.4.3.2 ISC-1a ISC-1c ISC-1d ISC-1e ISC-1f ISC-1h ISC-1i

Appendix C G2 PM-15, SI-5


A-15



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

ISC-1j ISC-1k ISC-1l

Analysis

RS.AN-1: Notifications from detection systems are investigated

3.5.4 P5 2.4.4.4 IR-1e IR-1f

6.2.3, 6.2.8 G4 DSS02.07 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8

SR 6.1 A.12.4.1, A.12.4.3, A.16.1.5

AU-6, CA-7, IR-4, IR-5, PE-6, SI-4

RS.AN-2: The impact of the incident is understood

2.1.6. 3.5.4 2.4.4.2 IR-2d TVM-1d IR-2g RM-2j

3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.3.6

G4 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8

A.16.1.6 CP-2, IR-4

RS.AN-3: Forensics are performed

3.5.4 4.4.3.3 IR-3d IR-3h IR-3i

G4 SR 2.8, SR

2.9, SR 2.10, SR 2.11, SR 2.12, SR 3.9, SR 6.1

A.16.1.7 AU-7, IR-4

RS.AN-4: Incidents are categorized consistent with response plans

3.5.4 5.4.2.4 IR-2a IR-1d IR-1e

G4 4.3.4.5.6 A.16.1.4 CP-2, IR-4, IR-5, IR-8

Mitigation

RS.MI-1: Incidents are contained 3.5.4 2.4.4.4 IR-3b 5.1 4.3.4.5.6 SR 5.1, SR 5.2, SR 5.4

A.16.1.5 IR-4

RS.MI-2: Incidents are mitigated 3.5.4 2.4.4.4 IR-3b 5.1 4.3.4.5.6, 4.3.4.5.10

A.12.2.1, A.16.1.5

IR-4

RS.MI-3: Newly identified vulnerabilities are mitigated or documented as accepted risks

3.5.4 P3 11.4.2.11 TVM-2c TVM-2f TVM-2g RM-2j TVM-2m TVM-2n

6.2.17.3 A.12.6.1 CA-7, RA-3, RA-5

Improvements

RS.IM-1: Response plans incorporate lessons learned

3.5.4 2.4.4.5 IR-3h G3 BAI01.13 4.3.4.5.10, 4.4.3.4

A.16.1.6 CP-2, IR-4, IR-8

RS.IM-2: Response strategies are updated

3.5.4 11.4.2 IR-3h IR-3k G3 CP-2, IR-4, IR-8

Recover


A-16



ISA 62443-2-1

ISA 62443-3-3

ISO/IEC 27001

NIST SP 800-53

Recovery Planning

RC.RP-1: Recovery plan is executed during or after an event

3.5.5 2.4.4, 2.4.4.1, 2.4.4.3

IR-3b IR-3d IR-3o IR-4k

5.17 G1 8 DSS02.05, DSS03.04

A.16.1.5 CP-10, IR-4, IR-8

Improvements

RC.IM-1: Recovery plans incorporate lessons learned

3.5.5 2.4.4.5 IR-3h IR-4i IR-3k

6.2.12 G3 BAI05.07 ISA 62443-2-1 4.4.3.4

CP-2, IR-4, IR-8

RC.IM-2: Recovery strategies are updated

3.5.5 2.4.4.5 IR-3h IR-3k 6.2.12 G3 BAI07.08 CP-2, IR-4, IR-8

Communications

RC.CO-1: Public relations are managed

3.5.5 2.4.3.2 RM-1c 6.2.6.1 G2 EDM03.02

RC.CO-2: Reputation after an event is repaired

3.5.5 2.4.3.2 IR-3d Appendix C G2 MEA03.02

RC.CO-3: Recovery activities are communicated to internal stakeholders and executive and management teams

3.5.5 P3 2.4.2.3 IR-3d 3.1, 6.2.19 G2 CP-2, IR-4


B-1

B. Appendix. Supply Chain References Some of the cybersecurity standards and best practices explicitly address requirements associated with

external parties (e.g., vendors) as part of the supply chain to ensure any potential vulnerabilities are

addressed. Table B1 identifies and summarizes the specific supply chain references in NIST 800-53, NIST

800-160, ISO 27001, and NIST MBLT Profile.

Table B1. Supply Chain References

Item/Page Location Summary Search Term

NIST 800-53

1/5 Section 1.4 Acquisition is included with deployment and operation as a fundamental consideration for the security system implementer.

Acquisition

2/6 Table 1 Acquisition is included in the SA “Family” of the Management “Class” of security controls

Acquisition

3/18 Appendix A NIST 800-23 is presented as an acquisition reference (Guideline to Federal Organizations on Security Assurance and Acquisition/Use

of Tested/Evaluated Products, August 2000).

Acquisition

4/35 Appendix D Provides a “catalog” of security controls that are recommended for three levels of “control baselines”: Low-impact, Moderate-impact, and High-impact information systems. The user of the catalog bears the responsibility for assigning impact level to the system(s) under assessment. This appendix is recommended for application to supplier management in Appendix E.

Acquisition

5/85 Appendix F Explicitly includes the topic of personnel security requirements in acquisition-related documents, and recommends related reading in NIST Special Publication 800-35, which provides guidance on information technology security services.

Acquisition

6/89 Appendix F IMPORTANT – Defines the requirement for security program acquisition policy and procedures that is consistent with applicable federal laws, directives, policies, regulations, standards, and guidance. Recommends related reading in NIST 800-12.

Acquisition

7/90 Appendix F IMPORTANT – Defines the requirement for including security requirements and/or security specifications, either explicitly or by reference, in information system acquisition contracts based on an assessment of risk. Directs the user to NIST publications 800-53, 800-36, 800-35, and 800-64.

Acquisition

8/114 Appendix G IMPORTANT – Maps the SA requirements for acquisition to other standards, specifically, ISO 1799 12.1 and 15.1.1; NIST 800-26 3.; DOD 85.2 DCAR-1; and, DCID 6/3 9.B.

Acquisition

11/31 Appendix D Provides a “catalog” of security controls that are recommended for three levels of “control baselines”: Low-impact, Moderate-impact, and High-impact information systems.

Vendor

12/37 Appendix E Makes note of the appropriateness of using the catalog for communicating security requirements to suppliers (and implementers) of the systems that are impact-assessed.

Vendor

13/70 Appendix F Recommends adherence to vendor specifications for periodic maintenance, and removal of protected information prior to onsite or offsite all maintenance or repairs of affected systems.

Vendor


B-2


14/100 Appendix F Recommends the prompt implementation of vendor-provided, security-relevant software evolution/repair actions.

Vendor

15/101 Appendix F Recommends the use of virus protection software products from different (or multiple) vendors for different protection layers or equipment types as a “separation of duties” protocol for implementation of virus protection software.

Vendor

16/103 Appendix F Recommends the use of virus protection software products from different (or multiple) vendors for different protection layers or equipment types as a “separation of duties” protocol for spam/spyware protection software.

Vendor

NIST 800-160

1/5 Section 1.2 Target audience of the special publication includes Individuals with acquisition, budgeting, and project management responsibilities. It also targets providers (i.e., suppliers and vendors) of technology products, systems, or services.

Acquisition

2/8 Chapter 2 – The

Fundamentals

The introduction to the chapter discusses principles and concepts in security engineering and states that While systems engineering is typically considered in terms of its developmental role as part of the acquisition of a capability, systems engineering efforts and responsibilities do not end once a system completes development and is transitioned to the operational environment.

Acquisition

3/20 Section 2.4 The Systems Security Engineering Framework is independent of system type and [an] engineering or acquisition process model and is not to be interpreted as a sequence of flows or process steps but rather as a set of interacting contexts, each with its own checks and balances.

Acquisition

4/21 Footnote 25 The footnote states that life cycle security concepts include those applied broadly during acquisition and program management. It further states that the impact of life cycle security concepts can affect such things as RFIs, RFPs, SOWs, source selections, development and test environments, operating environments and supporting infrastructures, supply chain, distribution, logistics, maintenance, training, and clearances/background checks.

Acquisition

5/26 Chapter 3 – System Life

Cycle Process Figure 4

The table sourced from ISO/IEC/IEEE 15288, 2015, presents a System Life Cycle Processes model that classifies Acquisition and Supply as Agreement Processes performed early in a system’s life cycle.

Acquisition

6/27 Chapter 3 – System Life

Cycle Process

The document points out that the processes can be applied concurrently, iteratively, or recursively at any level in the structural hierarchy of a system, and optimized at any stage in the system life cycle, in accordance with acquisition, systems engineering, or other imposed process models.

Acquisition

7/29 Table 2 Acquisition is assigned a discrete process designation, “AQ”, in Table 2.

Acquisition

8/31 Section 3.1 Agreement

Process

IMPORTANT: 3.1.1 Acquisition Process – “The purpose of the Acquisition process is to obtain a product or service in accordance with the acquirer's requirements.” This subsection discusses requirements for acquiring systems security engineering products and services (ISO/IEC/IEEE 15288-2015).

Acquisition


B-3


9/35 Section 3.1 Agreement

Process

IMPORTANT: 3.1.2 Supply Process – “The purpose of the Supply process is to provide an acquirer with a product or service that meets agreed requirements.” This subsection discusses requirements for satisfying a customer purchasing systems security engineering products and services (ISO/IEC/IEEE 15288-2015).

Acquisition

10/58 Section 3.3.1 PL-2.6 – The document discusses including the acquisition of security products and services as part of the overall systems security engineering program/project plan.

Acquisition

11/62 Section 3.3.2 PA-3.3 – The document discusses the potential impact on security resulting from requested contractual changes.

Acquisition

12/86 Section 3.4.1 BA-3.1 – The document discusses defining security aspects of preliminary operational concepts in all of a system’s life cycle stages, including acquisition.

Acquisition

13/89 Section 3.4.2 SN-1.2 – The document discusses inclusion of all stakeholders (including acquisition) during requirements development and analysis stages of a systems security engineering project.

Acquisition

14/116 Section 3.4.7 IP-2.1 – The document discusses the need to realize or adapt purchased system elements in accordance with the security aspects of the implementation strategy, defined implementation procedures, and security-driven constraints.

Acquisition

15/145 Section 3.4.13 MA-1.1 – The document discusses the need to address security aspects pertaining to acquisition of products and services needed to maintain a secured system or a security engineering system.

Acquisition

16/148 Section 3.4.13 MA-3.1 – The document discusses the need to ensure that security protection capability, performance, effectiveness, and trustworthiness are met as contractually agreed by suppliers for the full life cycle of the project.

Acquisition

17/165 Appendix G The document Glossary defines “Acquisitions” as the process of obtaining a system, product, or service. Ref: [ISO/IEC/IEEE 15288]

Acquisition

18/170 Appendix G The document glossary defines “life cycle security concepts” as a security-driven philosophy for the development and operation of a system to satisfy stakeholder protection needs. Life cycle security concepts are applied during program management, development, engineering, acquisition, production, operations, sustainment, and retirement.

Acquisition

19/182 Table D-1 Agreement Processes

IMPORTANT: The table points to 33 acquisition processes to be included in a security project plan.

Acquisition

20/187 Table D-3 Technical

Management Process

PL-2.6 – Plan the security aspects of acquisition of materials and enabling systems and services supplied from outside the project.

Acquisition

21/202 Table D-3 MA-3.1 – Perform the security aspects of acquisition logistics. Acquisition

22/229 Appendix G Examples of information elicited and that informs security requirements analysis include:

• Policy, legal, and regulatory requirements and mandates;

• Processes to be followed (e.g., acquisition, development, production, manufacturing, risk management, verification and validation, assurance, assessment, authorization); and

Acquisition


B-4


• Agreements, arrangements, and contracts for services provided to or received from external organizations.

23/37 Section 3.1.2 Supply Process

SP-5 – The document discusses supplier delivery support for the security project or service, including:

• Delivery of the product or service per the purchasing agreement and in accordance with the security aspects and considerations;

• Provision of security engineering assistance and support continues throughout operations, sustainment, and disposal of the system; and,

• Transfer the responsibility for the product or service to the acquirer or other party, as directed by the security aspects and considerations in the agreement.

Supplier

29/68 Section 3.3.4 Risk

Management Process

RM-3.2 – Estimate the likelihood of occurrence and consequences of each identified security risk based on available expertise. This expertise includes knowledge of assumptions, hazards, or actual threat information (e.g., historical data on attacks, disaster events, distribution, supplier, and supply chain issues; information on specific adversary capabilities, intentions, and targeting).

Supplier

30/70 Section 3.3.5 Configuration Management

Process

CM-1.1 – Define the security aspects of a configuration management strategy. This includes the secure coordination of configuration management activities across the set of acquirer, supplier, subcontractor, logistics, supply chain, and other organizations that have impact on achieving configuration management objectives.

Supplier

31/71 Section 3.3.5 CM-2.5 – Obtain acquirer and supplier agreement for security aspects to establish a security baseline for the product or service.

Supplier

32/80 Section 3.3.8 Quality

Assurance Process

QA-1.1 – Define the security aspects of the quality assurance strategy, including project security quality assurance procedures; security roles, responsibilities, accountabilities, and authorities; security activities oriented to each life cycle engineering process; security activities appropriate to each supplier and subcontractor; required security-oriented verification, validation, monitoring, measurement, inspection, and test activities specific to the product or service; security criteria for product or service acceptance; and security evaluation criteria and methods for process, product, and service evaluations.

Supplier

33/81 Section 3.3.8 QA-3.3 – Evaluate supplier processes (e.g., distribution, logistics, and supply chain) for conformance to process security requirements and evaluation, including supplier processes, constraints, and quality criteria derived from agreements.

Supplier

34/121 Section 3.4.7 Integration

Process

IN-2.1 – Obtain implemented system elements in accordance with security criteria and requirements as established in agreements and schedules. Security criteria address the handling, distribution, delivery, and acceptance of all forms of system elements as they are obtained from suppliers or withdrawn from storage. The criteria attempt to prevent and/or detect unauthorized knowledge of/about,

Supplier


B-5


access to/control over, use of, and modification to system elements as they are delivered to the integration location.

35/160 Appendix A References

Standards and Guidelines: ISO/IEC 27036-1:2014, Information technology — Security techniques — Information security for supplier relationships — Part 1: Overview and concepts, April 2014.

Supplier


Standards and Guidelines: ISO/IEC 27036-2:2014, Information technology — Security techniques — Information security for supplier relationships — Part 2: Requirements, August 2014.

Supplier


Standards and Guidelines: ISO/IEC 27036-3:2013, Information technology — Security techniques — Information security for supplier relationships — Part 3: Guidelines for information and communication technology supply chain security, November 2013.

Supplier

38/165 Appendix B Glossary

“acquirer” – Stakeholder that acquires or procures a product or service from a supplier. (ISO/IEC/IEEE 15288)

Supplier

39/175 Appendix B Glossary

Supplier – Organization or an individual that enters into an agreement with the acquirer for the supply of a product or service. (ISO/IEC/IEEE 15288)

Supplier

40/188 Appendix D PA-3.3 – Initiate change actions when there is a contractual change to cost, time, or quality due to the security impact of an acquirer or supplier request.

Supplier

41/189 Appendix D CM-2.5 – Obtain acquirer and supplier agreement for security aspects to establish a baseline.

Supplier

42/191 Appendix D QA-3.3 – Evaluate supplier processes for conformance to process security requirements.

Supplier

ISO 27001

1/18 Table A.1/ A.14.1.1

Objective: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks. The information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems.

Acquisition

2/18 Table A.1/ A.14.1.2

Same Objective as A.14.1.1. Information involved in application services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification.

Acquisition

3/18 Table A.1/ A.14.1.3

Same Objective as A.14.1.1. Information involved in application service transactions shall be protected to prevent incomplete transmission, misrouting, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay.

Acquisition

4/19 Table A.1/ A.15.1.1

Objective: To ensure protection of the organization’s assets that is accessible by suppliers. Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets shall be agreed with the supplier and documented.

Supplier

5/19 Table A.1/ A.15.1.2

Same Objective as A.15.1.1. All relevant information security requirements shall be established and agreed with each supplier

Supplier


B-6


that may access, process, store, communicate, or provide IT infrastructure components for, the organization’s information.

6/19 Table A.1/ A.15.1.3

Same Objective as A.15.1.1. Agreements with suppliers shall include requirements to address the information security risks associated with information and communications technology services and product supply chain.

Supplier

7/19 Table A.1/ A.15.2.1

Objective: To maintain an agreed level of information security and service delivery in line with supplier agreements. Organizations shall regularly monitor, review and audit supplier service delivery.

Supplier

8/19 Table A.1/ A.15.2.2

Same Objective as A.15.2.1. Changes to the provision of services by suppliers, including maintaining and improving existing information security policies, procedures and controls, shall be managed, taking account of the criticality of business information, systems and processes involved and re-assessment of risks.

Supplier

NIST MBLT Profile

1/34 Table 6.2 RC.CO: Security incident related restoration activities are coordinated with internal and external parties, such as coordinating centers, Internet Service Providers, owners of attacking systems, victims, other CSIRTs, and vendors.

Vendor

2/25 Table 6.2 ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established.

Supplier

3/28 Table 6.2 PR.AT: The organization’s third-party stakeholders (e.g., suppliers) are provided cybersecurity awareness education and are adequately trained to perform their information security-related duties and responsibilities consistent with related policies, procedures, and agreements.

Supplier

4/53 Appendix A Detailed

Subcategory Specifications

PR.AT-3 (Awareness and Training): Third-party stakeholders (e.g., suppliers, customers, and partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices.

Supplier

5/92 Appendix A ID.AM-6 (Asset Management): Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, and partners) are established. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices.

Supplier

6/94 Appendix A PR.AT-3 (Awareness and Training: Third-party stakeholders (e.g., suppliers, customers, and partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices.

Supplier


Supplier


Supplier


B-7


9/138 Appendix C Industry

Cybersecurity Processes &

Profile Mappings

ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established. Additional cybersecurity NIST Framework resources are cited, as are COBIT 5, and ISA 62443 and ISO/IEC 27001.

Supplier

10/141 Appendix C

PR.AT-3: Third-party stakeholders (e.g., suppliers, customers, partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, as are COBIT 5, and ISA 62443 and ISO/IEC 27001.

Supplier


C-1

C. Appendix. Security Management System Regulations (New) Table C1 provides a detailed exploration of the requirements of the Federal and international

regulations or standards requiring security management systems for major assets that operate in the

U.S. MTS, and documents which are related to cybersecurity or could be extended to address cyber

issues.

Legend

Cyber-specific requirements are not applicable

Requirements could be extended to address cyber issues

✓ Cyber-specific requirements are explicitly defined or could be inferred to be in scope

Table C1. Relevant Security Management Systems Regulations and Standards

Requirements Cyber Comments

33 CFR Subchapter H, Part 104 – Maritime Security: Vessels

Subpart A. General

Cyber-specific requirements are not applicable to this section.

Subpart B. Vessel Security Requirements

§104.200 Owner or operator

Cyber elements could be specifically addressed in: training, drills, exercises (b3), security systems (b10), & limited access to systems (b16)

§104.205 Master

§104.210 CSO

Cyber elements could be specifically addressed in: CSO qualifications, emergency preparedness, training, knowledge (b) and responsibilities (c)

§104.215 VSO

Cyber elements could be specifically addressed in: VSO qualifications, emergency preparedness, training, knowledge (b) and responsibilities (c)

§104.220 Company or vessel personnel with security duties

Cyber elements could be specifically addressed in: personnel knowledge of security threats (a) and operation of security equipment and systems (h)

§104.225 Security training for all other vessel personnel

Cyber elements could be specifically addressed in training of personnel in relevant provisions of VSP (a) and techniques used to circumvent security measures (e)

§104.230 Drill and exercise requirements

Cyber scenarios could be incorporated into drills & exercises

§104.235 Vessel recordkeeping requirements

§104.240 Maritime Security (MARSEC) Level coordination and implementation

§104.245 Communications

§104.250 Procedures for interfacing with facilities and other vessels


C-2


§104.255 Declaration of Security (DoS)

§104.260 Security systems and equipment maintenance

Working order of cybersecurity systems should be verified as well (a) and FSP should address cybersecurity system failures (c)

§104.265 Security measures for access control

§104.267 Security measures for newly hired employees

§104.270 Security measures for restricted areas ✓

Designate sensitive systems (a) and restrict access to them (b) and increase security with MARSEC level (d)

§104.275 Security measures for handling cargo

Address cyber threats to prevent unapproved cargo from being loaded (a)

§104.280 Security measures for delivery of vessel stores and bunkers

§104.285 Security measures for monitoring ✓

Monitor cybersecurity measures

§104.290 Security incident procedures

Respond to cyber scenarios (a) and report cyber incidents (c)

§104.292 Additional requirements—passenger vessels and ferries

§104.295 Additional requirements—cruise ships

§104.297 Additional requirements—vessels on international voyages

Subpart C. VSA

§104.300 General

✓

Ensure knowledge of cyber threats and techniques to circumvent cybersecurity measures and/or cause a cybersecurity incident (d)

§104.305 VSA requirements

✓

VSA should address cyber threats, vulnerabilities, security measures, and impacts and recommend improvements where necessary

§104.310 Submission requirements

Subpart D. VSP

§104.400 General

§104.405 Format of the Vessel Security Plan (VSP) ✓

VSP should document cyber scenarios, if applicable

§104.410 Submission and approval

§104.415 Amendment and audit

33 CFR Subchapter H, Part 105 – Maritime Security: Facilities

Subpart A. General


Subpart B. Facility Security Requirements


Cyber elements could be specifically addressed in: Facility Security Assessment (FSA) (b3) & reporting of incidents to the National Response Center (NRC) (b12)


C-3


§105.205 FSO

Cyber elements could be specifically addressed in: FSO qualifications, emergency preparedness, training, knowledge (b) and responsibilities (c)

§105.210 Facility personnel with security duties


§105.215 Security training for all other facility personnel

Cyber elements could be specifically addressed in training of personnel in relevant provisions of FSP (a) and techniques used to circumvent security measures (e)



§105.225 Facility recordkeeping requirements

§105.230 MARSEC Level coordination and implementation


Communication systems must enable notification to authorities in case of cyber-attack (c)

§105.230 Procedures for interfacing with vessels

§105.245 DoS







§105.265 Security measures for handling cargo

Address cyber threats to prevent unapproved cargo from being loaded (a)

§105.270 Security measures for delivery of vessel stores and bunkers





§105.285 Additional requirements—passenger vessels and ferries

§105.290 Additional requirements—cruise ships

§105.295 Additional requirements—Certain Dangerous Cargo (CDC) facilities

§105.296 Additional requirements— barge fleeting facilities

Subpart C. FSA


C-4


§105.300 General

✓


§105.305 Facility Security Assessment (FSA) requirements ✓

FSA should address cyber threats, vulnerabilities, security measures, and impacts and recommend improvements where necessary


Subpart D. FSP

§105.400 General

§105.405 Format of the FSP ✓ FSP should document cyber scenarios, if applicable



33 CFR Subchapter H, Part 106 – Maritime Security: OCS Facilities

Subpart A. General


Subpart B. OCS Facility Security Requirements


Cyber elements could be specifically addressed in: FSA (b3) & reporting of incidents to authorities (b12)

§104.205 CSO

Cyber elements could be specifically addressed in: CSO qualifications, emergency preparedness, training, knowledge (b) and responsibilities (c)

§106.210 OCS FSO

Cyber elements could be specifically addressed in: OCS FSO qualifications, emergency preparedness, training, knowledge (b) and responsibilities (c)

§106.215 Company or OCS facility personnel with security duties


§106.220 Security training for all other OCS facility personnel

Cyber elements could be specifically addressed in training of personnel in relevant provisions of FSP (a) and techniques used to circumvent security measures (e)



§106.230 OCS Facility recordkeeping requirements

§106.235 MARSEC Level coordination and implementation


Communication systems must enable notification to authorities in case of cyber-attack (c)

§106.250 DoS






C-5




§106.270 Security measures for delivery of stores and industrial supplies

Address cyber threats to prevent unapproved supplies from being delivered (a)





Subpart C. OCS FSA

§106.300 General

✓


§106.305 FSA requirements

✓



Subpart D. OCS FSP

§106.400 General

§106.405 Format of the FSP ✓ FSP should document cyber scenarios, if applicable



6 CFR 27 - Chemical Facility Anti-Terrorism Standards

6 CFR 27 - Chemical Facility Anti-Terrorism Standards

Subpart A—General


Subpart B—Chemical Facility Security Program

§27.200 Information regarding security risk for a chemical facility

§27.203 Calculating the screening threshold quantity by security issue

§27.204 Minimum concentration by security issue

§27.205 Determination that a chemical facility “presents a high level of security risk”

§27.210 Submissions schedule

§27.215 SVAs ✓

SVA should address cyber threats, cyber vulnerabilities, and cyber risk analysis

§27.220 Tiering

§27.225 Site security plans ✓

Security plan should address cyber vulnerabilities identified in SVA

§27.230 Risk-based performance standards ✓

Cyber is specifically addressed in this section: (a8) Cyber. Deter cyber sabotage, including by preventing unauthorized onsite or remote access to critical process


C-6


controls, such as SCADA systems, DCS, PCS, ICS, critical business system, and other sensitive computerized systems.

§27.235 Alternative security program

§27.240 Review and approval of security vulnerability assessments

§27.245 Review and approval of site security plans

§27.250 Inspections and audits

§27.255 Recordkeeping requirements

Subpart C—Orders and Adjudications


Subpart D—Other


SOLAS Chapter XI-2: ISPS Code

Part A

1 General

Cyber elements could be specifically addressed in: Objectives and functional requirements

2 Definitions

3 Application

4 Responsibilities of Contracting Governments

Cyber elements could be specifically addressed in guidance for protection from security incidents

5 DoS

Cyber elements could be specifically addressed in the security requirements in the Dos

6 Obligations of the Company

7 Ship Security ✓

Designate sensitive systems (7.2) and restrict access to them (7.2.4) and increase security with security level (7.3)

8 SSA

✓ SSA should address cyber threats, vulnerabilities, security measures, and impacts and recommend improvements where necessary

9 SSP ✓ SSP should document cyber scenarios, if applicable

10 Records

11 CSO

Cyber elements could be specifically addressed in the duties and responsibilities of the CSO (11.2)

12 SSO

Cyber elements could be specifically addressed in the duties and responsibilities of the SSO (12.2)

13 Training, Drill and Exercises on Ship Security


14 Port Facility Security

✓

Designate sensitive systems (14.2) and restrict access to them (14.2.4) and increase security with MARSEC level (14.3)

15 FSA

✓



C-7


16 Port Facility Security Plan ✓ FSP should document cyber scenarios, if applicable

17 PFSO

Cyber elements could be specifically addressed in the duties and responsibilities of the PFSO (17.2)

18 Training, Drills and Exercises on Port Facility Security


19 Verification and Certification for Ships

Appendix 1

International Ship Security Certificate (ISSC)

Appendix 2

Interim ISSC

Part B

1 Introduction

✓

Cyber elements could be specifically addressed: In guidance for protection from security incidents (1.6), CSO responsibilities (1.9), the approved SSP (1.11), the port facility assessment (1.17), PFSO training and responsibilities (1.18), the approved PFSP (1.19)

2 Definitions

3 Applications

4 Responsibilities of Contracting Governments

Cyber elements could be specifically addressed in guidance for protection from security incidents,

5 DoS

Cyber elements could be specifically addressed in the security requirements in the DoS

6 Obligations of the Company

7 Ship Security References sections 8, 9 and 13

8 Ship Security Assessment

✓ SSA should address cyber threats, vulnerabilities, security measures, and impacts and recommend improvements where necessary

9 Ship Security Plan

✓

Cyber elements could be specifically addressed in: Security measures in the SSP (9.2), Organization and performance of ship security duties (9.7 & 9.8), Restricted areas on the ship (9.18), Handling of cargo (9.25) and Monitoring the Security of the Ship (9.42)

10 Records

11 Company Security Officer References sections 8, 9 and 13

12 Ship Security Officer References sections 8, 9 and 13

13 Training, Drills and Exercises on Ship Security


14 Port Facility Security References sections 15, 16 and 18

15 FSA

✓


16 FSP

✓

Cyber elements could be specifically addressed in: Security measures in the PFSP (16.3), Organization and performance of ship security duties (16.8 & 16.9), Restricted areas on the ship (16.21), Handling of cargo (16.31) and Monitoring the Security of the Ship (16.49)

17 Port Facility Security Officer


C-8


18 Training, Drills and Exercises on Port Facility Security

Cyber scenarios could be incorporated into drills and exercises

19 Verification and Certification of Ships

Appendix 1

Form of DoS between a ship and port facility

Appendix 2

Form of a Statement of Compliance of a Port Facility


D-1

D. Appendix. Safety Management System Regulations (New) Table D1 provides a detailed exploration of the requirements of the Federal and international

regulations or standards requiring safety management systems for major assets that operate in the U.S.

MTS, and documents which are related to cybersecurity or could be extended to address cyber issues.

Legend

Cyber-specific requirements are not applicable

Requirements could be extended to address cyber issues

✓ Cyber-specific requirements are explicitly defined or could be inferred to be in scope

Table D1. Relevant Safety Management Systems Regulations and Standards


33 CFR 96, Subpart B - Rules for the Safe Operation of Vessels and Safety Management Systems: Company and Vessel Safety Management Systems

Subpart A—General


Subpart B—Company and Vessel Safety Management Systems

§ 96.200 Purpose

§ 96.210 Who does this subpart apply to?

§ 96.220 What makes up a safety management system?

§ 96.230 What objectives must a safety management system meet?

§ 96.240 What functional requirements must a safety management system meet?

§ 96.250 What documents and reports must a safety management system have?

✓

Cyber elements could be specifically addressed in personnel knowledge of safety management system and operation of safety critical equipment and systems (f4-5)

Cyber elements could be specifically addressed in safety training of personnel to ensure they can recognize corruption of control systems. (f7)

Cyber elements could be specifically addressed in drills and exercises (h2)

Vessel maintenance should consider the reliability of safety critical systems and cybersecurity measures should be considered to reduce likelihood and consequences of accidental system (j5-6)

Subpart C—How Will Safety Management Systems Be Certificated and Enforced?


Subpart D—Authorization of Recognized Organizations to Act on Behalf of the U.S.


D-2



SOLAS Chapter IX: ISM Code Part A

1 General

Cyber elements could be specifically addressed in: Objectives (1.2) and functional requirements (1.4)

2 Safety and Environmental Protection Policy

Cyber elements could be specifically addressed in the protection policy

3 Company Responsibilities and Authority

4 Designated Persons

Cyber elements could be specifically addressed the designated person(s) monitoring the safety and pollution prevention aspects of the operation of each ship

5 Master’s Responsibility and Authority

6 Resources and Personnel

Cyber elements could be specifically addressed: In the master’s qualifications (6.1.2), the seafarer’s qualifications (6.2.1) and any training in support of SMS (6.5).

7 Shipboard Operations ✓

Procedures, plans and instructions should document Cyber elements and scenarios, if applicable

8 Emergency Preparedness

Cyber scenarios could be incorporated into: Emergency shipboard situations and drills & exercises.

9 Reports and Analysis of Non-conformities, Accidents and Hazardous Occurrences

10 Maintenance of the Ship and Equipment

Working order cybersecurity systems should be verified as well (10.3) and any cyber measures found should be integrated into the ship’s operational maintenance routine (10.4)

11 Documentation

12 Company Verification, Review and Evaluation

Part B


30 CFR Part 250 – Oil and Gas and Sulphur Operations in the OCS 30 CFR Part 250, Subpart S - SEMS

§250.1900 Must I have a SEMS program?

§250.1901 What is the goal of my SEMS program?

§250.1902 What must I include in my SEMS program?

§250.1903 Acronyms and definitions.

§250.1904 Special instructions.

§250.1909 What are management's general responsibilities for the SEMS program?


D-3


§250.1910 What safety and environmental information is required?

§250.1911 What hazards analysis criteria must my SEMS program meet?

Scope of hazard review could explicitly consider cyber vulnerabilities of safeguards that could lead to accidental hazardous material releases.

§250.1912 What criteria for management of change must my SEMS program meet?

§250.1913 What criteria for operating procedures must my SEMS program meet?

§250.1914 What criteria must be documented in my SEMS program for safe work practices and contractor selection?

§250.1915 What training criteria must be in my SEMS program?

Cyber elements could be specifically addressed in safety training of personnel to ensure they can recognize corruption of control systems.

§250.1916 What criteria for mechanical integrity must my SEMS program meet?

§250.1917 What criteria for pre-startup review must be in my SEMS program?

§250.1918 What criteria for emergency response and control must be in my SEMS program?

§250.1919 What criteria for investigation of incidents must be in my SEMS program?

§250.1920 What are the auditing requirements for my SEMS program?

§250.1921 What qualifications must the ASP meet?

§250.1922 What qualifications must an AB meet?

§250.1924 How will BSEE determine if my SEMS program is effective?

§250.1925 May BSEE direct me to conduct additional audits?

§250.1927 What happens if BSEE finds shortcomings in my SEMS program?

§250.1928 What are my recordkeeping and documentation requirements?


D-4


§250.1929 What are my responsibilities for submitting OCS performance measure data?

§250.1930 What must be included in my SEMS program for SWA?

§250.1931 What must be included in my SEMS program for UWA?

§250.1932 What are my EPP requirements?

§250.1933 What procedures must be included for reporting unsafe working conditions?

40 CFR 68 – Chemical Accident Prevention Provisions Subpart A—General


Subpart B—Hazard Assessment


Subpart C—Program 2 Prevention Program

§68.48 Safety information

§68.50 Hazard review

Scope of hazard review could explicitly consider cyber vulnerabilities of safeguards that could lead to accidental hazardous material releases.

§68.52 Operating procedures

§68.54 Training


§68.56 Maintenance

§68.58 Compliance audits

§68.60 Incident investigation

Subpart D—Program 3 Prevention Program

§68.65 Process safety information

§68.67 Process hazard analysis

Scope of PHA could explicitly consider cyber vulnerabilities of engineering controls and evaluate the range of the possible safety and health effects of failure of controls due to accidental corruption of control systems

§68.69 Operating procedures

§68.71 Training


§68.73 Mechanical integrity

§68.75 Management of change

§68.77 Pre-startup review

§68.79 Compliance audits

§68.81 Incident investigation


D-5


§68.83 Employee participation

§68.85 Hot work permit

§68.87 Contractors

Subpart E—Emergency Response


Subpart F—Regulated Substances for Accidental Release Prevention


Subpart G—Risk Management Plan


Subpart H—Other Requirements


29 CFR 1910.119 – PSM of Highly Hazardous Chemicals Standard (a) Application

(b) Definitions

(c) Employee participation

(d) Process safety information

(e) Process hazard analysis (PHA)

Scope of PHA could explicitly consider cyber vulnerabilities of engineering controls and evaluate the range of the possible safety and health effects of failure of controls due to accidental corruption of control systems

(f) Operating procedures

(g) Training


(h) Contractors

(i) Pre-startup safety review

(j) Mechanical integrity

(k) Hot work permit

(l) Management of change

(m) Incident investigation

(n) Emergency planning and response

49 CFR 193 – LNG Facilities: Federal Safety Standards 49 CFR 193 – LNG Facilities: Federal Safety Standards

Subpart A—General


Subpart B—Siting Requirements


Subpart C—Design



D-6


Subpart D—Construction


Subpart E—Equipment


Subpart F—Operations


Subpart G—Maintenance


Subpart H—Personnel Qualifications and Training

§193.2701 Scope

§193.2703 Design and fabrication

§193.2705 Construction, installation, inspection, and testing

§193.2707 Operations and maintenance

§193.2709 Security

§193.2711 Personnel health

§193.2713 Training: operations and maintenance

§193.2715 Training: security

Cyber elements could be specifically addressed in security training of personnel to ensure they recognize cyber intrusions (1) and conditions where assistance is needed (4)

§193.2717 Training: fire protection

§193.2719 Training: records

Subpart I—Fire Protection


Subpart J—Security

§193.2901 Scope

§193.2903 Security procedures

Security inspections could cover cybersecurity inspection activities (a). Security responsibilities/duties could be extended to cover cybersecurity activities (b/c)

§193.2905 Protective enclosures

§193.2907 Protective enclosure construction

§193.2909 Security communications

§193.2911 Security lighting

§193.2913 Security monitoring

Security monitoring could include measures designed to detect cyber intrusions.

§193.2915 Alternative power sources

§193.2917 Warning signs


E-1

E. Appendix. Point of Failure Detection Worksheets The following figures provide sample worksheets for high consequence asset classes. The asset

functions listed across the top of the worksheet are based on systems commonly deployed on the

assets.


E-1

Table E1. Point of Failure Detection Framework: General Cargo Vessel


E-2

Table E2. Point of Failure Detection Framework: Tank Vessel


E-3

Table E3. Point of Failure Detection Framework: Drill Ship or MODU


E-4

Table E4. Point of Failure Detection Framework: Tug and Barge


E-5

Table E5. Point of Failure Detection Framework: Cruise Ship


E-6

Table E6. Point of Failure Detection Framework: Ferry


E-7

Table E7. Point of Failure Detection Framework: CDC Facility


E-8

Table E8. Point of Failure Detection Framework: Petroleum Refinery


E-9

Table E9. Point of Failure Detection Framework: Marine Cargo Terminal


F-1

F. Appendix. USMC CSR Questionnaire

Table F1. USMC CSR Questionnaire

Question Answer

1. What are the staffing requirements and what are the skills required?

a. Is there a distinction between range operational staff and security research staff?

Both are available through ManTec.

b. What are the skill requirements for ops staff? ManTec offers hardware, software, specialized research, and management skills as required. Services are scalable and can be adjusted to meet special requirements of clients.

c. What are the skill requirements for the research staff?

Research staff skill requirements are “flexed” based on client research and training requirements.

d. Are the needed skills provided by formal education or field experience – in what mix?

Both

e. What is the most useful approach you have found to attracting staff?

Not discussed in depth. ManTec apparently has access to a relatively deep pool of resources and skills.

f. How does the range leverage “field” staff or user information to guide uses of or research by the range?

Clients provide information concerning research activities from multiple sources. Commercial clients test/validate products in the lab. Clients hold some test activities/results very closely as proprietary. Other clients jointly develop and share methods and research tools with the Cyber Range. Agreements on sharing follow multiple patterns based on client preferences.

2. What facility/physical requirements are necessary, nice, not needed?

a. What are the CRITICAL facilities and support structures?

Did not discuss in detail. It was clear that during the 7-8 year service life of the Range, trial and error guided some of the Range development activities.

b. What are the NICE-TO-HAVE facilities and support structures?

Not discussed except for indications that the Range is able to extend its capabilities depending on the nature of the request and the ability of the requestor to “plus-up” unusual costs for a particular research activity.

c. What are the “I wish I had thought of that…” facilities and support structures?

Not discussed except for anecdotal information about having flexed capabilities and resources for clients in the past.

d. What are the “I wish I hadn’t bought that…” facilities and support structures?

Not discussed.


F-2

Question Answer

e. Is there a lifecycle migration path that your recommend in hindsight?

This was not discussed specifically, but indications were that the Range has developed over its lifecycle to adjust to specific driving problems provided by multiple service branch and commercial clients.

3. What funding models worked/didn't work?

a. In the commercial space, options for funding exist (e.g., subscription; “pay-for-play”; free access in association with work-for-hire contacts; internally funded and internal-use only). How do you control/provide access and recover costs?

The Range is open to all funding models in direct and indirect service of the service branches, “*.gov” agencies, and supporting commercial product and service providers – including the USCG. Range staff recommended further communication within the DHS. General feeling was a need for additional communication between DHS, USCG and the Stevens project.

b. How do you charge or get paid? See above (3a)

4. What is to be mirrored?

a. Internet traffic, others? Yes

b. What do you simulate? This varies based on client requirements. The Range possesses strong capabilities for high fidelity simulations of extraodinarily large communications and data loads.

c. What do you emulate? Indications were that simulation rather than emulation is the primary approach (double check with Cris).

d. Have you determined which use case characteristics or “drivers” cause one approach to be more useful than the other?

Yes, through observation, funding tradeoffs, and empirical results à simulation.

5. Are there transfer opportunities?

a. Technology, processes... Yes

b. What are the “outputs” of the range? Training, test results, and research

c. Were outputs driven by formal requirements or anecdotally discovered?

Both. The outputs of the Range are need and opportunity driven.

d. Can your experimental and use-case targets be transferred outside of the range (e.g., …security architectures?; …secured function architectures?; …threat types/modes? …identities behind threats? …calculable risk models [“equations”]? …design for “protectability?”)?

Yes. The Functions-Connections-Identities model was discussed and was very interesting to the director. Cris also raised the idea of “mutating” network forms as being useful for honey-netting and protecting in the future. The Range team seemed to already be working in those areas. They were a bit guarded in their comments.

e. How do you draw the line between public and proprietary information?

The line is drawn based on service branch requirements and agreed-to contract arrangements with commercial clients.

f. How do you stay away from picking winners in the commercial space (the competitive vs. pre-competitive issue)?

The Range is very careful to NOT pick winners and has a staff member who strongly enforces that directive. However, the Range is positioning


F-3

Question Answer

itself to provide a type of “Good Housekeeping” seal based on specific test results and performance in the Range.

6. Are there licensing opportunities for software?

a. Do you develop requirements or recommendations for proprietary or commercial security solutions?

This is not clear to me, but I think they might (Check with Cris).

b. How is range-generated IP classified, disseminated, and protected?

By in-place governmental guidelines carefully following by ManTec. ManTex is clearly a highly experienced government contractor.

c. Do you license solutions? Not clear, but probably not.

7. Can you avoid full price software licensing for this use?

a. Do you seek evaluation licenses? …product testing licenses? …other?

The Range tries to reduce costs at any opportunity. Since it is used for testing software solutions, some commercial products are “left behind” after testing for additional use by the Range.

8. How is range use and recognition "promoted"?

a. Internal promotion (proprietary?) Training, directed outreach, networking

b. External promotion (public domain?) Training, directed outreach, networking

Date post:	01-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

MARITIME Y ERSE URITY PROJE T · Maritime Cybersecurity Project 1 1. Introduction In July of 2016,...

Documents