SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Morgan King CISSP- ISSAP, CISA Senior Compliance Auditor – Cyber Security

cwen avatar
cwen
0 diapositives · 345 Views · Jul 05, 2014

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, Utah. Agenda . CIP-007-5 Overview New/Redefined Terminology CIP - 007-5 Audit Approach Issues & Pitfalls Questions.

Morgan King CISSP- ISSAP, CISA Senior Compliance Auditor – Cyber Security - slide 1
01 / 1Morgan King CISSP- ISSAP, CISA Senior Compliance Auditor – Cyber Security
1 / 17

Télécharger la présentation

Morgan King CISSP- ISSAP, CISA Senior Compliance Auditor – Cyber Security
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Morgan King CISSP-ISSAP, CISASenior Compliance Auditor – Cyber Security

    CIP-007-5 Compliance Outreach CIP v5 Roadshow May 14-15, 2014 Salt Lake City, Utah
  2. Agenda CIP-007-5 Overview New/Redefined Terminology CIP-007-5 Audit Approach Issues & Pitfalls Questions
  3. EMS ESP [IP network] EMS Electronic Security Perimeter Workstations Printer File Server Router Access Control Server Switch EAP CIP-005 Firewall CIP-007 CorpNet CIP-005 Router EAP CCA Firewall Switch DMZ CCA Switch Printer CCA CCA EMS WAN CCA EMS Servers EACM EACM CCA CCA CCA Access Control Server Intermediate Server Workstations
  4. EMS ESP/BCS [IP network] EMS Electronic Security Perimeter All PCA devices take on the impact level of the BCS Non-BCS Workstations File Server Printer PCA PCA PCA PCA Router PCA Switch EAP CIP-005 CIP-007 Firewall CorpNet CIP-005 EAP Router BCA/PCA BCA Firewall Switch CIP-002 Printer DMZ CCA Switch BCS BCA/PCA PCA BCA BCA EMS WAN BCA EMS Servers Workstations EACM EACM BCA BCA BCA Access Control Server Intermediate Server
  5. Multi-BCS ESP EMS Electronic Security Perimeter BCS Workstations BCS Server Printer BCS BCA BCA PCA BCA Router MEDIUM BCA Switch EAP CIP-007 CIP-005 Firewall CorpNet CIP-005 EAP Router BCA/PCA BCA Firewall Switch CIP-002 Printer DMZ CCA Switch BCS BCA/PCA PCA BCA BCA EMS WAN BCA EMS Servers Workstations EACM EACM BCA BCA BCA HIGH Access Control Server Intermediate Server
  6. EMS ESP [High Water Mark] EMS Electronic Security Perimeter All PCA devices take on the impact level of the BCS BCS Workstations BCS Server Printer PCA PCA PCA PCA Router PCA Switch EAP CIP-007 CIP-005 Firewall HIGH CorpNet CIP-005 EAP Router BCA/PCA BCA Firewall Switch CIP-002 Printer DMZ CCA Switch BCS BCA/PCA PCA BCA BCA EMS WAN BCA EMS Servers Workstations EACM EACM BCA BCA BCA Access Control Server Intermediate Server
  7. V5 Compliance Dates
  8. Requirement Count 7 Requirements (Version 3) 26 sub-requirements 5 Requirements (Version 5) 20 Parts
  9. CIP-007-5 Requirements CIP-007-5 R1 Ports and Services R2 Security Patch Management R3 Malicious Code Prevention R4 Security Event Monitoring R5 System Access Control
  10. CIP-007V3 to V5 Summary C-007-3 R1  CIP-010-1 R1.4 & R1.5 C-007-3 R2  CIP-007-5 R1 CIP-007-5 R1.2 – NEW – restrict physical ports CIP-007-3 R3  CIP-007-5 R2 CIP-007-5 R2.1 – NEW – identify patch sources CIP-007-3 R4  CIP-007-5 R3 CIP-007-5 R4.3 – NEW – Alerts CIP-007-3 R5  CIP-007-5 R5 CIP-007-3 R5.1  CIP-004-5 R4.1 CIP-007-3 R5.1.1  CIP-003-5 R5.2 CIP-007-3 R5.1.2  CIP-007 R4.1 CIP-007-3 R5.1.3  CIP-004-5 R4.3 CIP-007-5 R5.7 – NEW – unsuccessful login thresholds and alerts CIP-007-3 R6  CIP-007-5 R4 CIP-007-3 R7  CIP-011-1 R2 CIP-007-3 R8  CIP-010-1 R3 CIP-007-3 R9  Deleted Project 200806 Cyber Security Order 706 DL_Mapping_Document_012913.pdf
  11. Applicable Systems
  12. IAC CIP-007-5 R1-R5 contain Identify, Assess and Correct language in requirement. 17 requirements that include IAC Filing deadline Feb. 3, 2015
  13. Post for 45‐day first comment and ballot June 2–July 17, 2014 Communication Networks (Proposed Resolution) Modified requirement Part 1.2 in CIP‐007 More comprehensive coverage of physical ports IAC CIP-007, a new R2.5 CIP‐007, update to R4.4 Transient Devices CIP-010 – New Part 4.1 http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5RvnsRF/SDT%20Industry%20Webinar.pdf
  14. Serial Exemption Blanket Serial Exemption
  15. Substation Serial-Only Communications
  16. 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) 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)
  17. BCS with External Routable Connectivity CIP-007-5 Applicable Requirements: R1.2 Physical Ports R2 – Patch Management R3 – AV & Malicious code prevention R4.1, R4.3, R4.4 – Logging R5.2 – Default/Generic accounts R5.4 – Change default passwords R5.5 – Password complexity
  18. CIP-007-5 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 PACS PCA BCA groupings and BES Cyber Systems are permitted where indicated
  19. V5 Asset Level Requirements PACS systems (CIP-006-5 Part 3.1) Ports and Services (CIP-007-5 Part 1) Patch Management (CIP-007-5 Part 2) Security Event Monitoring (CIP-007-5 Part 4) BES Cyber System and/or Cyber Asset (if supported) System Access Control (CIP-007-5 Part 5) local system accounts
  20. V5 Asset Level Requirements Baseline requirement (CIP-010-1 Part 1.1) Baseline change managements (CIP-010-1 Part 1.2 – 1.5) Active monitoring -35 days (CIP-010-1 Part 2.1) Cyber Vulnerability Assessment (CIP-010-1 Part 3.1, 3.2, 3.4) Testing of new asset (CIP-010-1 Part 3.3) System reuse or destruction (CIP-011-1 Part 2)
  21. CIP-007-5 Part 1.1 Asset level requirement
  22. Ports and Services en.able, en.a.ble Logical network accessible ports
  23. Ports and Services Control required to be on the device itself or may be positioned inline (in a non-bypassable manner) Host based firewalls, TCP_Wrappersor other means on the Cyber Asset to restrict access Dynamic ports Port ranges or services 0-65535 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 Listening ports (netstat -boan/-pault) Configuration files of host-based firewalls
  24. 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:0-65535 <IP_address> >>nmap_tcp.txt Nmap –sU-sV –p U:0-65535 <IP_address> >> nmap_udp.txt #show control-plane host open-ports #show run all
  25. 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.0.0.0:135 0.0.0.0:0 LISTENING 952 C:\WINDOWS\system32\svchost.exe TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 [System] TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING 428 [spnsrvnt.exe] TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING 248 [sntlkeyssrvr.exe] TCP 0.0.0.0:7002 0.0.0.0:0 LISTENING 248 [sntlkeyssrvr.exe] TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING 1656 [dirmngr.exe] TCP 127.0.0.1:1029 0.0.0.0:0 LISTENING 2484 [alg.exe] TCP 127.0.0.1:5152 0.0.0.0:0 LISTENING 1764 [jqs.exe] TCP 127.0.0.1:33333 0.0.0.0:0 LISTENING 1856 [PGPtray.exe] TCP 172.16.105.220:139 0.0.0.0:0 LISTENING 4 [System] TCP 127.0.0.1:2111 127.0.0.1:33333 ESTABLISHED 1616 UDP 0.0.0.0:7001 *:* 248 [sntlkeyssrvr.exe] UDP 0.0.0.0:500 *:* 700 [lsass.exe] UDP 0.0.0.0:4500 *:* 700 [lsass.exe] UDP 0.0.0.0:445 *:* 4 [System] UDP 127.0.0.1:123 *:* 1084 c:\windows\system32\WS2_32.dll UDP 172.16.105.220:6001 *:* 428 [spnsrvnt.exe]
  26. Nmap EMS1 root@bt:/# nmap -sT -sV -p T:0-65535 172.16.105.151 Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-18 12:15 EST Nmap scan report for 172.16.105.151 Host is up (0.034s latency). Not shown: 65531 closed ports PORT STATE SERVICE VERSION 22/tcp open sshOpenSSH 5.3p1 Debian 3ubuntu6 (protocol 2.0) 80/tcp open http Apache httpd 2.2.14 ((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 http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 13.25 seconds
  27. Nmap EMS1 root@bt:/# nmap -sU -sV -p U:0-65535 172.16.105.151 Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-18 12:15 EST Nmap scan report for 172.16.105.151 Host is up (7.57s latency). Not shown: 65533 closed ports PORT STATE SERVICE VERSION 68/udpopen|filtereddhcpc 111/udp open rpcbind MAC Address: 00:0C:29:66:05:65 (VMware) Nmapdone: 1 IP address (1 host up) scanned in 1081.98 seconds Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 123.25 seconds
  28. Router Ports/Services
  29. What We Expect [Sample only] SAMPLE FORMAT ONLY
  30. 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-010-1 Part 1.1 "Develop a baseline configuration, individually or by group, which shall include the following items: 1.1.4. Any logical network accessible ports;’ need for a port to be open and not an actual authorization request for the port to be opened.
  31. Authorizations CIP-010-1 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"
  32. CIP-007-5 / CIP-010-1 Relationship CIP-010-1 baseline configuration requirements CIP-010-1 Part 1.1.4 Develop a baseline configuration of any logical network accessible ports Documented list of enabled ports CIP-007-5 Part 1.1 is concerned only with the enabling of needed ports Performance (CIP-007-5) versus documentation (CIP-010-1)
  33. Double Jeopardy? Failing to maintain the baseline configuration and failing to disable unnecessary ports are two different requirement violations CIP-007-5 Part 1.1 refers to listings of ports as evidence, but that evidence could be the same evidence required for CIP-010-1. Utilizing a single piece of evidence for proof of compliance with two different requirements is not double jeopardy
  34. R1.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 65535 TCP& 65535 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-010-1 and CIP-007-5) Focus on EAPs inward to ESP Cyber Systems and Cyber Assets
  35. CIP-007-5 Part 1.2 Asset level requirement
  36. CIP-007-5 Part 1.2 Asset level requirement
  37. CIP-007-3  CIP-007-5 Change
  38. Configuration Ports 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 http://www.tditechnologies.com/whitepaper-nerc-cip-007-5-r1
  39. Part 1.2 Physical Ports physical I/O ports Network Serial USB ports external to the device casing
  40. 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
  41. 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
  42. Port Locks http://www.blackbox.com/resource/genPDF/Brochures/LockPORT-Brochure.pdf
  43. Physical Access to Ports http://www.supernap.com/supernap-gallery-fullscreen/
  44. Question Would a Cyber Asset locked in a cage meet this requirement? Answer No, the required control needs to be applied on the Cyber Asset level
  45. Part 1.2 Physical Ports 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 validate physical port documentation
  46. 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
  47. CIP-007-5 Part 2.1 Asset level requirement
  48. CIP-007-3  CIP-007-5 Change
  49. 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 are routably connected or not, and mitigating those vulnerabilities Applicable to BES Cyber Systems that are accessible remotely as well as standalone systems
  50. 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 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
  51. 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 on the situation
  52. Patch Sources Electricity Sector Information Sharing and Analysis Center (ES-ISAC) https://www.esisac.com/ Common Vulnerabilities and Exposures http://cve.mitre.org/ BugTraq http://www.securityfocus.com/vulnerabilities National Vulnerability Database http://nvd.nist.gov/ ICS-CERT http://ics-cert.us-cert.gov/all-docs-feed
  53. Sources https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy
  54. 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-010-1 R1.1.5) Operating system/firmware, commercially available software or open-source application software, custom software
  55. Cyber Security software patches Hardware vendors do provide security patches and security upgrade to mitigate/eliminate vulnerabilities identified in their drivers and firmware
  56. ‘that are updateable’
  57. Windows XP (EOL 4-8-2014) 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
  58. XP Custom Support 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) http://www.computerworld.com/s/article/9237019/Microsoft_gooses_Windows_XP_s_custom_support_prices_as_deadline_nears?pageNumber=1
  59. Windows XP (EOL 4-8-2014) April 2014 there are no more security patches forthcoming for XP No patches to assess or apply No patches issued means no action required No TFEs in R2 language TFEs are not required at any step in the R2 process Still required to track, evaluate and install security patches outside of the OS
  60. End of Life Systems & Devices 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
  61. 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, 2019. The Windows Embedded operating system normally runs on appliances
  62. CIP-007-5 Part 2.2 Patch Evaluation Asset level requirement
  63. 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 Date of patch release, source, evaluation performed, date of performance and results Listing of all applicable security patches
  64. Part 2.2 Patch Evaluation
  65. Guidelines DHS “Quarterly Report on Cyber Vulnerabilities of Potential Risk to Control Systems” http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_13-39_Feb13.pdf “Recommended Practice for Patch Management of Control Systems” http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf
  66. Vulnerability Footprint http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf
  67. CIP-007-5 Part 2.3 Asset level requirement
  68. CIP-007-5 Part 2.3 [Patch Response] High Impact BCS Medium Impact BCS R2.1 Document Patch Management process & sources PCA PCA EACM EACM R2.2 Documented Patch evaluation (max 35 days) PACS PACS Required patch identified? YES NO Within 35 days R2.3 Implement Plan within time frame Install patch OR Create Mitigation plan OR Update Mitigation plan Asset level requirement
  69. 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.
  70. Timeframe Timeframe is 70 days total 35 days for tracking and determining applicability 35 days for either installing or determining the mitigation plan
  71. 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
  72. 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”
  73. CIP-007-5 Part 2.4 Asset level requirement
  74. CIP-007-5 Part 2.4 [Mitigation Plan] High Impact BCS Medium Impact BCS R2.1 Document Patch Management process & sources PCA PCA EACM EACM R2.2 Documented Patch evaluation (max 35 days) PACS PACS Required patch identified? YES NO Within 35 days R2.3 R2.4 Implement Plan within time frame Install patch CIP SM or Delegate approval OR Create Mitigation plan OR Plan Revision or Extension? YES Update Mitigation plan R2.4
  75. 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
  76. 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
  77. 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
  78. Part 2.4 Implement The ‘implement’ in the overall requirement is for the patch management process ‘Implement’ in R2.4 (Mitigation Plan) is for the individual patch 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
  79. Demonstrating implementation of Mitigation Plan 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
  80. Proposed CIP-007 R2.5
  81. R2 Issues & Pitfalls 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 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
  82. CIP-007-5 Part 3.1 BES Cyber System level requirement
  83. CIP-007-3  CIP-007-5 Change
  84. 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 R3.2 requires ability to detect malicious code 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 adapts while also reducing the need for TFEs
  85. AV/Anti-Malware
  86. Defense-N-Depth https://www.lumension.com/vulnerability-management/patch-management-software/third-party-applications.aspx
  87. 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 http://www.asd.gov.au/publications/csocprotect/application_whitelisting.htm
  88. Application Whitelisting Application File Attributes Digital Certificates File Hash File Ownership Location Reference Systems Signed Security Catalogs Software Packages
  89. Virtual Systems http://www.vmware.com/products/vshield-endpoint/overview.html
  90. Guidelines Network isolation techniques Portable storage media policies Intrusion Detection/Prevention (IDS/IPS) solutions
  91. 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
  92. ‘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 R3.1
  93. CIP-007-5 R3.2 BES Cyber System level requirement
  94. 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
  95. CIP-007-5 R3.3 BES Cyber System level requirement
  96. 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 R3.1 allows for any method to be used and does not preclude the use of any technology or tool
  97. 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?
  98. TFEs 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 TFEs are not required for equipment that does not run malicious code tools
  99. 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
  100. CIP-007-5 Part 4.1 BES Cyber System and/or Asset level requirement
  101. CIP-007-3  CIP-007-5 Change
  102. Part 4.1 Log Events 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) 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
  103. 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 outages in a timely manner
  104. CIP-007-5 Part 4.2 BES Cyber System and/or Cyber Asset (if supported) level requirement
  105. 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 Email, text, system display and alarming Alerting Examples Failed login attempt threshold exceeded Virus or malware alerts
  106. Part 4.2 Alerting Guidelines 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
  107. 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
  108. 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
  109. CIP-007-5 Part 4.3 – Part 4.4 BES Cyber System and/or Cyber Asset (if supported) level requirement
  110. 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 R4.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
  111. Part 4.3 ‘Retain Applicable Event Log’s’
  112. 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 ‘records of disposition’ of logs after their 90 days is up
  113. Part 4.4 Review Logs Guidelines 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
  114. 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 R 4.4 that should have been caught in R4.1 is this a violation?
  115. R4 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
  116. Cloud Computing http://www.ipspace.net/Webinars
  117. Monitoring-as-a-Service http://www.symantec.com/content/en/us/enterprise/other_resources/b-nerc_cyber_sercurity_standard_21171699.en-us.pdf
  118. CIP-007-5 Part 5.1 BES Cyber System and/or Cyber Asset level requirement
  119. CIP-007-3 CIP-007-5 Highlights
  120. Part 5.1 Enforce Authentication Ensure the BES Cyber System or Cyber Asset authenticates individuals with interactive access GPO (Group Policy Object) Interactive user access Doesn’t include read-only front panel displays, web-based reports Procedural Controls
  121. Part 5.1 Enforce Authentication
  122. CIP-007-5 Part 5.2 BES Cyber System and/or Cyber Asset level requirement
  123. Part 5.2 Identify Accounts Identifying the use of account types Default and other generic accounts remaining enabled must be documented 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-004-5
  124. CIP-007-5 Part 5.3 BES Cyber System and/or Cyber Asset level requirement
  125. CIP-007-3 Requirement 5.1.2
  126. Part 5.3 Identify Individuals CIP-004-5 to authorize access Authorizing access does not equate to knowing who has access to a shared account “authorized” 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
  127. CIP-007-5 Part 5.4 BES Cyber System and/or Cyber Asset level requirement
  128. 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-007-5 R2
  129. 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-5, this requirement must be met when a device becomes one of the applicable systems or assets
  130. CIP-007-5 Part 5.5 BES Cyber System and/or Cyber Asset level requirement
  131. Part 5.5 Passwords Eight characters or max supported 5.5.2 Three or more different types of chars or maximum supported
  132. Part 5.5 Passwords CAN-0017 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 Physical security suffices for local access configuration if the physical security can record who is in the Physical Security Perimeter and at what time
  133. 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
  134. CIP-007-5 Part 5.6 BES Cyber System and/or Cyber Asset level requirement
  135. 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
  136. CIP-007-5 Part 5.7 BES Cyber System and/or Cyber Asset level requirement
  137. Part 5.7 Authentication Thresholds Requirement does not duplicate CIP-007-5 part 4.2 Part 4.2 alerts for security events Part 5.7 alert after threshold is not required to be configured by the R4.2 Requirement TFEs TFE triggering language qualifies both options TFE would only be necessary based on failure to implement either option (operative word ‘or’)
  138. 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
  139. R5 Issues & Pitfalls 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
  140. Morgan King  CISSP-ISSAP, CISA Senior Compliance Auditor, Cyber Security Western Electricity Coordinating Council Salt Lake City, UT mking@wecc.biz (C) 801.608.6652 (O)801.819.7675 Questions?