Notable Changes to NERC Reliability Standard CIP-005-5

Transcription

1 MIDWEST RELIABILITY ORGANIZATION Notable Changes to NERC Reliability Standard CIP Electronic Security Perimeter(s) Bill Steiner MRO Principal Risk Assessment and Mitigation Engineer MRO CIP Version 5 Workshop February 12 and 18, 2015 Improving RELIABILITY and mitigating RISKS to the Bulk Power System

2 Agenda New concepts introduced in CIP Electronic Security Perimeter Definition Bulk Electric System Cyber Systems Access Requirements Method(s) for detecting malicious communications NERC Lessons Learned 2

3 New Concepts Introduced in CIP Electronic Security Perimeter Focus on Electronic Security Perimeters (ESP) definition Security Requirements have moved to CIP-007 New terms defined (See NERC Glossary of Terms for full definition) PCA Protected Cyber Assets. These are non-bca which get BCA protection by nature of their network connectivity (High Water Mark). ERC External Routable Connectivity. Many of the applicable requirements are determined by the characteristic of having bi-directional routable connectivity outside of the ESP. EACMS Electronic Access Control or Monitoring Systems. Firewalls, authentication servers, log monitoring and alerting systems, etc. Interactive Remote Access User initiated access by a routable protocol from outside of an ESP. 3

4 New Concepts introduced in CIP Bulk Electric System Cyber Systems All Bulk Electric System Cyber Systems (BCS) connected to a network via a routable protocol must be within an ESP (CIP R1) If a BCS within an ESP has External Routable Connectivity, an Electronic Access Point (EAP) must be identified (CIP R1) Dial-up Connectivity (POTS) will need to perform authentication and also be identified Direct serial, non-routable connections are not included (typically leased line communication) Electronic Access Point (EAP) is now an interface (previously an asset) (see NERC glossary) 4

5 New Concepts introduced in CIP Access Requirements Inbound and Outbound access permissions/alerting are now explicitly required (CIP R1) Deny by default, and provide justification for allowed traffic Rules which allow outgoing traffic to any address (unrestricted) will be heavily scrutinized Critical for the identification and reducing impact of zero day viruses Interactive Remote Access must be through an Intermediate System (CIP R2) Detail in Lesson Learned discussion The Guidelines and Technical Basis adds If the dial-up connectivity is used for Interactive Remote Access, then Requirement R2 also applies This does not seem to be implicit in the Requirements section NERC advice in progress 5

6 New Concepts introduced in CIP Method(s) for Detecting Malicious Communications One or more methods for detecting known or suspected malicious communications for both inbound and outbound communication Control Centers only Should be able to detect unnecessary communication in the event of a misconfigured firewall Watch for advice if this functionally is performed on same hardware as firewall To meet this Requirement, FERC Order No. 706 stated that it is in the public interest to require a responsible entity to implement two or more distinct security measures when constructing an electronic security perimeter. 51 The Commission believes that a responsible entity cannot meet the goal of defense in depth as required by the Commission with a single electronic device, because a single electronic device is easier to bypass than multiple devices. Therefore, we clarify that two or more separate and distinct electronic devices are necessary to implement the Commission s defense in depth requirements. Possible solution configure a separate TAP interface which is located within the ESP. 6

7 New Concepts introduced in CIP Method(s) for Detecting Malicious Communications One or more methods for detecting known or suspected malicious communications for both inbound and outbound communication (continued) From WECC Lesson Learned Presentation 7

8 Related NERC Lessons Learned Interactive Remote Access Lesson Learned posted for comments EACMS Mixed Trust Lesson Learned posted for comments Virtual Environments (Network, Server, SAN) Lesson Learned in progress External Routable Connectivity Lesson Learned in progress 8

9 What is Interactive Remote Access? Interactive Remote Access Lesson Learned User-initiated by a person using routable protocol Access originating from outside an ESP Access not originating from an Intermediate System or EAP Interactive Remote Access must be through an Intermediate System Intermediate System can not be in an ESP 9

10 Requirements and Considerations Interactive Remote Access Lesson Learned Requirements Use an Intermediate System such that the Cyber Asset initiating Interactive Remote Access does not directly access an applicable Cyber Asset (Part 2.1) Use encryption that terminates at an Intermediate System for all Interactive Remote Access (Part 2.2) Use multi-factor (i.e., at least two) authentication to manage all IRA sessions (Part 2.3) Considerations Intermediate Systems can access Cyber Assets inside the ESP as well as outside the ESP (i.e., one Intermediate System can be used to access Cyber Assets of different impact ratings) Intermediate Systems are considered an EACMS (per NERC Glossary) for security requirements 10

11 Example of typical Interactive Remote Access from NERC Lesson Learned: 11

12 EACMS Mixed Trust Authentication EACMS Mixed Trust Lesson Learned The Lesson Learned addresses: When BES Cyber Systems and corporate systems share an authentication mechanism, such as Microsoft active directory, the resulting environment is considered to be a mixed trust environment If an entity chooses to use corporate active directory servers to perform the access control function to ESP or BES Cyber Systems, the servers are, by definition, Electronic Access Control and Monitoring Systems (EACMS) associated with one or more BES Cyber Systems An Entity may elect to reduce the compliance burden on corporate servers by avoiding this mixed trust environment by having dedicated CIP Active Directory servers 12

13 EACMS Mixed Trust Authentication EACMS Mixed Trust Lesson Learned EACMS Mixed Trust Authentication (continued) 13

14 Network Communication Virtual Environments Lesson Learned Lesson Learned documents for network virtualization are still in progress Please watch for documents as they become available Topics of Interest: Virtualization (VLANS, Virtual Machines) Implementation of a switch as an EAP 14

15 Network Communication Virtual Environments Lesson Learned MRO Recommended Approach: Consider assigning Network Switches supporting Control Center servers as BCA Has a 15 Minute impact VLANS are welcome (possibly even recommended) but all networks within the switch need to be within a defined ESP Multiple VLANS of equal trust (High Water Mark) can be within one ESP Implement a separate device to serve as EAP 15

16 Network Communication Virtual Environments Lesson Learned MRO Recommended Approach (continued) Network switches used exclusively for non real-time applications (engineer support network) would not be classified as BCA PCA (preferred), EAP (wait for Lesson Learned) Level 2 Network Switch with mixed trust VLANs will not meet requirements Implementation of a Network Switch as an EAP (if allowed, not recommended) will be complicated For example, switches with mixed trust level must meet all Electronic Access Point requirements Will need to be at least Level 3 Switch 16

17 Network Communication Virtual Environments Lesson Learned Implementation of a Network Switch as an EAP (if allowed, not recommended) will be complicated (continued) For example, every interface into the ESP would need: Ingress/egress controls and monitoring One or more methods for detecting known or suspected malicious communications for both inbound and outbound communication (If at a Control Center) (CIP Part 1.5) Virtual Machines as BCS Lesson Learned documents for Virtual Machines are still in progress Please watch for documents as they become available MRO Recommended Approach: If a BCS is on a Virtual Machine all other VMs within the physical chassis and the hypervisor should be considered part of the same or equal impact ESP 17

18 External Routable Connectivity External Routable Connectivity Lesson Learned External Routable Connectivity (ERC) ERC determination is straight forward for typical network attached BCS ERC is determined at the BCA, not BCS If a BCA has a network interface in use, and is not within a physically islanded subnet, it has ERC If a BCS is determined to have an ERC, the applicable CIP requirements increases (most notably at right) 18

19 ERC connectivity to Serial connected BCS External Routable Connectivity Lesson Learned Lesson Learned documents for this type of External Routable Connectivity are still in progress Please watch for documents as they become available MRO recommends that concepts similar to determining ERC for Low Impact BCS (LERC) (CIP-003-7) are applied 19

20 ERC connectivity to Serial connected BCS Example External Routable Connectivity Lesson Learned Recommended example of ERC - Relay Engineer has full console access to device via ERC Serial 20

21 No ERC connectivity to Serial Example External Routable Connectivity Lesson Learned Example of no ERC - A protocol break prevents Relay Engineer from full console access to device via ERC 21

22 Questions? 22