Lesson Learned CIP Version 5 Transition Program CIP-002-5.1 R1: Grouping BES Cyber Assets Version: March 2, 2014 This document is designed to convey lessons learned from NERC’s various CIP version 5 transition activities. It is not intended to establish new requirements under NERC’s Reliability Standards, to modify the requirements in any existing reliability standards nor to provide an official interpretation. Additionally, there may be other legitimate ways to fulfill the obligations of the requirements that are not expressed within this supporting document. Compliance will continue to be determined based on language in the NERC Reliability Standards as they may be amended from time to time. Implementation of this lesson learned is not a substitute for compliance with requirements in NERC’s Reliability Standards. Purpose The purpose of this Lesson Learned is to describe useful methods to group BES Cyber Assets into BES Cyber Systems (BCS). Background The CIP Version 5 standards introduces a new concept not included in Version 3—a BES Cyber System, which consists of “one or more BES Cyber Assets (BCA) logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.” If a Registered Entity decides to group their BCA , they will need to demonstrate their grouping method. Guidance Registered entities may choose to create different groupings of BES Cyber Assets to comply with individual CIP Version 5 standards. Entities are provided flexibility in how they group their BES Cyber Assets. However, it is recommended that each entity should document their processes for grouping their BES Cyber Assets to improve transparency during compliance monitoring. The following sections provide examples of how different participants in NERC CIP version 5 implementation study grouped their BES Cyber Assets into BES Cyber Systems. Groupings Based on Function Certain implementation study participants grouped their BES Cyber Assets by function. In other words, the entity grouped BES Cyber Assets into BES Cyber Systems based primarily on which BES Cyber Assets perform a common function. For example, an Energy Management System (EMS) BES Cyber System may consist of a number of human–machine interface workstations, communications servers, processing servers, database servers, and peripheral devices such as time-synchronizing clocks or printers.

3353 Peachtree Road NE Suite 600, North Tower

Atlanta, GA 30326 404-446-2560 | www.nerc.com

All the EMS servers at a Control Center and the associated backup Control Center could be grouped together as they are categorized at the same impact level. Alternatively, entities can group Microsoft Cyber Assets, Linux Cyber Assets, and other Cyber Assets (e.g., network or disk servers) according to the software patching requirements (as the patch sources may be different and released on different release cycles). This grouping methodology allows entities to prepare their processes and demonstrate compliance of like systems. See Figure 1 below.

Figure 1: Functional Grouping

Groupings Based on Common Local Area Network Other implementation study participants used a BES Cyber System grouping based on whether individual BES Cyber Assets are on a common local area network and can communicate with each other via a routable protocol. For example, a Transmission Protection System identified as a BES Cyber System could include all of the protective relay BES Cyber Assets at a specific transmission substation, especially if various protective relays communicate with each other over a local area network for protection coordination. While initially it may seem prudent to create separate BES Cyber Systems for each protection zone or for those protecting a single Facility at a given station or substation, there may be communications between different protection zones, either to provide additional zones of protection or backup within a specific zone. If the various Protection Systems identified as BES Cyber Systems need to meet the same CIP standard requirements, there may be no benefit in creating multiple separate BES Cyber Systems at a Transmission station. However, if it is anticipated that (1) some BES Cyber Systems will be at different impact levels (i.e., Medium or Low), (2) there is limited or no communications between the BES Cyber Systems at different impact levels, and (3) they are not on the same local area network, then having multiple BES Cyber Systems may be a preferable approach. See Figure 2 below.

Figure 2: Grouping across Substations

Documenting BES Cyber Systems The inventory list created through the development of CIP-002-5.1, Requirement R1 should indicate the identified BES Cyber System groupings. To demonstrate compliance, one approach is to create a name for each individual BES Cyber System for reference when applying the remainder of the requirements of the CIP Version 5 standards. As provided in the example below, a reason (or reason code) to document the rationale for the grouping would also be beneficial when presenting your evidence for audit. One way to document this approach could be in a sortable spreadsheet, as shown below:

No. Facility Name

Equipment Description

Device ID

Responsible Work Group

Function Cyber Asset

Classification (BCS)

BES Reliability Operating

Service (BROS)

If not a BCA

- List the

reason why

PSP ESP

Additional Examples One implementation study participant identified several BES Cyber Assets at a medium impact substation and elected to group them into BES Cyber Systems based on both function and location as described above. The entity has grouped the remote terminal unit (RTU) equipment together as one BES Cyber System and the Protection Systems equipment together as another BES Cyber System. The BES Cyber Assets in each BES Cyber System work together to provide the same BES reliability operating services and the loss of one asset in the system impacts the functions of the system in a similar manner. See Figure 3 below.

Figure 3: Grouping by Function and Location

Alternatively, entities may choose to group all of the BES Cyber Assets at a particluar medium impact substation into a BES Cyber System, i.e. grouping by physical location, as in figure 4 below.

Figure 4: Grouping by Location

Notwithstanding the previous examples, there are many options for grouping BES Cyber Assets into a BES Cyber System. An entity may choose to group BES Cyber Assets of the same type into individual BES Cyber Systems. For example, at a medium impact substation, all Protection System BES Cyber Assets with External Routable Connectivity would be one BES Cyber System. All Protection System BES Cyber Assets without External Routable Connectivity

would be another BES Cyber System. Alternately, the entity could group all BES Cyber Assets with External Routable Connectivity (RTU equipment, Protection Systems, etc.) at the substation into one BES Cyber System. However the BES Cyber System is defined, it must meet the CIP V5 Standards at the system level for all of its component BES Cyber Assets. A BES Cyber Systems can cross Physical Security Perimeters (PSP), Electronic Security Perimeters (ESP), and Facility geographic boundaries; they can encompass many Physical Security Perimeters, Electronic Security Perimeters and Facilities. Grouping BES Cyber Assets Considerations:

• Groupings may assist an entity in placing controls around devices that would otherwise not be able to apply a particular control, e.g. CIP-007-6 R4.1, logging at the systems or asset level.

• BCS groupings do not influence or change other CIP concepts, such as ESP, PSP, Impact Rating, Watermarking, ERC, Facilities or Brightline.

• BCS groupings are object based, meaning that they include the basic capabilities for an object: identity, properties, and attributes defined by your procedures. The standards do not define the capabilities of the BCS objects.

• While it is possible to place a single BCA in more than one BCS, doing so creates complexity in documenting compliance for the entity and verification of compliance by the Regional Entity. Entities should exercise caution if planning to group in this manner.

• Entities should carefully document the strategies for grouping a BCA into a BCS, e.g. based on LAN, function, geolocation, etc. Entities should be prepared to provide the grouping approach upon receiving the 90 day audit notification and the Request For Information (RFI) may be customized by the region based on an entities grouping.

• Care should be taken when grouping across impact ratings. When there are multiple impact rated BCAs inside a single BCS, all assets must be protected to the highest impact rated BCA contained within the BCS.

• Entities should consider documenting which controls are being applied at the system level and which are being applied at the asset level.

Lesson Learned CIP Version 5 Transition Program CIP-002-5.1: Grouping BES Cyber Assets Industry Comments Draft Posted March 2, 2015 April 9, 2015

Comments Received – Grouping BES Cyber Assets

Organization Comment #

General Comments

Bonneville Power Authority

BPA supports the ‘Grouping of BES Cyber Systems (Revised) Lesson Learned with no comments.

Illinois Municipal Electric Agency

IMEA supports this Lesson Learned 2

SERC Reliability Corporation

1. The SERC CIPC felt that this Lessons Learned Document was easy to read and understand. The drawings were done well and are being used to help people begin grouping. • This document uses better language to serve as a lessons learned • Agreed that the direction is clear that you must document what you choose and

why but it is up to the entity to develop this grouping • No issues with the information shared in this document but would like to see

PCAs included; • No issues with the document but would like to see PCA examples, serial devices,

and generation included; • Where would log collection systems reside?

2. Do you have comments for the Grouping Based on Functions section? Agree, no comments

3. Do you have any comments for the Common Local Area Network Grouping section? Agree, no comments

4. Do you have any comments for the documenting BES Cyber Systems? Agree, no comments

5. Do you have any comments on this Additional Examples section? Agree, no comments

3

Dominion Every page should be numbered. 4

Comments Received – Grouping BES Cyber Assets

Organization Comment #

The document is missing examples of BES Cyber Assets that have no external routable connectivity and examples of non-routable communication (serial, modbus, etc.). Include examples of BES Cyber Assets that have no external routable connectivity and examples of non-routable communication (serial, modbus, etc.). This Lesson Learned document doesn’t include a cautionary note about creating separate groupings of BES Cyber Systems per requirement. Include language similar to bullet 4 on Page 5, that describes the complexity of taking that approach. The Lessons Learned is Transmission-centric. Either create a separate LL specific to Generation functions or include Generation examples in this document.

Southern Company

Southern Company appreciates the opportunity to comment on the North American Electric Reliability Corporation’s (NERC) two new lessons learned posted on March 2, 2015. NERC has put in a substantial effort to develop these drafts and we thank NERC for these efforts. Southern Company supports the Edison Electric Institute comments on the two lessons learned.

5

Edison Electric Institute Electric Power Supply Association

The Trades continue to support the CIP Version 5 Advisory Group in developing supporting documents using the Section 11 NERC process to help entities transition to the CIP Version 5 Standards. This process is very important to supporting NERC’s commitment to consistency across the Electric Reliability Organization1 and a “clear path and approach to transition from CIP Version 3 to CIP Version 5.”2 Herein, the Trades recommend several changes that will significantly improve the clarity of the Grouping BES Cyber Assets Lessons Learned.

American Electric Power

AEP is in agreement with the comments submitted by the Edison Electric Institute (EEI) in its entirety.

Exelon Exelon supports the comments submitted by EEI. 8

1 1 See, e.g., NERC, Project 2014-02 CIP Version 5 Revisions: Consideration of Comments, Additional Comment Period, January 23, 2015, p 8 (“NERC notes that it strives for consistency across the Electric Reliability Organization”); Informational Filing of the North American Electric Reliability Corporation Regarding the BES Cyber Asset Survey, Docket RM13-5-000, February 3, 2015, p. 26 (“NERC understands the need for consistent understanding of the CIP Version 5 standards across the ERO in order for entities to effectively transition to CIP Version 5 compliance”).

2 Informational Filing of the North American Electric Reliability Corporation Regarding the CIP Version 5 Reliability Standards Implementation Study, Docket RM13-5-000, October 11, 2013.

Comments Received – Grouping BES Cyber Assets

Organization Comment #

MidAmerican Energy Company

MidAmerican Energy Company supports the Edison Electric Institute comments on the two new lessons learned posted for comments on March 2, 2015, with comments due by March 30, 2015.

9

Wisconsin Electric Power Company

Wisconsin Electric Power Company participated in the development of, and supports the feedback comments submitted by Edison Electric Institute (EEI) regarding NERC’s Lessons Learned for “Grouping of BES Cyber Systems (Revised)” and “Functional Obligations and Control Centers” posted on March 2, 2015.

10

Encari Encari supports NERC’s efforts to provide guidance to the industry to ease the transition to the suite of NERC Version 5 Critical Infrastructure Protection (CIP) standards from the previous suite of NERC CIP Version 3, but provides the below comments on this Lessons Learned for NERC’s consideration. Encari, agrees with many of the outlined techniques used for grouping BES Cyber Assets into associated BES Cyber Systems. It is in the best interest that a process be developed for grouping of BES Cyber Assets into BES Cyber Systems where possible and as laid out throughout the NERC CIP Version 5 requirement paying attention to requirements which can be applied at the system level and not the asset level. The more thought that an entity puts into this ahead of time will cause less audit risk down the road, along with less chances for internal exceptions to policy This is a good example of the items that need to be asked as you categorize and complete your NERC CIP Version 5 inventory.

11

ERCOT ERCOT thanks the North American Electric Reliability Corporation (“NERC”) for the opportunity to review and provide comments on its Lesson Learned CIP Version 5 Transition Program CIP-002-5.1: Identification of BES Cyber Systems at Control Centers Pursuant to Reliability Standard CIP-002-5.1 and Lesson Learned CIP Version 5 Transition Program CIP-002-5.1 R1: Grouping BES Cyber Assets (“Lessons Learned”). ERCOT supports NERC’s efforts to provide guidance to the industry to facilitate its transition to Version 5 of the Critical Infrastructure Protection (CIP) reliability standards, but provides the below comments on these Lessons Learned for NERC’s consideration.

12

Specific Comments

Duke Energy Duke Energy takes issue with the last sentence in the Background section of this lessons learned document. The last sentence suggests that an entity may choose to group its BES Cyber Assets. This is misleading in that, to maintain compliance, an entity must groups its BES Cyber Assets, and is not afforded a choice in the matter. Also, as written, the section tends to suggest that an entity must document its grouping method. This is

13

Comments Received – Grouping BES Cyber Assets

Organization Comment #

not a requirement, and should not be written in a lessons learned document to suggest an entity must document its grouping method. We suggest revising the language in the Background section to better align with the Guidance section of the document, which puts forward documenting the grouping as a recommendation of good practice. Duke Energy notices that Protected Cyber Assets are not referenced in the lessons learned document. We suggest that an example or a section addressing Protected Cyber Assets and how they should be treated in conjunction with the subject of this document be inserted. Bullet 5 of the Considerations section goes beyond what is required in the applicable standard. Bullet 5 is recommending that entities be prepared to provide information during an audit, information that is not required in the standard. Currently, Measure 1 of CIP-002-5 requires that an entity identify a list of BES Cyber Systems, not provide a grouping approach. We suggest clarifying, or removing Bullet 5 altogether.

Dominion Re page 2: In regards to Figure 1 some direction should be provided on how to treat PCA(s) when you have multiple BES Cyber Systems in the same network with the PCA(s). Re page 3, Documenting BES Cyber Systems: The example provided exceeds what is required by the Standard. Include a disclaimer that indicates it is not a template to meet Compliance obligations. Re page 4. Figure 4: The figure provided is missing lines that connect the BES Cyber Assets to the EAP. Add lines similar to Figure 3.

14

Edison Electric Institute Electric Power Supply Association

A. CIP-002-5.1 requires Registered Entities to identify BES Cyber Systems, but does not require them to document the process they use to group BES Cyber Assets into a system.

Under CIP-002-5.1, Responsible Entities must identify high and medium impact BES Cyber Systems (BCS) and assets that contain low impact BCS. BES Cyber Assets (BCA) are not mentioned in the standard requirement. By definition, a BCS is “one or more BES Cyber Assets,” which implies that entities must group their BCA into BCS, Grouping can mean a single BES Cyber Asset can be considered a BES Cyber System, or it can mean that several BCAs make up one BCS. Basically, grouping is required by the standard, but how the grouping is done is left up to the entity. The last sentence under the background section of the lesson learned implies that entities have a choice of whether to group: “if a Registered Entity decides to group their BCA…”; however, this is inconsistent with the language of the standard, which requires grouping.

15

Comments Received – Grouping BES Cyber Assets

Organization Comment #

According to the background section of CIP-002-5.1, “it is left up to the Responsible Entity to determine the level of granularity at which to identify a BES Cyber System within the qualifications in the definition of BES Cyber System.” The language of the standard does not require or recommend that the entity demonstrate their grouping method when presenting evidence for an audit. Instead, it leaves it “up to the Responsible Entity to determine.” CIP-002-5.1 R1 and M1 require that entities identify the BCS, but do not require entities to demonstrate their BCA grouping process. In fact, BCA are not mentioned in the standard requirements. Therefore “they will need to demonstrate their grouping method” in the last sentence of the Background section is also inconsistent with the standard requirements. In the Guidance section, the sentence “however, it is recommended that each entity should document their processes for grouping their BES Cyber Assets to improve transparency during compliance monitoring” is more appropriate for the lesson learned. It should be clear in the lesson learned document that the standard does not require the entity to document their grouping process. The Trades recommend deleting the last sentence in the Background section3. Finally, the fifth bullet on the last page not only requires entities to carefully document their grouping strategies, but goes further by requiring them to provide the grouping approach upon receiving the 90 day audit notification. This bullet should also be removed as it establishes new requirements under the standard. It is “left up to the Responsible Entity to … identify a BES Cyber System within the qualifications in the definition” and they must document this identification for audit. The method for grouping BCAs into a BCS is not addressed by the standard; however, an entity’s grouping process could be used as evidence for BCS identification, but the standard does not require it. Therefore, it is not appropriate to modify the language of the standard to require the grouping approach under this supporting document. The lesson learned document “is not intended to establish new requirements under NERC’s Reliability Standards, to modify the requirements in any existing reliability standards nor to provide an official interpretation.” Therefore, the Trades recommend removing all of the language that requires or recommends that Responsible Entities document or demonstrate their grouping method from the lesson learned.

B. CIP-002-5.1 does not require entities to document or inventory the cyber assets in a BCS or document cyber assets that would not be considered BCS.

3 We are recommending removing “if a Registered Entity decides to group their BCA, they will need to demonstrate their grouping method” from the Background section of the lesson learned.

Comments Received – Grouping BES Cyber Assets

Organization Comment #

The documentation approach example under the Documenting BES Cyber Systems uses column titles that imply that Registered Entities must document or inventory all of their cyber assets, identify whether each cyber asset is a BCA, and list the reason why a cyber asset is not a BCA. However, this is not required by CIP-002-5.1, which only requires entities to identify each BCS. The example provided in the lesson learned may cause auditors to ask for this evidence. Therefore the Trades recommend either removing this example or making it very clear that these items are not required pieces of evidence for compliance with the standard.

C. BCA groupings may influence or change other CIP concepts. The second bullet on the last page states that BCS groupings “do not influence or change other CIP concepts”; however, the grouping can in fact have an impact on the other CIP concepts. For example, if a cyber asset that would be considered a low impact BCS on its own is added to a medium impact BCS with external routable connectivity (ERC), then the added cyber asset would take on the higher impact rating, as described by the sixth bullet. For physical security perimeters (PSP), the CIP-006 requirements are written at the BCS level such that every cyber asset added to the system has to meet all the requirements applicable to the BCS. Therefore if an entity groups what could be categorized on its own as a low impact cyber system to a medium BCS, then the cyber asset becomes a part of the medium BCS. Because the medium impact CIP-006 PSP requirements apply to the system, the medium impact requirements apply to every asset in the system. We recommend that the words “do not” be replaced with “may” in the second bullet so that it reads ‘BCS groupings may influence….”

D. The meaning of “object based” BCS groupings is unclear. The third bullet on the last page of this lesson learned describes “object based” BCS groupings; however, this bullet is unclear. We recommend the removal of this bullet.

E. Documenting the controls applied at the system and asset levels are not a part of CIP-002-5.1 and therefore should not be included in this lesson learned.

The last bullet on the last page of this lesson learned tells entities to document controls applied at the system and asset level, which is not a part of CIP-002-5.1, which focuses on BCS categorization. The Trades recommend removing the last bullet from this lesson learned.

F. Serial examples would be helpful.

Comments Received – Grouping BES Cyber Assets

Organization Comment #

The examples in this lesson learned are all IP based examples. It would be helpful to Responsible Entities to include a serial-based example in the lesson learned.

American Electric Power

The representative spreadsheet, in the Documenting BES Cyber Systems section, presents a column requesting the rationale for exclusion on a device by device basis. This is simply not reasonable for a large organization with thousands, or perhaps tens of thousands of cyber assets. The leading narrative, in the Documenting BES Cyber Systems section, describes the example compliance approach of applying a reason (or reason code) to the cyber assets. Neither the reason nor reason code is represented in the example spreadsheet columns.

16

ERCOT 1. Figure 1 does not represent the example explained. 2. The “Documenting BES Cyber Systems” section should be moved after the

examples of asset grouping. 3. “Grouping BES Cyber Assets Considerations” should be a section header. 4. Terms not included in the NERC glossary should not be capitalized.

17