PART 4: TECHNICAL SECURITY REQUIREMENTS FOR AN INDUSTRIAL AUTOMATION AND CONTROL SYSTEMS

Transcription

1 PART 4: TECHNICAL SECURITY REQUIREMENTS FOR AN INDUSTRIAL AUTOMATION AND CONTROL SYSTEMS Draft Edit THIS DRAFT VERSION IS STRICTLY FOR REVIEW BY ISA SP99 MEMBERS ONLY This document is a work product of the ISA SP 99 committee. It IS NOT part of any draft standard or technical report. Copies may be shared for purposes related to the operation of the SP 99 committee, but all copies must reproduce a copyright notice as follows: Copyright 2008 ISA. All rights reserved. Reproduced and distributed with permission of ISA. The reader is cautioned that this document has not been approved and cannot be presumed to reflect the position of ISA or any other committee, society, or group. Although every effort has been made to ensure accuracy, neither ISA, members of the S&P Department, nor their employers shall be held liable for errors or limitations. 2

2

3 Forward... v The ISA99 series... vi Relationships of the ISA99 standards to the ISA 99 technical reports... vi Introduction...vii Scope... 8 References... 8 Definitions of terms and acronyms... 8 Definition of terms...8 Definition of acronyms...9 Threat assessment and security policy... 0 Threat assessment vectors...0 Building a chain of trust...0 Identification of trusted and untrusted components... Security considerations for industrial automation and control systems... 2 Two perspectives: IT and Control System Operation...2 Technology roadmaps...4 Catalog of sources...5 Standards, recommended practices and guidelines...5 Security assurance... 6 Security foundational requirements... 7 Access control...7 Use control...7 Data integrity...7 Data confidentiality...8 Restrict data flow...8 Timely response to event...8 Network resource availability...8 SP99 Part 4 Draft Edit Word format.doc Page i

4 Derived requirements for effective security... 9 Protection of data at rest...9 Security of the industrial control network...22 Field communications and field device Security...43 Automation cell security...52 Control Network Host security...57 Interactive remote access security...72 Enterprise network / Control network interconnection security...99 Inter control center security...20 Annex A: Bibliography Annex B: System dynamics Managing Complexity The cyber space problem domain...32 The need to account for time and event dynamics...33 Be wary of more security is better...33 Annex C: Human behavior response to security Dynamic triggers...35 Beware of defense in depth...37 Impact of excessive security...38 Privacy issues...39 Fact or fiction the need for validation...40 Annex D: Guidance for using ISA Annex E: Field Communication and Devices Monitoring and control paradigms for automation systems...48 Needs for industrial device to device field communications...49 Patterns of industrial field communications use...5 Usage classes of industrial device to device field communications...53 SP99 Part 4 Draft Edit Word format.doc Page ii

5 2 TABLE OF FIGURES Figure Typical automation cell network configuration...53 Figure 2 Notional IRA reference topology...73 Figure 3 Notional ECI reference topology...00 Figure 4 Notional inter control center Network topology...22 Figure 6 Notional degradation of security assurance...33 Figure 7 Dynamic trigger hypothesis...36 Figure 8 Enabling Defense in Depth...37 Figure 9 The consequences of implementing security measures...38 Figure 0 Impact of excess security...39 Figure SmartCard for DiD TABLE OF TABLES Table Summary of IT and control system differences...2 Table 2 Data at Rest security requirements...20 Table 3 Malware, virus and Trojan security protection requirements...2 Table 4 Identity and access management Security requirements...24 Table 5 Confidentiality, integrity and availability security requirements...25 Table 6 Defense in Depth security requirements...26 Table 7 Network routing device hardening security requirements...29 Table 8 Field communication and field device security requirements...46 Table 9 Automation cell interconnection security requirements...53 Table 0 Control network host security requirements...58 Table IRA Network topology security s...76 SP99 Part 4 Draft Edit Word format.doc Page iii

6 Table 2 IRA Data flow security requirements...84 Table 3 IRA security component security requirements...88 Table 4 IRA operations security requirements...94 Table 5 IRA security policy requirements...98 Table 6 ECI network topology security requirements...02 Table 7 ECI data flow security requirements...09 Table 8 ECI security component requirements...2 Table 9 ECI operations security requirements...4 Table 20 ECI security policy requirements...20 Table 2 ICC network topology security requirements...24 Table 22 ICC data flow security requirements...26 Table 23 icc operations security requirements...26 Table 24 ICC policy security requirements...28 Table 25 Applicable requirements of ISA for users...42 Table 26 Field communications and device usage classes...45 Table 27 Cost considerations...45 Table 28 Availability and performance considerations...46 Table 29 Compatibility and scalability considerations...46 Table 30 Quality of service considerations...47 Table 3 Security considerations SP99 Part 4 Draft Edit Word format.doc Page iv

7 FORWARD This is the fourth in a series of ISA standards that addresses the subject of security for industrial automation and control systems. The focus is on the electronic security of these systems, commonly referred to as cyber security. This Part 4 standard defines the characteristics of industrial automation and control systems that differentiate them from other information technology systems from a security point of view. Based on these characteristics, the standard establishes the security requirements that are unique to this class of systems. This standard is structured to follow ISO/IEC directives part 2 for standards development as closely as possible. An introduction before the first numbered clause describes the range of coverage the entire series of standards. It defines industrial automation and control systems and provides various criteria to determine whether a particular item is included in the scope of the standards. Clause defines the scope of this standard. Clause 2 lists normative references that are incorporated as part of this standard because they are indispensable for the application of the document. Clause 3 is a list of terms and definitions used in this standard. Most are drawn from established references, but some are derived for the purpose of this standard. Clause 4 summarizes an informative description of threats and policy that provides the context for evaluating security options specified in this standard. Clause 5 provides an informative description of the situation with respect to the security of industrial automation and control systems that form the context for specifying the foundational and derived requirements in the normative clauses of this standard. Clause 6 specifies the normative procedure to model and calculate security assurance levels. Clause 7 specifies the normative foundational requirements for secure industrial automation and control systems Clause 8 specifies the normative security requirements to effectively implement, commission, maintain and manage security for industrial and automation enterprises. Part 4 annexes are included to provide informative explanations of the background and rational used to develop the normative requirements of this standard. The first annex is a bibliography of works cited in this standard. Annex D: Guidance for using ISA maps the normative requirements to expected audience interest. SP99 Part 4 Draft Edit Word format.doc Page v

8 THE ISA99 SERIES Standards in the ISA99 series address all aspects of security for industrial automation and control systems. The series is organized by parts described below. ISA Part : Terminology, Concepts and Models Part establishes the context for all of the remaining standards in the series by defining a common set of terminology, concepts and models for electronic security in the industrial automation and control systems environment. ISA Part 2: Establishing an Industrial Automation and Control System Security Program Part 2 describes the elements of a cyber security management system and provide guidance for their application to industrial automation and control systems. ISA Part 3: Operating an Industrial Automation and Control System Security Program Part 3 address how to operate a security program after it is designed and implemented. This includes definition and application of metrics to measure program effectiveness. 3 ANSI/ISA Copyright 2007 ISA. All rights reserved. ISA Part 4: Technical Security s for Industrial Automation and Control Systems Part 4 defines the characteristics of industrial automation and control systems that differentiate them from other information technology systems from a security point of view. Based on these characteristics, the standard will establish the security requirements that are unique to this class of systems RELATIONSHIPS OF THE ISA99 STANDARDS TO THE ISA 99 TECHNICAL REPORTS Two technical reports produced by the ISA99 committee on the subject of electronic security within the industrial automation and control systems environment were used as a guideline for this standard. ANSI/ISA TR Technologies for Protecting Manufacturing and Control Systems Technical Report, updated from the original 2004 version, describes various security technologies in terms of their applicability for use with industrial automation and control systems. This technical report will be updated periodically to reflect changes in technology. ANSI/ISA TR Integrating Electronic Security into the Manufacturing and Control Systems Environment Technical Report 2 describes how electronic security can be integrated into industrial automation and control systems. The contents of this technical report is superseded with by the Part 2 standard. SP99 Part 4 Draft Edit Word format.doc Page vi

9 INTRODUCTION The subject of this standard is security for industrial automation and control systems. In order to address a range of applications (i.e., industry types), each of the terms in this description have been interpreted very broadly. The term industrial automation and control systems (IACS) includes control systems used in manufacturing and processing plants and facilities, building environmental control systems, geographically dispersed operations such as utilities (i.e., electricity, gas, and water), pipelines and petroleum production and distribution facilities, and other industries and applications such as transportation networks, that use automated or remotely controlled or monitored assets. The term security is considered here to mean the prevention of illegal or unwanted penetration, intentional or unintentional interference with the proper and intended operation, or inappropriate access to confidential information in industrial automation and control systems. Electronic security, the particular focus of this standard, includes computers, networks, operating systems, applications and other programmable configurable components of the system. The audience for this standard includes all users of industrial automation and control systems (including facility operations, maintenance, engineering, and corporate components of user organizations), manufacturers, suppliers, government organizations involved with, or affected by, control system cyber security, control system practitioners, and security practitioners. Because mutual understanding and cooperation between information technology (IT) and operations, engineering, and manufacturing organizations is important for the overall success of any security initiative, this standard is also a reference for those responsible for the integration of industrial automation and control systems and enterprise networks. Annex D: Guidance for using ISA provides a user s guide of applicable security requirements. Typical questions addressed by this Part 4 standard include: How does one establish a quantitative security assurance level for the industrial automation and control system, and allocate security assurance to subsystems and components? What enabling technologies and technical considerations contribute to cost effective security? What security requirements are derived from the foundational requirements outlined in Part? What is the interaction or coupling between derived security requirements allocated to the zones and conduits of the industrial automation and control system, and how are these allocations constrained by operational procedures, availability and performance? SP99 Part 4 Draft Edit Word format.doc Page vii

10 SCOPE ISA (Part 4) defines the normative technical security requirements to achieve an asset owner s target security assurance level (SAL) for an Industrial Automation and Control System (IACS). The system includes all personnel, hardware and software used to ensure safe, secure and reliable operation of an industrial process. These systems include, but are not limited to: Distributed control systems (DCS), programmable logic controllers (PLC), remote terminal units (RTU), intelligent electronic devices (IED), supervisory control and data acquisition (SCADA), measurement units, monitoring units, and diagnostic systems. Process control systems (PCS) include safety instrumented system (SIS) functions that are separate units or embedded in process control devices. Associated information systems such as advanced or multivariable control, online optimizers, dedicated equipment monitors, graphical interfaces, historians, manufacturing execution systems and plant information management systems. Associated human, network or machine interfaces used to provide control, safety and manufacturing operations for continuous, batch, discrete and other processes REFERENCES [] ISA Part : Terminology, Concepts and Models [2] ISA Part 2: Establishing an Industrial Automation and Control System Security Program [3] ISA Part 3: Operating an Industrial Automation and Control System Security Program 20 2 DEFINITIONS OF TERMS AND ACRONYMS DEFINITION OF TERMS 3... Access authority entity responsible for monitoring and granting access privileges to IACSs and their associated industrial networks for other authorized entities Access control a) protection of system resources against unauthorized access b) process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy SP99 Part 4 Draft Edit Word format.doc Page 8

11 accountability property of a system (including all of its system resources) that ensures that the actions of a system entity may be traced uniquely to that entity, which can be held responsible for its actions application layer protocol layer 7 protocol specific to executing network applications such as and file transfer Note: Many modern industrial control systems include fieldbus networks, which do not normally include seven distinct layers, but do have an application layer authentication a process that establishes the origin of information, or validates an entity s identity Authorization Access privileges granted to an entity; conveys an official sanction to perform a security function or activity availability timely, reliable access to information by authorized entities tamper evident a device or process that makes unauthorized access to the protected object easily detected. This may take the form of seals, markings or other techniques tamper resistant resistance to tampering by either the normal users of a product, package, or system or others with physical access to it tamper response providing sensors to detect tampering and associated response mechanisms {More coming in a later draft waiting on maturity} 33 DEFINITION OF ACRONYMS 34 {TBS in a later draft waiting on maturity} SP99 Part 4 Draft Edit Word format.doc Page 9

12 THREAT ASSESSMENT AND SECURITY POLICY Threat assessment and security policy must be in place to provide a proper frame work for considering array of security options that could be deployed. This informative clause provides a brief review of the threat assessment vectors, the need to build a chain of trust, and the identification of trusted and untrusted components THREAT ASSESSMENT VECTORS Threat assessment vectors are derived from an understanding of the threat, the chain of trust, identification of trusted and untrusted components and the security vulnerabilities of the terminal devices. ISA [2] addresses the need to understand the threats and to put in place an effective security program. Those requirements are incorporated by normative reference into the considerations offered by ISA BUILDING A CHAIN OF TRUST Building a chain of trust between terminal devices, network devices and process control IEDs that have access to process control data is critical. In fact, it s often more important to authenticate the terminal device access the control network or process control IED that the people using them. This is particularly true in applications where companies need to trust the computers used to change operational settings or update programs that control production functions within a specific IED or subsystem. The ability to trust the computers managing the process control data or accessing the control networks is vital. Thais can be complicated by the fact that multiple vendors may have legitimate need to access these networks and devices. Software only implementations are inadequate particularly where the incentive to attack is high. Software only solutions often require considerable expense to develop and implement. But because the code, encryption algorithms and keys are exposed, they can be relatively easy to attack and clone especially with the many reverse engineering tools that are readily available for downloading on the Internet. For example, within a terminal device it becomes essential to isolate the security critical processing from the rest of the application. Through the physical interfaces where commands and data are delivered to and from the terminal device, an adversary will attempt to exploit system implementation flaws. Once a vulnerability is found, security components that are not isolated become susceptible to attack. To provide privacy, authentication, and non repudiation, security must include a combination of hardware and software. Even if an adversary can reverse engineer a portion of software to which he has access, he still doesn t have enough insight into what is going on in the hardware. SP99 Part 4 Draft Edit Word format.doc Page 0

13 ENTIFICATION OF TRUSTED AND UNTRUSTED COMPONENTS Control networks defined by conduits and routing devices (routers, switches, wireless access points) are trusted networks if their security requirement sets are implemented. Components attached to the control networks are trusted if their requirement sets are implemented. However, if the requirement sets for the attached components are not implemented, or if a security event occurs, the terminal device, network device or process control IED should include security mechanisms to provide another level of defense in depth. SP99 Part 4 Draft Edit Word format.doc Page

14 2 SECURITY CONSERATIONS FOR INDUSTRIAL AUTOMATION AND 3 CONTROL SYSTEMS Many sources were considered to develop the prescriptive security recommendations and guidelines for industrial automation and control systems. These sources include standards developed by other recognized organizations, reports by US national laboratories and roadmaps developed by US government and other country government organizations or consortiums. This informative clause summarizes the contribution of these sources TWO PERSPECTIVES: IT AND CONTROL SYSTEM OPERATION It is important to understand the differences of two perspectives of security: the perspective of the IT organization and the perspective of the process control system operations. Kim Fenrich (Fenrich, Kim; February 2008) summarized these differences in a very succinct table. The differences shown in Table are amplified in both the informative and normative clauses of this standard. TABLE SUMMARY OF IT AND CONTROL SYSTEM DIFFERENCES Category Information Technology System Industrial Control System Performance requirements Availability requirements Risk management requirements Non real time. Response must be consistent. High throughput required. High delay and jitter maybe acceptable Responses such as rebooting are acceptable. Availability deficiencies can often be tolerated, depending on the system s operational requirements. Data confidentiality and integrity are paramount. Fault tolerance is less important; momentary downtime is not a major risk. Major risk impact is day of business operation. Real time response is timecritical. Modest throughput is acceptable. High delay and/or jitter is a serious concern. Responses such as rebooting may not be acceptable because of process availability requirements. Outages must be planned and scheduled days/weeks in advance. High availability requires exhaustive pre deployment testing. Human safety is paramount, followed by protection of the process. Fault tolerance is essential, even momentary downtime is not acceptable. Major impact is regulatory noncompliance, loss of life, equipment or production. SP99 Part 4 Draft Edit Word format.doc Page 2

15 Category Information Technology System Industrial Control System Architecture security focus Unintended consequences Time critical interaction System operation Resource constraints Communications Primary focus is protecting the IT assets and the information stored on or transmitted among these assets. Security solutions are designed around typical IT systems. Less critical emergency interaction. Tightly restricted access control can be implemented to the degree necessary. Systems are designed for use with typical operating systems. Upgrades are straightforward with the availability automated deployment tools. Systems are specified with enough resources to support the addition of third party applications such as security solutions. Standard communication protocols. Primarily wired networks with some localized wireless capabilities. Typical IT networking practices. Primary goal is to protect edge clients (for example, field devices such as process controllers). Protection of central server is still important. Responses such as rebooting may not be acceptable because of process availability requirements. Response to human and other emergency interaction is critical. Access should be strictly controlled, yet not hamper human machine interaction. Differing and custom operating systems often without security capabilities. Software changes must be carefully made, usually by software vendors, because of the specialized control algorithms and perhaps modified by hardware and software involved. Systems are designed to support the intended industrial process, with minimal memory and computing resources to support the addition of security technology. Many proprietary and standard communication protocols. Several types of communication media used including dedicated wire and wireless (radio and satellite). Networks are complex and sometimes require the expertise of control engineers. SP99 Part 4 Draft Edit Word format.doc Page 3

16 Category Information Technology System Industrial Control System Change management Managed support Software changes are applied in a timely fashion in the presence of good security policy and procedures. The procedures are often automated. Allow for diversified support styles. Software changes must be thoroughly tested and deployed incrementally throughout a system to ensure that the integrity of the control system is maintained. Outages often must be planned and scheduled days/weeks in advance. Service support is usually via a single vendor. Component lifetime Lifetime on the order of 3 5 years. Lifetime on the order of 5 20 years. Access to components Components are usually local and easy to access. Components can be isolated, remote and require extensive physical effort to access TECHNOLOGY ROADMAPS Two quality technology roadmaps provide considerable guidance for the development of the prescriptive recommendations and guidelines specified in this standard. The US Department of Energy (DoE) published a Roadmap to Secure Control Systems in the Energy Sector (US Department of Energy January 2006)outlining needed research initiatives in the near term (2006 and 2007), the mid term ( ), the long term ( ) and the end state (205). The European Union (EU), European Commission (EC) Joint Research Center (JRC) published ICT Vulnerabilities of Power Systems: A roadmap for Future Research (GR Consortium December 2007) outlining research initiative in the near term ( ), the mid term ( ), the long term ( ) and the final state (2020) 2. Although the time frames differ slightly, both roadmaps address the same needs in each period: Near term, mid term and long term was described in periods of 0 2 years, 2 5 years and 5 0 years respectively. Based on the publication date of the DoE roadmap, these periods are mapped to calendar years. 2 Near term, mid term and long term was described in periods of 0 3 years, 3 8 years and 8 5 years respectively. Based on the publication date of the GR roadmap, these periods are mapped to calendar years. SP99 Part 4 Draft Edit Word format.doc Page 4

17 Establish scientific bases and tools that cross cut issues, raising awareness and providing education in the near term. Providing structural measures (actions) for components and architectures, and addressing societal and governance issues in the mid term. Deploying protective measures, remedial actions and real time applications in the long term. ISA 99 standards fit well in both roadmaps. ISA is designed to provide the prescriptive recommendations and guidelines needed to meet the long term objectives CATALOG OF SOURCES The US Department of Homeland Security (DHS) commissioned the Idaho National Laboratory (INL) to develop Catalog of Control Systems Security: Recommendations for Standards Developers (US Department of Homeland Security January 2008). This document provides a catalog of recommended requirements to be used in the facilitation of the development and implementation of control system cyber security standards. Included is a compilation of practices recommended by various organizations for increasing the security of control systems from both physical and cyber attacks. The recommended requirements in this catalog are grouped by 8 families, or categories, with similar emphasis. The recommended requirements for each of the families are displayed with a summary statement of the requirement, supplemental guidance or clarification, and a requirement enhancement statement providing augmentation for the requirement under special situations. INL s catalog was a valuable resource used in the development of the prescriptive recommendations and guidelines specified in this document. 2 STANDARDS, RECOMMENDED PRACTICES AND GUELINES {TBS need an author} SP99 Part 4 Draft Edit Word format.doc Page 5

18 SECURITY ASSURANCE ISA [] defines security assurance as the level corresponding to the required effectiveness of countermeasures to thwart cyber attacks against industrial automation systems. ISA intends to provide a scale of security assurance levels which asset owners can use to establish a minimum set of requirements. Each set is designed to protect selected zones or conduits against access to and use of devices, systems and data. The security level of the system (S system ) is described as the sum of the weighted security levels of the components (w i s i ). 0 S system = is i Based on the owner s assessment of risk and evaluation of consequences, w i (the weighting) and s i (the security level of the component) are assigned by the asset owner. It is important to note that s i is not a statement of probability, and there is no requirement that s i =[0,]. It is more like a score. A similar approach is described in the Common Vulnerability Scoring System (CVSS); however, it is not obvious why s i should be related to a probability of occurrence which is the foundation premise of CVSS. It is more likely that s i is a measure of the consequence of the failure to adequately protect the system against an adversary induced attack. That is, if s i is high, the consequence resulting from an attack is low; i.e., a measure of effectiveness. The target security level of a system can, with considerable effort, be determined for the NIST and documents. The problem is that there is no insight in the NIST publications as to how an asset owner should allocate system level security target to the component (or subsystem) security levels. Be that as it may, the target value for the system should be greater than the estimated (calculated) value for the system. S system SAL ISA recommends the following procedure:. The asset owner estimates the target level of the system using NIST (NIST SP n.d.) and Using the same assumptions and rules set forth in the NIST publications, the asset owner calculates the security level of the system by summing the weighted components. This is now the design security assurance level for the system. 3. If the estimated (calculated) design security level for the system is greater than something is amiss probably the assumptions are either not consistent, or the application of the assumptions has not been correctly performed. In either case the asset owner must redo both estimates. 4. If the estimated design security level for the system is less than the difference is the design margin. Given the uncertainty in all factors of this process, beginning with the uncertainty in the initial risk assessment and consequence analysis as well as the SP99 Part 4 Draft Edit Word format.doc Page 6

19 2 uncertainty in properly applying the assumptions (as discussed above), a design margin on the order of 00% is probably reasonable SECURITY FOUNDATIONAL REQUIREMENTS ISA [] established seven foundational security requirements. These requirements are used to derive the prescriptive recommendations and guidelines specified in ISA Furthermore because of the synergism between requirements, ISA specifications tend to focus on enabling technologies that provide a comprehensive security solution. The goal is to reduce the cost of implementing and maintaining security as described in ISA [2] and ISA [3] ACCESS CONTROL FR Control access to selected devices, information or both to protect against unauthorized interrogation of the device or information. : Using their risk assessment methodology, asset owners will select devices and information that require strong access control protection. Derived prescriptive recommendations and guidelines should include mechanisms that will operate in mixed modes; e.g., some devices on a communication channel require strong access control and others do not. By extension, access control requirements need to be extended to data at rest; i.e., ensure strong access control to data that resides in selected repositories USE CONTROL FR 2 Ensure the integrity of data on selected communication channels to protect against unauthorized operation of the device or use of information. : Using their risk assessment methodology, asset owners will select communication channels that require strong use control protection. Derived prescriptive recommendations and guidelines should include mechanisms that will operate in mixed modes; e.g., some communication channels require strong use control protection and others do not. By extension, use control requirements need to be extended to data at rest; i.e., ensure strong use control to data that resides in selected repositories DATA INTEGRITY FR 3 Ensure the integrity of data on selected communication channels to protect against unauthorized changes. : Using their risk assessment methodology, asset owners will select communication channels that require strong integrity protection. Derived prescriptive recommendations and guidelines should include mechanisms that will operate in mixed modes; e.g., some communication channels require strong integrity protection and others do not. By extension, data integrity requirements need to be extended to data at rest; i.e., protect the integrity of data that resides in selected repositories. SP99 Part 4 Draft Edit Word format.doc Page 7

20 DATA CONFENTIALITY FR 4 Ensure the confidentiality of data on selected communication channels to protect against eavesdropping. : Using their risk assessment methodology, asset owners will select communication channels that require strong confidentiality protection. Derived prescriptive recommendations and guidelines should include mechanisms that will operate in mixed modes; e.g., some communication channels require strong confidentiality protection and others do not. By extension, confidentiality requirements need to be extended to data at rest; i.e., protect the confidentiality of data that resides in selected repositories RESTRICT DATA FLOW FR 5 Restrict the flow of data on communication channels to prevent the publication of information to unauthorized sources. : Using their risk assessment methodology, asset owners will determine what information must be restricted for publication, and by extension block the communication channels used to deliver these data. Derived prescriptive recommendations and guidelines should include mechanisms that range from disconnecting control networks from business or public networks to using stateful firewalls and DMZ to manage the flow of information TIMELY RESPONSE TO EVENT FR 6 Respond to security violations by notifying the proper authority, reporting needed forensic evidence of the violation, and automatically taking timely corrective action in mission critical and safety critical situations. : Using their risk assessment methodology, asset owners will establish policies and proper lines of communication and control needed to respond to security violations. Derived prescriptive recommendations and guidelines should include mechanisms that collect, report and automatically correlate the forensic evidence to ensure timely corrective action NETWORK RESOURCE AVAILABILITY FR 7 Ensure the availability of all network resources to protect against denial of service attacks. : Using their risk assessment methodology, asset owners will establish policies and guidelines for communication network operational redundancy and by extension supporting information repositories. These guidelines will include criteria of emergency shutdown procedures, reconfiguration procedures, restart procedures and hot switchover procedures. SP99 Part 4 Draft Edit Word format.doc Page 8

21 2 3 DERIVED REQUIREMENTS FOR EFFECTIVE SECURITY The requirement sets specified in ISA are for the most part harmonized with the requirement sets in IEC (IEC ) PROTECTION OF DATA AT REST Protection of data at rest is a mission critical security requirement for industrial automation control systems. Because data at rest exists throughout the enterprise, a comprehensive security policy, security solution and deployment strategy is needed. Recommended security solutions must address data at rest residing in fixed and portable repositories. Data residing in these repositories may require significantly different security requirements. For example, security keys for encryption should comply with NIST FIPS 42 2 (NIST FIPS ) requirements; however, a non sensitive memo may not require any security protection. Lastly, it is important to understand that in a highly networked environment, which is the case for ISA , we must think about data as having a point of presence, rather than flowing from point A to point B. For this reason, protection of data at rest must a occur as close to its source of origination as possible, and these protection mechanisms must travel with the data throughout its lifetime. Access control, use control, data confidentiality and integrity are four of the foundational requirements that require special attention to protect data at rest. And because of the insidious nature of malware, virus and Trojan threat agents that attach themselves to data objects, protection mechanisms need to be designed with the appropriate counter measures to mitigate these threats. The combination of these requirements presents a significant challenge for designing a comprehensive security solution. Foundational requirement protection mechanisms The goal is to find one comprehensive security mechanism for strong access control, use control, confidentiality and integrity that can be tailored to provide the security assurance level specified by the asset owner. The mechanism must be cost effective in terms of procurement, deployment and maintenance over its life cycle. And most importantly, managing the security must be relatively easy to ensure its acceptance by those entrusted with security responsibilities. SP99 Part 4 Draft Edit Word format.doc Page 9

22 TABLE 2 DATA AT REST SECURITY REQUIREMENTS I&AM I&AM 2 I&AM 3 I&AM 4 I&AM 5 Provide the capability to provide strong access control, use control, confidentiality and integrity security assurance for any named data object. Provide the capability to implement I&AM within a single repository with the granularity to establish security assurance levels for an object defined as a record, file, physical medium, etc. Provide the capability manage access and use privileges using role based access control that is administered by the organizational unit most closely associated with the source or function that creates the data object. Provide the capability to use any validated cryptographic algorithm to match the security assurance requirements for confidentiality and integrity. Cryptographic module shall be designed and certified to be in compliance with FIPS 40 2 so as to achieve the security assurance level specified by the asset owner. A comprehensive security mechanism is needed to provide an integrated solution for access control, use control, confidentiality and integrity. Such a coherent mechanism will minimize the implementation of stove pipe security solutions designed to address each requirement independently. The intent is to implement a security mechanism that minimizes the need for physical separation of data objects that require different security assurance levels. The objective is to implement a common security assurance policy that is administered locally. The central management organization (enterprise authority) is responsible for oversight of the execution by all organizational units including partners, suppliers and government oversight agencies. The objective is to provide a graceful migration of acceptable cryptographic mechanisms that will be developed in the future. Tamper resistant and tamper proof requirements will be defined by the security assurance level. Note: The University of Cambridge has reported system level failures of tamper proofing (Drimer, Murdoch and Anderson February 2008). Security assurance needs to address this issue. 2 SP99 Part 4 Draft Edit Word format.doc Page 20

23 PROTECTION AGAINST MALWARE, VIRUS AND TROJANS Commercial products are readily available to provide protection against malware, virus and Trojan threats. In general, these products work well for office environments and Internet browsing. They may not work well in an industrial automation and control system where availability and performance are mission critical constraints. TABLE 3 MALWARE, VIRUS AND TROJAN SECURITY PROTECTION REQUIREMENTS MV&T MV&T 2 MV&T 3 MV&T 4 MV&T 5 MV&T 6 Subject to performance constraints, servers, desktops, network attached storage devices, or any other storage appliances shall have suitable anti virus software installed and kept up to date. Any data stored on publicly available servers (including third party service providers) shall have an associated numerical sum checksum to verify file transmission integrity Data storage points should include file based integrity checkers that run periodically to report on any file modifications. Virus scanning shall be applied to any backup media prior to use. Offsite data storage provided by third party data management providers shall comply with Service Level Agreements and periodic audits conducted by the asset owner to ensure that anti virus and malware protection mechanisms and procedures are in place, upto date, and are properly performed. Rootkit analysis shall be applied periodically to all data storage devices The first line of defense is to keep MV&T out of files entirely. Checking this checksum will prevent data from being modified in transit or from using out of date versions of software. File based integrity checkers can automatically detect modifications to any stored file and report on the variance. In the event of a virus compromise, or someone compromises backup data storage, this measure will mitigate replicating a virus back onto a machine being restored. Third party providers need to oversight audits due to varying implementations of security systems. Rootkits are often not found by antivirus software and can be very difficult to detect without special tools. SP99 Part 4 Draft Edit Word format.doc Page 2

24 MV&T 7 Active port and services scans shall be performed periodically to identify new network services that are enabled. Backdoors may often be installed or written that do not match known virus signatures (such as using netcat to establish a socket). Periodically reviewing and comparing to last run will limit this exposure SECURITY OF THE INDUSTRIAL CONTROL NETWORK ISA includes a reference model describing zones, conduits and target security assurance levels in process control systems that need to be protected from cyber attack. The normative clauses define the requirements sets needed for perimeter defense and intra zone defense in depth protection against selected threat assessment vectors. Informative information is needed to support the recommendation to embed objects in control network routing devices and terminal devices to improve the protection offered by other mechanisms. "Integrated security" describes the security functionality that is provided on a networking device, for example on a router, switch, or wireless access point. As traffic passes through a networking device, it must be scanned and analyzed, then allowed to continue, partitioned, or rejected. This requires that the integrated security device possess intelligence, performance, and scalability. "Embedded security" refers to security functionality that is distributed across key locations in the plant network infrastructure and terminal devices. Embedded, integrated security must defend the network against external and internal threat, always striking a balance between the need for access and the need for protection. That means security functionality must be embedded and integrated everywhere, but that it also must be transparent to the user and application. The goal is to deploy a set of security capabilities that together create an "intelligent self defending network" that can identify attacks as they occur, alert as appropriate, and then automatically respond, without user intervention. EMBEDDING PERIMETER DEFENSE OBJECTS IN TERMINAL DEVICES From a requirements analysis point of view, the terminal device is part of a zone as defined in the ISA reference model. Because of overlaps with other requirement sets defined for components in the zone, the terminal device requirement set is limited to the additional requirements that are not addressed by other components. SP99 Part 4 Draft Edit Word format.doc Page 22

25 If required by a company s security policy, high integrity security solutions that create a hardwareenforced security environment may be needed. Because of the special issues introduced by the insider threat, the use of a Portable Terminal Device (PTD) must be addressed. The terminal device requirement sets specified in ISA require security mechanisms that should be implemented with a common foundational base to minimize deployment of unique solutions which are not interoperable, or are difficult to manage. Special attention must be given to portable terminal devices. In today s industrial automation systems, mobile computing is fast becoming the norm. Mobile devices, such as notebooks for engineering or even PDAs can be connected everywhere in order to collect data, to maintain product process or to startup complex industrial plants. And that s where the lies. For those so inclined, improperly protected data is there for the taking at every point where a mobile device is connected. It is simply a matter of motivation. On the other hand, mobile devise are suitable alternate hosts for all kinds of viruses, worms or Trojans, which can be moved and distributed from one location to another. VULNERABILITIES OF THE TERMINAL DEVICE Threats and the resulting security vulnerabilities defined in ISA [2] are applicable to the control network. This specification adds no additional threats or resulting security vulnerability. However,, the terminal device introduces some unique considerations. The dominant concern is the insider threat. The terminal device and technician may be from an external organization. Terminal devices may be used for configuration changes, test drivers, monitoring, etc. The terminal device may not be under strict configuration and use control (might be used for other personal use or company use requiring access to non secure networks). For this reason, malware such as virus infection, Trojans, are of particular concern. Patch management and configuration management must include security mechanisms needed to ensure the confidentiality and integrity of the patches to be installed by the service technician. SECURITY REQUIREMENT SETS FOR TERMINAL DEVICES sets are specified for the following: Identity and access management see Table 4 Confidentiality, integrity and availability see Table 5 Defense in depth see Table 6 SP99 Part 4 Draft Edit Word format.doc Page 23

26 TABLE 4 ENTITY AND ACCESS MANAGEMENT SECURITY REQUIREMENTS I&AM 6 I&AM 7 I&AM 8 I&AM 9 I&AM 0 There shall be a policy in place, which ensures, that terminal devices can connected only to well defined (access) points of the company. This policy shall be enforced by technical measures which may differ, depending of the current technical configuration and the use case of the terminal device. A minimum of two factor authentication should be required to gain access to any network or device to which the terminal device is physically or logically attached. All devices to which the terminal device has access shall be alarmed. All accesses (unsuccessful attempts and successful entry) shall be logged and reported to an external monitor logging facility within 5 (TBR) seconds. All identity information related to the entry shall be adequately day/time stamped and included with the report to the monitor logging facility. Terminal devices are suitable to bypass perimeter borderlines, e.g. when they are connected behind a security gateway. So the use case has to be balanced with possible security risks. Two factor authentication requires that the person gaining access have an authentication key and a controlled PIN number something physical and something known. The advantage of two factor authentication is that access privileges can be controlled and are auditable. Unauthorized access attempts should result in an alarm that can be remotely monitored. A good security policy requires the ability to audit all activity that could result in a breach of security. The report should include all forensic information needed. : Day/time stamps are needed to correlate information. 2 3 s are grouped into three sets: confidentiality, integrity and availability. SP99 Part 4 Draft Edit Word format.doc Page 24