Chapter 10. Standards and Regulations
Information in this Chapter:
• Common Standards and Regulations
• Mapping Industrial Network Security to Compliance
• Mapping Compliance Controls to Network Security Functions
• Common Criteria and FIPS Standards
There are hundreds of cyber security standards and regulations imposed by governments and industry, which provide everything from “best practices” recommendations to hard requirements that are enforced through penalties and fines. Common standards include the North American Electric Reliability Corporation’s (NERC’s) Critical Infrastructure Protection (CIP) Reliability Standards, the U.S. Department of Homeland Security’s Chemical Facility Anti-Terrorism Standards (CFATS), the Regulated Security of Nuclear Facilities by the U.S. Nuclear Regulatory Commission (NRC), and general ICS security recommendations published by NIST in Special Publication 800-82. International standards include ISA-99 and ISO/IEC 27002:2005.
There are many specific compliance controls within these standards, as well as scores of additional compliance standards, which are not covered in this book. While efforts to maintain compliance with one or more of these regulations can be challenging and complex enough to fill an entire book dedicated to that topic, these controls often map directly to security best practices. These practices often agree with each other to a certain degree, although there are subtle differences among the various standards and regulations that can prove valuable when securing an industrial network. By mapping common security functions to common compliance controls, the best of each can be implemented as required (by a regulating authority) or as desired (for the sole purpose of strengthening the security of the industrial system).
Finally, there are standards and regulations that do not apply to industrial networks at all, but rather to the products that might be utilized by an industrial network operator to help secure (see Chapter 7, “Establishing Secure Enclaves”) and monitor (see Chapter 9, “Monitoring Enclaves”) the network. Among these are the international Common Criteria standards, and various FIPS standards including the FIPS 140-2 Security Requirements for Cryptographic Modules.
Common Standards and Regulations
As mentioned in Chapter 2, “About Industrial Networks,” industrial networks are of interest to several national and international regulatory and standards organizations. In the United States and Canada, NERC is well known because of the NERC CIP reliability standards, which heavily regulate security within the North American bulk electric system. NERC operates independently under the umbrella of the Federal Energy Regulatory Commission (FERC), which regulates natural gas, oil, and electric transmission, as well as hydropower projects. The Department of Energy (DoE) and Department of Homeland Security (DHS) also produce several security recommendations and requirements, including the Chemical Facility Anti-Terrorism Standards (CFATS), the Federal Information Security Management Act (FISMA), and Homeland Security Presidential Directive Seven, which all refer back to several special publications of the National Institute of Standards and Technology (NIST), particularly SP 800-53 “Recommended Security Controls for Federal Information Systems and Organizations” and SP 800-82 “Guide to Industrial Control Systems (ICS) Security.” The International Standard Association’s standard for the Security for Industrial Automation and Control Systems (ISA-99), and the International Standards Organization (ISO) Standard ISO/IEC 27002:2005 provide security recommendations that are applicable to industrial control networks.
NERC CIP
It is hard to discuss Critical Infrastructure security without referring to the North American Electric Reliability Corporations’ Critical Infrastructure Protection reliability standards (NERC CIP). Although NERC CIP standards are only enforceable upon North American bulk electric systems, the standards represented are technically sound and in alignment with other standards, and are presented in the spirit of improving the security and reliability of the electric industry. 1 Further, the critical infrastructures of the electric utilities—specifically the distributed control systems responsible for the generation of electricity and the stations, substations, and control facilities—utilize common industrial network assets and protocols, making the standards relevant to a wider base of industrial network operators.
1.M. Asante, NERC, Harder questions on CIP compliance update: ask the expert, 2010 SCADA and Process Control Summit, The SANS Institute, March 29, 2010.
NERC consists of nine separate configuration management controls:
• CIP-001-4—Sabotage Reporting. Requires that all disturbances or unusual occurrences, suspected or determined to be caused by sabotage, shall be reported to the appropriate systems, governmental agencies, and regulatory bodies. 2
2.North American Reliability Corporation, Standard CIP-001-4—Sabotage Reporting. < http://www.nerc.com/files/CIP-001-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-002-4—Critical Cyber Asset Identification. Requires the identification and documentation of the Critical Cyber Assets associated with the Critical Assets that support the reliable operation of the Bulk Electric System. These Critical Assets are to be identified through the application of a risk-based assessment. 3
3.North American Reliability Corporation, Standard CIP-002-4—Cyber Security—Critical Cyber Asset Identification. < http://www.nerc.com/files/CIP-002-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-003-4—Security Management Controls. Requires that Responsible Entities have minimum security management controls in place to protect Critical Cyber Assets. 4
4.North American Reliability Corporation, Standard CIP-003-4—Cyber Security—Security Management Controls. < http://www.nerc.com/files/CIP-003-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-004-4—Personnel and Training. Requires that personnel having authorized cyber or authorized unescorted physical access to Critical Cyber Assets, including contractors and service vendors, have an appropriate level of personnel risk assessment, training, and security awareness. 5
5.North American Reliability Corporation, Standard CIP-004-4—Cyber Security—Personnel and Training. < http://www.nerc.com/files/CIP-004-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-005-4—Electronic Security Perimeter(s). Requires the identification and protection of the Electronic Security Perimeter(s) inside which all Critical Cyber Assets reside, as well as all access points on the perimeter. 6
6.North American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-006-4—Physical Security of Critical Cyber Assets. Ensures the implementation of a physical security program for the protection of Critical Cyber Assets. 7
7.North American Reliability Corporation, Standard CIP-006-4—Cyber Security—Physical Security of Critical Cyber Assets. < http://www.nerc.com/files/CIP-006-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-007-4—Systems Security Management. Requires Responsible Entities to define methods, processes, and procedures for securing those systems determined to be Critical Cyber Assets, as well as the other (noncritical) Cyber Assets within the Electronic Security Perimeter(s). 8
8.North American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-008-4—Incident Reporting and Response Planning. Ensures the identification, classification, response, and reporting of Cyber Security Incidents related to Critical Cyber Assets. 9
9.North American Reliability Corporation, Standard CIP-008-4—Cyber Security—Incident Reporting and Response Planning. < http://www.nerc.com/files/CIP-008-4.pdf>, February 3, 2011 (cited: March 3, 2011).
• CIP-009-4—Recovery Plans for Critical Cyber Assets. Ensures that recovery plan(s) are put in place for Critical Cyber Assets and that these plans follow established business continuity and disaster recovery techniques and practices. 10
10.North American Reliability Corporation, Standard CIP-001-9—Cyber Security—Recovery Plans for Critical Cyber Assets. < http://www.nerc.com/files/CIP-009-4.pdf>, February 3, 2011 (cited: March 3, 2011).
Note
The NERC CIP standards have been mapped to common security controls under the section “Mapping Industrial Network Security to Compliance.”
CFATS
The Risk-Based Performance Standards (RBPS) for the Chemical Facilities Anti-Terrorism Standards (CFATS) outlines various controls for securing the cyber systems of chemical facilities. Specifically, RBPS Metric 8 (“Cyber”) outlines controls for (1) security policies, (2) access control, (3) personnel security, (4) awareness and training, (5) monitoring and incident response, (6) disaster recovery and business continuity, (7) system development and acquisition, (8) configuration management, and (9) audits.
Controls of particular interest are Cyber Metric 8.2.1, which requires that system boundaries have been identified and secured using perimeter controls, which supports the enclave security model. Metric 8.2 includes perimeter defense, access control (including password management), the limiting of external connections, and “least-privilege” access rules. 11
11.Department of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards, May 2009.
Metric 8.3 (Personnel Security) also requires that specific user access controls are established, primarily around the separation of duties, and the enforcement thereof by using unique user accounts, access control lists, and other measures. 12
12.Ibid.
Metric 8.5 covers the specific security measures for the monitoring of asset security (primarily patch management and Anti-Malware), network activity, log collection and alerts, and incident response, whereas Metric 8.8 covers the ongoing assessment of the architecture, assets, and configurations to ensure that security controls remain in compliance. 13
13.Ibid.
Of particular note are RBPS 6.10 (Cyber Security for Potentially Dangerous Chemicals), RBPS 7 (Sabotage), RBPS 14 (Specific Threats, Vulnerabilities, and Risks), and RBPS 15 (Reporting)—all of which include cyber security controls outside of the RBPS 8 recommendations for cyber security. RBPS 6.10 implicates ordering and shipping systems as specific targets for attack that should be protected according to RBPS 8. 14 RBPS 7 indicates that cyber systems are targets for sabotage and that the controls implemented “deter, detect, delay, and respond” to sabotage. 15 RBPS 14 requires that measures are in place to address specific threats, vulnerabilities, and risks, inferring a strong vulnerability assessment plan, 16 whereas RBPS 15 defines the requirements for the proper notification of incidents when they do occur. 17
14.Ibid.
15.Ibid.
16.Ibid.
17.Ibid.
Note
The CFATS standards as defined by the Risk-Based Performance Standards (RBPS) have been mapped to common security controls under the section “Mapping Industrial Network Security to Compliance.”
ISO/IEC 27002:2005
The ISO/IEC 27002:2005 Standard is an international standard published by the International Standards Organization (ISO), the International Electrotechnical Commission (IEC), and the American National Standards Institute (ANSI). Although ISO/IEC 27002:2005 provides less guidance for the specific protection of industrial networks, it is useful in that it maps directly to many additional national security standards in Australia and New Zealand, Brazil, Chile, Czech Republic, Denmark, Estonia, Japan, Lithuania, the Netherlands, Poland, Peru, South Africa, Spain, Sweden, Turkey, United Kingdom, Uruguay, Russia, and China. 18
18.International Standards Organization/International Electrotechnical Commission (ISO/IEC), About ISO. http://www.iso.org/iso/about.htm (cited: March 21, 2011).
Note
ISO/IEC 27002:2005 follows the C-I-A information security model, prioritizing Confidentiality, Integrity, and Availability in that order. However, depending upon the criticality of the industrial network and relevant safety concerns, these priorities may differ. For example, in nuclear facilities, the reliability and safety of the plant are paramount, whereas the confidentiality of information is less critical.
As with NERC CIP and CFATS, ISO/IEC 27002:2005 focuses on risk assessment and security policies in addition to purely technical security controls. The technical controls that are discussed include asset management and configuration management controls, separation and security controls for network communications, specific host security controls regarding access control, and Anti-Malware protection. Of particular interest are a group of controls around security incident management—the first of the standards discussed in this book to specifically mention the anticipation of a security breach using anomaly detection. Specifically, ISO/IEC mentions “malfunctions or other anomalous system behavior may be an indicator of a security attack or actual security breach.”19
19.International Standards Organization/International Electrotechnical Commission (ISO/IEC), International ISO/IEC Standard 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15.
Note
Excerpts from the ISO/IEC 27002:2005 Standard have been mapped to common security controls under the section “Mapping Industrial Network Security to Compliance.”
NRC Regulation 5.71
NRC Regulation 5.71 (RG 5.71) provides security recommendations for complying with Title 10 of the Code of Federal Regulations (CFR) 73.54. It consists of an in-depth discussion of the general requirements of cyber security, to specific requirements of planning, establishing, and implementing a cyber security program. Specific to RG 5.71 is the use of a five-zone network separation model, with one-way communications being required between zones 0 and 1 (the most critical enclaves of the five zones). One-way communications gateways, such as data diodes, allow outbound communications while preventing any return communications, promising an ideal security measure for the transmission of information from a secure zone to an outside supervisory system.
Although many of the recommendations in RG 5.71 are general in nature, RG 5.71 also includes three appendices, which provide a well-defined security plan template as well as specific technical security and operational controls for each recommendation. 20
20.U.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010.
NIST SP 800-82
The National Institute of Standards and Technology (NIST) has published a working draft of a “Guide to Industrial Control Systems (ICS) Security,” which includes recommendations for Security, Management, Operational, and Technical controls in order to improve control system security. This NIST publication is currently still in draft form and represents recommendations, not hard regulations. However, the controls presented are comprehensive and map well to additional NIST recommendations, such as those provided in SP 800-53 (“Recommended Security Controls for Federal Information Systems and Organizations”) and SP 800-92 (“Guide to Computer Security Log Management”). 21
21.K. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, September 2008.
Mapping Industrial Network Security to Compliance
There are literally hundreds of security regulations and recommendations that are published globally; many are applicable to industrial networks; some are enforced, some not; some are regional; some are applicable to all industrial networks, while some (such as NERC CIP) apply to specific industries. Although most standards and regulations focus on a variety of general security measures (including physical security, security policy development and planning, training, etc.), each has specific controls and measures for cyber security.
Tip
Many enforced compliance regulations (e.g., NERC CIP) require that “compensating controls” be used where a requirement cannot be feasibly met. Using additional compliance standards as a guide, alternate “compensating controls” may be identified. Therefore, even if the compliance standard is not applicable to a particular organization, the recommendations made within may prove useful.
These cyber security measures often overlap, although there are differences—both subtle and strong—among them. Efforts to normalize all the available controls to a common “compliance taxonomy” are being led by organizations such as the Unified Compliance Framework (UCF), which has currently mapped close to 500 Authority Documents to a common framework consisting of thousands of individual controls. 22 The advantages of a common mapping are significant and include the following:
22.The Unified Compliance Framework, What is the UCF? < http://www.unifiedcompliance.com/what_is_ucf> (cited: March 21, 2011).
• Facilitating compliance efforts for organizations that are responsible for multiple sets of compliance controls. For example, a nuclear energy facility that must track industrial regulations such as NRC Title 10 CFR 73.54, NRC RG 5.71, and NEI 08/09 requirements, as well as business regulations such as Sarbanes Oxley (SOX). Understanding which specific controls are common among all regulations prevents the duplication of efforts and can significantly reduce the costs of collecting, maintaining, storing, and documenting the information necessary for compliance.
• Facilitating the implementation of specific security controls by providing a comprehensive list of controls that must be implemented across all relevant standards and regulations.
This Chapter begins to map the security and compliance requirements for this purpose; however, owing to the extensive nature of most regulations, as well as the changing nature of specific compliance control documents, only a select sample of common controls has been included in this text.
Caution
Figure 10.1, Figure 10.2 and Figure 10.3 and the corresponding Table 10.1, Table 10.2 and Table 10.3 show how various compliance controls apply to different areas of control system security. Although every attempt has been made to reference common and relevant controls, which provide insight into best security practices, the controls represented in this Chapter are far from all-inclusive.
This text should not be used as a sole resource for any regulatory compliance effort. Always reference source compliance standards documents and/or contact the standards organization directly to ensure that all required compliance controls are fully understood in order to avoid possible penalties or fines.
| aNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| bDepartment of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| cIbid. | |
| dInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| eIbid. | |
| fIbid. | |
| gIbid. | |
| hIbid. | |
| iU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| jIbid. | |
| kIbid. | |
| lK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 5.3.2, Firewall Between Corporate Network and Control Network, September 2008. | |
| mIbid. | |
| nIbid. | |
| oIbid. | |
| pD. Peterson, Intrusion detection and cyber security monitoring of SCADA and DCS networks, ISA < http://whitepapers.techrepublic.com.com/whitepaper.aspx?&docid=126355&promo=100511>, 2004 (cited: March 3, 2011). | |
| qK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.2.6.2 Intrusion Detection and Prevention, September 2008. | |
| rNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| sDepartment of Homeland Security, Risk-Based Performance Standards Guidance, Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| tNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s), < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| uInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| vIbid. | |
| wIbid. | |
| xU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| yIbid. | |
| zIbid. | |
| aaIbid. | |
| Compliance Control | Recommendations |
|---|---|
| P1—Electronic Security Perimeter | |
| NERC CIP-005-4 R1, Electronic Security Perimeter CIP-005-4 R1 requires that the Electronic Security Perimeter (ESP), which should be established around “every Critical Cyber Asset,” is identified and documented, including all access points to the ESP. a | Construct security perimeters at the edge of all enclaves, using multiple layered defenses (e.g., a firewall and an IPS, and/or Industrial Protocol Filters and Industrial Application Monitors). |
| Implementing network flow monitoring at the perimeter will facilitate the detection and reporting of assets (by IP) on both sides of the perimeter and will also allow monitoring of the perimeter for communication violations, using an event or log management system. | |
| CFATS RBPS Metric 8.2.1, Systems Boundaries The Risk-Based Performance Standard Metric 8.2.1 requires that an electronic perimeter be identified and also that appropriate security controls are implemented “to limit access across those boundaries.”b | Consider naming devices that make up an ESP using a common nomenclature that identifies the ESP to which those devices belong, as well as the enclave(s) that it protects, in order to facilitate reporting, filtering, and other information management functions. |
| CFATS RBPS Metric 8.5.1, Cyber Security Controls The Risk-Based Performance Standard Metric 8.5.1 requires security controls to “prevent malicious code from exploiting critical assets,” although there is no indication of whether network- or host-based protection is required. c | Implement an IPS to detect malware within inbound network traffic. Where an IPS is not feasible, utilize an IDS (or an IPS configured to operate in a “passive” or “IDS” mode) via a span port or network tap. The detection capability of the IDS is the same, without the risk of incurring latency or other connectivity issues. |
| ISO/IEC 27002:2005, Control 10.6.1, Network Controls Control 10.6.1 requires that networks be “adequately managed and controlled,” to protect the systems and applications using the network. The control specifically calls out the protection of information in transit and offers guidance including the separation of duties, and the establishment of controls “to safeguard the confidentiality and integrity of data passing over public networks or over wireless networks, and to protect the connected systems and applications.” While guidance for specific security controls is not provided, ISO/IEC 27002:2005, Control 10.6.1 does require that those controls utilize “appropriate logging and monitoring” of “security relevant actions.”d | Network devices (switches, routers, etc.) should be configured to provide layer 3 separation of enclaves, with explicit access controls in place where possible. |
| Network management and security monitoring systems should be functionally isolated as well, via layer 1 (physically isolated network connections), layer 2 (VLAN), or layer 3 (subnet) separation. | |
| Communication enforcement between enclaves (explicit source-to-destination rules) should be implemented at a minimum, and encryption should be used where interconnections occur across less secure networks. | |
| An IDS or IPS may also be used to detect and/or block intrusion attempts, whereas an Industrial Protocol Filter or Application Monitor can detect the attempted misuse of industrial protocols. | |
| All measures should be configured to produce verbose logs, for collection and management (see Chapter 9, “Monitoring Enclaves”). | |
| ISO/IEC 27002:2005, Control 11.4.5, Segregation of Networks Control 11.4.5 supports the separation of functional groups into enclaves, defined as “groups of information services, users, and information,” going on to include the concept of separating out enclaves based upon the criticality of systems and assets. | Establish each domain as a separate enclave and implement an electronic perimeter consisting of a firewall and/or IPS, at a minimum. |
| While network separation using layer 2 (VLAN) or layer 3 (Network) controls is recommended, these methods are significantly less secure and should be supplemented with a strong electronic perimeter, if used. | |
| Guidance for how to perform the separation of enclaves includes separating the network into multiple network domains; installing a firewall between networks, utilizing virtual private networks to control access. Additional guidance includes separating networks using “network device functionality” such as layer 3 routing, layer 2 switching, and access control lists—as well as strong authentication and encryption. e | To separate Industrial Networks using layer 2 and 3 protocols (see Chapter 4, “Industrial Network Protocols”), implement an Industrial Protocol Filter, or use an Application Monitor capable of operating as an Industrial Protocol Filter. |
| ISO/IEC 27002:2005, Control 11.4.6, Network Connection Control Control 11.4.6 refers specifically to shared network environments; that is, those networks that cross organizational or functional boundaries, such as a business intelligence workstation for the visualization of operational or production metrics to a business user located in a nonsecure network. | The reachability of networks should be controlled by electronic perimeter devices such as a firewall or IPS, whereas accessibility should be controlled via network access control, enforced within the network infrastructure. |
| Applications and services should also be isolated within unique enclaves, and therefore be separated at the network layer, with explicitly defined network access control in addition to perimeter defenses. | |
| Guidance includes strong network access controls, including date and time considerations for access control (i.e., the enforcement of “shifts”). Guidance also includes the “capability of users [to] be restricted through network gateways that filter traffic by means of predefined tables or rules.”f Although the method of restricting traffic is not specified, examples of restrictions are given, which include messaging applications, file transfers, interactive access, and application access—the latter two of which imply a control against the use of executable code or scripts in a network environment. | |
| ISO/IEC 27002:2005, Control 11.4.7, Network Routing Control Control 11.4.7 continues the trend of network-based separation recommended in Controls 11.4.5 and 11.4.6, this time focusing on network routing—specifically, to “ensure that computer connections and information flows do not breach the access control policy of the business applications.”g The guidance refers to source and destination address checking, implying standard TCP/IP routing protocols for layer 3 separation of network traffic. However, the use of security gateways is also recommended to validate routing by checking source and destination addresses. | All routers should separate enclaves at layer 3, with explicitly defined Access Control Lists (ACLs) enforced where supported to control the specific source and destination addresses allowed to communicate between networks. |
| Layer 2 network separation via Virtual Local Area Networks (VLANs) is less secure and, although VLANs may be used where needed, they should not be used as a secure means of network separation. | |
| ISO/IEC 27002:2005, Control 11.6.2, Sensitive System Isolation Control 11.6.2 further supports the enclave model of functional separation and isolation, specifically requiring that critical systems should be implemented on a dedicated computing environment, which is isolated from other systems. h | All sensitive systems should be isolated within secured enclaves (see Chapter 7, “Establishing Secure Enclaves”). |
| NRC RG 5.71, Control B.1.4, Information Flow Enforcement RG 5.71 Control B.1.4 is written in the context of documentation, but concerns control over “the flow of information, in near-real time” within and between Critical Digital Assets (CDAs) in accordance with defense-in-depth security practices. i This includes documenting those information flows that are allowed (basically, establishing a perimeter security policy as described in Chapter 7, “Establishing Secure Enclaves”) and monitoring both access and information flows. | Information flow between systems can be controlled at the network level via an IPS or firewall, which can also “deter, detect, prevent, and respond” to unauthorized communication flows. |
| One-way communications can be enforced via a carefully configured firewall with explicitly defined “deny all” rules in one direction, or via dedicated unidirectional network gateways or data diodes. | |
| Information flows are required to be controlled using “domain-type enforcement” and monitored for indications of malicious communications attempts. j | Completing the feedback loop between monitoring, analysis, and defense provides dynamic control; this can be automated using more advanced SIEM or Log Management tools in response to detected threats, by appropriately configuring perimeter defenses (firewalls, NAC, IPS) in response to the threat. |
| NRC RG 5.71 Control B.1.4 presents a strict perimeter security requirement for critical zones, requiring the implementation of one-way data flows from the highest-security enclaves to less secure enclaves. | |
| NRC RG 5.71, Control B.3.4, Denial-of-Service Protection RG 5.71 Control B.3.4 is written in the more general context of protecting CDAs against denial-of-service attacks. The control specifically requires both network-based protection (“… restrict[ing] the ability of users to launch denial-of-service attacks against other CDAs or networks”) and host-based security considerations (“… configuring CDAs to manage excess capacity, bandwidth, or other redundancy to limit the effects of information-flooding and saturation types of denial-of-service attacks.”). k | To protect against denial of service (DoS) or information-flooding, limit the direct visibility to (i.e., make it more difficult to find) and the accessibility to (i.e., make it more difficult to connect) all outward facing services. Implement an IPS and/or firewall at the perimeter to block DoS behavior, as well as to block inbound scan attempts that could lead to DoS behavior. Make sure that any perimeter devices are capable of filtering unwanted traffic in excess of the maximum line rate of the network connection being protected, in order to prevent dropped traffic. |
| NIST SP 800-82, Network Architecture Control 5.3.2, Firewall between Corporate Network and Control Network NIST SP 800-82 Control 5.3.2 outlines how to deploy a firewall between corporate and control networks. The recommendation indicates that “ICS networks and corporate networks can be segregated to enhance cyber security using different architectures. By introducing a simple two-port firewall between the corporate and control networks … a significant security improvement can be achieved. Properly configured, a firewall significantly reduces the chance of a successful external attack on the control network.”l | Configure firewall policies according to the recommendations in Chapter 7, “Establishing Secure Enclaves.” |
| Consider a layered defensive strategy consisting of one or more additional security measures in addition to a firewall—such as an IPS or Application Monitor. | |
| Consider implementing a DMZ (see NIST SP 800-82, Network Architecture Control 5.3.4) or paired firewalls (see NIST SP 800-82, Network Architecture Control 5.5) to terminate and reestablish connections between enclaves when using a common protocol (to “disjoint” the protocol). | |
| NIST SP 800-82, Network Architecture Control 5.3.4, Firewall with DMZ between Corporate Network and Control Network NIST SP 800-82 Control 5.3.4 expands upon the recommendations of Control 5.3.2, recommending that a DMZ be used to provide access to certain systems—such as a data historian or business intelligence workstation—to both corporate and control networks, while maintaining security between the two. | When utilizing firewall DMZs to allow a device to communicate with multiple enclaves, always ensure that any and all devices within the DMZ have appropriate measures to prevent forwarding or relaying communications, in order to prevent the DMZ-connected devices from being used as a stepping-stone into other enclave(s). |
| Consider a layered defensive strategy consisting of one or more additional security measures in addition to a firewall—such as an IPS or Application Monitor. | |
| Specifically, NIST recommends that “… each DMZ holds one or more critical components, such as the data historian, the wireless access point, or remote and third party access systems. In effect, the use of a DMZ-capable firewall allows the creation of an intermediate network.”m | Consider strengthening the DMZ further through the use of paired firewalls, as described in “NIST SP 800-82, Network Architecture Control 5.5.” Use different policies on each perimeter to prevent “pass through” communications; i.e., “disjoint” the network connectivity. |
| The establishment of a firewall DMZ is fairly straightforward and supported by most firewalls. Apart from the firewall interfaces that connect to the corporate network and the control network, additional interfaces are used to connect to those systems that are accessed by both. | |
| NIST SP 800-82, Network Architecture Control 5.3.5, Paired Firewalls between Corporate Network and Control Network NIST SP 800-82 Control 5.3.5 recommends the establishment of a SCADA DMZ network. That is, an isolated network containing supervisory controls, historians, and other resources that require access by the corporate and control networks. Unlike the configuration described in Control 5.3.4, two firewalls are used in a pair: one between the corporate network and the DMZ network, and one between the DMZ network and the control network. | This is the preferred method of separation (shown in Figure 10.1), as it enforces explicitly defined and disjointed communication policies bi-directionally. |
| Consider a layered defensive strategy consisting of one or more additional security measures in addition to a firewall—such as a SCADA IPS, Industrial Protocol Filter, or Application Monitor. | |
| The result is “… a DMZ-like network zone sometimes referred to as a Manufacturing Execution System (MES) layer,” referred to as a SCADA DMZ in this book, where “the first firewall blocks arbitrary packets from proceeding to the control network or the shared historians. The second firewall can prevent unwanted traffic from a compromised server from entering the control network, and prevent control network traffic from impacting the shared servers.”n | |
| NIST SP 800-82, Network Architecture Control 5.5, General firewall policies for ICS Control 5.5 of NIST SP 800-82 covers basic recommendations for firewall configurations, including configuring firewalls with bidirectional Deny All rules and then explicitly enabling only “traffic [that is] absolutely required for business needs is every organization’s basic premise.” | Always explicitly define the source and destination IP and port in all firewall policies, so that potentially vulnerable traffic will only be allowed between trusted assets. |
| For critical enclaves, further protection can be provided via deeper analysis of the allowed traffic. Implement a SCADA IPS, Industrial Protocol Filter, or Application Monitoring device to provide deep packet inspection of allowed traffic, to detect exploits against allowed protocols (see Chapter 7, “Establishing Secure Enclaves”). | |
| NIST’s recommendations in Control 5.5 include guidance on the “absolutely required” means, noting that “Many important protocols used in the industrial world, such as HTTP, FTP, OPC/DCOM, EtherNet/IP, and MODBUS/TCP, have significant security vulnerabilities.”o Using SQL as an example, SQL is often used for historian data access but is also a major inbound attack vector. Simply allowing SQL traffic, therefore, is not recommended. If SQL is allowed, it should be exclusively limited to specific IPs and ports. Alternatively, additional methods of historian access should be investigated. | |
| NIST SP 800-82, Security Controls 6.2.6.2, Intrusion Detection and Prevention NIST SP 800-82 is one of the few documented guidelines to specifically recommend using an IDS. Specifically NIST SP 800-82 Control 6.2.6.2 recommends using an IDS “to monitor events on a network, such as traffic patterns, or a system, such as log entries or file accesses, so that they can identify an intruder breaking into or attempting to break into a system.”p NIST also points out that an IDS can “ensure that unusual activity such as new open ports, unusual traffic patterns, or changes to critical operating system files is brought to the attention of the appropriate security personnel.”q | NIST SP 800-82 Security Control 6.2.6.2 highlights the benefits of intrusion detection vs. intrusion prevention, using the IDS to detect unusual activity (i.e., anomaly detection) as well as traffic on “new open ports” (i.e., using the IDS to detect policy violations). By following the guidelines provided in Chapter 7, “Establishing Secure Enclaves,” any deviations from authorized activities should be easily identified, via the use of “whitelist” variables defining known good ports, protocols, users, assets, etc. |
| With the proper policies in place, Intrusion Prevention Systems (IPS) can be used in place of IDS to provide active protection. However, any detection policy configured to block traffic should be carefully considered to ensure that there is no possibility of disrupting a critical process as the result of a false positive. | |
| Note that Control 6.2.6.2 specifically calls for IDS, and not IPS, and references the IDS for monitoring use cases rather than active protection. | |
| P2—Network and Perimeter Monitoring | |
| NERC CIP-005-4 R2, Electronic Access Control CIP-005-4 R2 is an example of a compliance control designed to ensure that operational or organizational processes are established, yet that can be facilitated by the proper implementation of security controls. In this case, CIP-005-4 R2 requires that the “organizational processes and technical and procedural mechanisms for control of electronic access at all electronic access points to the Electronic Security Perimeter(s)” be implemented and documented. r | Implement access policies at the perimeter according to Chapter 7, “Establishing Secure Enclaves.” The use of a centralized configuration management system to track and monitor these access policies as defined within the electronic security perimeter device(s) can facilitate the documentation requirements. |
| In addition, monitoring of the ESP itself can provide further evidence that the ESP is in place and (assuming that ESP logs indicate successful and failed access attempts to the ESP) that the correct controls are in place. | |
| CFATS RBPS Metric 8.5.2, Network Monitoring Metric 8.5.2 calls for network monitoring traffic to identify unauthorized access and to detect malicious code. This requirement suggests the use of an IDS, which can do both tasks. | Monitoring a network in near-real time for unauthorized access or the introduction of malware requires either an active network monitoring solution such as an IDS or IPS, or the centralized analysis of alerts and logs by a Log Management or SIEM solution. |
| In addition, RBPS Metric 8.5.2 specifies that the network monitoring result in immediate alerts, and that logs of all alert activity be produced. Again, this suggests the use of an IDS or application-aware firewall, although these devices are not specified. | In the latter case, the Log Management or SIEM system must be able to collect, correlate, and analyze logs and alerts generated by perimeter security monitoring tools such as firewalls, IDS, IPS, etc. and to provide the necessary threat detection capability required to detect the malicious access. |
| Of particular interest in RBPS Metric 8.5.2 is an exception allowing “network monitoring [to] occur on-site or off-site. Where logging of cyber security events on their networks is not technically feasible (e.g., logging degrades system performance beyond acceptable operational limits).”s | |
| This could be interpreted as allowing the use of an external network monitoring device (such as an IDS or network probe) to be connected via a network tap or mirrored interface, to monitor control networks where an in-line device could interfere with network operations; or it could be interpreted as allowing the remote collection and analysis of logs. | |
| P3—Network Access and Authentication | |
| NERC CIP-005-4 R3, Monitoring Electronic Access CIP-005-4 R3 requires that a process for monitoring and logging access be established and documented. This control specifically requires the need to monitor access to the ESP as well as nonroutable network access via dial-up (in Control R3.1), where feasible, and generate alerts when an unauthorized access attempt is detected (in Control R3.2). t | Utilize a security event management system (SIEM) to centrally collect and display security events from the electronic security perimeter device(s). (See Chapter 9, “Monitoring Enclaves.”) |
| Practice a combined process of automated monitoring (i.e., the use of a SIEM for automated analysis and threat detection) with manual review of the ESP using a real-time “Security Operations Center” dashboard—typically provided by the same monitoring tools. The SIEM will not only facilitate the analysis of logs, but will also assist with the required documentation of the monitoring process(es). | |
| ISO/IEC 27002:2005, Control 11.4.1, Policy of use of Network Services Control 11.4.1 requires the use of “least privilege” access control, where a minimal set of privileges are provided to a username, based upon the role of the human operator, and what services he or she has been authorized to use. | Implement Network Access Control (NAC), and a central authentication system, directory system, or Identity Access Management (IAM) system to manage users, roles, and privileges. |
| Map user privileges to specific allow policies in perimeter firewalls and IPSs, and to network access control lists within the network infrastructure. | |
| Guidance provided by ISO/IEC 27002:2005 Control 11.4.1 includes the identification of which networks are accessible, and the mapping of user access to networks and services based upon a mapping of user authority to specific enclaves. u | |
| ISO/IEC 27002:2005, Control 11.4.2, User Authentication for External Connections Control 11.4.2 simply requires that “appropriate authentication methods” are used by remote users. Guidance suggests that appropriate methods include “a cryptographic based technique, hardware tokens, or a challenge/response protocol” such as what is commonly associated with VPN authentication or dial-back procedures when using remote dial-up connectivity via modems. Node authentication (authenticating to the connected host rather than the network access service) is specified as an alternative for the connection of user groups to a shared network or facility. v | Remote access should only be provided using secure remote access mechanisms such as a VPN. |
| Once terminated locally, remote users should be further restricted via network access control, and preferably be isolated to a unique enclave that is separated from local networks via an electronic perimeter. | |
| In other words, remote access should never allow direct authentication to a cyber asset. For example, a SCADA application installed on a laptop or smartphone should not be able to communicate directly to control system devices, unless the connection is made via a separately established and authenticated VPN, which terminates into a monitored and secured enclave. In this example, where control system access is being remotely granted, the additional layers of authentication (terminating the VPN into an isolated enclave that then requires additional authentication) prevents direct access to other critical networks from remote users. | |
| If remote ports are enabled when in use and otherwise disabled as a policy, the state of these access devices should be monitored using the Simple Network Management Protocol (SNMP) or a similar mechanism, so that network and security analysts can account for instances where remote access is enabled. | |
| ISO/IEC 27002:2005, Control 11.4.4, Remote Diagnostic and Configuration Port Protection Control 11.4.4 is actually a physical security control as well as a logical security control, mandating that the configuration ports of cyber assets be controlled to prevent unauthorized access. This compliance control highlights the ability to physically circumvent cyber security controls (by physically accessing a local communication port) and to logically circumvent physical security controls (by accessing configurations via the network where physical access is prevented). w | Logical access to configuration ports can be controlled through the use of strict access controls, requiring one or more authenticated connections, as discussed in response to “ISO/IEC 27002:2005, Control 11.4.2, User Authentication for External Connections.” |
| If the remote access port supports local access control, the interface can be protected further by only allowing inbound connections from these secure sources—in other words, the physical configuration port could be accessed locally, but it would not function; only connections established via an authenticated source would be allowed. | |
| NRC RG 5.71, Control B.1.4, Information Flow Enforcement As stated above under P1—Electronic Security Perimeter, NRC RG 5.71 Control B.1.4 is written in the context of documentation, but concerns control over “the flow of information, in near-real time” within and between Critical Digital Assets (CDAs) in accordance with defense-in-depth security practices. x This includes an access control mechanism in addition to establishing an electronic security perimeter, in order to capture and log all inbound communications for purposes of information flow enforcement. | NRC RG 5.71 Control B.1.4 introduces the concept of authenticated flow control between assets. Where authentication is not supported at the protocol layer (e.g., in the case of certain industrial network protocols, as discussed in Chapter 4, “Industrial Network Protocols”), the authentication will need to be enforced using external controls, such as Network Access Control, VPN, Domain authentication, etc. |
| NRC RG 5.71 Control B.1.4 also requires that information flows are deeply inspected, and that even encrypted data be scrutinized via content checking controls. y | The requirement to inspect the contents of a flow encourages the use of an Application Monitor or Industrial Protocol filter capable of determining (and analyzing) the payload of the information flow. In the case of encrypted traffic, the traffic must either be inspected prior to encryption or after decryption. In the case of network-based encryption, this can be accomplished by monitoring just outside of the encrypted link (just before the traffic has been encrypted, or just after it has been decrypted). If it is host-based data encryption, or if the encrypted connection is not fully assessable, it may be necessary to implement a network-based SSL inspection product. These devices effectively perform a hardware-accelerated Man-in-the-Middle attack on the encrypted traffic to allow full content inspection with minimal impact to network performance. |
| NRC RG 5.71, Control B.1.15, Network Access Control NRC’s regulatory Guideline 5.71 Control B.1.15 specifically recommends the use of Network Access Control techniques, including “MAC address locking, physical or electrical isolation, static tables, encryption, or monitoring.”z | Network access control is supported on most modern Ethernet switches and/or routers. If it is not, dedicated network access control (NAC) devices may be used. |
| For non-IP industrial control networks, access control can be provided by whitelisting known industrial behaviors based upon device IDs and industrial protocol function codes (see Chapter 4, “Industrial Network Protocols”). | |
| P4—Network and Perimeter Ports and Services | |
| NRC RG 5.71, Control B.1.16, “Open/Insecure” Protocol Restrictions Like NERC CIP-007-4 R2, NRC RG 5.71 Control B.1.16 requires that protocol use be limited and controlled on the network. However, Control B.1.16 acknowledges that many industrial protocols lack security controls, and therefore requires that additional precautions be taken when using these protocols, including mechanisms to prevent protocols from initiating commands across an enclave perimeter. aa | To secure against the malicious use of open or insecure protocols, all enclave perimeters should carefully control the protocols that are/are not allowed to communicate, so that insecure protocols are fully restricted to those areas where they are necessary. |
| In addition, to prevent unauthorized exploitation of or misuse of open or insecure protocols where they are allowed, an Industrial Control System Firewall, SCADA IPS, or Industrial Protocol Filter should be used that is capable of full protocol, session, and application monitoring, so that any misuse of these protocols will be detected. | |
| For example, Industrial Protocol filter may be able to allow or deny industrial protocol traffic based upon the specific function codes contained within the protocol frame (see Chapter 4, “Industrial Network Protocols”), effectively preventing that protocol from initiating commands across an enclave boundary. | |
| aNorth American Reliability Corporation, Standard CIP-003-4—Cyber Security—Security Management Controls. < http://www.nerc.com/files/CIP-003-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| bNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| cDepartment of Homeland Security, Risk-Based Performance Standards Guidance, Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| dInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| eIbid. | |
| fU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| gK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.2.4 Configuration Management, September 2008. | |
| hNational Institute of Standards and Technology, Special Publication 800-53 Revision 3, Recommended Security Controls for Federal Information Systems and Organizations, August 2009. | |
| iNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| jU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| kNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| lIbid. | |
| mDepartment of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| nInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| oIbid. | |
| pU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| qIbid. | |
| rIbid. | |
| sK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.2.6.2 Malicious Code Detection, September 2008. | |
| tDepartment of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| uIbid. | |
| vIbid. | |
| wIbid. | |
| xInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| yU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| zIbid. | |
| aaIbid. | |
| abK. Stouffer, J. Falco, K. Scarfone, National Institute of Standards and Technology, Special Publication 800-82 (Final Public Draft), Guide to Industrial Control Systems (ICS) Security, Section 6.3.2 Access Control, September 2008. | |
| acNational Institute of Standards and Technology, Special Publication 800-53 Revision 3, Recommended Security Controls for Federal Information Systems and Organizations, August 2009. | |
| Compliance Control | Recommendations |
|---|---|
| H1—Asset Configurations | |
| NERC CIP-003-4 R6, Change Control and Configuration Management Like many NERC CIP requirements, CIP-003-4 R6 is written in the context of establishing and documenting a process. However, CIP-003-4 R6 does specifically require organizations to “implement supporting configuration management activities to identify, control and document all entity or vendor-related changes to hardware and software components of Critical Cyber Assets.”a This could be accomplished manually, although configuration management tools would automate change identification, control, and documentation. | Configuration management and change control are important considerations for host security, as an unauthorized change from a “known good” configuration can negate host security controls. |
| Security configurations should be compared against an authorized configuration file and monitored for changes. Although many configuration files can be monitored using host OS auditing or external FIM products, a commercial Configuration/Change Management system (or a commercial security monitoring tool with integrated CM features) may be justified in networks with a large number of assets. | |
| NERC CIP-007-4 R3, Security Patch Management CIP-007-4 R3 specifically ties security patch management on individual cyber assets to the change controls required under CIP-003. Patch management requirements include tracking patches, evaluating them, and testing and implementing patches on all cyber assets within the ESP. b | Patch management should be performed in a separate, secure, and controlled environment; so that patches can be obtained free of risk (i.e., no open communications are established from live production networks to the Internet) and so that adequate testing and verification of patches can be performed prior to implementation (see Chapter 6, “Vulnerability and Risk Assessment”). |
| CFATS RBPS Metric 8.8.2, Cyber Asset Identification CFATS Metric 8.8.2 requires that all “hardware, software, information, and services” have been identified and that all unnecessary items have been disabled, and requires that any remaining vulnerabilities be accommodated by compensating security controls. c This implies that in addition to ports and services on a particular asset, an entire asset or system may need to be removed if it is determined to be unnecessary. | Metric 8.8.2 requires a conglomeration of asset and vulnerability identification, all of which are met through a combination of network discovery and vulnerability assessment, as discussed in Chapter 6, “Vulnerability and Risk Assessment.” |
| ISO/IEC 27002:2005, Control 10.1.2, Change Management The change management controls defined under ISO/IEC 27002:2005, Control 10.1.2, requires change management for all information processing facilities, and the provided guidance includes the identification of changes, the assessment of any potential impacts of those changes, and a system to generate detailed reports of all changes—to support an audit log of all change activity as well as to notify “relevant persons” when changes occur. d | Monitoring configuration files using host file system auditing (e.g., Linux auditd), and/or a commercial configuration management or change management system will identify change activities, as well as produce necessary reports and audit trails. |
| By comparing new configurations against authorized configurations, configuration assurance is provided. This comparison may be performed manually using host tools (e.g., diff), and/or a commercial configuration management or change management system. File comparisons may also be a supported feature of certain SIEM or Log Management systems. Unauthorized changes may be an indication of malicious activity, as many attacks will attempt to alter network or security settings, add or change user credentials, or make other configuration changes as part of the attack process. | |
| ISO/IEC 27002:2005, Control 12.6.1, Control of Technical Vulnerabilities ISO/IEC 27002:2005’s control of Technical Vulnerabilities is in-line with other vulnerability controls, requiring that vulnerabilities be identified, evaluated, and addressed and that “appropriate, timely action should be taken in response to the identification of potential technical vulnerabilities.”e Specific guidance offered includes maintaining a complete inventory of all assets, including details about installed software and version numbers/patches of the software. | The Control of Technical Vulnerabilities is similar to other vulnerability assessment and patching controls, with the additional guidance of providing “timely” information about vulnerabilities, as well as “timely” action when vulnerabilities are identified. |
| This implies that vulnerability assessment should occur frequently, so that developing vulnerabilities can be quickly identified and remediated. By performing ongoing Vulnerability Assessments against a segregated test environment, frequent scans are possible without introducing risk to production systems. | |
| NRC RG 5.71, Control B.5.3, Changes to File System and Operating System Permissions The NRC outlines clear asset configuration management requirements, including the file system and operating system permissions controls in NRC RG 5.71, Control B.5.3, which requires least-privilege access to “data, commands, files and account[s]” for both users and system services, as well as the documentation of any changes to access permissions or other security settings. f | This control requires that strong user/access policies are in place to prevent unnecessary privileged access, which will limit the impact of a compromised user account (or the actions of a disgruntled employee) to the least possible scale. |
| Change management requirements are included to ensure that privilege escalations do not occur—which can be enforced using configuration file auditing and/or a commercial change management system. Validation is also possible by monitoring account changes as they are represented in system and application logs, and/or in application contents (by directly monitoring applications for account commands). | |
| NIST SP 800-82, Network Architecture Control 6.2.4, Configuration Management NIST’s recommendations for configuration control include restricting access configuration settings, and setting security controls to the “most restrictive mode,” with specific guidance for “maintaining, monitoring, and documenting configuration control changes.”g | Monitor configuration files for indications of manipulation or change, via local file system auditing and/or a commercial CM system. This recommendation is almost identical to the corresponding NRC regulation 5.71 Control B.5.3, although it specifically references NIST Special Publication 800-53 for CM guidance, which identifies nine areas of configuration control: policies and procedures; baseline configurations; change control; security impact analysis; access restrictions for change; configuration settings; least functionality; IS component (asset) inventory; and the establishment of a configuration management plan. h |
| NIST SP 800-82 Control 6.2.4 also refers to the extensive configuration management guidance provided within the Configuration Management (CM) section of NIST SP 800-53, “Recommended Security Controls for Federal Information Systems and Organizations.” | |
| H2—Ports and Services | |
| NERC CIP-007-4 R2, Ports and Services CIP-007-4 R2 mandates that only required ports and services be enabled on a cyber asset (and that there is a documented process to ensure it). i | Unnecessary ports and services should be detected and disabled as part of earlier configuration and vulnerability assessments—and regular assessments can be used to further validate that only necessary services are in operation. |
| However, malicious code will commonly open new ports or enable new services, requiring a continuous assessment of ports and services in order to truly ensure that only authorized services are in use. This can be accomplished by monitoring network activity in addition to host and perimeter configurations. Network flow analysis will clearly indicate which ports are actively in use, and can be used to generate an alarm when an unknown or unauthorized port is used (see Chapter 9, “Monitoring Enclaves”). | |
| NRC RG 5.71, Control B.5.1, Removal of Unnecessary Services and Programs Like NERC CIP-007-4 R2, the NRC’s guidelines call for the removal of all unnecessary ports and services. However, the NRC goes further in defining “applications, utilities, system services, scripts, configuration files, databases, and other software and the appropriate configurations, including revisions or patch levels, for each of the computer systems associated with the CDAs.”j | This control supports the concept of application whitelisting by requiring that known good applications are identified and documented, and that all other applications are removed. |
| This can be achieved using AWL, which will also then prevent new software or services from being installed or executed in the future. | |
| Apart from the added detail about the types of unnecessary items that must be removed or disabled, NRC RG 5.71 Control B.5.1 also specifies that patches be included in the assessment of “necessary” elements to prevent potential disruption of service or weakening of the security controls caused by the implementation of an unnecessary software patch. | “Whitelisting” can also be achieved by documenting known good applications and using this list as a variable that can be referenced by threat detection and network monitoring tools. |
| For example, Vulnerability Assessment scanners (which will probe the assets directly) will detect most applications that are in use. | |
| Application traffic on the network can also be detected by network monitoring tools. Network connections can be mapped to applications based upon the TCP/UDP port; if there is traffic on these ports, the corresponding application is in use. | |
| For critical environments, application monitoring will provide a deeper look into application traffic. This will help detect applications running over nonstandard ports, applications that are masquerading as other applications, and even malware operating covertly inside of other applications. | |
| By comparing real-time application activity with the defined list of authorized applications, security administrators can be alerted of unauthorized application use. | |
| H3—Anti-Malware | |
| NERC CIP-007-4 R4, Malicious Software Prevention NERC CIP-007-4 R4 technically requires the use of “antivirus software and other malicious software (“malware”) prevention tools,”k indicating that at least two Anti-Malware controls should be implemented where technically feasible. However, while the wording of NERC CIP-007-4 R4 makes it difficult to determine which specific security controls should be implemented, its intentions are clear: to “detect, prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber Assets within the Electronic Security Perimeter(s).”l | NERC CIP-007-4 R4 specifically requires the use of antivirus software. However, antivirus software requires regular patching and verification. Consider using Application Whitelisting instead, although a technical feasibility exception may be required as a result. |
| Many AWL products are able to operate in fully isolated environments once properly configured, and require minimal patching (they only need to be updated when new software is applied to the host). | |
| CFATS RBPS Metric 8.5.1, Cyber Security Controls The DHS’ Risk-Based Performance Standards do not specify or recommend specific Anti-Malware controls, only that controls must be implemented to prevent malicious code from exploiting critical systems. However, RBPS Metric 8.5.1 goes somewhat further to require that appropriate security patches and updates are tested and applied “as soon as possible.”m This is an important consideration, especially using AV systems that can only protect against known malware definitions, making AV patching an important necessity. | This control is similar to NERC CIP-007-4 R4, except that it does not specifically call out antivirus software, using the more general label of “malicious code” prevention. This allows the implementation of alternate controls such as Application Whitelisting. AWL will also facilitate the testing and patching of updates, as AWL profiles typically only require updating to accommodate other upgrades (i.e., unless you upgrade an authorized application, the AWL does not need to be regularly patched to protect against malware). |
| ISO/IEC 27002:2005, Control 10.4.1, Controls Against Malicious Code ISO/IEC 27002:2005’s contribution to Anti-Malware methods can be found in Control 10.4.1, which requires that “Detection, prevention, and recovery controls to protect against malicious code” are implemented, along with “appropriate user awareness procedures.”n | Utilize an antivirus system for strict adherence with this control, which requires “detection and repair.” Application Whitelisting (AWL) is also an adequate control for preventing malware, although malicious code repair is not a function of most AWL systems. |
| Note the inclusion of change management controls specific to Anti-Malware efforts, indicating that Anti-Malware systems should be closely monitored and maintained as part of formal assessment and patching. This is necessary to ensure that the Anti-Virus software is up to date, and that it is using the most current malware detection signatures. | |
| The specific guidance of Control 10.4.1 again calls out awareness as a control against malware (which is true, considering that a significant amount of infections still occur through phishing attacks). Guidance also recommends that system access and change management controls be used to protect against malware. o | |
| NRC RG 5.71, Control B.5.2, Host Intrusion Detection System The NRC’s host security recommendations extend to the use of Host Intrusion Detection Systems. Specifically, a HIDS should be configured to detect “dynamic file name patterns, system and user accounts, execution of unauthorized code, host utilization, and process permissions, to enable the system to detect cyber attacks.” In other words, the HIDS should be configured to detect known malware and exploit patterns, and to alert security personnel when an event occurs. p | The requirement that the HIDS be configured to prevent the execution of “unauthorized code” implies that whitelisting behavior is preferred over blacklisting behavior. Although AWL is not specifically mentioned, traditional antivirus systems are blacklisting systems, where only code that is explicitly defined as bad is blocked. Whitelisting reverses this by defining what is good. This can be achieved through careful hardening of the host using a strong permissions-based operating system such as Linux, and/or through the use of an application whitelisting agent, which watches system files and low-level code execution (and in many cases memory-resident code as well). |
| NRC RG 5.71 Control B.5.2 also recommends specific logging methods to ensure event log integrity and requires that HIDS rule updates are performed to keep the HIDS in-line with known threat patterns. q | Interestingly, the requirement also states that the HIDS should not adversely impact operations, r which may be an acknowledgement to the potential application latency imposed by some AWL solutions. Proper testing and evaluation of whitelisting solutions should resolve any concerns. |
| The requirement that the HIDS create logs supports the need for situational awareness (provided by holistic log review) and accountability (via an audit trail). | |
| Of additional interest is the inclusion of specific guidance for upgrades and patching, which suggests the use of traditional AV vs. AWL. With adequate host Anti-Malware in place (see Chapter 7, “Establishing Secure Enclaves”), RG 5.71 Control B.5.2 should be satisfied regardless of the type of HIDS that is implemented. | |
| NIST SP 800-82, Network Architecture Control 6.2.6.1, Malicious Code Detection NIST SP 800-82 also identifies the need for host-based security and recommends the use of an antivirus, defined as a product that “evaluate[s] files on a computer’s storage devices against an inventory of known malware signature files. If one of the files on a computer matches the profile of a known virus, the virus is removed through a disinfection process (e.g., quarantine, deletion), so it cannot infect other local files or communicate across a network to infect other files,” going on to point out that “antivirus software can be deployed on workstations, servers, firewalls, and handheld devices”—an important consideration as mobile devices become more ubiquitous. s | Control 6.2.6.1 identifies antivirus products specifically, precluding AWL or other HIDS solutions. However, consider utilizing these additional measures in addition to antivirus in order to better secure critical hosts. This control specifically requires the protection of handheld devices—which is valid advice and an acknowledgement that mobile devices (such as smart phones) can be an inbound vehicle for malware. |
| H4—Authentication | |
| CFATS RBPS Metric 8.2.5, Password Management Password management controls, as defined by RBPS Metric 8.2.5, require that authentication methods are documented and enforced for all administrative and end user accounts, and that strong passwords are used (e.g., default passwords are not allowed). t Interestingly, RBPS Metric 8.2.5 allows for compensating controls to be implemented where changing a default password is “not technically feasible (e.g., a control system with a hard-coded password.”u | Implement a centralized authentication system (Active Directory or a Commercial IAM) to track user authentication requirements. |
| Monitor application contents (either via deep packet inspection via IPS or deep session inspection via an Application Monitor) for instances of weak passwords or known default passwords. | |
| Implement exception-based reporting using known good accounts as a whitelist of account behavior, to detect when legitimate but unknown or unauthorized authentications occur (e.g., a valid authentication against a hard-coded password, as used by Stuxnet). | |
| CFATS RBPS Metric 8.3.2, Unique Accounts RBPS Metric 8.3.2 extends the provisions of Metric 8.2.5, which prohibit the use of default accounts, by requiring that unique accounts be used for all users and administrators, and prohibiting the sharing of accounts. The exception is “in instances where users function as a group (e.g., control system operators) and user identification and authentication is role based, then appropriate compensating security controls (e.g., physical controls) have been implemented.”v | Usernames can be extracted from any monitoring system capable of examining authentications (i.e., packet—or session deep packet inspection, database or application monitoring, application log monitoring, IAM monitoring, etc.). |
| The correlation of usernames and network flows can be used to identify where accounts are being shared across multiple physical consoles. | |
| Where multiple users are sharing a single physical console, alternate measures will need to be implemented, as there is no adequate cyber separation of user activity. | |
| CFATS RBPS Metric 8.3.4, Access Control Lists RBPS Metric 8.3.4 further strengthens access control by requiring that an access control list be maintained, and by ensuring that administrative accounts are adjusted or deleted as appropriate when an administer leaves the organization or otherwise no longer requires access. w | Although access control lists are often thought of in terms of network switches and routers, host ACLs are an effective way to limit access to a particular asset. |
| Validation of active accounts can be done by monitoring the authentication activity on the network and correlating that information against centralized account management systems such as Active Directory, or a commercial IAM. | |
| ISO/IEC 27002:2005, Control 11.2.1, User Registrations ISO/IEC 27002:2005 requires the use of a formal “registration and de-registration” procedure to ensure the accuracy of all access privileges to information systems. Guidance includes the use of unique user IDs, and evaluation of user and system access privileges with the business or system owner, removing access privileges from users who no longer need them, checking for and removing duplicate accounts, and similar procedural controls. x | These functions are supported by most IAM systems, including the centralization of user accounts and the normalization of multiple accounts to a common user identity; the roles and privileges of that user; and the ability to centrally apply, ensure, or revoke privileges. |
| NRC RG 5.71, Control B.1.3, Access Enforcement NRC RG 5.71’s Access Enforcement Controls (B.1.3) require that authorized access is only provided in accordance with established procedures. Specific security controls that are required under B.1.3 include the use of “dual authorization” for critical privileged functions and the creation of any privileged account. y | The NRC’s guidance for access control extends beyond most authentication controls by adding controls that specifically require dual authorization for critical access, and by requiring that authentication methods should not interfere or adversely impact performance of the operational system being authenticated to. |
| Although many authentication and access control recommendations can be met using a commercial IAM platform, the dual-authorization requirement should ideally use a separate set of credentials that are managed separately. In this way, a successful enumeration attack against the IAM itself would not compromise access to these critical systems. | |
| NRC RG 5.71, Control B.4.2, User Identification and Authentication NRC RG 5.71 Control B.4.2 specifically requires the implementation of “identification and authentication technology to uniquely identify and authenticate individuals and processes acting on behalf of users interacting with CDA and ensuring that CDAs, security boundary devices, physical controls of the operating environment, and individuals interacting with CDAs, are uniquely identified and authenticated and that all processes acting on behalf of users are equally authenticated and identified; ensuring that the authentication technology employs strong multifactor authentication using protected processing levels.”z | This control requires that users are uniquely identified and authenticated—a function of IAM systems where multiple accounts can be reconciled to a common human user identity. |
| However, the requirement to track user activity (including applications that are authenticating on behalf of a user) can present challenges. For example, if a poorly written application uses account pooling (where many users authenticate to the application, but then the application authenticates to a backend system using a single account), the original user identity can be lost. | |
| This challenge can be resolved by correlating logs from all stages of authentication. However, to correctly log backend authentications, a database monitoring tool or custom software agent may be required. | |
| If the application in question is customizable, strengthening the backend authentications to include session details and user credentials is advisable. | |
| NRC RG 5.71, Control B.4.3, Password Requirements NRC RG 5.71 Control B.4.3 extends the strength of Identification and Authentication controls of B.4.2 by requiring the use of strong passwords and secure password management. B.4.3 defines a strong password as having a “length and complexity commensurate with the required security,” and requires that passwords be changed regularly. In addition, master passwords must be stored securely, and any authorization to change master passwords must be strictly controlled.”aa | Strong password requirements may be implemented and maintained using a common authentication or IAM system, which will provide the necessary password strength controls as well as password storage and recovery controls. |
| In addition to password management, active monitoring for password violations—including weak passwords or default passwords—is recommended as an additional checksum to ensure that only strong passwords are in use, even if there are misconfigurations or errors in password provisioning at the central IAM. | |
| NIST SP 800-82, Network Architecture Control 6.3.2, Access Control NIST SP 800-83 refers access control requirements back to NIST SP 800-53’s Access Control (AC) recommendations, which “specifies controls for managing information system accounts, including establishment, activating, modifying, reviewing, disabling, and removing accounts [and] cover access and flow enforcement issues such as separation of duties, least privilege, unsuccessful login attempts, system use notification, previous logon notification, concurrent session control, session lock, and session termination.”ab | NIST SP 800-53 Access Control recommendations are thoroughly defined, consisting of 22 individual controls, including requirements to monitor established sessions to enforce time-outs, break inactive sessions, etc. to enforce postauthentication access control. ac |
| aNorth American Reliability Corporation, Standard CIP-003-4—Cyber Security—Security Management Controls, < http://www.nerc.com/files/CIP-003-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| bNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s), < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| cNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| dIbid. | |
| eU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| fIbid. | |
| gIbid. | |
| hIbid. | |
| iNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| jIbid. | |
| kIbid. | |
| lDigitalBond, Inc. Bandolier and NERC CIP. < http://www.digitalbond.com/tools/bandolier/bandolier-and-nerc-cip/> (cited: March 3, 2011). | |
| mNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| nIbid. | |
| oW. Baker, M. Goudie, A. Hutton, C.D. Hylender, J. Niemantsverdriet, C. Novak, et al. 2010 Data Breach Investigations Report, Verizon. < http://www.verizonbusiness.com/resources/reports/rp_2010-data-breach-report_en_xg.pdf>, 2010 (cited: March 3, 2011). | |
| pNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| qIbid. | |
| rDepartment of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| sIbid. | |
| tInternational Standards Organization/International Electrotechnical Commission (ISO/IEC). INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information Technology—Security Techniques—Code of Practice for Information Security Management, first edition 2005-06-15. | |
| uIbid. | |
| vIbid. | |
| wU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| xNorth American Reliability Corporation, Standard CIP-005-4—Cyber Security—Electronic Security Perimeter(s). < http://www.nerc.com/files/CIP-005-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| yNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| zIbid. | |
| aaIbid. | |
| abIbid. | |
| acDepartment of Homeland Security, Risk-Based Performance Standards Guidance; Chemical Facility Anti-Terrorism Standards (CFATS), May 2009. | |
| adInternational Standards Organization/International Electrotechnical Commission (ISO/IEC), INTERNATIONAL ISO/IEC STANDARD 27002:2005 (E), Information technology—Security techniques—Code of practice for information security management, first edition 2005-06-15. | |
| aeU.S. Nuclear Regulatory Commission, Regulatory Guide 5.71 (New Regulatory Guide) Cyber Security Programs for Nuclear Facilities, January 2010. | |
| afIbid. | |
| agNorth American Reliability Corporation, Standard CIP-007-4—Cyber Security—Systems Security Management. < http://www.nerc.com/files/CIP-007-4.pdf>, February 3, 2011 (cited: March 3, 2011). | |
| ahN. Falliere, L.O. Murchu, E. Chien, Symantec. W32.Stuxnet Dossier, Version 1.1, October 2010. | |
| Compliance Control | Recommendations |
|---|---|
| S1—Asset Configurations | |
| NERC CIP-003-4 R6, Change Control and Configuration Management NERC CIP-003-4 R6 concerns configuration and change controls of cyber assets and requires the implementation of “supporting configuration management activities to identify, control, and document all entity or vendor-related changes to hardware and software … ”a | To satisfy the requirement “to identify, control, and document all entity or vendor-related changes to hardware and software” requires that—whatever configuration management system is in place—adequate logs are produced to document any changes that may be made. |
| Ideally, those logs should be centrally collected and managed for compliance auditing purposes. | |
| NERC CIP-005-4 R4, Cyber Vulnerability Assessment NERC CIP-005-4 R4 requires the assessment, review, and documentation of vulnerabilities, including a review of ports and services in use, validity of access at perimeters, and identification of default accounts. Although the vulnerability assessment procedure required under CIP-005-4 R4 can be satisfied by an annual vulnerability assessment scan (either automated via a VA product or performed manually), many of these requirements can also be met—or at least facilitated—using continual network and security monitoring tools. “The Responsible Entity shall implement and document an electronic or manual process(es) for monitoring and logging access at access points to the Electronic Security Perimeter(s) twenty-four hours a day, seven days a week.”b | Although CIP-005-4 R4 does not specifically mention the configurations of assets, a vulnerability assessment should be the basis of all asset configurations, as it will identify open ports and services, unnecessary services that are in use, and possible vulnerabilities that should be fixed via a patch or by the removal of the software. |
| Outside of the vulnerability assessment process, security monitoring tools can be used to detect default passwords, weak passwords, account changes, violations of the electronic security perimeter, the presence of unauthorized ports and services, etc. Security monitoring should ideally be used in conjunction with a vulnerability assessment system, to correlate vulnerabilities identified by the VA tool with the activities being observed by the security monitoring tool(s). | |
| NERC CIP-007-4 R3, Security Patch Management NERC CIP-007-4 R3 requires the use of security patch management, or “compensating controls” where patches are not or cannot be installed. c | Patch management is a challenge in industrial networks due to the requirements to obtain and test patches in a controlled environment prior to deployment, and because of the minimal maintenance windows that are available for production upgrades in most industrial systems. |
| Therefore, the establishment of compensating measures—under the assumption that unpatched assets will continue to be present—is a sound practice to avoid noncompliance. These compensation measures could include the isolation of systems and least-privilege access controls to those systems. Establishing (and documenting) highly segmented and secured enclaves may be sufficient as a compensating measure (always verify compliance audit assumptions with a local, qualified compliance consultant). Regardless, security monitoring should be used to obtain a clear picture of all incidents or events surrounding the asset(s) in question, and to ensure the proper function of any compensating controls. The logs and events analyzed should also be retained for supporting documentation of the compensating controls. | |
| NERC CIP-007-4 R8, Cyber Vulnerability Assessment NERC CIP-007-4 R8 is an example of how security monitoring can be used to validate specific security controls. CIP-007-4 R8 requires documentation of a vulnerability assessment, the vulnerabilities that may have been identified, and a plan to remediate the vulnerability, including the execution status of that action plan.”d | Vulnerability assessments can be a useful aid to configuration assessment and management. Once configurations are established, tested, and locked down, there should no longer be any open vulnerabilities. In addition, central logging and monitoring software such as a Log Management system or SIEM will have assimilated the VA scan data, such that any new vulnerabilities, changes in software versions or patch levels, etc., will provide a clear indication that an asset has changed. This can be used to validate the results of configuration file monitoring or configuration management systems to ensure that only good configurations are in use. |
| By using a broader security monitoring solution to manage VA results (along with other relevant activities and events), the required VA documentation can be coupled with an audit trail of any changes made to remediate specific vulnerabilities. | |
| NRC 5.71, Control A.4.1.3, Vulnerability Scans and Assessments NRC requires a periodic vulnerability scanning and assessment to validate all security controls. Unlike NERC CIP, NRC RG 5.71 controls specify the “periodic vulnerability scanning and assessments of the security controls, defensive architecture and of all CDAs to identify NRC requires a periodic vulnerability scanning and assessment to validate all security controls. Unlike NERC CIP, NRC RG 5.71 controls specify the “periodic vulnerability scanning and assessments of the security controls, defensive architecture and of all CDAs to identify security deficiencies. The CST performs assessments of security controls and scans for vulnerabilities in CDAs and the environment [no less frequently than once a quarter] or as specified in the security controls in Appendices B and C to RG 5.71, whichever is more frequent, and when new vulnerabilities that could potentially affect the effectiveness the security program and security of the CDAs are identified. In addition, the CST employs up-to-date vulnerability scanning tools and techniques that promote interoperability among tools and automate parts of the vulnerability management process.”e | NRC 5.71 specifically requires that vulnerability assessment scans be performed quarterly, and “when new vulnerabilities … are identified,”f which necessitates (potentially) very frequent scanning. In addition, NRC 5.71 requires the “promotion”g of interoperability among automation tools, validating the recommendation to use integrated event monitoring and VA solutions. |
| Most Log Management and SIEM solutions integrate with VA scanners to the extent that observed events within the infrastructure (from log and event sources) can be correlated against known vulnerabilities (from the most recent VA scan). To support this requirement, consider using the SIEM or Log Management solution to produce regularly scheduled exception reports—either daily or weekly—to indicate both open vulnerabilities on assets, as well as anomaly-based events that may indicate a new exploit against which vulnerability assessments have not been run. This latter report can then be used by a security analyst to assess whether there is sufficient evidence of “new vulnerabilities” to justify an interim vulnerability scan. | |
| NRC 5.71, Control A.4.2.1, Configuration Management NRC RG 5.71 Control A.4.2.1 ties the change management process and vulnerability assessment process together and “ensures that changes made are conducted using these configuration management procedures to avoid the introduction of additional vulnerabilities, weaknesses, or risks into the system.”h | NRC 5.71 Control 4.2.1 specifically requires that any change to an asset’s configuration requires additional vulnerability assessment of that asset. |
| This direct linking of CM and VM requirements further supports the promotion of an integrated solution that can manage configuration management as well as the integrated vulnerability assessment data and the event/alarm data promoted in Control 4.1.3. | |
| Although not hard requirements (the tasks could be performed manually using isolated systems), these recommendations for integrated security management indicate that a more advanced security management platform be used. At the time of this writing, there are commercial SIEM and Log Management solutions available that are evolving in this direction. | |
| S2—Documentation | |
| NERC CIP-005-4 R1, Electronic Security Perimeter NERC CIP requires extensive documentation, including the requirements of CIP-005-4 R1, which mandate the documentation of the ESP, including all assets within the ESP and all access points to the ESP, including access control and security monitoring assets that may be used. i | Controls such as CIP-005-4 R1, which require “documentation of assets,” may be streamlined using the same Log Management or SIEM systems used to manage the logs that the asset(s) produce. |
| Assets may also be detectable or discoverable using SNMP/In addition by producing logs, the asset(s) comprising the ESP are identified to the central reporting system. | |
| Finally, monitoring network flows can identify which asset(s) are deployed on either side of the ESP, as can extrapolation of source and destination IP addresses that may be present in firewall or IPS logs, generated by the ESP. | |
| NERC CIP-005-4 R3, Monitoring Electronic Access CIP-005-4 R3 requires a 24-hour, 7-day monitoring and documentation of electronic access at all access points to the ESP. j | Monitoring electronic access at the host level can be achieved by monitoring authentication to the host itself, and can be further scrutinized by monitoring application and/or database access. That is, the human operator logs into the host machine (host authentication logs), launches an application and logs into it (application authentication logs), and as the user performs tasks (application activity logs), the application itself will typically connect to a backend database (database authentication logs). |
| Note that each monitored authentication may use a different set of credentials, which can make it difficult to track a session from the end user to the backend system(s) without the aid of an identity management system. | |
| For unauthenticated access, most commercial VA scanners will be able to identify vulnerabilities through which access might be obtained, and are able to produce comprehensive reports indicating the results of such a scan. | |
| NERC CIP-005-4 R4, Cyber Vulnerability Assessment NERC CIP-005-4 R4 mandates that the results of a vulnerability be documented, that a plan be documented to remediate any vulnerabilities found, and that the status of that plan also be documented. k | Most commercial VA scanners are able to produce comprehensive reports indicating the results of the scan. The Bandolier project by Digital Bond (www.digitalbond.com) provides a plug-in to the Nessus VA scanner to map the results of the vulnerability assessment to specific NERC CIP controls. l |
| Although no tool can automate the generation of an organizational procedure, the actions taken to execute a remediation plan can be monitored and logged to produce a viable audit trail of the remediation activities. This could include the application of patches, disabling of ports or services, etc. | |
| NERC CIP-005-4 R5, Documentation Review and Maintenance NERC CIP-005-4 R5 requires that all of Electronic Security Perimeter requirements, including access points to the ESP, access controls, and monitored access to the ESP up to and including individual user access to the ESP, be documented and that all relevant logs are maintained and reviewed. m | In addition to the event logs of ESP devices, which can easily be collected, reviewed, and retained, CIP-005-4 R5 requires that all individual user account access activity (i.e., authentications) be monitored and logged. To meet minimal compliance requirements, simple log reports of account authentications from VPNs, network access controls, and other relevant logs are likely to be sufficient. Although CIP-005-4 R5 does not necessitate that actual end user identities are tracked (i.e., there is no need to determine how specific user accounts map back to human operators), user account normalization is recommended, as it will facilitate incident detection as well as incident reporting if/when an incident does occur. |
| Like most NERC CIP documentation requirements, CIP-005-4 R5 requires that all logs be retained for a period of 90 days. However, if a log is determined to be associated with a cyber incident, the required retention period increases to 3 years. n | |
| According to the 2010 Verizon Data Breach Report, the majority of incidents are not detected for months after they occur. o Because any “benign” log could be associated with an incident long after the minimum 90-day period, it is recommended that all logs are retained for the full 3 years required by NERC CIP-008-4 R2. | |
| NERC CIP-007-4 R2, Ports and Services NERC CIP-007-4 R2 requires that only those ports and services that are allowed are enabled, and that processes are put in place to ensure that unauthorized ports and services are not in use. p | The documentation of those ports and services that are enabled requires either a manual assessment of assets or the use of a vulnerability assessment scanner. Most VA tools have documentation and reporting features to facilitate this type of documentation requirement. |
| However, malicious code will commonly open new ports or enable new services, requiring a continuous assessment of ports and services in order to truly ensure that only authorized services are in use. This can be accomplished by monitoring network activity in addition to host and perimeter configurations. Network flow analysis will clearly indicate which ports are actively in use and can be used to generate an alarm when an unknown or unauthorized port is used (see Chapter 9, “Monitoring Enclaves”). | |
| Unauthorized ports and services that are in use should be immediately remediated. | |
| NERC CIP-008-4 R2, Cyber Security Incident Documentation NERC differentiates between standard activity logs (what might be thought of as “events” by information security analysts) and identified Cyber Security Incidents. Although most documentation only needs to the retained for 90 days, documentation that is relevant to a Cyber Security Incident must be retained for 3 years. q | CIP-008 R2 presents a “worst case” requirement for log retention for 3 years, mandated for any log associated with a cyber security incident. As mentioned above in regards to NERC CIP-005-4 R5, even “benign” logs that are not initially related to a cyber security incident could be associated with an incident after the minimum 90-day retention period is over. If the log is discarded after 90 days, insufficient evidence may be available to adequately document an incident when/if one occurs. Therefore, it is recommended that all logs are retained for the full 3 years required by NERC CIP-008-4 R2. |
| CFATS RBPS Metric 8.5.4, Incident Reporting CFATS RBPS Metric 8.5.4 illustrates a common reporting requirement across many compliance standards, which is that all incidents must be reported to a higher authority. In the case of Metric 8.5.4, incidents must be reported to senior management and to the DHS’s US-CERT at www.us-cert.gov.”r | Incident reporting controls such as RBPS Metric 8.5.4 can often be met using the alarm or notification functions of information management systems. |
| First, define notification lists of important administrators and/or outside agencies that must be notified of an incident. | |
| Define a report containing the necessary summary information of the suspected incident, and configure the security tool (typically a SIEM) to automatically distribute the summary report to the responsible entities. | |
| The report template should include the contact information for the next level of escalation, as well as incident handling and escalation procedures, thereby automating incident reporting procedures at several layers of authority. | |
| CFATS RBPS Metric 8.9.1, Audits As with Metric 8.5.4, Metric 8.9.1 involves the communication of security information to senior management. Where Metric 8.5.4 concerns specific incidents, Metric 8.9.1 concerns the delivery of the results of regularly conducted audits against the facility’s cyber security policies. s | As with Control 8.5.4, the security information management tool used to collect and report on relevant security data can and should be configured to distribute reports to appropriate managers and/or other authorities, as needed. |
| ISO/IEC 27002:2005, Control 10.10.1, Audit Logging ISO/IEC 27002:2005 controls for Audit Logging require that logs recording “user activities, exceptions, and information security events” should be collected and retained for an undefined period. Further guidance suggests that these audit logs should include a variety of details including user IDs, dates, times, terminal identities, authentication results, configuration changes, application use, and many other relevant security events. t | The required information can be obtained by collecting security events and by monitoring users, networks, hosts, applications, and/or database transactions and configuration files as detailed in Chapter 9, “Monitoring Enclaves.” |
| Note that Control 10.10.1 requires that audit logs should include many details that are not typically provided by all logs. | |
| This can be addressed through event enrichment, by correlating logs together based upon common indicators and either adding additional detail to the log at the time of collection, or providing the additional context at the time of analysis (i.e., when the report is generated). See Chapter 8, “Exception, Anomaly, and Threat Detection,” for more information about data enrichment. | |
| ISO/IEC 27002:2005, Control 13.1.1, Reporting Information Security Events ISO/IEC Control 13.1.1 requires that security events be reported to higher levels of authority within the organization. The control also recommends that an established point of contact should be used, and that he or she should be identifiable and accessible. u | As with CFATS RBPS Metric 8.5.4, ISO/IEC 27002:2005’s reporting controls can be facilitated through simple configurations to the security information reporting system (typically a Log Management or SIEM solution). |
| By defining notification lists of responsible managers and using these lists for automated incident notifications, the incident will be “reported as quickly as possible,” in that it will occur automatically at the time of detection. | |
| Limiting these incident reports to summary information of the suspected incident and including escalation procedures with additional contact information included allows responsible staff to assess, approve, and forward incident reports upward through the management chain as is necessary, with minimal delay. | |
| ISO/IEC 27002:2005, Control 13.2.3, Collection of Evidence ISO/IEC 27002:2005, Control 13.2.3 concerns the ability to produce evidence of a cyber security incident where required for legal action. v | Although many compliance controls require security logs and information to be stored in a secure manner, with considerations made for nonrepudiation, ISO/IEC 27002:2005, Control 13.2.3 specifically requires that this information be retrievable for presentation to some judicial authority. |
| The operational consideration here is that among potentially billions of stored logs, finding all the relevant logs (and only the relevant logs) related to a particular incident can be daunting. | |
| As is often the case, there are a variety of tools available to facilitate this task: from ubiquitous tools such as grep, to log search or “IT search” products, to both open-source and commercial Log Management and SIEM products—all of which provide a means of searching through large volumes of log files, to provide a single relevant filtered log cache. | |
| NRC RG 5.71, Control C.5, Records Retention and Handling NRC RG 5.71 requires the establishment of procedures to ensure that all necessary records are developed, reviewed, and retained. Control C.5 specially requires that a facility retain records including, but not limited to, “all digital records, log files, audit files, and nondigital records that capture, record, and analyze network and CDA events. These records are retained to document access history and discover the source of cyber attacks or other security-related incidents affecting CDAs or SSEP functions or both. [Licensee/Applicant] will retain superseded portions of these records for at least 3 years after the record is superseded, unless otherwise specified by the NRC.”w | Monitoring activities and events in the industrial infrastructure provides the necessary digital records, log files, and audit files to partially satisfy NRC RG 5.71, Control C.5, as well as most other record retention requirements from other compliance standards. |
| Although logs and events cannot measure or document the formation or implementation of a security plan per se, certain logs can also be used to support the requirements to show how certain activities were managed, reviewed, reacted to, and completed. For example, many SIEM systems include workflow integration with help desk ticketing systems, or they may provide limited ticketing systems as a core function of the SIEM. By logging these SIEM-derived activities along with network-derived logs and events, a broader array of governing procedures and policies can be audited. | |
| S3—Monitoring | |
| NERC CIP-005-4 R3, Monitoring Electronic Access NERC CIP-005-4 R3 specifically requires that electronic access be monitored at all access points to the ESP. x | Security perimeters are often thought of in terms of what is not allowed, and as a result, alerts generated by most perimeter security devices (firewalls, IPS, etc.) typically involve traffic that was denied access at the perimeter. |
| However, the requirement to monitor and log access at access points to the Electronic Security Perimeter requires that alerts are generated, collected, and retained that pertain to traffic that is allowed access at the perimeter. | |
| Depending upon the nature of the enclave being secured, this could result in a significant number of alerts; for excample, if a business intelligence server is communication constantly with one or more HMI systems, there will a cotinuous number of new sessions established through the ESP | |
| Network flow analysis can also be used to indicate access to/through an ESP. By logging flow records that originate and terminate on different sides of the perimeter. | |
| To accommodate this additional event (and/or flow) load, consider using event aggregation (see Chapter 9, “Monitoring Enclaves”) to reduce the total number of collected events. Alternatively, further separate assets into more specialized functional groups, in order to reduce the number of inbound and outbound traffic to any given enclave (see Chapter 7, “Establishing Secure Enclaves”). Note that in the latter case, the total number of access alerts will remain the same and will still need to be supported and managed by a properly sized Log Management or SIEM system. However, the additional level of distribution may facilitate event collection. | |
| NERC CIP-007-4 R5 Account Management NERC CIP-005-4 R5 requires the establishment of procedures to generate logs “of sufficient detail to create historical audit trails of individual user account access activity for a minimum of ninety days.”y | Although auditing account activity is typically thought of in terms of authentication logs produced by individual servers or applications, or in other cases by a centralized directory or authentication system, account activities can also be directly monitored. |
| Certain monitoring tools such as Database Monitors, Protocol Monitors or Filters, and Application Monitors can detect and log authentications as they occur, via the capture and decoding of network traffic. | |
| This provides a valuable verification that authentication logs are valid and can also help to ensure that authentications do not use default or weak credentials. | |
| NERC CIP-007-4 R2, Ports and Services NERC CIP-007-4 R2 requires the implementation of a process to ensure that only authorized ports and services are in use. z | It is possible to monitor for ports and services that are actively in use within the network. |
| This level of monitoring will detect ports and services that may have been enabled after the initial asset inventory and assessment has been completed, and so is recommended even when manual assessments have been made. | |
| Network flow monitoring is most useful for this, as it will also indicate the source and destination IP address of the communication, in order to identify the assets that are using unauthorized ports and services. | |
| Unauthorized ports and services that are in use should be immediately remediated. | |
| NERC CIP-007-4 R6, Security Status Monitoring NERC CIP-007-4 R6 provides a clear mandate for security monitoring, requiring that all cyber assets within the ESP “implement automated tools or organizational process controls to monitor system events that are related to cyber security.”aa | “Automated tools” to monitor security events seem to clearly indicate the use of a Log Management and/or SIEM system (see Chapter 9, “Monitoring Enclaves”). |
| Although NERC does not specifically call out the types of activities and events that require monitoring, the more vague requirement to monitor what is “related to cyber security”ab should be assumed to require user, host, network, application, change, and other events. | |
| CFATS RBPS Metric 8.5.2, Network Monitoring RBPS Metric 8.5.2 recommends the use of network monitoring to detect “unauthorized access or the introduction of malicious code,” and requires that immediate alerts be generated, that the resulting security logs be reviewed, and that alerts be responded to in a timely manner. Network monitoring may occur on-site or off-site. Where logging of cyber security events on their networks is not technically feasible (e.g., logging degrades system performance beyond acceptable operational limits), appropriate compensating security controls (e.g., monitoring at the network boundary) are implemented.”ac | RBPS Metric 8.5.2 requires network monitoring and deep packet inspection to detect unauthorized access or malicious code, that is, an Intrusion Detection System. However, there are some interesting exceptions: the first allowing on-site or off-site review of security events; and the second allowing for perimeter-only monitoring where network monitoring within an enclave is not feasible. |
| Because industrial systems and protocols are often sensitive to latency, and any in-line network monitoring or deep packet inspection will incur at least some degree of latency, it is foreseeable that such an exception will be justifiable in some cases. | |
| However, rather than removing network monitoring to the enclave perimeters, consider implementing an IDS, Industrial Protocol Filter, or Application Monitor within the enclave using passive deployment methods. For example, implement a network tap to “mirror” traffic that needs to be monitored to the monitoring device(s). In this way, the “live” traffic will remain untouched, with no impact caused by the network monitoring facilities. | |
| In addition, highly specialized industrial monitoring devices may be available that provide low-latency/low-impact in-line monitoring. | |
| ISO/IEC 27002:2005, Control 10.10.2, Monitoring System Use Control 10.10.2 of the ISO/IEC 27002:2005 Standard mandates procedures for monitoring the use of information systems, as well as for the regular review of the monitored activity (i.e., logs). This control provides further guidance for the areas of information systems that should be monitored, which include authorized user activities, failed authentications, system alerts or failures, and changes to security settings or configurations. ad | This control requires both positive alerts (alerts on successful admin access and all successful admin operations), negative alerts (system alerts and failures), and change events (configuration changes and attempted changes). |
| As with NERC CIP-005-4 R3, ISO/IEC 27002:2005, Control 10.10.2 will produce increased amounts of events, as both benign and malicious activities are logged. | |
| NRC RG 5.71, Control C.3.5, Security Alerts and Advisories NRC RG 5.71 introduces the concept of external monitoring, for the purpose of information gathering in order to strengthen existing security controls. Information sources that should be monitored include “security alerts, bulletins, advisories, and directives from credible external organizations as designated by the NRC.” Monitored information should then be evaluated to determine the scope and need of implementing new or modified security controls. ae | NRC RG 5.71 Control 3.5 incorporates external threat intelligence into security monitoring. This is a useful monitoring approach where updated threat lists can be used to dynamically populate “blacklist” security defenses. That is, the security devices such as firewalls, Intrusion Prevention Systems, protocol filters, etc. can block known sources of malware or other threats by matching against a dynamically populated variable. For example, Deny $ThreatList to Any rule would block any source in the $ThreatList variable. See Chapter 7, “Establishing Secure Enclaves,” for more information on blacklist policies. |
| NRC RG 5.71, Control C.4.1, Continuous Monitoring and Assessment For the monitoring of internal systems, the NRC provides guidance for ongoing security monitoring and assessment, which include the requirement that “Automated support tools are also used, as appropriate, to accomplish near-real time cyber security management,” including “Ongoing assessments to verify that the security controls implemented for each CDA remain in place throughout the life cycle; Verification that rogue assets have not been connected to the infrastructure; Periodic assessments of the need for and effectiveness of the security controls … [and the] Periodic security program review to evaluate and improve the effectiveness of the program.”af | Not surprisingly, the guidelines presented by NRC RG 5.71 focus on the continuous monitoring and the continuous assessment of cyber activities. |
| Here, rather than focusing on long-term information repositories for proof of compliance, the requirement is on the security of the network. | |
| NRC RG 5.71 Control C.4.1 also specifically requires network monitoring to detect the presence of rogue assets. This can be accomplished using most Network Management Systems but is also a good example of how security monitoring can be combined with anomaly detection techniques and correlation to detect policy violations. For example, an alert could be generated if the total number of Source IP Addresses seen within 24 hours of network flow records increases. In a business enterprise, this type of detection would likely result in a high percentage of false positives. In an industrial network, where operations are well defined and controlled, any variation could indicate the presence of rogue assets. | |
| S4—Authentication | |
| NERC CIP-007-4 R5, Account Management NERC CIP-007-4 R5 requires the establishment of procedures to generate logs “of sufficient detail to create historical audit trails of individual user account access activity for a minimum of ninety days.”ag | The requirement for user account and authentication activity logs is common among many compliance controls. Of note in NERC CIP-005-4 R5 is the term “sufficient detail” in regard to recreating an audit trail of user account activity. |
| This is important because of the inconsistencies in log formats. Where one log may clearly indicate a user account name and the results of authentication attempts, others may not. In addition, certain applications may pool user accounts, accessing backend resources through a common identifier and password, as was the case with Stuxnet. ah | |
| There is room for interpretation in “individual user accounts,” which could also be significant, as the ability to create an audit trail based on an individual user requires some method of normalizing user identities across multiple systems, while tracking user accounts would only require a distinct audit trail for each account; potentially tracking several accounts in parallel for a single end user (see the section “User Identities and Authentication” in Chapter 9, “Monitoring Enclaves”). | |
Perimeter Security Controls
Figure 10.1 and Table 10.1 map specific security controls to those requirements of the NERC CIP, CFATS, ISO 27002, NRC RG 5.71, and NIST SP 800-82 (draft) standards that are most relevant to perimeter security (see the section “Securing Enclave Perimeters” in Chapter 7, “Establishing Secure Enclaves”).
Caution
These mappings are only intended to provide a high-level awareness of how security and compliance interrelate. Although based upon the most recent publications of each relevant standard at the time of writing, they do not represent a comprehensive list of the requirements and recommendations for all controls. Specifically cited requirements are excerpts from the original standards documentation only and do not represent the full scope of the referenced standard. Recommendations are provided for the purposes of improving security; adherence to these recommendations does not guarantee compliance with any referenced standard. Always reference the most current publication of the original standards document(s) when planning regulatory compliance efforts.
Figure 10.1, Figure 10.2 and Figure 10.3 illustrate where specific compliance controls can be implemented within the network, whereas the corresponding Table 10.1, Table 10.2 and Table 10.3 then outline the corresponding controls and provide recommendations on how to implement appropriate security measures.
Figure 10.1 and Table 10.1 focus specifically on perimeter security controls and how they can be implemented to support regulatory requirements.
Host Security Controls
Figure 10.2 and Table 10.2 map specific security controls to those requirements of the NERC CIP, CFATS, ISO 27002, NRC RG 5.71, and NIST SP 800-82 (draft) standards that are most relevant to host security (see the section “Securing Enclave Interiors” in Chapter 7, “Establishing Secure Enclaves”).
Caution
These mappings are only intended to provide a high-level awareness of how security and compliance interrelate. Although based upon the most recent publications of each relevant standard at the time of writing, they do not represent a comprehensive list of the requirements and recommendations for all controls. Specifically cited requirements are excerpts from the original standards documentation only and do not represent the full scope of the referenced standard. Recommendations are provided for the purposes of improving security; adherence to these recommendations does not guarantee compliance with any referenced standard. Always reference the most current publication of the original standards document(s) when planning regulatory compliance efforts.
Figure 10.2 and Table 10.2 focus specifically on host security controls, and how they can be implemented to support regulatory requirements.
Security Monitoring Controls
Figure 10.3 and Table 10.3 map specific security controls to those requirements of the NERC CIP, CFATS, ISO 27002, NRC RG 5.71, and NIST SP 800-82 (draft) standards that are most relevant to security monitoring, log management, and situational awareness (see Chapter 9, “Monitoring Enclaves”).
Caution
These mappings are only intended to provide a high-level awareness of how security and compliance interrelate. Although based upon the most recent publications of each relevant standard at the time of writing, they do not represent a comprehensive list of the requirements and recommendations for all controls. Specifically cited requirements are excerpts from the original standards documentation only and do not represent the full scope of the referenced standard. Recommendations are provided for the purposes of improving security; adherence to these recommendations does not guarantee compliance with any referenced standard. Always reference the most current publication of the original standards document(s) when planning regulatory compliance efforts.
Figure 10.3 and Table 10.3 focus specifically on security monitoring and auditing controls, and how they can be implemented to support regulatory requirements.
Mapping Compliance Controls to Network Security Functions
As an additional reference for mapping compliance and security controls, Table 10.4 provides a reverse mapping, indicating which specific security functions are required by which compliance controls.
| Compliance Regulation | Category | Mapping | Chapter |
|---|---|---|---|
| NERC CIP-003-4 R6 | Asset Configurations | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| NERC CIP-003-4 R6 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-005-4 R1 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NERC CIP-005-4 R1.6 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NERC CIP-005-4 R2 | Access Control | P2 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| NERC CIP-005-4 R3 | Monitoring | P3 | Chapter 8, “Exception, Anomaly, and Threat Detection” |
| NERC CIP-005-4 R3 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-005-4 R3 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NERC CIP-005-4 R4.5 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-005-4 R4.5 | Asset Configurations | S2 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-005-4 R5.3 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NERC CIP-007-4 R5.1.2 | Authentication | S4 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R5.1.2 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R5.1.2 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NERC CIP-007-4 R2 | Ports and Services | H2 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| NERC CIP-007-4 R2 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R2 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NERC CIP-007-4 R3.2 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R3.2 | Asset Configurations | S2 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R4 | Asset Configuration | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| NERC CIP-007-4 R5 | Anti-Malware | H3 | Chapter 7, “Establishing Secure Enclaves” |
| NERC CIP-007-4 R6 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R8.4 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-007-4 R8.4 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NERC CIP-008-4 R2 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| CFATS RBPS Metric 8.2.5 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| CFATS RBPS Metric 8.3.2 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| CFATS RBPS Metric 8.3.4 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| CFATS RBPS Metric 8.5.1 | Anti-Malware | H3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| CFATS RBPS Metric 8.5.1 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| CFATS RBPS Metric 8.5.2 | Monitoring | P2 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| CFATS RBPS Metric 8.5.2 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| CFATS RBPS Metric 8.5.4 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| CFATS RBPS Metric 8.8.2 | Asset Configuration | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| CFATS RBPS Metric 8.9.1 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| ISO/IEC 27002:2005 Control 10.1.2 | Asset Configuration | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| ISO/IEC 27002:2005 Control 10.4.1 | Anti-Malware | H3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| ISO/IEC 27002:2005 Control 10.6.1 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| ISO/IEC 27002:2005 Control 10.10.1 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| ISO/IEC 27002:2005 Control 10.10.2 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| ISO/IEC 27002:2005 Control 11.2.1 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| ISO/IEC 27002:2005 Control 11.4.1 | Authentication | P3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| ISO/IEC 27002:2005 Control 11.4.2 | Authentication | P3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| ISO/IEC 27002:2005 Control 11.4.4 | Authentication | P3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| ISO/IEC 27002:2005 Control 11.4.5 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| ISO/IEC 27002:2005 Control 11.4.6 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| ISO/IEC 27002:2005 Control 11.4.7 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| ISO/IEC 27002:2005 Control 11.6.2 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| ISO/IEC 27002:2005 Control 12.6.1 | Asset Configuration | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| ISO/IEC 27002:2005 Control 13.1.1 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| ISO/IEC 27002:2005 Control 13.2.3 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NRC RG 5.71 Control A4.1 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NRC RG 5.71 Control A4.1.3 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NRC RG 5.71 Control A4.2.1 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NRC RG 5.71 Control A4.2.2 | Asset Configurations | S1 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NRC RG 5.71 Control A5 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
| NRC RG 5.71 Control B1.3 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control B1.4 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NRC RG 5.71 Control B1.4 | Authentication | P3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control B1.15 | Authentication | P3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control B1.16 | Ports and Services | P4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Perimeters” |
| NRC RG 5.71 Control B3.4 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NRC RG 5.71 Control B4.2 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control B4.3 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control B5.1 | Ports and Services | H2 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 8, “Exception, Anomaly, and Threat Detection” | |||
| NRC RG 5.71 Control B5.2 | Anti-Malware | H3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| NRC RG 5.71 Control B5.3 | Asset Configuration | H1 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NRC RG 5.71 Control C3.5 | Monitoring | S3 | Chapter 9, “Monitoring Enclaves: Determining What to Monitor” |
| NIST SP 800-82 Control 5.3.2 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NIST SP 800-82 Control 5.3.4 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NIST SP 800-82 Control 5.3.5 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NIST SP 800-82 Control 5.5 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NIST SP 800-82 Control 6.2.6.2 | ESP | P1 | Chapter 7, “Establishing Secure Enclaves” |
| NIST SP 800-82 Control 6.2.4 | Asset Configuration | H1 | Chapter 6, “Vulnerability and Risk Assessment” |
| NIST SP 800-82 Control 6.2.6.1 | Anti-Malware | H3 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| NIST SP 800-82 Control 6.3.2 | Authentication | H4 | Chapter 7, “Establishing Secure Enclaves: Securing Enclave Interiors” |
| Chapter 9, “Monitoring Enclaves: Determining What to Monitor” | |||
| NIST SP 800-82 Control 6.3.3 | Documentation | S2 | Chapter 9, “Monitoring Enclaves: Log Storage and Retention” |
Common Criteria and FIPS Standards
Unlike other standards, Common Criteria and FIPS aim to certify security products, rather than security policies and processes. The Common Criteria for Information Technology Security Evaluation (“Common Criteria” or “CC”) is an international framework that is currently recognized by Australia/New Zealand, Canada, France, Germany, Japan, the Netherlands, Spain, the United Kingdom, and the United States. 23 FIPS standards are defined by NIST in Federal Information Processing Standards Publications or FIPS PUBs. Although there are several FIPS standards, it is the FIPS 140-2 Standard that validates information encryption that is most relevant to information security products.
23.The Common Criteria Working Group, Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model, Version 3.1, Revision 3 Final, July 2009.
Common Criteria
Common Criteria’s framework defines both functional and assurance requirements, which security vendors can test against in order to validate the security of the product in question. 24 Certification by an authorized Common Criteria testing facility provides a high level of assurance that specific security controls have been appropriately specified and implemented into the product.
24.Ibid.
The evaluations required prior to certification are extensive and include the following:
• Protection Profiles (PP)
• Security Target (ST)
• Security Functional Requirements (SFRs)
• Security Assurance Requirements (SARs)
• Evaluation Assurance Level (EAL)
The Security Target defines what is evaluated during the certification process, providing both the necessary guidance during evaluation as well as high-level indication of what has been evaluated after an evaluation is complete. 25
25.Ibid.
The Security Targets are translated to the more specific Security Functional Requirements (SFRs), which provide the detailed requirements against which the various STs are evaluated. The SFRs provide a normalized set of terms and requirements designed so that different STs for different products can be evaluated using common tests and controls, to provide an accurate comparison.
When common requirements are established for a particular product type or category, typically by a standards organization, they can be used to develop a common Protection Profile (PP), which is similar to an ST in that it provides a high-level indication of the assessment, but different in that the specific targets are predefined within the PP. 26 For example, there is a Common Criteria Protection Profile for Intrusion Detection and Prevention Systems that defines the specific security targets that an IDS or IPS must meet to earn certification.
26.Ibid.
Perhaps the most commonly identified CC metric is the Evaluation Assurance Level, or EAL. EALs measure Development (ADV), Guidance Documents (AGD), Lifecycle Support (ALC), Security Target Evaluation (ASE), Tests (ATE), and Vulnerability Assessment (AVA). 27 There are seven total assurance levels, EAL 1 through EAL 7, each of which indicates a more extensive degree of evaluation against a more exhaustive set of requirements for each of these components. For example, to compare just one of the evaluation requirements (AVA, Vulnerability Assessment), CC EAL 1 provides a basic level of assurance, using a limited security target, and a vulnerability assessment consisting only of a search for potential vulnerabilities in the public domain. 28 In contrast, EAL 3 requires a “vulnerability analysis … demonstrating resistance to penetration attackers with a basic attack potential,”29 and EAL 4 requires a “vulnerability analysis … demonstrating resistance to penetration attackers with an Enhanced-Basic attack potential” (i.e., more sophisticated attack profiles for a more thorough vulnerability assurance level). 30 At the most extensive end of the certification assurance spectrum is EAL 7, which requires “complete independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential.”31
27.The Common Criteria Working Group, Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components, Version 3.1, Revision 3 Final, July 2009.
28.Ibid.
29.Ibid.
30.Ibid.
31.Ibid.
It is important to understand that the EAL level does not measure the level of security of the product that is under evaluation but rather measures the degree to which the product’s security is tested. Therefore, a higher EAL does not necessarily indicate a more secure system. It is the specific security target(s) being evaluated that indicate the functional requirements of the system. When comparing like systems that are tested against identical targets, the higher EAL indicates that those targets were more thoroughly tested and evaluated, and therefore, the higher EAL provides additional confidence in the proper and secure function of the system.
FIPS 140-2
The Federal Information Processing Standards Publication (FIPS PUB) 140-2 establishes the requirements for the “cryptographic modules” that are used within a cyber asset or system. There are four qualitative levels of FIPS validation, Levels 1 through 4, which like Common Criteria’s EALs intend to validate increasingly thorough assurance. With FIPS 140-2, this assurance is in the form of cryptographic integrity: basically, how resistant encrypted boundaries are to penetration. 32 FIPS 140-2 covers the implementation and use of Symmetric and Asymmetric Keys, the Secure Hash Standard, Random Number Generators, and Message Authentication. 33 The specific validation levels represent increasingly more stringent controls to prevent physical access to information with the encrypted boundary. For example, FIPS 140-2 Level 2 requires that data cannot be accessed, physically, even through the removal of disk drives or direct access to system memory. Level 3 provides stronger physical controls to prevent access to and tampering, even through ventilation holes, whereas Level 4 even accommodates environmental failures to protect the encrypted data against recovery during or following a failure. 34
32.National Institute of Standards and Technology, Information Technology Laboratory, Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.
33.Ibid.
34.Ibid.
Summary
Understanding how regulatory standards and regulations can impact the security of a network or system will help at all stages of industrial network security planning and implementation. For example, specific compliance controls might dictate the use of certain products or services to improve security, and/or how to configure specific security products.
The security products themselves are subject to regulation as well, of course. The Common Criteria standards provide a means for evaluating the function and assurance of a product in a manner designed to facilitate the comparison of similar products, whereas FIPS standards such as FIPS 140-2 can provide further validation of specific security functions (in this case, encryption) used by a product.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.