CIP Ben Christensen Senior Compliance Risk Analyst, Cyber Security

Transcription

1 CIP Ben Christensen Senior Compliance Risk Analyst, Cyber Security

2 2 Agenda Help entities understand and prepare for the upcoming CIP Differences and relations to current requirements Transient devices and removable media Possible pitfalls to look for while implementing CIP WECC s audit approach Best practices

3 3 CIP 010-2

4 4 CIP Effective Dates CIP R1 R3 April 1, 2016 for documented processes April 1, 2017 for active or paper vulnerability assessment (15 months) April 1, 2018 for active vulnerability assessment (36 months) CIP R4 January 1, 2017 Registered Entities shall not be required to comply with Reliability Standard CIP-010-2, Requirement R4 (TRANSIENT DEVICES) until nine calendar months after the effective date of Reliability Standard CIP

5 5 Applicable Systems

6 6 Applicable Systems in R4 Transient Devices Removable Media

7 7 Purpose of CIP Prevent and detect unauthorized changes to BES Cyber Systems. Specify vulnerability assessment requirements in support of protecting BES Cyber Systems from compromise. Document and maintain device baselines and periodically verify they are accurate. Prevent unauthorized access or malware propagation from transient devices.

8 8 CIP Similarities with V3 CIP R6: Change Control and Configuration Management CIP R1: Test procedures CIP R4 and CIP R8: Cyber Vulnerability Assessment(s) CIP R9 and CIP R5: Documentation review and maintenance

9 9 CIP R1

10 CIP R1 Part 1.1 Applicable to Protected Cyber Assets (PCA) and specifies information required in device baselines CIP R1.1 CIP R6

11 11 CIP R1 Part Possible Pitfall #1 CIP R6 was previously not applicable to Non-CCAs that resided within an ESP. Thus entity did not create baselines or update procedures to ensure baselines were maintained for these devices.

12 12 CIP R1 Part Possible Pitfall #2 Entity does not ensure documented baselines for all devices contain operating system, commercial/open source software, custom software, logical ports, and security patches applied.

13 13 CIP R1 Part Possible Pitfall #2 Software Software name, version, patch level Custom software needs to be listed with version

14 14 CIP R1 Part 1.1 Approach Ensure entity has documented baselines for all devices (or group of devices) in applicable BES Cyber Systems Verify baselines include operating system/firmware, commercial software, custom software, logical network accessible ports, and security patches applied

15 15 Limited Device Example Serial-only microprocessor relay: Asset # at Substation Alpha R1.1.1 Firmware: [MANUFACTURER]-[MODEL]-XYZ ABC R1.1.2 Not Applicable R1.1.3 Not Applicable R1.1.4 Not Applicable R1.1.5 Patch 12345, Patch 67890, Patch 34567, Patch

16 16 CIP R1 Part 1.1 Approach 5 minimum components of baseline software/firmware versions open source/commercially available software custom applications logical network accessible ports applied security patches Information about hardware differences may apply since it could affect installed applications and patches

17 17 Basic Baseline

18 18 CIP R1 Part 1.1 Best Practice Use combination of automated tools and manual walkthroughs/verifications to ensure lists and baselines are accurate Minimize applications on devices to only what is necessary Include step to periodically verify accuracy of applicable device lists and baselines

19 19 CIP R1 Part 1.1 Best Practice Discussions and careful planning should be conducted on the method for maintaining device baselines Review CIP 007 R3 presentation from Oct 2013 CIPUG for common methods to maintain information What method is best for your organization: Commercial Software Custom Software Spreadsheet

20

21 21 CIP R1 Part 1.2 Applicable to PCA and requires changes to be authorized CIP R1.2 CIP R6

22 22 CIP R1 Part Possible Pitfall Entity cannot demonstrate all changes made to baseline(s) were authorized

23 23 CIP R1 Part Possible Pitfall Entity only documents enabled ports and services for Medium Impact BCS with ERC which is CIP R1 Part 1.1

24 24 CIP R1 Part Approach Ensure all changes made to baselines have been authorized.

25 25 CIP R1 Part Approach

26 CIP Part Approach 26

27 27 CIP Part 1.2 Self Reporting When should an entity self report on R1.2? Keep in mind that this process is new! Let s work together to determine the best course to take based on the facts and circumstances

28 28 CIP Part 1.2 Best Practice Update procedural documentation to include at minimum: Who can authorize changes, and to what When authorization needs to occur How the authorization will be documented, stored, and tracked Segregation of duties The implementer should be different from the authorizer

29 29 CIP R1 Part 1.3 Baselines must be updated within 30 days of change CIP R1.3 CIP R5 CIP R9

30 30 CIP Possible Pitfall Entity cannot demonstrate baselines are updated within 30 days of changes made

31 31 CIP R1 Part Approach Ensure entity is updating baselines within 30 days of when change was made. Start date will be determined by reviewing work orders, tracking sheet, or other documentation that details when the change actually occurred.

32 32 CIP R1 Part Approach Should baseline be updated when the first cyber asset in a BCS is changed or when the last one in the BCS is changed?

33 33 CIP R1 Part 1.3 Best Practices Procedures for updating baselines should address: Who will communicate the changes made to the baselines How changes will be communicated Who the changes are communicated to When the changes will be made

34 34 CIP R1 Part 1.3 Best Practices Maintain a version history when updating documentation. Version number Who performed the update to the documentation Who made the change to the device Who authorized the change What was changed

35 35 CIP R1 Part 1.4 Impact due to a change must consider security controls in CIP 005 and CIP 007 CIP R1.4 CIP R1

36 36 CIP R1 Part 1.4 Possible Pitfall Entity verifies same controls for all changes made to any baseline. Thus entity does not account for different environments, devices, or changes when determining what controls could be impacted May be ok if all controls are verified every time

37 37 CIP R1 Part Approach Verify all changes made to device baselines are documented Ensure controls that may be impacted were identified and documented prior to the change Why were some controls not included? Review evidence supporting identified controls were not adversely impacted

38 38 CIP R1 Part 1.4 Best Practices Procedures should include: Documenting date all steps taken to support cyber security controls were identified prior to change taking place How are potential impacted cyber security controls identified? Who does this? How will adverse impacts be detected Who does this and when?

39 39 CIP R1 Part 1.4 Best Practices Include a peer review step for reviewing what controls may be impacted and when verifying controls weren t adversely impacted Coordinate testing processes between departments, business units, etc. to ensure consistency

40 40 CIP R1 Part R1.5 CIP R1.5 CIP R1

41 41 CIP R1 Part R1.5 Cont. Only applicable to High Impact systems Specific to security controls that must be tested Security Controls in CIP 005 and CIP 007 New test environment requirements Document if test environment was used Document differences between test and production environment Measures taken to account for these differences

42 42 CIP R1 Part R1.5 Possible Pitfall Entity does not document differences between production and testing environment Entity does not take measures to account for differences in the production and testing environment.

43 43 CIP R1 Part R1.5 - Approach For each change that deviates from existing baseline: List of cyber security controls tested Test results List of differences between the production and test environments Descriptions of how any differences were accounted for When testing occurred

44 44 CIP R1.5 Best Practices Use checklist or other task managing tool to reduce likelihood of not testing all controls Document specific test procedures for all cyber assets or group of assets? Describe the test procedures Describe the test environment and how it models the production environment

45 45

46 46 CIP R2 Part 2.1 Must actively search for unauthorized changes to baseline Automated preferred but can be manual Must document and investigate unauthorized changes CIP R2.1 CIP R6

47 47 CIP Part 2.1 Possible Pitfall Not consistently monitoring for changes every 35 days Entity begins process at end of month Thus entity continuously misses 35 day deadline as it does not have enough time to complete review Documentation is inconsistent and SMEs can t keep track if specific devices have automated or manual process for tracking configuration changes

48 48 CIP Part Approach Logs from a system that is monitoring configurations Work orders, tracking sheets, raw data evidence of manual investigations Records investigating detected unauthorized changes

49 49 CIP Part Approach Sample review of baseline

50 50 CIP R2 Best Practice Consider using a commercial or open source File Integrity Monitoring software for continuous monitoring Start monitoring process with enough advance to complete review o Consider using an automated task managing tool

51 51 CIP R2 Best Practice What if you find an unauthorized change? What change(s) have been made without authorization Who made the change(s)? When were the change(s) made? How can a similar issue be prevented?

52 52 CIP R2 Best Practice ONLY FOR HIGH IMPACT BES CYBER SYSTEMS, EACMS, and PCA Some evaluation required at least every 35 days Keep in mind that this process is new! Let s work together to determine the best course to take based on the facts and circumstances

53 53 CIP R1 and R2 QUIZ Time

54 54 CIP R1 and R2 Entities are required to test all changes in a test environment that reflects the production environment. False

55 55 CIP R1 and R2 Entity baselines are required to include: 1. Operating system/firmware 2. Commercial/open source software 3. Custom software 4. Logical ports 5. All security patches applied TRUE But what about devices where some of these don t apply?

56 56 CIP R3

57 57 CIP R3.1 No more annual requirement; vulnerability assessment (VA) can be active or paper CIP R3.1 CIP R4 CIP R8

58 58 Vulnerability Assessment Timelines 1 st performance of active or paper (15 months) April 1, st performance of active (36 months) April 1, 2018

59 59 CIP R3.1 Possible Pitfall Entity conducts initial vulnerability assessment in January then not again until April the next year (16 months) Miss the 1 st performance of active and paper vulnerability assessments

60 60 4 Steps for Paper Vulnerability Assessment 1. Network Discovery 2. Network Port and Service Identification 3. Vulnerability Review 4. Wireless Review

61 61 Paper Vulnerability Assessment Network Discovery A review of network connectivity to identify all Electronic Access Points to the Electronic Security Network Port and Service Identification A review to verify that all enabled ports and services have an appropriate business justification.

62 62 Paper Vulnerability Assessment Vulnerability Review A review of security rule sets and configurations including controls for default accounts, passwords, and network management community strings. Wireless Review Identification of common types of wireless networks (such as a/b/g/n) and a review of their controls if they are in any way used for BES Cyber System communications.

63 63 What is a Paper Assessment? Is it a document review exercise? still requires something active to be conducted Should I perform physical inspections? Do I need to include Enumeration of ports and services?

64 64 What is a Paper Assessment? Should include: Document reviews Such as reviews of known vulnerabilities of installed applications Dumps of configs Such as list of open listening ports generated by platform resident tools such as netstat Might contain information about issues such as: Current threats and how the baseline configurations are designed to address them

65 65 4 Steps for Active Assessment 1. Network Discovery 2. Network Port and Service Identification 3. Vulnerability Scanning 4. Wireless Scanning

66 66 Active Vulnerability Assessment Network Discovery - Use of active discovery tools to discover active devices and identify communication paths in order to verify that the discovered network architecture matches the documented architecture. Network Port and Service Identification Use of active discovery tools (such as Nmap) to discover open ports and services.

67 67 Active Vulnerability Assessment Vulnerability Scanning Use of a vulnerability scanning tool to identify network accessible ports and services along with the identification of known vulnerabilities associated with services running on those ports. Wireless Scanning Use of a wireless scanning tool to discover wireless signals and networks in the physical perimeter of a BES Cyber System. Serves to identify unauthorized wireless devices within the range of the wireless scanning tool.

68 68 What tools should I use? Are tools such as Nmap required for active assessments, or can entities use custom scripts (which use native OS commands) to enumerate open ports and services? What constitutes an active port scan?

69 69 CIP R3 Part 3.1 Approach Verify when last vulnerability assessment was conducted Verify current vulnerability assessment was conducted within 15 calendar months of previous vulnerability assessment Evidence could include: A document listing the date of the assessment and the output of any tools used to perform the assessment.

70 70 CIP R3 Initial Evidence C:\HMI-1>netstat Active Connections Proto Local Address Foreign Address State TCP HMI-1:2111 localhost:33333 ESTABLISHED TCP HMI-1:3616 localhost:10525 ESTABLISHED TCP HMI-1:5152 localhost:1573 CLOSE_WAIT TCP HMI-1:10525 localhost:3616 ESTABLISHED TCP HMI-1:33333 localhost:2111 ESTABLISHED TCP HMI-1:netbios-ssn :56761 TIME_WAIT TCP HMI-1:netbios-ssn :56762 TIME_WAIT TCP HMI-1:netbios-ssn :56765 TIME_WAIT TCP HMI-1:netbios-ssn :56766 TIME_WAIT

71 R3 Evidence Nessus Summary 71

72 Nessus Summary 72

73 Cyber Vulnerability Assessment

74 74 Manual Review of Configs #show run ip http server! access-list 23 permit access-list 23 permit ! line vty 5 15 transport input ssh! access-class 23 in! ntp-server

75 75 Manual Review of Configs #show run no logging ip http server! access-list 23 permit access-list 23 permit ! line vty 5 15 transport input telent Login Password ***********! access-class 23 in! no logging console debug condition interface no snmp-server ntp-server

76 76 CIP R3 Typical Data Requests For the following servers and workstations (within the BCS) provide current netsat (netstat b o a -n / netstat p a -l) or port scan (TCP/UDP) results. [sample list] For the following network devices, provide current configuration files (i.e., show run all), ports and services running (scan results if exists) Provide a spreadsheet identifying all BCS assets, associated TFEs, and associated requirements

77 77 CIP R3 Typical Data Requests Provide initial paper vulnerability assessment report Provide initial active vulnerability assessment Provide subsequent assessments Provide detailed (RAW DATA) vulnerability assessment results for the following specific BCS, EACMs and PACS [sample list] Provide mitigation plan and results (current status) for VA Provide action plan and current status

78 78 CIP R3 Typical Interview Questions How do you perform an active and paper assessment? Describe the procedures used to identify the required ports/services Are vendors involved with the definition of required ports/services? Are there devices, which ports and services cannot be disabled? If so, what are the compensating measures in place

79 79 CIP R3 Typical Interview Questions Describe the vulnerability assessment process Who performs the assessment? Is the assessment performed in-house or outsourced Does the assessment include all BCS and cyber assets? specific addresses or entire networks Describe procedures/tools utilized to identify open ports/services and user accounts Is there a baseline to compare ports/services and user accounts with?

80 80 R3 Audit Evidence Examples Netstat: Netstat -b -o -a -n > netstat_boan.txt Netstat -p -a -l > netstat_pal.txt NMAP scan results Nmap st sv p T: <IP_address> >>nmap_tcp.txt Nmap su sv p U: <IP_address> >> nmap_udp.txt show control-plane host open-ports Manual review show run config file (router or firewall)

81 81 Vulnerability Assessment Sample Checklist Active or Paper Network Discovery Review of network diagrams Walk down performed Ping sweeps Network Port and Service Identification Nmap scans of all subnets Netstat or other resident tool used Manual review of config

82 Vulnerability Assessment Sample Checklist Cont. Vulnerability Scanning Nmap/Nessus scan performed Manual review of config Rule-sets Accounts Passwords Default community strings Wireless Scanning Scan performed Visual inspection performed 82

83 83 HMI-1 Baseline Evidence C:\Documents and Settings\HMI-1>netstat -b -o -a -n > netstat_boan.txt Active Connections Proto Local Address Foreign Address State PID TCP : :0 LISTENING 952 C:\WINDOWS\system32\svchost.exe TCP : :0 LISTENING 4 [System] TCP : :0 LISTENING 428 [spnsrvnt.exe] TCP : :0 LISTENING 248 [sntlkeyssrvr.exe] TCP : :0 LISTENING 248 [sntlkeyssrvr.exe] TCP : :0 LISTENING 1656 [dirmngr.exe] TCP : :0 LISTENING 2484 [alg.exe] TCP : :0 LISTENING 1764 [jqs.exe] TCP : :0 LISTENING 1856 [PGPtray.exe] TCP : :0 LISTENING 4 [System] TCP : :33333 ESTABLISHED 1616 UDP :7001 *:* 248 [sntlkeyssrvr.exe] UDP :500 *:* 700 [lsass.exe] UDP :4500 *:* 700 [lsass.exe] UDP :445 *:* 4 [System] UDP :123 *:* 1084 c:\windows\system32\ws2_32.dll UDP :6001 *:* 428 [spnsrvnt.exe]

84 84 HMI-1 Evidence Cont. nmap -st -sv -p T: Starting Nmap 5.59BETA1 ( ) at :28 EST Nmap scan report for Host is up ( s latency). Not shown: closed ports PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 777/tcp open multiling-http? 6002/tcp open http SafeNet Sentinel License Monitor httpd /tcp open afs3-callback? 7002/tcp open http SafeNet Sentinel Keys License Monitor httpd 1.0 (Java Console) MAC Address: 00:0C:29:07:09:3B (VMware) Service Info: Host: HMI-1; OS: Windows

85 85 HMI-1 Evidence Cont. nmap -su -sv -p U: Starting Nmap 5.59BETA1 ( ) at :28 EST Nmap scan report for Host is up ( s latency). Not shown: closed ports PORT STATE SERVICE VERSION 123/udp open ntp Microsoft NTP 137/udp open netbios-ns Microsoft Windows NT netbios-ssn (workgroup: WORKGROUP) 138/udp open filtered netbios-dgm 445/udp open filtered microsoft-ds 500/udp open filtered isakmp 1900/udp open filtered upnp 4500/udp open filtered nat-t-ike 6001/udp open filtered X11:1 MAC Address: 00:0C:29:07:09:3B (VMware) Service Info: Host: HMI-1; OS: Windows

86 86 EMS1 Evidence

87 87 EMS1 Evidence Cont. EMS1 nmap -st -sv -p T: Starting Nmap 5.59BETA1 ( ) at :15 EST Nmap scan report for Host is up (0.034s latency). Not shown: closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu6 (protocol 2.0) 80/tcp open http Apache httpd ((Ubuntu)) 111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000) 42851/tcp open status (status V1) 1 (rpc #100024) MAC Address: 00:0C:29:66:05:65 (VMware) Service Info: OS: Linux Service detection performed. Please report any incorrect results at Nmap done: 1 IP address (1 host up) scanned in seconds

88 88 EMS1 Evidence Cont. EMS1 nmap -su -sv -p U: Starting Nmap 5.59BETA1 ( ) at :15 EST Nmap scan report for Host is up (7.57s latency). Not shown: closed ports PORT STATE SERVICE VERSION 68/udp open filtered dhcpc 111/udp open rpcbind MAC Address: 00:0C:29:66:05:65 (VMware) Nmap done: 1 IP address (1 host up) scanned in seconds Service detection performed. Please report any incorrect results at Nmap done: 1 IP address (1 host up) scanned in seconds

89 89 Router Ports/Services

90 2014 Vulnerability Assessment 90

91 BPC Vulnerability Assessment

92 2014 BPC Vulnerability Assessment 92

93 Active Vulnerability Assessment Wireless Scanning 93

94 CVA- HMI1 Software Vulnerability Security vulnerability - exploit available to execute arbitrary code. Exploit Title: KingView 6.53 SCADA HMI Heap Overflow PoC 9/28/ # Exploit Title: KingView SCADA ActiveX W ETCP S T777 E R N E L E C T R I C I T Y C O O R D I N A T I N G C O U N C I L

95 95 EMS1 Baseline Evidence

96 96 CIS Scan Results - Local Account Results Account Name :Administrator The Administrator account is an ADMINISTRATOR, and the password was changed 1207 days ago. This account has been used 70 times to logon. The default Administrator account has not been renamed. Comment :Built-in account for administering the computer/domain Account Name :bill The ubill account is an ADMINISTRATOR, and the password was changed 548 days ago. This account has been used 0 times to logon. Comment :auto-logon account Account Name :billiam The billiam account is an ADMINISTRATOR, and the password was changed 548 days ago. This account has been used 233 times to logon. Comment :shared account WARNING Administrator's password is blank

97 97 Nessus Results Services

98 3 rd Party Vulnerability Assessment Sample 1 host 98

99 99 CIP R3 Part 3.1 Best Practice Consider keeping vulnerability assessments for devices or groups of devices on the same cycle Implement a task managing tool to help track needed tasks and deadlines Review NIST SP for guidance on conducting a vulnerability assessment

100 100 CIP R3 Part 3.2 CIP R3.2 CIP R4 CIP R8

101 101 CIP R3 Part 3.2 Cont. Only applicable to High Impact BES systems Required to be performed at least every 36 months Vulnerability assessment must be active and can be performed in production or test environment Test environment must model production Document differences between test and production environment Take and document measures to address the differences between test and production environment

102 102 CIP R3 Part 3.2 Cont. Vulnerability assessment can be conducted on sub-groups in one BCS instead of all Cyber Assets in the BCS

103 103 CIP R3 Part 3.2 Possible Pitfall Entity does not conduct active vulnerability assessments at least every 36 months Entity does manual review on devices that are technically feasible to have active assessment

104 104 CIP R3 Part 3.2 Approach Verify active vulnerability assessments conducted at least every 36 months Description of test environment and how differences were accounted for (if test environment used for assessment) Raw data outputs of assessment for applicable devices

105 105 Production Vs. Test

106 106 CIP R3 Part 3.2 Best Practices Vulnerability assessment should include at minimum: Network and access point discovery Port and service Identification Review of default accounts, passwords, and network management community strings Wireless access point review

107 107 CIP R3 Part 3.2 Best Practice Where possible conduct the vulnerability assessment on the production environment Implement a task managing tool to help track needed tasks and deadlines Document SMEs responsible for conducting the vulnerability assessment and for what cyber assets

108 108 CIP R3 Part 3.3 New devices need an active vulnerability assessment prior to deployment CIP R3.3 CIP R1

109 109 CIP R3 Part 3.3 Possible Pitfall Entity adds new asset to production without first conducting active vulnerability assessment

110 110 CIP R3 Part 3.3 Approach Ensure all newly added assets have had active vulnerability scan conducted prior to device being added to production Verify all necessary controls were verified as part of assessment Verify raw data output of vulnerability assessment can be provided

111 111 CIP R3 Part 3.3 Best Practice Document specific procedures that include: Responsible personnel for conducting the test When testing needs to occur Where testing should occur How the testing should be conducted for each cyber asset or group of cyber assets Use a checklist and/or peer reviews to reduce chance of human error

112

113 113 CIP R3 Part 3.4 Document planned completion date for each remediation action CIP R4 CIP R3.4 CIP R8

114 114 CIP R3 Part 3.4 Possible Pitfall Entity is not actively maintaining an action plan to remediate vulnerabilities found in the vulnerability assessment Entity is not documenting or updating planned date of completion for remediation actions

115 115 CIP R3 Part 3.4 Approach Document results or the review or assessment List of action items to remediate issues Status of the action items Documented proposed dates of completion for the action plan What is a reasonable timeframe?

116 116 CIP R3 Part 3.4 Approach Basic sample of action items with status

117 117 R3 BPC Mitigation Plan CIP R3.4 Document the results of the assessments action plan to remediate or mitigate vulnerabilities identified planned date of completing the action plan and the execution status BPC mitigation plan There is work in progress within BPC as well from current vendors to document correct Ports/Services required. The vendor will be on-site in March to assist with the finalization of this effort. Expected completion of the definitions for each host/group of hosts, to be completed June 30, BPC mitigation plan After the completion of the mitigation plan BPC will begin a validation and change process to ensure that all systems within the BCS have the approved ports and services configured and un-needed ports/services disabled or removed. The expected completion date for this effort will be by September 31, 2014.

118 118 R3 Mitigation Plan

119 119 CIP R3 Part 3.4 Best Practice Tie actions outlined in the plan to specific SMEs Use an automated task managing tool to track all required tasks and ensure they are being completed Have steps to ensure action plan is updated and reflects actual proposed completion date of actions

120 120 CIP R3 QUIZ Time

121 121 CIP R3 Entities are required to test all changes in a test environment that models the production environment. False Active VA not required for Medium impact facilities or for like devices with similar baseline configurations

122 122 CIP R3 Entity s will be required to meet expected completion date of action plans to remediate issues found during vulnerability assessment However, entity can update the expected date if more time is needed. TRUE If the update is reasonable, justified, and done prior to the due date.

123 123 Transient and Removable Media

124 124 CIP R4 Each Responsible Entity, for its high impact and medium impact BES Cyber Systems, shall implement one or more documented Transient Cyber Asset and Removable Media plan(s) that include the applicable elements in Attachment 1

125 125 CIP R4 Goals To address FERC Order No. 791 Paragraphs 6 and 136, which require the standards to address security-related issues associated with tools specifically used for data transfer, vulnerability assessment, maintenance, or troubleshooting.

126 126 CIP R4 Goals Preventing unauthorized access or malware propagation to BES Cyber Systems through Transient Cyber Assets or Removable Media; and Preventing unauthorized access to BES Cyber System Information through Transient Cyber Assets or Removable Media

127 127 7/16/2015 FERC NOPR Transient Devices FERC states R4 is satisfactory and addresses the following: 1. Device authorization 2. Software authorization 3. Security patch management 4. Malware prevention 5. Unauthorized use

128 128 7/16/2015 FERC NOPR Transient Devices NERC will provide information to FERC why R4 should not apply to Low Impact BES Cyber Systems FERC may have NERC address this gap by developing a solution Modification to the Standard?

129 129 Transient Cyber Asset and Removable Media Plan Transient Cyber Asset(s) Managed by the Responsible Entity Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity Removable Media

130 Transient Cyber Asset(s) Managed by the Responsible Entity 1.1 Transient Cyber Asset Management 1. Ongoing manner to ensure compliance with applicable requirements at all times 2. On-demand manner applying the applicable requirements before connection to a BES Cyber System 3. Combination of both 130

131 Transient Cyber Asset(s) Managed by the Responsible Entity 1.2 Transient Cyber Asset Authorization: For each individual or group of Transient Cyber Asset(s), each Responsible Entity shall authorize: Users, either individually or by group or role Locations, either individually or by group; and Uses, which shall be limited to what is necessary to perform business functions. 131

132 Transient Cyber Asset(s) Managed by the Responsible Entity 1.3. Software Vulnerability Mitigation: Use one or a combination of the following methods to achieve the objective of mitigating the risk of vulnerabilities posed by unpatched software on the Transient Cyber Asset (per Transient Cyber Asset capability): Security patching, including manual or managed updates; Live operating system and software executable only from read-only media; System hardening; or Other method(s) to mitigate software vulnerabilities. 132

133 Transient Cyber Asset(s) Managed by the Responsible Entity 1.4. Introduction of Malicious Code Mitigation: Use one or a combination of the following methods to achieve the objective of mitigating the introduction of malicious code (per Transient Cyber Asset capability): Antivirus software, including manual or managed updates of signatures or patterns Application whitelisting; or Other method(s) to mitigate the introduction of malicious code 133

134 Transient Cyber Asset(s) Managed by the Responsible Entity 1.5. Unauthorized Use Mitigation: Use one or a combination of the following methods to achieve the objective of mitigating the risk of unauthorized use of Transient Cyber Asset(s): Restrict physical access; Full-disk encryption with authentication; Multi-factor authentication; or Other method(s) to mitigate the risk of unauthorized use. 134

135 135 CIP R4 Approach Auditors will request your plan(s) which address Transient Devices and Removable Media Evidence of records of connecting, using, and disconnecting Transient Devices and Removable Media Sample of devices and methods used to secure device prior to connecting

136 136 CIP R4 Example Sample record Raw data Screen shot of A/V signatures, patch level Screenshot of full disk encryption settings Change ticket

137 CIP R4 Change Ticket Example 137

138 Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity 138 Implement actions prior to connecting the vendor or contractor-owned Transient Cyber Asset.

139 Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity 2.1 Software Vulnerabilities Mitigation: Use one or a combination of the following methods to achieve the objective of mitigating the risk of vulnerabilities posed by unpatched software on the Transient Cyber Asset (per Transient Cyber Asset capability): Review of installed security patch(es); Review of security patching process used by the party; Review of other vulnerability mitigation performed by the party; or Other method(s) to mitigate software vulnerabilities. 139

140 Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity 2.2 Introduction of malicious code mitigation: Use one or a combination of the following methods to achieve the objective of mitigating malicious code (per Transient Cyber Asset capability): Review of antivirus update level; Review of antivirus update process used by the party; Review of application whitelisting used by the party; Review use of live operating system and software executable only from read-only media; Review of system hardening used by the party; or Other method(s) to mitigate malicious code. 140

141 Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity 2.3 For any method used to mitigate software vulnerabilities or malicious code as specified in 2.1 and 2.2, Responsible Entities shall determine whether any additional mitigation actions are necessary and implement such actions prior to connecting the Transient Cyber Asset. 141

142 Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity Sample review record 142

143 CIP R4 Change Ticket Example 143

144 144 Removable Media 3.1. Removable Media Authorization: For each individual or group of Removable Media, each Responsible Entity shall authorize: Users, either individually or by group or role; and Locations, either individually or by group.

145 145 Removable Media 3.2. Malicious Code Mitigation: To achieve the objective of mitigating the threat of introducing malicious code to high impact or medium impact BES Cyber Systems and their associated Protected Cyber Assets, each Responsible Entity shall: Use method(s) to detect malicious code on Removable Media using a Cyber Asset other than a BES Cyber System or Protected Cyber Assets; and Mitigate the threat of detected malicious code on Removable Media prior to connecting the Removable Media to a high impact or medium impact BES Cyber System or associated Protected Cyber Assets.

146 146 Transient and Removable Media Types These assets do not provide BES reliability services and are not part of the BES Cyber Asset they are connected to. Examples of these devices include, but are not limited to: Hardware/software diagnostic test equipment Hardware/software packet sniffers Hardware/software used for BES Cyber System maintenance Hardware/software used for BES Cyber System configuration Hardware/software used to perform vulnerability assessments

147 147 Removable Media Types Storage media that (i) are not Cyber Assets, (ii) are capable of transferring executable code, (iii) can be used to store, copy, move, or access data, and (iv) are directly connected for 30 consecutive calendar days or less to: A BES Cyber Asset A network within an ESP A Protected Cyber Asset that can be used to store, copy, move, or access data Removable Media are not Cyber Assets. Examples include, but are not limited to, floppy disks, compact disks, USB flash drives, external hard drives, and other flash memory cards/drives that contain nonvolatile memory.

148 148 Transient Cyber Asset Types Transient Cyber Asset: A Cyber Asset, (e.g., using Ethernet, serial, Universal Serial Bus, and wireless including near field and Bluetooth communication) directly connected for 30 consecutive calendar days or less, capable of transmitting executable code to: A BES Cyber Asset A network within an ESP A Protected Cyber Asset

149 149 Transient Cyber Asset Types Examples include, but are not limited to Cyber Assets used for: Data transfer Vulnerability assessment Maintenance Troubleshooting purposes Once the transient device is disconnected, the requirements listed herein are not applicable.

150 150 CIP R4 Approach How should I document the use and removal of transient devices and removable media? Maintain records: Which devices were connected to which ESP When they were connected/disconnected What was it used for Systems assessed Entities are required to document and implement a plan for how they will manage the use of Transient Cyber Assets and Removable Media

151 151 CIP R4 Best Practices Ensure transient devices do not have wireless or Bluetooth features enabled Transient Cyber Assets that may be used for assets in differing impact areas (i.e. high impact, medium impact, low impact) Consider the need to have separate Transient Cyber Assets for each impact level Use a combination of methods listed, not just the minimum

152 152 CIP R4 Best Practices Use the concept of system hardening for Transient devices helps minimize security vulnerabilities by removing all non-essential software programs and utilities and only installing the bare necessities Restrict or disable serial or network (including wireless) communications can be used to minimize the opportunity to introduce malicious code onto the Transient Cyber Asset

153 153 Additional Resources CIP NERC version 4 to version 5 mapping Glossary of Terms Used in NERC Reliability Standards NIST SP Security testing

154 154 Summary Know what is required for each BES cyber system(s) Create and maintain device baselines Active vs. paper assessment Track and manage deadlines Transient Devices and Removable Media

155 155 Speaker Contact Info Ben Christensen Senior Compliance Risk Analyst, Cyber Security