Presentation is loading. Please wait.

Presentation is loading. Please wait.

Morgan King CISSP-ISSAP, CISA Senior Compliance Auditor – Cyber Security CIP-007-5 Compliance Outreach CIP v5 Roadshow May 14-15, 2014 Salt Lake City,

Similar presentations


Presentation on theme: "Morgan King CISSP-ISSAP, CISA Senior Compliance Auditor – Cyber Security CIP-007-5 Compliance Outreach CIP v5 Roadshow May 14-15, 2014 Salt Lake City,"— Presentation transcript:

1 Morgan King CISSP-ISSAP, CISA Senior Compliance Auditor – Cyber Security CIP Compliance Outreach CIP v5 Roadshow May 14-15, 2014 Salt Lake City, Utah

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

3 3 EMS ESP [IP network] CorpNet EMS WAN Firewall Router Workstations File Server Access Control Server EMS Servers Printer Router Switch CCA EMS Electronic Security Perimeter EAP Intermediate Server Access Control Server EACM Switch EACM DMZ EAP

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

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

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

7 7 V5 Compliance Dates CIP Version 5 Effective Dates RequirementEffective Date Effective Date of StandardApril 1, 2016 Requirement-Specific Effective Dates CIP R2April 1, 2016 CIP R1April 1, 2016 CIP R2 for medium and high impact BES Cyber SystemsApril 1, 2016 CIP R2 for low impact BES Cyber SystemsApril 1, 2017 CIP Part 4.4April 15, 2016 CIP Part 2.1May 6, 2016 CIP Part 4.2July 1, 2016 CIP Part 2.3April 1, 2017 CIP Part 4.3April 1, 2017 CIP Part 4.4April 1, 2017 CIP Part 3.1April 1, 2017 CIP Part 2.1April 1, 2017 CIP Part 2.1April 1, 2017 CIP Part 2.2April 1, 2017 CIP Part 3.1April 1, 2017 CIP Part 2.3April 1, 2018 CIP Part 3.1 April 1, 2017 CIP Part 3.2April 1, 2018 CIP Part 3.5Within 7 years after previous Personnel Risk Assessment

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

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

10 10 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 CIP-007 V3 to V5 Summary Project Cyber Security Order 706 DL_Mapping_Document_ pdf

11 11 Applicable Systems

12 12 CIP R1-R5 o contain Identify, Assess and Correct language in requirement. 17 requirements that include IAC o Filing deadline Feb. 3, 2015 IAC

13 13 Post for 45 ‐ day first comment and ballot June 2–July 17, 2014 Communication Networks (Proposed Resolution) o Modified requirement Part 1.2 in CIP ‐ 007  More comprehensive coverage of physical ports IAC o CIP-007, a new R2.5 o CIP ‐ 007, update to R4.4 Transient Devices CIP-010 – New Part 4.1

14 14 Serial Exemption

15 15 Substation Serial-Only Communications

16 16 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) are to be included within the V5 requirements and may be BES Cyber Assets or even BES Cyber System, even if no routable communications exist Therefore, there are V5 requirements to be addressed (i.e. CIP-007-5) Non-Routable BCS

17 17 CIP Applicable Requirements: o R1.2 Physical Ports o R2 – Patch Management o R3 – AV & Malicious code prevention o R4.1, R4.3, R4.4 – Logging o R5.2 – Default/Generic accounts o R5.4 – Change default passwords o R5.5 – Password complexity BCS with External Routable Connectivity

18 18 o 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  PACS  PCA o BCA groupings and BES Cyber Systems are permitted where indicated CIP Asset Level Requirements

19 19 PACS systems (CIP Part 3.1) 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 V5 Asset Level Requirements

20 20 Baseline requirement (CIP Part 1.1) Baseline change managements (CIP Part 1.2 – 1.5) Active monitoring -35 days (CIP Part 2.1) Cyber Vulnerability Assessment (CIP Part 3.1, 3.2, 3.4) Testing of new asset (CIP Part 3.3) System reuse or destruction (CIP Part 2) V5 Asset Level Requirements

21 21 CIP Part 1.1 Asset level requirement

22 22 en. able, en. a. ble Logical network accessible ports Ports and Services

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

24 24 Netstat: o Netstat -b -o -a -n > netstat_boan.txt o Netstat -p -a -u -l -t > netstat_pault.txt NMAP scan results o Nmap -sT -sV –p T: >>nmap_tcp.txt o Nmap –sU -sV –p U: >> nmap_udp.txt #show control-plane host open-ports #show run all Tools/commands

25 25 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] Netstat

26 26 Nmap 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

27 27 Nmap 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

28 28 Router Ports/Services

29 29 What We Expect [Sample only] Device IDDevice NameTCP PortsUDP PortsServiceJustification

30 30 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? o CIP Part 1.1  "Develop a baseline configuration, individually or by group, which shall include the following items:  Any logical network accessible ports;’ o need for a port to be open and not an actual authorization request for the port to be opened. Question

31 31 CIP Part 1.2 o "Authorize and document changes that deviate from the existing baseline configuration.” o 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" Authorizations

32 32 CIP baseline configuration requirements o 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-5) versus documentation (CIP-010-1) CIP / CIP Relationship

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

34 34 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 both logical and physical ports Initial identification of physical port usage and controls – port use mapping VA, approved baselines, and implemented logical ports and services should always agree (CIP and CIP ) Focus on EAPs inward to ESP Cyber Systems and Cyber Assets R1.1 Issues & Pitfalls

35 35 CIP Part 1.2 Asset level requirement

36 36 CIP Part 1.2 Asset level requirement

37 37 CIP  CIP Change

38 38 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 Configuration Ports

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

40 40 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” o Requirement is not to be a 100% preventative control o 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 Part 1.2 Physical Ports

41 41 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 Guidelines

42 42 Port Locks

43 43 Physical Access to Ports

44 44 Would a Cyber Asset locked in a cage meet this requirement? Answer o No, the required control needs to be applied on the Cyber Asset level Question

45 45 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 o Think before you plug anything into one of these systems o 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 validate physical port documentation Part 1.2 Physical Ports

46 46 A routable device with all of its physical network ports blocked which would have otherwise been identified as routable device, now cannot route. o 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 o The Cyber Asset’s function as it pertains to BES reliability determines system identification Physical Ports and Applicable Systems

47 47 CIP Part 2.1 Asset level requirement

48 48 CIP  CIP Change

49 49 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 are routably connected or not, and mitigating those vulnerabilities Applicable to BES Cyber Systems that are accessible remotely as well as standalone systems Part 2.1 Patch Management Process

50 50 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 monthly basis 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 the specific circumstances Part 2.1 Tracking

51 51 Is applicability based on original source of patch (e.g. Microsoft) or the SCADA vendor? o 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. o Appropriate source dependent on the situation Tracking for Applicability

52 52 Electricity Sector Information Sharing and Analysis Center (ES-ISAC) o https://www.esisac.com/ https://www.esisac.com/ Common Vulnerabilities and Exposures o BugTraq o National Vulnerability Database o ICS-CERT o Patch Sources

53 53 Sources https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy

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

55 55 Hardware vendors do provide security patches and security upgrade to mitigate/eliminate vulnerabilities identified in their drivers and firmware Cyber Security software patches

56 56

57 57 ‘that are updateable’

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

59 59 Are entities required to enter into a very expensive, per-Cyber Asset custom support contract with Microsoft in order to continue to receive support $200,000 - $500,000 (2006) $200,000 cap (2010) $600,000 - $5 million for first year (2014) XP Custom Support

60 60 April 2014 there are no more security patches forthcoming for XP o No patches to assess or apply No patches issued means no action required No TFEs in R2 language o TFEs are not required at any step in the R2 process Still required to track, evaluate and install security patches outside of the OS Windows XP (EOL )

61 61 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 End of Life Systems & Devices

62 62 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 Windows XP Embedded

63 63 CIP Part 2.2 Patch Evaluation Asset level requirement

64 64 At least every CIP Month (35 days) evidence of patch release monitoring and evaluation of patches for applicability Evaluation Assessment o Determination of Risk o Remediation of vulnerability o Urgency and timeframe of remediation o 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 o Date of patch release, source, evaluation performed, date of performance and results o Listing of all applicable security patches Part 2.2 Patch Evaluation

65 65 Part 2.2 Patch Evaluation

66 66 DHS o “Quarterly Report on Cyber Vulnerabilities of Potential Risk to Control Systems”  39_Feb13.pdf 39_Feb13.pdf o “Recommended Practice for Patch Management of Control Systems”  cert.gov/sites/default/files/recommended_practices/Patch ManagementRecommendedPractice_Final.pdf cert.gov/sites/default/files/recommended_practices/Patch ManagementRecommendedPractice_Final.pdf Guidelines

67 67 Vulnerability Footprint

68 68 CIP Part 2.3 Asset level requirement

69 69 CIP Part 2.3 [Patch Response] Document Patch Management process & sources High Impact BCS Medium Impact BCS PCA R2.1 EACM PACS PCA EACM PACS Documented Patch evaluation (max 35 days) R2.2 Required patch identified? Install patch NO YES Within 35 days Create Mitigation plan Update Mitigation plan OR Implement Plan within time frame R2.3 Asset level requirement

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

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

72 72 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 o Requirement is to have a plan  Date of the plan in requirement part 2.3 is what part 2.4 depends upon o Must work towards that plan Maximum Timeframes

73 73 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” Timeframes Guidelines

74 74 CIP Part 2.4 Asset level requirement

75 75 CIP Part 2.4 [Mitigation Plan] Document Patch Management process & sources High Impact BCS Medium Impact BCS PCA R2.1 EACM PACS PCA EACM PACS Required patch identified? Documented Patch evaluation (max 35 days) R2.2 Install patch NO YES Within 35 days Create Mitigation plan Update Mitigation plan OR Implement Plan within time frame CIP SM or Delegate approval Plan Revision or Extension? R2.3 R2.4 YES

76 76 Evidence of CIP Senior Manager’s approval for updates to mitigation plans or extension requests o 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 Part 2.4 Mitigation Plan

77 77 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 Part 2.3 Mitigation

78 78 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 Part 2.3 Mitigation Guidelines

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

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

81 81 Proposed CIP-007 R2.5

82 82 Asset level requirements Know, track, and mitigate the known software vulnerabilities associated with BES Cyber Assets Not including a complete listing of BES Cyber Systems and assets that are applicable o Firmware devices (relays, appliances, etc.) o Infrastructure devices within ESP o 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 o required to be included in the monitoring for patches R2 Issues & Pitfalls

83 83 CIP Part 3.1 BES Cyber System level requirement

84 84 CIP  CIP Change

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

86 86 AV/Anti-Malware

87 87 Defense-N-Depth https://www.lumension.com/vulnerability-management/patch-management-software/third-party-applications.aspx

88 88 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 Application Whitelisting

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

90 90 Virtual Systems

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

92 92 Is an awareness campaign to deter ok? o ‘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 Part 3.1 Malicious Code

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

94 94 CIP R3.2 BES Cyber System level requirement

95 95 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 o Entity can state how the mitigation covers the associated PCA’s Part 3.2 Detected Malicious Code

96 96 CIP R3.3 BES Cyber System level requirement

97 97 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 R3.1 allows for any method to be used and does not preclude the use of any technology or tool Requires process for updates

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

99 99 Requirement has been written at a much higher level than previous versions Requirement no longer prescriptively requires a single technology tool for addressing the issue o TFEs are not required for equipment that does not run malicious code tools TFEs

100 100 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 R3 Issues & Pitfalls

101 101 CIP Part 4.1 BES Cyber System and/or Asset level requirement

102 102 CIP  CIP Change

103 103 Entity determines which computer generated events are necessary to log, 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 (4.1.1  4.1.3) o Successful and failed logins o 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 o Detection of malicious code Part 4.1 Log Events

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

105 105 CIP Part 4.2 BES Cyber System and/or Cyber Asset (if supported) level requirement

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

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

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

109 109 Guidance implies that only technical means are allowed for alerting on a ‘detected cyber security event’ o 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 o Requirement does not preclude procedural controls Guidance

110 110 CIP Part 4.3 – Part 4.4 BES Cyber System and/or Cyber Asset (if supported) level requirement

111 111 Timeframe: o Response timeframe begins with the alert of the failure o After something or someone has detected the failure and has generated an alert as in R4.2 o 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 o On or before April 15, 2016 Part 4.3 ‘Retain Applicable Event Logs’

112 112 Part 4.3 ‘Retain Applicable Event Log’s’

113 113 Is the audit approach to ask for any single day’s logs in past three years? o 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 o ‘records of disposition’ of logs after their 90 days is up Part 4.3 ‘Retain Applicable Event Logs’

114 114 Summarization or sampling of logged events o log analysis can be performed top-down starting with a review of trends from summary reports o Determined by the Responsible Entity Electronic Access Points to ESP’s are EACMs, this is one of the primary logs that should be reviewed Part 4.4 Review Logs Guidelines

115 115 Purpose is to identify undetected security incidents Paragraph 525 of Order 706 o Even if automated systems are used, the manual review is still required o Manually review logs ensure automated tools are tuned and alerting on real incidents What if an entity identifies events in R 4.4 that should have been caught in R4.1 is this a violation? Part 4.4 Review Logs

116 116

117 117 Ensure all EACMs are identified o “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 o Log collection data flows o Aggregation points o Analysis processes and/or technologies Validation of the required logs and alert configurations R4 Issues & Pitfalls

118 118 Cloud Computing

119 119 Monitoring-as-a-Service

120 120 CIP Part 5.1 BES Cyber System and/or Cyber Asset level requirement

121 121 CIP  CIP Highlights

122 122 Ensure the BES Cyber System or Cyber Asset authenticates individuals with interactive access o GPO (Group Policy Object) Interactive user access o Doesn’t include read-only  front panel displays, web-based reports Procedural Controls Part 5.1 Enforce Authentication

123 123 Part 5.1 Enforce Authentication

124 124 CIP Part 5.2 BES Cyber System and/or Cyber Asset level requirement

125 125 Identifying the use of account types o Default and other generic accounts remaining enabled must be documented o Avoids prescribing an action to address these accounts without analysis  Removing or disabling the account could have reliability consequences. Not inclusive of System Accounts For common configurations, documentation can be performed at a BES Cyber System or more granular level Restricting accounts based on least privilege or need to know covered in CIP Part 5.2 Identify Accounts

126 126 CIP Part 5.3 BES Cyber System and/or Cyber Asset level requirement

127 127 CIP Requirement 5.1.2

128 128 CIP to authorize access o Authorizing access does not equate to knowing who has access to a shared account “authorized” o An individual storing, losing or inappropriately sharing a password is not a violation of this requirement Listing of all shared accounts and personnel with access to each shared account Part 5.3 Identify Individuals

129 129 CIP Part 5.4 BES Cyber System and/or Cyber Asset level requirement

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

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

132 132 CIP Part 5.5 BES Cyber System and/or Cyber Asset level requirement

133 133 Eight characters or max supported Three or more different types of chars or maximum supported Part 5.5 Passwords

134 134 CAN-0017 o Compliance Application Notices do not carry forward to new versions of the standard Requirement explicitly addressed the issue raised by CAN-0017 that either technical or procedural mechanisms can meet the requirement Guidelines Section o Physical security suffices for local access configuration if the physical security can record who is in the Physical Security Perimeter and at what time Part 5.5 Passwords

135 135 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 Part 5.5 Passwords

136 136 CIP Part 5.6 BES Cyber System and/or Cyber Asset level requirement

137 137 Password change procedures Evidence of password changes at least every CIP Year (15 months) Disabled Accounts o Password change is not required because these do not qualify as providing interactive user authentication Part 5.6 Password Changes

138 138 CIP Part 5.7 BES Cyber System and/or Cyber Asset level requirement

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

140 140 Threshold for unsuccessful login attempts o “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 o No value specified Part 5.7 Authentication Thresholds

141 141 Setting the lockout setting to low can shut out account access – Caution TFEs Password change management Identification and documentation of device password limitations Ensuring all interactive access has implemented authentication R5 Issues & Pitfalls

142 Morgan King CISSP-ISSAP, CISA Senior Compliance Auditor, Cyber Security Western Electricity Coordinating Council Salt Lake City, UT (C) (O) Questions?


Download ppt "Morgan King CISSP-ISSAP, CISA Senior Compliance Auditor – Cyber Security CIP-007-5 Compliance Outreach CIP v5 Roadshow May 14-15, 2014 Salt Lake City,"

Similar presentations


Ads by Google