Cybersecurity of Industrial Internet of Things (Iiot) Devices 25.040.40; 35.030

CAN/CIOSC 105:20XX NATIONAL STANDARD OF CANADA

Cybersecurity of Industrial Internet of Things (IIoT) devices 25.040.40; 35.030

WARNING This document is not an official CIOSC Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as a National Standard of Canada. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

- Page left intentionally blank -

1 Foreword ...... vi 1 Introduction ...... 2 1.1 Proliferation of devices ...... 2 1.2 Threats and events ...... 2 1.3 Focusing on the acquisition of new devices ...... 2 2 Scope ...... 3 2.1 Applicability...... 3 2.2 Intended users ...... 4 2.3 Exclusions ...... 5 2.4 Normative references: ...... 5 3 Technical Requirements and Lifecycle Management ...... 6 3.1 Core Cybersecurity IIoT Objectives ...... 6 3.2 Technical Requirements ...... 7 3.3 Evaluating compliance to requirements ...... 15 3.3.2. Vendor’s self-declaration claim and certifications ...... 18 3.4 Reporting on results ...... 19 ANNEX A: Reference IIoT Scope and Context ...... 19 ANNEX B: CORE IIOT CYBERSECURITY OBJECTIVES ...... 24 ANNEX C: Standards Mapping ...... 25 ANNEX D: Glossary of Terms ...... 26 ANNEX E: Bibliography ...... 28

FIGURE 1: GENERAL IIOT DEVICE DEPLOYMENT ...... 20 FIGURE 2: NETWORKS OF 'THINGS' HIERARCHY...... 21 FIGURE 3: IIOT VS. ICS VS. IOT ...... 23

TABLE 1: IIOT DEVICE CATEGORIZATION...... 4 TABLE 2: CORE CYBERSECURITY IIOT OBJECTIVES ...... 6 TABLE 3: : LIST OF TECHNICAL REQUIREMENTS ...... 8 TABLE 4: SECURE DEPLOYMENT AND MAINTENANCE GUIDELINES ...... 16 TABLE 5: ZERO-TRUST PRINCIPLES ...... 21 TABLE 6: DEVICES CATEGORIZATION ...... 22

- Page left intentionally blank -

© CIOSC 2021 – All rights reserved. Unauthorized reproduction is strictly prohibited. v CAN/CIOSC 105:2020 (D1) 1 Foreword CIO Strategy Council (CIOSC) is a not-for-profit corporation providing a national forum for public and private sector members to transform, shape and influence the Canadian information and technology ecosystem.

CIOSC standards are developed in accordance with the Requirements & Guidance – Accreditation of Standards Development Organizations, 2019-06-13, established by the Standards Council of Canada (SCC).

Attention is drawn to the possibility that some of the elements of this Standard may be the subject of patent rights. CIOSC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of this Standard are included in the Introduction.

For further information about CIOSC, please contact:

CIO Strategy Council 304-555 Legget Drive, Tower A Ottawa, ON K2K 2X3 ciostrategycouncil.com

A National Standard of Canada is a standard developed by a Standards Council of Canada (SCC) accredited Standards Development Organization, in compliance with requirements and guidance set out by SCC. More information on National Standards of Canada can be found at www.scc.ca.

SCC is a Crown corporation within the portfolio of Innovation, Science and Economic Development (ISED) Canada. With the goal of enhancing Canada's economic competitiveness and social well-being, SCC leads and facilitates the development and use of national and international standards. SCC also coordinates Canadian participation in standards development, and identifies strategies to advance Canadian standardization efforts.

Accreditation services are provided by SCC to various customers, including product certifiers, testing laboratories, and standards development organizations. A list of SCC programs and accredited bodies is publicly available at www.scc.ca

- Page left intentionally blank -

CETTE NORME NATIONALE DU CANADA EST DISPONIBLE EN VERSIONS FRANÇAISE ET ANGLAISE

- Page left intentionally blank -

Cybersecurity of Industrial Internet of Things (IIoT) devices

This is the First Edition of CAN/CIOSC 105:2021, Cybersecurity of Industrial Internet of Things Devices. CAN/CIOSC 105:2021 was prepared by the CIO Strategy Council Technical Committee 5 (TC 5) on cybersecurity, comprised of over XXXX thought leaders and experts in cybersecurity of devices and systems as well as a cross section of users of these devices. This Standard was approved by a Technical Committee formed balloting group, comprised of X producers, X government / regulator / policymakers, X users, and X general interests.

All units of measurement expressed in this Standard are in SI units using the International system (SI). This Standard is subject to technical committee review beginning no later than one year from the date of publication. The completion of the review may result in a new edition, revision, reaffirmation or withdrawal of the Standard.

The intended primary application of this Standard is stated in its scope. It is important to note that it remains the responsibility of the user of the Standard to judge its suitability for a particular application. This Standard is intended to be technology agnostic. This Standard is intended to be used for conformity assessment. ICS 25.040.40; 35.030

CAN/CIOSC 105:2020 (D1)

1 Introduction

1.1 Proliferation of devices Over the coming years, billions of Industrial IoT (IIoT) devices are slated to come online. IIoT devices refer to a broad array of smart devices that are geographically distributed. They serve a multiplicity of functions in a wide range of industrial, commercial, institutional and critical infrastructure settings and have a level of inherent connectivity and processing capability. Their manufacturing, configuration and use require a broad complex supply chain inclusive of hardware components, software stacks, and communication services providers.

1.2 Threats and events In the past, IoT and IIoT devices have generally not been designed with cybersecurity in mind. Every region of the globe has witnessed cybersecurity breaches through these devices, with impacts on products such as self-driving vehicles and medical devices, as well as systems and networks operating critical infrastructure such as military equipment, utilities, pipelines and telecommunication networks.

As real-world attacks and discovered vulnerabilities have demonstrated, there is a critical need for cybersecurity guidance for the IIoT devices in addition to the systems and networks to which they connect. There are currently no globally accepted consolidated standards or certifications applicable to IIoT technologies that organizations can reference to ensure device cybersecurity. Organizations face a labyrinth of global standards, government directives, regulations, and best practice guidance focused on connected technologies that can be applied to IoT, IIoT, Industrial Control System (ICS), and other devices.

Considering the broad application scope of these technologies and understanding global state of play of IIoT cybersecurity, this standard starts down the path to a single consolidated cybersecurity framework. This framework is designed to ensure that connected devices have the embedded capabilities (memory, processing power, network bandwidth, etc.) to enable safe, reliable, and secure operation. Critical infrastructure, smart grid, smart city systems and a wide variety of industrial, commercial and institutional settings will benefit from a singular, verifiable standard to ensure cybersecurity in these devices.

By codifying and standardizing cybersecurity requirements from a wide variety of sectors, it is expected that demand for cybersafe devices will grow. With a clear and consistent market signal from owners and operators of IIoT devices on essential cybersecurity requirements, manufacturers and vendors will be in a position to respond accordingly and manufacture a new generation of cybersafe devices.

1.3 Focusing on the acquisition of new devices This standard fills a void by providing guidance to organizations that are in the process of acquiring new IIoT devices or equipment embedding IIoT devices. It provides a set of well-defined requirements that

CAN/CIOSC 105:2020 (D1)

can be used to select cybersecure IIoT devices through purchasing or procurement activities. This will contribute to improve the overall performance of cybersecurity systems.

The normative requirements in this standard are aimed at organizations that plan to acquire new IIoT devices and equipment embedding IIoT devices.

Although the standard does not compel organizations to replace any installed equipment, it can be used by organizations to assess the vulnerabilities of installed IIoT devices by comparing device specifications with cybersecurity requirements outlined in this document.

The standard can also assist organizations in selecting third-parties using IIoT devices to deliver a service. Organizations can choose to do business with service providers that use cybersafe IIoT devices in order to improve their overall cybersecurity risk profile.

The guidance is presented in the form of technical requirements aimed to deliver a core set of security controls. The security controls are taken from source documents focusing on cybersecurity of devices and of systems issued by research agencies, regulatory agencies as well as standards development organizations. As such, this standard can be seen as a consolidated standard.

It should be noted that this standard does not introduce additional cybersecurity requirements to organizations. All requirements codified in this standard are taken from a range of source documents.

This standard provides high-level guidance to purchasing and procurement authorities. It provides a framework to determine whether an IIoT device considered for acquisition meet defined cybersecurity requirements. It also proposes a pathway for manufacturers and vendors to address compliance to the requirements, either through self-declarations or through third-party testing and/or certification when available.

2 Scope As a National Standards of Canada, this is a voluntary standard. It only applies to the organizations that decide to adopt the standard and communicate their intention to use it for purchasing and procurement purposes. Following adoption, the standard can be actioned through incorporation in relevant cybersecurity policies and procedures; reference in relevant purchasing and procurement processes and use in the selection of devices, equipment or services.

2.1 Applicability This standard applies to Industrial Internet of Things (IIoT) devices. It is meant to support and complement other standards, codes of practice, guidance and best practices focusing on the cybersecurity of systems and networks.

a. For the purposes of this standard, IIoT is assumed to be a subset of IoT devices.

CAN/CIOSC 105:2020 (D1)

b. IoT devices are characterized by: a) at least one transducer (either a sensor or an actuator) for interacting with the physical world; and b) at least one network interface (including but not limited to Ethernet, Wi-Fi, Bluetooth, Long-Term Evolution or LTE, Zigbee, and Ultra- Wideband or UWB) for interacting with the digital world (NIST 2020, v).

c. IIoT devices share these characteristics. They are connected to equipment used in a wide variety of industrial, commercial and institutional settings and provide data, actuation and control functionalities. General categorization of these devices can be found in TABLE 1.

TABLE 1: IIOT DEVICE CATEGORIZATION Type Definition Sensor Produces a measurement of some physical property and then sends this information as controlled variables to the controller (NIST SP800-82r2) Actuator Used to directly manipulate the controlled process based on commands from the controller (e.g. breakers, switches, valves, and motors) (NIST SP800-82r2) Controller Interprets the signals and generates corresponding manipulated variables, based on a control algorithm and target set points (NIST SP800-82r2) Edge Computer Device capable of processing data and applying advanced algorithms for signal conditioning, Machine Learning (ML), and Artificial Intelligence (AI) Edge Communication Device sued to communicate data over a range of (Field) Gateway communication media (Wireless, WAN, LAN, and cellular) to a central location.

2.2 Intended users a. The standard applies to organizations planning to acquire new IIoT devices or equipment embedding IIoT devices. As such, intended users are those who have a role to play in the acquisition process; ideally a team composed of accountability centres using IIoT devices or services in operations; accountability centres managing cybersecurity policies and procedures; and accountability centres responsible for procurement and purchasing.

b. Other potential users include: i. Manufacturers and vendors of IIoT devices ii. Manufacturers and vendors of equipment embedding IIoT devices iii. Manufacturers and vendors of IoT devices

c. Intended uses of the standard include: i. The acquisition of new cybersafe IIoT devices ii. The acquisition of equipment embedding new cybersafe IIoT devices © CIOSC 2021 – All rights reserved. Unauthorized reproduction is strictly prohibited. 4

CAN/CIOSC 105:2020 (D1)

d. Other potential uses include: i. Contracting with organizations using IIoT devices in delivering a service ii. Assessing the vulnerability of installed devices by benchmarking them against cybersecurity requirements featured in this standard iii. Using cybersecurity requirements in the standard to acquire IoT devices

2.3 Exclusions a. This standard does not apply to: i. Installed devices and equipment embedding IIoT devices ii. Cybersecurity systems and networks

2.4 Normative references: a. An organization adopting this standard shall commit to its application in all relevant purchasing and/procurement activities.

b. The standard shall be incorporated to the organization’s cybersecurity policy. The use of the standard may be enforced through that policy.

c. An organization adopting this standard should communicate its decision to regulators, supply chain participants, suppliers and customers in order to demonstrate its commitment to improving the cybersecurity of its operations, systems and networks.

d. The organization adopting this standard should design and use a rating system that reflects the particular cybersecurity profile and risks that apply to its operations. It should rank cybersecurity requirements accordingly in order to select appropriate devices. The rating system should address the cybersecurity objectives outlined in section 3.1 of this standard.

e. Purchasing authorities should incorporate this standard by reference in all relevant purchasing requests for proposals (RFPs) and procurement documentation for the purposes of acquiring cybersafe IIoT devices and equipment embedding IIoT devices.

f. Purchasing authorities should receive adequate training to understand the scope and reach of cybersecurity requirements outlined in section 3.2 of this standard. (NOTE: CIOSC funding includes a provision for training collateral to be developed once the standard is developed).

g. Purchasing authorities should incorporate specifications covering each requirement outlined in section 3.2 of this standard.

h. Purchasing authorities should evaluate compliance documentation submitted by vendors according to section 3.3 of this standard.

CAN/CIOSC 105:2020 (D1)

i. Organizations shall strike the right balance between cybersecurity requirements and the risks IIoT devices face. For example, mission-critical devices, even when deployed in a private network or behind a secure gateway, need built-in security features.

j. Organizations shall consider a “defence in depth” strategy for mission-critical IIoT applications.

k. Organizations shall report internally and to key stakeholders results in the procurement of cybersecure IIoT devices at regular intervals as outlined in section 3.4 of this standard.

3 Technical Requirements and Lifecycle Management

3.1 Core Cybersecurity IIoT Objectives a. Given the diversity of potential devices and feature sets across a range of devices, it is critical to define core cybersecurity objectives. The following objectives are derived from the «Seven Properties of Highly Secure Devices» by Microsoft Research NExT Operating Systems Technologies Group and from «Baseline Security Recommendations for IoT for Critical Infrastructure» by the European Union Agency for Cybersecurity (ENISA). Annex B provides additional information on the selected cybersecurity IIoT objectives. These should be used as guiding principles when defining specific technical requirements during the acquisition process This is provided to show the similarity among all of the IIoT guidance and that the tenets used here are grounded in industry accepted principles.

b. All the requirements are intended to adhere to the following tenets, derived from multiple standards and best practices and focussing on the core capabilities of the majority of IIoT devices as per Table 2

TABLE 2: CORE CYBERSECURITY IIOT OBJECTIVES Firmware Integrity and Authenticity Method to cryptographically ensure firmware, software, and configuration files are authorized from the device vendor Least privilege Each entity (e.g. user, service, or other resource) only has the permission necessary to perform a task Secure by Design Concept referring to the default state of minimal attack surface (points of interaction) where additional access needs to be explicitly enabled

CAN/CIOSC 105:2020 (D1)

Certificate based Authentication Cryptographically ensure the identity of an entity (device, user, etc.) Renewable security capability Ability to be updated (e.g. firmware) to address known security vulnerabilities and weaknesses

Strong authentication Strong and adequately complex methods to verify access Secure communication Provide confidentiality (secrecy) and integrity (validity) for communications Full lifecycle vulnerability reporting and response Active program to identify, address, communicate, and respond (e.g. updates, mitigation or remediation measures) to security vulnerabilities throughout the entire product life

Logging and Reporting Ability to report key access (logon/logoff) and anomalous conditions (e.g. malware or unauthorized access)

3.2 Technical Requirements

a. The technical requirements presented below are high-level requirements. They are not detailed specifications. Details such as specific interfaces, algorithms, protocols, and technology solutions are not addressed. They provide the impulse for the creation of more detailed specifications from each organization while selecting appropriate IIoT devices or equipment with embedded IIoT devices.

b. The requirements reflect technical security controls defined in the Department of Homeland Security (DHS) Catalog of Control Systems Security, various Federal Information processing Standards (FIPS), voluntary standards from international standards development bodies and industry best practices. Some of the controls have been refined to be as specific and actionable as possible. They define the requirements for the hardware and software that should be used to IIoT devices or equipment embedding an IIoT device. Requirements are linked to a series of cybersecurity controls that the device must exhibit.

c. Cybersecurity controls are described as follows: i. Control ID: Composed of the control’s category, a sequence number within that ii. Short Name: Short string that summarizes the intent of the control in a unit string iii. Definition: The text that defines the control itself iv. Reference(s): Standards on which a control is based

d. As per TABLE 3, three categories of cybersecurity controls apply to IIoT devices:

CAN/CIOSC 105:2020 (D1)

i. Detection - Identifying an attack or weakness. ii. Hardware – Designates specific hardware needs and considerations iii. Protection - Active measures used in normal circumstances that are designed to prevent an attack.

TABLE 3: : LIST OF TECHNICAL REQUIREMENTS

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References Firmware or - DHS 2.14.3 configuration file - IEEE 1686-2007 R5.3 & downloads to field 5.4 devices shall have - NERC CIP-005-3 R3 - NERC CIP-007-3 R6 cryptographically Firmware / - NEMA SG-AMI 1 3.2 signed message Smart Meter & 1.3 Detection.1 Software payloads. - J3061: NISTIR 7628 Authenticity SG.SC-12 - J3061: NIST SP 800-53 R4 SI-3, - DOT HS 812 333 - Section 6.7.5 - DO-356A O11.2, 5.6.2 The device shall have an internal log CR 3.4 Software and file that records at information integrity minimum for each CR 4.3 Use of event the user ID, cryptography the date/time of event, and the type EDR 3.2 Protection of event. Such from malicious code events should EDR 3.12 Provisioning include successful product supplier roots logons / logoffs, of trust unsuccessful logon HDR 3.12 Provisioning attempts, changes to device product supplier roots Audit Log configuration of trust Detection.2 - NIST SP 800.53 R4 AU-7 Management parameters, and HDR 3.13 Provisioning other relevant asset owner roots of security events. trust (This requirement is NDR 3.12 Provisioning also relevant for systems where a product supplier roots comprehensive audit of trust log management NDR 3.13 Provisioning must be asset owner roots of implemented.) trust Error messages CR 1.2 Software shall not reveal potentially harmful process and device (e.g., exploitable) identification and information. authentication © CIOSC 2021 – All rights reserved. Unauthorized reproduction is strictly prohibited. 8

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References CR 1.9 Strength of public key-based authentication CR 5.1 Network segmentation

Software/firmware shall be able to report identifying and configuration information on Self- Detection.3 request. This should - DHS 2.6.4 Identification include version number, installation date, patch level /firmware version where applicable. The device shall employ mechanisms to check manual user inputs for accuracy, completeness, - DHS 2.15.14 validity, and - NIST SP 800-53 R4 IA-7 authenticity. - IEEE 1686-2007 R5.1.5 Message Message recipients - NISTIR 7628 SG.SC-12 Detection.4 Validation and Use of Validated must validate Integrity Cryptography application / protocol - ISO/IEC 11889 fields for logical and - J3061: NIST SP 800-53 expected R4 IA-7 values/payloads including source, destination, time stamps, state indicators etc.

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References The device shall feature a hardware cryptographic root of trust and cryptographic module authentication for authenticating users and devices. The device shall have adequate resources to ensure all cryptographic - DHS 2.15.14 integrity - NIST SP 800-53 R4 IA-7 - IEEE 1686-2007 R5.1.5 Hardware mechanisms can be implemented, for - NISTIR 7628 SG.SC-12 IEC 62443-4-2 CR 1.05 Hardware.1 based identity Use of Validated example key RE(1) and security Cryptography generation, storage, - ISO/IEC 11889 processing, etc. - J3061: NIST SP 800-53 The authenticators R4 IA-7 on which the component rely shall be protected via hardware mechanisms, for example password protected memory, OTP memory, hardware data integrity checks, and device security boot mechanism. The device shall - DHS 2.15.14 disable - NIST SP 800-53 R4 IA-7 unused/unnecessary - IEEE 1686-2007 R5.1.5 Minimize interfaces and ports, - NISTIR 7628 SG.SC-12 IEC 62443-4-2 CR 1.05 Hardware.2 Hardware Use of Validated for example JTAG RE(1) Attack Surface Cryptography and other diagnostic - ISO/IEC 11889 interfaces at least by - J3061: NIST SP 800-53 R4 IA-7 default

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References The device shall provide protection at root of trust level by storing the sensitive data, keys and code in tamper- resistant, secure hardware. Tamper detection mechanisms shall be - DHS 2.15.14 used to detect an - NIST SP 800-53 R4 IA-7 - IEEE 1686-2007 R5.1.5 Secure storage active attempt to - NISTIR 7628 SG.SC-12 IEC 62443-4-2 CR 1.05 Hardware.3 and tamper compromise the Use of Validated RE(1) detection device’s integrity, or Cryptography - ISO/IEC 11889 the data associated - J3061: NIST SP 800-53 with the device. R4 IA-7 If there is a tampering attempt, the device should: a) reset itself to protect sensitive information, b) notify the user that it has been tampered with. The device shall - DHS 2.15.14 secure boot to - NIST SP 800-53 R4 IA-7 - IEEE 1686-2007 R5.1.5 ensure the Hardware boot - NISTIR 7628 SG.SC-12 IEC 62443-4-2 CR 1.05 Hardware.4 authenticity and Use of Validated integrity RE(1) integrity of the code Cryptography - ISO/IEC 11889 running upon every - J3061: NIST SP 800-53 boot. R4 IA-7 The device shall be accompanied with Documentation appropriate Protection.1 to securely - UL 2900-1 Sec.4-6 IEC 62443-4-1 documentation and deploy devices guidance to facilitate its deployment The device should EDR 3.10 - Support for support the ability updates to be updated to Renewable HDR 3.10 - Support for Protection.2 address security security updates vulnerabilities, NDR 3.10 - Support for weaknesses, and updates other defects.

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References The device shall - DHS 2.8.9 employ a - DHS 2.9.4 cryptographically - DHS 2.9.11 strong mechanism - NISTIR 7628 SG.SC-9 & 26 to ensure - IEC 62351 authenticity, integrity - NISTIR 7628 SG.SC-12 and confidentiality of - NIST SP 800-53 R4 SC-1 communication. - NIST SP 800-53 R4 SC-8 Cryptographically - NIST SP 800-53 R4 SI-8 Communication strong is defined in - DHS 2.8.20 Protection.3 Integrity & FIPS 180, FIPS 186 and FIPS 140-2. - NISTIR 7628 SG.SC-8 Confidentiality Communication Integrity - IEC 62351 - NEMA SG-AMI 1 Section 4, Upgrade Process Security Requirement, - NISTIR 7628 SG.SC-12 Use of Validated Cryptography - DOT HS 812 333 -Section 6.7.10 ETSI TS All remote user- - DHS 2.10.9 interactive sessions - NIST SP 800-53 R4 MP- to field deployed 5(4) devices shall be - NIST SP 800-53 R4 AC- encrypted using 17(2) Secure Remote FIPS 140-2 - DODI 8500.2: ECCT-1 Protection.4 Maintenance - DODI 8500.2: EBRU-1 compliant Sessions - DODI 8500.2: EBRP-1 mechanisms, - J3061: NIST SP 800-53 including all R4 AC-14 administrative and - J3061: NIST SP 800-53 maintenance R4 AC-17 activities. - FIPS 140-2 Users, process and service integrations such as connections to a database, and - DHS 2.8.19 - DOD-5200.28-STD all other active - NERC CIP-007-1 R5 elements in a device Account Management shall follow the - ISA-99.00.02 Part 2 principle of least Section 5.3, B.14, C3 NDR 1.6 Wireless Protection.5 Least Privilege privilege. Each - J3061: NIST SP800-53 process or service R4 AC-1, Access Management within a system will - DHS 2.8.19 be granted the most - DOT HS 812 333 - restrictive set of Section 6.7.3 - DO-356A 5.8.2 privileges (or lowest - ETSI TS clearance) needed for the performance of authorized tasks.

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References Devices and applications shall fail to a known state that meets the system requirements set by - DHS 2.8.2 the organization for - NIST SP 800-53 R4 SC- safety and security. 7(6)4 Startup & Fail Devices and - NISTIR 7628 SG.SC-22 Protection.6 in Known - J3061: NIST SP 800-53 applications shall Secure State R4 SC-24 start up in a known - J3061: NIST SP 800-53 state that is safe R4 SC-24 and/or secure in - DO-356A 5.9.4 accordance with system requirements set by the organization. All networking and communication capabilities not required for the operation or maintenance of the device shall be disabled. This includes VOIP, - DHS 2.6.7 instant messaging, - (NERC) CIP-007-1 R2, ftp, HTTP, file “Ports and Services,” sharing. - ANSI/ISA-99.00.01 Part Vendor defaults for 1Section 5 all wireless options - NIST 800-42 Disabling should be initially set - IEEE 1686-2007 R5.3.5 Unused "off". &5.5 Interfaces & - J3061: NIST SP 800-53 Protection.7 Any unused ports Insecure R4 CM-7 must be disabled. Communication - DHS 2.8.21 FTP, HTTP, Telnet Services - DOT HS 812 333 - shall be disabled Section 6.7.1 and secure versions - DOT HS 812 333 - of these protocols, Section 6.7.6 Secure FTP, Secure - DO-356A 5.7.3 Copy Protocol, - DO-356A 5.7.4 HTTP over TLS, and - ETSI TS Secure Shell, must be used instead. Modems should be disabled by default. Every modem port and LAN port should be disabled by default.

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References EDR 3.10 Support for Updates IEC-62443-4-1 DM-1: Receiving notifications of security-related issues IEC-62443-4-1 DM-2: Reviewing security- related issues IEC-62443-4-1 DM-3: Assessing security- related issues IEC-62443-4-1 DM-4: The device shall Addressing security- employ related issues cryptographic-based IEC-62443-4-1 DM-5: bi-directional Disclosing security- identification and Device related issues authentication (e.g. - DHS 2.15.12 Identification - NIST SP 800-53 R4 IA-3 IEC-62443-4-1 DM-6: Protection.8 TLS) for device to and - NISTIR 7628 SG.SC-20 device Periodic review of Authentication - IEC 62351 communication. security defect Paswordless management practice authentication IEC 62443-4-1 SUM-1 should be Security update considered. qualification IEC 62443-4-1 SUM-2 Security update documentation IEC 62443-4-1 SUM-3 Dependent operating system security documentation IEC 62443-4-1 SUM-4 Security update delivery IEC 62443-4-1 SUM-5 Timely delivery of patches All wireless - DHS 2.25.26 communications - J3061: NIST SP 800-53 shall use a FIPS R4 AC-18 Wireless 140-2 compliant - J3061: NIST SP 800-53 Protection.9 R4 AC-19 Security method of link-layer - DODI 8500.2: ECCT-1, encryption in ECWN-1 addition to any - DOT HS 812 333 -Section encryption already 6.7.11

CAN/CIOSC 105:2020 (D1)

Description IEC 62443-4-1 and Control ID Title References IEC 62443 4-2 References required by other controls.

Any third-party component/libraries used in the Secure Third- software/firmware - OWASP Top 10 (A9) Protection.10 Party IEC 62443-4-1 SG-4 should not have any - DO-356A O2.1 Components publicly known Critical/High vulnerabilities. Devices should have an established process/plan to patch/update any FIPS-140-2(Section- Vulnerability component in their - OWASP Top 10 (A9) 4.11) and IEC62443 Protection.11 Management system against - DO-356A O5.1 Plan which a vulnerability - ETSI TS (Section –13 to 15), is discovered. This SAE J3061 8.5.4 should cover the usable life of the product. Safety-critical data and communications (if any) in a device need to be protected additionally to prevent any safety FIPS-140-2(Section- incidents. 4.11) andIEC62443 The product shall Sensitive and (Section –13 to 15), ensure the - UL 2900-1 Sec.10 Protection.12 safety critical - NIST SP 800-88 R1 SAE J3061 8.5.3 confidentiality of all data protection - ETSI TS sensitive data and Hardware Level Personally Vulnerability Analysis , Identifiable J3101 6.8 Information (PII) generated, stored, used or communicated by the device.

3.3 Evaluating compliance to requirements When reviewing bids from vendors, purchasing authorities should evaluate compliance to requirements by assessing how vendors are managing supply chains used to design and manufacture devices and by reviewing the vendor’s self-declaration claim and certifications.

CAN/CIOSC 105:2020 (D1)

3.3.1 Supply chain and lifecycle management

a. The vendor should provide the following information regarding supply chains used to design and manufacture a device:

i. A description of its vulnerability management and response program including communication mechanisms.

ii. A description of the Secure Development Lifecycle (SDL) used to create the device.

The vendor should provide deployment and maintenance guidelines addressing the following items:

TABLE 4: SECURE DEPLOYMENT AND MAINTENANCE GUIDELINES

Secure supplier and asset selection Suppliers and assets adhere to Secure Development Lifecycle practices to help ensure cybersecurity risk reduction throughout the lifecycle

Asset and configuration management Keeping track of software and hardware assets in your environment is a pre-requisite for effectively managing cybersecurity. Eaton recommends that an accurate inventory of authorized hardware and software running on the system is maintained.

At a minimum, the following information should be included in the hardware inventory: manufacturer, type, serial number, f/w version number, product support contact/location, and function.

At a minimum software inventories should include the following information: publisher, name, version, version date, patches/updates/hotfixes applied.

Physical access controls (restrict physical access) Restrict and monitor physical access to a system.

Secure access controls Apply secure remote access controls and management that include the following:

• Role Based Access Control (RBAC) • Applying least privilege • Ensure default credentials are changed upon first login. Eaton recommends verifying all default credentials are changed during commissioning This

CAN/CIOSC 105:2020 (D1)

includes default usernames, passwords, and certificates. • No account or password sharing • Restrict administrative privileges - Threat actors are increasingly focused on gaining control of legitimate credentials, especially those associated with highly privileged accounts. Limit privileges to only those needed for a user’s duties • Perform periodic account maintenance (remove unused accounts). • Change passwords and other system access credentials no longer than every 90 days, or per the organizational policy • Enforce complex passwords and session time-outs • Secure centralized authentication (e.g. via RADIUS or LDAP) according to industry best practices and manufacturer guidelines Media and transient asset protection Awareness training and hygiene around the dangers of and how to adequately secure assets (e.g. USB and maintenance laptops) used for maintenance, troubleshooting, commissioning, and other “transient” (temporary) activities.

Secure Architecture and Network Access Several principles can be applied to maintain adequate separation of critical networks, traffic restrictions, monitoring, and secure remote access including maintaining isolation from direct connection the internet or les trusted networks. Physical, logical, and network access are assumed to be limited to authorized users and assets (user responsibility to implement).

Network Segmentation (functional isolation) Apply adequate segmentation and functional isolation to keep critical processes separated (e.g. do not run IT functions on a control system network)

Logging and Event Management Logging and review of key access and anomalous events and ensuring these logs are themselves secured and retained for a period of time.

CAN/CIOSC 105:2020 (D1)

Vulnerability Management Monthly (at least) monitoring for vulnerabilities on individual vendor sites, the Department of Homeland Security (DHS) Industrial Control System (ICS) Computer Emergency Readiness Team (CERT), and NIST National Vulnerability Database (NVD) for known vulnerabilities in products and mitigating or remediating the vulnerabilities as recommended though patches, updates, or compensating controls.

Backup and recovery Maintain adequate backups and configuration information to be able to respond and recover from an incident

Cybersecurity Awareness Training provided to personnel for general awareness of cybersecurity risks and about specific activities or job specific duties related to reducing cybersecurity risks.

Secure decommissioning and disposal It is a best practice to purge the data before disposing any device containing data. Proper decommissioning is described in NIST SP800-88. Eaton recommends that products containing embedded flash memory be destroyed to ensure any secure data is unrecoverable.

3.3.2. Vendor’s self-declaration claim and certifications

a. The vendor should provide documentation outlining how a device meets the technical requirements set in this standard and additional specifications set by procurement authorities. b. Assessment of conformity may be performed through a combination of a self- attestation/declaration and third-party certification. c. Evidence provided does not need to be at a detail that compromises the Intellectual Property (IP) of the vendor but rather a description of the validation cases and conformance. d. A self-declaration may cover the processor architecture, memory, clock speed, and techniques used to ensure adequate resources are present to establish hardware root of trust, secure key storage, and cryptographic offload capability. This doesn’t need to be exhaustive, but it should ensure that a minimum level of processing is present. e. A vendor obtaining third-party certification completed against the IEC 62443-4-1 standard shall be deemed by procurement authorities as acceptable evidence of compliance to the requirements set in this standard.

CAN/CIOSC 105:2020 (D1)

3.4 Reporting on results a. Organizations that have adopted the standard should establish a process to record purchasing/procurement decisions regarding new IIoT devices or equipment embedding IIoT devices to determine to what extent they meet cybersecurity requirements stipulated in this standard.

ANNEX A: Reference IIoT Scope and Context

The overall objective is to define cybersecurity for IIoT devices used in critical infrastructure applications. To achieve this in a way that allows for widespread adoption

To effectively define the scope of IIoT and adequate security guidance, some foundational items need to be established including the target applications, device context and characteristics, and key cybersecurity objectives.

To define the context for IIoT There are two (2) main areas that need addressed when defining the targeted scope of this effort. These are

i. Definition of Industrial Internet of Things (IIoT) as contrasted with normal Internet of Things (IoT) and Industrial Control System (ICS) components ii. IIoT devices as part of an overall IIoT ecosystem

IIoT systems and networks are distributed networks consisting of several components. These range from physical devices, communication devices, cloud-based components including virtual machines, services, algorithms, etc.

A high-level context is provided in FIGURE 1. While not an exhaustive diagram it does show the basic components and helps illustrate the scope of an IIoT device addressed by this document. These devices may have either wireless or wired (e.g. Ethernet) connectivity and are generally assumed to be sensors or actuators and the optional ability to do field level control.

CAN/CIOSC 105:2020 (D1)

Cloud Service Provider

Communication Provider (Cellular, Leased Line, ISP, etc.)

IIoT Device Microprocessor Vendor Communication Stack Vendor

FIGURE 1: GENERAL IIOT DEVICE DEPLOYMENT

An Industrial Control System (ICS) is an interconnection of components to achieve an industrial objective often with very specific real-time, availability, safety, and performance criteria. While there are several types of ICS’s [4], the distributed electrical grid is a specific class that deserves special attention given the role of these systems as critical infrastructure.

In the context of modern technology, an ICS can be considered a type of more general Networks of ‘Things’ (NoT). While more formal definitions exist [3], a NoT is a collection of devices (‘Things’) connected to a common network which could be the internet, a restricted private network, Wide Area Network (WAN), or Local Area Network (LAN). As shown in FIGURE 2, Not can be considered the Internet of Things (IoT), Industrial Internet of Things (IIoT), or an Industrial Control System (ICS).

CAN/CIOSC 105:2020 (D1)

Networks of Things (NoT)

Industrial Internet of Industrial Control Internet of Things Things Systems (IoT) (IIoT) (ICS)

FIGURE 2: NETWORKS OF 'THINGS' HIERARCHY There are similarities and differences in these NoT subcategories, but the main differentiation lies in the connectivity (IoT connected to the general internet, IIoT to the internet of restricted network, ICS typically to a LAN or WAN). The IIoT and ICS networks and devices typically serve a more critical function or at least tie to a critical system (e.g. the power grid).

ICS networks and devices have some features that differentiate them from traditional IT networks or even IoT applications. A good definition and treatment of ICS security is provided by the NIST SP800-82 Guide to Industrial Control System Security [4]. The main differentiating factors are the availability, performance, resource, and operations requirements. This leads to the primary differences related to the priority of security objectives. In ICS, the priority of the security objectives is 1) Availability, 2) Integrity, and 3) Confidentiality (AIC triad). For traditional IT systems the priority is considered 1) Confidentiality, 2) Integrity, and 3) Availability (i.e. CIA triad). This is due to the physical control of environments, nature of operations, and nature of the data. For more distributed applications – and especially when considering IIoT, these objectives may get blurred. For the purposes of IIoT devices in critical infrastructure applications, or any devices used in critical applications, the availability and performance criteria will still be considered a priority.

Traditional ICS security considers a defense in depth approach of layered defenses often instantiated in a tiered network structure (leveraging the typically static and determiNISTic nature of ICS traffic). For IIoT and distributed applications a different model of zero-trust should be assumed. Zero-Trust does not rely on layered defenses but rather more authentication and identity-based controls. For IIoT, zero trust considerations are often provided alongside defense in depth concepts to get the balance between the AIC vs. CIA models. An overview of core tenets of Zero Trust architecture are presented in the (albeit a draft) NIST SP800-207 and Microsoft (https://www.microsoft.com/en-us/security/business/zero-trust).

TABLE 5: ZERO-TRUST PRINCIPLES Explicit verification Authentication and authorization based on several data sources and methods. Least Privilege Minimal access or Just-In-Time (JIT) or Just-Enough-Access (JEA) to perform necessary functions (applicable to users and device services)

CAN/CIOSC 105:2020 (D1)

Breach Assumption Assume the overall system is compromised and minimize the impact by minimizing the ability to access data and move laterally through session controls and encryption.

The Zero-Trust model should be given significant consideration and weighting in any consolidated guidance around IIoT. The Zero-Trust model provides a more atomic approach to device level cybersecurity.

When looking at the device level, it can be difficult to discuss the differences between a general connected device and a device used for IIoT. For the purposes of this effort a Smart Embedded Device (SED) is used as a generic model representing IIoT devices used in utility. The SED’s have intelligence and connectivity and are assumed to be used in a range of applications. This abstraction provides a working model while not getting bogged down in terminology variations.

The building blocks of an IIoT ICS system or network are the individual devices. To normalize the terminology and provide a common context, a general Smart Embedded Device (SED) is defined. These devices will be considered any device supporting connectivity and performs a real-time function in an ICS network. This SED is a superset of the as a sensor, actuator, or controller as defined in the NIST SP800-82 standard for ICS Cybersecurity [4] and the sensor and aggregator primitives defined in the NIST SP800-183 [19] in the context of the Networks of ‘Things’ standard. In addition, the SED will have a communication channel and consider the eUtility (external processes sing responsible for configuration, processing, etc. [19]). The SED will be assumed to support any wired or wireless connectivity. The SED could be considered an Intelligent Electronic Device (IED) as defined in IEEEE 1686 [2] (a phrase commonly used to refer to substation devices).

IIoT devices can be broadly categorized according to the definitions for ICS devices defined by NIST in NIST SP800-82.

TABLE 6: DEVICES CATEGORIZATION Type Definition Sensor Produces a measurement of some physical property and then sends this information as controlled variables to the controller (NIST SP800-82r2) Actuator Used to directly manipulate the controlled process based on commands from the controller (e.g. breakers, switches, valves, and motors) (NIST SP800-82r2 Controller Interprets the signals and generates corresponding manipulated variables, based on a control algorithm and target set points (NIST SP800-82r2) Edge Computer Device capable of processing data and applying advanced algorithms for signal conditioning, Machine Learning (ML), and Artificial Intelligence (AI) Edge Communication Device sued to communicate data over a range of communication media (Field) Gateway (Wireless, WAN, LAN, and cellular) to a central location.

CAN/CIOSC 105:2020 (D1)

There are a broad range of IIoT devices that can have a bunch of potential features: Two examples are the interactive interface or the power scheme. Devices may have a monitor or user interface, operate “headless” (e.g. no monitor connection but some type of embedded web interface or shell), or no interactive interface at all. Some devices may require constant power (AC/DC), battery power, run constantly, or run periodically timed or based on some stimulus).

It is worth considering the typical differences between IIoT, ICS, and IoT devices. They may be subtle or ambiguous in some cases however it can help focus discussions on IIoT device specific considerations especially when looking at a global labyrinth of standards. As shown in FIGURE 8, the primary differences with IIoT devices are the connectivity and use (e.g. industrial vs. residential).

IIoT

Connectivity (Cellular, Wi-Fi, etc.) Critical Functions Over the Air Updates Industrial Environment (OTA) Local/Restricted Updates

IoT ICS

FIGURE 3: IIOT VS. ICS VS. IOT One additional consideration is the nature of the data on these devices. Each type of device (IIoT, ICS, or IoT) can be assumed to contain critical information. In ICS and IIoT many industries consider connectivity (e.g. IP address) and configuration (e.g. protection settings) critical information. Personally, Identifiable Information (PII) is a special categorization of data that contains personally sensitive information (e.g. age, race, gender, national identification number. PII is not typically encountered in ICS or IIoT devices but needs to be considered. The General Data Privacy Regulation (GDPR) is a European regulation that defines key principles around personal data collection and use and establishes a penalty framework. The handing of PII and the GDPR are items vendors need to consider and can serve as a reference point for data handling (in transit, in use, and at rest) in the context of IIoT cybersecurity.

There are multiple existing and proposed IIoT applications and use cases. They vary in application, deployment, communication medium, distribution, etc.

CAN/CIOSC 105:2020 (D1)

ANNEX B: CORE IIOT CYBERSECURITY OBJECTIVES

The core IIoT cybersecurity tenets in this document were derived from a number of sources and references. As a reference point, it is worth looking At two IIoT references that also define tenets. While there is not a direct mapping between these tenets, they do demonstrate similarities and that the core tenets defined in this standard address these key areas. These references are:

The Seven Properties of Highly Secure Devices Microsoft Research NExT Operating Systems Technologies Group1 :

1. Hardware Root of Trust 2. Defense in Depth 3. Small Trusted Computing Base 4. Dynamic Compartments 5. Password-less Authentication 6. Error Reporting 7. Renewable Security

Additionally, the European Union Agency For Network And Information Security (ENISA) Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures2 organizes its guidance around the following:

1. Hardware security 2. Trust and Integrity Management 3. Strong default security and privacy 4. Data protection and compliance 5. System safety and reliability 6. Secure Software / Firmware updates 7. Authentication 8. Authorisation 9. Access Control - Physical and Environmental security 10. Cryptography 11. Secure and trusted communications 12. Secure Interfaces and network services 13. Secure input and output handling 14. Logging 15. Monitoring and Auditing

1 https://www.microsoft.com/en-us/research/wp-content/uploads/2017/03/SevenPropertiesofHighlySecureDevices.pdf

CAN/CIOSC 105:2020 (D1)

ANNEX C: Standards Mapping

(PLACEHOLDER) WILL DEFINE MAPPING TABLES WHEN REQUIREMENTS ARE STABLE)

CAN/CIOSC 105:2020 (D1)

ANNEX D: Glossary of Terms

Term Definition Security Goal That Generates The Requirement For Actions Of An Entity To Be Traced Accountability Uniquely To That Entity. This Supports Nonrepudiation, Deterrence, Fault Isolation, Intrusion Detection And Prevention, And After-Action Recovery And Legal Action. Federal Information Processing Standard (FIPS) Approved Or National Institute Of Standards And Technology (NIST) Recommended. An Algorithm Or Technique That Is Either Approved 1) Specified In A FIPS Or NIST Recommendation, Or 2) Adopted In A FIPS Or NIST Recommendation. Asymmetric Cryptography See Public Key Cryptography. Two Related Keys, A Public Key And A Private Key That Are Used To Perform Asymmetric Keys Complementary Operations, Such As Encryption And Decryption Or Signature Generation And Signature Verification. Set Of Interfaces (The “Attack Vectors”) Where An Unauthorized User Can Try To Enter Attack Surface Data To Or Extract Data From A System Or Modify A System’s Behavior. Interfaces Or Paths An Attacker Uses To Exploit A Vulnerability. For Instance, An Exploit May Use An Open Ip Port Vulnerability On A Variety Of Different Attack Vectors Such As Attack Vector Wi-Fi, Cellular Networks, Ip Over Bluetooth, Etc. Attack Vectors Enable Attackers To Exploit System Vulnerabilities, Including The Human Element. Verifying The Identity Of A User, Process, Or Device, Often As A Prerequisite To Allowing Authentication Access To Resources In An Information System Access Privileges Granted To A User, Program, Or Process Or The Act Of Granting Those Authorization Privileges. Ensuring Timely And Reliable Access To And Use Of Information. The Property Of Being Availability Accessible And Useable Upon Demand By An Authorized Entity. An Undocumented Way Of Gaining Access To A Computer System. A Backdoor Is A Backdoor Potential Security Risk. The Sequence Of Bytes That Comprises The Software, Both Code And Data, Running On Binary/Firmware image Vehicle Electronics. Preserving Authorized Restrictions On Information Access And Disclosure, Including Means For Protecting Personal Privacy And Proprietary Information. It Is The Property That Confidentiality Sensitive Information Is Not Disclosed To Unauthorized Individuals, Entities, Or Unauthorized Individuals, Entities, Or Processes. Collections Of Resources, Buildings, And Distributed Energy Resources That Incorporate Connected Community Integrated Energy Management Strategies And Other Common Functions To Serve A Community Controller Area Network Is Dominant Serial Communication Network Protocol Used For Intra-Vehicle (CAN) Communication. Cyber-Physical Systems (Cps) Are Integrations Of Computation, Networking, And Physical Processes. Cyber-Physical Systems (Cps) Comprise Interacting Digital, Analog, Physical, And Cyber Physical Systems (CPS) Human Components Engineered For Function Through Integrated Physics And Logic. These Systems Will Provide The Foundation Of Our Critical Infrastructure, Form The Basis Of Emerging And Future Smart Services, And Improve Our Quality Of Life In Many Areas. Debug The Activity Of Discovering Errors Or Undesirable Actions Within Computer Code.

CAN/CIOSC 105:2020 (D1)

An Interface On A Routing Firewall That Is Similar To The Interfaces Found On The Firewall’s Protected Side. Traffic Moving Between The The Internal Netwo9Rk’S Demilitarized Zone (DMZ) Information Assurance Policy For External Information Exchange And To Provide External, Untrusted Sources With Restricted Access To Releasable Information While Shielding The Internal Networks From Outside Attacks. The Prevention Of Authorized Access To Resources Or The Delaying Of Time-Critical Denial of Service (DoS) Operations. (Time-Critical May Be Milliseconds Or It May Be Hours, Depending Upon The Service Provided.) Is A Mathematical Technique Used To Validate The Authenticity And Integrity Of A Digital signing Message, Software Or Digital Document. Is An Embedded System That Provides A Control Function To A Vehicle’s Electrical System Electronic Control Unit (ECU) Or Subsystems Through Digital Computing Hardware And Associated Software. An Action That Takes Advantage Of A Vulnerability In Order To Cause Unintended Or Unanticipated Behavior To Occur On Computer Software And/Or Hardware. An Example Of Exploit An Exploit Would Be Using A Diagnostic Port Vulnerability To Take Advantage Of A Buffer Overflow That Allows Access Over Internet Protocol (Ip) Networks. The Software Code And Data That Reside On An Embedded System, Such As An Automotive Electronic Control System, That Implements Dedicated Functions And Manage System Resources (E.G., System Input/Outputs (I/O) To Execute Those Functions. Firmware May Firmware Take A Variety Of Different Forms. For Example, In Some Cases “Firmware” May Refer To Source Code While In Some Cases It May Take The Form Of A Binary Image Consisting Of A File System And Compiled Code. Is An Occurrence That Actually Or Potentially Jeopardizes The Confidentiality, Integrity, Or Incident Availability Of An Information System On A Vehicle Computing Platform Through The Use Of An Exploit. A Set Of Policies, Processes, Server Platforms, Software, And Workstations Used For The Public Key Infrastructure Purpose Of Administering Certificates And Public-Private Key Pairs, Including The Ability To Issue, Maintain, And Revoke Public Key Certificates. The Smart Grid Enhances The Utility Capability And Introduces Additional Entities To Implement Grid Function Including Demand Response, Consumer Efficiency, Wide-Area Smart Grid Situational Awareness, Distributed Energy Resource (Der) Management, Energy Storage, Network Communication, And Advanced Metering Infrastructure (Ami) The Integration Of Telecommunications And Informatics For Intelligent Applications In Telematics Vehicles, Such As Fleet Management. A Public Key And The Name Of A Certification Authority That Is Used To Validate The First Certificate In A Sequence Of Certificates. The Trust Anchor’s Public Key Is Used To Verify Trust Anchor The Signature On A Certificate Issued By A Trust Anchor Certification Authority. The Security Of The Validation Process Depends Upon The Authenticity And Integrity Of The Trust Anchor. A Tamper-Resistant Integrated Circuit Built Into Some Computer Motherboards That Can Trusted Platform Module Perform Cryptographic Operations (Including Key Generation) And Protect Small Amounts (TPM) Chip Of Sensitive Information, Such As Passwords And Cryptographic Keys. Is A Weakness In A System Or Its Associated Networks, System Security Procedures, Internal Controls, Or Implementation That Could Be Exploited To Obtain Unauthorized Vulnerability Access To System Resources. For Instance, An Open Diagnostic Port On An Ecu Is A Vulnerability.

CAN/CIOSC 105:2020 (D1)

ANNEX E: Bibliography

Broadband Internet Technical Advisory Group (BITAG) (2016) Internet of Things (IoT) Security and Privacy [1] Recommendations. (Broadband Internet Technical Advisory Group [BITAG], Denver, CO).

Cloud Security Alliance (CSA) IoT Working Group (2015) Identity and Access Management for the Internet of [2] Things. (Cloud Security Alliance [CSA]).

CTIA (2018) CTIA Cybersecurity Certification Test Plan for IoT Devices, Version 1.0.1. (CTIA, Washington, DC). [3] https://www.ctia.org/about-ctia/test-plans/

Embedded System Conference. Implementing Secure Remote Firmware Updates. Embedded System [4] Conference Silicon Valley ESC-202. May 2011.

[5] European Network for Cyber Security. EV Charging Systems - Security Requirements. August 2017

European Technical Standards Institute (ETSI). TS 103 645 V1.1.1, Cyber Security for Consumer Internet of [6] Things. February 2019.

Federal Information Processing Standards (FIPS). FIPS 140-2, Security Requirements for Cryptographic [7] modules. May 2001

Federal Information Processing Standards (FIPS). FIPS 140-3, Security Requirements for Cryptographic [8] Modules. March 2019

[9] Federal Information Processing Standards (FIPS). FIPS 180-4, Secure Hash Standard. August 2015

[10] Federal Information Processing Standards (FIPS). FIPS 186-4, Digital Signature Standard. July 2013

Institute of Electrical and Electronics Engineers (IEEE). IEEE 1613, 2009 Edition Environmental and Testing [11] Requirements for Communications Networking Devices in Electric Power Substations.

Institute of Electrical and Electronics Engineers (IEEE). IEEE C37.231-2006, Recommended Practice for [12] Microprocessor-Based Protection Equipment Firmware Control

Institute of Electrical and Electronics Engineers. IEEE STD 1613-2003, Standard Networks and Systems in [13] Substations - Part 3: General Requirements

International Electrotechnical Commission (IEC), IEC 62351, Information Security for Power System Control [14] Operations

[15] International Electrotechnical Commission (IEC). IEC 61850-3, Communication. January 2002

International Electrotechnical Commission IEC). IEC-62443 Part 4-2, Security for Industrial Automation and [16] Control Systems (IACS). 2019

CAN/CIOSC 105:2020 (D1)

International Organization for Standardization (ISO). ISO/FDIS 15118, DRAFT, Road vehicles - Vehicle to grid [17] communication interface, Parts 1-8. 2017

National Electrical Manufacturers Association (NEMA). NEMA SG-AMI 1, Requirements for Smart Meter [18] Upgradeability. 2009

[19] NIST. Cybersecurity Framework: Framework for Improving Critical Infrastructure Cybersecurity. April 2018

[20] NIST. Interagency Report 7298r2, Glossary of Key Information Security Terms. May 2013

[21] NIST. Interagency Report 7946, CVSS Implementation Guidance. April 29, 2014.

[22] NIST. SP 800-154, DRAFT, Guide to Data-Centric System Threat Modelling. March 2016

NIST. SP 800-16 Rev. 1, A Role-Based Model for Federal Information Technology / Cyber Security Training. [23] March 2014

NIST. SP 800-37 Rev. 1, Guide for Applying the Risk Management Framework to Federal Information Systems: [24] A Security Life Cycle Approach. February 2010

NIST. SP 800-52 Rev. 2, DRAFT, Guidelines for the Selection, Configuration, and Use of Transport Layer Security [25] (TLS) Implementations. November 2017

NIST. SP 800-53 Rev. 4, Recommended Security Controls for Federal Information Systems and Organizations. [26] May 2013

[27] NIST. SP 800-82 Rev. 2, Guide to Industrial Control Systems (ICS) Security. May 2015

[28] NIST. SP 800-88 Rev. 1, Guidelines for Media Sanitization. December 2014

NIST. Supply Chain Risk Management Practices for Federal Information Systems and Organizations, NIST [29] SP800-161 (National Institute of Standards and Technology, Gaithersburg, MD)

North American Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) Standards [30] https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx

Open Web Application Security Project (OWASP). Internet of Things Project, May 2018. [31] https://owasp.org/www-project-internet-of-things/

Radio Technical Commission for Aeronautics (RTCA). RTCA DO-326, Airworthiness Security Process [32] Specification. December 2010

Radio Technical Commission for Aeronautics (RTCA). RTCA DO-326A, Airworthiness Security Process [33] Specification. August 2014

CAN/CIOSC 105:2020 (D1)

Radio Technical Commission for Aeronautics (RTCA). RTCA DO-356, Airworthiness Security Methods and [34] Considerations. September 2014

Radio Technical Commission for Aeronautics (RTCA). RTCA DO-356A, Airworthiness Security Methods and [35] Considerations. June 2018

[36] Security Profile for Distribution Management Version 1.0, ASAP-SG February 2012

Society of Automotive Engineers (SAE). SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle [37] Systems. Jan 2016

The Seven Properties of Highly Secure Devices Microsoft Research NExT Operating Systems Technologies [38] Group

U.S. Department of Defence (DoD). Directive 8500.2, Information Assurance (IA) Implementation. February 6, [39] 2003

U.S. Department of Homeland Security. Catalog of Control Systems Security: Recommendations for Standards [40] Developers. April 2011.

U.S. Department of Transportation (DOT). DOT HS 812 075, National Highway Traffic Safety Administration [41] (NHTSA): A Summary of Cybersecurity Best Practices. October 2014

U.S. Department of Transportation (DOT). DOT HS 812 333, National Highway Traffic Safety Administration [42] (NHTSA): Cybersecurity best practices for modern vehicles. October 2016 U.S. Department of Transportation (DOT). Medium and Heavy-Duty Electric Vehicle and Charging [43] Infrastructure Cyber Security Baseline Reference Document V1.2, National Motor Freight Traffic Association (NMFTA). May 2018 Underwriters Laboratories (UL). U.L. 2900-1, Standard for Software Cybersecurity for Network-Connectable [44] Products, Part 1: General Requirements. July 2017

European Union Agency for Network And Information Security (ENISA) Baseline Security Recommendations [45] for IoT in the context of Critical Information Infrastructures

CAN/CIOSC 105:2020 (D1)