Compliance Outreach CIP v5 Roadshow

Compliance Outreach CIP v5 Roadshow
CIP-101 September 24-25, 2013 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 (c) 2013 Dr. Joseph B. Baugh

Agenda CIP-007-5 Overview New/Redefined Terminology
CIP-101 September 24-25, 2013 Agenda CIP Overview New/Redefined Terminology CIP Audit Approach Issues & Pitfalls Questions (c) 2013 Dr. Joseph B. Baugh

EMS ESP [IP network] EMS Electronic Security Perimeter CorpNet EMS WAN
CIP-101 September 24-25, 2013 EMS ESP [IP network] EMS Electronic Security Perimeter EMS WAN Workstations File Server Access Control Server EMS Servers Printer Router Switch CCA CIP-007 Router CIP-005 EAP Firewall CorpNet EAP Firewall DMZ Switch CIP-002 identification of scope Cip-005 EAP knowing what traffic we allow through the EAPs EACM EACM Access Control Server Intermediate Server (c) 2013 Dr. Joseph B. Baugh

EMS ESP/BCS [IP network]
CIP-101 September 24-25, 2013 EMS ESP/BCS [IP network] EMS Electronic Security Perimeter All PCA devices take on the impact level of the BCS EMS WAN Non-BCS Workstations File Server Printer PCA PCA PCA PCA Router PCA CIP-005 Switch EAP CIP-007 Firewall CorpNet EAP BCS CIP-002 BCA/PCA Router Firewall BCA Switch Printer DMZ Switch BCA/PCA CCA PCA CIP-007 specific controls of BCA, EACM and PACs .. New higher level concept of a BCS As you go through CIP-007 V5 will find have a lot of controls already in place from Version BCS logical grouping of Cyber Assets important to how you group cyber assets in a BCS so your affording required controls Again important CIP-002, CIP-005 and CIP-007 SMEs to work together BCA BCA BCA Workstations EMS Servers EACM EACM BCA BCA BCA Access Control Server Intermediate Server (c) 2013 Dr. Joseph B. Baugh

BCS BCS Multi-BCS ESP EMS Electronic Security Perimeter MEDIUM CorpNet
CIP-101 September 24-25, 2013 Multi-BCS ESP EMS Electronic Security Perimeter EMS WAN BCS Workstations BCS Server BCS Printer BCA BCA PCA BCA Router MEDIUM BCA CIP-005 Switch EAP CIP-007 Firewall CorpNet EAP BCS CIP-002 BCA/PCA Router Firewall BCA Switch Printer DMZ Switch BCA/PCA CCA PCA Understand multiple higher level logical grouping of Cyber Assets (BCS) can exist within the same ESP BCA BCA BCA Workstations EMS Servers EACM EACM BCA BCA BCA HIGH Access Control Server Intermediate Server (c) 2013 Dr. Joseph B. Baugh

EMS ESP [High Water Mark]
CIP-101 September 24-25, 2013 EMS ESP [High Water Mark] EMS Electronic Security Perimeter All PCA devices take on the impact level of the BCS EMS WAN BCS Workstations BCS CIP-002 BCS Server Printer PCA PCA PCA PCA Router PCA CIP-005 Switch EAP CIP-007 Firewall HIGH CorpNet EAP BCA/PCA Router Firewall BCA Switch Printer DMZ Switch BCA/PCA CCA PCA However the High water requires the afforded to appropriate CIP 7 controls .. evidence for CIP-007 please provide List of Cyber Assets develop our random sample set of Cyber Assets. Update current list to address BCS logical grouping ESP CIP-005 R1 All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP. I have not heard of any version 5 updates to the NERC random sampling guidelines as of today. BCA BCA BCA Workstations EMS Servers EACM EACM BCA BCA BCA Access Control Server Intermediate Server (c) 2013 Dr. Joseph B. Baugh

V5 Compliance Dates CIP-101 September 24-25, 2013
CIP Version 5 Effective Dates Requirement Effective Date Effective Date of Standard April 1, 2016 Requirement-Specific Effective Dates CIP R2 CIP R1 CIP R2 for medium and high impact BES Cyber Systems for low impact BES Cyber Systems April 1, 2017 CIP Part 4.4 April 15, 2016 CIP Part 2.1 May 6, 2016 CIP Part 4.2 July 1, 2016 CIP Part 2.3 CIP Part 4.3 CIP Part 4.4 CIP Part 3.1 CIP Part 2.1 CIP Part 2.1 CIP Part 2.2 CIP Part 3.1 CIP Part 2.3 April 1, 2018 CIP Part 3.2 CIP Part 3.5 Within 7 years after previous Personnel Risk Assessment A lot of dates from V5 implementation are a year out from 4/1/16. There are requirements in CIP-007 with 15 calendar day an action needs to happen. (c) 2013 Dr. Joseph B. Baugh

Requirement Count 7 Requirements (Version 3)
26 sub-requirements 5 Requirements (Version 5) 20 Parts Moved from sub-requirements to Parts of a requirement

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 Note again all of CIP7 version 5 contains high level V3 controls. Verify EAPs are afforded all the protections of CIP-007 as required.

CIP-007 V3 to V5 Summary C-007-3 R1  CIP-010-1 R1.4 & R1.5
CIP-101 September 24-25, 2013 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 On the left is version 3 and can see they all still exist in Version 5 with some new controls added Specifically ……. Note: CIP R4.3 – NEW – mitigation plan for alert and processing failures –[ this is not in the final standard --Mapping document incorrect] Project Cyber Security Order 706 DL_Mapping_Document_ pdf (c) 2013 Dr. Joseph B. Baugh

Applicable Systems CIP-101 September 24-25, 2013 No requirements at
Lows, Dialup and EAP. Again EAPs fall under the umbrella of EACMs. (c) 2013 Dr. Joseph B. Baugh

IAC CIP-007-5 R1-R5 17 requirements that include IAC
contain Identify, Assess and Correct language in requirement. 17 requirements that include IAC Filing deadline Feb. 3, 2015 IAC language ambiguous, concerns about inconsistent application, unclear expectations placed on industry Sounds like SDT is moving to remove it instead of further define it. FERC gave NERC 1 year to address IAC and come up with alternative approach ROP/RAI

Post for 45‐day first comment and ballot June 2–July 17, 2014
CIP-101 September 24-25, 2013 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 NERC defines Cyber Assets as “[p]rogrammable electronic devices and communication networks including hardware, software, and data.” NERC Glossary of Terms Used in NERC Reliability Standards (NERC Glossary), at 4. NERC defines Critical Cyber Assets as “Cyber Assets essential to the reliable operation of Critical Assets.” Id. In turn, Critical Assets are defined as “[f]acilities, systems, and equipment which, if destroyed, degraded, or otherwise rendered unavailable, would affect the reliability or operability of the Bulk Electric System.” Id. Section 215(a)(8) of the FPA defines “cybersecurity incident” as “a malicious act or suspicious event that disrupts, or was an attempt to disrupt, the operation of those programmable electronic devices and Post for 45‐day first comment and ballot June 2–July 17, 2014:  SDT in‐person meetings July and August, 2014 (will finalize at May meeting) • Additional 45‐day comment and ballot August 29‐October 13, 2014 (if necessary) • Final ballot October 31–November 10, 2014 CIP-006 – NEW PART 1.10 Restrict Pysical Access to cablink and other nonprogrammable commuication compontes used for connection between applicalble cyber assets within the same ESP when cabling and components are outsdie a PSP IF cannot ‘alternative measures encrypting data or alarm/alert monitoring communication links. Transient Devices Proposed Resolution Proposed new definitions  Transient Cyber Asset  Removable Media • Proposed modified definitions  BES Cyber Asset  Protected Cyber Asset • New requirement in CIP‐010 • Additional guidance provided in CIP‐004 and CIP‐011 Part 4.1. Authorize Transient Cyber Assets and Removable Media prior to initial use, except for CIP Exceptional Circumstances. Authorization shall include: Users, individually or by group/role; Locations, individually or by group/role; For Transient Cyber Assets, software, including but not limited to; OS or firmware where no independent OS exists, intentionally installed software; and For Transient Cyber Assets, any security patches applied. Transient Part 4.2. Deploy method(s) on Transient Cyber Assets to deter, detect, or prevent malicious code (per Transient Cyber Asset capability). Part 4.3. Deploy method(s) for Removable Media to detect malicious code prior to each use (per device capability). Per Removable Media capability? Part 4.4. For Transient Cyber Assets and Removable Media, mitigate the threat of detected malicious code. Part 4.5 For those methods identified in Part 4.2 that use signatures or patterns, have a process for the update of the signatures or patterns. The process must address testing and installing the signatures or patterns. Part 4.6. Evaluate Transient Cyber Assets prior to initial use and at least once every 15 calendar months for modifications as documented in Part For modification(s) identified in this section, take one of the following actions prior to use:  Remediate by returning the Transient Cyber Asset to the baseline documented in Part 4.1.3; or  Update the approved baseline in Part 4.1.3 Part 4.7. Evaluate Transient Cyber Assets prior to initial use and at least once every 15 calendar months for patches documented in Part take one of the following actions prior to use:  Apply the applicable patches; or  Create a dated mitigation plan; or  Revise an existing mitigation plan. Mitigation plans shall include the Responsible Entity’s planned actions to mitigate the vulnerabilities addressed by each security patch prior to use. (c) 2013 Dr. Joseph B. Baugh

Blanket Serial Exemption
CIP-101 September 24-25, 2013 Serial Exemption Blanket Serial Exemption Version 3 had this concept about a Blanket Serial exception Serial devices come into play how they grouped in the BCS and the applicability matrices for each requirement.. (c) 2013 Dr. Joseph B. Baugh

Substation Serial-Only Communications
CIP-101 September 24-25, 2013 Substation Serial-Only Communications Again Serially connected Cyber Assets .. programmable electronic devices, including the hardware, software, and data in those devices. May be BCA and require afforded protections based on BCS impact rating (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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) Ok how many ways can you say the same thing Again hammering home this point (c) 2013 Dr. Joseph B. Baugh

BCS with External Routable Connectivity
CIP-101 September 24-25, 2013 BCS with External Routable Connectivity CIP 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 Again as discussed in CIP-005 a lot of requirements apply when ESP has ERC… Note as discussed yesterday Cyber Assets that do not have an IP Address still may be considered to have ERC If host A to Host B anywhere in the link there is the use of IP then the device maybe ERC Reverse telnet. (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 Asset Level Requirements
CIP-101 September 24-25, 2013 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 PACS PCA BCA groupings and BES Cyber Systems are permitted where indicated Entities have asked can we afford CIP7 at BCS level? Certainly some parts of requirements (c) 2013 Dr. Joseph B. Baugh

V5 Asset Level Requirements
CIP-101 September 24-25, 2013 V5 Asset Level Requirements 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 A lot of these go beyond CIP-007 Something to ask is how are ensuring we are affording required protections to these cyber assets ? May chose a common control relative to each BCS but ensuring the control is applied to each Cyber Asset in scope of the requirement Maintenance and testing of each Physical Access Control System and locally mounted hardware or devices at the Physical Security Perimeter at least once every 24 calendar months to ensure they function properly. (c) 2013 Dr. Joseph B. Baugh

V5 Asset Level Requirements
CIP-101 September 24-25, 2013 V5 Asset Level Requirements 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) Now each Cyber Asset needs a baseline of ports and services and other things and may be part of a similar grouping but all Cyber Assets must be addressed (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 Part 1.1 Asset level requirement
CIP-101 September 24-25, 2013 CIP Part 1.1 Not an ‘implement a policy’ type requirement. In response, the SDT does not believe that a policy only requirement would meet the FERC directive in Docket No. RD of March 18, 2010, which is the genesis of this requirement. Several commenters suggested that signage is a weak control that does not provide adequate protection. In response, the SDT notes that signage was never meant to be a preventative control against intruders. Signage is indeed a directive control, not a preventative one. However, with a defense-in-depth posture, different layers and types of controls are required throughout the standard with this providing another layer for depth in Control Center environments. The industry has made several comments as to the other preventative and detective measures that are required before physical access to a physical port is ever achieved. Once physical access has been achieved through the other preventative and detective measures by authorized personnel, a directive control that outlines proper behavior as a last line of defense is appropriate in these highest risk areas. In essence, signage would be used to remind authorized users to “think before you plug anything into one of these systems” which is the intent. This control is not designed primarily for intruders, but for example the authorized employee who plugs his infected smart phone into an operator console USB port “just to charge the battery”. Asset level requirement (c) 2013 Dr. Joseph B. Baugh

Ports and Services en.able, en.a.ble Logical network accessible ports
CIP-101 September 24-25, 2013 Ports and Services en.able, en.a.ble Logical network accessible ports NERC is working to ensure Regional Entities have a much more synchronous approach moving to V5 Auditor Training Pilot Study Per RFC 793, these are indicative of established connections that are “half - open” 4 One side of the TCP connection has closed or aborted the connection without the knowledge of the other side, or both sides of the connection have become de synchronized. 7 “Enabled” ● What does “enable” mean? Since it is not specifically defined by NERC, we use a reasonable definition, such as would be found in a dictionary.  en·able transitive verb \ i ˈ nā bəl : to cause (a feature or capability of a computer) to be active or available for use (http :// webster.com) en·a·ble • To supply with the means, knowledge, or opportunity make operational; activate ( Port In TCP/IP and UDP networks, a port is the name given to an endpoint of a logical connection. Example – port 80 Hypertext Transfer Protocol (HTTP) Service A service is a system process that can run independent of or in conjunction with an application and may have one or more ports associated with it. DFSRs.exe Distributed File System Replication As an example, consider the following scenario: A socket application has been terminated, but Netstat reports the socket in a CLOSE_WAIT state. This could indicate that the client properly closed the connection (FIN has been sent), but the server still has its socket open. This could be the result of one instance (among all threads or processes) of the socket not being closed. NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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_Wrappers or other means on the Cyber Asset to restrict access Dynamic ports Port ranges or services 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 If non-required ports cannot be disabled – document why –TFE not required TCP Wrapper is a host-based networking ACL system, used to filter network access to Internet Protocol servers on (Unix-like) operating systems such as Linux or BSD. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes. “Listening” ports eliminates all UDP ports not an accepted security control What about known ports that are not in “Listening” state? Ranges UDP Network accessible Device communicating (client) with a server process (NTP, SNMP, FTP, etc.) – Do we need to supply list of these to identify? 7 “Enabled” ● What does “enable” mean? Since it is not specifically defined by NERC, we use a reasonable definition, such as would be found in a dictionary.  en·able - transitive verb \ i ˈ nā bəl : to cause (a feature or capability of a computer) to be active or available for use (http :// webster.com) en·a·ble • To supply with the means, knowledge, or opportunity make operational; activate ( Port In TCP/IP and UDP networks, a port is the name given to an endpoint of a logical connection. Example – port 80 Hypertext Transfer Protocol (HTTP) Service A service is a system process that can run independent of or in conjunction with an application and may have one or more ports associated with it. DFSRs.exe Distributed File System Replication (c) 2013 Dr. Joseph B. Baugh

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 run all Control Plane Policing features (available from 12.3(4)T)

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 : : LISTENING C:\WINDOWS\system32\svchost.exe TCP : : LISTENING [System] TCP : : LISTENING [spnsrvnt.exe] TCP : : LISTENING [sntlkeyssrvr.exe] TCP : : LISTENING [sntlkeyssrvr.exe] TCP : : LISTENING [dirmngr.exe] TCP : : LISTENING [alg.exe] TCP : : LISTENING [jqs.exe] TCP : : LISTENING [PGPtray.exe] TCP : : LISTENING [System] TCP : : ESTABLISHED UDP : *:* [sntlkeyssrvr.exe] UDP : *:* [lsass.exe] UDP : *:* [lsass.exe] UDP : *:* [System] UDP : *:* c:\windows\system32\WS2_32.dll UDP : *:* [spnsrvnt.exe]

Nmap CIP-101 September 24-25, 2013 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 Purpose: Port 0 is officially a reserved port in TCP/IP networking, meaning that it should not be used for any TCP or UDP network communications. However, port 0 sometimes takes on a special meaning in network programming, particularly Unix socket programming. In that environment, port 0 is a programming technique for specifying system-allocated (dynamic) ports. Description: Configuring a new socket connection requires assigning a TCP or UDP port number. Instead of hard-coding a particular port number, or writing code that searches for an available port on the local system, network programmers can instead specify port 0 as a connection parameter. That triggers the operating system to automatically search for and return the next available port in the dynamic port number range. Unix, Windows and other operating systems vary slightly in their handling of port 0. (c) 2013 Dr. Joseph B. Baugh

Nmap CIP-101 September 24-25, 2013 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 open|filteredNmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way. (c) 2013 Dr. Joseph B. Baugh

Router Ports/Services
Control Plane Policing features (available from 12.3(4)T),

What We Expect [Sample only]
CIP-101 September 24-25, 2013 What We Expect [Sample only] Device ID Device Name TCP Ports UDP Ports Service Justification SAMPLE FORMAT ONLY “individually or by group” to the bullet point. This gets into CIP-010 baselines but (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 "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. Some folks have taken a stance that the “intent” of the standard(s), CIP-005, R1.3 and CIP-007, R1.1 – is that entities capture the need for a port to be open and the approval request for the port to be opened. We would agree that the approach be to " capture the need for a port to be open (to and through) and not an actual approval request for the port to be opened. Now for an EAP and entity could utilize the #comment in an ACL and certainly to have an established 'baseline' of the configuration so that whatever is running on the Cyber Asset/EAP is the approved baseline and this also ties into CIP Part 1.1 "Develop a baseline configuration, individually or by group, which shall include the following items: Any logical network accessible ports; and" Others contend that the intent of the requirement is that entities know what ports are opened and give a reason for them being open, but that there is no requirement to tie the reason back to the authorization request; that any approval of changes is tracked in CIP-010-1 So I guess you could say both ideas are correct because CIP Part 1.2 requires - "Authorize and document changes that deviate from the existing baseline configuration." and Measures reads - 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" That being said an entity will want a way to link all of this together in order to demonstrate compliance with the requirements. I don't see the CIP-005 or CIP-007 auditors verifying the actual authorizations, but certainly the CIP auditors would most likely random sample to gain a reasonable assurance an entity actually authorizes changes that deviate from existing baseline configurations . It doesn’t seem like too big of a deal to track the reason/justification for a port or set of ports to be opened and the approval request however, if you have a firewall rule, for example, that contains a service object group, each time a port is added or removed from that object group the description will have to be updated. So if you are tracking the reasoning and approval process, the reason/justification can become clouded with the various approvals that might occur over multiple audit periods. The same constraint would apply to tracking approvals using an .xls or through a database. I will reserve judgement on 'big or small deal' to track the reason/justification but pursuant to CIP Part 1.2 it is required. I hope that we can capture the answer as a lessons learned but I don’t want SMUD’s sole interpretation to be a lessons learned without it first being considered by a larger group. Certainly this maybe something to point out in the lessons learned if you deem so. I hope this is helpful and may require further discussion so we are on the same page. (c) 2013 Dr. Joseph B. Baugh

Authorizations CIP-010-1 Part 1.2
CIP-101 September 24-25, 2013 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" BCS grouping can be used but every cyber asset in scope needs to be included in the relative grouping The question is with regard to the tracking of ports and services – at both the asset level and through the EAP (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 / CIP-010-1 Relationship
CIP-101 September 24-25, 2013 CIP / CIP Relationship CIP baseline configuration requirements CIP Part 1.1.4 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) (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 So is the baseline incorrect or is the ports and services incorrect? Now if the ports and services running on a cyber asset are correct and can demonstrate that fact would only be a baseline PV. So an entity could utilize their VA RAW data as evidence of ports and services currently running on Cyber Asset. We would compare that evidence to the existing baseline. Now the running configuration cannot be the approved baseline of ports and services. Certainly this requires vendor and SME to Determinte what is’ determined to be needed by the Responsible Entity,’ (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 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-007-5) Focus on EAPs inward to ESP Cyber Systems and Cyber Assets Port The only one left not part of a default Windows install. To find out what ports like these are, you need documentation. After a quick search through Robert Grahams Firewall Forensics: What am I seeing? leads to the conclusion that this is the Sub7 trojan horse. Use a virusscanner to remove it. If you have port Only identifying ports above Configuring Port to Application Mapping (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 CIP Part 1.2 Protect against the use of unnecessary physical input/output ports used for network connectivity, console commands, or removable media. Measures: An example of evidence may include, but is not limited to, documentation showing types of protection of physical input/output ports, either logically through system configuration or physically using a port lock or signage. Asset level requirement (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 CIP Part 1.2 Protect against the use of unnecessary physical input/output ports used for network connectivity, console commands, or removable media. Measures: An example of evidence may include, but is not limited to, documentation showing types of protection of physical input/output ports, either logically through system configuration or physically using a port lock or signage. The network ports included in the scope of this requirement part are not limited to those on the BES Cyber System itself. The scope of physical network ports includes those ports that may exist on nonprogrammable devices such as unmanaged switches, hubs, or patch panels. Asset level requirement (c) 2013 Dr. Joseph B. Baugh

CIP-007-3  CIP-007-5 Change CIP-007-3 CIP-007-5 Logical Ports only
Includes Physical Ports (R1)

Configuration Ports Change Bios Upgrade Firmware
CIP-101 September 24-25, 2013 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 9600 bits per second 8 Parity : none Stop bits : 1 Flow control : none. A significant influence on the severity of the threat an access port presents to the Utility organization is the privileged capabilities the port presents to its user. Configuration ports present an extremely high set of privileges that can be used to change almost anything on the target device. This level of privilege is why access to configuration ports is often referred to as having the “keys to the kingdom.” The list of severe security threats over configuration ports is impossible to fully document due to the range of privileged commands these ports provide to its users. Some of the more obvious threats are: communication ports can be changed or added data can be copied malware can be installed at multiple levels (Bios, Firmware, OS) user accounts and privileges can be added, changed or deleted device configuration can be changed ports are “discoverable” making them targets for malicious actors (c) 2013 Dr. Joseph B. Baugh

Part 1.2 Physical Ports physical I/O ports Network Serial
CIP-101 September 24-25, 2013 Part 1.2 Physical Ports physical I/O ports Network Serial USB ports external to the device casing accidental use such as connecting a modem, connecting a network cable that bridges networks, or inserting a USB drive. (c) 2013 Dr. Joseph B. Baugh

Part 1.2 Physical Ports All ports should be either secured or disabled
CIP-101 September 24-25, 2013 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 not use the verb “prevent” (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 inclusion of means such as signage, is not meant to be a preventative control against intruders. Signage is indeed a directive control, not a preventative one. Once physical access has been achieved through the other preventative and detective measures by authorized personnel, a directive control that outlines proper behavior as a last line of defense are appropriate in these highest risk areas. (c) 2013 Dr. Joseph B. Baugh

Port Locks

Physical Access to Ports
CIP-101 September 24-25, 2013 Physical Access to Ports (c) 2013 Dr. Joseph B. Baugh

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

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

Physical Ports and Applicable Systems
CIP-101 September 24-25, 2013 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 So although a Cyber Asset may indeed be a BES Cyber Asset, if all communication ports are disabled then the BES Cyber Asset would have no External Routable Connectivity or dial-up connectivity and thus none of the requirements which have that condition in the applicability column would apply. SDT notes that BES Cyber Systems consist of one or more BES Cyber Assets, not every programmable electronic device. No language in applicability of ‘and their associated: EACM, PACS and PCA. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 CIP Part 2.1 ???Need a process – Recommened to not just repeat the standard, but address your environment. Process can be on BCS but installing on a BCA level managing patches on all Cyber Assets is a best practice, making this a mandatory and auditable requirement would divert the industry’s attention to managing an onerous burden of records on orders of magnitude more devices at the lowest impact level. SDT has been careful to balance what is absolutely required in a mandatory and enforceable manner and the burden of proof such a change would entail with maintaining a high degree of industry focus on the higher risk assets. If we overburden the Low impact classes, it would be easy to divert an inordinate amount of industry focus to the lowest impact assets if we don’t maintain that balance. The SDT also believes that many devices will probably have some portion of the population declared as medium impact and thus many entities will need to handle any vulnerabilities on those devices and oftentimes will just patch all devices of that type. R3. Security Patch Management — The Responsible Entity, either separately or as a component of the documented configuration management process specified in CIP Requirement R6, shall establish, document and implement a security patch management program for tracking, evaluating, testing, and installing applicable cyber security software patches for all Cyber Assets within the Electronic Security Perimeter(s). R3.1. The Responsible Entity shall document the assessment of security patches and security upgrades for applicability within thirty calendar days of availability of the patches or upgrades. R3.2. The Responsible Entity shall document the implementation of security patches. In any case where the patch is not installed, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure. Asset level requirement (c) 2013 Dr. Joseph B. Baugh

CIP-007-3  CIP-007-5 Change CIP-007-3 CIP-007-5
No time frames to implement patches Patch management required actions and timelines (R2)

Part 2.1 Patch Management Process
CIP-101 September 24-25, 2013 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 A sound defense-in-depth security strategy employs additional measures such as physical security, malware prevention software, and software patch management to reduce the introduction of malicious code or the exploit of known vulnerabilities. Concerning process Don’t get caught in just using language of the standard as the process Be specific so it is repeatable … with explected results Many patches may address vulnerabilities that the entity has already mitigated through existing means and require no action. In fact, it is expected that the lack of external routable connectivity would be used as a major factor in many applicability decisions and/or mitigation plans where that is the case. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 In version 3 process essentially required entity to always be tracking individual patches for applcability (c) 2013 Dr. Joseph B. Baugh

Tracking for Applicability
CIP-101 September 24-25, 2013 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 vendor who invalidates support contracts if the system is patched outside of their approval, then the vendor should be the appropriate source. If the system were custom built by the Responsible Entity, then the vendor for each of the components used to build the system would be the appropriate source. (c) 2013 Dr. Joseph B. Baugh

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

Sources

Patch Update Issues Cyber Security focused
CIP-101 September 24-25, 2013 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 R1.1.5) Operating system/firmware, commercially available software or open-source application software, custom software rewards obsolescence and never requires upgrading to a patchable system. In response, the SDT notes that the standard’s intent is to secure the infrastructure that is in place without requiring equipment upgrades of currently functional equipment solely for security purposes. Cyber security risks are one factor in the decision to upgrade. The SDT also notes that cyber risk is determined by many factors, and older equipment could actually have a lower cyber security risk. These decisions are best left to the Responsible Entity to make based on the specific circumstances rather than mandated unilaterally in a cyber security standard. (c) 2013 Dr. Joseph B. Baugh

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

‘that are updateable’

CIP-101 September 24-25, 2013 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 I have yet to approve a TFE based on excessive cost... I don't expect that will change with XP. -kevin- Sent from my iPhone On Mar 28, 2014, at 1:35 PM, "Dodd, Rick" wrote: Microsoft is fact offering Premium Customer Support. So, shouldn’t the Entity be required to file a TFE to request exclusion if they feel the support “vi) would require the incurrence of costs that, in the determination of the Regional Entity, far exceed the benefits to the reliability of the Bulk Electric System”? Would think we should be requiring the Entity to justify the TFE on this basis and provide the numbers to back it up. Gartner report Some background information on Microsoft Custom Support. “It's worth repeating these patches aren't for everyone, or, in fact, almost anyone. To get these custom patches, users need an active Premier Support agreement, a Microsoft spokesperson reiterated. On top of that, you need to purchase Custom Support. The combo is costly. For many, other than those in Fortune 500 companies, who are still running Windows XP, it's probably outside the realm of possibility.” Microsoft Support Lifecycle: If you have any questions, please let me know. Thanks, Florida Reliability Coordinating Council Office: Compliance Enforcement Specialist Rick Dodd - CISSP This and any of its attachments may contain FRCC proprietary information that is privileged, confidential, or subject to copyright belonging to FRCC. This is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this , you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this is strictly prohibited and may be unlawful. If you receive this in error, please notify the sender immediately and permanently delete the original and any copy of this and any printout. <image002.jpg> From:  Sent: Friday, March 28, :21 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th It seems given Lew’s response: CIP-007 R3 (Patch Management) As long as they have (assessed) all the patches/service packs up to April 8th the entity will be in compliance if they are still using Windows XP. CIP-007 R4 (Anti-Virus) As long as they have anti-virus/malware implemented and all signatures are up to date they will be in compliance if they are still using Windows XP. However, I think there may be an issue when Anti-virus/malware prevention tool companies’ products stop supporting Windows XP. Likely, this would not be an issue for another year. Could this be a TFE issue? CIP-007 R8 (Cyber Vulnerability Assessment) I assume any vulnerabilities found would be tied back to the reasoning within CIP-007 R3. i.e. you cannot fix what you cannot patch. Therefore they would be keeping within compliance. The only exception that I would see to this is when third-party software outside the Operating System is found to be vulnerable. This is when something additional would need to be addressed from within the entity’s vulnerability assessment process. Judging by the responses from this message so far, it seems that the parameters are clear for V3. Any issues that could happen with CIP-007 R4 from a TFE issue would be at least another year out or more depending on what anti-virus/malware prevention companies decide to do. Thank you for the feedback! David Sopata – CISA, CISSP, ISO 27001 <image003.png> NEW ADDRESS AND PHONE NUMBER: CIP Auditor Main Number: Cleveland, OH 44131 3 Summit Park Drive, Suite 600 Direct Dial: | Cell: (330) Forward Together • ReliabilityFirst From: Tom Hofstetter  Sent: Friday, March 28, :47 AM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Do we need consensus on a common audit approach for XP-based systems, or are the parameters of the v3 clear enough? Are there TFE ramifications that entities could/should address in connection with systems that continue to rely on XP after 4/8? From: Kevin Perry  Sent: Thursday, March 27, :08 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th I agree with Lew. Southwest Power Pool Regional Entity Director, Critical Infrastructure Protection Kevin B. Perry, CISA, CRISC kperry.re<at>spp<dot>org Cell: (501) Voice: (501) SMS Text: <at>vtext<dot>com From:  Sent: Thursday, March 27, :17 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Dave, Here’s my personal opinion on the XP obsolescence issue: First, from a strict compliance perspective: As of April 2014 there will be no more security patches forthcoming for XP. The entity will have no patches to assess or apply. There cannot be a violation unless the entity does not assess a patch for applicability within 30 days, or the entity does not implement the patch or compensating measures if the patch is not implemented. No patches issued means no action required by the entity. TFEs are only needed if a patch cannot be applied. CIP R2 works in a similar manner. I don’t like this answer, but we have to work with the tools (the language of the Requirements) that we’re given. Second, from a cyber security and risk perspective: A utility that continues to use XP within an ESP without establishing significant protections for these systems will probably be viewed as an elevated risk to the BES. This perception of increased risk can have significant impact on the entity. Audits of such entities may be broader, deeper, and more frequent. As RAI moves forward, such an entity’s internal controls may be assessed more frequently and in greater depth. Audit findings, while not able to write violations on this issue, will almost certainly return Areas of Concern which the entity ignores at its peril. Some basic mitigating actions are identified in the March issue of OUCH!: Lew Lew Folkerth, PE, CISSP, CISA Office ReliabilityFirst Corporation Principal CIP Auditor Cell Any opinions expressed are my own and not those of ReliabilityFirst or its management. From:  Sent: Wednesday, March 26, :54 PM To: ccwg Subject: Just a friendly reminder: Windows XP will be end of Life April 8th Hello Everyone, Just a friendly reminder, Windows XP will be end of Life as of April 8th. There are a few questions that I have for the group that I thought entities may be asking us during our audits. · How does this affect/impact compliance to CIP v3, the transition guidance to CIP v5, CIP v5, and TFEs? · What questions should auditors be asking during audit when they run into systems that are still using XP or older Windows Operating Systems? · What should we say as auditors when responding back to entities when they say “What can we do? We will not be migrating away from Windows XP for another 2 + years. “ ? Right away for CIP v3, I see potential issues with the following requirements: · CIP R3, R3.1, and R3.2 Because Microsoft has stopped support for Windows XP, this also means that Microsoft has stopped creating patches for this OS. Which means, that if there is a vulnerability that is sweeping across all versions of Windows OSs the Windows XP patch will not be created. Therefore, Older OSs will be left vulnerable without a way to patch. · CIP R4, R4.1, and R4.2 Many Anti-virus companies will only support Windows XP for another year or so. Here is an article speaking to that. One mitigating control that I could see would be Whitelisting, Host Intrusion Protection Systems (HIPS), and/or File-integrity monitoring (FIM) solutions that would be used as a form of anti-malware protection. The idea would be that you would be able to detect or prevent system files from being modified and only allow application that are known and trusted to be executed. CIP R8, R8.4 Because these systems can no longer be patched, many vulnerability scanning software systems will likely trigger on these vulnerabilities and will only provide the recommendation to upgrade to a newer OS. This will likely create a laundry list of vulnerability mitigation plan efforts. Any thoughts? CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential, privileged or subject to copyright belonging to ReliabilityFirst Corporation. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this electronic message is strictly prohibited and may be unlawful. If you have received this message in error, please notify the sender immediately and permanently delete the original and any copy of this electronic message. Y ---  This and any attachments are confidential. They may contain legal, professional, proprietary and/or other privileged information. They also may contain information that is subject to copyright belonging to NERC. This and any attachments are intended solely for the addressee(s). If you are not the intended recipient, do not use the information in this in any way, permanently delete this and any attachments and notify the sender immediately. Warning: This comes from an external sender. Be cautious when opening URLs or attachments from external senders. (c) 2013 Dr. Joseph B. Baugh

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)

CIP-101 September 24-25, 2013 Windows XP (EOL ) 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 I have yet to approve a TFE based on excessive cost... I don't expect that will change with XP. -kevin- Sent from my iPhone On Mar 28, 2014, at 1:35 PM, "Dodd, Rick" wrote: Microsoft is fact offering Premium Customer Support. So, shouldn’t the Entity be required to file a TFE to request exclusion if they feel the support “vi) would require the incurrence of costs that, in the determination of the Regional Entity, far exceed the benefits to the reliability of the Bulk Electric System”? Would think we should be requiring the Entity to justify the TFE on this basis and provide the numbers to back it up. Gartner report Some background information on Microsoft Custom Support. “It's worth repeating these patches aren't for everyone, or, in fact, almost anyone. To get these custom patches, users need an active Premier Support agreement, a Microsoft spokesperson reiterated. On top of that, you need to purchase Custom Support. The combo is costly. For many, other than those in Fortune 500 companies, who are still running Windows XP, it's probably outside the realm of possibility.” Microsoft Support Lifecycle: If you have any questions, please let me know. Thanks, Florida Reliability Coordinating Council Office: Compliance Enforcement Specialist Rick Dodd - CISSP This and any of its attachments may contain FRCC proprietary information that is privileged, confidential, or subject to copyright belonging to FRCC. This is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this , you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this is strictly prohibited and may be unlawful. If you receive this in error, please notify the sender immediately and permanently delete the original and any copy of this and any printout. <image002.jpg> From:  Sent: Friday, March 28, :21 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th It seems given Lew’s response: CIP-007 R3 (Patch Management) As long as they have (assessed) all the patches/service packs up to April 8th the entity will be in compliance if they are still using Windows XP. CIP-007 R4 (Anti-Virus) As long as they have anti-virus/malware implemented and all signatures are up to date they will be in compliance if they are still using Windows XP. However, I think there may be an issue when Anti-virus/malware prevention tool companies’ products stop supporting Windows XP. Likely, this would not be an issue for another year. Could this be a TFE issue? CIP-007 R8 (Cyber Vulnerability Assessment) I assume any vulnerabilities found would be tied back to the reasoning within CIP-007 R3. i.e. you cannot fix what you cannot patch. Therefore they would be keeping within compliance. The only exception that I would see to this is when third-party software outside the Operating System is found to be vulnerable. This is when something additional would need to be addressed from within the entity’s vulnerability assessment process. Judging by the responses from this message so far, it seems that the parameters are clear for V3. Any issues that could happen with CIP-007 R4 from a TFE issue would be at least another year out or more depending on what anti-virus/malware prevention companies decide to do. Thank you for the feedback! David Sopata – CISA, CISSP, ISO 27001 <image003.png> NEW ADDRESS AND PHONE NUMBER: CIP Auditor Main Number: Cleveland, OH 44131 3 Summit Park Drive, Suite 600 Direct Dial: | Cell: (330) Forward Together • ReliabilityFirst From: Tom Hofstetter  Sent: Friday, March 28, :47 AM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Do we need consensus on a common audit approach for XP-based systems, or are the parameters of the v3 clear enough? Are there TFE ramifications that entities could/should address in connection with systems that continue to rely on XP after 4/8? From: Kevin Perry  Sent: Thursday, March 27, :08 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th I agree with Lew. Southwest Power Pool Regional Entity Director, Critical Infrastructure Protection Kevin B. Perry, CISA, CRISC kperry.re<at>spp<dot>org Cell: (501) Voice: (501) SMS Text: <at>vtext<dot>com From:  Sent: Thursday, March 27, :17 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Dave, Here’s my personal opinion on the XP obsolescence issue: First, from a strict compliance perspective: As of April 2014 there will be no more security patches forthcoming for XP. The entity will have no patches to assess or apply. There cannot be a violation unless the entity does not assess a patch for applicability within 30 days, or the entity does not implement the patch or compensating measures if the patch is not implemented. No patches issued means no action required by the entity. TFEs are only needed if a patch cannot be applied. CIP R2 works in a similar manner. I don’t like this answer, but we have to work with the tools (the language of the Requirements) that we’re given. Second, from a cyber security and risk perspective: A utility that continues to use XP within an ESP without establishing significant protections for these systems will probably be viewed as an elevated risk to the BES. This perception of increased risk can have significant impact on the entity. Audits of such entities may be broader, deeper, and more frequent. As RAI moves forward, such an entity’s internal controls may be assessed more frequently and in greater depth. Audit findings, while not able to write violations on this issue, will almost certainly return Areas of Concern which the entity ignores at its peril. Some basic mitigating actions are identified in the March issue of OUCH!: Lew Lew Folkerth, PE, CISSP, CISA Office ReliabilityFirst Corporation Principal CIP Auditor Cell Any opinions expressed are my own and not those of ReliabilityFirst or its management. From:  Sent: Wednesday, March 26, :54 PM To: ccwg Subject: Just a friendly reminder: Windows XP will be end of Life April 8th Hello Everyone, Just a friendly reminder, Windows XP will be end of Life as of April 8th. There are a few questions that I have for the group that I thought entities may be asking us during our audits. · How does this affect/impact compliance to CIP v3, the transition guidance to CIP v5, CIP v5, and TFEs? · What questions should auditors be asking during audit when they run into systems that are still using XP or older Windows Operating Systems? · What should we say as auditors when responding back to entities when they say “What can we do? We will not be migrating away from Windows XP for another 2 + years. “ ? Right away for CIP v3, I see potential issues with the following requirements: · CIP R3, R3.1, and R3.2 Because Microsoft has stopped support for Windows XP, this also means that Microsoft has stopped creating patches for this OS. Which means, that if there is a vulnerability that is sweeping across all versions of Windows OSs the Windows XP patch will not be created. Therefore, Older OSs will be left vulnerable without a way to patch. · CIP R4, R4.1, and R4.2 Many Anti-virus companies will only support Windows XP for another year or so. Here is an article speaking to that. One mitigating control that I could see would be Whitelisting, Host Intrusion Protection Systems (HIPS), and/or File-integrity monitoring (FIM) solutions that would be used as a form of anti-malware protection. The idea would be that you would be able to detect or prevent system files from being modified and only allow application that are known and trusted to be executed. CIP R8, R8.4 Because these systems can no longer be patched, many vulnerability scanning software systems will likely trigger on these vulnerabilities and will only provide the recommendation to upgrade to a newer OS. This will likely create a laundry list of vulnerability mitigation plan efforts. Any thoughts? CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential, privileged or subject to copyright belonging to ReliabilityFirst Corporation. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this electronic message is strictly prohibited and may be unlawful. If you have received this message in error, please notify the sender immediately and permanently delete the original and any copy of this electronic message. Y ---  This and any attachments are confidential. They may contain legal, professional, proprietary and/or other privileged information. They also may contain information that is subject to copyright belonging to NERC. This and any attachments are intended solely for the addressee(s). If you are not the intended recipient, do not use the information in this in any way, permanently delete this and any attachments and notify the sender immediately. Warning: This comes from an external sender. Be cautious when opening URLs or attachments from external senders. (c) 2013 Dr. Joseph B. Baugh

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

CIP-101 September 24-25, 2013 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 I have yet to approve a TFE based on excessive cost... I don't expect that will change with XP. -kevin- Sent from my iPhone On Mar 28, 2014, at 1:35 PM, "Dodd, Rick" wrote: Microsoft is fact offering Premium Customer Support. So, shouldn’t the Entity be required to file a TFE to request exclusion if they feel the support “vi) would require the incurrence of costs that, in the determination of the Regional Entity, far exceed the benefits to the reliability of the Bulk Electric System”? Would think we should be requiring the Entity to justify the TFE on this basis and provide the numbers to back it up. Gartner report Some background information on Microsoft Custom Support. “It's worth repeating these patches aren't for everyone, or, in fact, almost anyone. To get these custom patches, users need an active Premier Support agreement, a Microsoft spokesperson reiterated. On top of that, you need to purchase Custom Support. The combo is costly. For many, other than those in Fortune 500 companies, who are still running Windows XP, it's probably outside the realm of possibility.” Microsoft Support Lifecycle: If you have any questions, please let me know. Thanks, Florida Reliability Coordinating Council Office: Compliance Enforcement Specialist Rick Dodd - CISSP This and any of its attachments may contain FRCC proprietary information that is privileged, confidential, or subject to copyright belonging to FRCC. This is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this , you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this is strictly prohibited and may be unlawful. If you receive this in error, please notify the sender immediately and permanently delete the original and any copy of this and any printout. <image002.jpg> From:  Sent: Friday, March 28, :21 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th It seems given Lew’s response: CIP-007 R3 (Patch Management) As long as they have (assessed) all the patches/service packs up to April 8th the entity will be in compliance if they are still using Windows XP. CIP-007 R4 (Anti-Virus) As long as they have anti-virus/malware implemented and all signatures are up to date they will be in compliance if they are still using Windows XP. However, I think there may be an issue when Anti-virus/malware prevention tool companies’ products stop supporting Windows XP. Likely, this would not be an issue for another year. Could this be a TFE issue? CIP-007 R8 (Cyber Vulnerability Assessment) I assume any vulnerabilities found would be tied back to the reasoning within CIP-007 R3. i.e. you cannot fix what you cannot patch. Therefore they would be keeping within compliance. The only exception that I would see to this is when third-party software outside the Operating System is found to be vulnerable. This is when something additional would need to be addressed from within the entity’s vulnerability assessment process. Judging by the responses from this message so far, it seems that the parameters are clear for V3. Any issues that could happen with CIP-007 R4 from a TFE issue would be at least another year out or more depending on what anti-virus/malware prevention companies decide to do. Thank you for the feedback! David Sopata – CISA, CISSP, ISO 27001 <image003.png> NEW ADDRESS AND PHONE NUMBER: CIP Auditor Main Number: Cleveland, OH 44131 3 Summit Park Drive, Suite 600 Direct Dial: | Cell: (330) Forward Together • ReliabilityFirst From: Tom Hofstetter  Sent: Friday, March 28, :47 AM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Do we need consensus on a common audit approach for XP-based systems, or are the parameters of the v3 clear enough? Are there TFE ramifications that entities could/should address in connection with systems that continue to rely on XP after 4/8? From: Kevin Perry  Sent: Thursday, March 27, :08 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th I agree with Lew. Southwest Power Pool Regional Entity Director, Critical Infrastructure Protection Kevin B. Perry, CISA, CRISC kperry.re<at>spp<dot>org Cell: (501) Voice: (501) SMS Text: <at>vtext<dot>com From:  Sent: Thursday, March 27, :17 PM To: ccwg Subject: RE: Just a friendly reminder: Windows XP will be end of Life April 8th Dave, Here’s my personal opinion on the XP obsolescence issue: First, from a strict compliance perspective: As of April 2014 there will be no more security patches forthcoming for XP. The entity will have no patches to assess or apply. There cannot be a violation unless the entity does not assess a patch for applicability within 30 days, or the entity does not implement the patch or compensating measures if the patch is not implemented. No patches issued means no action required by the entity. TFEs are only needed if a patch cannot be applied. CIP R2 works in a similar manner. I don’t like this answer, but we have to work with the tools (the language of the Requirements) that we’re given. Second, from a cyber security and risk perspective: A utility that continues to use XP within an ESP without establishing significant protections for these systems will probably be viewed as an elevated risk to the BES. This perception of increased risk can have significant impact on the entity. Audits of such entities may be broader, deeper, and more frequent. As RAI moves forward, such an entity’s internal controls may be assessed more frequently and in greater depth. Audit findings, while not able to write violations on this issue, will almost certainly return Areas of Concern which the entity ignores at its peril. Some basic mitigating actions are identified in the March issue of OUCH!: Lew Lew Folkerth, PE, CISSP, CISA Office ReliabilityFirst Corporation Principal CIP Auditor Cell Any opinions expressed are my own and not those of ReliabilityFirst or its management. From:  Sent: Wednesday, March 26, :54 PM To: ccwg Subject: Just a friendly reminder: Windows XP will be end of Life April 8th Hello Everyone, Just a friendly reminder, Windows XP will be end of Life as of April 8th. There are a few questions that I have for the group that I thought entities may be asking us during our audits. · How does this affect/impact compliance to CIP v3, the transition guidance to CIP v5, CIP v5, and TFEs? · What questions should auditors be asking during audit when they run into systems that are still using XP or older Windows Operating Systems? · What should we say as auditors when responding back to entities when they say “What can we do? We will not be migrating away from Windows XP for another 2 + years. “ ? Right away for CIP v3, I see potential issues with the following requirements: · CIP R3, R3.1, and R3.2 Because Microsoft has stopped support for Windows XP, this also means that Microsoft has stopped creating patches for this OS. Which means, that if there is a vulnerability that is sweeping across all versions of Windows OSs the Windows XP patch will not be created. Therefore, Older OSs will be left vulnerable without a way to patch. · CIP R4, R4.1, and R4.2 Many Anti-virus companies will only support Windows XP for another year or so. Here is an article speaking to that. One mitigating control that I could see would be Whitelisting, Host Intrusion Protection Systems (HIPS), and/or File-integrity monitoring (FIM) solutions that would be used as a form of anti-malware protection. The idea would be that you would be able to detect or prevent system files from being modified and only allow application that are known and trusted to be executed. CIP R8, R8.4 Because these systems can no longer be patched, many vulnerability scanning software systems will likely trigger on these vulnerabilities and will only provide the recommendation to upgrade to a newer OS. This will likely create a laundry list of vulnerability mitigation plan efforts. Any thoughts? CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential, privileged or subject to copyright belonging to ReliabilityFirst Corporation. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this electronic message is strictly prohibited and may be unlawful. If you have received this message in error, please notify the sender immediately and permanently delete the original and any copy of this electronic message. Y ---  This and any attachments are confidential. They may contain legal, professional, proprietary and/or other privileged information. They also may contain information that is subject to copyright belonging to NERC. This and any attachments are intended solely for the addressee(s). If you are not the intended recipient, do not use the information in this in any way, permanently delete this and any attachments and notify the sender immediately. Warning: This comes from an external sender. Be cautious when opening URLs or attachments from external senders. (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 Part 2.2 Patch Evaluation
Asset level requirement

CIP-101 September 24-25, 2013 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 Are you reviewing your sources also? (c) 2013 Dr. Joseph B. Baugh

Part 2.2 Patch Evaluation

CIP-101 September 24-25, 2013 Guidelines DHS “Quarterly Report on Cyber Vulnerabilities of Potential Risk to Control Systems” “Recommended Practice for Patch Management of Control Systems” guidance on an evaluative process (c) 2013 Dr. Joseph B. Baugh

Vulnerability Footprint
CIP-101 September 24-25, 2013 Vulnerability Footprint Determination that a security related patch, hotfix, and/or update poses too great a risk to install on a system or is not applicable due to the system configuration should not require a TFE. (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 Part 2.3 [Patch Response]
CIP-101 September 24-25, 2013 CIP 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? Install patch NO YES Within 35 days Create Mitigation plan Update Mitigation plan OR Implement Plan within time frame R2.3 For applicable patches identified in Part 2.2, within 35 calendar days of the evaluation completion, take one of the following actions:  Apply the applicable patches; or  Create a dated mitigation plan; or  Revise an existing mitigation plan. Mitigation plans shall include the Responsible Entity’s planned actions to mitigate the vulnerabilities addressed by each security patch and a timeframe to complete these mitigations. Measures: Examples of evidence may include, but are not limited to:  Records of the installation of the patch (e.g., exports from automated patch management tools that provide installation date, verification of BES Cyber System Component software revision, or registry exports that show software has been installed); or  A dated plan showing when and how the vulnerability will be addressed, to include documentation of the actions to be taken by the Responsible Entity to mitigate the vulnerabilities addressed by the security patch and a timeframe for the completion of these mitigations. Asset level requirement (c) 2013 Dr. Joseph B. Baugh

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.

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

CIP-101 September 24-25, 2013 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 SDT has decided that the reliability risk of putting prescriptive and mandatory timeframes for patching outweigh the risks of having an open-ended patching timeframe. One reason is the industry goes through periods of time during seasons of the year that we refer to as “nobody is touching nothing” mode because the risk of any change to equipment or systems invokes an availability risk when the asset is depended upon the most. Tripping a generating unit on a 100-degree day because a standard said we were out of time to patch it to fix some minor issue is not acceptable. Another reason is we are in a largely legacy equipment environment as this standard expands outside of control centers where there are no patch management solutions. (c) 2013 Dr. Joseph B. Baugh

Timeframes Guidelines
CIP-101 September 24-25, 2013 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” SDT has decided that the reliability risk of putting prescriptive and mandatory timeframes for patching outweigh the risks of having an open-ended patching timeframe. One reason is the industry goes through periods of time during seasons of the year that we refer to as “nobody is touching nothing” mode because the risk of any change to equipment or systems invokes an availability risk when the asset is depended upon the most. Tripping a generating unit on a 100-degree day because a standard said we were out of time to patch it to fix some minor issue is not acceptable. Another reason is we are in a largely legacy equipment environment as this standard expands outside of control centers where there are no patch management solutions. (c) 2013 Dr. Joseph B. Baugh

CIP-007-5 Part 2.4 [Mitigation Plan]
CIP-101 September 24-25, 2013 CIP 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? Within 35 days YES NO R2.3 R2.4 For each mitigation plan created or revised in Part 2.3, implement the plan within the timeframe specified in the plan, unless a revision to the plan or an extension to the timeframe specified in Part 2.3 is approved by the CIP Senior Manager or delegate. Measures: An example of evidence may include, but is not limited to, records of implementation of mitigations. Implement Plan within time frame CIP SM or Delegate approval Plan Revision or Extension? Install patch OR Create Mitigation plan OR YES Update Mitigation plan R2.4 (c) 2013 Dr. Joseph B. Baugh

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

CIP-101 September 24-25, 2013 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 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. A measure to address a software vulnerability may involve disabling a particular service. That same service may be exploited through other software vulnerabilities. Therefore disabling the single service has addressed multiple patched vulnerabilities. (c) 2013 Dr. Joseph B. Baugh

Part 2.3 Mitigation Guidelines
CIP-101 September 24-25, 2013 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 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. A measure to address a software vulnerability may involve disabling a particular service. That same service may be exploited through other software vulnerabilities. Therefore disabling the single service has addressed multiple patched vulnerabilities. A measure to address a software vulnerability may involve disabling a particular service. That same service may be exploited through other software vulnerabilities. Therefore disabling the single service has addressed multiple patched vulnerabilities. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 No double jeopardy (c) 2013 Dr. Joseph B. Baugh

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

Proposed CIP-007 R2.5

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

CIP-007-5 Part 3.1 BES Cyber System level requirement
CIP-101 September 24-25, 2013 CIP Part 3.1 Multiple commenters suggested that the applicability should change to all medium impact with ERC. In response, the SDT disagrees because the threat of malicious code is not limited to introduction through external routable connectivity. The threat of malicious code is arguably higher from portable media, temporarily connected cyber assets (vendor laptops, etc) and inadvertent insider actions. SDT Entities should also have awareness of malware protection requirements for Transient Cyber Assets and Removable Media (“transient devices”) in CIP The protections required here in CIP Requirement R3 complement but do not meet the additional obligations for transient devices. Important to note its about BCS without ERC the threat of malicious code is not limited to introduction through external routable connectivity. The threat of malicious code is arguably higher from portable media, temporarily connected cyber assets (vendor laptops, etc) and inadvertent insider actions. R4. Malicious Software Prevention — The Responsible Entity shall use anti-virus software and other malicious software (“malware”) prevention tools, where technically feasible, to detect, prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber Assets within the Electronic Security Perimeter(s). R4.1. The Responsible Entity shall document and implement anti-virus and malware prevention tools. In the case where anti-virus software and malware prevention tools are not installed, the Responsible Entity shall document compensating measure(s) applied to mitigate risk exposure. R4.2. The Responsible Entity shall document and implement a process for the update of anti-virus and malware prevention “signatures.” The process must address testing and installing the signatures. BES Cyber System level requirement (c) 2013 Dr. Joseph B. Baugh

CIP-007-3  CIP-007-5 Change CIP-007-3 CIP-007-5
CIP-101 September 24-25, 2013 CIP  CIP Change CIP-007-3 CIP-007-5 AV on ALL cyber assets or TFE Malicious code controls can be at cyber system level, rather than per asset (R3) All previous versions of the standard did prescribe a particular technology and method that must be used on all applicable cyber assets, and while that had no vagueness it became a huge burden on the industry for TFE’s, putting the industry’s focus on what could not be done rather than what could be done. T Malicious code protection is at the ‘forefront of the fight’ and is rapidly evolving and changing to match the ever changing and morphing threat. SDT believes the protection of our infrastructure can be better accomplished if we do not have prescriptive technical methods detailed in this requirement. This could have the unintended effect in the future of stifling innovation and the use of new and better tools that would provide better protection but not be compliant with what the SDT would specify today. It does not produce a standard that is future-proof. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 In this ‘arms race’ of malware Requirement does not prescribe how malware is to be addressed on each Cyber Asset. (c) 2013 Dr. Joseph B. Baugh

AV/Anti-Malware

Defense-N-Depth

Application Whitelisting
CIP-101 September 24-25, 2013 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 How to implement application whitelisting Application whitelisting is commonly implemented using a combination of a software product for identifying and approving necessary executable and library files, and Access Control Lists preventing users from changing the approved files. AppLocker is a set of group policy settings which are present in Microsoft Windows 7. Extending the capabilities of Software Restriction Policies in earlier versions of Windows, AppLocker allows multiple levels of enforcement as well as several methods of recognising whitelisted executables. Both AppLocker and Software Restriction Policies are free application whitelisting products that are provided with recent versions of Microsoft Windows. There are a number of third party applications which provide similar functionality to AppLocker. Mention of these products does not imply endorsement by DSD. Among these are products such as Bit9 Parity Suite, CoreTrace Bouncer, Lumension Application Control and McAfee Application Control. It is crucial that the software selected and configuration used covers both executables and software libraries. An omission of either of those could negate the security afforded by the whitelisting implementation. Whitelisted executables should be positively identified via means other than merely by file name or directory location. This helps ensure malware cannot trivially masquerade as legitimate software. (c) 2013 Dr. Joseph B. Baugh

Application Whitelisting
CIP-101 September 24-25, 2013 Application Whitelisting Application File Attributes Digital Certificates File Hash File Ownership Location Reference Systems Signed Security Catalogs Software Packages Advanced threats use many methods to infiltrate an organization including zero-day vulnerabilities. According to research by Symantec, the average time for detection of zero-day vulnerabilities is 300 days. Zero-day attacks are used against specific targets making them difficult to detect. In situations where traditional antivirus products are used, they may be configured to automatically remove or quarantine the malicious code. In white-listing situations, the white-listing tool itself can mitigate the threat as Page 54 of 67 Guidelines and Technical Basis it will not allow the code to execute, however steps should still be taken to remove the malicious code from the Cyber Asset. In some instances, it may be in the best interest of reliability to not immediately remove or quarantine the malicious code, such as when availability of the system may be jeopardized by removal while operating and a rebuild of the system needs to be scheduled. In that case, monitoring may be increased and steps taken to insure the malicious code cannot communicate with other systems. (c) 2013 Dr. Joseph B. Baugh

Virtual Systems What about vendor products like Vmware’s vShield Endpoint? vShield Endpoint Offloads the A/V from within the VMs to the Hypervisor and uses introspection at hypervisor Introspection - ability to monitor each guest OS as it is running And know exactly what is happening within the VM And this is done through APIs (application programming interfaces) So Instead of running 50 VMs on a Hypervisor and 50 A/V agents inside of those VMs that could get rolled back to an outdated version b/c of a snapshot rollback and loose all your current A/V signatures Offloading the AV to the hypervisor can help ensure before a VM even powers up it’s A/V is updated and scanned Eliminates the risk of A/V Storms in Virtual environment Our audit approach is that this meets the language of the CIP-007 R4 requirement Again WECC Is not endorsing this product, but simply Showing there are solutions out there.

Guidelines Network isolation techniques
CIP-101 September 24-25, 2013 Guidelines Network isolation techniques Portable storage media policies Intrusion Detection/Prevention (IDS/IPS) solutions SDT is working on stripping a lot from Guidelines and technical bases .. (c) 2013 Dr. Joseph B. Baugh

Part 3.1 Malicious Code Is an awareness campaign to deter ok?
CIP-101 September 24-25, 2013 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 In this ‘arms race’ of malware malware detection and prevention is an inexact science and essentially an ‘arms race’, the SDT did not want to word the requirement in such a way that it required perfection in an imperfect environment with imperfect tools. despite an entity’s best efforts if some zero-day malware did make it onto an applicable cyber asset the entity would be in violation of the requirement. but the requirement is to mitigate the threat posed by the now identified malicious code. (c) 2013 Dr. Joseph B. Baugh

‘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

CIP R3.2 BES Cyber System level requirement

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

CIP R3.3 BES Cyber System level requirement

Requires process for updates
CIP-101 September 24-25, 2013 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 Other anomaly or heuristics based analysis/detection, not just signature updates. In response, (c) 2013 Dr. Joseph B. Baugh

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?

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

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

CIP-007-5 Part 4.1 BES Cyber System and/or Asset level requirement
CIP-101 September 24-25, 2013 CIP Part 4.1 how is a BCA/BCS going to detect failed Access Attempts (HIPS) how does it differ or can leverage CIP R5 IDS? BES Cyber System and/or Asset level requirement (c) 2013 Dr. Joseph B. Baugh

CIP-007-3  CIP-007-5 Change CIP-007-3 CIP-007-5 Security logs
Identification of specific log collection events (R4) Sampling and or summarization not mentioned Log reviews for High impact Cyber Systems can be summarization or sampling (R4) CIP-007-3 CIP-007-5 Log reviews every 90 days when applicable Log reviews for High Impact Cyber Systems must be reviewed every 15 days (R4)

CIP-101 September 24-25, 2013 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 Specific security events already required in Version 4 of the CIP Standards carry forward in this version. A little bit of confusion here SDT commented to questions about logging being required for both local access at the BCS and remote access. Note applicable systems does note include ERC.. There fore do not have to log, but per R4.2 you have to alert remote access for medium with ERC. This goes to CIP R1.2 where an EAP is not required where there is no ERC. (c) 2013 Dr. Joseph B. Baugh

Part 4.1 Log Events Types of events
CIP-101 September 24-25, 2013 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 A little bit of confusion here SDT commented to questions about logging being required for both local access at the BCS and remote access. Note applicable systems does note include ERC.. There fore do not have to log, but per R4.2 you have to alert remote access for medium with ERC. This goes to CIP R1.2 where an EAP is not required where there is no ERC. (c) 2013 Dr. Joseph B. Baugh

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

CIP-101 September 24-25, 2013 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 threshold exceeded Virus or malware alerts system display and alarming (again the requirement talks about Alerting the guidance speaks to real-time alerting. From the guidance of CIP-007 unsuccessful login attempt threshold should be added as it is a requirement in CIP-007 R5.7 unsuccessful login attempt threshold should be added as it is a requirement in CIP-007 R5.7 and has made this addition. The SDT notes that account lockout is a subset (or post action) of unsuccessful login attempt threshold and has not included it. (c) 2013 Dr. Joseph B. Baugh

Part 4.2 Alerting Guidelines
CIP-101 September 24-25, 2013 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 From the guidance of CIP-007 states Real-Time Alerting, but the requirement just speaks to alerting not real-time. Note Guidelines speak a lot of Real-Time, but note it is not in the standard Again entity determines which computer generated events are necessary to log, provide alerts and monitor for their particular BES Cyber System environment. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 if malicious code gets through the layers of defense and makes it way on to a BES Cyber System, that is an event that needs the entity’s timely attention and response so the defenses can be shored up for the zero-day that is not detected and quarantined. (c) 2013 Dr. Joseph B. Baugh

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

CIP-101 September 24-25, 2013 CIP Part 4.3 – Part 4.4 media hardware failure that results in loss of stored logs is still a violation. In response, the SDT agrees and has added “except under CIP Exceptional Circumstances” to the requirement as it includes hardware failure. BES Cyber System and/or Cyber Asset (if supported) level requirement (c) 2013 Dr. Joseph B. Baugh

Part 4.3 ‘Retain Applicable Event Logs’
CIP-101 September 24-25, 2013 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 (c) 2013 Dr. Joseph B. Baugh

Part 4.3 ‘Retain Applicable Event Log’s’
CIP-101 September 24-25, 2013 Part 4.3 ‘Retain Applicable Event Log’s’ 4.3 Logs that are created under Part 4.1 are to be retained on the applicable Cyber Assets or BES Cyber Systems for at least 90 days. This is different than the evidence retention period called for in the CIP standards used to prove historical compliance. For such audit purposes, the entity should maintain evidence that shows that 90 days were kept historically. One example would be records of disposition of event logs beyond 90 days up to the evidence retention period. (c) 2013 Dr. Joseph B. Baugh

Part 4.3 ‘Retain Applicable Event Logs’
CIP-101 September 24-25, 2013 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 4.3 Logs that are created under Part 4.1 are to be retained on the applicable Cyber Assets or BES Cyber Systems for at least 90 days. This is different than the evidence retention period called for in the CIP standards used to prove historical compliance. For such audit purposes, the entity should maintain evidence that shows that 90 days were kept historically. One example would be records of disposition of event logs beyond 90 days up to the evidence retention period. (c) 2013 Dr. Joseph B. Baugh

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

CIP-101 September 24-25, 2013 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? this is a ‘tuning’ requirement to insure that an entity’s automated Security Information and Event Management (SIEM) type tools are not missing conditions that are appearing in the logs and going undetected. What if an entity identifies events in R 4.4 that should have been caught in R4.1 is this a violation? No R4.1 uses the word ‘detected’ R4.4 talks about a review It is a safety net an additional layer of defense. (c) 2013 Dr. Joseph B. Baugh

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

Cloud Computing Up to this point been talking about private cloud –

Monitoring-as-a-Service

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

CIP-007-3 CIP-007-5 Highlights
TFE required for devices that cannot meet password requirements Password requirement may be limited to device capabilities as opposed to filing TFE (R5) Not specified in V3 Failed access threshold and alerts (R5)

Part 5.1 Enforce Authentication
CIP-101 September 24-25, 2013 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 front panel read-outs do not qualify as interactive user access. Procedural Controls One commenter suggested, with regard to CAN-0017, procedural controls should be explicitly allowed in the requirement. However, the SDT points out that Compliance Application Notices do not carry forward to new versions of the standard. Previous versions require both procedural and technical controls for passwords, but this language is not included in the current draft. It would cause more confusion to explicitly allow procedural controls for each requirement part. (c) 2013 Dr. Joseph B. Baugh

Part 5.1 Enforce Authentication
CIP-101 September 24-25, 2013 Part 5.1 Enforce Authentication Not every Cyber Asset uses a GPO… local policy (c) 2013 Dr. Joseph B. Baugh

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

CIP Requirement 5.1.2

Part 5.3 Identify Individuals
CIP-101 September 24-25, 2013 Part 5.3 Identify Individuals CIP 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 Entities may choose to identify individuals with access to shared accounts through the access authorization and provisioning process, in which case the individual authorization records suffice to meet this Requirement Part. Alternatively, entities may choose to maintain a separate listing for shared accounts. Either form of evidence achieves the end result of maintaining control of shared accounts. (c) 2013 Dr. Joseph B. Baugh

CIP-101 September 24-25, 2013 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 Default passwords can be commonly published in vendor documentation that is readily available to all customers using that type of equipment and possibly published online. Page 57 of 67 Guidelines and Technical Basis The requirement option to have unique password addresses cases where the Cyber Asset generates or has assigned pseudo-random default passwords at the time of production or installation. In these cases, the default password does not have to change because the system or manufacturer created it specific to the Cyber Asset. (c) 2013 Dr. Joseph B. Baugh

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

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

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

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

Part 5.6 Password Changes Password change procedures
CIP-101 September 24-25, 2013 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 (c) 2013 Dr. Joseph B. Baugh

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 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’)

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

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

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

Compliance Outreach CIP v5 Roadshow

Similar presentations

Presentation on theme: "Compliance Outreach CIP v5 Roadshow"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Compliance Outreach CIP v5 Roadshow

Similar presentations

Presentation on theme: "Compliance Outreach CIP v5 Roadshow"— Presentation transcript:

Similar presentations

About project

Feedback