CIP Workshop - Southwest Power Pool cip workshop... · 2019-02-08 · CIP Workshop Facility Information (see map) Restrooms: From auditorium, go left out the door, then left again

CIP Workshop

Facility Information (see map) Restrooms: From auditorium, go left out the door, then left again at the next hallway. More restrooms are located on the other side of the stairway in the main foyer.

Vending machines: Continue past the closest restrooms and turn right Business Center: Behind the reception desk. A PC and printer is available. SPP cafe with tables: Other side of the vending machine wall Smoking area: Outside the SPP cafe

An employee must let you in if you exit a side or cafe door

SPP.org ->Regional Entity ->6-27-17 CIP Workshop:

Questions? Online question box generates anonymous email to staff from [email protected]

You can also email questions/comments to [email protected]

Wireless

“SPP GUEST” network. Enter your email address on the login page.

SPP RE CIP Workshop

7:30-8:00 Registration and light breakfast

8:00-8:20 Welcome & Introductory Remarks Emily Pennel, SPP RE Dave Christiano, Trustees Chair 8:20-9:00 1 - V5/6 Lessons Learned Robert Vaughn & Ted Bell, SPP RE

9:00-9:10 Break

9:10-10:10 2 - Internet of Things/Using SHODAN Philip Daigle, NERC E-ISAC 10:10-10:40 Networking Break

10:40-11:40 3 - Electronic Access Controls Kevin Perry, SPP RE 11:40-1:00 Lunch

1:00-1:45 4 - Access Control Analysis Using NP-View Kevin Perry, SPP RE 1:45-2:00 Break

2:00-2:40 5 - CIP-010-2/R1, R2 - Change Management/ Shon Austin, SPP RE Vulnerability Assessments 2:40-2:50 Break 2:50-3:40 6 - CIP-013 & Revised CIP Standards Chris Evans, SPP RTO Jennifer Flandermeyer, KCP&L Sushil Subedi, SPP

2:50-3:40 7 - Audit Success Jim Nail, City of Independence Conf. B 3:40-4:10 Networking Break

4:10-4:50 8 - Preparing for Low Impact-only Audits Jeremy Withers, SPP RE 4:50-5:00 Q&A / Closing

Survey

Download any free QR code reader on your device such as Scan Life or QR Scanner

Please answer at least the first question: How was the workshop overall?

You may also rate and leave comments on each session.

- Thank you! Emily

DOORPRIZE!

Open this QR code and enter your name for a fabulous prize!

Auditorium

SPP Cafe/

Lunch

Smoking

Vending Machines

Restroom

s

Restroom

s

CIP V5/6 Lessons LearnedJune 27, 2017

Robert E Vaughn Ted BellCompliance Specialist II Senior Compliance [email protected] [email protected] 501.614.3535

1

mailto:[email protected]


By the Numbers

Self Reports (60)

• CIP-007 (23)

• CIP-004 (11)

• CIP-010 (9)

Audits (21)

• CIP-005 (10)

• CIP-007 (5)

2We’ve gotten more self reports than audit findings, showing Registered Entities are being diligent with internal controls and reviews.

CIP-004 R4

• Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances

3

CIP-004 R5

• A process to initiate removal of an individual’s ability for unescorted physical access and Interactive Remote Access upon a termination action, and complete the removals within 24 hours of the termination action (Removal of the ability for access may be different than deletion, disabling, revocation, or removal of all access rights).

4

CIP-005-5 Part 1.3

Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default.

5

Firewalls done right

6

Firewall that’s not as tough as it looks

7

Double check the vendor request

8

CIP-005 R2• Utilize an Intermediate

System such that the Cyber Asset initiating Interactive Remote Access does not directly access an applicable Cyber Asset.

• Require multi-factor authentication for all Interactive Remote Access sessions.

9

CIP-007-5 R2

• Part 2.1

⁻ A patch management process for tracking, evaluating, and installing cyber security patches for applicable Cyber Assets.

10

CIP-007-5 R2

• Part 2.2

⁻ At least once every 35 calendar days, evaluate security patches for applicability

11

CIP-007-5 R5

• Part 5.2

⁻ Have a method(s) to enforce authentication of interactive user access, where technically feasible.

12

CIP-007-5 R5

• Part 5.4

⁻ Change known default passwords, per Cyber Asset capability

13

CIP-010 R1

• Part 1.1

⁻ Develop a baseline configuration, individually or by group…

14

CIP-010 R1

• Part 1.2

⁻ Authorize and document changes that deviate from the existing baseline configuration.

15

External Links

• CIP-005-5

⁻ Kevin’s analysis of the Ukraine Attack https://vimeopro.com/sppcompliance/re/video/168830797

⁻ EISAC ALERThttps://www.us-cert.gov/ncas/alerts/TA17-163A

⁻ Commonly used ports, and which Trojans exploit them http://www.razorpointsecurity.com/PDF/Rz.PortsList.pdf

⁻ Danger: Open Ports – Trojan is as Trojan Does https://www.acunetix.com/blog/articles/danger-open-ports-trojan-trojan/

16

https://vimeopro.com/sppcompliance/re/video/168830797

https://www.us-cert.gov/ncas/alerts/TA17-163A

http://www.razorpointsecurity.com/PDF/Rz.PortsList.pdf

https://www.acunetix.com/blog/articles/danger-open-ports-trojan-trojan/

CIP Group Contact Information

• SPP Compliance Team

⁻ [email protected]

• SPP Enforcement Team

⁻ [email protected]

• Outreach Videos/Webinars

⁻ https://www.spp.org/regional-entity/outreach/

17



https://www.spp.org/regional-entity/outreach/

What Services Do You Have Exposed?

Philip Daigle, Cyber Security Analyst, E-ISAC

2

What Services Do You Have Exposed

Or,What do you look like to an attacker?

3

Why is it Important?

It’s easy to forget to look at what your “House” looks like from the “Street”

4

Define Your External IP Space

5

Don’t Forget Cloud Services!

6

• NMAP– https://nmap.org

• SHODAN– https://www.shodan.io

Tools

7

• TCP and UDP ports can be used for just about anything

• Verification is key

Port Numbers are Great, but…

8




9




10

Example Using NMAP

#!/bin/shTARGETS=“<your external IP range>"OPTIONS="-p0-65535 -v -T4 -sV"date=`date +%Y.%m.%e.%H:%M:%S`cd /opt/scansnmap $OPTIONS $TARGETS -oA scan-$date > /dev/nullif [ -e scan-prev.xml ]; then

ndiff scan-prev.xml scan-$date.xml > diff-$dateecho "*** NDIFF RESULTS ***"cat diff-$dateecho

fi# echo "*** NMAP RESULTS ***"# cat scan-$date.nmapln -sf scan-$date.xml scan-prev.xml

A Script (slightly modified) From NMAP’s Website

11

Example Using NMAP

*** NDIFF RESULTS ***

-Nmap 7.25BETA2 scan initiated Sun Mar 19 14:36:33 2017 as: nmap -p22,80,443 -v -T4 -sV -oA scan-2017.03.19.14:36:33 portquiz.net

+Nmap 7.25BETA2 scan initiated Sun Mar 19 14:37:20 2017 as: nmap -p22,80,443 -v -T4 -sV -oA scan-2017.03.19.14:37:20 portquiz.net

electron.positon.org, portquiz.net (178.33.250.62):

PORT STATE SERVICE VERSION+443/tcp open ssl/ssl Apache httpd (SSL-only mode)

.diff File Output From Script

12

Example Using Shodan

https://www.shodan.io

To begin, point your browser to https://www.shodan.io and click “Login or Register”

13

After clicking “Create an Account” you will receive an email and you’re all set to start using the service!


14


Now we can enter an IP address to discover information about it. For this example, I’ll use portquiz.net which is a web service that listens on all TCP ports. (It’s IP address is 178.33.250.62)

15


The responding ports are listed hereThis is last

time Shodanhas updated the scan information for this host

16


Each responding port will have a corresponding entry in the list of services. These entries will show the port number (80), the protocol (TCP), and the associated service based on port number and header retreived(HTTP)

It will also have the header information that was collected from the host on that port.

17


This is an example of an SSH server. If one were to attempt to attack this server, the next step would be to search the web or something like Metasploit for vulnerabilities associated with “SSH 2.0” or “OpenSSH 6.6.1p1” or even the string regarding the version of Ubuntu

18


Adding the filter “net:” followed by a network in CIDR format, will allow querying of network ranges.

19


Adding additional filters can allow the user to quickly narrow the search to exactly what they are looking for.

20


Example ICS/SCADA Ports and Protocols:Modbus 502Dnp 19999Dnp3 20000Fieldbus 1089-91ethernet/IP 2222etherCAT 34980Profinet 34962-64

Knowing how to stack filters, and a little knowledge of the default ports for some popular ICS/SCADA equipment,We can construct a query that looks like this:

The above query actually reads: “port:502,19999,20000,1089,1090,1091,2222,34980,34962,34963,34964”

21

Script Using Shodan API

#!/bin/bashshodan init <Your API Key>d=`date +%Y%m%d%H%M%S`while IFS='' read -r line || [[ -n "$line" ]]; do

#begin command insertion #$d = date | $line = input line from file shodan host $line >> shodan-out.$d.txt#end command insertion

done < "$1“cat shodan-out.$d.txt

https://cli.shodan.io/

22

Electronic Access ControlsJune 27, 2017Kevin B. Perry

Director, Critical Infrastructure Protection

[email protected]

501.614.3251

1

Electronic Access Point

2

What does your access control look like?

3

4

App A&B

DB A&B

HMI A&B

CFE Terminal Servers A, B, and C

OpconA

OpconB

OpconC

OpconD

SatelliteClock

ESP

A/VServer

WSUSServer

RHELServer

SyslogServer Historian

A&B

Jump Host

VLAN 21 / 192.168.21.0/24

VLAN 22 / 192.168.22.0/24

VLAN 23 / 192.168.23.0/24

VLAN 24 / 192.168.24.0/24

Field Network

Corp Network

AD Server

VLAN 20 / 192.168.20.0/24

Microsoft Windows

Redhat Linux

Firmware-based

5

App A&B

DB A&B

HMI A&B


OpconA

OpconB

OpconC

OpconD

SatelliteClock

ESP

A/VServer

WSUSServer

RHELServer


A&B

Jump Host

VLAN 21 / 192.168.21.0/24

VLAN 22 / 192.168.22.0/24

VLAN 23 / 192.168.23.0/24

VLAN 24 / 192.168.24.0/24

Field Network

Corp Network

AD Server

VLAN 20 / 192.168.20.0/24

HTTP, HTTPS Listening

6

App A&B

DB A&B

HMI A&B


OpconA

OpconB

OpconC

OpconD

SatelliteClock

ESP

A/VServer

WSUSServer

RHELServer


A&B

Jump Host

VLAN 21 / 192.168.21.0/24

VLAN 22 / 192.168.22.0/24

VLAN 23 / 192.168.23.0/24

VLAN 24 / 192.168.24.0/24

Field Network

Corp Network

AD Server

VLAN 20 / 192.168.20.0/24

ESP-Group

DMZ-Group

Consider this…object-group network ESP-Group

network-object 192.168.20.0 255.255.255.0network-object 192.168.21.0 255.255.255.0network-object 192.168.22.0 255.255.255.0

object-group network DMZ-Groupnetwork-object 192.168.23.0 255.255.255.0network-object 192.168.24.0 255.255.255.0

object-group service WSUSservice-object icmp echo service-object icmp echo-reply service-object icmp time-exceededservice-object icmp unreachableservice-object tcp destination eq www service-object tcp destination eq 443 service-object tcp destination eq 135service-object tcp destination range 8530 8531

permit ESP_allow_in extended permit object-group WSUS object-group DMZ-Group object-group ESP-Group

permit ESP_allow_out extended permit object-group WSUS object-group ESP-Group object-group DMZ-Group 7

Audience Participation Time…

What are the compliance concerns with the rules just shown?

What are the risks posed by the rules as written?

How would you make the access control lists better?

(No fair looking ahead…)

8

Compliance Concerns

• CIP-005-5, Requirement R1, Part 1.3 states:

Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default

• Expectation:

⁻ Inbound and outbound permissions are demonstrably needed

⁻ Inbound and outbound permissions are tightly restricted

9

Compliance Concerns

• Object groups are not sufficiently granular

⁻ ESP-Group encompasses every Cyber Asset within the ESP

⁻ DMZ-Group encompasses every Cyber Asset in the DMZ

⁻ WSUS defines every port (service) that is required for any reason to support WSUS, plus some not required by WSUS

No consideration of reason for the port

No consideration of direction of traffic flow

• This example will result in a Potential Non-Compliance

10

Compliance Concerns

• From Microsoft TechNet:

Configure the firewall to allow communication for the HTTP and HTTPS ports used by the WSUS server. By default, a WSUS server that is configured for the default Web site uses port 80 for HTTP and port 443 for HTTPS. By default, the WSUS server uses port 8530 for HTTP and port 8531 for HTTPS if it is using the WSUS custom Web site

• References:

⁻ https://technet.microsoft.com/en-us/library/bb693717.aspx

⁻ https://technet.microsoft.com/en-us/library/bb632477.aspx

11

https://technet.microsoft.com/en-us/library/bb693717.aspx


Risks Posed by the Rules

• Full DMZ – ESP inbound and outbound access

⁻ Even with port limitation, such broad IP ranges are not warranted in a Control Center network environment

⁻ Reciprocal rules not required with a stateful firewall

⁻ Unnecessarily increases the attack surface

• ICMP not required for WSUS purposes

⁻ Although limited to only the “ping” and “traceroute” commands, ICMP can be used by a malicious attacker to perform network reconnaissance

12


• WSUS uses either ports 80/443 or 8530/8531 per the TechNet bulletins.

⁻ Ports only “listening” on the WSUS server

⁻ Listening ports configured when WSUS is installed

⁻ Ports required to download patches from an upstream server or Microsoft web site.

⁻ No requirement for the WSUS server to connect to the client Cyber Assets, thus inbound rules not required

13


• Only Microsoft Windows-based Cyber Assets are supported by WSUS

⁻ Outbound rules should permit either ports 80/443 or 8530/8531 from the operator consoles and Active Directory server to the WSUS server

⁻ Permitting broad outbound access increases the ability of malware to contact its command and control system through a compromised proxy in the non-ESP networks

14


• Permitting port 80 and 443 from every Cyber Asset in the DMZ inadvertently exposes the CFE terminal servers to malicious configuration interface access

⁻ Any external remote access to the CFE terminal servers using web services needs to go through the Intermediate System (jump host)

⁻ Malicious actor could access and reconfigure the CFE terminal servers and disrupt SCADA/EMS communication with the generating plants and substations

15

16

App A&B

DB A&B

HMI A&B


OpconA

OpconB

OpconC

OpconD

SatelliteClock

ESP

A/VServer

WSUSServer

RHELServer


A&B

Jump Host

VLAN 21 / 192.168.21.0/24

VLAN 22 / 192.168.22.0/24

VLAN 23 / 192.168.23.0/24

VLAN 24 / 192.168.24.0/24

Field Network

Corp Network

AD Server

VLAN 20 / 192.168.20.0/24

HTTP, HTTPS Listening

Windows Clients in the ESP

Improving the Access Control Listsobject-group network Windows-Systems

network-object object Opcon_Anetwork-object object Opcon_Bnetwork-object object Opcon_Cnetwork-object object Opcon_Dnetwork-object object AD_Server

object network WSUS-Serverhost 192.168.23.102

object-group service WSUSservice-object tcp destination range 8530 8531

permit ESP_allow_out extended permit object-group WSUS object-group Windows-Systems object WSUS-Server

• Define similar tight rules for interaction with the Active Directory server, RHEL update server, anti-virus server, the syslog server, and between the primary and backup Control Center ESPs 17

Active Directory

• Current design

⁻ AD server is inside the ESP to allow normal operation with the outside interface of the firewall disconnected in an emergency

⁻ DMZ Cyber Assets have to reach into the ESP to access the AD server

⁻ Default AD server configuration (Dynamic RPC) exposes the ESP to approximately 95% of all possible ports

⁻ Exposure is magnified if inbound access is not limited to just the AD server

18

Active Directory

• Required ports – Dynamic RPC (default) configuration

19

Service Port/protocolRPC endpoint mapper 135/tcp, 135/udpNetwork basic input/output system (NetBIOS) name service 137/tcp, 137/udpNetBIOS datagram service 138/udpNetBIOS session service 139/tcpRPC dynamic assignment 1024-65535/tcpServer message block (SMB) over IP (Microsoft-DS) 445/tcp, 445/udpLightweight Directory Access Protocol (LDAP) 389/tcpLDAP ping 389/udpLDAP over SSL 636/tcpGlobal catalog LDAP 3268/tcpGlobal catalog LDAP over SSL 3269/tcpKerberos 88/tcp, 88/udpDomain Name Service (DNS) 53/tcp1, 53/udpWindows Internet Naming Service (WINS) resolution (if required) 1512/tcp, 1512/udpWINS replication (if required) 42/tcp, 42/udp

Source: https://technet.microsoft.com/en-us/library/bb727063.aspx


Active Directory

• Dynamic RPC (default) configuration

⁻ Pros:

No special server configuration

⁻ Cons:

Turns the firewall into "Swiss cheese"

Random incoming high-port connections

Insecure firewall configuration

20

Active Directory

• Required Ports – Limited RPC configuration

21Source: https://technet.microsoft.com/en-us/library/bb727063.aspx

Service Port/protocolRPC endpoint mapper 135/tcp, 135/udpNetBIOS name service 137/tcp, 137/udpNetBIOS datagram service 138/udpNetBIOS session service 139/tcpRPC static port for AD replication <AD-fixed-port>/TCPRPC static port for FRS <FRS-fixed-port>/TCPSMB over IP (Microsoft-DS) 445/tcp, 445/udpLDAP 389/tcpLDAP ping 389/udpLDAP over SSL 636/tcpGlobal catalog LDAP 3268/tcpGlobal catalog LDAP over SSL 3269/tcpKerberos 88/tcp, 88/udpDNS 53/tcp, 53/udpWINS resolution (if required) 1512/tcp, 1512/udpWINS replication (if required) 42/tcp, 42/udp


Active Directory

• Limited RPC configuration

⁻ Pros:

More secure than dynamic RPC—only two open high ports

⁻ Cons:

Registry modification to all Active Directory servers

• Instructions for selecting the high ports and modifying the Registry are found in:


22


Active Directory

• But wait… It can get even better

⁻ Currently, the DMZ Cyber Assets need to punch through the firewall to access the Active Directory server

⁻ Every permitted port is another opportunity for exploit

• A read-only domain controller (RODC) is a new type of domain controller in the Windows Server® 2008 operating system.

⁻ Eliminates need for inbound port permissions to the Active Directory server inside the ESP

23

24

App A&B

DB A&B

HMI A&B


OpconA

OpconB

OpconC

OpconD

SatelliteClock

ESP

A/VServer

WSUSServer

RHELServer


A&B

Jump Host

VLAN 21 / 192.168.21.0/24

VLAN 22 / 192.168.22.0/24

VLAN 23 / 192.168.23.0/24

VLAN 24 / 192.168.24.0/24

Field Network

Corp Network

AD Server

VLAN 20 / 192.168.20.0/24

ADServer(RODC)

Read-Only Active Directory

• Read-only AD DS database

⁻ Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.

• Unidirectional replication

⁻ Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make to the DMZ Active Directory Server cannot replicate from the RODC to the rest of the forest.

Source: https://technet.microsoft.com/en-us/library/cc732801(v=ws.10).aspx

25

https://technet.microsoft.com/en-us/library/cc732801(v=ws.10).aspx

Read-Only Active Directory

• One more thing to do…

⁻ Point the Cyber Assets inside the ESP to the Active Directory server inside the ESP

⁻ Point the Cyber Assets outside the ESP to the Active Directory server in the DMZ

⁻ Eliminate all AD-related permissions through the firewall from the DMZ into the ESP

Frustrates the malicious actor…too bad, so sad…

26

Interactive Remote Access

27

28

What is Multi-Factor Authentication?

• Something you know:

⁻ Password, passphrase, PIN

• Something you have:

⁻ RSA token, CRYPTOcard, challenge/response card, cell phone

• Something you are:

⁻ Biometrics (fingerprint, facial features, iris)

29

Something You Have

• This is the most misunderstood factor

⁻ You need to be in physical possession

⁻ You cannot stop off somewhere (electronically) and pick it up

⁻ It cannot be publicly available

• The Guidelines and Technical Basis for CIP-005-5, Requirement R2 simply says “See Secure Remote Access Reference Document (see remote access alert).”

⁻ Guidance for Secure Interactive Remote Access

30

http://www.nerc.com/fileUploads/File/Events%20Analysis/FINAL-Guidance_for_Secure_Interactive_Remote_Access.pdf

Multi-Factor Scenario 1

• Authentication is performed by the following sequence:

⁻ Enter username and password

⁻ One-time token is sent by the authentication server to your company email account

⁻ Enter the one-time token value found in the email body

⁻ You are authenticated

• Question: Is this a valid form of multi-factor authentication?

NO

31




⁻ One-time token is generated using an app on your smart phone

⁻ Enter the one-time token



YES

32



⁻ Enter username and password to authenticate to a Citrix server (not the Intermediate System)

⁻ Connect to the Intermediate System from the Citrix server

⁻ Enter your username and password

⁻ Enter the password to enable use of your digital certificate, stored in your user profile on the Citrix server



NO 33



⁻ Connect to the Intermediate System from your laptop

⁻ Enter your username and password

⁻ Enter the password to enable use of your digital certificate, stored in your user profile on your laptop



Yes, but…

34




⁻ The authentication system places a call to a pre-registered phone number (cell or landline)

⁻ Answer the phone and respond as instructed



YES (cell phone would be best)

35



⁻ Insert USB key containing your digital certificate into your laptop

⁻ Launch your VPN client on your laptop and connect to the VPN concentrator (upstream from the Intermediate System)

⁻ Enter the passcode required to use your digital certificate



YES

36



⁻ Log into your laptop using your fingerprint in lieu of entering your username and password

⁻ Once logged in, connect to the Intermediate System with a username and password



You would think so, but, NO

37

Summary

• Electronic Access Point

⁻ You want tight ingress and egress access controls

⁻ Access in and out needs to be limited to what is necessary to operate, not for convenience

• Multi-Factor Authentication

⁻ Two of three: something you know, something you have, something you are

⁻ You need to be in sole possession of something you have

38

SPP RE CIP Team

• Kevin Perry, Director of Critical Infrastructure Protection(501) 614-3251

• Shon Austin, Lead Compliance Specialist-CIP(501) 614-3273

• Ted Bell, Senior Compliance Specialist-CIP(501) 614-3535

• Jeremy Withers, Senior Compliance Specialist-CIP(501) 688-1676

• Robert Vaughn, Compliance Specialist II-CIP(501) 482-2301

• Sushil Subedi, Compliance Specialist II-CIP(501) 482-2332

39

CIP-010-2 Configuration Change Management and Vulnerability Assessments

Shon Austin

Lead Compliance Specialist

[email protected]

501.614.3273

1

Ground Rules

2

Asking questions

Audience Participation

Parking lot

Learning Objectives• After this presentation you will understand:

CIP-010 purpose, expectations, challenges, and best practices*

R1: Configuration change management R2: Configuration Monitoring

3* Best practices are suggested by SPP RE staff but are NOT required by the standard

Expectations• What are your expectations for this

presentation?

4

Think of at least 1thing you expect to take away from this presentation.

Purpose• To prevent and detect unauthorized changes to

BES Cyber Systems by specifying configuration change management and vulnerability assessment requirements in support of protecting BES Cyber Systems from compromise that could lead to misoperation or instability in the BES

5

Prior CIP Versions

Version 3 Version 5

CIP-003, R6: Change and Configuration Management

CIP-010, R1, R2

CIP-005, R4 and CIP-007, R8: Cyber VulnerabilityAssessments

CIP-010, R3

CIP-007, R1: Testing cyber security controls

CIP-010, R1.4, R1.5

6

CIP-010, R1: Implement one or more documented process for baseline configurations

7

R1: What auditors expect

• Primary evidence: Documented Configuration Change Management

process Evidence of implementation of the Configuration

Change Management process

• Supporting evidence: List of applicable BES Cyber Systems and their

associated: Electronic Access Control and Monitoring Systems

(EACM) Physical Access Control Systems (PAC) Protected Cyber Assets (PCA)

8

Part1.1: Develop Baseline Configurations

9

• P1.1.1: Operating system/firmware

• P1.1.2: Commercially available or open-source application software

• P1.1.3: Custom software

• P1.1.4: Logical network accessible port

• P1.1.5: Applied security patches

P1.1: What auditors will expect• Primary evidence: Documented configuration baselines

• Supporting evidence: Documented Configuration Change Management

process

10

P1.1: Common Failures / Challenges

• Not including all required baseline items listed in Parts 1.1.1 -1.1.5 in configuration change management process

• The following are NOT baselines: Version management documentation Change management report WinAudit Report NETSTAT output

• Identifying ports allowed through Electronic Access Point instead of what is enabled on the EACMS

• Failing to maintain baseline configuration vs. failing to disable unneeded ports (CIP-007-6 R1)

• Baseline is not complete

• Limitations of tools

• Grouping 11

P1.1: Best Practices• Use of automation

12

Part 1.2: Authorize and document changes

13

P1.2: What auditors expect• Primary evidence: Documentation of changes that deviate from the

existing baseline configuration Evidence the change was authorized

• Supporting evidence: List of personnel with the authority to approve

changes

14


• Insufficient configuration change control process

• Authorizers not documented

• Authorizer doesn’t fully understand what s/he is authorizing

• Timing of authorization

• Documentation and communication of authorization

• Implementation without authorization

15


• Organizational silos

• Limitations of tools

• Not documenting all changes made to device baselines

16

P1.2: Best Practices• Separation of duties

• Document the Who, What, When, Where, & How for changes

17

Part 1.3: Update baselines within 30 days of change

18

P1.3: What auditors expect• Primary evidence: Updated baseline documentation Evidence that baseline updates were completed

within 30 calendar days of completing the change

• Supporting evidence Evidence of the date the change was completed

19

P1.3: Common Failures / Challenges• Not documenting the updated baseline

configurations within 30 days of when the change was completed

20

P1.3: Best Practices• Communicating changes made to baseline

• Coordination of change implementation timing

• Maintaining detailed revision history

• Use of automation

21

Part 1.4: Deviation from baselines must consider impact to security controls (CIP-005 and CIP-007)

22

P1.4: What auditors expect• Primary evidence: Documentation of the pre-implementation

determination of the required cyber security controls in CIP-005 and CIP-007 that could be impacted by the change; or

Attestation that no controls were expected to be impacted

Documentation of the results of the post-implementation verification of the required security controls in CIP-005 and CIP-007

23

P1.4: Common Failures/Challenges

• Not considering, identifying, and documenting all security controls in CIP-005 and CIP-007 possibly impacted by a change

• Not verifying each change that deviates from an existing baseline

• Sampling

• Not identifying and/or documenting tested cyber security controls

• Not documenting verification results

24

P1.4: Best Practices• Matrix for correlating security controls and

types of changes

• Unconditionally verifying all controls

• Coordination of controls verification across functional organizational units

• Document the Who, What, When, Where, & How testing of the security controls test

25

Part 1.5: Test Environment Requirements

Only applicable to High Impact BES Cyber Systems

26

P1.5: What auditors expect• Primary evidence: Test results for each change that deviated from

the established baseline for High Impact BES Cyber Systems Documentation of tdifferences between the test

and production environments; or Attestation there were no differences between

the test and production environments; or Attestation that testing was performed in

production environment and evidence test was performed in a manner that minimizes adverse effects

27

P1.5: Common Failures / Challenges• Not documenting test environment

• Not considering, identifying, and documenting differences between production and test environment

• Not having a process for testing changes in an environment that models the baseline configuration before implementing a change that deviates from baseline

28

P1.5: Best Practices• Test environment completely replicates

production

• Correlation document that align applicable cyber systems with associated test system

• List of cyber assets that are only tested in production environment

29

CIP-010, R2: Implement one or more documented process for Configuration Monitoring

Only applicable to High Impact BES Cyber Systems

30

R2: What auditors expect• Primary evidence: Documentation of Configuration Monitoring

process Evidence of implementation of Configuration

Monitoring process

• Supporting evidence: List of High Impact BES Cyber Systems and their

associated EACMS, PACS, and PCA

31

CIP-010 R2 Part 2.1: Configuration Monitoring

32

P2.1: What auditors expect• Primary evidence: Evidence the baseline configurations for High

Impact BES Cyber Systems and their associated EACMS and PCA were monitored for changes to the baselines at least once every 35 calendar days

Evidence detected changes were investigated; or Attestation there were no detected changes

• Supporting evidence Configuration Monitoring process

33

P2.1: Common Failures / Challenges• Not documenting and/or implementing a

process to identify, investigate, and document detected unauthorized changes to the baseline at least once every 35 calendar days

34

P2.1: Best Practices• Real-time monitoring

• Know the Who, What, When, Where, & How for identified unauthorized changes Consider the following: How unauthorized changes are identified How unauthorized changes are handled What the identified unauthorized changes were Who made the change When the unauthorized changes occurred Which BES Cyber Systems and their associated

EACMS, PACS, and PCA were affected

35

CIP-010, R3 and CIP-010, R4• CIP-010, R3: Implement one or more

documented process for Vulnerability Assessments

• CIP-010, R4: Implement one or more documented process for Transient Cyber Assets and Removable Media

36

CIP-010 impact on other Requirements

• CIP-004-6 R4.2

• CIP-005-5 R1.3

• CIP-007-6 R1

• CIP-007-6 R2

• CIP-007-6 R4

• CIP-007-6 R5

• CIP-009-6 R1

• CIP-011-2 R1

37

Did I miss anything

38

Summary• Prevent and detect unauthorized changes

to BES Cyber Systems by specifying configuration change management

• Use manual processes, automated tools, or a combination of both

• Test appropriate security controls and verify

• Understand and document the Who, What, When, Where, & How of your processes

39

Project 2016-02CIP ModificationsStandard Drafting Team Meeting SummaryMay 2017 – Columbus, OH

RELIABILITY | ACCOUNTABILITY2

• Covered administrative details and confirmed quorum

• The SDT received an overview of the use of Implementation Guidance from

NERC Compliance Assurance staff

• The SDT reviewed the following in preparation for future formal and informal

comment and ballot postings

Communication networks

Virtualization

Transmission Owner Control Centers (TOCC) performing the functional obligations

of a Transmission Operator

CIP Exceptional Circumstances

Standard Drafting Team (SDT) Meeting Activities


• The SDT is coordinating its posting schedule closely with the Supply Chain drafting team

• The SDT is actively moving towards posting new or modified standards for informal comment on the following: Virtualization

• The SDT is actively moving towards posting new or modified standards for formal comment and ballot on the following: Communication networks

Transmission Owner Control Centers (TOCC) performing the functional obligations

of a Transmission Operator

CIP Exceptional Circumstances

Key Messages


• The SDT reviewed a draft of CIP-012 based on the feedback received. R1. The Responsible Entity shall develop one or more documented plan(s) to

mitigate the risk of the unauthorized disclosure or modification of data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted, excluding oral communication, between Control Centers by (1) physically protecting the communication links transmitting the data, (2) logically protecting the data during transmission, (3) a combination of both physical and logical protections, or (4) any equally effective method to mitigate the risk of unauthorized disclosure or modification of the data.

• The SDT will continue refine the requirement language for formal posting.• The SDT is considering developing Implementation Guidance focusing on

network demarcation

Communication Networks (CommNet)


• The SDT continued to move forward with a revised CIP-002 Attachment 1 Criterion 2.12 creating a threshold that would have the effect of identifying BES Cyber Systems associated with certain small TOP and TO Control Centers as low impact

• With the introduction of “low impact Control Centers,” the SDT had discussions regarding whether additional security controls needed to be added for low impact Control Centers. Based on the readily available information analyzed by the SDT, the SDT

found no compelling reason to propose new security controls for low impact Control Centers at this time.

Transmission Owner Control Centers (TOCC)


• Control Centers or backup Control Centers of Transmission, excluding Generation, not included in High Impact Rating (H) above, that monitor and control BES Transmission Lines with an "aggregate weighted value" exceeding 6000 according to the table below which includes BES Transmission Lines between 100 kV and 499 kV. The "aggregate weighted value" for a Control Center or backup Control Center of Transmission, excluding Generation, is determined by summing the "weight value per line" shown in the table below for each BES Transmission Line monitored and controlled by the Control Center or backup Control Center of Transmission, excluding Generation.

Transmission Owner Control Centers (TOCC)


• The SDT reviewed the list of additional requirements for consideration of CEC• The SDT determined minimal additions to those 7 requirement parts noted in

the comment form were appropriate and would move forward• The SDT is considering drafting implementation guidance for existing and

new areas within the CEC scope• A modification to the CEC definition was proposed A situation that where it impedes performance of a requirement which involves or threatens to

involve one or more of the following, or similar, conditions that impact safety or BES reliability: a risk of injury or death; a natural disaster; civil unrest; an imminent or existing hardware, software, or equipment failure; a Cyber Security Incident requiring emergency assistance; a response by emergency services; the enactment of a mutual assistance agreement; or an impediment of large scale workforce availability.

CIP Exceptional Circumstance (CEC)


• The SDT reviewed modifications to definitions and requirements to address the unique risks and complexities of virtual environments. The draft definitions and requirements that were discussed are included on the slides that follow.

• The SDT plans to conduct a webinar for storage virtualization during the June meeting

• The SDT plans to conduct a webinar for Q&A of the informal comment form

Virtualization


• The SDT reviewed proposed modifications to the Cyber Asset definition to clarify its applicability to virtualized environments: Cyber Asset: A programmable electronic device (physical or virtual)

including the hardware, software, and data in the device. A virtual machine is itself a distinct asset from its host(s);

• The SDT reviewed four possible draft definitions for Electronic Security Zone (ESZ) 1. A logical grouping of one or more Cyber Asset(s) that require to be

separated; 2. A distinct group of one or more Cyber Asset(s) that require separation. 3. A distinct group of one or more Cyber Asset(s) that separation/isolation

strengthen security. 4. A distinct group of one or more Cyber Asset(s) where cyber security is

enhanced by separation/isolation.

Draft Virtualization Definitions


• PCA: One or more Cyber Assets connected using a routable protocol within or on an Electronic Security Perimeter that is not part of the highest impact BES Cyber System within the same Electronic Security Perimeter and ESZ, if any. The impact rating of Protected Cyber Assets is equal to the highest rated BES Cyber System in the same ESP and ESZ, if any.

• CMS: A centralized system for administration or configuration of BES Cyber Systems through which the configuration of the BES Cyber System can be altered;

• The SDT also discussed the possibility of breaking down the EACMS definition into 4 more precise subcategories: CMS which can alter the configuration of BCAs; AAA Systems which differ from CMS not in the sense that it cannot alter the

configuration of BCAs (or change its behavior), but more importantly unlike the CMS is has greater impact on the availability, it should therefore be in scope of CIP-009;

SIEM systems which cannot alter BCA configuration but holds BCS information should only have a subset of the current EACMS requirement;

Firewall (or EAP hosts) should have the EACMS requirement with the additions of CIP-009 E2.3 and CIP-010 E3.3.

Draft Virtualization Definitions


• CIP-004, Part 4.1: Clarified requirement language: The Responsible Entity shall document and implement process(es) to authorize electronic and unescorted physical access to BES Cyber Systems and BES Cyber Systems Information, that implements the principles of Need-to-Know, Least Privilege, and Separation of Duties as determined by the Responsible Entity, as per system capability, and except for CIP Exceptional Circumstances

• CIP-005 R1, Part 1.6 applicable systems: High & Medium Impact BES Cyber Systems residing in a Multi-instance environment and their associated CMS

• CIP-005 R1, Part 1.6 requirement: All Applicable Systems shall reside within one or more defined ESZ. At a minimum, per system capability:

1. the management plane and the data plane shall be in separate ESZ;2. CMS shall be accessed only via the management plane ESZ;


• CIP-005 R1, Part 1.7 requirement: Identify, control and explicitly allow only necessary inbound and outbound communication between ESZs

Draft Virtualization Requirements



• CIP-005 R1, Part 1.8 requirement: When an Infrastructure is shared between BES Cyber Systems and other Cyber Assets not part of a BES Cyber System:

1. The BES Cyber System, the shared infrastructure and the hosted Cyber Assets not part of the a BES Cyber Systems shall reside in separated ESZs;2. have all communications between the BES Cyber System and the hosted Cyber Assets not part of the BES Cyber System shall be explicitly denied;3. The shared infrastructure and the hosted Cyber Assets not part of the BES Cyber System shall be afforded the same security controls as the hosted BES Cyber System.


• CIP-005 R3, Part 3.1 requirement: Require Authentication, Integrity and Non-Repudiation controls for all sessions initiated outside of the ESZ, whether user initiated or systems to systems communications, used to perform CMS functions;

Draft Virtualization Requirements


• Prepare formal ballot and comment for CEC• Prepare formal ballot and comment for CommNet• Prepare formal ballot and comment for TOCC• Prepare informal comment for virtualization• Prepare webinar for storage virtualization • Continue revisions of definitions

Next Steps


Conference Dial-in 1-866-740-1260

Access Code 4469785

Reserved Call Times Fridays - 11 a.m. – 1 p.m. (ET)o Full team updateo Security Code: 0005

• Discussion topics will vary based on the issue area work progress.

• Check the NERC Standards calendar of events for the most updated information.

Sub-team Working Calls--Scheduled if needed on the NERC Standards Calendar Tuesdays - Noon – 2 p.m. (ET)o Sub-team working sessiono Security code: 0002

Thursdays - Noon – 2 p.m. (ET)o Sub-team working sessiono Security Code: 0004

• Sub-team working calls will be scheduled as needed to allow the sub-teams to process input and develop proposals.

Conference Call Schedule


2017 Planned Dates: June 20-22 – Montreal, Quebec - Hydro-Québec TransÉnergie ALL REMAINING MEETINGS WILL BE SCHEDULED BASED ON POSTING TIMELINESo July o August o September o October o November

SDT Meeting Schedule


• Information relative to the CIP Modifications project and SDT may be found on the Project 2016-02 Project Page under Related Files:

Project 2016-02 Modifications to CIP Standards– Mat Bunch, NERC Staff: [email protected]– Katherine Street, NERC Staff : [email protected]

Resources

http://www.nerc.com/pa/Stand/Pages/Project%202016-02%20Modifications%20to%20CIP%20Standards.aspx




CIP-013 Cyber Security – Supply ChainChris Evans - Southwest Power Pool

Manager, Cyber Security

[email protected]

June 7th June 30th

Where are we?

SDT Web Meeting June 30

Next posting will be in ‘early July’ most likely for final ballots

CIP-013 Implementation Guidance endorsed by the ERO

CIP-013-1,CIP-005-6,CIP-010-3 passes

June 16th June 20th-21st

SDT meeting to respond to comments and make minormodifications to standards

Early July August 10th

August 10 NERC Board of Trustees Meeting

Filing deadline

September 27th

Changes to the Standard• CIP-013 R1 – Added clarification to R1.2.4 Disclosure by vendors of known vulnerabilities

related to the products or services provided to the Responsible Entity

3

Changes to the Standard• CIP-005 – Changes to the rationale Removed word rapidly Added the following: If an entity does not allow remote access (system to

system or IRA) then the entity need not develop a process. The entity could document that it does not allow remote access of any kind to meet the reliability objective.

4

Changes to the Standard• CIP-010 Added clarification to R1.6 Prior to a change that deviates from the existing

baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5, and when the method to do so is available to the Responsible Entity from the software source: 1.6.1. Verify the identity of the software source; and 1.6.2. Verify the integrity of the software obtained

from the software source.

5

Changes to the Standard• CIP-010 Added the following to the

measures for R1.6 An example of evidence may include, but is not

limited to a change request record that demonstrates the verification of identity of the software source and integrity of the software was performed prior to the baseline change or a process which documents the mechanisms in place that would automatically ensure the authenticity and integrity of the software.

• Added Guidelines and Technical Basis

6

Common Questions CIP-013• R1.1 – Process to identify cyber security risks

This requirement is an information system planning requirement.

Have a team of SME’s consider cyber security risks to the BES that could be introduced by the vendor/product in new or planned modifications to BES Cyber Systems. For example:

Known system vulnerabilities Known threat techniques or tactics Methods to minimize network exposure Methods to limit and/or control remote access

The team could document mitigation measures to address the identified threats.

Note – This is just an example of one method to address this requirement.

7

Common Questions CIP-013• R1.2.2 – Coordination of responses to vendor-

identified incidents

A Responsible Entity and vendor could agree on service level agreements for response to cyber security incidents and commitment from vendor to collaborate with the Responsible Entity in implementing mitigating controls and product corrections.


8

Common Questions CIP-013• R1.2.5 - Verification of software integrity and

authenticity

This is different than CIP-010 R1.6. This is about contracts/RFP’s etc.

In an RFP or during contract negotiations, request that the vendor include in contract provisions a commitment from the vendor to provide fingerprints, cipher hashes or digital signatures for all software so that the Responsible Entity can verify the values prior to installation on the BES Cyber System to verify the integrity of the software.


9

Common Questions CIP-005• R2.4 and R2.5

This includes both vendor initiated and entity initiated vendor remote access.

This requirement does not require session recording.

10

Common Questions CIP-010• R1.6 - Prior to a change that deviates from

the existing baseline configuration validate the integrity and identity.

This requirement only comes into play once the baseline has been established.

Automated patching solutions can be used. They must validate authenticity/identity.

Secure software stores can be used so that once a piece of software has been validated it can be used multiple times.

11

Common Questions CIP-010• R1.6 – Potential Evidence

A method exists Validate digital signature Calculated hash values Validate web SSL certificate Documentation from vendor for automatic solutions

No method exists Screenshots of download page showing a method

doesn’t exist. Statements from the vendor Entity Attestations – As a last resort

12

Questions?

13

• Refer to the Project 2016-03 page for more information

• Email [email protected] to join the email list

• Corey Sellers, Southern Company, SDT Chair Email at [email protected]

• JoAnn Murphy, PJM Interconnection, SDT Vice Chair Email at [email protected]

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




City of Independence

Power & Light Department

Jim Nail – Reliability Compliance Coordinator

2016 O&P AUDIT Zero Findings Zero Concerns

The Successful Result of a Three Year Strategy.

Municipal Utility TO/TOP/TP/GO/GOP/DP/RP Compliance Staff: 4

Plus 15 SME’s

City of Independence

Power & Light Department

Start with 2013 Intense Effort Good Programs Multiple Errors Evidence Didn’t Speak for Itself.

Learn from our Mistakes

Take Audit Comments Seriously Incorporate Changes Avoid Repeat Errors Improve Narrative/Evidence

IPL Strategy – Maintain & Build on Success

Improve vs. Re-write On-going Program vs. Audit Prep If the Auditors Liked it…

Continuous Program Annual Review of Every Requirement SME Review Evidence Collection Monthly Compliance Team Meetings

Establish BasicInternal Controls

Checklist of Annual Requirements Checklist of Event Driven Requirements Document Review Process SharePoint Document Control Compliance Team Oversight

Participate!Participate!Participate!

Workshops & Forums Standard Drafting Teams/Webinars SPP Working Groups

2016 Audit PreparationOne Year OutRSAW Reviews SME ReviewsEvidence Reviews

RSAW Reviews Focus on Narrative Speak to the Requirement

…and only the requirement

Road Map to the Evidence

SME Reviews Accuracy Agreement Stick to the Facts Verify Evidence Up-To-Date

Evidence Review Good Representative Examples Cover the Entire Audit Period Primary vs. Hip-pocket Identify Gaps or Weak Evidence

5-6 Months SPP/RTO Staff Focused on Expected Audit Scope Mock Audit

Third Party Reviews

Audit Notice Final Review Compliance Team Builds Audit Package Separate, Restricted Network Folder Open EVERY File!

Manage the Audit Facilities Reserved Staff Present or Available Cooperative, Non-Adversarial Atmosphere Compliance Coordinator Primary Spokesman

SME on hand as back-up

Manage the Audit Quick Response to Requests Check all Evidence Get all Questions Answered Before End of

Audit

Results…

19 Evidence Requests Zero PV Zero Areas of Concern

Questions???

Audit Preparation and Expectations – “The Low-Down”

June 27, 2017

Jeremy Withers, CISSP, Security+, Network+, CISASenior Compliance Specialist - CIPSPP RE Staff

1

Overview

• Audit preparation tips

• Audit overview

• Cyber security plan

• CIP Version 5 Evidence Request

• RSAW completion

• Evidence Request Workbooks

• Summary

2

Compliance is an ongoing process

• Get support from the top-down

• Conduct continual review of documentation and procedures

• Documentation of evidence

⁻ Maintain version history

⁻ Maintain and review documentation yearly

⁻ Ensure process changes are addressed in documentation updates

⁻ Ensure evidence is relevant, valid, and reliable

3

Be organized

• Assign responsibility to specific people

• Use checklists for documentation reviews⁻ Define/assign responsibilities

⁻ Timing (quarterly, annual, etc.)

⁻ Establish/document internal controls

Outlook calendars

Excel spreadsheets

SharePoint

• Know where documentation is stored4

Self-assess compliance

• Self-Certifications

• Periodic Data Submittals

• Internal auditing

• Self-Report when non-compliance is found

⁻ Shows good culture of compliance

⁻ Strongly encouraged

• Third-party review

5

Consider using outside resources

• Define, improve technical processes

• Assist with regulatory approaches

• Provide pre-audit reviews and support for compliance programs and supplement available resources

• Be sure to check out the resources

⁻ Call references

• Mock audits

• Internal Audit department

6

Audit Overview

• Audited Standards/Requirements based on BES Cyber System Categorization

• Audit Period: July 1, 2016 until date of audit

• Audit Cycle: Nominally 3-year (BA, TOP, RC) and 6-year (IA, GO, GOP, DP, TO)

• Pre-Audit: Inherent Risk Assessment, Notification, Request for information, Review of evidence, Supplemental requests

• Audit: Opening presentations, Interviews, Review of Evidence, End-of-day briefing, Exit Presentation

• Post-Audit: Draft audit report, Registered Entity comments (10 days), Feedback forms, Final audit report (non-public)

7

CIP Audit Scope (Low Impact BES Cyber Systems)

• CIP-002-5.1a Requirement R1 & R2

• CIP-003-6 Requirement R1.2

⁻ Part 1.2.1

⁻ Part 1.2.2

⁻ Part 1.2.3

⁻ Part 1.2.4

8

CIP Audit Scope (Low Impact BES Cyber Systems)

• CIP-003-6 Requirement R2

⁻ Physical security controls (effective September 1, 2018)

⁻ Electronic access controls for Low Impact External Routable Connectivity and Dial-up Connectivity (effective September 1, 2018)



9

Low Impact BES Cyber Systems Overview

• An inventory, list, or discrete identification of Low Impact BCS or their BES Cyber Assets is not required

• BUT!!!!

⁻ A list containing the name of “each asset that contains a Low Impact BES Cyber System” is required, such as a list of:

Generating plants

Transmission stations

Certain distribution stations

Certain “small” control centers that contain Low Impact BCS

Blackstart resources and cranking paths

10

CIP-003-6 R1.2

• Each Responsible Entity shall review and obtain CIP Senior Manager approval at least once every 15 calendar months for one or more documented cyber security policies that collectively address the following topics:

• R1.2 For its assets identified in CIP‐002 containing Low Impact BES Cyber Systems, if any:

⁻ 1.2.1. Cyber security awareness;

⁻ 1.2.2. Physical security controls;

⁻ 1.2.3. Electronic access controls for Low Impact External Routable Connectivity (LERC) and Dial‐up Connectivity; and

⁻ 1.2.4. Cyber Security Incident response

11

CIP-003-6 R2

• Each Responsible Entity with at least one asset identified in CIP‐002 containing Low Impact BES Cyber Systems shall implement one or more documented cyber security plan(s) for its Low Impact BES Cyber Systems that include the sections in Attachment 1. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]

⁻ Note: An inventory, list, or discrete identification of Low Impact BES Cyber Systems or their BES Cyber Assets is not required. Lists of authorized users are not required.

12

CIP-003-6 R2 Attachment 1 Section 1

• Section 1 – Cyber Security Awareness

⁻ Shall reinforce cyber security practices at least every 15 months

⁻ May include physical security practices

13


• Section 2 – Physical Security Controls (effective September 1, 2018)

⁻ Shall control physical access, based on need as determined by the Responsible Entity to:

Low Impact BCS within the asset

LEAPs, if any

14


• Section 3 – Electronic Access Controls (effective September 1, 2018)

⁻ 3.1 For Low Impact LERC, if any, implement a LEAP to permit only necessary inbound and outbound bi-directional routable protocol access

⁻ 3.2 Implement authentication for all Dial-up Connectivity, if any, that provides access to Low Impact BES Cyber Systems, per Asset capability

15


• Section 4 – Cyber Security Incident Response plan(s)

⁻ 4.1 Identification, Classification and Response to a Cyber Security Incident

⁻ 4.2 Determination of whether an identified Cyber Security Incident is a Reportable Cyber Security Incident and subsequent notification to the Electricity Information Sharing and Analysis Center (E‐ISAC), unless prohibited by law;

16

CIP-003-6 R2 Attachment 1 Section 4 (cont.)


⁻ 4.3 Identification of the roles and responsibilities for Cyber Security Incident response by groups or individuals;

⁻ 4.4 Incident handling for Cyber Security Incidents;

⁻ 4.5 Testing the Cyber Security Incident response plan(s) at least once every 36 calendar months by: (1) responding to an actual Reportable Cyber Security Incident; (2) using a drill or tabletop exercise of a Reportable Cyber Security Incident; or (3) using an operational exercise of a Reportable Cyber Security Incident

17

CIP-003-6 R2 Attachment 1 Section 4 (cont.)


⁻ 4.6 Updating the Cyber Security Incident response plan(s), if needed, within 180 calendar days after completion of a Cyber Security Incident response plan(s) test or actual Reportable Cyber Security Incident.

18

19

Example: Acme Power’s Low Impact BCS

• Acme has documented and implemented the following for its Low Impact BCS:

⁻ Electronic access controls

⁻ Physical security controls

⁻ Cyber security awareness (strong passwords, virus protection, etc.)

⁻ Inclusion in a Cyber Security Incident response plan

1.Substation Alpha

2.Substation Beta

3.Substation Charlie

4.Edison Coal Plant

5.Acme Primary Control Center

20

21

CIP Version 5 Evidence Request

• Level 1

⁻ High level documentation

⁻ Policies, procedures, processes, etc.

⁻ List of all BES assets

• Level 2

⁻ More granular documentation

⁻ Evidence of implementation

⁻ Selected sample of BES assets

22

BES Assets Tab

23

Level 1 Tab

24

Level 1 Tab (cont.)

25

Sample Sets L2 Tab

26

Level 2 Tab

27

Example: Acme’s R2 Evidence• For Acme’s 5 assets that contain BCS, evidence of:

⁻ Electronic access controls

Network diagram - Level 1

access control list - Level 2

⁻ Physical security controls

Documentation of card readers, key locks, etc. - Level 2

⁻ Cyber security awareness

Security policies - Level 1

Awareness training (posters, learning modules) – Level 2

⁻ Cyber Security Incident response plan

Copy of the plan – Level 1

Evidence of testing prior to April 1, 2017 – Level 2 28

29

Complete RSAW for each Standard

• RSAWs included in audit packet are pre-populated with audit team and entity information

• Provide detailed narrative of how you meet compliance for each requirement

• Best practice:

⁻ Complete all applicable RSAWS for every applicable requirement

⁻ Hold those labeled not required in initial audit notice in case the audit team requests them as part of audit scope expansion

⁻ Be prepared to provide evidence for all applicable requirements in case audit scope is expanded

30

CIP-003-6 RSAW completion example

31

CIP-003-6 RSAW completion example (cont.)

32


33


34


35


36

Evidence Request Workbook Completion

37

Complete Evidence Request Workbook for each Standard

• Evidence Request Workbooks included in audit packet are pre-populated with entity information

• Provide a record of evidence artifact submissions

• Allows auditors to correlate evidence artifacts with Requirement Parts

• You may reference the Evidence Request Workbook in the RSAWs, but you may not reference the RSAWs in the Evidence Request Workbook

38

Evidence Request Workbook example

39

Evidence Request Workbook example (cont.)

40

EFT Upload

• All audit documentation should be uploaded to the EFT server in the following format:

41

Questions

42

Summary

• Compliance is an ongoing process, not a one-time process

• Ensure you identify each asset that contains a Low Impact BES Cyber System

• Ensure you implement all sections of CIP-003-6 Attachment 1 for each asset that contains a Low Impact BES Cyber System

• Provide adequate evidence to support all requirements in scope

• Provide detailed narrative of how you meet compliance for each requirement in RSAWs

43

References

• Audit Processes & Sampling

• CIP V5 - Preparing for Audit

• CIP V5 Identifying BES Cyber Systems

• CIP V5 Low Impact Auditing

• EFT Server Tutorial

• CIP Version 5 Evidence Request

44






http://www.nerc.com/pa/comp/Pages/ERO-Enterprise-Compliance-Auditor-Manual.aspx

SPP RE CIP Team

• Kevin Perry, Director of Critical Infrastructure Protection(501) 614-3251

• Shon Austin, Lead Compliance Specialist-CIP(501) 614-3273

• Ted Bell, Senior Compliance Specialist-CIP(501) 614-3535

• Jeremy Withers, Senior Compliance Specialist-CIP(501) 688-1676

• Robert Vaughn, Compliance Specialist II-CIP(501) 482-2301

• Sushil Subedi, Compliance Specialist II-CIP(501) 482-2332

• Leesa Oakes, Compliance Enforcement(501) 614-3274 45

Documents

CIP Workshop - Southwest Power Pool cip workshop... · 2019-02-08 · CIP Workshop Facility Information (see map) Restrooms: From auditorium, go left out the door, then left again