Maritime Cybersecurity Project

MARITIME CYBERSECURITY PROJECT

1. Risk-Based Performance Standards Recommendation 2. 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

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

i Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

iii

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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 U.S. Coast Guard Office of Performance Management and CG-DCO-81 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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

vii

Maritime Cybersecurity Project

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

viii

Maritime Cybersecurity Project

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 What risk-based performance standards can be developed for cyber Performance risk management of the Marine Transportation System (MTS)? How Standards 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 What type of criteria should be utilized to develop an academically Cyber Policy rigorous framework for Cyber Policy for the MTS? 3 Critical Points of Based on a multi-node analysis, what are the critical Points of Failure Failure within the cyber system supporting the MTS? 4 Requirements for What are the critical requirements that should be considered when Maritime Cyber developing an academically rigorous and multi-use Maritime Cyber Range Range? 5 Framework for What methodologies can be utilized or invented to develop a Point of Failure framework to analyze a point of Failure Detection Methodology? Detection Methodology 6 Maritime Cyber What methodologies can be employed to conduct a quantitative Deterrent Strategy analysis of maritime cyber deterrent strategy effectiveness? 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)

Maritime Cybersecurity Project

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/

Maritime Cybersecurity Project

• 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.

Maritime Cybersecurity Project

Figure 1. Example Port with Common MTS Components

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

• 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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

Figure 2. IT/OT Cybersecurity Overview

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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 Framework for Improving Critical Infrastructure 1 February 2014

Cybersecurity SP 800-82 Revision 2, Guide to Industrial Control 2 February 2015 Systems Security ISO 27001: Information Security Management 3 October 2013 Standard (Link not available)

4 C2M2 February 2014

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

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

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

Maritime Cybersecurity Project

# Organization Title Release Date

7 Instruction 8500.01, Cybersecurity March 2014

Transportation Systems Sector Cybersecurity 8 June 2015

Framework Implementation Guidance

9 The Guidelines on Cyber Security Onboard Ships February 2016

Interim Guidelines on Maritime Cyber Risk 10 June 2016

Management

Guidance Notes on the Application of 11 Cybersecurity Principles to Marine and Offshore September 2016

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

13 Top 20 Critical Security Controls (CSC) August 2016

14 SP 800-160, Systems Security Engineering May 2016

15 USCG Cyber Strategy June 2015

National Strategy for Trusted Identities in 16 April 2011

Cyberspace (NSTIC)

Maritime Bulk Liquids Transfer Cybersecurity 17 November 2016

Framework Profile

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

Maritime Cybersecurity Project

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 ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government ✓ International ✓ 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

Maritime Cybersecurity Project

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 Organization NIST Release Date February 2015 Type Standard Page Count 249 Audience Upper- and mid-level management, ICS security engineers, and system administrators

Maritime Cybersecurity Project

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 Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government ✓ International ✓ Offshore ✓ Vessels 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.

Maritime Cybersecurity Project

• 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 Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities OT ✓ Government ✓ International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

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 Type Standard Page Count 71 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

Maritime Cybersecurity Project

Content Focus

Notes: Directly-applicable implementation material begins on page 15 Applicability Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government ✓ International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

• 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 Type Standard Page Count 159 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 Primary Domains Stakeholders Geography Asset Types IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT Government ✓ International ✓ Offshore ✓ Vessels 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;

Maritime Cybersecurity Project

• 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 Organization ISA/IEC Release Date November 2011 Type Standard Page Count 89 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 Primary Domains Stakeholders Geography Asset Types IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT Government ✓ International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

• 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 Organization ISA/IEC Release Date November 2011 Type Standard Page Count 84 Audience Mid to lower-level management, IACS cybersecurity architects and designers, and policy-makers Content Focus

Applicability Primary Domains Stakeholders Geography Asset Types IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT Government ✓ International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

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 Organization NIST Release Date February 2005 Type Standard Page Count 130 Audience Diverse federal audience of information system and information security professionals Content Focus

Applicability Primary Domains Stakeholders Geography Asset Types ✓ IT Commercial ✓ U.S. ✓ Facilities OT ✓ Government International 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

Maritime Cybersecurity Project

• 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

Maritime Cybersecurity Project

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

Applicability Primary Domains Stakeholders Geography Asset Types ✓ IT Commercial ✓ U.S. ✓ Facilities OT ✓ Government International 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 Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities

Maritime Cybersecurity Project

✓ 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 Release Date February 2016 Maritime Council (BIMCO) Type Best Practices Page Count 36 Audience Ship owners and operators Content Focus

Maritime Cybersecurity Project

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 Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. Facilities ✓ OT Government ✓ International 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.

NIST

Iden fy Protect Detect Respond Recover

Iden fy Iden fy Assess Protect and Establish Respond to Threats Vulnerabili es Risks Detect Con ngency Plans Incidents ?

BIMCO

Maritime Cybersecurity Project

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 Type Best Practices Page Count 6 Audience Maritime risk managers Content Focus

Applicability Primary Domains Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT Government ✓ International ✓ Offshore ✓ Vessels 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:

Maritime Cybersecurity Project

• 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 Type Best Practices Page Count 45 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 ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT Government ✓ International ✓ Offshore ✓ Vessels 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.

Maritime Cybersecurity Project

• 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 Release Date April 2012 Control Association (ISACA) Type Standard Page Count 93 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 Systems Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities OT ✓ Government ✓ International ✓ Offshore ✓ Vessels Description

Maritime Cybersecurity Project

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 Type Best Practices Page Count 107 Audience High- to mid-level management and implementation staff Content Focus

Note: Very useful for IT and OT security management endeavors. Applicability Systems Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government ✓ International ✓ Offshore ✓ Vessels Description The CSCs is an international community activity to:

Maritime Cybersecurity Project

• 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 Type Standard Page Count 309 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 Systems Stakeholders Geography Asset Types

Maritime Cybersecurity Project

✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government ✓ International ✓ Offshore ✓ Vessels 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)

Maritime Cybersecurity Project

— 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 Type Policy Page Count 44 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.

Maritime Cybersecurity Project

Applicability Systems Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government International ✓ Offshore ✓ Vessels 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 Type Policy Page Count 52 Audience Public and private sector enterprises, individuals, organizations, networks, services, and devices involved in online transactions Content Focus

Maritime Cybersecurity Project

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 Systems Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

Organization NIST Release Date November 2016 Type Best Practices Page Count 154 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 Systems Stakeholders Geography Asset Types ✓ IT ✓ Commercial ✓ U.S. ✓ Facilities ✓ OT ✓ Government International ✓ Offshore ✓ Vessels 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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

Figure 3. Literature Review Summary

Maritime Cybersecurity Project

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)

Maritime Cybersecurity Project 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 New Mapping Original Mapping

1 3

- -

2 3

- -

Function 82

Category

Subcategory

IMO BIMCO ABS C2M2 800 NIST DHS TSS CSC CCS COBIT5 62443 ISA 62443 ISA ISO/IEC27001 SP NIST 800 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 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Maritime Cybersecurity Project

New Mapping Original Mapping

1 3

- -

2 3

- -

Function 82

Category

Subcategory

IMO BIMCO ABS C2M2 800 NIST DHS TSS CSC CCS COBIT5 62443 ISA 62443 ISA ISO/IEC27001 SP NIST 800 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

Maritime Cybersecurity Project

New Mapping Original Mapping

1 3

- -

2 3

- -

Function 82

Category

Subcategory

IMO BIMCO ABS C2M2 800 NIST DHS TSS CSC CCS COBIT5 62443 ISA 62443 ISA ISO/IEC27001 SP NIST 800 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 ✓ ✓ ✓ ✓ ✓ ✓ ✓

Maritime Cybersecurity Project

New Mapping Original Mapping

1 3

- -

2 3

- -

Function 82

Category

Subcategory

IMO BIMCO ABS C2M2 800 NIST DHS TSS CSC CCS COBIT5 62443 ISA 62443 ISA ISO/IEC27001 SP NIST 800 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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Figure 4. Recommended Performance Standards – Facility Decision Tree

Maritime Cybersecurity Project

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

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

Maritime Cybersecurity Project

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

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

Maritime Cybersecurity Project

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 & BSEE is responsible for promoting safety, protecting the Environmental environment, and conserving resources offshore through Enforcement (BSEE) 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 PHMSA’s mission is to protect people and the environment by Transportation (DOT) advancing the safe transportation of energy and other hazardous Pipeline and Hazardous materials that are essential to our daily lives. To do this, the Materials Safety Administration agency establishes national policy, sets and enforces standards, (PHMSA) educates, and conducts research to prevent incidents. Environmental The EPA's basic mission is to protect human health and the Protection Agency environment -- air, water, and land. EPA, state, local and tribal (EPA) 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 & The OSHA’s mission is to assure safe and healthful working Health Administration conditions for working men and women by setting and enforcing (OSHA) 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.

Maritime Cybersecurity Project

Figure 7. Regulatory Oversight for Common MTS Components

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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 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: • §105.200 Owner or operator • §105.205 Facility Security Officer (FSO) • §105.210 Facility personnel with security duties • §105.215 Security training for all other facility personnel • §105.220 Drill and exercise requirements • §105.235 Communications • §105.250 Security systems and equipment maintenance • §105.260 Security measures for restricted areas • §105.265 Security measures for handling cargo • §105.275 Security measures for monitoring • §105.280 Security incident procedures • §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 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: • §106.200 Owner or operator • §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

Maritime Cybersecurity Project

• §106.225 Drill and exercise requirements • §106.240 Communications • §106.255 Security systems and equipment maintenance • §106.265 Security measures for restricted areas • §106.270 Security measures for delivery of stores and industrial supplies • §106.275 Security measures for monitoring • §106.280 Security incident procedures • §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

Maritime Cybersecurity Project

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 Part B 1 - General 1 – Introduction 4 - Responsibilities of Contracting Governments 4 - Responsibilities of Contracting Governments 5 - Declaration of Security 5 - Declaration of Security 7 - Ship Security 8 - Ship Security Assessment 8 - Ship Security Assessment 9 - Ship Security Plan 9 - Ship Security Plan 13 - Training, Drills and Exercises on Ship Security 11 - CSO 15 - Port Facility Security Assessment 12 - SSO 16 - Port Facility Security Plan 13 - Training, Drill and Exercises on Ship Security 18 - Training, Drills and Exercises on Port Facility 14 - Port Facility Security Security 15 - Port Facility Security Assessment 16 - Port Facility Security Plan 17 - PFSO 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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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 • Management of Change • Process Hazard Analysis (PHA) • Incident Investigation • Operating Procedures • Compliance Audits • Training • Trade Secrets • Contractors • Employee Participation • Mechanical Integrity • Pre-startup Safety Review • Hot Work • 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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project 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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project 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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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, Risk Level Criteria vulnerability, and consequence factor scores. The result is a Very High >10K RIN relative expected loss risk score, expressed in units of Risk Index High 500 to 10K RIN Number (RIN), for each scenario. Scenarios are then mapped into Medium 100 to 500 RIN one of five risk levels (Figure 14) based on their risk scores. Risk Low 10 to 100 RIN levels are used in many applications to help the USCG and its Very Low 0 to 10 RIN partners focus their resources on very high and high risk scenarios. Figure 14. MSRAM Risk Levels 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/

Maritime Cybersecurity Project 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:

Maritime Cybersecurity Project

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 Figure 15. The Fire Triangle

Logically, the components of the security risk equation can replace the fire triangle elements (Figure 16).

Maritime Cybersecurity Project

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 Figure 16. Security Risk Triangle 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 Figure 17. Cybersecurity Risk Triangle 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.”

Maritime Cybersecurity Project

• 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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

• 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 • Consequential • Mission-oriented • Inconsequential Connections • Discrete • Vulnerable • Simple • Invulnerable • Complex • VLN Identities • Human • Threatening • Machine • 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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project 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

Maritime Cybersecurity Project

Figure 20. Virtual Asset Diagram

Maritime Cybersecurity Project

Figure 21. Example 1: Segmented Architecture

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

• 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,

Maritime Cybersecurity Project

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)

Maritime Cybersecurity Project

• 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.

Maritime Cybersecurity Project

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.

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

Table 12. Cyber Scenario Framework

Asset Classes Incidents: Safety-critical Function Exploitation Event Potential Consequences Commercial Vessel Propulsion System: Increase or decrease speed at • Grounding • Loss of life/injuries to crew Communities: Systems found on critical moments during port transit or extreme • Collision/Allision and passengers most commercial vessels weather at sea • Flooding/Sinking • Vessel damage • Freight Ship Steering/Maneuvering Control System: Take vessel • Spill of fuel oil • Industrial Vessel off course at critical moments during port transit or • Channel blockage • Mobile Offshore Drilling Unit extreme weather at sea • Offshore Supply Vessel Navigation Systems: Take vessel off course at critical • Passenger (More Than 6) moments during port transit • Public Tankship/Barge Power Management System: Lose power or • Public Vessel, Unclassified overpower vessel at critical moments during port • Research Vessel transit or extreme weather at sea • School Ship • Tank Ship Ballast Control System: Facilitate improper loading, • Towing Vessel causing listing or potentially exceeding hull loading limits Tank Ship Cargo Management System: Open valves to release of • Oil, refined product, or • Spill of oil, refined product, oil, refined product, or certain dangerous cargo (CDC) CDC spill or CDC during port transit • Navigation restriction • Loss of life to crew and nearby populations • Evacuation of port areas • Navigation restriction Mobile Offshore Drilling Unit Dynamic Positioning System: Take MODU off station • Emergency disconnects • Spill of oil and drilling mud in at critical moments during drilling operations • Loss of well control the riser Drilling Control System: Affect drilling system • Navigation restriction performance at critical moments during drilling • Loss of life/injuries to crew 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 • Oil, refined product, or • Spill of oil, refined product, from facility’s processing or storage equipment CDC spill or CDC • Navigation restriction

Maritime Cybersecurity Project

Asset Classes Incidents: Safety-critical Function Exploitation Event Potential Consequences • Loss of life to crew and nearby populations • Evacuation of port areas • Navigation restriction Waterfront Facility (Container Crane Control System: Affect crane system • Container drop • Loss of life/injuries to Terminal) performance at critical moments during container • Crane damage workers loading/unloading operations • Crane damage, resulting in reduced port throughput Terminal Operating System: Unavailability of terminal • Inability to load or • Port disruption operating system or corruption of data. Improper unload cargo loading of container, affecting ship stability

Maritime Cybersecurity Project

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.

100

Maritime Cybersecurity Project

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.

101

Maritime Cybersecurity Project

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%

102

Maritime Cybersecurity Project

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.

103

Maritime Cybersecurity Project

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

104

Maritime Cybersecurity Project

• 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.

105

Maritime Cybersecurity Project

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

106

Maritime Cybersecurity Project

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

107

Maritime Cybersecurity Project

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.

108

Maritime Cybersecurity Project

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: Figure 33. USMC CSR Connectivity Diagram • 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.

109

Maritime Cybersecurity Project

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

110

Maritime Cybersecurity Project

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.

111

Maritime Cybersecurity Project

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.

112

Maritime Cybersecurity Project

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

113

Maritime Cybersecurity Project

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.

114

Maritime Cybersecurity Project

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 NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 Identify Asset Management ID.AM-1: Physical devices and 3.5.1 3.4.1 ACM-1a 3.3.2 G1 1 BAI09.01, 4.2.3.4 SR 7.8 A.8.1.1, CM-8 systems within the organization ACM-1c BAI09.02 A.8.1.2 are inventoried ACM-1e ACM-1f ID.AM-2: Software platforms and 3.5.1 P2 3.4.1 ACM-1a 3.3.2 G1 2 BAI09.01, 4.2.3.4 SR 7.8 A.8.1.1, CM-8 applications within the ACM-1c BAI09.02, A.8.1.2 organization are inventoried ACM-1e BAI09.05 ACM-1f ID.AM-3: Organizational 3.5.1 P5 3.4.1 RM-2g 3.3.2 G1 1 DSS05.02 4.2.3.4 A.13.2.1 AC-4, CA-3, communication and data flows ACM-1e CA-9, PL-8 are mapped ID.AM-4: External information 3.5.1 P3 3.4.1 EDM-1a G1 APO02.02 A.11.2.6 AC-20, SA-9 systems are catalogued EDM-1c EDM-1e EDM-1g RM- 1c ID.AM-5: Resources (e.g., 3.5.1 P3 1.4.2 ACM-1a 3.3.2 G1 APO03.03, 4.2.3.6 A.8.2.1 CP-2, RA-2, hardware, devices, data, and ACM-1b APO03.04, SA-14 software) are prioritized based ACM-1c BAI09.02 on their classification, criticality, ACM-1d and business value ID.AM-6: Cybersecurity roles and 3.5.1 P2, P3 1.4.1.1.2 WM-1a WM- 2.4 G1 APO01.02, 4.3.2.3.3 A.6.1.1 CP-2, PS-7, responsibilities for the entire 1b DSS06.03 PM-11 workforce and third-party WM-1c stakeholders (e.g., suppliers, customers, partners) are established Business Environment

A-1

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 ID.BE-1: The organization’s role 3.5.1 P2 3.4.2.3 EDM-1b 2.4 G5 APO08.04, A.15.1.3, CP-2, SA-12 in the supply chain is identified EDM-1d APO08.05, A.15.2.1, and communicated EDM-1f APO10.03, A.15.2.2 EDM-1g RM- APO10.04, 1c APO10.05 ID.BE-2: The organization’s place 3.5.1 P1 1.4.2.1 EDM-1b 4.1 G5 APO02.06, PM-8 in critical infrastructure and its EDM-1d APO03.01 industry sector is identified and EDM-1f communicated CPM-1c EDM-1g RM- 1c ID.BE-3: Priorities for 3.5.1 1.4.2.1 RM-3b 4.1 G5 APO02.01, 4.2.2.1, PM-11, SA- organizational mission, RM-1c APO02.06, 4.2.3.6 14 objectives, and activities are APO03.01 established and communicated ID.BE-4: Dependencies and 3.5.1 P3 1.4.2.2 ACM-1a 2.3.1, 3.3.2, G5 A.11.2.2, CP-8, PE-9, critical functions for delivery of ACM-1b 3.3.6 A.11.2.3, PE-11, PM-8, critical services are established EDM-1a A.12.1.3 SA-14 ACM-1c ACM-1d EDM-1c EDM-1e ACM-1e ACM-1f RM- 1c EDM-1g ID.BE-5: Resilience requirements 3.5.1 P3, P5 1.4.2.4, 2.4.1 IR-4a IR-4b 2.1 G5 DSS04.02 A.11.1.4, CP-2, CP-11, to support delivery of critical IR-4c A.17.1.1, SA-14 services are established IR-4e A.17.1.2, A.17.2.1 Governance ID.GV-1: Organizational 3.5.1 P2 ALL CPM-2g 4.3, 4.4 G5 APO01.03, 4.3.2.6 A.5.1.1 -1 controls information security policy is CPM-5d RM- EDM01.01, from all established 3e EDM01.02 families ID.GV-2: Information security 3.5.1 1.4.1.1.2, WM-1a WM- 3.3.3 G5 APO13.12 4.3.2.3.3 A.6.1.1, PM-1, PS-7 roles & responsibilities are 2.4.2.1, 1b A.7.2.1 coordinated and aligned with 2.4.3.1, WM-1c WM- 2.4.3.3 2d WM-5b A-2

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 internal roles and external ISC-2b partners WM-1e WM- 1f WM-1g

ID.GV-3: Legal and regulatory 3.5.1 P1 12.4.2.1 CPM-2k IR- 4.3 G5 MEA03.01, 4.4.3.7 A.18.1 -1 controls requirements regarding 3n RM-3f MEA03.04 from all cybersecurity, including privacy ACM-4f IAM- families and civil liberties obligations, are 3f TVM-3f (except PM- understood and managed SA-4f ISC-2f 1) IR-5f EDM-3f WM-5f ID.GV-4: Governance and risk 2.1.6, 3.4, P3 2.4.2, 2.4.3, RM-2a RM- 3.1 G5 DSS04.02 4.2.3.1, PM-9, PM-11 management processes address 3.5.1 2.4.4 2b 4.2.3.3, cybersecurity risks RM-2h RM- 4.2.3.8, 3e RM-1c 4.2.3.9, RM-1e 4.2.3.11, 4.3.2.4.3, 4.3.2.6.3 Risk Assessment ID.RA-1: Asset vulnerabilities are 2.1.4, 3.5.1 P5; Section 3.4.1.3, TVM-2a Appendix C G1, P1-1 4 APO12.01, 4.2.3, A.12.6.1, CA-2, CA-7, identified and documented 2.1 3.4.1.4, TVM-2b APO12.02, 4.2.3.7, A.18.2.3 CA-8, RA-3, 3.4.1.5 TVM-2d APO12.03, 4.2.3.9, RA-5, SA-5, TVM-2e APO12.04 4.2.3.12 SA-11, SI-2, TVM-2f SI-4, SI-5 RM-1c RM-2j TVM-2i TVM- 2j TVM-2k TVM-2l TVM- 2m ID.RA-2: Threat and vulnerability 3.5.1 P5; Section 1.4.3.2, TVM-1a 4.1.3, D-2, D- G1, P1-1, P1- 4.2.3, A.6.1.4 PM-15, PM- information is received from 1, 2.1 3.4.2.3, TVM-1b 4 2 4.2.3.9, 16, SI-5 information sharing forums and 6.4.1, 6.4.2 TVM-2a 4.2.3.12 sources TVM-2b TVM-2d

A-3

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 ID.RA-3: Threats, both internal 2.1.4, 3.5.1 P3; Section 1 3.4.1, 4.4.1, TVM-1a 3.2 G1 APO12.01, 4.2.3, RA-3, SI-5, and external, are identified and 5.4.1, 6.4.1, TVM-1b APO12.02, 4.2.3.9, PM-12, PM- documented 7.4.1, 8.4.1, TVM-1d APO12.03, 4.2.3.12 16 9.4.1, 10.4.1, TVM-1e APO12.04 12.4.2.1.2, RM-2j TVM- 13.4.2 1j

ID.RA-4: Potential business 2.1.6, 3.5.1 P3; Section 1.4.1.1.3, TVM-1d 3.2 G1, P1-2 DSS04.02 4.2.3, RA-2, RA-3, impacts and likelihoods are 2.2, 2.3 1.4.2 TVM-1f 4.2.3.9, PM-9, PM- identified RM-1c TVM- 4.2.3.12 11, SA-14 1i ID.RA-5: Threats, vulnerabilities, 2.1.4, 2.1.6, P3; Section 1.4.1 RM-1c RM-2j 3.2 G1 APO12.02 A.12.6.1 RA-2, RA-3, likelihoods, and impacts are used 3.5.1 2.2, 2.3 TVM-2m PM-16 to determine risk ID.RA-6: Risk responses are 3.4, 3.5.1 P3; Section 3 2.4.1.8, RM-2e TVM- 3.2 G1 APO12.05, PM-4, PM-9 identified and prioritized 2.4.2, 2.4.3 1d APO13.02 RM-1c RM-2j IR-3m Risk Management Strategy ID.RM-1: Risk management 2.1.4, 3.5.1 P3; Section 3 All RM-2a RM- 4.1.1 G1, P1-1 APO12.04, 4.3.4.2 PM-9 processes are established, 2b APO12.05, managed, and agreed to by RM-1a RM- APO13.02, organizational stakeholders 1b RM-2c BAI02.03, RM-2d RM- BAI04.02 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

A-4

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 ID.RM-2: Organizational risk 3.4, 3.5 1 P3 2.4.1 RM-1c RM- 4.1.1 G1, P1-1 APO12.06 4.3.2.6.5 PM-9 tolerance is determined and 1e clearly expressed ID.RM-3: The organization’s 3.5.1 P3 2.4.1 RM-1b 4.1.1, 4.1.2 G1, P1-1 PM-8, PM-9, determination of risk tolerance is RM-1c PM-11, SA- informed by its role in critical 14 infrastructure and sector specific risk analysis Protect Access Control PR.AC-1: Identities and 3.5.2 4.4.1 IAM-1a IAM- 5.15, 6.2, G1 16 DSS05.04, 4.3.3.5.1 SR 1.1, SR A.9.2.1, AC-2, IA credentials are managed for 1b IAM-1c 6.2.7.4 DSS06.03 1.2, SR 1.3, A.9.2.2, Family authorized devices and users IAM-1d IAM- SR 1.4, SR A.9.2.4, 1e IAM-1f 1.5, SR 1.7, A.9.3.1, RM-1c IAM- SR 1.8, SR 1.9 A.9.4.2, 1g A.9.4.3 PR.AC-2: Physical access to assets 3.5.2 2.4.11, 10.4 IAM-2a IAM- 5.4. 6.2, G1 DSS01.04, 4.3.3.3.2, A.11.1.1, PE-2, PE-3, is managed and protected 2b IAM-2c 6.2.11 DSS05.05 4.3.3.3.8 A.11.1.2, PE-4, PE-5, IAM-2d IAM- A.11.1.4, PE-6, PE-9 2e IAM-2f A.11.1.6, IAM-2g A.11.2.3 PR.AC-3: Remote access is 3.5.2 5.4 IAM-2a IAM- 2.4, 5.3, G1 APO13.01, 4.3.3.6.6 SR 1.13, SR A.6.2.2, AC-17, AC- managed 2b IAM-2c 5.8.6, 5.10.2, DSS01.04, 2.6 A.13.1.1, 19, AC-20 IAM-2d IAM- 6.2.1 DSS05.03 A.13.2.1 2e IAM-2f IAM-2g

PR.AC-4: Access permissions are 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, AC-2, AC-3, managed, incorporating the A.9.1.2, AC-5, AC-6, principles of least privilege and A.9.2.3, AC-16 separation of duties A.9.4.1, A.9.4.4 PR.AC-5: Network integrity is 3.5.2 P5 3.4.1.4, CPM-3a 5.1, 5.5, G1 4.3.3.4 SR 3.1, SR 3.8 A.13.1.1, AC-4, SC-7 protected, incorporating network 3.4.1.5, 3.4.2 CPM-3b 5.5.6 A.13.1.3, segregation where appropriate CPM-3c A.13.2.1 CPM-3d

A-5

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 Awareness and Training PR.AT-1: All users are informed 3.3, 3.5.2, P3 7.4 WM-3a WM- 6.2.2 G3, P1-1 9 APO07.03, 4.3.2.4.2 A.7.2.2 AT-2, PM-13 and trained 3.5.7 4a BAI05.07 WM-3b WM- 3c WM-3d WM-3g WM- 3h WM-3i PR.AT-2: Privileged users 3.5.2 P3 7.4.1.2 WM-1a WM- 3.3.1, 4.1.4, G3 9 APO07.02, 4.3.2.4.2, A.6.1.1, AT-3, PM-13 understand roles & 1b 4.2, 6.2.2 DSS06.03 4.3.2.4.3 A.7.2.2 responsibilities WM-1c WM- 1d WM-1e WM- 1f WM-1g PR.AT-3: Third-party 3.5.2 P3 7/4/1, WM-1a WM- 3.3.1 G3, P1-1 9 APO07.03, 4.3.2.4.2 A.6.1.1, PS-7, SA-9 stakeholders (e.g., suppliers, 1.4.1.2 1b APO10.04, A.7.2.2 customers, partners) understand WM-1c WM- APO10.05 roles & responsibilities 1d WM-1e WM- 1f WM-1g PR.AT-4: Senior executives 3.3, 3.5.2 P3 7.4.1.2, WM-1a WM- 4.1.4 G3 9 APO07.03 4.3.2.4.2 A.6.1.1, AT-3, PM-13 understand roles & 2.4.2.2 1b A.7.2.2, responsibilities WM-1c WM- 1d WM-1e WM- 1f WM-1g PR.AT-5: Physical and 3.5.2 P3 7.4.1.3 WM-1a WM- 3.3.1 G3, P1-1 9 APO07.03 4.3.2.4.2 A.6.1.1, AT-3, PM-13 information security personnel 1b A.7.2.2, understand roles & WM-1c WM- responsibilities 1d WM-1e WM- 1f WM-1g Data Security PR.DS-1: Data-at-rest is 2.1.2, 3.5.2 P5 13.4.6 TVM-1c 5.14 G4 17 APO01.06, SR 3.4, SR 4.1 A.8.2.3 SC-28 protected TVM-2c BAI02.01, BAI06.01, DSS06.06

A-6

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 PR.DS-2: Data-in-transit is 2.1.2, 3.5.2 P5 3.4.1.4 TVM-1c 5.14 G4 17 APO01.06, SR 3.1, SR A.8.2.3, SC-8 protected TVM-2c DSS06.06 3.8, SR 4.1, A.13.1.1, SR 4.2 A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 PR.DS-3: Assets are formally 3.5.2 P5 12.4.2 ACM-3a ref to G4 BAI09.03 4. 4.3.3.3.9, SR 4.2 A.8.2.3, CM-8, MP-6, managed throughout removal, ACM-3b ISO27001, 4.3.4.4.1 A.8.3.1, PE-16 transfers, and disposition ACM-3c 5.10.1 A.8.3.2, ACM-3d A.8.3.3, ACM-4a A.11.2.7 ACM-4b ACM-4c ACM-4d ACM-3f ACM-4e ACM-4f ACM-4g PR.DS-4: Adequate capacity to 3.5.2 P5 2.4.1 TVM-1c 6.2.3, 2.3.1, G4 APO13.01 SR 7.1, SR 7.2 A.12.3.1 AU-4, CP-2, ensure availability is maintained TVM-2c 2.4 SC-5 CPM-3b PR.DS-5: Protections against data 2.1.2, 3.5.2 P5 3.4.1.4, TVM-1c 5.14 G4 17 APO01.06 SR 5.2 A.6.1.2, AC-4, AC-5, leaks are implemented 3.4.2.2.2 TVM-2c A.7.1.1, AC-6, PE-19, CPM-3b A.7.1.2, PS-3, PS-6, TVM-2n A.7.3.1, SC-7, SC-8, A.8.2.2, SC-13, SC-31, A.8.2.3, SI-4 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, A-7

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 A.14.1.2, A.14.1.3

PR.DS-6: Integrity checking 3.5.2 P5 13.4 SA-2e 2.4, 6.2.17 G4 SR 3.1, SR A.12.2.1, SI-7 mechanisms are used to verify SA-2i 3.3, SR 3.4, A.12.5.1, software, firmware, and SR 3.8 A.14.1.2, information integrity A.14.1.3 PR.DS-7: The development and 3.5.2 P2, P3 ACM-3c G4 BAI07.04 A.12.1.4 CM-2 testing environment(s) are ACM-3e separate from the production environment Information Protection Processes and Procedures PR.IP-1: A baseline configuration 3.4, 3.5.2 1.4.2.1, ACM-2a G1, P1-1 3, 10 BAI10.01, 4.3.4.3.2, SR 7.6 A.12.1.2, CM-2, CM-3, of information 2.4.1, 3.4.1, ACM-2b BAI10.02, 4.3.4.3.3 A.12.5.1, CM-4, CM-5, technology/industrial control 3.4.2 ACM-2c BAI10.03, A.12.6.2, CM-6, CM-7, systems is created and ACM-2d BAI10.05 A.14.2.2, CM-9, SA-10 maintained ACM-2e A.14.2.3, A.14.2.4 PR.IP-2: A System Development 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, SA-3, SA-4, Life Cycle to manage systems is A.14.1.1, SA-8, SA-10, implemented A.14.2.1, SA-11, SA-12, A.14.2.5 SA-15, SA-17, PL-8 PR.IP-3: Configuration change 3.5.2 P2 13.4 ACM-3a 6.2.5 G1 BAI06.01, 4.3.4.3.2, SR 7.6 A.12.1.2, CM-3, CM-4, control processes are in place ACM-3b BAI01.06 4.3.4.3.3 A.12.5.1, SA-10 ACM-3c A.12.6.2, ACM-3d A.14.2.2, ACM-4a A.14.2.3, ACM-3e A.14.2.4 ACM-3f ACM-4e PR.IP-4: Backups of information 3.5.2 P5 13.4.5.1, 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, CP-4, CP-6, are conducted, maintained, and 13.4.6 A.17.1.2A.17. CP-9 tested periodically 1.3, A.18.1.3

A-8

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 PR.IP-5: Policy and regulations 3.5.2 P2 10.4 ACM-4f RM- 3.2, 6.2.11 G1 DSS01.04, 4.3.3.3.1 A.11.1.4, PE-10, PE-12, regarding the physical operating 3f DSS05.05 4.3.3.3.2, A.11.2.1, PE-13, PE-14, environment for organizational 4.3.3.3.3, A.11.2.2, PE-15, PE-18 assets are met 4.3.3.3.5, A.11.2.3 4.3.3.3.6 PR.IP-6: Data is destroyed 3.5.2 ACM-3d 6.2.10, G1 BAI09.03 4.3.4.4.4 SR 4.2 A.8.2.3, MP-6 according to policy 6.2.14 A.8.3.1, A.8.3.2, A.11.2.7 PR.IP-7: Protection processes are 3.5.2 P3 1.4.3, CPM-1g 3.1, 4.1.4 G1, P1-2 APO11.06, 4.4.3.1, CA-2, CA-7, continuously improved 1.4.3.1, DSS04.05 4.4.3.2, CP-2, IR-8, 1.4.3.3 4.4.3.3, PL-2, PM-6 4.4.3.4, 4.4.3.5, 4.4.3.6, 4.4.3.7, 4.4.3.8 PR.IP-8: Effectiveness of 3.5.2 1.4.1.2, ISC 1a ISC-1b 6.1.6, ref SP G1 A.16.1.6 AC-21, CA-7, protection technologies is shared 1.4.2.5, ISC-1c ISC-1d 800-40 SI-4 with appropriate parties 1.4.2.6, ISC-1e ISC-1f 1.4.3, 1.4.3.1 ISC-1g ISC-2b ISC-1h ISC-1i ISC-1j ISC-1k ISC-1l PR.IP-9: Response plans (Incident 3.5.2 2.4 IR-4c 6.2.8 G1 DSS04.03 4.3.2.5.3, A.16.1.1, CP-2, IR-8 Response and Business IR-3f IR-4d 4.3.4.5.1 A.17.1.1, Continuity) in place and managed IR-4f IR-5a A.17.1.2 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 PR.IP-10: Response and recovery 3.5.2 1.4.3.1 IR-3e IR-4f G1 4.3.2.5.7, SR 3.3 A.17.1.3 NIST SP 800- plans are tested IR-3k IR-4i IR- 4.3.4.5.11 53 Rev.4 CP- 4j A-9

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 4, IR-3, PM- 14 PR.IP-11: Cybersecurity is 3.5.2 1.4.1.1, WM-2a WM- G1 APO07.01, 4.3.3.2.1, A.7.1.1, PS Family included in human resources 1.4.2.5, 1.4.3 2b APO07.02, 4.3.3.2.2, A.7.3.1, practices (e.g., deprovisioning, WM-2c WM- APO07.03, 4.3.3.2.3 A.8.1.4 personnel screening) 2d APO07.04, WM-2e WM- APO07.05 2f WM-2g WM-2h PR.IP-12: A vulnerability 3.5.2 P3, P5 1.4 TVM-3a 6.2.17.3 G1 A.12.6.1, RA-3, RA-5, management plan is developed TVM-3e A.18.2.2 SI-2 and implemented Maintenance PR.MA-1: Maintenance and 3.5.2 P3 13.4.7 ACM-3b 5.16 G1 BAI09.03 4.3.3.3.7 A.11.1.2, MA-2, MA-3, repair of organizational assets is ACM-4c A.11.2.4, MA-5 performed and logged in a timely ACM-3f A.11.2.5 manner, with approved and controlled tools PR.MA-2: Remote maintenance 3.5.2 8.4 SA-1a IR-1c 5.16, 5.10.2, G1 DSS05.04 4.3.3.6.5, A.11.2.4, MA-4 of organizational assets is IAM-2a IAM- 6.2.1 4.3.3.6.6, A.15.1.1, approved, logged, and performed 2b IAM-2c 4.3.3.6.7, A.15.2.1 in a manner that prevents IAM-2d IAM- 4.4.4.6.8 unauthorized access 2e IAM-2f IAM-2g IAM- 2h Protective Technology PR.PT-1: Audit/log records are 3.5.2 P2 4.4.3.2, SA-1a SA-2a 5.16, 6.2, G3 14 APO11.04 4.3.3.3.9, SR 2.8, SR A.12.4.1, AU Family determined, documented, 4.4.3.3, SA-1b SA-1c 6.2.3 4.3.3.5.8, 2.9, SR 2.10, A.12.4.2, implemented, and reviewed in 3.4.2.2.1, SA-2e SA-4a 4.3.4.4.7, SR 2.11, SR A.12.4.3, accordance with policy 3.4.2.2.4 SA-1d 4.4.2.1, 2.12 A.12.4.4, SA-1e 3dSA- 4.4.2.2, A.12.7.1 4e SA-4f SA- 4.4.2.4 4g PR.PT-2: Removable media is 3.5.2 8.4 IAM-2a IAM- 6.2.10, G3 DSS05.02, SR 2.3 A.8.2.2, MP-2, MP-4, protected and its use restricted 2b IAM-2c 6.2.14 APO13.01 A.8.2.3, MP-5, MP-7 according to policy A.8.3.1,

A-10

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 IAM-3e IAM- A.8.3.3, 3f A.11.2.9 PR.PT-3: Access to systems and 3.5.2 P5 4.4.1.1 IAM-2a IAM- G-28 CM-7 G3 DSS05.02 4.3.3.5.1, SR 1.1, SR A.9.1.2 AC-3, CM-7 assets is controlled, incorporating 2b IAM-2c 4.3.3.5.2, 1.2, SR 1.3, the principle of least functionality IAM-2d IAM- 4.3.3.5.3, SR 1.4, SR 2e IAM-2f 4.3.3.5.4, 1.5, SR 1.6, IAM-2g IAM- 4.3.3.5.5, SR 1.7, SR 2h IAM-2i 4.3.3.5.6, 1.8, SR 1.9, 4.3.3.5.7, SR 1.10, SR 4.3.3.5.8, 1.11, SR 4.3.3.6.1, 1.12, SR 4.3.3.6.2, 1.13, SR 2.1, 4.3.3.6.3, SR 2.2, SR 4.3.3.6.4, 2.3, SR 2.4, 4.3.3.6.5, SR 2.5, SR 4.3.3.6.6, 2.6, SR 2.7 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 PR.PT-4: Communications and 3.5.2 P3 3.4.2.2 CPM-3a 3, 3.3.6, 4, 5, G3 7 DSS05.02, SR 3.1, SR A.13.1.1, AC-4, AC-17, control networks are protected CPM-3b 6 APO13.01 3.5, SR 3.8, A.13.2.1 AC-18, CP-8, CPM-3c SR 4.1, SR SC-7 CPM-3d 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 Detect Anomalies and Events DE.AE-1: A baseline of network 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, operations and expected data CM-2, SI-4 flows for users and systems is established and managed

A-11

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 DE.AE-2: Detected events are 3.5.3 P5 2.4.4 IR-1f IR-2i IR- 5.3, 6.2.8, ref G4, P1-2 4.3.4.5.6, SR 2.8, SR A.16.1.1, AU-6, CA-7, analyzed to understand attack 3h SP 800-94 4.3.4.5.7, 2.9, SR 2.10, A.16.1.4 IR-4, SI-4 targets and methods 4.3.4.5.8 SR 2.11, SR 2.12, SR 3.9, SR 6.1, SR 6.2 DE.AE-3: Event data are 3.5.3 P5 2.4.4.5, IR-1e Appendix E- G4 SR 6.1 AU-6, CA-7, aggregated and correlated from 4.4.3.3, IR-1f IR-2i Intrusion IR-4, IR-5, IR- multiple sources and sensors 5.4.2.4 Detection 8, SI-4 and Prevention DE.AE-4: Impact of events is 2.1.6, 3.5.3 P3 1.4.2.3, IR-2b 3.3.2, 3.3.3, G4, P1-2 APO12.06 CP-2, IR-4, determined 2.4.1.2, IR-2d TVM- 3.3.4, 3.3.5, RA-3, SI -4 2.4.1.3, 1d 3.3.6 2.4.4.5 IR-2g RM-2j DE.AE-5: Incident alert 3.5.3 P5 1.4.2.1, IR-2a 5.2, 6.2, G4, P1-2 APO12.06 4.2.3.10 IR-4, IR-5, IR- thresholds are established 2.4.1.2, IR-2d TVM- 6.2.3, 6.2.17 8 2.4.1.3, 1d SA-2d 2.4.4.2 IR-2g RM-2j Security Continuous Monitoring DE.CM-1: The network is 3.5.3 2.4.4.2, SA-2a SA-2b 5.16 G4 14, 16 DSS05.07 SR 6.2 AC-2, AU-12, monitored to detect potential 5.4.2, 9.4.2 SA-2e SA-2f CA-7, CM-3, cybersecurity events TVM-1d SC-5, SC-7, SA-2g SA-2i SI-4 DE.CM-2: The physical 3.5.3 10.4.1.3, SA-2a SA-2b 3.3, 3.3.5, G4 4.3.3.3.8 CA-7, PE-3, environment is monitored to 10.4.1.4.1 SA-2e 5.2 PE-6, PE-20 detect potential cybersecurity SA-2i events DE.CM-3: Personnel activity is 3.5.3 6.4.1.3, SA-2a SA-2b 6.2.13, 6.2.3 G4 SR 6.2 A.12.4.1 AC-2, AU-12, monitored to detect potential 6.4.1.4, SA-2e AU-13, CA-7, cybersecurity events 6.4.1.5 SA-2i CM-10, CM- 11 DE.CM-4: Malicious code is 3.5.3 5.4.2.1, SA-2a SA-2b 6.2, 6.2.17, G4 5 DSS05.01 4.3.4.3.8 SR 3.2 A.12.2.1 SI-3 detected 8.4.1, SA-2e CPM- Appendix E 12.4.2.2 4a SA-2i

A-12

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 DE.CM-5: Unauthorized mobile 3.5.3 SA-2a SA-2b ref to SP G4 SR 2.4 A.12.5.1 SC-18, SI-4. code is detected SA-2e 800-28 SC-44 SA-2h SA-2i DE.CM-6: External service 3.5.3 4.4.2.3, EDM-2a SA- 5, 5.2 G4 APO07.06 A.14.2.7, CA-7, PS-7, provider activity is monitored to 4.4.3.3, 2a SA-2b A.15.2.1 SA-4, SA-9, detect potential cybersecurity 5.4.2.1, SA-2e SI-4 events 5.4.2.4, EDM-2j 6.4.1.3, EDM-2n 6.4.1.4 DE.CM-7: Monitoring for 3.5.3 2.4.4.1, SA-2a SA-2b 6.2.11 G4 AU-12, CA-7, unauthorized personnel, 5.4.2, SA-2e SA-2f CM-3, CM-8, connections, devices, and 6.4.1.3, TVM-1d PE-3, PE-6, software is performed 6.4.1.4, SA-2g SA-2i PE-20, SI-4 6.4.1.5, 9.4.2.6 DE.CM-8: Vulnerability scans are 3.5.3 5.4.2 TVM-2e G-51 RA-5 G4 BAI03.10 4.2.3.1, A.12.6.1 RA-5 performed TVM-2i TVM- 4.2.3.7 2j TVM-2k RM-1c Detection Processes DE.DP-1: Roles and 3.5.3 P3 2.4.2.1, WM-1a 6.2.3 , G4 5 DSS05.01 4.4.3.1 A.6.1.1 CA-2, CA-7, responsibilities for detection are 2.4.3, WM-1d 6.2.6.2 PM-14 well defined to ensure 4.4.1.1, WM-1f accountability 4.4.1.4, 4.4.2 DE.DP-2: Detection activities 3.5.3 P5 1.4.3.1, IR-1d 6.2.3 G4 4.4.3.2 A.18.1.4 CA-2, CA-7, comply with all applicable 5.4.1, IR-5a TVM- PM-14, SI-4 requirements 12.4.1.2, 1d 12.4.1.3 IR-1g IR-5f RM-1c RM-2j DE.DP-3: Detection processes are 3.5.3 P2, P3, P5 2.4.4.3 IR-3e G4 APO13.02 4.4.3.2 SR 3.3 A.14.2.8 CA-2, CA-7, tested IR-3j PE-3, PM-14, SI-3, SI-4

A-13

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 DE.DP-4: Event detection 3.5.3 2.4.4.4, IR-1b 2.4, 3.1, G4 APO12.06 4.3.4.5.9 SR 6.1 A.16.1.2 AU-6, CA-2, information is communicated to 2.4.4.5, IR-3c ISC-1a 3.3.6 CA-7, RA-5, appropriate parties 11.4.2.10, ISC-1c ISC-1d SI-4 12.4.2.3 IR-3n ISC-1h ISC-1j

DE.DP-5: Detection processes are 3.5.3 1.4.3.3, IR-3h IR-3k G4 APO11.06, 4.4.3.4 A.16.1.6 CA-2, CA-7, continuously improved 11.4.1, DSS04.05 PL-2, RA-5, 11.4.2.3, SI-4, PM-14 12.4.1.4, 12.4.2.2 Respond Response Planning RS.RP-1: Response plan is 3.5.4 2.4.4, IR-3d 5.17, 6.2.8 G1 18 BAI01.10 4.3.4.5.1 A.16.1.5 CP-2, CP-10, executed during or after an event 2.4.4.1, IR-4, IR-8 2.4.4.3 Communications RS.CO-1: Personnel know their 3.5.4 P3 2.4.3.1 IR-3a 6.2.11 G2 4.3.4.5.2, A.6.1.1, CP-2, CP-3, roles and order of operations IR-5b 4.3.4.5.3, A.16.1.1 IR-3, IR-8 when a response is needed 4.3.4.5.4 RS.CO-2: Events are reported 3.5.4 P2 2.4.4.5 IR-1a IR-1b 6.2, 6.2.4, ref G2 4.3.4.5.5 A.6.1.3, AU-6, IR-6, consistent with established SP 800-61 A.16.1.2 IR-8 criteria RS.CO-3: Information is shared 3.5.4 2.4.4.3 ISC-1a ISC-1b 6.2, 6.2.4, ref G2 4.3.4.5.2 A.16.1.2 CA-2, CA-7, consistent with response plans ISC-1c SP 800-61 CP-2, IR-4, IR-3d ISC-1c IR-8, PE-6, ISC-1d RA-5, SI-4 IR-3i IR-3l RS.CO-4: Coordination with 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, stakeholders occurs consistent IR-8 with response plans RS.CO-5: Voluntary information 3.5.4 P3 2.4.3.2 ISC-1a Appendix C G2 PM-15, SI-5 sharing occurs with external ISC-1c ISC-1d stakeholders to achieve broader ISC-1e ISC-1f cybersecurity situational ISC-1h ISC-1i awareness A-14

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 ISC-1j ISC-1k ISC-1l

Analysis RS.AN-1: Notifications from 3.5.4 P5 2.4.4.4 IR-1e 6.2.3, 6.2.8 G4 DSS02.07 4.3.4.5.6, SR 6.1 A.12.4.1, AU-6, CA-7, detection systems are IR-1f 4.3.4.5.7, A.12.4.3, IR-4, IR-5, PE- investigated 4.3.4.5.8 A.16.1.5 6, SI-4 RS.AN-2: The impact of the 2.1.6. 3.5.4 2.4.4.2 IR-2d TVM- 3.3.2, 3.3.3, G4 4.3.4.5.6, A.16.1.6 CP-2, IR-4 incident is understood 1d 3.3.4, 3.3.5, 4.3.4.5.7, IR-2g RM-2j 3.3.6 4.3.4.5.8 RS.AN-3: Forensics are 3.5.4 4.4.3.3 IR-3d G4 SR 2.8, SR A.16.1.7 AU-7, IR-4 performed IR-3h IR-3i 2.9, SR 2.10, SR 2.11, SR 2.12, SR 3.9, SR 6.1 RS.AN-4: Incidents are 3.5.4 5.4.2.4 IR-2a G4 4.3.4.5.6 A.16.1.4 CP-2, IR-4, categorized consistent with IR-1d IR-1e IR-5, IR-8 response plans 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 A.16.1.5 IR-4 5.2, SR 5.4 RS.MI-2: Incidents are mitigated 3.5.4 2.4.4.4 IR-3b 5.1 4.3.4.5.6, A.12.2.1, IR-4 4.3.4.5.10 A.16.1.5 RS.MI-3: Newly identified 3.5.4 P3 11.4.2.11 TVM-2c 6.2.17.3 A.12.6.1 CA-7, RA-3, vulnerabilities are mitigated or TVM-2f TVM- RA-5 documented as accepted risks 2g RM-2j TVM- 2m TVM-2n Improvements RS.IM-1: Response plans 3.5.4 2.4.4.5 IR-3h G3 BAI01.13 4.3.4.5.10, A.16.1.6 CP-2, IR-4, incorporate lessons learned 4.4.3.4 IR-8 RS.IM-2: Response strategies are 3.5.4 11.4.2 IR-3h IR-3k G3 CP-2, IR-4, updated IR-8 Recover

A-15

Maritime Cybersecurity Project

NIST ISA 62443-2- ISA 62443-3- ISO/IEC NIST SP Subcategory IMO BIMCO ABS C2M2 DHS TSS CCS CSC COBIT 5 800-82 1 3 27001 800-53 Recovery Planning RC.RP-1: Recovery plan is 3.5.5 2.4.4, IR-3b 5.17 G1 8 DSS02.05, A.16.1.5 CP-10, IR-4, executed during or after an event 2.4.4.1, IR-3d DSS03.04 IR-8 2.4.4.3 IR-3o IR-4k Improvements RC.IM-1: Recovery plans 3.5.5 2.4.4.5 IR-3h IR-4i 6.2.12 G3 BAI05.07 ISA 62443-2- CP-2, IR-4, incorporate lessons learned IR-3k 1 4.4.3.4 IR-8 RC.IM-2: Recovery strategies are 3.5.5 2.4.4.5 IR-3h IR-3k 6.2.12 G3 BAI07.08 CP-2, IR-4, updated IR-8 Communications RC.CO-1: Public relations are 3.5.5 2.4.3.2 RM-1c 6.2.6.1 G2 EDM03.02 managed RC.CO-2: Reputation after an 3.5.5 2.4.3.2 IR-3d Appendix C G2 MEA03.02 event is repaired RC.CO-3: Recovery activities are 3.5.5 P3 2.4.2.3 IR-3d 3.1, 6.2.19 G2 CP-2, IR-4 communicated to internal stakeholders and executive and management teams

A-16

Maritime Cybersecurity Project

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 Search Item/Page Location Summary Term NIST 800-53 1/5 Section 1.4 Acquisition is included with deployment and operation as a Acquisition fundamental consideration for the security system implementer. 2/6 Table 1 Acquisition is included in the SA “Family” of the Management Acquisition “Class” of security controls 3/18 Appendix A NIST 800-23 is presented as an acquisition reference (Guideline to Acquisition Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products, August 2000). 4/35 Appendix D Provides a “catalog” of security controls that are recommended Acquisition 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. 5/85 Appendix F Explicitly includes the topic of personnel security requirements in Acquisition acquisition-related documents, and recommends related reading in NIST Special Publication 800-35, which provides guidance on information technology security services. 6/89 Appendix F IMPORTANT – Defines the requirement for security program Acquisition acquisition policy and procedures that is consistent with applicable federal laws, directives, policies, regulations, standards, and guidance. Recommends related reading in NIST 800-12. 7/90 Appendix F IMPORTANT – Defines the requirement for including security Acquisition 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. 8/114 Appendix G IMPORTANT – Maps the SA requirements for acquisition to other Acquisition 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. 11/31 Appendix D Provides a “catalog” of security controls that are recommended Vendor for three levels of “control baselines”: Low-impact, Moderate- impact, and High-impact information systems. 12/37 Appendix E Makes note of the appropriateness of using the catalog for Vendor communicating security requirements to suppliers (and implementers) of the systems that are impact-assessed. 13/70 Appendix F Recommends adherence to vendor specifications for periodic Vendor maintenance, and removal of protected information prior to onsite or offsite all maintenance or repairs of affected systems.

B-1

Maritime Cybersecurity Project

Search Item/Page Location Summary Term 14/100 Appendix F Recommends the prompt implementation of vendor-provided, Vendor security-relevant software evolution/repair actions. 15/101 Appendix F Recommends the use of virus protection software products from Vendor different (or multiple) vendors for different protection layers or equipment types as a “separation of duties” protocol for implementation of virus protection software. 16/103 Appendix F Recommends the use of virus protection software products from Vendor different (or multiple) vendors for different protection layers or equipment types as a “separation of duties” protocol for spam/spyware protection software. NIST 800-160 1/5 Section 1.2 Target audience of the special publication includes Individuals Acquisition with acquisition, budgeting, and project management responsibilities. It also targets providers (i.e., suppliers and vendors) of technology products, systems, or services. 2/8 Chapter 2 – The introduction to the chapter discusses principles and concepts Acquisition The in security engineering and states that While systems engineering Fundamentals 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. 3/20 Section 2.4 The Systems Security Engineering Framework is independent of Acquisition 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. 4/21 Footnote 25 The footnote states that life cycle security concepts include those Acquisition 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. 5/26 Chapter 3 – The table sourced from ISO/IEC/IEEE 15288, 2015, presents a Acquisition System Life System Life Cycle Processes model that classifies Acquisition and Cycle Process Supply as Agreement Processes performed early in a system’s life Figure 4 cycle. 6/27 Chapter 3 – The document points out that the processes can be applied Acquisition System Life concurrently, iteratively, or recursively at any level in the Cycle Process 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. 7/29 Table 2 Acquisition is assigned a discrete process designation, “AQ”, in Acquisition Table 2. 8/31 Section 3.1 IMPORTANT: 3.1.1 Acquisition Process – “The purpose of the Acquisition Agreement Acquisition process is to obtain a product or service in accordance Process with the acquirer's requirements.” This subsection discusses requirements for acquiring systems security engineering products and services (ISO/IEC/IEEE 15288-2015).

B-2

Maritime Cybersecurity Project

Search Item/Page Location Summary Term 9/35 Section 3.1 IMPORTANT: 3.1.2 Supply Process – “The purpose of the Supply Acquisition Agreement process is to provide an acquirer with a product or service that Process meets agreed requirements.” This subsection discusses requirements for satisfying a customer purchasing systems security engineering products and services (ISO/IEC/IEEE 15288- 2015). 10/58 Section 3.3.1 PL-2.6 – The document discusses including the acquisition of Acquisition security products and services as part of the overall systems security engineering program/project plan. 11/62 Section 3.3.2 PA-3.3 – The document discusses the potential impact on security Acquisition resulting from requested contractual changes. 12/86 Section 3.4.1 BA-3.1 – The document discusses defining security aspects of Acquisition preliminary operational concepts in all of a system’s life cycle stages, including acquisition. 13/89 Section 3.4.2 SN-1.2 – The document discusses inclusion of all stakeholders Acquisition (including acquisition) during requirements development and analysis stages of a systems security engineering project. 14/116 Section 3.4.7 IP-2.1 – The document discusses the need to realize or adapt Acquisition purchased system elements in accordance with the security aspects of the implementation strategy, defined implementation procedures, and security-driven constraints. 15/145 Section 3.4.13 MA-1.1 – The document discusses the need to address security Acquisition aspects pertaining to acquisition of products and services needed to maintain a secured system or a security engineering system. 16/148 Section 3.4.13 MA-3.1 – The document discusses the need to ensure that Acquisition security protection capability, performance, effectiveness, and trustworthiness are met as contractually agreed by suppliers for the full life cycle of the project. 17/165 Appendix G The document Glossary defines “Acquisitions” as the process of Acquisition obtaining a system, product, or service. Ref: [ISO/IEC/IEEE 15288] 18/170 Appendix G The document glossary defines “life cycle security concepts” as a Acquisition 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. 19/182 Table D-1 IMPORTANT: The table points to 33 acquisition processes to be Acquisition Agreement included in a security project plan. Processes 20/187 Table D-3 PL-2.6 – Plan the security aspects of acquisition of materials and Acquisition Technical enabling systems and services supplied from outside the project. Management Process 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 Acquisition 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

B-3

Maritime Cybersecurity Project

Search Item/Page Location Summary Term • Agreements, arrangements, and contracts for services provided to or received from external organizations. 23/37 Section 3.1.2 SP-5 – The document discusses supplier delivery support for the Supplier Supply Process 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. 29/68 Section 3.3.4 RM-3.2 – Estimate the likelihood of occurrence and consequences Supplier Risk of each identified security risk based on available expertise. This Management expertise includes knowledge of assumptions, hazards, or actual Process threat information (e.g., historical data on attacks, disaster events, distribution, supplier, and supply chain issues; information on specific adversary capabilities, intentions, and targeting). 30/70 Section 3.3.5 CM-1.1 – Define the security aspects of a configuration Supplier Configuration management strategy. This includes the secure coordination of Management configuration management activities across the set of acquirer, Process supplier, subcontractor, logistics, supply chain, and other organizations that have impact on achieving configuration management objectives. 31/71 Section 3.3.5 CM-2.5 – Obtain acquirer and supplier agreement for security Supplier aspects to establish a security baseline for the product or service. 32/80 Section 3.3.8 QA-1.1 – Define the security aspects of the quality assurance Supplier Quality strategy, including project security quality assurance procedures; Assurance security roles, responsibilities, accountabilities, and authorities; Process 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. 33/81 Section 3.3.8 QA-3.3 – Evaluate supplier processes (e.g., distribution, logistics, Supplier and supply chain) for conformance to process security requirements and evaluation, including supplier processes, constraints, and quality criteria derived from agreements. 34/121 Section 3.4.7 IN-2.1 – Obtain implemented system elements in accordance Supplier Integration with security criteria and Process 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,

B-4

Maritime Cybersecurity Project

Search Item/Page Location Summary Term access to/control over, use of, and modification to system elements as they are delivered to the integration location. 35/160 Appendix A Standards and Guidelines: ISO/IEC 27036-1:2014, Information Supplier References technology — Security techniques — Information security for supplier relationships — Part 1: Overview and concepts, April 2014. 36/160 Appendix A Standards and Guidelines: ISO/IEC 27036-2:2014, Information Supplier References technology — Security techniques — Information security for supplier relationships — Part 2: Requirements, August 2014. 37/160 Appendix A Standards and Guidelines: ISO/IEC 27036-3:2013, Information Supplier References technology — Security techniques — Information security for supplier relationships — Part 3: Guidelines for information and communication technology supply chain security, November 2013. 38/165 Appendix B “acquirer” – Stakeholder that acquires or procures a product or Supplier Glossary service from a supplier. (ISO/IEC/IEEE 15288) 39/175 Appendix B Supplier – Organization or an individual that enters into an Supplier Glossary agreement with the acquirer for the supply of a product or service. (ISO/IEC/IEEE 15288) 40/188 Appendix D PA-3.3 – Initiate change actions when there is a contractual Supplier change to cost, time, or quality due to the security impact of an acquirer or supplier request. 41/189 Appendix D CM-2.5 – Obtain acquirer and supplier agreement for security Supplier aspects to establish a baseline. 42/191 Appendix D QA-3.3 – Evaluate supplier processes for conformance to process Supplier security requirements. ISO 27001 1/18 Table A.1/ Objective: To ensure that information security is an integral part Acquisition A.14.1.1 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. 2/18 Table A.1/ Same Objective as A.14.1.1. Information involved in application Acquisition A.14.1.2 services passing over public networks shall be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. 3/18 Table A.1/ Same Objective as A.14.1.1. Information involved in application Acquisition A.14.1.3 service transactions shall be protected to prevent incomplete transmission, misrouting, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay. 4/19 Table A.1/ Objective: To ensure protection of the organization’s assets that is Supplier A.15.1.1 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. 5/19 Table A.1/ Same Objective as A.15.1.1. All relevant information security Supplier A.15.1.2 requirements shall be established and agreed with each supplier

B-5

Maritime Cybersecurity Project

Search Item/Page Location Summary Term that may access, process, store, communicate, or provide IT infrastructure components for, the organization’s information. 6/19 Table A.1/ Same Objective as A.15.1.1. Agreements with suppliers shall Supplier A.15.1.3 include requirements to address the information security risks associated with information and communications technology services and product supply chain. 7/19 Table A.1/ Objective: To maintain an agreed level of information security and Supplier A.15.2.1 service delivery in line with supplier agreements. Organizations shall regularly monitor, review and audit supplier service delivery. 8/19 Table A.1/ Same Objective as A.15.2.1. Changes to the provision of services Supplier A.15.2.2 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. NIST MBLT Profile 1/34 Table 6.2 RC.CO: Security incident related restoration activities are Vendor coordinated with internal and external parties, such as coordinating centers, Internet Service Providers, owners of attacking systems, victims, other CSIRTs, and vendors. 2/25 Table 6.2 ID.AM-6: Cybersecurity roles and responsibilities for the entire Supplier workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established. 3/28 Table 6.2 PR.AT: The organization’s third-party stakeholders (e.g., Supplier 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. 4/53 Appendix A PR.AT-3 (Awareness and Training): Third-party stakeholders (e.g., Supplier Detailed suppliers, customers, and partners) understand roles & Subcategory responsibilities. Additional cybersecurity NIST Framework Specifications resources are cited, including C2M2 practices. 5/92 Appendix A ID.AM-6 (Asset Management): Cybersecurity roles and Supplier 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. 6/94 Appendix A PR.AT-3 (Awareness and Training: Third-party stakeholders (e.g., Supplier suppliers, customers, and partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices. 7/103 Appendix A PR.AT-3 (Awareness and Training: Third-party stakeholders (e.g., Supplier suppliers, customers, and partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices. 8/114 Appendix A PR.AT-3 (Awareness and Training: Third-party stakeholders (e.g., Supplier suppliers, customers, and partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, including C2M2 practices.

B-6

Maritime Cybersecurity Project

Search Item/Page Location Summary Term 9/138 Appendix C ID.AM-6: Cybersecurity roles and responsibilities for the entire Supplier Industry workforce and third-party stakeholders (e.g., suppliers, Cybersecurity customers, partners) are established. Additional cybersecurity Processes & NIST Framework resources are cited, as are COBIT 5, and ISA Profile 62443 and ISO/IEC 27001. Mappings 10/141 Appendix C PR.AT-3: Third-party stakeholders (e.g., suppliers, customers, Supplier partners) understand roles & responsibilities. Additional cybersecurity NIST Framework resources are cited, as are COBIT 5, and ISA 62443 and ISO/IEC 27001.

B-7

Maritime Cybersecurity Project

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 Cyber elements could be specifically addressed in: with security duties  personnel knowledge of security threats (a) and operation of security equipment and systems (h) §104.225 Security training for all other Cyber elements could be specifically addressed in training vessel personnel  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-1

Maritime Cybersecurity Project

Requirements Cyber Comments

§104.255 Declaration of Security (DoS) §104.260 Security systems and Working order of cybersecurity systems should be equipment maintenance  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 Designate sensitive systems (a) and restrict access to restricted areas ✓ them (b) and increase security with MARSEC level (d) §104.275 Security measures for handling Address cyber threats to prevent unapproved cargo from cargo  being loaded (a) §104.280 Security measures for delivery of vessel stores and bunkers §104.285 Security measures for Monitor cybersecurity measures monitoring ✓ §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 VSP should document cyber scenarios, if applicable Plan (VSP) ✓ §104.410 Submission and approval §104.415 Amendment and audit

33 CFR Subchapter H, Part 105 – Maritime Security: Facilities Subpart A. General Cyber-specific requirements are not applicable to this section. Subpart B. Facility Security Requirements §105.200 Owner or operator Cyber elements could be specifically addressed in:  Facility Security Assessment (FSA) (b3) & reporting of incidents to the National Response Center (NRC) (b12)

C-2

Maritime Cybersecurity Project

Requirements Cyber Comments §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 Cyber elements could be specifically addressed in: duties  personnel knowledge of security threats (a) and operation of security equipment and systems (h) §105.215 Security training for all other Cyber elements could be specifically addressed in training facility personnel  of personnel in relevant provisions of FSP (a) and techniques used to circumvent security measures (e) §105.220 Drill and exercise requirements  Cyber scenarios could be incorporated into drills & exercises §105.225 Facility recordkeeping requirements §105.230 MARSEC Level coordination and implementation §105.235 Communications  Communication systems must enable notification to authorities in case of cyber-attack (c) §105.230 Procedures for interfacing with

vessels

§105.245 DoS §105.250 Security systems and Working order of cybersecurity systems should be equipment maintenance  verified as well (a) and FSP should address cybersecurity system failures (c) §105.255 Security measures for access

control §105.257 Security measures for newly hired employees §105.260 Security measures for Designate sensitive systems (a) and restrict access to restricted areas ✓ them (b) and increase security with MARSEC level (d) §105.265 Security measures for handling Address cyber threats to prevent unapproved cargo from cargo  being loaded (a) §105.270 Security measures for delivery of vessel stores and bunkers §105.275 Security measures for Monitor cybersecurity measures monitoring ✓ §105.280 Security incident procedures Respond to cyber scenarios (a) and report cyber incidents  (c) §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-3

Maritime Cybersecurity Project

Requirements Cyber Comments §105.300 General Ensure knowledge of cyber threats and techniques to ✓ circumvent cybersecurity measures and/or cause a cybersecurity incident (d) §105.305 Facility Security Assessment FSA should address cyber threats, vulnerabilities, security (FSA) requirements ✓ measures, and impacts and recommend improvements where necessary §105.310 Submission requirements Subpart D. FSP §105.400 General §105.405 Format of the FSP ✓ FSP should document cyber scenarios, if applicable §105.410 Submission and approval §105.415 Amendment and audit

33 CFR Subchapter H, Part 106 – Maritime Security: OCS Facilities Subpart A. General Cyber-specific requirements are not applicable to this section. Subpart B. OCS Facility Security Requirements §106.200 Owner or operator 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 Cyber elements could be specifically addressed in: personnel with security duties  personnel knowledge of security threats (a) and operation of security equipment and systems (h) §106.220 Security training for all other Cyber elements could be specifically addressed in training OCS facility personnel  of personnel in relevant provisions of FSP (a) and techniques used to circumvent security measures (e) §106.225 Drill and exercise requirements  Cyber scenarios could be incorporated into drills & exercises §106.230 OCS Facility recordkeeping requirements §106.235 MARSEC Level coordination and implementation §106.240 Communications  Communication systems must enable notification to authorities in case of cyber-attack (c) §106.250 DoS §106.255 Security systems and Working order of cybersecurity systems should be equipment maintenance  verified as well (a) and FSP should address cybersecurity system failures (c) §106.260 Security measures for access

control §106.262 Security measures for newly hired employees

C-4

Maritime Cybersecurity Project

Requirements Cyber Comments §106.265 Security measures for Designate sensitive systems (a) and restrict access to restricted areas ✓ them (b) and increase security with MARSEC level (d) §106.270 Security measures for delivery Address cyber threats to prevent unapproved supplies of stores and industrial  from being delivered (a) supplies §106.275 Security measures for Monitor cybersecurity measures monitoring ✓ §106.280 Security incident procedures Respond to cyber scenarios (a) and report cyber incidents  (c) Subpart C. OCS FSA §106.300 General Ensure knowledge of cyber threats and techniques to ✓ circumvent cybersecurity measures and/or cause a cybersecurity incident (d) §106.305 FSA requirements FSA should address cyber threats, vulnerabilities, security ✓ measures, and impacts and recommend improvements where necessary §106.310 Submission requirements Subpart D. OCS FSP §106.400 General §106.405 Format of the FSP ✓ FSP should document cyber scenarios, if applicable §106.410 Submission and approval §106.415 Amendment and audit

6 CFR 27 - Chemical Facility Anti-Terrorism Standards 6 CFR 27 - Chemical Facility Anti-Terrorism Standards Subpart A—General Cyber-specific requirements are not applicable to this section. 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 Cyber is specifically addressed in this section: standards ✓ (a8) Cyber. Deter cyber sabotage, including by preventing unauthorized onsite or remote access to critical process

C-5

Maritime Cybersecurity Project

Requirements Cyber Comments 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 Cyber-specific requirements are not applicable to this section. Subpart D—Other Cyber-specific requirements are not applicable to this section.

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 Cyber elements could be specifically addressed in Governments  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 Cyber scenarios could be incorporated into drills & Ship Security  exercises 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 FSA should address cyber threats, vulnerabilities, security ✓ measures, and impacts and recommend improvements where necessary

C-6

Maritime Cybersecurity Project

Requirements Cyber Comments 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 Cyber scenarios could be incorporated into drills & Port Facility Security  exercises 19 Verification and Certification

for Ships Appendix International Ship Security

1 Certificate (ISSC) Appendix Interim ISSC

2 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 Cyber elements could be specifically addressed in Governments  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 Cyber scenarios could be incorporated into drills & Ship Security  exercises 14 Port Facility Security References sections 15, 16 and 18 15 FSA FSA should address cyber threats, vulnerabilities, security ✓ measures, and impacts and recommend improvements where necessary 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-7

Maritime Cybersecurity Project

Requirements Cyber Comments 18 Training, Drills and Exercises on Cyber scenarios could be incorporated into drills and Port Facility Security  exercises 19 Verification and Certification of

Ships Appendix Form of DoS between a ship

1 and port facility Appendix Form of a Statement of 2 Compliance of a Port Facility

C-8

Maritime Cybersecurity Project

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.

Table D1. Relevant Safety Management Systems Regulations and Standards Requirements Cyber Comments 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 Cyber-specific requirements are not applicable to this section. 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 Cyber elements could be specifically addressed in must a safety management personnel knowledge of safety management system and system have? 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? Cyber-specific requirements are not applicable to this section. Subpart D—Authorization of Recognized Organizations to Act on Behalf of the U.S.

D-1

Maritime Cybersecurity Project

Requirements Cyber Comments Cyber-specific requirements are not applicable to this section.

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 Cyber elements could be specifically addressed in the Protection Policy  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 Working order cybersecurity systems should be verified Equipment 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 Cyber-specific requirements are not applicable to this section.

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-2

Maritime Cybersecurity Project

Requirements Cyber Comments §250.1910 What safety and environmental information is required? §250.1911 What hazards analysis criteria Scope of hazard review could explicitly consider cyber must my SEMS program  vulnerabilities of safeguards that could lead to accidental meet? 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 Cyber elements could be specifically addressed in safety in my SEMS program?  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-3

Maritime Cybersecurity Project

Requirements Cyber Comments §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 Cyber-specific requirements are not applicable to this section. Subpart B—Hazard Assessment Cyber-specific requirements are not applicable to this section. 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 Cyber elements could be specifically addressed in safety  training of personnel to ensure they can recognize corruption of control systems. §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 Cyber elements could be specifically addressed in safety  training of personnel to ensure they can recognize corruption of control systems. §68.73 Mechanical integrity §68.75 Management of change §68.77 Pre-startup review §68.79 Compliance audits §68.81 Incident investigation

D-4

Maritime Cybersecurity Project

Requirements Cyber Comments §68.83 Employee participation §68.85 Hot work permit §68.87 Contractors Subpart E—Emergency Response Cyber-specific requirements are not applicable to this section. Subpart F—Regulated Substances for Accidental Release Prevention Cyber-specific requirements are not applicable to this section. Subpart G—Risk Management Plan Cyber-specific requirements are not applicable to this section. Subpart H—Other Requirements Cyber-specific requirements are not applicable to this section.

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 Cyber elements could be specifically addressed in safety  training of personnel to ensure they can recognize corruption of control systems. (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 Cyber-specific requirements are not applicable to this section. Subpart B—Siting Requirements Cyber-specific requirements are not applicable to this section. Subpart C—Design Cyber-specific requirements are not applicable to this section.

D-5

Maritime Cybersecurity Project

Requirements Cyber Comments Subpart D—Construction Cyber-specific requirements are not applicable to this section. Subpart E—Equipment Cyber-specific requirements are not applicable to this section. Subpart F—Operations Cyber-specific requirements are not applicable to this section. Subpart G—Maintenance Cyber-specific requirements are not applicable to this section. 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 Cyber-specific requirements are not applicable to this section. 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

D-6

Maritime Cybersecurity Project

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

Maritime Cybersecurity Project

Table E1. Point of Failure Detection Framework: General Cargo Vessel

E-1

Maritime Cybersecurity Project

Table E2. Point of Failure Detection Framework: Tank Vessel

E-2

Maritime Cybersecurity Project

Table E3. Point of Failure Detection Framework: Drill Ship or MODU

E-3

Maritime Cybersecurity Project

Table E4. Point of Failure Detection Framework: Tug and Barge

E-4

Maritime Cybersecurity Project

Table E5. Point of Failure Detection Framework: Cruise Ship

E-5

Maritime Cybersecurity Project

Table E6. Point of Failure Detection Framework: Ferry

E-6

Maritime Cybersecurity Project

Table E7. Point of Failure Detection Framework: CDC Facility

E-7

Maritime Cybersecurity Project

Table E8. Point of Failure Detection Framework: Petroleum Refinery

E-8

Maritime Cybersecurity Project

Table E9. Point of Failure Detection Framework: Marine Cargo Terminal

E-9

Maritime Cybersecurity Project

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 Both are available through ManTec. staff and security research staff? 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 Research staff skill requirements are “flexed” staff? based on client research and training requirements. d. Are the needed skills provided by formal Both education or field experience – in what mix? e. What is the most useful approach you have Not discussed in depth. ManTec apparently has found to attracting staff? access to a relatively deep pool of resources and skills. f. How does the range leverage “field” staff or Clients provide information concerning research user information to guide uses of or research by the activities from multiple sources. Commercial range? 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 Did not discuss in detail. It was clear that during structures? 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 Not discussed except for indications that the support structures? 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…” Not discussed except for anecdotal information facilities and support structures? about having flexed capabilities and resources for clients in the past. d. What are the “I wish I hadn’t bought that…” Not discussed. facilities and support structures?

F-1

Maritime Cybersecurity Project

Question Answer e. Is there a lifecycle migration path that your This was not discussed specifically, but recommend in hindsight? 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 The Range is open to all funding models in direct exist (e.g., subscription; “pay-for-play”; free access and indirect service of the service branches, in association with work-for-hire contacts; “*.gov” agencies, and supporting commercial internally funded and internal-use only). How do product and service providers – including the you control/provide access and recover costs? 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 Yes, through observation, funding tradeoffs, and characteristics or “drivers” cause one approach to empirical results à simulation. be more useful than the other?

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 Both. The outputs of the Range are need and anecdotally discovered? opportunity driven. d. Can your experimental and use-case targets be Yes. The Functions-Connections-Identities model transferred outside of the range (e.g., …security was discussed and was very interesting to the architectures?; …secured function architectures?; director. Cris also raised the idea of “mutating” …threat types/modes? …identities behind threats? network forms as being useful for honey-netting …calculable risk models [“equations”]? …design for and protecting in the future. The Range team “protectability?”)? 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 The line is drawn based on service branch proprietary information? requirements and agreed-to contract arrangements with commercial clients. f. How do you stay away from picking winners in The Range is very careful to NOT pick winners the commercial space (the competitive vs. pre- and has a staff member who strongly enforces competitive issue)? that directive. However, the Range is positioning

F-2

Maritime Cybersecurity Project

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 This is not clear to me, but I think they might recommendations for proprietary or commercial (Check with Cris). security solutions? b. How is range-generated IP classified, By in-place governmental guidelines carefully disseminated, and protected? 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 The Range tries to reduce costs at any testing licenses? …other? 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

F-3