i e c 6 2 4 4 3 s ta n d a r d s a n d i s a s e c u r e c

ISA Security Compliance Institute

67 T.W. Alexander Drive Research Triangle Park, NC 27709

Copyright © 2017 ASCI - Automation Standards Compliance Institute, all rights reserved.

I E C 6 2 4 4 3 S T A N D A R D S A N D I S A S E C U R E ®

C E R T I F I C AT I O N : A P P L I C A B I L I T Y T O

B U I L D I N G C O N T R O L S Y S T E M S

REPORT FROM THE ISA SECURITY COMPLIANCE INSTITUTE BUILDING CONTROL SYSTEM CYBER SECURITY WORKING

GROUP

JANUARY 16, 2017 FINAL




I E C 6 2 4 4 3 A N D I S A S E C U R E ® C E R T I F I C AT I O N A P P L I C A B I L I T Y

T O BU I L D I N G C O N T RO L S Y S T E M S

REPORT FROM THE ISASECURE BUILDING CONTROL SYSTEMS CYBER SECURITY WORKING GROUP DRAFT 0.8

INTRODUCTION ........................................................................................................................................ 4

AUDIENCE ................................................................................................................................................ 7

TECHNICAL ANALYSIS ............................................................................................................................... 7

APPLICABILITY OF IEC 62443 STANDARDS TO BCS................................................................................................ 8 BCS USE CASES .............................................................................................................................................. 8

Use Cases by Tier ................................................................................................................................... 9 Use cases by BCS Component Type ...................................................................................................... 10

BCS CYBERSECURITY STANDARDS AND CERTIFICATIONS ........................................................................................ 11 APPLICABILITY OF ISASECURE CERTIFICATIONS TO BCS ......................................................................................... 12

MARKET OBSERVATIONS ....................................................................................................................... 14

APPENDIX 1 - IEC 62443 SERIES OF STANDARDS ..................................................................................... 17

APPENDIX 2 - WORKING GROUP EFFORT ............................................................................................... 19

MEMBERS ................................................................................................................................................... 19 WORK PROCESS ............................................................................................................................................ 20

APPENDIX 3 - BCS COMPONENTS ........................................................................................................... 22

CHARACTERISTICS OF BCS EMBEDDED DEVICES ................................................................................................... 22 HVAC EMBEDDED DEVICES ............................................................................................................................ 22 HVAC APPLICATIONS .................................................................................................................................... 23 OTHER BCS EMBEDDED DEVICES ..................................................................................................................... 23

APPENDIX 4 - BCS PROTOCOLS ............................................................................................................... 24

APPENDIX 5 - CYBER SECURITY EFFORTS RELATED TO BCS ..................................................................... 27

US DEPARTMENT OF DEFENSE - BCS CYBER SECURITY .......................................................................................... 27 US FEDERAL GOVERNMENT - PHYSICAL ACCESS CONTROL ..................................................................................... 27 US FEDERAL GOVERNMENT CYBER SECURITY - GENERAL IT AND CONTROL SYSTEMS ................................................. 28 NATIONAL INSTITUTE OF BUILDING SCIENCES ...................................................................................................... 29 ASHRAE .................................................................................................................................................... 29 BACNET SECURITY FEATURES .......................................................................................................................... 29 MODBUS SECURE .......................................................................................................................................... 30 ELECTRIC SECTOR .......................................................................................................................................... 30 INTERNET OF THINGS ..................................................................................................................................... 30 CYBER PHYSICAL SYSTEMS ............................................................................................................................... 31

P a g e | 2




APPENDIX 6 - REVIEW OF IEC 62443 STANDARDS .................................................................................. 32

IEC 62443-1-1 ........................................................................................................................................... 32 IEC 62443-3-3 AND IEC 62443-4-2 .............................................................................................................. 34 IEC 62443-4-1 ........................................................................................................................................... 36

APPENDIX 7 - OVERVIEW OF ISASECURE CERTIFICATIONS ...................................................................... 37

APPENDIX 8 - REVIEW OF ISASECURE CERTIFICATIONS .......................................................................... 39

SECURITY DEVELOPMENT LIFECYCLE .................................................................................................................. 39 FUNCTIONAL SECURITY ASSESSMENT ................................................................................................................ 39 ROBUSTNESS TESTING .................................................................................................................................... 39

APPENDIX 9 - LEVEL 1 EDSA FSA REQUIREMENTS NOT ALLOCATABLE .................................................... 41

APPENDIX 10 - IEC 62443 AND BCS ARCHITECTURES .............................................................................. 42

SUMMARY COMPARISON OF BCS ARCHITECTURE MODELS TO ISA REFERENCE MODEL ................................................ 42 BUILDING CONTROL TIERS ARCHITECTURE DIAGRAM ............................................................................................ 42 DOD FACILITY-RELATED CONTROL SYSTEM ARCHITECTURE ................................................................................... 43

APPENDIX 11 - ACRONYMS .................................................................................................................... 45

Tables

Table 1 ISASecure Mapped to IEC 62443 ....................................................................................................... 6 Table 2 BCS Types, Candidates for ISASecure Certification ......................................................................11 Table 3 Working Group Members ..................................................................................................................19 Table 4 Examples of BCS Embedded Devices Other Than HVAC .........................................................23 Table 5 BCS Protocols by Priority ...................................................................................................................24 Table 6 ISCI Recognized Tool Support for BCS Protocols........................................................................25

Figures

Figure 1 From ASHRAE Guideline 13, Figure 12.14.5 ................................................................................. 9 Figure 2 IT Convergence for BCS Sub Systems ...........................................................................................16 Figure 3 Evaluation Elements for ISASecure EDSA Certification ..........................................................37 Figure 4 Evaluation Elements for ISASecure SSA Certification ................................................................38 Figure 5 Reference Architecture for IEC 62443 from IEC 62443-1-1 .....................................................42 Figure 6 Building Automation System Tier Architecture ............................................................................43 Figure 7 Control System Architecture Diagram from UFC 4-010-06 .......................................................44

P a g e | 3




P a g e | 4




INTRODUCTION

Background

This study was initiated at the request of Building Control Systems (BCS) stakeholders during a Q4 2015 ISA (International Society of Automation) Security Compliance Institute (ISCI) meeting in Japan. Attendees included major building owners and tier-1 BCS suppliers.

Stakeholders agreed to commit volunteer BCS cybersecurity subject matter experts to a BCS working group (WG). Stakeholders also agreed to provide funding necessary for support staff to facilitate the BCS WG study and draft the final report containing the results of the BCS WG study. ISCI expresses gratitude to BCS WG participants for their volunteer time and for funds contributed to enable the study to move forward.

Purpose

In March 2016, the industry consortium ISCI convened the ISASecure® BCS cybersecurity working group with goal to determine the applicability of existing ISCI ISASecure cybersecurity certification programs to building control systems. This report reflects the consensus of the BCS WG volunteer participants and describes the study’s findings.

The specific goals of the BCS study included the following items:

1. Applicability of IEC 62443 to BCS Determine whether IEC 62443 standards adequately cover BCS cybersecurity requirements for BCS systems, components, and supplier development process

2. BCS Use Cases Identify product use-cases where IEC 62443 standards are relevant to BCS

3. BCS Cybersecurity Standards Survey existing BCS cybersecurity standards (if any) to determine if IEC 62443 would be duplicative or complementary

4. BCS Cybersecurity Certifications Identify existing BCS cybersecurity certifications (if any) already in place to determine if ISASecure would be duplicative or complementary for BCS certifications

5. Applicability of ISASecure Certifications to BCS Analyze ISASecure coverage for BCS in relevant areas of BCS from #2 – develop a gap analysis report describing changes and additions necessary for ISASecure to fully support BCS.

This study is based, in large part, upon the recognition that the IEC 62443 standards were written as technology horizontal control system cybersecurity standards with broad industry applicability, including BCS.

However, it is also recognized that in the drafting of the IEC 62443 standards, traditional process industry automation experts were well represented in the ISA99 committees; and although the standards were written as a technology horizontal rather than as process industry-specific standards, the standard reflects in large part the input from process automation industry participants.

What is a Building Control System

P a g e | 5




"Building control systems" here refers to devices and systems that control physical operations for commercial building facilities. Examples of physical operations are HVAC (heating, ventilation and air conditioning), lighting, physical access control, and fire safety systems. Examples of such building facilities are office, military, financial, education, retail, aviation, and medical facilities.

Scope of IEC 62443 Standards and ISASecure Certifications

The intention of the IEC 62443 series of standards is comprehensive coverage for control systems cybersecurity for affected stakeholder groups. The various parts of this series as pictured in "Appendix 1 - IEC 62443 Series of Standards" cover component technical requirements, system technical requirements, product supplier development lifecycle practices, integrator practices, and end user management and operation of a cybersecurity program at a site. Through a special arrangement with the IEC, the standards developed by ISA with the title ISA 62443, are internationalized as IEC 62443 standards on a fast-track basis. In recognition of this, the standards are generally referred to as IEC 62443 in this document. However, the name ISA 62443 will be used when discussing references to the standards from other documents, that use that title.

ISASecure certifications at this time assess conformance to a subset of the IEC 62443 series. In particular, ISASecure certifies commercial-off-the-shelf (COTS) products and product supplier development lifecycle practices, for conformance with applicable parts of the IEC 62443 series. The overall BCS architecture for a specific building or enterprise is not certifiable under the ISASecure program. However, architecture is taken into account in product certification in the following ways:

Certification requires development of a threat model for a product, which will include assumptions regarding the system environment in which the product will reside

Certification will address portions of a BCS architecture that are delivered as a single COTS product that incorporates several integrated networked devices. Here, we refer to such a product as a "COTS control system product." This is distinguished from the use of the term "control system," which may refer to a COTS control system product or to a site-engineered and integrated set of products from several suppliers, that together comprise a system.

The following section describes product types in scope of existing ISASecure certifications, and the mapping from these certifications to the IEC 62443 standards.

ISASecure Certifications Currently Available

There are currently three ISASecure certification programs which are designed to certify to IEC 62443 standards. The first two below are granted to COTS products; the third is granted to an organization for a documented security development lifecycle process that it follows for developing products.

ISASecure EDSA 2.0.0 (Embedded Device Security Assurance), under which an embedded device may be certified. Examples of BCS embedded devices are a fully programmable network controller, HVAC single or multi-zone controller, VAV (Variable Air Volume) box controller, badge entry controller, parking lot lighting controller. See Appendix 1 for the definition of an embedded device.

ISASecure SSA 2.0.0 (System Security Assurance), under which a COTS control system product consisting of more than one device, may be certified. An example of such a

P a g e | 6




BCS control system is a fire safety system that includes controllers, alarms, sensors, and related software that provides a human-machine interface.

ISASecure SDLA 1.0.0 (Security Development Lifecycle Assurance), under which a control system product supplier's security development lifecycle (SDL) process may be certified.

ISASecure Certifications Relationship to IEC 62443

The EDSA and SSA certifications assess conformance to IEC 62443 component and control system requirements standards, respectively, as well as to the development lifecycle standard. The SDLA process certification assesses conformance of a product development organization against the IEC 62443 development lifecycle standard. The following table summarizes this mapping.

Table 1 ISASecure Mapped to IEC 62443

ISASecure Certification

IEC 62443 Standards

ISASecure EDSA IEC 62443-4-2 Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components

IEC 62443-4-1 Security for industrial automation and control systems – Part 4-1: Secure product development life-cycle requirements

ISASecure SSA IEC 62443-3-3 Security for industrial automation and control systems – Part 3-3: System security requirements and security levels

IEC 62443-4-1 Security for industrial automation and control systems – Part 4-1: Secure product development life-cycle requirements

ISASecure SDLA IEC 62443-4-1 Security for industrial automation and control systems – Part 4-1: Secure product development life-cycle requirements

It should be noted that the IEC 62443-3-3 standard has been approved and published by IEC. The other two standards in the table above are expected to achieve this status in 2017. The related ISASecure certifications are currently aligned with advance drafts of the standards (which were donated to the ISA 99 committee), and will be modified in 2017 for alignment as needed with the approved versions.

All three certifications assess supplier capability to perform a SDL process in conformance with IEC 62443-4-1. In addition, EDSA and SSA certifications assess how that process was applied to the specific product to be certified. EDSA and SSA certifications assess an organization's process by taking a snapshot at the specific point in time when a product achieves certification. By comparison, achievement of SDLA certification represents an ongoing commitment by an organization to a conformant SDL for a specified subset (possibly all) of their product development activity. Once attained, EDSA and SSA certifications for a product do not expire; SDLA certification of a supplier's process requires a re-certification audit every three years.

P a g e | 7




Since ISASecure certifications are designed to align with IEC 62443 control system cyber security standards, the review by the BCS working group opened with a review of the most recent versions of those standards in the IEC 62443 series with which ISASecure certifications align. Those standards are named in Table 1.

In this document, "Appendix 7 - Overview of ISASecure Certifications" provides additional information and key facts about the three existing ISASecure certification programs. For the reader’s convenience, please note that all documents that define ISASecure certification criteria are publicly available at www.ISASecure.org.

Potential Future ISASecure Certifications

The overall mission of ISCI is to provide conformance programs for the IEC 62443 standards. IEC 62443-4-2 covers component requirements for applications, network devices, and hosts, in addition to embedded devices. Beyond the existing ISASecure certifications, ISCI has discussed possible future certifications for applications, network devices (such as routers, firewalls, and gateways), and hosts (such as a Windows server). See Appendix 1 for IEC 62443 definitions of these component types. ISCI has done initial design work on a certification for software applications, which has been named ISASecure ASA (Application Security Assurance). These future certifications would certify conformance to IEC 62443-4-2 and IEC 62443-4-1, as shown in Table 1 for EDSA.

Report Organization

The main body this report has been organized into technical analysis and marketplace observations:

Technical analysis, which covers results related to the five goals listed above for the study; and

Market observations, regarding the current state of the BCS market for certifications such as ISASecure.

Appendices provide additional details for the technical analysis.

AUDIENCE

The intended audience for this report is the ISCI governing board and the BCS working group itself. The report will assist the ISCI board in assessing new development work (if any) necessary, should ISCI move forward to support ISASecure certifications for the BCS industry segment. In the future, parts of this report may be made available to BCS industry organizations, the ISA 99 Committee, and other BCS cyber security stakeholders.

TECHNICAL ANALYSIS

This section summarizes the results for the five goals described above as the purpose of the BCS working group effort.

P a g e | 8




APPLICABILITY OF IEC 62443 STANDARDS TO BCS

The working group judged that the IEC 62443 standards reviewed in this effort were applicable from a technical standpoint to BCS. Several members of the group were already using IEC 62443 in their BCS cyber security work prior to the working group effort. The major difficulty in reviewing the standards was achieving a common understanding of terminology. The group did not identify any clearly inapplicable or missing technical requirements. Details of this review are found in "Appendix 6 - Review of IEC 62443 standards."

BCS USE CASES

BCS use cases are specific COTS products to which the IEC 62443 standards apply, and which therefore could be candidates for ISASecure certification. Types of components distinguished in IEC 62443 are embedded devices, hosts, network devices, and applications. "Appendix 1 - IEC 62443 Series of Standards" provides the definitions of these terms from the standard.

The group identified many types of embedded devices involved in Heat, Ventilation, and Air Conditioning (HVAC) functions. These may be at the supervisory or IO level; they may reside in mechanical rooms or distributed in HVAC zones throughout a building.

Physical items that are controlled by embedded devices for HVAC are dampers, fans, heating and cooling coils, chillers, and boilers. Temperature and humidity sensors that incorporate embedded software are also embedded devices.

Beyond HVAC, BCS embedded devices include controllers and sensors involved in "smart buildings" systems such as the list below developed by the US DoD.

Advanced Metering Infrastructure

Building Automation System

Building Management Control System

CCTV Surveillance System

CO2 Monitoring

Digital Signage Systems

Electronic Security System

Emergency Management System

Energy Management System

Exterior Lighting Control Systems

Fire Alarm System

Fire Sprinkler System

Interior Lighting Control System

Intrusion Detection Systems

Physical Access Control System

Public Safety/Land Mobile Radios

Renewable Energy Geothermal Systems

Renewable Energy Photo Voltaic Systems

Shade Control System

Smoke and Purge Systems

Vertical Transport System (Elevators and Escalators)

P a g e | 9




The following sections examine BCS products that are candidates for ISASecure certification, by referencing two dimensions of product characteristics provided in ASHRAE Guideline 13-2015: "Specifying Building Automation Systems." The first dimension is ASHRAE tier. Guideline 13 defines these tiers, and includes a set of integration overview figures in section 12.4 illustrating their use. Each figure shows for a specific subsystem, how an architecture can be designed using products placed within each ASHRAE architecture tier. The second product dimension is type of component, where the ASHRAE guideline in section 4.4 enumerates and defines these types.

USE CASES BY TIER

The "integration overview" figures numbered 12.14.nn in ASHRAE Guideline 13 are used for reference here to illustrate the applicability of ISASecure product certifications. These figures in Guideline 13 cover a subset of the subsystems listed above. As an example for convenience to the reader, Figure 12.14.5 "Example multitier HVAC integration overview drawing" is shown below as it appears in the guideline.

Figure 1 From ASHRAE Guideline 13, Figure 12.14.5

Following is a description of applicability of ISASecure current and future product certifications at each of the ASHRAE tiers.

Tier 1: This tier is described per Guideline 13 section 12.4 :

"This set of components—graphical user interfaces (GUIs), applications, central servers, databases, network management tools—is commonly referred to as “system software” but also includes the physical hardware, such as computer servers, on which this software runs ... This software accesses data from networked controllers; has communication protocol access the control network; and stores information and data about the system such that user

P a g e | 10




interfaces, management tools, and other applications can display, analyze, manipulate, and interact with the control system."

Tier 1 in all of the integration overview figures includes corporate servers. Software applications and hosts in this tier would be candidates for potential future ISASecure ASA and host certifications.

Tier 2: The building level tier in the integration overview figures includes free programmable controllers, free programmable network controllers, and building panels. All of these products are embedded devices which are candidates for EDSA certification.

Tier 3: The equipment level tier in the integration overview figures includes application specific controllers, such as for controlling a (separate) air handling unit under gas detection or fire conditions, as well as security control systems, lighting control systems, fire life/safety interface systems, energy and water metering systems. All of these are embedded devices which are candidates for EDSA certification.

Tier 4: This tier consists of sensors, actuators or other field devices. If these devices contain embedded software, they meet the definition of embedded devices. Some are capable of IP communication; many are not. Although formally, all are candidates for EDSA certification, the certification will be of most interest for IP-capable field devices. Examples are smart thermostats and IP security cameras.

Common to many tiers: Communication devices (Guideline 13, section 4.4) such as gateways and routers may reside in any tier, and between tiers. These are classified as network devices in IEC 62443 terms, and therefore would be candidates for a possible future ISASecure certification of network devices. The ASHRAE guideline (section 4.4.1.8) also defines composite devices that may incorporate communication functions, such as a panel that incorporates a gateway. Such a device would be a candidate for both EDSA certification and a possible future network device certification. Likewise, software applications appear not only in tier 1, but also in tiers 2 and 3. These would be candidates for the potential future ISASecure ASA certification.

Cross-tier: In a few cases, BCS suppliers sell a specific combination of several devices off-the-shelf, as a product. Such a product crosses several tiers when its devices reside in several tiers. Specifically, ASHRAE Guideline 13 Figure 12.14.11 illustrates a fire/life safety system with devices in three tiers, which might be sold together as a COTS control system product. That example includes a fire panel at the building tier 2, a fire/life safety interface system at the equipment tier 3, and relays at tier 4. Such a COTS control system product is a candidate for ISASecure SSA certification.

.

USE CASES BY BCS COMPONENT TYPE

Section 4.4 of ASHRAE guideline 13 defines a number of component types. The following table lists these types and notes the applicability of existing or potential future ISASecure certifications.

P a g e | 11




Table 2 BCS Types, Candidates for ISASecure Certification

ASHRAE Guideline 13

Section Component Type

ISASecure Certification Type

(Potential future certification types shown in italics)

Comments

4.4.1.1 Building controller EDSA

4.4.1.2 Custom application controller

EDSA

4.4.1.3 Application-specific controller

EDSA

4.4.1.4 Programmable controller

EDSA

4.4.1.5 Supervisory controller EDSA

4.4.1.6 Building or equipment network interface

Network device certification

4.4.1.7 Web-server appliance ASA

4.4.1.8 Combination device Depends upon functions Example: panel with gateway: EDSA and network device certification

4.4.1.10 Other communication devices

Network device certification Includes gateways, routers, media translation (e.g. Ethernet to ARCNET)

4.4.3 I/O devices EDSA

4.4.4 Operator interface ASA Host certification would also apply if PC-based

"Appendix 3 - BCS Components" contains further background information about BCS component types.

BCS CYBERSECURITY STANDARDS AND CERTIFICATIONS

The group broadened this topic, to a general discussion of cyber security efforts that currently impact BCS products or supplier security development lifecycle processes, or that are expected to do so in the future.

The US DoD is starting an effort to create a process for listing approved operational technology (OT) products that support cyber security guidance for US DoD facilities. No other government or private sector BSC-specific guidelines, standards, or certifications for products in the BCS domain are known to the members of the working group.

Recent US DoD guidelines for facility cyber security and physical access control systems, will however impact requirements for BCS products to appear on the future approved OT list. Other

P a g e | 12




federal government standards for cyber security, some of which are specific to control systems, also impact BCS suppliers in that marketplace.

Security specification improvements are nearing release for the commonly used BCS protocol BACnet (Building Automation and Control networks). The availability of implementations will enable stronger network security specifications by BCS customers. Efforts by NIST (National Institute of Standards and Technology) on the Internet of Things (IoT) and cyber physical systems may ultimately impact BCS. Industry organizations ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) and CABA (Continental Automated Buildings Association) are beginning education efforts regarding cyber security, and launching efforts to study the needs of their members related to BCS cyber security.

A number of these efforts reference ISA 62443:

NIST Framework for Improving Infrastructure Cybersecurity includes ten specific references to ISA 62443-3-3

NIST 800-82 Guide to Industrial Control System Security and NIST Framework for Cyber Physical Systems provide ISA 62443 a general reference

In CABA's 2015-16 study Intelligent Buildings and Cybersecurity, ISA 62443 is first in a list of "prominent building control cybersecurity standards."

"Appendix 5 - Cyber Security efforts related to BCS" in this document contains further details of BCS-related cybersecurity efforts.

APPLICABILITY OF ISASECURE CERTIFICATIONS TO BCS

The group concluded that existing ISASecure EDSA, SSA, and SDLA certifications can be applied to BCS. Members agreed that further detailed technical analysis of Communication Robustness Testing (CRT) would be necessary to ensure that CRT testing procedures properly support BCS products and use-cases, noting any recommended adjustments. The group's analysis of these certifications and the nature of these adjustments is further detailed below.

Applicability of ISASecure Certifications on ISCI Roadmap

In addition to embedded devices and systems, BCS also incorporate a wide variety of software applications. The working group was interested in the ISASecure Application Security Assurance (ASA) certification which is currently under development by the ISCI Technical Steering Committee.

EDSA Analysis

ISASecure EDSA certifications as outlined in "Appendix 7 - Overview of ISASecure Certifications" are comprised of three certification elements to complete a 360 degree product evaluation. The three elements are:

1) Security Development Lifecycle assessment of the product development process and related artifacts for the product

2) Functional Security Assessment of the product's security capabilities (features)

P a g e | 13




3) Robustness Testing, including Communication Robustness Testing (CRT) and Vulnerability Identification Testing (VIT)

The group concluded that all evaluation elements of the EDSA certification apply to BCS embedded devices, noting possible adjustments needed for a limited number of CRT test criteria.

For example, although the group agreed with the test goal for ISASecure CRT, configuration of a test control signal for the device, and pass/fail criteria for CRT, may need adjustment for specific types of BCS embedded devices. Some types of BCS controllers can be programmed to create the control signals specified by EDSA for monitoring during CRT, and some cannot. Further, slow cycle controllers may have a process time constant of up to a half hour, whereas ISCI CRT flood tests run for two minutes.

The group recommended that ISCI collaborate with BCS subject matter experts to identify a method to monitor various types of BCS devices for the impact of CRT tests on the control function. The group briefly discussed an approach that would involve developing a sequence of sensor inputs and then monitoring for either the expected control output based on these inputs, or for a fixed "default" output designed-in to be used when inputs were not received. However, it was beyond the charter of the group to develop a specific proposal for this.

Nevertheless, the group felt confident that CRT test processes could be adapted to accommodate these types of BCS devices.

These potential adjustments to EDSA certification procedures do not imply a need for corresponding changes to IEC 62443 requirements. Maintenance of essential functions under network attack per IEC 62443 was agreed to be an applicable requirement for BCS. The existing ISASecure CRT test regimen of monitoring for jitter on specific control signals, is a detailed method for testing that requirement; other methods are possible.

SSA Analysis

Similar to EDSA, ISASecure SSA certifications are comprised of three certification elements to complete a 360-degree product evaluation. The three elements are:

1) Security Development Lifecycle assessment of control system development process and related artifacts for the product

2) Functional Security Assessment of the control system’s security capabilities (features)

3) Robustness Testing, including Communication Robustness Testing (CRT), Network Stress Robustness Testing (NST), and Vulnerability Identification Testing (VIT)

The group concluded that all evaluation elements of the SSA certification apply to BCS systems, noting possible adjustments needed for a limited number of CRT test criteria.

Since the ISASecure SSA certification uses the same CRT approach as EDSA, SSA would require similar CRT test adaptations as noted for EDSA. All other aspects of the ISASecure SSA certification appeared applicable for BCS.

The group noted that there are limited examples of BCS systems that are COTS control system products and therefore candidates for SSA certification. This is because most BCS systems are site-engineered. In general, the BCS industry is moving to an open interoperability model so BCS can be

P a g e | 14




integrated using ‘best of breed’ to construct the customer site-engineered solution. Even though one integrator (supplier) may deliver a mix and match solution of components from various suppliers, the solution is not typically managed as an COTS product; rather its components and their interactions comprise a site-specific solution.

Examples of BCS products that can be addressed by an ISASecure SSA certification include:

A BCS embedded device delivered together with other devices that provide compensating controls for that embedded device

Systems with several devices that communicate using proprietary protocols

Systems for fume hood control or fire safety, that include HMI software, controllers, sensors, and actuator devices made by the same manufacturer.

SDLA Analysis

The BCS WG concluded that the ISASecure SDLA certification for suppliers of control system products is applicable to BCS suppliers, and did not note any issues.

It was understood that the SDLA-312 document used for SDLA certification, will be aligned with the approved IEC 62443-4-1 in a few months. The group, therefore, reviewed the requirements in IEC 62443-4-1 rather than the requirements in the published specification ISASecure SDLA-312. Some BCS WG supplier members found many individual SDLA requirements to be familiar, noting that their customers are already including those requirements in procurement specifications.

Further details of this review are found in "Appendix 8 - Review of ISASecure Certifications." Information about BCS protocols relevant for certification is found in "Appendix 4 - BCS Protocols."

MARKET OBSERVATIONS

Although a market analysis was not a specific objective for the WG, during the course of the study the WG members offered their perspective on the likely market demand and viability of a BCS product cybersecurity certification scheme. If a BCS certification is desired by building owners/end users, what will the market uptake curve look like? Which BCS market segments will be the early adopters/thought leaders and which segments will likely follow later? What is the maturity level of the BCS industry stakeholders regarding BCS cybersecurity and are stakeholders increasing investments in BCS cybersecurity?

The working group agreed that the security requirements in the IEC 62443 standard and ISA certifications are already of interest at this time to some BCS end-users. Several industry segments were immediately identified as cybersecurity leaders/early adopters including aviation, medical, clean room, and military facilities. The US DoD (United States Department of Defense) has identified the need to extend the concept of its APL (Approved Product List) from IT to OT (operational technology) devices. The DoD has recently published guidance for facility cyber security. Current federal government contract language seen by group members includes requirements for SDL (security development lifecycle), assurances against the top 10 OWASP errors, and software signing.

P a g e | 15




BCS WG members felt that both the IEC 62443 standard requirements and the ISASecure certification requirements may be too rigorous and expensive for suppliers of low-margin ‘commodity BCS products’ sold into BCS market segments such as strip malls, restaurants, and small medical offices. The section below "IEC 62443-3-3 and IEC 62443-4-2" lists specific cybersecurity requirements in the standard that may exceed the needs of these end-users and/or be too expensive for the low-margin suppliers to meet economically.

The group perceived that the ISASecure product certifications would be prohibitively expensive for many low-cost, constrained BCS embedded devices, regardless of end-user. Therefore, the group did not expect that an industry-wide building control organization would embrace IEC 62443 or the ISASecure certifications across all BCS products. It is expected, however, that interest in cyber security across the industry will broaden over time. Reports are emerging of specific cyber-attacks on BCS. A recent denial of service cyber-attack in Finland turned off the heat in two apartment buildings ("Let's Get Cyberphysical: Internet Attack shuts off the Heat in Finland," The Security Ledger Nov 8, 2016 https://securityledger.com/2016/11/lets-get-cyberphysical-ddos-attack-halts-heating-in-finland/).

One driver of future demand for product cybersecurity certifications is the current high interest in cyber security for the Internet of Things, which includes very simple "devices" that ultimately reside on building networks. Incidents such a recent serious DDoS (Distributed Denial of Service) attack employing such devices, are expected to ultimately broaden interest in their security ("Massive cyberattack turned ordinary devices into weapons," CNNMoney, Oct 22, 2016 http://money.cnn.com/2016/10/22/technology/cyberattack-dyn-ddos/index.html). Touching the BCS space in particular, a collection of insecure IP connected CCTV cameras was recently used to launch denial of service attacks against other targets ("IOT Botnet - 25000 CCTV Cameras Hacked to launch DDOS Attack," The Hacker News, June 28, 2016 http://thehackernews.com/2016/06/cctv-camera-hacking.html).

However, such cases offer an argument for securing all IP-based devices, but not necessarily an argument for ISASecure certifications for all such devices. The threat of being an unwitting DDoS participant might for example be addressed by a certification that provides assurances against device misuse to the detriment of network "neighbors" of the device, and may not extend to assurance of robustness of the device itself, as required by IEC 62443 and ISASecure.

The working group felt that increasingly, the "customers" for BCS security were those responsible for IT security in the building. This is because of the increasing convergence of IT and OT functions on the same network. This convergence trend is reflected in the CABA study which reported that 86% of survey respondents agreed with the statement "Role of IT & operations is converging when it concerns cybersecurity in intelligent buildings."

The level of integration with IT networks is a driver for the need for increased security of specific building sub systems. The following graphic from the CABA study cited above depicts current level of integration for major sub systems. However, the overall trend is toward increased integration. The study also advises of the risks inherent in this trend: "Damaged HVAC and other equipment after all, cannot be 'restored from backup.' ... Future research should attempt to uncover the extent to which IT departments have the resources and skillsets needed to handle threats targeted at building control systems... In fact, the federal government wants to completely separate the OT (operations technology) and IT networks."

https://securityledger.com/2016/11/lets-get-cyberphysical-ddos-attack-halts-heating-in-finland/

https://securityledger.com/2016/11/lets-get-cyberphysical-ddos-attack-halts-heating-in-finland/

http://money.cnn.com/2016/10/22/technology/cyberattack-dyn-ddos/index.html

http://thehackernews.com/2016/06/cctv-camera-hacking.html

P a g e | 16




Figure 2 IT Convergence for BCS Sub Systems

From this figure, it appears then that high level controllers (here denoted BACS) and CCTV would be high priority product areas for increased attention to cybersecurity.

Industry groups ASHRAE and CABA have start-up efforts in the area of cyber security. They are working to educate their members and to determine what guidance their members need. CABA is working on a study entitled Intelligent Buildings and the Impact of IoT in addition to the recently published study Intelligent Buildings and Cybersecurity. The CABA study points out that "Embedded security is becoming more imperative in today’s product development of IoT (or automated) systems or solutions."

Large vendors in the industry are addressing SDL, but roll-outs in many cases are not yet organization-wide.

A particular advantage the working group sees for IEC 62443 is that it is an international standard. Even the US DoD has many facilities outside of the US. Achieving compliance for such facilities with US standards can be challenging. Suppliers operate in an international marketplace, making an international standard most efficient from their standpoint.

P a g e | 17




APPENDIX 1 - IEC 62443 SERIES OF STANDARDS

Organization

The following diagram from the ISA99 committee web site at http://isa99.isa.org/ISA99%20Wiki/Home.aspx depicts the IEC 62443 series of standards. An overview the series can be found at http://isa99.isa.org/Public/Information/The-62443-Series-Overview.pdf.

Component Type Definitions

The following component types are defined in IEC 62443-3-3.

application

software programs executing on the infrastructure that are used to interface with the process or the control system itself (for example configuration software and historian)

Note to entry: Attributes: executable, typically execute on personal computers (PCs) or embedded controllers.

http://isa99.isa.org/ISA99%20Wiki/Home.aspx

http://isa99.isa.org/Public/Information/The-62443-Series-Overview.pdf

http://isa99.isa.org/Public/Information/The-62443-Series-Overview.pdf

P a g e | 18




embedded device

special purpose device running embedded software designed to directly monitor, control or actuate an industrial process

Note 1 to entry: Typical attributes: no rotating media, limited number of exposed services, programmed through an external interface, embedded operating systems (OSs) or firmware equivalent, real-time scheduler, may have an attached control panel, may have a communications interface.

Note 2 to entry: Examples include PLCs, field sensor devices, safety instrumented system (SIS) controllers, distributed control system (DCS) controllers.

host device

general purpose device running a general purpose operating system (for example Microsoft Windows OS or Linux) capable of hosting one or more applications, data stores or functions

Note to entry: Typical attributes: rotating media, no real time scheduler, and full HMI (keyboard, mouse, etc.).

network device

device that facilitates data flow between devices, or restricts the flow of data, but does not directly interact with a control process

Note to entry: Typical attributes include embedded OS or firmware, no HMI, no real-time scheduler, and configured through an external interface.

P a g e | 19




APPENDIX 2 - WORKING GROUP EFFORT

This section discusses members and working process for the BCS working group.

MEMBERS

Active members of the working group were:

Table 3 Working Group Members

Name Company Role

Ron Bernstein Independent Consultant LonMark, Smart Buildings Institute, ASHRAE

Bruce Billedeaux Maverick Technologies ASHRAE, ISA/IEC 62443 terminology committee

Michael Chipley Independent Consultant US DoD and US Federal government Consultant

Brij Mohan Gupta IREO

Leading property developer /

asset owner in India.

Matt Jakuc CSA Group Standards development and related research

Harry Koujaian Siemens BCS supplier

Carol Lomonaco Johnson Controls BCS supplier; Senior Product Manager, Metasys critical systems

Carol Muehrcke Adventium Labs Project manager for ISCI

Carlos Petty Syska Hennessy Group, Inc.

Consulting, engineering, and commissioning firm for built environments

Andre Ristaino ISCI ISCI Managing Director

Steve Scott Johnson Controls BCS supplier

Kevin Staggs Honeywell Building Solutions BCS supplier, ISA 62443-4-2 lead, ISCI member

Greg Strass Schneider-Electric BCS supplier

Jon Williamson Schneider-Electric BCS supplier

The mission and vision of ASHRAE from its web site are:

Mission: To advance the arts and sciences of heating, ventilation, air conditioning and refrigeration to serve humanity and promote a sustainable world. Vision ASHRAE will be the global leader, the foremost source of technical and educational information, and the primary provider of opportunity for professional growth in the arts and sciences of heating, ventilating, air conditioning and refrigerating.

P a g e | 20




The mission and vision of CSA from its web site are:

Vision Our vision is to create a better, safer, more sustainable world where standards work for people and business. Mission The Mission of CSA Group is to represent the interests of its members in creating a better, safer, more sustainable world – primarily through standards development, technical research, and training in relevant fields. Through its world-class commercial subsidiaries, CSA Group engages in testing, certification, and related activities that support the organization technically and financially.

CSA has recently begun work to support CABA in its study entitled Intelligent Buildings and the Impact of IoT.

WORK PROCESS

The working group first discussed the definition of various types of components (embedded device, network device, host, application) from IEC 62443, and developed the following lists:

BCS product types, to consider the applicability of certification

BCS protocols, to examine the applicability of certification protocol testing

Related standards or guidelines efforts in the BCS industry.

The group then reviewed the requirements in the following versions of the IEC 62443 standards, and recorded member comments.

62443-1-1 Terminology, concepts and models Oct 29, 2007, published version

62443-3-3 System security requirements and security levels Aug 12, 2012, published version

62443-4-1 Secure product development life-cycle requirements Draft 3, Edit 11, March 2016 (ISA and IEC approved draft, download at http://isa99.isa.org/Public/Ballots/201603-ISA-62443-4-1/ISA-62443-4-1-CDV.pdf)

62443-4-2 Technical security requirements for IACS components Draft 2, Edit 4, July 2, 2015 (working draft, download at http://isa99.isa.org/Public/Documents/ISA-62443-4-2-WD.pdf )

The stated intent of the review was to uncover top-of-mind comments and reactions that would affect in turn the applicability of ISASecure certifications for BCS. This was not a complete detailed review of the standards, which would be appropriate to carry out within the ISA standards committee itself. The purpose was to identify applicable requirements in the standard, and any major issues with the requirements of the standard, that would indicate that a certification program aligned with the standard would or would not be applicable for BCS.

Finally, the group reviewed each of the ISASecure certifications. Certification processes and pass/fail criteria were discussed in slide format, and by showing selected portions of the ISASecure specifications themselves.

http://isa99.isa.org/Public/Ballots/201603-ISA-62443-4-1/ISA-62443-4-1-CDV.pdf


http://isa99.isa.org/Public/Documents/ISA-62443-4-2-WD.pdf


P a g e | 21




P a g e | 22




APPENDIX 3 - BCS COMPONENTS

CHARACTERISTICS OF BCS EMBEDDED DEVICES

BCS are often implemented in a hierarchical architecture, which may include at the top, supervisory controllers which interface up to an overall building automation system, and at the bottom, IO (Input/Output) controllers which talk directly down to the physical devices being controlled. Architectures are becoming flatter, with fewer intermediate layers between these, if any. Even though some controllers may implement logic and give instructions "indirectly" via IO controllers, they are considered embedded devices in the IEC 62443 terminology. Such intermediate-level controllers in the industrial space have been EDSA certified under ISASecure.

BCS controllers are characterized as fixed, configurable, or fully programmable. This characteristic is expected to influence how CRT pass/fail criteria might be adjusted for such devices. Other BCS embedded devices are sensors, with no control function present.

HVAC EMBEDDED DEVICES

Products related to Heat, Ventilation, and Air Conditioning (HVAC) are common to all buildings and these were examined in detail. Physical items that are controlled within such a system are dampers, fans, heating and cooling coils, chillers, and boilers. Various embedded devices control these items. Other embedded devices are sensors to measure temperature and humidity, which will influence controller actions.

A "terminal unit" is a subsystem that controls fans and dampers specific to an HVAC zone. A floor of a building may have many HVAC zones. Each terminal unit would have its own controller. These controllers have historically not been networked, but are expected to be in the future. There is however a large embedded base of non-networked terminal unit controllers.

In addition to controllers for terminal units, a few controllers run equipment at one or more central points in mechanical rooms, where cool/warm air is initially distributed to building zones. These controllers are normally mounted on the wall of the room. There may be, for example, one mechanical room for a small building, or one for each floor in a larger building.

Particular rooms may require specialty equipment such as Computer Room Air Conditioning (CRAC) Units for data centers.

Controllers in the mechanical room are typically networked to provide status to an overall building automation system. That system however does not issue commands to the mechanical room controllers. A mechanical room has its own supervisory controller that acts independently.

The chiller produces cold water, and the boiler warm water. A chiller typically has its own embedded controller from the chiller manufacturer.

In summary, sensors and controllers used for mechanical rooms, for HVAC zones, and for chillers and boilers were identified as embedded devices, that might be candidates for ISASecure certification. There are many types of each, depending upon the physical design of the system.

P a g e | 23




HVAC APPLICATIONS

The working group identified many software applications that may exist within an HVAC subsystem, including programs that implement control strategies (burner modulation for boilers, air flow for air handling units) and fault detection and diagnostics software for HVAC remote terminal units and air handling units.

OTHER BCS EMBEDDED DEVICES

Below are additional examples of BCS embedded devices for building control sub systems other than HVAC.

Table 4 Examples of BCS Embedded Devices Other Than HVAC

Subsystem Embedded Device

Exterior Lighting Control Systems Parking Lot Light Controller

Physical Access Control System Physical Access and Badge Access Controllers

Smoke and Purge Systems Parking Garages Exhaust Controller

Smoke and Purge Systems UL 864 Certified UUKL 9th / 10th Ed. listed Smoke Control or Fire Alarm System

Vertical Transport System Elevator Controller

P a g e | 24




APPENDIX 4 - BCS PROTOCOLS

The protocols used by BCS are of relevance for ISASecure certification because fuzz and flood testing of protocols for a device are required under the robustness testing and SDLPA/SDA certification elements (Security Development Lifecycle Process Assessment/Security Development Artifacts). In particular, CRT for EDSA and SSA certifications currently addresses the six protocols Ethernet, ARP, IPv4, ICMPv4, UDP, TCP. The specification ISASecure SDLA-312 requires supplier testing of all product parsers (which includes all protocol stacks) using fuzz and flood tests. In the future, ISASecure certification will include under SDLPA/SDA, detailed technical audit of supplier tests for all protocols supported by a device. Hence the availability of tools/methods to test protocols commonly used by BCS would impact the ease and utility of adoption for ISASecure.

The following table shows major BCS protocols as identified by the working group, arranged by priority. Highest priority (priority 1) indicates highest prevalence in the industry. Some of these protocols depend upon lower protocol layers currently tested by ISASecure CRT, as shown in the second column of the table. A double dash (--) indicates that the lower layer protocols that support the protocol listed in the left column, are not currently in the scope of certifier testing under ISASecure certification.

Table 5 BCS Protocols by Priority

Protocol

Lower Layers currently tested

under ISASecure CRT

BCS Priority

BACnet/IP™

Modbus (RTU)

Modbus (TCP)®

Network bridge devices (e.g. Ilan or Loytec)

ZigBee©- Open protocol

Wireless Cellular Protocols o DALI o EnOcean©- Low Power

Wireless protocol for energy harvesting and very lower power devices.

o KNX - Euro-Asian World standard for building control. Previously EIB/EHS/BATIBus

UDP/IP/Ethernet

--

TCP/IP/Ethernet

IP/Ethernet

--

-- 1

LonTalk®- protocol for LonWorks technology by Echelon Corporation

OPC UA (Open Platform Communications Universal Architecture)

--

--

2

BACnet MS/TP™

Ethernet Powerlink© - an open protocol managed by the Ethernet POWERLINK Standardization Group (EPSG) - Austrian.

oBIX© (Open Building Information XChange)

--

Ethernet

IP/TCP/Ethernet

3

P a g e | 25




Protocol

Lower Layers currently tested

under ISASecure CRT

BCS Priority

OPC - DA (Data Acquisition)

OPC - AE (Alarms and Events)

OSGP© - The Open Smart Grid Protocol, a widely use protocol for smart grid devices built on ISO/IEC 14908.1

VoIP (Voice over IP)

POE (Power over Ethernet)

SIA DC-05-1999.09 Ademco ® Contact ID Protocol - for Alarm System Communications

--

--

--

IPv4

Ethernet

--

DyNet (Control for Phillips Dynalite System)

WiMAX®

Z-Wave©

--

--

--

4

Testing of these protocols is supported by current ISCI-recognized test tools as shown below. This information comes from the public web sites of these vendors. ISCI maintains its list of recognized tools at www.isasecure.org. Specifics about the tests provided for these protocols by ISCI-recognized tools are not known at this time. A double dash (--) indicates that no tools currently recognized by ISCI support testing of the protocol listed in the left column.

Table 6 ISCI Recognized Tool Support for BCS Protocols

Protocol Tool

BCS Priority

BACnet/IP™

Modbus (RTU)

Modbus (TCP)®

Network bridge devices (e.g. Ilan or Loytec)

ZigBee©- Open protocol

Wireless Cellular Protocols o DALI o EnOcean©- Low Power

Wireless protocol for energy harvesting and very lower power devices.

o KNX - Euro-Asian World standard for building control. Previously EIB/EHS/BATIBus

beSTORM

--

Achilles/beSTORM/Defensics

--

Achilles/beSTORM

--

1

P a g e | 26




Protocol Tool

BCS Priority

LonTalk®- protocol for LonWorks technology by Echelon Corporation

OPC UA (Open Platform Communications Universal Architecture)

--

Achilles/Defensics

2

BACnet MS/TP™

Ethernet Powerlink© - an open protocol managed by the Ethernet POWERLINK Standardization Group (EPSG) - Austrian.

oBIX© (Open Building Information XChange)

OPC - DA (Data Acquisition)

OPC - AE (Alarms and Events)

OSGP© - The Open Smart Grid Protocol, a widely use protocol for smart grid devices built on ISO/IEC 14908.1

VoIP (6 and 8 related protocols, respectively)

POE (Power over Ethernet)

SIA DC-05-1999.09 Ademco ® Contact ID Protocol - for Alarm System Communications

--

--

--

--

--

--

beSTORM/Defensics

--

--

3

DyNet (Control for Phillips Dynalite System)

WiMAX®

Z-Wave©

--

--

--

4

P a g e | 27




APPENDIX 5 - CYBER SECURITY EFFORTS RELATED TO BCS

This appendix provides information on standards, guidelines and other industry efforts that currently impact BCS products or supplier security development lifecycle processes, or are expected to do so in the future.

US DEPARTMENT OF DEFENSE - BCS CYBER SECURITY

The US DoD has 562,600 buildings and structures, with $847 billion in value [reference PMC Group Consulting slides from Sep 14, 2016]. Efforts in the cyber security domain for DoD facilities are based around NIST standards.

Started 5 years ago, and two years in drafting, the US DoD published on 19 September 2016, a document "UFC 4-010-06 Unified Facilities Criteria - Cyber Security of Facility-Related Control Systems," which applies to all DoD facilities. This document does not reference IEC 62443. It specifically applies NIST SP 800-53 R4 and NIST SP 800-82 R2 (referenced below) to the BCS domain.

More broadly, the National Defense Authorization Act in 2017, defined a specific task to address cyber vulnerabilities and risk of control systems including specifically "Supervisory Control and Data Acquisition Systems, Building Automation Systems, Utility Monitoring, and Energy Management and Control Systems." The task output is a report covering risks, vulnerabilities, capabilities, proposed mitigations, and implementation plan.

The US DoD has published as of January 2016, Advanced Cyber Industrial Control Systems Tactics, Techniques and Procedures (ACI TTP's) for DoD Industrial Control Systems. A workshop developed by the PMC Group LLC applies this document specifically to building control systems (http://www.nibs.org/events/EventDetails.aspx?id=844995&group= ).

A good portion of the content in these guides addresses whole building security, as distinct from security of individual products. However, the need for secure products is addressed and understood. Members of the BCS working group report that the DoD is working to create a list of operational technology (OT) devices and components that would be on an approved product list (APL), similar to the current DISA IT APL. The US Army Corp of Engineers (USACE) is starting the first effort, focusing on Energy Systems. Ultimately the DoD would like to have overall cyber secure systems delivered by vendors, as now required by the new UFC cited above. The DoD has also indicated it would like a certification program for personnel, per DoDI 8140.01 (DoD Instruction Cyberspace Workforce Management) mapped to the NIST NICE which is out for public comment until Jan 5, 2017 (NIST Special Publication SP 800-181 DRAFT NICE Cybersecurity Workforce Framework (NCWF): National Initiative for Cybersecurity Education http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-181). The NIST NICE includes definitions for categories of cyber security skills.

US FEDERAL GOVERNMENT - PHYSICAL ACCESS CONTROL

The following recent US federal government efforts apply specifically for physical access control systems. These systems must protect information subject to privacy policies, as well as control cyber physical devices, and integrate with physical security measures.

http://www.nibs.org/events/EventDetails.aspx?id=844995&group=%20

http://csrc.nist.gov/publications/PubsDrafts.html%23SP-800-181

P a g e | 28




NIST 800-16, A Recommendation for the Use of PIV Credentials in Physical Access Control Systems

(PACS) http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-

116.pdf

Securing Government Assets through Combined Traditional Security and Information Technology: An Interagency Security Committee White Paper (Feb 2015) https://www.dhs.gov/sites/default/files/publications/ISC-CVS-White-Paper-2015-508.pdf The Interagency Security Committee (ISC), chaired by DHS, consists of 54 Federal departments and agencies and has as its mission the development of security standards and best practices for nonmilitary Federal facilities in the United States. Quoting from the ISC message that accompanies this paper: "Securing Government Assets through Combined Traditional Security and Information Technology: An Interagency Security Committee White Paper is intended to be applied to all buildings and facilities in the United States occupied by Federal employees for nonmilitary activities." This document focuses on the interaction between IT and physical security techniques used to secure these facilities, for monitoring and physical access control.

US FEDERAL GOVERNMENT CYBER SECURITY - GENERAL IT AND CONTROL SYSTEMS

The federal government has developed a large number of standards and guidelines for general cyber security, as well as some specific to control systems. Major documents are listed here.

NIST Framework for Improving Infrastructure Cybersecurity The NIST Framework for Improving Infrastructure Cybersecurity includes ten informative references to ISA 62443-3-3 found across the functions Identify, Protect, Detect, and Respond. The framework also references ISA 62443-2-1. Working group members reported that some of their customers are applying the framework to develop requirements, which in turn appear in procurement specifications.

NIST 800-82 Guide to Industrial Control System Security NIST 800-82 includes the statement in Section 2.5: "Although this guide provides guidance for securing ICS, other types of control systems share similar characteristics and many of the recommendations from this guide are applicable and could be used as a reference to protect such systems against cybersecurity threats. For example, although many building, transportation, medical, security and logistics systems use different protocols, ports and services and are configured and operate in different modes than ICS, they share similar characteristics to traditional ICS ... Examples of some of these systems and protocols include: Other Types of Control Systems •Advanced Metering Infrastructure •Building Automation System •Building Management Control System •CCTV Surveillance System •CO2 Monitoring •Digital Signage Systems •etc."

NIST 800-42 Guideline on Network Security Testing

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-116.pdf

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-116.pdf

https://www.dhs.gov/sites/default/files/publications/ISC-CVS-White-Paper-2015-508.pdf

P a g e | 29




NIST 800-53 Recommended Security Controls for Federal Information Systems and Organizations

NIST SP 800-88 Guidelines for Media Sanitization

FIPS 199 Standards for Security Categorization of Federal Information and Information Systems

FIPS 200 Minimum Security Requirements for Federal Information and Information Systems FIPS 200 summarizes security controls in 17 categories and the profiles for 3 levels of security.

FIPS 140-2 Security Requirements for Cryptographic Modules

NATIONAL INSTITUTE OF BUILDING SCIENCES

As part of its Whole Building Design Guide, the National Institute of Building Sciences offers a Cyber Security resource page https://www.wbdg.org/resources/cybersecurity.php. Working group member Michael Chipley manages this page. This page has extensive links to resources related to control system security, including NIST and ISA 62443 standards. The Whole Building Design Guide site serves as the publication mechanism for DoD UFC's.

ASHRAE

The ASHRAE website has the following description of a new subcommittee under TC (Technical Committee) 1.5 Computer Applications: "TC 1.5 Cybersecurity Subcommittee was recently formed with the goals of increasing awareness of the importance of Cybersecurity and to provide guidance on issues relating to Cybersecurity." The technical committee website has links to a number of cyber security resources. A working group member who attends this subcommittee reports that the subcommittee is working to understand what the community needs.

TC 1.4, Control Theory and Application, put together a Guideline Project Committee (GPC) covering cyber security topics such as securing networks.

ASHRAE Technical Resource Group, TG2 HVAC Heating Ventilation and Air-Conditioning (HVAC) Security (originally TRG2.BCBR) covers HVAC security. It has a guideline considered out of date, which covers topics such as how to prevent terrorist chemical attacks through the HVAC system. The committee has not yet determined a going forward plan.

The UK organization CIBSE (Chartered Institution of Building Services Engineers) has approached TC 1.5 and TC 2, looking to collaborate in updating existing CIBSE guidance.

.

BACNET SECURITY FEATURES

BACnet is specifically designed for building automation and control network communications. It is maintained by ASHRAE. The protocol is defined in ANSI/ASHRAE Standard 135-2016 "BACnet - A Data Communication Protocol for Building Automation and Control Networks." The standard is under continuous maintenance by an ASHRAE Standing Standard Project Committee (SSPC). This is compared to other ASHRAE standards that are updated every four or five years.

NIST has been involved in the BACnet effort from the beginning. Government requirements and a NIST gap analysis were among the drivers for recent efforts to improve BACnet security.

"BACnet/IT Additions" have been released for public review in Addendum 135-2016bj to the BACnet standard. The addendum approach uses web socket communication, changing from a

https://www.wbdg.org/resources/cybersecurity.php

P a g e | 30




session less (UDP) model to a session-based model (TCP). This change enables the use of standard security techniques such as TLS to secure BACnet connections. Original BACnet was in clear text, unencrypted, and unauthenticated. BACnet/IT complements clause 24 of the current BACnet standard. The Clause 24 effort defined a security model that would apply to all transports in the standard. It did not achieve adoption.

MODBUS SECURE

Modbus.org is reviewing a draft version the Modbus Secure standard. Modbus Secure wraps the existing Modbus application layer in TLS and does not change the existing Modbus application layer protocol. Authorizations are supported by Modbus Secure. A Modbus device can supply roles or rights via a signed/issued certificate. These certificates are validated by a mutually trusted Certificate Authority. Modbus Secure is registered over TCP/UDP port 802 with IANA.

ELECTRIC SECTOR

BCS intersect with electric sector both in electric utility facilities and in smart buildings that employ intelligent end points of the smart grid.

National Electric Reliability Committee Critical Infrastructure Protection http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx

Compliance with NERC CIP is a regulatory requirement for portions of electric sector. Some BSC controllers are used in power plants. For this reason, they must conform to requirements derived from NERC CIP.

NRECA (National Rural Electric Cooperative) Guide to Developing a Cyber Security and Risk Mitigation Plan https://www.smartgrid.gov/files/CyberSecurityGuideforanElectricCooperativeV11-21.pdf This document contains extensive references to general NIST cyber security standards and guidance (those listed above in this document and others), as well as the NERC CIP regulatory standards. It also includes a section of development lifecycle guidance that discusses practices such as threat modeling, security requirements and testing, and deployment guidance. The lifecycle section references NISTIR 7628 Guidelines for Smart Grid Cybersecurity http://nvlpubs.nist.gov/nistpubs/ir/2014/NIST.IR.7628r1.pdf.

INTERNET OF THINGS

The Internet of Things (IoT) space overlaps with BCS, since IoT devices will in many cases enable "smart buildings."

The document NIST Special Publication 800-183 Networks of "Things" http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-183.pdf provides a conceptual framework for describing IoT networks, and outlines trust concepts. Details related to cyber security have not yet been addressed.

The document Industrial Internet Consortium: Industrial Internet of Things Volume G4: Security Framework https://www.iiconsortium.org/pdf/IIC_PUB_G4_V1.00_PB.pdf is not specifically targeted at BCS, though it might be applied for that purpose. Its stated purpose is to initiate a process to create broad

http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx

https://www.smartgrid.gov/files/CyberSecurityGuideforanElectricCooperativeV11-21.pdf

http://nvlpubs.nist.gov/nistpubs/ir/2014/NIST.IR.7628r1.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-183.pdf

https://www.iiconsortium.org/pdf/IIC_PUB_G4_V1.00_PB.pdf

P a g e | 31




industry consensus on how to secure Industrial Internet of Things (IIoT) systems." It includes detailed references to ISA 62443.

CYBER PHYSICAL SYSTEMS

The cyber physical systems (CPS) space overlaps with BCS, where the physical aspect of the CPS involves a built facility. The draft document Framework for Cyber Physical Systems https://s3.amazonaws.com/nist-sgcps/cpspwg/files/pwgglobal/CPS_PWG_Framework_for_Cyber_Physical_Systems_Release_1_0Final.pdf by the NIST-established Cyber Physical Systems Working Group includes a general discussion of security aspects and challenges for cyber physical systems. It lists ISA 62443 as a reference.

https://s3.amazonaws.com/nist-sgcps/cpspwg/files/pwgglobal/CPS_PWG_Framework_for_Cyber_Physical_Systems_Release_1_0Final.pdf



P a g e | 32




APPENDIX 6 - REVIEW OF IEC 62443 STANDARDS

This appendix describes major points of discussion during the BCS WG review of these IEC 62443 standards:

62443-1-1 Terminology, concepts and models Oct 29, 2007, published version

62443-3-3 System security requirements and security levels Aug 12, 2012, published version

62443-4-1 Secure product development life-cycle requirements Draft 3, Edit 11, March 2016 (ISA and IEC approved draft, download at http://isa99.isa.org/Public/Ballots/201603-ISA-62443-4-1/ISA-62443-4-1-CDV.pdf)

62443-4-2 Technical security requirements for IACS components Draft 2, Edit 4, July 2, 2015 (working draft, download at http://isa99.isa.org/Public/Documents/ISA-62443-4-2-WD.pdf )

IEC 62443-1-1

The group specifically expressed concurrence with the following general points in the published IEC 62443-1-1 standard:

Trends toward integration with IT infrastructure, connectivity and use of IT technology as described in 4.3 are occurring in the BCS industry.

Nature of risks The risks in 4.4. apply. The most likely risk due to BCS is disruption of the process and resulting disruption of building occupancy.

Primary importance of integrity over confidentiality as discussed in 5.2 is agreed. However, confidentiality may apply in more situations for BCS than for the industrial case. This is due to collection of information that can be related to individual’s occupants of a building. As an example, the US DoD has defined the concept of hybrid/converged systems, which will often contain protected information such as personally identifiable information (PII). Such a system has control elements and traditional IT elements, such as an Access control/alarm system that use badges/Common Access Cards and Active Directory for keyless entry. Convergence will create more communication between IEC 62443 security zones. Such information needs to be protected across zones.

Applicability of foundational requirements: These requirements are in 5.2.1. The group reviewed a more current version of the foundational requirements (FR's) as found in IEC 62443-3-3 (which will be rolled back into IEC 62443-1-1), as follows. The group agreed these requirements are all applicable to building control. No additional missing requirements at this level were identified.

o FR 1 – Identification and authentication control Identify and authenticate all users (humans, software processes and devices) before allowing them to access to the control system





P a g e | 33




o FR 2 – Use control Enforce the assigned privileges of an authenticated user (human, software process or device) to perform the requested action on the IACS and monitor the use of these privileges.

o FR 3 – System integrity Ensure the integrity of the IACS to prevent unauthorized manipulation.

o FR 4 – Data confidentiality Ensure the confidentiality of information on communication channels and in data repositories to prevent unauthorized disclosure.

o FR 5 – Restricted data flow Segment the control system via zones and conduits to limit the unnecessary flow of data.

o FR 6 – Timely response to events Respond to security violations by notifying the proper authority, reporting needed evidence of the violation and taking timely corrective action when incidents are discovered.

o FR 7 – Resource availability Ensure the availability of the control system against the degradation or denial of essential services.

The group observed regarding FR 5 Restricted data flow, that an organization that supplies BCS products, would in most cases not have control of the network upon which products were placed, or of related devices such as firewalls. It was explained that IEC 62443 accounts for this. In particular, the overall IEC 62443 series (in other parts of the standard than those reviewed by the WG) defines requirements not only for product developers, but also for asset owners and system integrators, who often take responsibility for overall network architecture. Nevertheless, a BCS product supplier would need to make assumptions regarding this architecture in order to create a threat model as required by IEC 62443-4-1.

Related to FR 6 Timely response to events, the group pointed out that organizations such as hospitals, DoD, etc., have different requirements about reporting and corrective action. It was explained that from point of view of a product developer, FR 6 becomes requirements about logging, that are enhanced at higher security levels.

General risk management: Material in 5.3-5.7 and 5.11 regarding risk management was agreed to be independent of a specific domain and generally applicable, including for BCS.

Security zone and security level concepts: The group agreed that the concepts of security zone and security level apply for BCS. However, such decomposition is not a practiced nor familiar concept, and would therefore require significant education in the industry. Examples the group cited for higher security zones were a high security lab inside a building, and fire safety systems. There is familiarity in the industry with an ASHRAE four tier model, an example of which can be found in this report in "Appendix 10 - IEC 62443 and BCS Architectures." The ASHRAE model is similar to the 5 level IEC 62443 reference model (Figure 12 IEC 62443-1-1, presented also in the Appendix). In both cases, the tiers are related to functionality, and not necessarily to security level.

Conduit concept: Likewise, the group agreed that the concept of conduit applied for BCS. It was however not a commonly used term in the BCS industry. There is no known equivalent term that is familiar, though the related terms "backbone" and "network segmentation" were more familiar and may be used to fashion an explanation for the BCS industry.

P a g e | 34




The following discussion points add information about applicability to BCS, that may improve the presentation in the IEC 62443-1-1 standard as it relates to BCS. The comments do not indicate inapplicability or inaccuracy of the existing standard.

Terminology "industrial" and "embedded device"- In the Introduction clause, building environmental control systems are explicitly called out as an example of industrial automation and control systems. However, “industrial" is an unusual term to use related to BCS. Possibly "industrial or commercial" may be more appropriate. Another term coming into common use that could be considered for use in the standard is "cyber physical systems." This would cover additional areas medical and transportation. Other related potential modifications to definitions in the document could be:

o industrial automation and control system (IACS) - collection of personnel, hardware, software and policies involved in the operation of the commercial or industrial process and that can affect or influence its safe, secure, and reliable operation

o embedded device - special purpose device running embedded software designed to directly monitor, control or actuate a commercial or industrial process

The term "embedded device" is not generally familiar in the BCS industry, where these devices are called "controllers" or "sensors." Achieving a common understanding of terminology occupied several working group meetings. It was felt that individuals in the BCS industry would better grasp the relevance of the standard, if they first saw a mapping of terminology in the standard to more familiar BCS concepts.

Responsiveness: Third paragraph of 5.2, whereas it is true that in general control systems can have response requirements in the 1 millisecond range, BCS response requirements are generally closer to traditional business systems, ranging from 1 second to a half hour.

Risks: All risks listed in 5.5.3 were felt to apply for BCS. It was understood that the list was examples and not intended to be complete. One additional example typical for BCS is the risk to contents of a building, such as an art museum or library.

Security zone diagrams: Existing architecture diagrams in 6.4 depicting security zones are specific to industrial examples. Additional examples for BCS could be added to the standard or described separately, such as in a TR (Technical Report). In this document, "Appendix 10 - IEC 62443 and BCS Architectures" contains some example BCS architecture diagrams and compares them to the IEC 62443 reference model.

IEC 62443-3-3 AND IEC 62443-4-2

The two documents IEC 62443-3-3 and IEC 62443-4-2 are treated together because most of the requirements are very similar and their requirement numbers correspond. This is because ISA 624443-4-2 component requirements are derived from corresponding IEC 62443-3-3 system requirements.

P a g e | 35




Derived requirements: Derived requirements under the following FRs were felt to be applicable to BCS after clarifying discussion in a few cases, without further comment by the group.

o FR 5 – Restricted data flow o FR 7 – Resource availability

The group offered the following additional information about timestamps for BCS under FR 2:

Timestamps - integrity of timestamps per SR/CR 2.11 was important for some applications such as energy monitoring, where costs for energy are different at different times. Careful time synchronization across a system was likely not needed in most cases for BCS since events happen in a time frame of "seconds" or longer.

Several requirements in the IEC 62443-3-3 and IEC 62443-4-2 standards, although agreed to be

applicable for many BCS, were questioned by members as requirements to apply across all BCS embedded devices. These were:

Under FR 1: Identification and authentication control, regarding the "capability to enforce configurable password strength based on minimum length and a variety of character types," it was asked, what is good enough to meet this requirement (which applies at all levels)? It was questioned for simple devices such as a thermostat controller that simply require a short PIN for some functions.

Under FR 2: Use control, examples of derived requirements felt to be inapplicable in some cases were maintaining of audit records, due to space and processing limitations in some devices (SR/CR 2.9), and non-repudiation of human users (SR/CR 2.12). It was pointed out that these requirements pass under EDSA certification if they are allocatable. ("Allocatable" means that the device does not preclude compensating controls external to the device that satisfy the requirement.) Under SR/CR 2.8 Auditable events, members observed that "simple devices" such as relays, thermostat controllers, sensors and other similar devices would not create audit records.

Under FR 3: System integrity, SR/CR 3.1 regarding protecting integrity of transmitted information - it was noted that very few BCS applications use encryption due to the fact that it lowers the speed of communications. It was noted that encryption is moving into hardware, which will address this limitation. Further, other integrity mechanisms such as CRC's, although not as strong as encryption, also could be used to meet this requirement.

Under FR 3: System integrity, SR/CR 3.4 regarding integrity checks on software, configuration and other information - this was seen as applicable at the higher supervisory level but not common at the controller level. Other members offered examples which indicated that the feature is migrating to these lower levels.

Under FR 4: Data confidentiality, it was observed that SR/CR 4.2, which requires the capability to purge access controlled information from devices when out of service, did not seem as critical as the other requirements, except in the case of the DoD.

Under FR 6 Timely response to event, the requirement SR/CR 6.2 "Capability to continuously monitor all security mechanism performance using commonly accepted security industry practices and recommendations..." was felt to be beyond what was being done in most cases today in building control systems.

P a g e | 36




IEC 62443-4-1

Many security development lifecycle practices described in the IEC 62443-4-1 standard were currently performed by several supplier members of the group. Specifically mentioned were threat modeling under Practice 2 and static code analysis under Practice 4. Requirements under Practice 6 Security Defect Management were felt to be straightforward.

It was generally agreed that the standard defined current good practices. The following would be most challenging for BCS suppliers:

Finding trained individuals per SM-4, capable of performing tasks that require a whole building perspective, such as threat modeling related to BCS components. This expertise is currently rare in the industry.

Meeting assurance requirements for third party components in SM-8 and SM-9, specifically for inexpensive components with limited functionality.

P a g e | 37




APPENDIX 7 - OVERVIEW OF ISASECURE CERTIFICATIONS

All ISASecure specifications are publicly available at www.isasecure.org. The documents EDSA-100, SSA-100 and SDLA-100 describe at a high level, the ISASecure EDSA, SSA, and SDLA certifications, respectively. These 100-series documents also list all of the further detailed documents that together fully define certification requirements and procedures, and describe the content and audience for each document. The 300-series documents EDSA-300, SSA-300, and SDLA-300 explicitly define pass/fail criteria for each certification.

ISCI designs the certification programs and defines certification requirements. Third parties that meet program accreditation requirements (found in the 200-series documents) may perform certifications.

The following figures extracted from EDSA-300 and SSA-300 provide an overview of the elements of EDSA and SSA product certifications, for embedded devices and systems, respectively.

Figure 3 Evaluation Elements for ISASecure EDSA Certification

Embedded Device Security

Assessment (EDSA)

Security Development Lifecycle

Process Assessment (SDLPA)

Security Development Artifacts

for Embedded Devices (SDA-E)

Ensures Fundamental Security Features are Supportable by

Device

• A device’s security functionality is audited against defined

requirements by security level

• Functionality not directly supported by the device must be

allocatable to other components in its architectural environment

Identifies Vulnerabilities in Actual Implementation

• Vulnerability Identification Testing (VIT) - scan identifies known

vulnerabilities

• Communication Robustness Testing (CRT) – show device

maintains essential functions when subjected to erroneous

protocol traffic, high traffic rates

Ensures Security Was Designed-In and Can Be Maintained

• SDLPA audits the supplier’s development and maintenance

processes for security practices

• SDA-E ensures a device was developed following a robust,

secure development process by examining development

artifacts

Functional Security

Assessment for Embedded

Devices (FSA-E )

Embedded Device

Robustness Testing (ERT)

P a g e | 38




Figure 4 Evaluation Elements for ISASecure SSA Certification

P a g e | 39




APPENDIX 8 - REVIEW OF ISASECURE CERTIFICATIONS

This appendix describes major points of discussion from the BCS working group's review of the ISASecure certifications EDSA, SSA, and SDLA. For reference, figures from the ISASecure specifications that depict the elements of these certifications are replicated in this document in "Appendix 7 - Overview of ISASecure Certifications." The most significant details are issues found with CRT, which is used for both EDSA and SSA.

SECURITY DEVELOPMENT LIFECYCLE

The requirements for the SDLPA and SDA portions of the EDSA and SSA certifications were considered to be covered, through the group's review of IEC 62443-4-1. This is because ISASecure SDLA-312 will in a few months align with this standard as approved. No major technical issues were identified. Likewise, no issues were raised regarding the SDLA certification in discussions of administrative aspects of the certification such as expiration time interval.

FUNCTIONAL SECURITY ASSESSMENT

The group reviewed specifically the current EDSA certification level 1 requirements that cannot pass certification by being assessed as "allocatable," as distinguished from the requirements under level 1 that may be allocated to external components. ("Allocatable" means that the device does not preclude compensating controls external to the device that satisfy the requirement.) These requirements are replicated in this document for reference in "Appendix 9 - Level 1 EDSA FSA Requirements Not Allocatable". The group did not feel that any of the requirements could be dropped from the minimum "not allocatable" set.

A specific issue was raised regarding the backup/restore requirements in this set. It was asked if some low cost devices with minimal configuration could meet the EDSA backup/restore requirements by simple physical replacement of the device. As long as this strategy was documented for the user, it was felt to be a valid method for meeting the backup/restore requirements in the most recent draft of ISA 62443-4-2. Therefore, this is expected to suffice for EDSA certification, once EDSA FSA has been aligned with the standard.

Review of requirements at other certification levels was not felt to be useful at this time, since a revision to align with an approved IEC 62443-4-2 is expected to modify the certification in the relative near term.

The SSA FSA requirements were not explicitly reviewed, but they were noted to be aligned with the approved IEC 62443-3-3, which was reviewed by the group.

ROBUSTNESS TESTING

The group felt that fuzz testing and flood testing which comprise CRT, and VIT (Vulnerability Identification Testing, a Nessus scan) were reasonable as part of the minimum requirements for a BCS security product certification. However, the group questioned in general the benefit of the credential scan currently performed as part of VIT. CRT and VIT are sub elements for embedded device robustness testing (ERT) and system robustness testing (SRT) under EDSA and SSA certifications, respectively.

P a g e | 40




Since the test criteria for CRT assurance of maintenance of upward essential functions (e.g. view, alarms) are custom-designed for each product certification, this was expected to work for BCS. The test criteria for control functions (downward essential functions) were judged however unlikely to fit for BCS in many cases, for the following reasons:

Devices not always fully programmable and lower-frequency: The fixed digital and analog control signals currently specified in the specification EDSA-310 (Requirement ERT.R30) for EDSA ERT testing of the control essential function, cannot be created by some BCS embedded devices. The reasons are because (1) the device cannot be fully programmed, since it is a fixed function device or has limited configurability or (2) the range of cycle times over which BCS controllers operate is very wide, ranging from a second to a half hour, hence it may not be able to create a signal that changes every second.

Diverse control functionality: Further, the specification of any single signal to test for all BCS controllers will likely not be feasible to cover the BCS range of capability. A signal would need to be selected based upon the function of the controller.

Relevance of jitter not obvious: EDSA ERT tests use excessive jitter as a pass/fail criterion when testing the control capability. Jitter as a concept is not familiar in the BCS space. Jitter is not judged to be relevant to the time frames in which BCS controllers typically operate. It will not be clear to BCS end users how this test criterion is related to their requirements.

Cannot monitor control signal: In some cases, there is no interface to a BCS embedded device, via which a test function could monitor the BCS control signal. This signal in these cases is internal to a product that includes both the controller and the entity being controlled.

Test time and test impact time: EDSA CRT tests for flooding, run for 2 minutes. For many BCS controllers, it will not be feasible to observe test impact in this time frame, whether for control or other essential functions.

This group could not under its present scope develop a detailed revised specification, but members felt confident that this could be done. Some general ideas were discussed. Under various input conditions, a device would either go to a "fail safe mode" where the control signal wasn't changing, or it would continue its operation based upon the usual algorithms, considering its inputs. The inputs could be set up so that particular changes should be detected if the device continued operation and did not go into a failsafe mode. A sequence of input conditions to be tested would be part of the test definition. Perhaps the contents of internal logs could help for defining test criteria.

P a g e | 41




APPENDIX 9 - LEVEL 1 EDSA FSA REQUIREMENTS NOT ALL OCATABLE

Repeated here from the ISCI document EDSA-311 v1.4 for convenience of reference, are certification requirements from the Functionality Security Assessment element of EDSA 2.0.0 certification, that apply at level 1 (and all higher certification levels) and must be directly supported by the device. In other words, an assessment of “allocatable" is not an option for meeting these requirements under the certification. "Allocatable" means that the device does not preclude compensating controls external to the device that satisfy the requirement.

• FSA-AC-2.1.9 Clear Text Password: The IACS embedded device shall not internally store or send password over shared networks in clear text format.

• FSA-AC-2.1.11 Access Control for All Exposed Service: The IACS embedded device user authentication shall cover access to all services supported by the device during normal operation. Clarification added: “All services should either be secured by access control or able to be disabled for normal operation (services that must be disabled also need to be documented for the user).”

• FSA-UC-1.1 Physical Disable Wireless Access: IACS embedded products that provide wireless access must provide the option to be physically disabled by the end user of the product by a method unable to be overridden by SW or user soft configuration

• FSA-NRA-1.2 Protocol Fuzzing Protection: The IACS embedded device communications shall be tolerant to standard protocol fuzzing attacks for protocols supported by the device

• FSA-NRA-1.3 Deterministic Loss of Communication: The IACS embedded device communications shall provide documented or configurable default states for IO and other transmitted variables to be applied upon loss of communications

• FSA-NRA-1.5 Preservation of Essential Services: The IACS embedded device communications shall be able to maintain essential services under flooding attack, as defined in robustness testing specification

• FSA-NRA-2 IACS Backup: The IACS embedded device or its support utilities shall provide user functionality to facilitate creation of backups of user-level and system-level information (including system security state information) contained in the IACS

• FSA-NRA-3 IACS Recovery: The IACS embedded device shall provide user functionality to allow the IACS to be recovered and reconstituted to previously saved IACS Backup after a disruption or failure

P a g e | 42




APPENDIX 10 - IEC 62443 AND BCS ARCHITECTURES

SUMMARY COMPARISON OF BCS ARCHITECTURE MODELS TO ISA REFERENCE MODEL

In summary, BCS architecture figures provided by the working group and presented below in this Appendix, have the following commonalities with the ISA reference model also shown below. All have a tiered architecture with equipment, sensors and actuators at lower tiers, enterprise systems at the highest tier, and control functions in between. The BCS architecture models that the group discussed do not explicitly distinguish operations management from supervisory control, which are ISA reference model architecture levels 2 and 3. However, the BCS models do distinguish two layers of control, corresponding to ISA architecture levels 1 and 2.

The following reference figure for control systems is from IEC 62443-1-1:

Figure 5 Reference Architecture for IEC 62443 from IEC 62443-1-1

However, no issues arose with the IEC 62443 requirements reviewed, that were due to a distinction, or lack of distinction, between ISA architecture levels 2 and 3. The terms "operations management" and "supervisory control" that name these architecture levels, do not appear in the IEC 62443 standards reviewed.

The following sub sections review for correspondence with the IEC 62443 reference model, two detailed architecture diagrams below from the BCS community.

BUILDING CONTROL TIERS ARCHITECTURE DIAGRAM

Ron Bernstein offered the following architecture diagram for group reference, as an example following the ASHRAE four-tier architecture.

P a g e | 43




Figure 6 Building Automation System Tier Architecture

There are four levels identified, vs. five in the IEC 62443 reference model. Numbering order is reversed from the IEC 62443-1-1 numbering. Both models show the Enterprise at the highest level. Building Level in Figure 6 appears to correspond to both operations management and supervisory control in the ISA reference model. Equipment Level in the BCS diagram appears to correspond to Basic Control in the ISA reference model. In Figure 6, sensors and actuators are at the lowest level, and equipment at the next level up, whereas the ISA reference model shows equipment at the lowest level.

DOD FACILITY-RELATED CONTROL SYSTEM ARCHITECTURE

The following general control system architecture is used in the US DoD document UFC 4-010-06 Unified Facilities Criteria - Cyber Security of Facility-Related Control Systems. A working group member stated it had been developed based on IEC 62443 figures. The term PIT (Platform IT) used in the figure, is a DoD term, used to describe the category of IT hardware and software that is physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems.

P a g e | 44




Figure 7 Control System Architecture Diagram from UFC 4-010-06

Sensors and actuators in the IEC 62443 model and in the UFC model are in lowest layer 0. Level 1 in the ISA reference model is Basic Control and Safety and Protection. In the UFC model, Levels 1 and 2 distinguish IP and non-IP equipment with these functions. In the UFC model, the connection to higher level control in Level 4 is distinguished as Level 3. These two levels appear to correspond to both Operations Management and Supervisory Control in the IEC 62443 reference model. A separate level has been added to the UFC model for the boundary of the system authorized under US DoD procedures to operate, and for software, network, and security management for all of the levels.

P a g e | 45




APPENDIX 11 - ACRONYMS

AHU Air Handling Unit ASHRAE American Society of Heating, Refrigerating and Air-Conditioning Engineers APL Approved Product List ARP Address Resolution Protocol ASA Application Security Assurance BACS Building Automation and Control System BACnet Building Automation Control network BCS Building Control System(s) CABA Continental Automated Buildings Association CCTV Closed Circuit Television CIBSE Chartered Institution of Building Services Engineers CIP Critical Infrastructure Protection COTS Commercial Off-The-Shelf CPS Cyber Physical Systems CR Component Requirement CRAC Computer Room Air Conditioning CRT Communication Robustness Testing DISA Defense Information Systems Agency DDoS Distributed Denial of Service DoD Department of Defense DoDI Department of Defense Instruction EDSA Embedded Device Security Assurance ERT Embedded Device Robustness Testing FIPS Federal Information Processing Standard FR Foundational Requirements FSA Functional Security Assessment FSA-E Functional Security Assessment for Embedded Devices FSA-S Functional Security Assessment for Systems GPC Guideline Project Committee HVAC Heating, Ventilation and Air Conditioning IACS Industrial Automation and Control System ICMPv4 Internet Control Message Protocol version 4 IEC International Electrotechnical Commission IoT Internet of Things IP Internet Protocol IPv4 Internet Protocol version 4 ISA International Society of Automation ICS Industrial Control System IIoT Industrial Internet of Things ISC Interagency Security Committee ISCI ISA Security Compliance Institute IO Input/Output IT Information Technology NCWF NICE Cybersecurity Workforce Framework NERC North American Electric Reliability Corporation NICE National Initiative for Cybersecurity Education NIST National Institute of Standards and Technology NIST IR NIST Interagency Report

P a g e | 46




NRECA National Rural Electric Cooperative NST Network Stress Testing OA Outside Air OT Operational Technology OWASP Open Web Application Security Project PII Personally Identifiable Information PIV Personal Identity Verification PIT Platform IT RA Return Air RTU Remote Terminal Unit SDA Security Development Artifacts SDA-E Security Development Artifacts for Embedded Devices SDA-S Security Development Artifacts for Systems SDL Security Development Lifecycle SDLA Security Development Lifecycle Assurance SDLPA Security Development Lifecycle Process Assessment SP Special Publication SR System Requirement SRT System Robustness Testing SM Security Management SSA System Security Assurance SW Software TC Technical Committee TCP Transmission Control Protocol

TLS Transport Layer Security

TG Task Group UDP User Datagram Protocol

UFC Unified Facilities Criteria US United States VAV Variable Air Volume VFD Variable Frequency Drive VIT Vulnerability Identification Test WG Working Group

P a g e | 47




Contact Information

Andre Ristaino

Managing Director, ASCI

67 T.W. Alexander Drive

Research Triangle Park, NC 27709

[email protected]

mailto:[email protected]