CIP Workshop. SPP.org ->Regional Entity -> CIP Workshop: Questions? Wireless. SPP GUEST network. Enter your address on the login page.

Transcription

1 CIP Workshop SPP.org ->Regional Entity -> CIP Workshop: Questions? Online question box generates anonymous to staff from You can also questions/comments to Wireless SPP GUEST network. Enter your address on the login page. 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

2 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: V5/6 Lessons Learned Robert Vaughn & Ted Bell, SPP RE 9:00-9:10 Break 9:10-10: Internet of Things/Using SHODAN Philip Daigle, NERC E-ISAC 10:10-10:40 Networking Break 10:40-11: Electronic Access Controls Kevin Perry, SPP RE 11:40-1:00 Lunch 1:00-1: Access Control Analysis Using NP-View Kevin Perry, SPP RE 1:45-2:00 Break 2:00-2: CIP-010-2/R1, R2 - Change Management/ Shon Austin, SPP RE Vulnerability Assessments 2:40-2:50 Break 2:50-3: CIP-013 & Revised CIP Standards Chris Evans, SPP RTO Jennifer Flandermeyer, KCP&L Sushil Subedi, SPP 2:50-3: Audit Success Jim Nail, City of Independence Conf. B 3:40-4:10 Networking Break 4:10-4: Preparing for Low Impact-only Audits Jeremy Withers, SPP RE 4:50-5:00 Q&A / Closing

3 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!

4 Restrooms Restrooms Vending Machines SPP Cafe/ Lunch Smoking Auditorium

5 CIP V5/6 Lessons Learned June 27, 2017 Robert E Vaughn Ted Bell Compliance Specialist II Senior Compliance Specialist rvaughn.re@spp.org tbell.re@spp.org

6 By the Numbers Self Reports (60) CIP-007 (23) CIP-004 (11) CIP-010 (9) Audits (21) CIP-005 (10) CIP-007 (5) We ve gotten more self reports than audit findings, showing Registered Entities are being diligent with internal controls and reviews. 2

7 CIP-004 R4 Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances 3

8 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

9 CIP Part 1.3 Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default. 5

10 Firewalls done right 6

11 Firewall that s not as tough as it looks 7

12 Double check the vendor request 8

13 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

14 CIP R2 Part 2.1 A patch management process for tracking, evaluating, and installing cyber security patches for applicable Cyber Assets. 10

15 CIP R2 Part 2.2 At least once every 35 calendar days, evaluate security patches for applicability 11

16 CIP R5 Part 5.2 Have a method(s) to enforce authentication of interactive user access, where technically feasible. 12

17 CIP R5 Part 5.4 Change known default passwords, per Cyber Asset capability 13

18 CIP-010 R1 Part 1.1 Develop a baseline configuration, individually or by group 14

19 CIP-010 R1 Part 1.2 Authorize and document changes that deviate from the existing baseline configuration. 15

20 External Links CIP Kevin s analysis of the Ukraine Attack EISAC ALERT Commonly used ports, and which Trojans exploit them Danger: Open Ports Trojan is as Trojan Does 16

21 CIP Group Contact Information SPP Compliance Team SPP Enforcement Team Outreach Videos/Webinars 17

22 What Services Do You Have Exposed? Philip Daigle, Cyber Security Analyst, E-ISAC

23 What Services Do You Have Exposed Or, What do you look like to an attacker? 2

24 Why is it Important? It s easy to forget to look at what your House looks like from the Street 3

25 Define Your External IP Space 4

26 5 Don t Forget Cloud Services!

27 Tools NMAP SHODAN 6

28 Port Numbers are Great, but TCP and UDP ports can be used for just about anything Verification is key 7

29 Port Numbers are Great, but TCP and UDP ports can be used for just about anything Verification is key 8

30 Port Numbers are Great, but TCP and UDP ports can be used for just about anything Verification is key 9

31 Example Using NMAP A Script (slightly modified) From NMAP s Website #!/bin/sh TARGETS= <your external IP range>" OPTIONS="-p v -T4 -sv" date=`date +%Y.%m.%e.%H:%M:%S` cd /opt/scans nmap $OPTIONS $TARGETS -oa scan-$date > /dev/null if [ -e scan-prev.xml ]; then ndiff scan-prev.xml scan-$date.xml > diff-$date echo "*** NDIFF RESULTS ***" cat diff-$date echo fi # echo "*** NMAP RESULTS ***" # cat scan-$date.nmap ln -sf scan-$date.xml scan-prev.xml 10

32 Example Using NMAP.diff File Output From Script *** NDIFF RESULTS *** -Nmap 7.25BETA2 scan initiated Sun Mar 19 14:36: as: nmap -p22,80,443 -v -T4 -sv -oa scan :36:33 portquiz.net +Nmap 7.25BETA2 scan initiated Sun Mar 19 14:37: as: nmap -p22,80,443 -v -T4 -sv -oa scan :37:20 portquiz.net electron.positon.org, portquiz.net ( ): PORT STATE SERVICE VERSION +443/tcp open ssl/ssl Apache httpd (SSL-only mode) 11

33 Example Using Shodan To begin, point your browser to and click Login or Register 12

34 Example Using Shodan After clicking Create an Account you will receive an and you re all set to start using the service! 13

35 Example Using Shodan 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 ) 14

36 Example Using Shodan This is last time Shodan has updated the scan information for this host The responding ports are listed here 15

37 Example Using Shodan 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. 16

38 Example Using Shodan 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 17

39 Example Using Shodan Adding the filter net: followed by a network in CIDR format, will allow querying of network ranges. 18

40 Example Using Shodan Adding additional filters can allow the user to quickly narrow the search to exactly what they are looking for. 19

41 Example Using Shodan 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, Example ICS/SCADA Ports and Protocols: Modbus 502 Dnp Dnp Fieldbus ethernet/ip 2222 ethercat Profinet

42 Script Using Shodan API #!/bin/bash shodan 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 21

43 22

44 Electronic Access Controls June 27, 2017 Kevin B. Perry Director, Critical Infrastructure Protection

45 Electronic Access Point 2

46 What does your access control look like? 3

47 Corp Network Satellite Clock VLAN 20 / /24 VLAN 22 / /24 VLAN 24 / /24 Opcon A Opcon B Opcon C Opcon D Jump Host VLAN 21 / /24 VLAN 23 / /24 App A&B DB A&B HMI A&B AD Server CFE Terminal Servers A, B, and C A/V Server WSUS Server RHEL Server Syslog Server Historian A&B ESP Microsoft Windows Field Network Redhat Linux Firmware-based 4

48 Corp Network Satellite Clock VLAN 20 / /24 VLAN 22 / /24 VLAN 24 / /24 Opcon A Opcon B Opcon C Opcon D Jump Host VLAN 21 / /24 VLAN 23 / /24 App A&B DB A&B HMI A&B AD Server CFE Terminal Servers A, B, and C A/V Server WSUS Server RHEL Server Syslog Server Historian A&B ESP HTTP, HTTPS Listening Field Network 5

49 Corp Network ESP-Group Satellite Clock VLAN 20 / /24 VLAN 22 / /24 VLAN 24 / /24 Opcon A Opcon B Opcon C Opcon D Jump Host VLAN 21 / /24 VLAN 23 / /24 ESP App A&B DB A&B HMI A&B AD Server CFE Terminal Servers A, B, and C A/V Server WSUS Server RHEL Server Syslog Server Historian A&B DMZ-Group Field Network 6

50 Consider this object-group network ESP-Group network-object network-object network-object object-group network DMZ-Group network-object network-object object-group service WSUS service-object icmp echo service-object icmp echo-reply service-object icmp time-exceeded service-object icmp unreachable service-object tcp destination eq www service-object tcp destination eq 443 service-object tcp destination eq 135 service-object tcp destination range 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

51 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

52 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

53 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

54 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:

55 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

56 Risks Posed by the Rules 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

57 Risks Posed by the Rules 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

58 Risks Posed by the Rules 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

59 Corp Network Satellite Clock VLAN 20 / /24 VLAN 22 / /24 VLAN 24 / /24 Opcon A Opcon B Opcon C Opcon D Jump Host VLAN 21 / /24 VLAN 23 / /24 App A&B DB A&B HMI A&B AD Server CFE Terminal Servers A, B, and C A/V Server WSUS Server RHEL Server Syslog Server Historian A&B ESP HTTP, HTTPS Listening Field Network Windows Clients in the ESP 16

60 Improving the Access Control Lists object-group network Windows-Systems network-object object Opcon_A network-object object Opcon_B network-object object Opcon_C network-object object Opcon_D network-object object AD_Server object network WSUS-Server host object-group service WSUS service-object tcp destination range 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

61 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

62 Active Directory Required ports Dynamic RPC (default) configuration Service RPC endpoint mapper Network basic input/output system (NetBIOS) name service NetBIOS datagram service NetBIOS session service RPC dynamic assignment Server message block (SMB) over IP (Microsoft-DS) Lightweight Directory Access Protocol (LDAP) LDAP ping LDAP over SSL Global catalog LDAP Global catalog LDAP over SSL Kerberos Domain Name Service (DNS) Windows Internet Naming Service (WINS) resolution (if required) WINS replication (if required) Source: Port/protocol 135/tcp, 135/udp 137/tcp, 137/udp 138/udp 139/tcp /tcp 445/tcp, 445/udp 389/tcp 389/udp 636/tcp 3268/tcp 3269/tcp 88/tcp, 88/udp 53/tcp1, 53/udp 1512/tcp, 1512/udp 42/tcp, 42/udp 19

63 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

64 Active Directory Required Ports Limited RPC configuration Service Port/protocol RPC endpoint mapper 135/tcp, 135/udp NetBIOS name service 137/tcp, 137/udp NetBIOS datagram service 138/udp NetBIOS session service 139/tcp RPC static port for AD replication <AD-fixed-port>/TCP RPC static port for FRS <FRS-fixed-port>/TCP SMB over IP (Microsoft-DS) 445/tcp, 445/udp LDAP 389/tcp LDAP ping 389/udp LDAP over SSL 636/tcp Global catalog LDAP 3268/tcp Global catalog LDAP over SSL 3269/tcp Kerberos 88/tcp, 88/udp DNS 53/tcp, 53/udp WINS resolution (if required) 1512/tcp, 1512/udp WINS replication (if required) 42/tcp, 42/udp Source: 21

65 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

66 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

67 Corp Network Satellite Clock VLAN 20 / /24 VLAN 22 / /24 VLAN 24 / /24 Opcon A Opcon B Opcon C Opcon D Jump Host VLAN 21 / /24 VLAN 23 / /24 App A&B DB A&B HMI A&B AD Server CFE Terminal Servers A, B, and C AD Server (RODC) A/V Server WSUS Server RHEL Server Syslog Server Historian A&B ESP Field Network 24

68 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: 25

69 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

70 Interactive Remote Access 27

71 28

72 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

73 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

74 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 account Enter the one-time token value found in the body You are authenticated Question: Is this a valid form of multi-factor authentication? NO 31

75 Multi-Factor Scenario 2 Authentication is performed by the following sequence: Enter username and password One-time token is generated using an app on your smart phone Enter the one-time token You are authenticated Question: Is this a valid form of multi-factor authentication? YES 32

76 Multi-Factor Scenario 3 Authentication is performed by the following sequence: 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 You are authenticated Question: Is this a valid form of multi-factor authentication? NO 33

77 Multi-Factor Scenario 4 Authentication is performed by the following sequence: 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 You are authenticated Question: Is this a valid form of multi-factor authentication? Yes, but 34

78 Multi-Factor Scenario 5 Authentication is performed by the following sequence: Enter username and password The authentication system places a call to a pre-registered phone number (cell or landline) Answer the phone and respond as instructed You are authenticated Question: Is this a valid form of multi-factor authentication? YES (cell phone would be best) 35

79 Multi-Factor Scenario 6 Authentication is performed by the following sequence: 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 You are authenticated Question: Is this a valid form of multi-factor authentication? YES 36

80 Multi-Factor Scenario 7 Authentication is performed by the following sequence: 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 are authenticated Question: Is this a valid form of multi-factor authentication? You would think so, but, NO 37

81 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

82 SPP RE CIP Team Kevin Perry, Director of Critical Infrastructure Protection (501) Shon Austin, Lead Compliance Specialist-CIP (501) Ted Bell, Senior Compliance Specialist-CIP (501) Jeremy Withers, Senior Compliance Specialist-CIP (501) Robert Vaughn, Compliance Specialist II-CIP (501) Sushil Subedi, Compliance Specialist II-CIP (501)

83 CIP Configuration Change Management and Vulnerability Assessments Shon Austin Lead Compliance Specialist

84 Ground Rules Audience Participation Asking questions Parking lot 2

85 Learning Objectives After this presentation you will understand: CIP-010 purpose, expectations, challenges, and best practices* R1: Configuration change management R2: Configuration Monitoring * Best practices are suggested by SPP RE staff but are NOT required by the standard 3

86 Expectations What are your expectations for this presentation? 1 Think of at least thing you expect to take away from this presentation. 4

87 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

88 Prior CIP Versions Version 3 Version 5 CIP-003, R6: Change and Configuration Management CIP-005, R4 and CIP-007, R8: Cyber Vulnerability Assessments CIP-007, R1: Testing cyber security controls CIP-010, R1, R2 CIP-010, R3 CIP-010, R1.4, R1.5 6

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

90 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

91 Part1.1: Develop Baseline Configurations P1.1.1: Operating system/firmware P1.1.2: Commercially available or opensource application software P1.1.3: Custom software P1.1.4: Logical network accessible port P1.1.5: Applied security patches 9

92 P1.1: What auditors will expect Primary evidence: Documented configuration baselines Supporting evidence: Documented Configuration Change Management process 10

93 P1.1: Common Failures / Challenges Not including all required baseline items listed in Parts 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 R1) Baseline is not complete Limitations of tools Grouping 11

94 P1.1: Best Practices Use of automation 12

95 Part 1.2: Authorize and document changes 13

96 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

97 P1.2: Common Failures / Challenges 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

98 P1.2: Common Failures / Challenges Organizational silos Limitations of tools Not documenting all changes made to device baselines 16

99 P1.2: Best Practices Separation of duties Document the Who, What, When, Where, & How for changes 17

100 Part 1.3: Update baselines within 30 days of change 18

101 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

102 P1.3: Common Failures / Challenges Not documenting the updated baseline configurations within 30 days of when the change was completed 20

103 P1.3: Best Practices Communicating changes made to baseline Coordination of change implementation timing Maintaining detailed revision history Use of automation 21

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

105 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 postimplementation verification of the required security controls in CIP-005 and CIP

106 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

107 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

108 Part 1.5: Test Environment Requirements Only applicable to High Impact BES Cyber Systems 26

109 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

110 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

111 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

112 CIP-010, R2: Implement one or more documented process for Configuration Monitoring Only applicable to High Impact BES Cyber Systems 30

113 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

114 CIP-010 R2 Part 2.1: Configuration Monitoring 32

115 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

116 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

117 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

118 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

119 CIP-010 impact on other Requirements CIP R4.2 CIP R1.3 CIP R1 CIP R2 CIP R4 CIP R5 CIP R1 CIP R1 37

120 Did I miss anything 38

121 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

122 Project CIP Modifications Standard Drafting Team Meeting Summary May 2017 Columbus, OH

123 Standard Drafting Team (SDT) Meeting Activities 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 2 RELIABILITY ACCOUNTABILITY

124 Key Messages 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 3 RELIABILITY ACCOUNTABILITY

125 Communication Networks (CommNet) 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 4 RELIABILITY ACCOUNTABILITY

126 Transmission Owner Control Centers (TOCC) 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. 5 RELIABILITY ACCOUNTABILITY

127 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. 6 RELIABILITY ACCOUNTABILITY

128 CIP Exceptional Circumstance (CEC) 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. 7 RELIABILITY ACCOUNTABILITY

129 Virtualization 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 8 RELIABILITY ACCOUNTABILITY

130 Draft Virtualization Definitions 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) 9 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. RELIABILITY ACCOUNTABILITY

131 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 E RELIABILITY ACCOUNTABILITY

132 Draft Virtualization Requirements 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 applicable systems: High & Medium Impact BES Cyber Systems residing in a Multi-instance environment and their associated CMS CIP-005 R1, Part 1.7 requirement: Identify, control and explicitly allow only necessary inbound and outbound communication between ESZs 11 RELIABILITY ACCOUNTABILITY

133 Draft Virtualization Requirements CIP-005 R1, Part 1.8 applicable systems: High & Medium Impact BES Cyber Systems residing in a Multi-instance environment and their associated CMS 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 applicable systems: High & Medium Impact BES Cyber Systems residing in a Multi-instance environment and their associated CMS 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; 12 RELIABILITY ACCOUNTABILITY

134 Next Steps 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 13 RELIABILITY ACCOUNTABILITY

135 Conference Call Schedule Conference Dial-in Access Code Reserved Call Times Fridays - 11 a.m. 1 p.m. (ET) o Full team update o 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 session o Security code: 0002 Thursdays - Noon 2 p.m. (ET) o Sub-team working session o Security Code: 0004 Sub-team working calls will be scheduled as needed to allow the sub-teams to process input and develop proposals. 14 RELIABILITY ACCOUNTABILITY

136 SDT Meeting Schedule 2017 Planned Dates: June Montreal, Quebec - Hydro-Québec TransÉnergie ALL REMAINING MEETINGS WILL BE SCHEDULED BASED ON POSTING TIMELINES o July o August o September o October o November 15 RELIABILITY ACCOUNTABILITY

137 Resources Information relative to the CIP Modifications project and SDT may be found on the Project Project Page under Related Files: Project Modifications to CIP Standards Mat Bunch, NERC Staff: Katherine Street, NERC Staff : katherine.street@nerc.net 16 RELIABILITY ACCOUNTABILITY

138 17 RELIABILITY ACCOUNTABILITY

139 CIP-013 Cyber Security Supply Chain Chris Evans - Southwest Power Pool Manager, Cyber Security cevans@spp.org 1

140 Where are we? CIP-013 Implementation Guidance endorsed by the ERO SDT meeting to respond to comments and make minor modifications to standards Next posting will be in early July most likely for final ballots Filing deadline June 7th June 16th June 20 th -21st June 30 th Early July August 10 th September 27th CIP-013-1, CIP-005-6, CIP passes SDT Web Meeting June 30 August 10 NERC Board of Trustees Meeting

141 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

142 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

143 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: Verify the identity of the software source; and Verify the integrity of the software obtained from the software source. 5

144 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

145 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

146 Common Questions CIP-013 R1.2.2 Coordination of responses to vendoridentified 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. Note This is just an example of one method to address this requirement. 8

147 Common Questions CIP-013 R 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. Note This is just an example of one method to address this requirement. 9

148 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

149 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

150 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

151 Questions? Refer to the Project page for more information to join the list Corey Sellers, Southern Company, SDT Chair at JoAnn Murphy, PJM Interconnection, SDT Vice Chair at 13

152 City of Independence Power & Light Department Jim Nail Reliability Compliance Coordinator

153 2016 O&P AUDIT Zero Findings Zero Concerns The Successful Result of a Three Year Strategy.

154 City of Independence Power & Light Department Municipal Utility TO/TOP/TP/GO/GOP/DP/RP Compliance Staff: 4 Plus 15 SME s

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

156 Learn from our Mistakes Take Audit Comments Seriously Incorporate Changes Avoid Repeat Errors Improve Narrative/Evidence

157 IPL Strategy Maintain & Build on Success Improve vs. Re-write On-going Program vs. Audit Prep If the Auditors Liked it

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

159 Establish Basic Internal Controls Checklist of Annual Requirements Checklist of Event Driven Requirements Document Review Process SharePoint Document Control Compliance Team Oversight

160 Participate! Participate! Participate! Workshops & Forums Standard Drafting Teams/Webinars SPP Working Groups

161 2016 Audit Preparation One Year Out RSAW Reviews SME Reviews Evidence Reviews

162 RSAW Reviews Focus on Narrative Speak to the Requirement and only the requirement Road Map to the Evidence

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

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

165 Third Party Reviews 5-6 Months SPP/RTO Staff Focused on Expected Audit Scope Mock Audit

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

167 Manage the Audit Facilities Reserved Staff Present or Available Cooperative, Non-Adversarial Atmosphere Compliance Coordinator Primary Spokesman SME on hand as back-up

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

169 Results 19 Evidence Requests Zero PV Zero Areas of Concern

170 Questions???

171 Audit Preparation and Expectations The Low-Down June 27, 2017 Jeremy Withers, CISSP, Security+, Network+, CISA Senior Compliance Specialist - CIP SPP RE Staff 1

172 Overview Audit preparation tips Audit overview Cyber security plan CIP Version 5 Evidence Request RSAW completion Evidence Request Workbooks Summary 2

173 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

174 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 stored 4

175 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

176 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

177 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-ofday briefing, Exit Presentation Post-Audit: Draft audit report, Registered Entity comments (10 days), Feedback forms, Final audit report (non-public) 7

178 CIP Audit Scope (Low Impact BES Cyber Systems) CIP a Requirement R1 & R2 CIP Requirement R1.2 Part Part Part Part

179 CIP Audit Scope (Low Impact BES Cyber Systems) CIP 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) CIP Requirement R3 CIP Requirement R4 9

180 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

181 CIP 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: Cyber security awareness; Physical security controls; Electronic access controls for Low Impact External Routable Connectivity (LERC) and Dial up Connectivity; and Cyber Security Incident response 11

182 CIP 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

183 CIP 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

184 CIP R2 Attachment 1 Section 2 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

185 CIP R2 Attachment 1 Section 3 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

186 CIP R2 Attachment 1 Section 4 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

187 CIP R2 Attachment 1 Section 4 (cont.) Section 4 Cyber Security Incident Response plan(s) 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

188 CIP R2 Attachment 1 Section 4 (cont.) Section 4 Cyber Security Incident Response plan(s) 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

189 19

190 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

191 21

192 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

193 BES Assets Tab 23

194 Level 1 Tab 24

195 Level 1 Tab (cont.) 25

196 Sample Sets L2 Tab 26

197 Level 2 Tab 27

198 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

199 29

200 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

201 CIP RSAW completion example 31

202 CIP RSAW completion example (cont.) 32

203 CIP RSAW completion example (cont.) 33

204 CIP RSAW completion example (cont.) 34

205 CIP RSAW completion example (cont.) 35

206 CIP RSAW completion example (cont.) 36

207 Evidence Request Workbook Completion 37

208 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

209 Evidence Request Workbook example 39

210 Evidence Request Workbook example (cont.) 40

211 EFT Upload All audit documentation should be uploaded to the EFT server in the following format: 41

212 Questions 42