Eric Weston Compliance Auditor Cyber Security. John Graminski Compliance Auditor Cyber Security

Transcription

1 Eric Weston Compliance Auditor Cyber Security John Graminski Compliance Auditor Cyber Security CIP Advanced Workshop Agenda CIP September 9-10, 2015 Salt Lake City, UT

2 2 Agenda CIP Overview New/Redefined Terminology CIP Audit Approach Mock Audit Issues & Pitfalls Questions

3 3 Transition Guidance NERC. (2014 August 12). Cyber Security Reliability Standards CIP V5 Transition Guidance: ERO Compliance and Enforcement Activities during the Transition to the CIP Version 5 Reliability Standards. Retrieved from -V5%20Transition%20Guidance%20FINAL.pdf (NERC, 2014, CIP V5 Transition Guidance)

4 4 Mock Audit Approach Review of what is expected by the auditors for each CIP requirement Review of Billiam Evidence Sample Data Requests Sample Interview questions Discussion and interactive audit of requirements

5 5 EMS ESP [IP network] EMS Electronic Security Perimeter File Server Workstations Printer EMS WAN CorpNet CIP-005 EAP Firewall Access Control Server Router Switch CIP-007 BCA EAP Router Firewall CIP-005 Switch DMZ Printer Switch BCA BCA EACM Intermediate Server EACM Access Control Server BCA BCA BCA Workstations BCA BCA EMS Servers

6 6 EMS ESP/BCS [IP network] All PCA devices take on the impact level of the BCS CorpNet CIP-005 Firewall EAP EMS Electronic Security Perimeter File Server Non-BCS Workstations Printer PCA PCA PCA PCA PCA Switch BCA/PCA Router CIP-007 BCA EAP EMS WAN Router Firewall CIP-005 Switch DMZ Printer PCA CIP-002 Switch BCA/PCA BCA EACM Intermediate Server EACM Access Control Server BCA BCA Workstations BCA BCA BCA EMS Servers

7 7 Multi-BCS ESP EMS Electronic Security Perimeter BCS Server BCS Workstations BCA BCA Printer PCA EMS WAN CIP-005 BCA MEDIUM CIP-007 BCA Switch EAP Router Firewall CorpNet Firewall EAP BCA/PCA Router BCA CIP-005 Switch DMZ Printer PCA CIP-002 Switch BCA/PCA BCA EACM Intermediate Server EACM Access Control Server BCA BCA Workstations BCA BCA BCA EMS Servers HIGH

8 8 EMS ESP [High Water Mark] All PCA devices take on the impact level of the BCS CorpNet CIP-005 Firewall EAP EMS Electronic Security Perimeter BCS Server BCS Workstations Printer PCA PCA PCA PCA CIP-007 BCA/PCA Router PCA Switch HIGH BCA EAP EMS WAN Router Firewall CIP-005 Switch DMZ Printer PCA CIP-002 Switch BCA/PCA BCA EACM Intermediate Server EACM Access Control Server BCA BCA Workstations BCA BCA BCA EMS Servers

9 9 V5 Effective Dates Requirement/Part Implementation Dates Document CIP_V5_Implementation Plan Dates.pdf Implementation Plan Document CIP_Implementation_Plan_CLEAN_ pdf CIP-007 No specific date set in this document 4/1/2016 CIP-007 Part 1.2 No specific date set in this document 1/1/2017 For PCA's, Comm components CIP-007 Part 4.4 4/15/2016 No specific date set in this document

10 10 Requirement Count 7 Requirements (Version 3) 26 sub-requirements 5 Requirements (Version 5) 20 Parts

11 11 CIP Requirements CIP R1 Ports and Services R2 Security Patch Management R3 Malicious Code Prevention R4 Security Event Monitoring R5 System Access Control

12 12 CIP-007 V3 to V5 Summary C R1 CIP R1.4 & R1.5 C R2 CIP R1 CIP R1.2 NEW restrict physical ports CIP R3 CIP R2 CIP R2.1 NEW identify patch sources CIP R4 CIP R3 CIP R4.3 NEW Alerts CIP R5 CIP R5 CIP R5.1 CIP R4.1 CIP R5.1.1 CIP R5.2 CIP R5.1.2 CIP-007 R4.1 CIP R5.1.3 CIP R4.3 CIP R5.7 NEW unsuccessful login thresholds and alerts CIP R6 CIP R4 CIP R7 CIP R2 CIP R8 CIP R3 CIP R9 Deleted Project Cyber Security Order 706 DL_Mapping_Document_ pdf

13 13 Applicable Systems

14 14 CIP TFEs P1.1 TFE language but not required P4.3 Log retention P5.1 Authentication enforcement P5.6 Password change enforcement P5.7 Limit authentication attempts

15 15 Non-Routable BCS BES Cyber System and associated BES Cyber Assets are not dependent upon a routable protocol A BES Cyber System may include only serial devices with no routable devices at all End point devices (relays, meters, etc.) are to be included within the V5 requirements and may be BES Cyber Assets or even a BES Cyber System, even if no routable communications exist Therefore, there are V5 requirements to be addressed (i.e. CIP-007-6)

16 Requirements for BCS without External Routable Connectivity CIP Applicable Requirements: Part 1.2 Physical Ports R2 Patch Management - Firmware R3 AV & Malicious code prevention multiple controls Part 4.1, Part 4.3, Part 4.4 Logging Part 5.2 Default/Generic accounts Part 5.4 Change default passwords Part 5.5 Password complexity 16

17 17 CIP Asset Level Requirements Most of CIP-007 can NOT be performed at a system level, but at the Cyber Asset level for the following assets: BES Cyber Asset (BCA) EACM (EAP) PACS PCA BCA groupings and BES Cyber Systems are permitted where indicated

18 18 V5 Asset Level Requirements Ports and Services (CIP Part 1) Patch Management (CIP Part 2) Security Event Monitoring (CIP Part 4) BES Cyber System and/or Cyber Asset (if supported) System Access Control (CIP Part 5) local system accounts

19 19 CIP R1 R1. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of the applicable requirement parts in CIP Table R1 Ports and Services. [Violation Risk Factor: Medium] [Time Horizon: Same Day Operations.] M1. Evidence must include the documented processes that collectively include each of the applicable requirement parts in CIP Table R1 Ports and Services and additional evidence to demonstrate implementation as described in the Measures column of the table.

20 20 CIP Part 1.1

21 21 Ports and Services Control required to be on the device itself or may be positioned inline (cannot be bypassed) Host based firewalls, TCP_Wrappers or other means on the Cyber Asset to restrict access Dynamic ports Port ranges or services (tcp & udp) Blocking ports at the EAP does not substitute for the device level requirement Know what ports are opened and provide a business reason for enabling service Measures Listening ports (netstat -boan/-pault) Configuration files of host-based firewalls

22 22 Tools/commands Netstat: Netstat -b -o -a -n > netstat_boan.txt Netstat -p -a -u -l -t > netstat_pault.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 show running configurations (router or firewall)

23 23 What We Expect [Sample only] Device ID Device Name TCP Ports UDP Ports Service Justification

24 24 Question Is it required to capture not only the need for a port to be open, but also the authorization request for the port to be opened? CIP Part 1.1 NO "Develop a baseline configuration, individually or by group, which shall include the following items: Any logical network accessible ports; need for a port to be open and not an actual authorization request for the port to be opened.

25 25 Authorizations CIP Part 1.2 "Authorize and document changes that deviate from the existing baseline configuration. Measure: A change request record and associated electronic authorization (performed by the individual or group with the authority to authorize the change) in a change management system for each change; or"

26 26 CIP / CIP Relationship CIP baseline configuration requirements CIP Part Develop a baseline configuration of any logical network accessible ports Documented list of enabled ports CIP Part 1.1 is concerned only with the enabling of needed ports Performance (CIP-007-6) versus documentation (CIP )

27 27 Double Jeopardy? Failing to maintain the baseline configuration and failing to disable unnecessary ports are two different requirement violations CIP Part 1.1 refers to listings of ports as evidence, but that evidence could be the same evidence required for CIP Utilizing a single piece of evidence for proof of compliance with two different requirements is not double jeopardy.

28 28 Mock Audit of Billiam Audit Approach Bad Evidence Examples Typical Data Request Typical Interview Questions Good Evidence Examples

29 29 Part 1.1 Evidence Provide the following evidence: a. Identification of the enabled logical ports which are network accessible. Include, if applicable, documentation of the configuration of host firewalls or other methods of restricting network access to a listening port. For Electronic Access Points, this information is only required for the device s management ports. a. If dynamic ports are in use, provide the following: I. The name of each service that requires dynamic ports. II. The port range used by each service. III. The method used to associate service with the dynamic port (e.g., netstat, etc.) b. Documentation of the need (e.g., operational purpose) for all enabled logical network accessible ports. For Electronic Access Points, this information is only required for the device s management ports. a. The comparison of the list of ports actually network accessible to the list of ports needed

30 30 Part 1.1 Audit Steps Verify process(es) are documented. Verify the documentation includes the need for each enabled logical network accessible port on the device. Where a port range is required, verify the associated service is also identified. If a logical network accessible port is deemed needed by the inability to disable the port, verify the documentation of the inability to disable the port. Review the list of logical network accessible ports on the device. Review the comparison of the needed ports and services with the listening ports and services. Verify that this comparison is complete and correct.

31 [CIP Part 1.1] Audit Approach What are we looking for? Required ports defined documented Cyber Asset specific What service is running on what port Port ranges must include service Documentation of procedures to identify and manage required ports/services TCP and UDP ports listening/established state (disregard loopback addresses) Vendor documentation may assist in defining required ports and services and their operational purpose Documentation of ports and services used in normal or emergency operation Are high risk ports/services running? Operational requirement? 31

32 [CIP Part 1.1] Audit Approach What are we looking for? [continued] Procedures to ensure only required ports/services are enabled for new/changed devices (Part 1.1) What tests are performed to validate correct configurations who, when, how, tools (Part 1.1) If a device has no provision for disabling ports they are deemed needed, No TFEs (Part 1.1) 32

33 33 [CIP Part 1.1] Typical Data Requests For the following servers and workstations (Bes cyber assets) provide current netsat (netstat b o a -n / netstat p a -l) or port scan (TCP/UDP) results. [random sample list] For the following network devices, provide current configuration files (i.e., show run), ports and services running (scan results if exists) and evidence of any firmware/software updates since 10/1/2010, [random sample list]

34 [CIP Part 1.1] Typical Interview Questions 34 Describe the procedures used to identify the required ports/services Are vendors involved with the definition of required ports/services? Are there Cyber Assets, which ports and services cannot be disabled?

35 35 Part 1.1 Issues & Pitfalls Accurate enablement of required ports, services and port ranges Understanding critical data flows and communications within ESP and EAPs Logical ports include TCP & UDP ports Managing changes of logical ports VA, approved baselines, and implemented logical ports and services should always agree (CIP and CIP-007-6)

36 36 Part 1.1 Insufficient Evidence Why? 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

37 37 HMI-1 Baseline Evidence [netstat] 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]

38 38 HMI-1 Evidence [nmap tcp] 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

39 39 HMI-1 Evidence [nmap udp] 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

40 40 EMS1 Evidence [netstat tcp & udp]

41 41 Router Ports/Services

42 42 Manual Review of Configs

43 Part 1.1 Ports/Service Sufficient Evidence Why? McAfee Engine Service What is it? EngineServer service loads instances of the Engine and DATs to facilitate scanning for the features Scan, Script Scan, and the memory scan portion of On Demand Scan. Is it required? YES - For systems belonging to the CIP Domain IP Port numbers used: None ( Reference: 43 McAfee Framework Service What is it? The Framework Service controls the scheduled tasks and updating portion of the VirusScan Enterprise application. Is it required? YES - If disabled, the McAfee VirusScan agent will not function correctly. IP Port numbers used: Default Port Protocol Traffic direction 8081 TCP Inbound connection to the McAfee server TCP Inbound connection to the McAfee server. 80 TCP Outbound connection from the McAfee server. 443 UDP Outbound connection from the McAfee server.

44 44 CIP Part 1.2 Asset level requirement

45 45 CIP CIP Change CIP Logical Ports only CIP Includes Physical Ports (R1.2) and includes nonprogrammable communications equipment Guidance-- apply to only those nonprogrammable communication components that are inside both an ESP and a PSP in combination, not those components that are in only one perimeter.

46 46 Configuration Ports - capability Change Bios Upgrade Firmware Set Baseline Configuration Build-out devices that have components (like servers) Perform a variety of Administrative functions Perform emergency repair or failure recovery when no other port is accessible

47 47 Part 1.2 Physical Ports Physical I/O ports Network Serial USB ports external to the device casing

48 48 Part 1.2 Physical Ports All ports should be either secured or disabled Ports can be protected via a common method not required to be per port Protect against the use Requirement is not to be a 100% preventative control Last measure in a defense in depth layered control environment to make personnel think before attaching to a BES Cyber System in the highest risk areas

49 49 Guidelines Disabling all unneeded physical ports within the Cyber Asset s configuration Prominent signage, tamper tape, or other means of conveying that the ports should not be used without proper authorization Physical port obstruction through removable locks

50 50 Part 1.2 Physical Ports - Evidence Documented approach to ensure unused physical ports are controlled (identify controls in place) Controls in place for ensuring that attempts of physical port usage are identified Think before you plug anything into one of these systems Controls: 802.1x, physical plugs, port block, signage Physical port usage documentation know what is in use versus existing ports not required Site tours may be used to validate physical port documentation

51 51 Port Locks

52 52 Question Signage for physical port protection (CIP R1.2) is it acceptable to place signs at the PSP doors, rather than on each individual device port? NO, this is a device specific requirement. There must be clear notice regarding the use of physical ports or a physical/electronic method to ensure that ports are not inadvertently connected to a network/device. Policies also need to be in place to control the use of transient devices (USB stick, etc.) Would a Cyber Asset locked in a cage meet this requirement? No, the required control needs to be applied on the Cyber Asset level

53 53 Physical Ports and Applicable Systems A routable device with all of its physical network ports blocked which would have otherwise been identified as routable device, now cannot route. The ability to communicate outside of itself is not a determining factor as to whether a Cyber Asset is or is not a BES Cyber Asset or BES Cyber System The Cyber Asset s function as it pertains to BES reliability determines system identification

54 54 CIP Part 1.2 Is the use of tamper tape a compliant method to address this requirement? It depends upon the placement. The placement must be obvious to the asset

55 CIP V5 Questions with Draft Responses.pdf Part

56 56 Part 1.2 Audit Approach 1. Verify the entity has documented one or more processes which address this Part. 2. Verify the list of physical input/output ports is complete and correct. 3. Verify the list of physical input/output ports required for operations appears correct. 4. Verify that the unnecessary physical input/output ports are protected against use. Protections provided to unnecessary physical input/output ports may include, but are not limited to: a. Logically disabling b. Physically disabling c. Physical signage

57 57 Part 1.2 Evidence Sample of BES Cyber Systems: a. The list of all BES Cyber Assets and Cyber Assets which comprise the BES Cyber System. b. The list of all PCA associated with the BES Cyber System. c. The list of all nonprogrammable communication components associated with the BES Cyber System and located inside both a PSP and an ESP Provide the following evidence: a. List of all physical input/output ports (capable of network connectivity, console commands, or Removable Media) b. List of all physical input/output ports (capable of network connectivity, console commands, or Removable Media) that are required for operations, and the basis for that requirement c. Documentation of the protections provided to physical input/output ports (capable of network connectivity, console commands, or Removable Media) that are not required for operations

58 58 Part 1.2 Evidence

59 59 CIP Part 2.1

60 60 CIP CIP Change CIP No time frames to implement patches CIP Patch management required actions and timelines (R2)

61 61 Part 2.1 Patch Management Process Patch management documented process List of sources monitored for BES Cyber Systems and/or BES Cyber Assets List of Cyber Assets and software used for patch management Watching and being aware of vulnerabilities within BES Cyber Systems, whether they use routable communications or not, and mitigating those vulnerabilities Applicable to BES Cyber Systems that are accessible remotely as well as standalone systems

62 62 Part 2.1 Tracking Requirement allows entities to focus on a monthly batch cycle of patches rather than tracking timelines for every individual patch Tracking can be on a CIP monthly basis (35 days) for all patches released that month rather than on an individual patch basis Decision to install/upgrade security patch left to the Responsible Entity to make based on their specific circumstances

63 63 Tracking for Applicability Is applicability based on original source of patch (e.g. Microsoft) or the SCADA vendor? Some may consider it a best practice that vulnerabilities be mitigated in the shortest timeframe possible, even before the patch is certified by the SCADA vendor Appropriate source dependent upon the situation Patch source cannot be internal source

64 64 Vulnerability-Patch Sources Electricity Sector Information Sharing and Analysis Center (ES-ISAC) Common Vulnerabilities and Exposures BugTraq National Vulnerability Database ICS-CERT

65 65 Sources

66 66 Patch Update Issues Cyber Security focused Requirement does not cover patches that are purely functionality related, with no cyber security impact Cyber Asset Baseline documentation with patch tracking (CIP Part 1.1.5) Operating system/firmware, commercially available software or open-source application software, custom software

67 67 Cyber Security software patches ALERT Hardware vendors may provide security patches and security upgrades to mitigate/eliminate vulnerabilities identified in their drivers and firmware These need to be patched

68 68 Graphic Driver Patch

69 CIS CYBER SECURITY ADVISORY NUMBER: DATE(S) ISSUED: 07/02/2014 SUBJECT: Multiple Vulnerabilities in Apple Mac OS X Prior to

70 70 that are updateable [XP Support]

71 71 Windows XP (EOL ) April 2014 there are no more security patches forthcoming for XP No Software Updates from Windows Update No Security Updates No Security Hotfixes No Free Support Options No Online Technical Content Updates

72 72 End of Life Evidence Document vendor end dates Document BCS Assets affected Ensure latest applicable patch is implemented Deploy mitigation measures for vulnerabilities not able to patch Monitor US-CERT, and other vulnerability tracking sites to be aware of newly identified vulnerabilities that would affect your assets Where possible, implement mitigation measures for the newly identified vulnerability

73 73 Windows XP Embedded Cyber Assets running the Microsoft Windows XP Embedded SP3 operating system have until January 12, 2016, before support ends for that version of the operating system Support for systems built on the Windows Embedded Standard 2009 operating system ends on January 8, The Windows Embedded operating system normally runs on appliances

74 74 Part 2.1 Audit Approach 1. Verify the entity has documented one or more processes 2. Verify the documented process(es) include provisions for tracking, evaluating, and installing cyber security patches 3. Verify the tracking portion of the documented process(es) includes the identification of one or more sources for cyber security patches

75 75 Part 2.1 Data Request Provide identification of: a. The operating system; or firmware b. Identification of any commercially available software installed on the device c. Identification of any open-source application software installed on the device d. Identification of any custom software installed on the device Software identified: a. Name or other identification of the software installed b. Version, release number, and/or revision date of the software installed c. Identification of the source being tracked for cyber security patches, or documentation that no patch source exists

76 [CIP Part 2.1] Audit Approach what are we looking for? Documented procedures for the tracking, evaluating, testing and implementing of patches and updates Evidence of monitoring of all installed software and firmware Develop a list of all monitored applications/os/firmware Identify and document process and location for notifications of updates Look to vendors where possible Evidence of identification and evaluation of applicability within 35 days of availability Evidence of implementation of patches as defined in documented procedures, evidence of testing prior to release to production Evidence of the patch analysis and implementation of compensating measures if applicable patch/updates will not be implemented within 30 days Risk of NOT implementing patches/updates expectation of implementation 76

77 77 [CIP Part 2.1] Typical Data Requests Provide evidence of Cyber Security patch management tracking for the audit period for the following devices Provide list of all software (OS, firmware, applications) being monitored for security updates/patches and method used for monitoring Provide evidence of security patch assessment of applicable systems within 35 days

78 [CIP Part 2.1] Typical Interview Questions Describe your patch management process What technical and procedural controls are in place? Describe the process to determine if a security patch/update is applicable Are vendors involved with the determination? Describe the decision process to decide if an update/patch will be installed What is the process if an applicable patch will not be installed? 78

79 79 Insufficient Evidence Why?

80 80 Sufficient Evidence Why? Software listings Patch sources Assessment procedure who, what, when, how, --timing, criteria Assessment results and rationale

81 81 Part 2.2 Patch Evaluation At least every CIP Month (35 days) evidence of patch release monitoring and evaluation of patches for applicability Evaluation Assessment Determination of Risk Remediation of vulnerability Urgency and timeframe of remediation Next steps Entity makes final determination for their environment if it is more of a reliability risk to patch a running system than the vulnerability presents Listing of all applicable security patches Date of patch release, source, evaluation performed, date of performance and results

82 82 Guidelines DHS Quarterly Report on Cyber Vulnerabilities of Potential Risk to Control Systems Recommended Practice for Patch Management of Control Systems ManagementRecommendedPractice_Final.pdf

83 83 Vulnerability Footprint

84 84 Audit Approach Verify that security patches from the patch source have been evaluated for applicability at least once every 35 calendar days during the audit period Verify the results of the evaluations documented results

85 85 Part 2.2 Data Request For each patch source identified, provide the following: a. Identification of each security patch released by each patch source during the audit period, including the date of release; b. Evidence of the evaluation of each security patch for applicability, including: i. Date of evaluation ii. Results of the evaluation (i.e., applicable or not applicable) iii. If not applicable, the reason the patch is not applicable

86 86 Sample Interview Questions Describe the patch management process Describe the evaluation criteria Describe patch source identification process Describe the patch identification process for asset types: BCA EACM PACS PAs

87 87 Part 2.2 Patch Evaluation

88 88 Evidence Sample spreadsheet

89 89 CIP Part 2.3 Asset level requirement

90 90 Part 2.3 Actions Evidence of performance of: Installation of patches Not an install every security patch requirement Mitigation plan created includes specific mitigation/mediation of identified security vulnerability, date of planned implementation and rational for delay Mitigation plan update evidence Evidence of Mitigation plan completion with dates Note: referenced mitigation plan is a entity plan and not associated at all with the Enforcement Mitigation plans.

91 91 Part 2.3 Mitigation Some patches may address vulnerabilities that an entity has already mitigated through existing means and require no action Lack of external routable connectivity may be used as a major factor in many applicability decisions and/or mitigation plans where that is the case

92 92 Part 2.3 Mitigation Guidelines When documenting the remediation plan measures it may not be necessary to document them on a one to one basis The remediation plan measures may be cumulative

93 Demonstrating implementation of Mitigation Plan 93 Measures Records of the implementation of the plan Installing the patch/record of the installation Disabling of any affected service Adding of a signature to an IDS Change to a host based firewall Record of the completion of these changes

94 94 Timeframe Timeframe is 70 days total 35 days for tracking and determining applicability 35 days for either installing or determining the mitigation plan

95 95 Maximum Timeframes It is compliant with the requirement to state a timeframe of the phrase End of Life Upgrade Mitigation timeframe is left up to the entity Requirement is to have a plan Date of the plan in requirement part 2.3 is what part 2.4 depends upon Must work towards that plan

96 96 Timeframes Guidelines Timeframes do not have to be designated as a particular calendar day but can have event designations such as at next scheduled outage of at least two days duration

97 97 Part 2.3 Audit Approach 1. For each applicable security patch, verify that one of the following actions was taken within 35 calendar days of the completion of the evaluation for applicability: a. The patch was applied to all devices for which it is applicable; or b. A mitigation plan was created; or c. A mitigation plan was revised. 2. In the case where a mitigation plan was created or revised: a. Verify the mitigation plan addresses each vulnerability addressed by the security patch; b. Verify the mitigation plan is sufficient to mitigate each vulnerability addressed by the security patch; c. Verify the mitigation plan includes a timeframe for completion; d. Review the timeframe specified by the mitigation plan to determine if it results in mitigation of each vulnerability within a reasonable period; and e. If the mitigation plan is complete, verify the mitigation plan was completed within the timeframe specified by the mitigation plan, or within the approved extension period per Part 2.4.

98 98 Part 2.3 Data Request 1. Provide the following: a. Identification of each security patch released by each patch source during the audit period b. The date of completion of the evaluation of each applicable patch; and c. A list of the devices comprising or associated with the BES Cyber System for which each patch is applicable 2. Provide evidence of the action taken regarding the patch: a. For each device to which the patch was applied provide: i. Evidence of the application of the patch ii. Evidence of the date the patch was applied b. If the patch was not applied to all devices comprising or associated with the BES Cyber System for which the patch is applicable, provide: I. The associated mitigation plan II. The implementation status of the mitigation plan

99 99 Sample Interview Questions Describe the patch assessment process Describe the patch implementation process Describe the Mitigation Plan documentation process why, what, who, when

100 100 Performance Notes Results-based Requirement: The end result of this Requirement must be the mitigation of vulnerabilities addressed by applicable security patches. The entity has been granted wide latitude by the language of the Requirement regarding how this result is accomplished. It is the function of the auditor to verify that the end result is sufficient to protect the BES. Implementation Timelines: Due to the large variety of circumstances to which this Requirement may apply, there is no specific requirement regarding the time to implement a mitigation plan. The auditor must use professional judgment to accept or express concern over the time frame to implement mitigation plans. While a finding of Possible Violation for an excessively lengthy mitigation timeline is not supported by the language of the Requirement, a documented Area of Concern or Recommendation will ensure that the matter is addressed during risk assessment.

101 101 Part 2.3 Audit Evidence Examples

102 102 Part 2.3 Audit Evidence Examples

103 103 CIP Part 2.4 Asset level requirement

104 104 Part 2.4 Mitigation Plan Evidence of CIP Senior Manager s approval for updates to mitigation plans or extension requests Per Mitigation plan Revising the plan, if done through an approved process such that the revision or extension, must be approved by the CIP Senior Manager or delegate

105 105 Part 2.4 Implement The implement in the overall requirement is for the patch management process Implement in Part 2.4 (Mitigation Plan) is for the individual patch If Part 2.4 does not have an implement requirement at the patch level, then the implement in the overall requirement only applies to drafting a plan

106 106 Part 2.4 Audit Steps For each completed mitigation plan: 1. Verify the mitigation plan was completed by implementing all provisions of the mitigation plan; 2. Verify the mitigation plan was completed within the specified timeframe. 3. If a revision or an extension was made to a mitigation plan, verify the revision or extension was approved by the CIP Senior manager or delegate. 4. For each active mitigation plan: a. Verify the mitigation plan has not exceeded its implementation timeframe, or its approved extension, if any. b. If a revision or an extension was made to a mitigation plan, verify the revision or extension was approved by the CIP Senior manager or delegate. c. If one or more of the verify steps above fails, a finding of Possible Violation should be returned.

107 107 Part 2.4 Data Request For each mitigation plan identified, provide the following: a. The mitigation plan; b. The status of the mitigation plan (i.e., completed or active); a) For completed mitigation plans: i. Evidence of the work performed to complete the mitigation plan; ii. Evidence of the completion date of the mitigation plan. b) For active mitigation plans: i. Evidence of the status of the mitigation plan; ii. The expected completion date of the mitigation plan.

108 108 R2 Issues & Pitfalls Asset level requirements Know, track, and mitigate the known software vulnerabilities associated with BES Cyber Assets, Pas, EACMS and PACS Including a complete listing of BES Cyber Systems and assets that are applicable Firmware devices (relays, appliances, etc.) Infrastructure devices within ESP OS based systems Cyber Asset applications (tools, EMS, support applications, productivity applications, etc.) If something is connected to or running on the BES Cyber Assets that releases security patches required to be included in the monitoring for patches

109 109 CIP Part 3.1

110 110 CIP CIP Change CIP CIP AV on ALL cyber assets or TFE Malicious code controls can be at cyber system level, rather than per asset (R3)

111 111 Part 3.1 Malicious Code Deter OR detect OR prevent - any one or combination will meet the wording of the requirement Avoids zero-defect language Part 3.2 requires ability to detect malicious code (also Part requires detection) Methods = processes, procedures, controls Applicability is at the system level Methods do not have to be used on every single Cyber Asset Allows entities to adapt as the threat changes while also reducing the need for TFEs

112 112 Part 3.1 Guidance the Responsible Entity determines on a BES Cyber System basis which Cyber Assets have susceptibility to malware intrusions and documents their plans and processes for addressing those risks and provides evidence that they follow those plans and processes. There are numerous options available including traditional antivirus solutions for common operating systems, white-listing solutions, network isolation techniques, Intrusion Detection/Prevention (IDS/IPS) solutions, etc.

113 FAQ - CIP R3 What constitutes malicious code detection for relays which are not computers and do not have an operating system where traditional antivirus software can be applied? To demonstrate compliance a Registered Entity should track its firmware versions and keep firmware versions current from the vendor, particularly any upgrades having to do with security enhancements. This combined with a demonstrated security model for securing both physical and logical access to these Cyber Assets, including logging, is a sufficient deterrence program aimed at preventing malware introduction or firmware code injection. Contact with the vendor and knowledge of evolving product lines with more security options should also be considered and documented.

114 114 CIP R3 For the implementation of malicious code prevention, should entities choose to deter, detect, or prevent malicious code? If an entity chooses to deter, how should they plan on complying with 3.2 since there would be no mechanism to detect? The intent is to perform all three, however the requirement allows for choosing which technology will be implemented. However, Part 3.2 requires detection capabilities, if deter is the choice as above, there must be additional capabilities to detect as well, to meet requirement 3.2. Therefore, the minimum must include detection capabilities.

115 115 Defense-N-Depth W E S T 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

116 116 Application Whitelisting Identifying specific executable and software libraries which should be permitted to execute on a given system Preventing any other executable and software libraries from functioning on that system Preventing users from being able to change which files can be executed W E S T 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

117 117 Application Whitelisting Application File Attributes Digital Certificates File Hash File Ownership Location Reference Systems Signed Security Catalogs Software Packages

118 118 Guidelines Network isolation techniques Portable storage media policies Intrusion Detection/Prevention (IDS/IPS) solutions

119 119 Part 3.1 Malicious Code Is an awareness campaign to deter ok? or and deter to avoid zero-defect language Requirement is not to detect or prevent all malicious code Approach is not to require perfection in an imperfect environment with imperfect tools

120 120 Associated PCAs Associated PCAs are included at a Cyber Asset (device) level, not system level How will the system concept apply? Malware prevention is at a BCS level The associated PCA s could be included by reference in the documentation an entity supplies for Requirement Part 3.1

121 121 CIP-007 FAQ Question: What is malware? Answer: Malware generally means malicious software such as viruses, worms, timebombs, and Trojan horses. This software may be distributed through attachments, unsecured remote procedure calls, Internet downloads, and opening infected files. Malware may delete or modify files, attempt to crack passwords, capture keystrokes, present unwanted pop-ups on screen, fill-up disc space, or other malicious and destructive activity, without the authorization or knowledge of the person using the infected computer.

122 122 Part 3.1 Audit Approach 1. Verify the entity has documented one or more processes which address this Part 2. Verify that each device comprising the BES Cyber System has one or more methods documented and deployed to deter, detect, or prevent malicious code 3. Verify that each EACMS, PACS, and PCA associated with the BES Cyber System has one or more methods documented and deployed to deter, detect, or prevent malicious code Note: System Approach: The intent of the requirement is that the BES Cyber System as a whole has malware prevention deployed Each individual component is not required to have the same protection Not all components will be vulnerable to malware. Of those that are, differing protections may be appropriate for each type of device. For example, a firmware-based device may not be vulnerable to malware if its USB port is protected, such that only authorized personnel may update the firmware. This protection could be considered sufficient to deter the introduction of malicious code.

123 [CIP Part 3.1] Audit Approach what are we looking for? Documentation of the AV/anti-malware technical and procedural controls in place Evidence that each device comprising the BES Cyber System, EACMS, PACS and PAS has one or more methods documented and deployed to deter, detect, or prevent malicious code Identification of all Cyber Assets that are unable to run AV/anti-malware What appropriate compensating controls are in place Validate real-time scanning is active or performed on an appropriate cycle where applicable Validate that users cannot disable the AV or anti-malware or have alert mechanism to monitor Validate that signature updates are being performed on a regular basis after defined testing is performed Evidence that AV alerts are generated and notification is performed Evidence of defined procedures to respond to virus or malware alerts 123

124 124 [CIP Part 3.1] Interview Topics Describe your AV/anti-malware technical and procedural controls for all BCS assets and associated Pas, EACMs and PACS Is the AV/anti-malware application at the current release version What is the testing and approval process for AV signature updates? How current are the signature files? How long of delay between release and implementation? How often is the application updated? Are Application Whitelist techniques used?

125 125 CIP Part 3.2

126 126 Part 3.2 Detected Malicious Code Requires processes No maximum timeframe or method prescribed for the removal of the malicious code Mitigation for the Associated Protected Assets may be accomplished through other applicable systems Entity can state how the mitigation covers the associated PCA s

127 127 CIP R3 Entities are required to mitigate the threat of detected malicious code regardless of the methods they choose to deter, detect, or prevent malicious code (Part 3.1)

128 128 Part 3.2 Audit Approach 1. Verify the entity has documented one or more processes which address this Part 2. Verify the entity uses one or more methods to detect malicious code 3. For each instance of detected malicious code reviewed, verify the mitigating steps taken are consistent with the process and mitigate the threat of the malicious code Results-based Requirement: The Requirement assumes malicious code will be detected the entity is therefore required to do so, but the approaches used to perform this detection are not specified.

129 129 Part 3.2 Data Request List of all instances of detected malicious code, including: 1. Type of malicious code detected 2. Date the malicious code was detected 3. Devices affected by the malicious code, if any 4. Method of detection 5. Mitigation actions taken 6. Date the mitigation actions were taken 7. If the threat of the detected malicious code has not been fully mitigated, the action plan, including timetable, to complete the mitigation

130 130 Part 3.2 Sample Interview Questions Describe the malicious code identification and mitigation processes Have there been malicious code events identified? Have there been malicious code events that have not been mitigated? Have mitigation activities been performed? Please describe these efforts.

131 131 Part 3.2 Evidence Documentation of events Mitigation processes completed How does the mitigation efforts specifically address the malicious code

132 132 CIP Part 3.3

133 133 Requires process for updates Requires processes that address: Testing Does not imply that the entity is testing to ensure that malware is indeed detected by introducing malware into the environment Ensuring that the update does not negatively impact the BES Cyber System before those updates are placed into production Installation No timeframe specified Requirement Part 3.1 allows for any method to be used and does not preclude the use of any technology or tool

134 134 Part 3.3 Signatures Specific sub requirement is conditional and only applies to for those methods identified in requirement part 3.1 that use signatures or patterns If an entity has no such methods, the requirement does not apply. Requirement does not require signature use Can an entity rely on AV vendor testing?

135 135 Audit Approach Verify the entity has documented one or more processes to address this Part Verify the processes address testing and installing updates to signatures or patterns Verify the processes are implemented

136 136 Data Request All applicable documented processes for implementation List of all methods used to deter, detect, or prevent malicious code which use signatures or patterns For each method used to deter, detect, or prevent malicious code which uses signatures or patterns, provide the process used to update the signatures or patterns For each method used to deter, detect, or prevent malicious code which uses signatures or patterns, provide evidence of the implementation of each process.

137 137 Sample Interview Questions Describe the procedures for testing of signatures prior to implementation How often are the signatures updated?

138 138 Part 3.3 Evidence Documented signature testing and updating procedures Evidence of performance of the signature testing

139 139 R3 Issues & Pitfalls Technical selection and implementation Coverage for all cyber assets Combination of solutions BCS and ESP coverage Clear documentation demonstrating coverage Identification, alerts and response procedures

140 140 CIP Part 4.1

141 141 CIP CIP Change CIP CIP Security logs Identification of specific log collection events (P4.1) Sampling and or summarization not mentioned Log reviews for High impact Cyber Systems can be summarization or sampling (P4.4) CIP Log reviews every 90 days when applicable CIP Log reviews for High Impact Cyber Systems must be reviewed every 15 days (P4.4)

142 142 Part 4.1 Log Events Entity determines which computer generated events are necessary to log (beyond minimum required), provide alerts and monitor for their particular BES Cyber System environment Logging is required for both local access at the BES Cyber Systems themselves, and remote access through the EAP Evidence of required logs ( ) Successful and failed logins Failed ACCESS attempts blocked network access attempts successful and unsuccessful remote user access attempts blocked network access attempts from a remote VPN successful network access attempts or network flow information Detection of malicious code

143 143 Part 4.1 Log Events Types of events Requirement does not apply if the device does not log the events Devices that cannot log do not require a TFE logging should be enabled wherever it is available 100% availability is not required Entity must have processes in place to respond to logging outages in a timely manner

144 144 Part 4.1 Log Events For system event monitoring, per 4.1, should entities log at a system level? If so, how is it recommended that they monitor at that level? The requirement does not explicitly define which one to use; system level or asset level logging. The entity has the option to do one or the other or both, based upon asset capabilities. Typically, these logs are sent to a syslog or SIEM device for log aggregation and analysis How should entities provide capability proof for 4.1? this is usually provided via log aggregation systems (syslog, SIEM). Configuration files and manual log reviews may also help to provide proof of performance.

145 145 Part 4.1 Audit Approach System Level If logging is performed at the BES Cyber System level, for each sampled BES Cyber System and associated EACMS, PACS and PCA: 1. For each of the following event types: successful login attempts, failed access attempts, failed login attempts, and detected malicious code, verify: a. The BES Cyber System or associated device is capable of, and configured for, logging the event type; or b. The BES Cyber System or associated device is not capable of logging the event type. 2. Verify logs are being generated by the BES Cyber System and associated device(s).

146 146 Part 4.1 Audit Approach Asset level If logging is performed at the Cyber Asset level, for each Cyber Asset comprising the sampled BES Cyber System and associated EACMS, PACS and PCA: 1. For each of the following event types: successful login attempts, failed access attempts, failed login attempts, and detected malicious code, verify: a. The Cyber Asset or associated device is capable of, and configured for, logging the event type; or b. The Cyber Asset or associated device is not capable of logging the event type. 2. Verify logs are being generated by the Cyber Asset and associated devices.

147 147 Part 4.1 Data Request Indication of whether logging is performed at the BES Cyber System level or the Cyber Asset level. 1. If logging is performed at the BES Cyber System level: a. Provide evidence of the types of logging events enabled for the BES Cyber Systems, EACMS, PACS and associated PCAs b. If any component of the BES Cyber System or any associated device is not capable of logging at least the required event types, provide evidence of the lack of capability. c. Provide evidence that logs for the BES Cyber System, EACMS, PACS and associated PCAs are being generated. 2. If logging is performed at the Cyber Asset level: a. Provide evidence of the types of logging events enabled for each Cyber Asset comprising the BES Cyber System, EACMS, PACS and associated PCAs b. If any component of the BES Cyber System or any associated device is not capable of logging at least the required event types, provide evidence of the lack of capability. c. Provide evidence that logs for the BES Cyber Asset, EACMS, PACS and associated PCAs are being generated.

148 148 [CIP Part 4.1] Typical Data Requests Provide evidence that all cyber assets security monitoring logs are enabled. [sample list] Provide evidence of security event logging for [period of time] failed logins, etc. Provide security alerts and alert contact list for [period of time]

149 [CIP Part 4.1] Audit Approach what are we looking for? Evidence that all cyber assets (BCA, EACMS, PACS, PAS) are enabled for logging (if feasible) for required security events Consider using a central Syslog server when possible aggregation of devices logs easier to review Consider implementing a Security Information and Event Management (SIEM) tool (provides logging, monitoring and alerts) Ensure OS and critical application logs are included in logging 149

150 [CIP Part 4.1] Typical Interview Questions Describe the logging and monitoring tools and procedures Describe the log monitoring for required events Describe the Alerting tools and response procedures triggers, who receives, what response required, escalation 150

151 151 Part 4.1 Evidence Device configurations for logging of required events Examples of required events being identified

152 152 Manual Review of Configs [logging] #show run no logging ip http server! access-list 23 permit access-list 23 permit ! line vty 5 15 transport input ssh! access-class 23 in! no logging console debug condition interface no snmp-server ntp-server

153 153 CIP Part 4.2

154 154 Part 4.2 Alerting Detected known or potential malware or malicious activity (Part 4.2.1) Failure of security event logging mechanisms (Part 4.2.2) Alert Forms , text, system display and alarming Alerting Examples Failed login attempt Virus or malware alerts Failure of logging

155 155 Part 4.2 Alerting Guidelines and Technical Basis Consideration in configuring real-time alerts: Login failures for critical accounts Interactive login of system accounts Enabling of accounts Newly provisioned accounts System administration or change tasks by an unauthorized user Authentication attempts on certain accounts during non-business hours Unauthorized configuration changes Insertion of removable media in violation of a policy

156 156 Question Is an alert required for malicious activity if it is automatically quarantined? Alerts are required for detection of malicious code regardless of any subsequent mitigation actions taken

157 157 Guidance Guidance implies that only technical means are allowed for alerting on a detected cyber security event Requirement language is the ruling language and guidance is not auditable and is provided to provide further context, examples or assistance in how entities may want to approach meeting the requirement Requirement does not preclude procedural controls

158 158 Audit Approach Verify the entity has documented one or more processes which address this Part. Verify the list of security events determined to necessitate an alert includes: 1. Detected malicious code; 2. Detected failure of logging. Verify the security events determined to necessitate an alert are configured to generate an alert Verify alerts are being generated for applicable security events

159 159 Part 4.2 Data Request Provide the following evidence: 1. The list of security events determined to necessitate an alert and at a minimum includes: a. Detected malicious code b. Detected failure of logging 2. Evidence that such detected security events are configured to generate an alert 3. Evidence that such detected security events generate an alert

160 160 Part 4.2 Sample Interview Questions Describe the alert processes Describe the alert configurations for required asset types Describe the alert types and required responses

161 161 Part 4.2 Evidence Procedures for alert configuration setup that meet the minimum requirements Configuration settings and alert thresholds Evidence of alerts being generated Documented responses to alerts

162 162 CIP Part 4.3

163 163 Part 4.3 Retain Applicable Event Logs Timeframe: Response timeframe begins with the alert of the failure After something or someone has detected the failure and has generated an alert as in Part 4.2 For the compliance period, the applicable cyber systems maintain 90 days of logs. (All High BCS as well as Medium BCS at Control Center) Retention methods are left to Responsible Entity On or before April 15, 2016

164 Part 4.3 Retention of Event Logs Section C. of CIP Compliance Enforcement Authority: As defined in the NERC Rules of Procedure, Compliance Enforcement Authority (CEA) means NERC or the Regional Entity in their respective roles of monitoring and enforcing compliance with the NERC Reliability Standards Evidence Retention: The following evidence retention periods identify the period of time an entity is required to retain specific evidence to demonstrate compliance. For instances where the evidence retention period specified below is shorter than the time since the last audit, the CEA may ask an entity to provide other evidence to show that it was compliant for the full time period since the last audit. The Responsible Entity shall keep data or evidence to show compliance as identified below unless directed by its CEA to retain specific evidence for a longer period of time as part of an investigation: Each Responsible Entity shall retain evidence of each requirement in this standard for three calendar years.

165 165 Part 4.3 Retain Applicable Event Logs Is the audit approach to ask for any single day s logs in past three years? Compliance evidence requirement is that the entity be able to show that for the historical compliance period, the applicable cyber systems maintained 90 days of logs

166 166 Audit Approach Documented procedures to meet the required Parts For each BES Cyber System and its associated EACMS, PACS, and PCA, verify logs are retained for at least 90 calendar days unless: An approved TFE covers one or more of the devices. If this applies, verify the TFE s compensating measures are in place, and review the log retention for the devices not covered by the TFE A documented CIP Exceptional Circumstance exists. If this applies, review the log retention for devices and timeframes not covered by the CIP Exceptional Circumstance.

167 167 Part 4.3 Data Request Provide documented procedures to ensure 90 days of logs are maintained as required Provide evidence that logs pertaining to the BES Cyber System and its associated EACMS (including EAP), PACS, and PCA are retained for at least 90 calendar days for all High impact systems and Medium Control Center devices Provide evidence that the 90 day log requirement has been maintained for the audit period

168 168 Part 4.3 Sample Interview Questions Describe the log retention procedures for required assets for 90 days Describe the log management processes for logs greater than 90 days to show compliance for the audit period

169 169 Part 4.3 Evidence Log retention procedures SEIM Configurations Reports showing log management Evidence of audit period compliance log file procedures for greater than 90 days

170 170 CIP Part 4.4

171 171 Part 4.4 Review Logs Guidelines High Impact BCS/BCA, associated EACMS and PAs Summarization or sampling of logged events log analysis can be performed top-down starting with a review of trends from summary reports Determined by the Responsible Entity Electronic Access Points to ESP s are EACMs, this is one of the primary logs that should be reviewed

172 172 Part 4.4 Review Logs Purpose is to identify undetected security incidents Paragraph 525 of Order 706 Even if automated systems are used, the manual review is still required Manually review logs ensure automated tools are tuned and alerting on real incidents What if an entity identifies events in Part 4.4 that should have been caught in Part 4.1 is this a violation? NO, modify event setting to include newly identified event

173 173 Part 4.4 Issues & Pitfalls Ensure all EACMs are identified Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Systems. NERC glossary Documentation of log collection architecture Log collection data flows Aggregation points Analysis processes and/or technologies Validation of the required logs and alert configurations 15 day review documentation

174 174 Part 4.4 Audit Steps 1. Verify the entity has documented one or more processes 2. Verify the entity reviews a summary or sampling of logged events 3. Verify the entity reviews logged events at least every 15 calendar days

175 175 Part 4.4 Data Request For each BES Cyber System, provide: 1.The process or method used to review logged events. 2.For each calendar month selected, provide evidence of the review of logged events at least every 15 calendar days

176 176 Part 4.4 Sample Interview Questions Describe the procedures for reviewing logs as required Describe the log selection procedures for review of logs How is the 15 day review ensured? Describe the review process and evidence documentation Have there been findings of events that were previously unidentified?

177 177 Part 4.4 Evidence Log selection evidence Evidence of log review performance Evidence of issues identified For identified issues what are the mitigation plans to ensure the events are identified prior to the log reviews

178 178 Part 4.4 Evidence Procedures Evidence of reviews validating the 15 day maximum review timeframes A checkbox on a list is not sufficient evidence

179 Part 4.4 Good Evidence 179

180 180 CIP Part 5.1

181 181 CIP CIP Highlights CIP TFE required for devices that cannot meet password requirements CIP Password requirement may be limited to device capabilities as opposed to filing TFE (P5.5) Not specified in V3 Failed access threshold and alerts (P5.7)

182 182 Part 5.1 Enforce Authentication Ensure the BES Cyber System or Cyber Asset authenticates individuals with interactive access Interactive user access Doesn t include read-only (Rationale for Requirement R5) front panel displays web-based reports

183 183 Audit Approach Verify the entity has documented one or more processes which address this Part. Verify the entity has documented one or more methods to enforce authentication of interactive user access. Verify either: The entity has implemented the method(s) to enforce authentication of interactive user access, or An approved TFE is in place. If a TFE is in place, verify the compensating measures have been implemented

184 184 Part 5.1 Data Request For each BES Cyber and the associated EACMS (including EAP), PACS, and PCA, provide the following: 1. Evidence of the method(s) used to enforce authentication of interactive access. 2. Evidence of the implementation of the method(s) used to enforce authentication of interactive access.

185 185 Part 5.1 Sample Interview Questions Describe the process to ensure authenticated interactive access to required cyber assets is enforced Identify the controls to enforce authentication for all interactive access

186 186 Part 5.1 Evidence Procedures for implementation of authenticated interactive access Evidence of controls in affect

187 187 CIP Part 5.2

188 188 Part 5.2 Identify Accounts Identifying the use of account types Default and other generic accounts remaining enabled must be documented Deleted or disabled accounts do not need to be inventoried Not inclusive of System Accounts For common configurations, documentation can be performed at a BES Cyber System or more granular level Devices that only authenticate with a password should be included in the inventory, an account name of null is acceptable

189 189 CIP-007 Part 5.2 Question How should entities approach inventorying all known enabled default or generic account types? There are a number or ways to identify default and/or generic accounts. Typically the vendors will provide listing of the required accounts on a system. Also, there are tools that can be run to identify user accounts created on a local system. The AD also, will have listing of accounts with access to systems. It is not uncommon for EMS operators to use shared accounts. Talking with the operators will identify these shared accounts. Another method is to review the device/application web sites or support to identify if there are default accounts Are password safe s recommended? Although WECC does not give specific recommendations of vendor tools, we have seen successful utilization of this technology during our audits.

190 190 Audit Approach Verify the entity has documented one or more processes which address this Part Verify the entity has identified and inventoried all known or enabled generic accounts.

191 191 Part 5.2 Data Request For each BES Cyber System and associated EACMS (including EAP), PACS, and PCA, provide the following evidence: 1. The inventory of all known default or generic account types 2. Are inventories of accounts done individually or by system type

192 192 Part 5.2 Sample Interview Questions Describe the account management procedures to include default accounts Procedure to ensure identification of default accounts

193 193 Evidence Procedures documentation Listing of default accounts Password management of default accounts

194 194 CIP Part 5.3

195 195 Part 5.3 Identify Individuals Auditors would expect to see a list of shared accounts and each individual user who has authorized access to the accounts Authorized users can be documented individually or in combined list(s) Accounts configured on devices that only use a password to authenticate should be labeled as a generic account type No requirement in version 5 to maintain audit trail

196 196 Part 5.3 Data Request For each BES Cyber System and the associated EACMS (including EAP), PACS, and PCA, provide the following evidence: 1. The list of individuals with authorized access to shared accounts.

197 197 Part 5.3 Sample Interview Questions Describe the procedures to assign and track all users with access to shared accounts

198 198 Part 5.3 Evidence Procedures documentation Listing of shared accounts Identification of all users with access to the default and shared accounts

199 199 CIP Part 5.4

200 200 Part 5.4 Known Cases where the entity was not aware of an undocumented default password by the vendor would not be a possible violation Once entity is made known of this default password may require action per CIP R2

201 201 Part 5.4 Timeframe When is a default password required to be changed? No timeframe specified in requirement As with all requirements of CIP-007-6, this requirement must be met when a device becomes one of the applicable systems or assets

202 202 Audit Approach Verify the entity has documented one or more processes which address this Part. For devices with the ability to change default passwords, verify the entity has changed the default passwords For Cyber Assets that do not have the ability to change default passwords, verify the inability to do so

203 203 Part 5.4 Data Request For each BES Cyber System and the associated EACMS (including EAP), PACS, and PCA, provide: 1. Evidence of change of the known default password(s) for each device 2. For Cyber Assets that do not have the ability to change one or more default passwords, provide evidence of the inability to change the passwords

204 204 Part 5.4 Sample Interview Questions Describe the password management procedures for default accounts Are there any default accounts that do not allow for password changes? How are the above assets managed?

205 205 R5.4 Evidence Password management procedures for generic accounts Evidence of generic account default password management Logs Change Control Reports Tool output last password change date

206 206 CIP Part 5.5

207 207 Part 5.5 Passwords Eight characters or max supported Three or more different types of characters or maximum supported Per device capability (no TFE s)

208 208 Part 5.5 Passwords Password Group Policy Object (GPO) evidence Password configuration for all applicable devices Where device cannot support the requirement, document why (evidence) and the allowed configurations, and the configuration that is enabled

209 209 Part 5.5 Audit Steps This Part does not apply to multi-factor authentication. This part does not apply to read-only access to a Cyber Asset, in which the configuration of the Cyber Asset cannot be changed and there is no way for the Cyber Asset to affect the BES. If a device has the technical capability to enforce password length and/or complexity, then that method should normally be used. If the entity chooses a procedural method of enforcement when a technical method is available, the circumstances regarding this choice should be reviewed

210 210 Part 5.5 Data Request For each BES Cyber System and the associated EACMS (including EAP), PACS, and PCA, provide: The method used to enforce the password length requirement (i.e., technical or procedural) for password-only authentication for interactive user access If password length is enforced by a technical method, provide evidence of configuration to enforce this requirement If password length is enforced by a procedural method: Provide the procedure used to enforce this requirement Provide evidence (e.g., training content, notification, etc.) that this procedure is enforced The method used to enforce the password complexity requirement (i.e., technical or procedural) for password-only authentication for interactive user access If password complexity is enforced by a technical method, provide evidence of configuration to enforce this requirement If password complexity is enforced by a procedural method: Provide the procedure used to enforce this requirement Provide evidence (e.g., training content, notification, etc.) that this procedure is enforced

211 211 Part 5.5 Sample Interview Questions Describe the password management procedures for meeting the password length and complexity requirements Are there devices which do not support the required length and password requirements? How are these devices identified and managed?

212 212 Part 5.5 Evidence Password configuration settings Vendor documentation that identifies device password capabilities for those devices that cannot support the defined requirements

213 213 Part 5.5 Good Evidence Part Part 5.5.2

214 214 Part 5.5 Good Evidence 180 Part Part 5.5.2

215 215 CIP Part 5.6

216 216 Part 5.6 Password Changes Password change procedures Evidence of password changes at least every CIP Year (15 months) Disabled Accounts Password change is not required because these do not qualify as providing interactive user authentication Technical or procedural processes should be able to accommodate all device types (TFE s unlikely)

217 217 Audit Approach Verify the entity has documented one or more processes which address this Part For password-only authentication for interactive user access, verify password length is enforced by either technical or procedural methods For password-only authentication for interactive user access, verify password complexity is enforced by either technical or procedural methods

218 218 Audit Approach [continued] 1. Does not apply to multi-factor authentication 2. Does not apply to read-only access to a Cyber Asset, in which the configuration of the Cyber Asset cannot be changed and there is no way for the Cyber Asset to affect the BES. 3. If a device has the technical capability to enforce password length and/or complexity, then that method should normally be used. If the entity chooses a procedural method of enforcement when a technical method is available, the circumstances regarding this choice should be reviewed

219 219 Part 5.6 Data Request For each BES Cyber System (BCAs) and the associated EACMS (including EAP), PACS, and PCA, provide: The method used to enforce the password change requirement (i.e., technical or procedural) for passwordonly authentication for interactive user access If password change is enforced by a technical method, provide evidence of configuration to enforce this requirement If password change is enforced by a procedural method: Provide the procedure used to enforce this requirement Provide evidence (e.g., training content, notification, etc.) that this procedure is enforced

220 220 Part 5.6 Sample Interview Questions Describe the password change procedures for all required asset types Are there any devices that do not support password changes? Is vendor documentation available as evidence?

221 221 Part 5.6 Evidence Password change procedures Password configuration settings Vendor documentation that identifies device password capabilities for those devices that cannot support the defined requirements Evidence of password changes Attestation of compliance referencing documented procedures followed

222 222 Part 5.6 Good Evidence Part 5.6

223 223 CIP Part 5.7

224 224 Part 5.7 Authentication Thresholds Requirement does not duplicate CIP part 4.2 Part 4.2 alerts for security events Part 5.7 alert after threshold is not required to be configured by the Part 4.2 Requirement TFEs TFE triggering language qualifies both options TFE would only be necessary based on failure to implement either option (operative word or )

225 225 Part 5.7 Authentication Thresholds Threshold for unsuccessful login attempts The threshold of failed authentication attempts should be set high enough to avoid false-positives from authorized users failing to authenticate. Minimum threshold parameter for account lockout No value specified

226 226 Audit Approach Verify the entity has documented one or more processes which address this Part If the number of unsuccessful authentication attempts is limited, verify the evidence of configuration supports this method If alerts are generated after a threshold of unsuccessful authentication attempts, verify the evidence of configuration supports this method If neither method is used, verify an approved TFE covers this circumstance, and verify the compensating measures described by the TFE are in place

227 227 Part 5.7 Data Request For each BES Cyber System and the associated EACMS (including EAP), PACS, and PCA, provide: The method used to address unsuccessful authentication attempts (i.e., limiting attempts or alerting) Evidence of the configuration used to enforce this requirement

228 228 Part 5.7 Sample Interview Questions Describe the authentication lockout configuration for all required cyber assets Where no support exists for automatic lockout, describe additional security controls implemented to identify successive failed authentication attempts Describe response required for authentication lockout and of identification of successive failed login attempts

229 229 Part 5.7 Evidence Configuration evidence for assets that can meet this requirement Procedures for devices that do not support this capability

230 Part 5.7 Good evidence 230

231 231 Part 5.7 Good evidence

232 232 Part 5.7 Good evidence

233 233 R5 Issues & Pitfalls Setting the lockout setting too low can shut out account access Caution TFEs [P5.1, P5.6, P5.7] Password change management Identification and documentation of device password limitations Ensuring all interactive access has authentication implemented

234 References CIP Cyber Security Systems Security Management dated June 2, 2014 from, RSAW Version: RSAW CIP DRAFT1v0 Revision Date: June 17, 2014, RSAW Template: RSAW2014R1.3: Reliability Standard Audit Worksheet, CIP Cyber Security System Security Management, from: DRAFT NERC Reliability Standard Audit Worksheet, RSAW Version: RSAW CIP DRAFT2v0 Revision Date: September 17, 2014 RSAW Template: RSAW2014R1.3, from: NERC Consideration of Issues and Directives, Federal Energy Regulatory Commission Order No. 791 September 3, 2014, from: ves_clean_ pdf NERC Project CIP Version 5 Revisions, Mapping Document Showing Translation of the Version 5 standards into CIP-003-6, CIP-004-6, CIP-006-6, CIP-007-6, CIP-009-6, CIP-010-2, and CIP (CIP-002-5, CIP-005-5, and CIP were not modified), from: 14.pdf

235 Questions? Eric Weston Compliance Auditor Cyber Security John Graminski Compliance Auditor Cyber Security