Morgan King
CISSP-ISSAP, CISA
Senior Compliance Auditor – Cyber Security
CIP-007-5
Compliance Outreach CIP v5 Roadshow
May 14-15, 2014
Salt Lake City, Utah
Agenda
•
•
•
•
•
2
CIP-007-5 Overview
New/Redefined Terminology
CIP-007-5 Audit Approach
Issues & Pitfalls
Questions
EMS ESP [IP network]
EMS Electronic Security Perimeter
Workstations
Printer
EMS WAN
File
Server
CIP-005
Router
Access
Control
Server
Switch
EAP
Firewall
CIP-007
CIP-005
Router
EAP
CorpNet
CCA
Firewall
Switch
Switch
DMZ
CCA
Printer
CCA
CCA
EACM
EACM
CCA
Intermediate
Server
3
CCA
Access
Control
Server
CCA
Workstations
CCA
EMS
Servers
EMS ESP/BCS [IP network]
EMS Electronic Security Perimeter
All PCA
devices take on
the impact level
of the BCS
File Server Non-BCS Workstations
PCA
PCA
Printer
PCA
PCA
Router
PCA
Switch
CIP-005
DMZ
CIP-005
BCA
Printer
Switch
CIP-002
CCA
BCA/PCA
PCA
BCA
BCA
EACM
EACM
Access
Control
Server
BCA
Workstations
BCA
Intermediate
Server
Firewall
BCA/PCARouter
Firewall
Switch
4
EAP
CIP-007
EAP
CorpNet
EMS WAN
BCA
BCA
EMS
Servers
Multi-BCS ESP
EMS Electronic Security Perimeter
BCS Server BCS Workstations
BCA
BCA
Printer
EMS WAN
PCA
BCA
Router
BCA
Switch
MEDIUM
CIP-005
EAP
CorpNet
Firewall
CIP-005
BCA/PCARouter
BCA
Firewall
Switch
DMZ
Printer
Switch
CIP-002
CCA
BCA/PCA
PCA
BCA
BCA
EACM
Intermediate
Server
EACM
Access
Control
Server
BCA
Workstations
BCA
5
EAP
CIP-007
BCA
BCA
EMS
Servers
HIGH
EMS ESP [High Water Mark]
EMS Electronic Security Perimeter
All PCA
devices take on
the impact level
of the BCS
BCS Server BCS Workstations
PCA
PCA
Printer
EMS WAN
PCA
PCA
Router
PCA
Switch
CIP-005
EAP
CIP-007
Firewall
HIGH
EAP
CorpNet
BCA
Firewall
Switch
DMZ
Printer
Switch
CIP-002
CCA
BCA/PCA
PCA
BCA
BCA
EACM
Intermediate
Server
EACM
Access
Control
Server
BCA
Workstations
BCA
6
CIP-005
BCA/PCARouter
BCA
BCA
EMS
Servers
V5 Compliance Dates
CIP Version 5 Effective Dates
Requirement
Effective Date
Effective Date of Standard
April 1, 2016
Requirement-Specific Effective Dates
CIP-002-5 R2
April 1, 2016
CIP-003-5 R1
April 1, 2016
CIP-003-5 R2
for medium and high impact BES Cyber
Systems
April 1, 2016
CIP-003-5 R2
for low impact BES Cyber Systems
April 1, 2017
CIP-007-5 Part 4.4
April 15, 2016
CIP-010-1 Part 2.1
May 6, 2016
CIP-004-5 Part 4.2
July 1, 2016
CIP-004-5 Part 2.3
April 1, 2017
CIP-004-5 Part 4.3
April 1, 2017
CIP-004-5 Part 4.4
April 1, 2017
CIP-006-5 Part 3.1
April 1, 2017
CIP-008-5 Part 2.1
April 1, 2017
CIP-009-5 Part 2.1
April 1, 2017
CIP-009-5 Part 2.2
April 1, 2017
CIP-010-1 Part 3.1
April 1, 2017
CIP-009-5 Part 2.3
April 1, 2018
CIP-010-1 Part 3.1
April 1, 2017
CIP-010-1 Part 3.2
April 1, 2018
CIP-004-5 Part 3.5
Within 7 years after previous
Personnel Risk Assessment
7
Requirement Count
• 7 Requirements (Version 3)
o 26 sub-requirements
• 5 Requirements (Version 5)
o 20 Parts
8
CIP-007-5 Requirements
• CIP-007-5
o R1 Ports and Services
o R2 Security Patch Management
o R3 Malicious Code Prevention
o R4 Security Event Monitoring
o R5 System Access Control
9
CIP-007 V3 to V5 Summary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
10
C-007-3 R1  CIP-010-1 R1.4 & R1.5
C-007-3 R2  CIP-007-5 R1
CIP-007-5 R1.2 – NEW – restrict physical ports
CIP-007-3 R3  CIP-007-5 R2
CIP-007-5 R2.1 – NEW – identify patch sources
CIP-007-3 R4  CIP-007-5 R3
CIP-007-5 R4.3 – NEW – Alerts
CIP-007-3 R5  CIP-007-5 R5
CIP-007-3 R5.1  CIP-004-5 R4.1
CIP-007-3 R5.1.1  CIP-003-5 R5.2
CIP-007-3 R5.1.2  CIP-007 R4.1
CIP-007-3 R5.1.3  CIP-004-5 R4.3
CIP-007-5 R5.7 – NEW – unsuccessful login thresholds and alerts
CIP-007-3 R6  CIP-007-5 R4
CIP-007-3 R7  CIP-011-1 R2
CIP-007-3 R8  CIP-010-1 R3
CIP-007-3 R9  Deleted
Project 200806 Cyber Security Order 706 DL_Mapping_Document_012913.pdf
Applicable Systems
11
IAC
• CIP-007-5 R1-R5
o contain Identify, Assess and Correct language in
requirement.
• 17 requirements that include IAC
o Filing deadline Feb. 3, 2015
12
•
•
Post for 45‐day first comment and ballot June 2–July 17, 2014
Communication Networks (Proposed Resolution)
o Modified requirement Part 1.2 in CIP‐007
 More comprehensive coverage of physical ports
•
•
13
IAC
o CIP-007, a new R2.5
o CIP‐007, update to R4.4
Transient Devices CIP-010 – New Part 4.1
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5RvnsRF/SDT%20Industry%20Webinar.pdf
Serial Exemption
14
Substation Serial-Only Communications
15
Non-Routable BCS
• BES Cyber System and associated BES Cyber
Assets are not dependent upon a routable protocol
• A BES Cyber System may include only serial
devices with no routable devices at all
• End point devices (relays) 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)
16
BCS with External Routable Connectivity
• CIP-007-5 Applicable Requirements:
o R1.2 Physical Ports
o R2 – Patch Management
o R3 – AV & Malicious code prevention
o R4.1, R4.3, R4.4 – Logging
o R5.2 – Default/Generic accounts
o R5.4 – Change default passwords
o R5.5 – Password complexity
17
CIP-007-5 Asset Level Requirements
o Most of CIP-007 can NOT be performed at a
‘system’ level but at the Cyber Asset level for
the following assets:
 BES Cyber Asset (BCA)
 EACM
 PACS
 PCA
o BCA groupings and BES Cyber Systems are
permitted where indicated
18
V5 Asset Level Requirements
•
•
•
•
PACS systems (CIP-006-5 Part 3.1)
Ports and Services (CIP-007-5 Part 1)
Patch Management (CIP-007-5 Part 2)
Security Event Monitoring (CIP-007-5 Part 4)
• BES Cyber System and/or Cyber Asset (if supported)
• System Access Control (CIP-007-5 Part 5)
• local system accounts
19
V5 Asset Level Requirements
• Baseline requirement (CIP-010-1 Part 1.1)
• Baseline change managements (CIP-010-1 Part
1.2 – 1.5)
• Active monitoring -35 days (CIP-010-1 Part 2.1)
• Cyber Vulnerability Assessment (CIP-010-1 Part
3.1, 3.2, 3.4)
• Testing of new asset (CIP-010-1 Part 3.3)
• System reuse or destruction (CIP-011-1 Part 2)
20
CIP-007-5 Part 1.1
Asset level requirement
21
Ports and Services
• en.able, en.a.ble
• Logical network accessible ports
22
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
o Port ranges or services
o 0-65535
• Blocking ports at the EAP does not substitute for the device level
requirement
• Know what ports are opened and give a reason for enabling service
• Measures
o Listening ports (netstat -boan/-pault)
o Configuration files of host-based firewalls
23
Tools/commands
• Netstat:
o Netstat -b -o -a -n > netstat_boan.txt
o Netstat -p -a -u -l -t > netstat_pault.txt
• NMAP scan results
o Nmap -sT -sV –p T:0-65535 <IP_address>
>>nmap_tcp.txt
o Nmap –sU -sV –p U:0-65535 <IP_address> >>
nmap_udp.txt
• #show control-plane host open-ports
• #show run all
24
Netstat
C:\Documents and Settings\HMI-1>netstat -b -o -a -n > netstat_boan.txt
Active Connections
Proto Local Address
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
UDP
UDP
UDP
UDP
UDP
UDP
25
Foreign Address
State
PID
0.0.0.0:135
0.0.0.0:0
LISTENING
952 C:\WINDOWS\system32\svchost.exe
0.0.0.0:445
0.0.0.0:0
LISTENING
4 [System]
0.0.0.0:6002
0.0.0.0:0
LISTENING
428 [spnsrvnt.exe]
0.0.0.0:7001
0.0.0.0:0
LISTENING
248 [sntlkeyssrvr.exe]
0.0.0.0:7002
0.0.0.0:0
LISTENING
248 [sntlkeyssrvr.exe]
127.0.0.1:1025
0.0.0.0:0
LISTENING
1656 [dirmngr.exe]
127.0.0.1:1029
0.0.0.0:0
LISTENING
2484 [alg.exe]
127.0.0.1:5152
0.0.0.0:0
LISTENING
1764 [jqs.exe]
127.0.0.1:33333
0.0.0.0:0
LISTENING
1856 [PGPtray.exe]
172.16.105.220:139 0.0.0.0:0
LISTENING
4 [System]
127.0.0.1:2111
127.0.0.1:33333
ESTABLISHED 1616
0.0.0.0:7001
*:*
248
[sntlkeyssrvr.exe]
0.0.0.0:500
*:*
700
[lsass.exe]
0.0.0.0:4500
*:*
700
[lsass.exe]
0.0.0.0:445
*:*
4
[System]
127.0.0.1:123
*:*
1084
c:\windows\system32\WS2_32.dll
172.16.105.220:6001 *:*
428
[spnsrvnt.exe]
Nmap
EMS1
root@bt:/# nmap -sT -sV -p T:0-65535 172.16.105.151
Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-18 12:15 EST
Nmap scan report for 172.16.105.151
Host is up (0.034s latency).
Not shown: 65531 closed ports
PORT
STATE SERVICE
VERSION
22/tcp open ssh
OpenSSH 5.3p1 Debian 3ubuntu6 (protocol 2.0)
80/tcp open http
Apache httpd 2.2.14 ((Ubuntu))
111/tcp open rpcbind (rpcbind V2) 2 (rpc #100000)
42851/tcp open status (status V1) 1 (rpc #100024)
MAC Address: 00:0C:29:66:05:65 (VMware)
Service Info: OS: Linux
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.25 seconds
26
Nmap
EMS1
root@bt:/# nmap -sU -sV -p U:0-65535 172.16.105.151
Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-18 12:15 EST
Nmap scan report for 172.16.105.151
Host is up (7.57s latency).
Not shown: 65533 closed ports
PORT
STATE SERVICE
68/udp open|filtered dhcpc
111/udp open
rpcbind
VERSION
MAC Address: 00:0C:29:66:05:65 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1081.98 seconds
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 123.25 seconds
27
Router Ports/Services
28
What We Expect [Sample only]
Device ID
29
Device Name
TCP Ports
UDP Ports
Service
Justification
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?
o CIP-010-1 Part 1.1
 "Develop a baseline configuration, individually or by
group, which shall include the following items:
 1.1.4. Any logical network accessible ports;’
o need for a port to be open and not an actual
authorization request for the port to be opened.
30
Authorizations
• CIP-010-1 Part 1.2
o "Authorize and document changes that deviate
from the existing baseline configuration.”
o Measure:
 A change request record and associated electronic
authorization (performed by the individual or group
with the authority to authorize the change) in a
change management system for each change; or"
31
CIP-007-5 / CIP-010-1 Relationship
• CIP-010-1 baseline configuration requirements
o CIP-010-1 Part 1.1.4
 Develop a baseline configuration of any
logical network accessible ports
 Documented list of enabled ports
• CIP-007-5 Part 1.1 is concerned only with the
enabling of needed ports
• Performance (CIP-007-5) versus documentation
(CIP-010-1)
32
Double Jeopardy?
• Failing to maintain the baseline configuration and
failing to disable unnecessary ports are two
different requirement violations
o CIP-007-5 Part 1.1 refers to listings of ports as
evidence, but that evidence could be the same
evidence required for CIP-010-1.
o Utilizing a single piece of evidence for proof of
compliance with two different requirements is not
double jeopardy
33
R1.1 Issues & Pitfalls
• Accurate enablement of required ports, services and
port ranges
• Understanding critical data flows and communications
within ESP and EAPs
• Logical ports include 65535 TCP & 65535 UDP ports
• Managing changes of both logical and physical ports
• Initial identification of physical port usage and controls –
port use mapping
• VA, approved baselines, and implemented logical ports
and services should always agree (CIP-010-1 and CIP007-5)
• Focus on EAPs inward to ESP Cyber Systems and
Cyber Assets
34
CIP-007-5 Part 1.2
Asset level requirement
35
CIP-007-5 Part 1.2
Asset level requirement
36
CIP-007-3  CIP-007-5 Change
CIP-007-3
Logical Ports only
37
CIP-007-5
Includes Physical Ports (R1)
Configuration Ports
•
•
•
•
Change Bios
Upgrade Firmware
Set Baseline Configuration
Build-out devices that have components
(like servers)
• Perform a variety of Administrative functions
• Perform emergency repair or failure
recovery when no other port is accessible
http://www.tditechnologies.com/whitepaper-nerc-cip-007-5-r1
38
Part 1.2 Physical Ports
• physical I/O ports
o Network
o Serial
o USB ports external to the device casing
39
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”
o Requirement is not to be a 100% preventative
control
o Last measure in a defense in depth layered control
environment to make personnel think before
attaching to a BES Cyber System in the highest
risk areas
40
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
41
Port Locks
42
http://www.blackbox.com/resource/genPDF/Brochures/LockPORT-Brochure.pdf
Physical Access to Ports
43
http://www.supernap.com/supernap-gallery-fullscreen/
Question
• Would a Cyber Asset locked in a cage meet
this requirement?
• Answer
o No, the required control needs to be applied on
the Cyber Asset level
44
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
o Think before you plug anything into one of these
systems
o Controls: 802.1x, physical plugs, port block, signage
• Physical port usage documentation – know what is
in use versus existing ports not required
• Site tours may validate physical port documentation
45
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.
o The ability to communicate outside of itself is
not a determining factor as to whether a Cyber
Asset is or is not a BES Cyber Asset or BES
Cyber System
o The Cyber Asset’s function as it pertains to
BES reliability determines system identification
46
CIP-007-5 Part 2.1
Asset level requirement
47
CIP-007-3  CIP-007-5 Change
CIP-007-3
No time frames to
implement patches
48
CIP-007-5
Patch management required actions and
timelines (R2)
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
49
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
50
Tracking for Applicability
• Is applicability based on original source of patch (e.g.
Microsoft) or the SCADA vendor?
o Some may consider it a best practice that
vulnerabilities be mitigated in the shortest
timeframe possible, even before the patch is
certified by the SCADA vendor.
o Appropriate source dependent on the situation
51
Patch Sources
• Electricity Sector Information Sharing and Analysis Center (ES-ISAC)
o https://www.esisac.com/
• Common Vulnerabilities and Exposures
o http://cve.mitre.org/
• BugTraq
o http://www.securityfocus.com/vulnerabilities
• National Vulnerability Database
o http://nvd.nist.gov/
• ICS-CERT
o http://ics-cert.us-cert.gov/all-docs-feed
52
Sources
53
https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy
Patch Update Issues
• Cyber Security focused
o Requirement does not cover patches that are
purely functionality related with no cyber
security impact
o Cyber Asset Baseline documentation with patch
tracking (CIP-010-1 R1.1.5)
o Operating system/firmware, commercially
available software or open-source application
software, custom software
54
Cyber Security software patches
• Hardware vendors do provide security
patches and security upgrade to
mitigate/eliminate vulnerabilities identified in
their drivers and firmware
55
56
‘that are updateable’
57
Windows XP (EOL 4-8-2014)
• April 2014 there are no more security patches
forthcoming for XP
o
o
o
o
o
58
No Software Updates from Windows Update
No Security Updates
No Security Hotfixes
No Free Support Options
No Online Technical Content Updates
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)
59
http://www.computerworld.com/s/article/9237019/Microsoft_gooses_Windows_XP_s_custom_support_prices_as_deadline_nears?pageNumber=1
Windows XP (EOL 4-8-2014)
• April 2014 there are no more security patches
forthcoming for XP
o No patches to assess or apply
• No patches issued means no action required
• No TFEs in R2 language
o TFEs are not required at any step in the R2 process
• Still required to track, evaluate and install
security patches outside of the OS
60
End of Life Systems & Devices
•
•
•
•
Document vendor end dates
Document BCS Assets affected
Ensure latest applicable patch is implemented
Deploy mitigation measures for vulnerabilities not
able to patch
• Monitor US-CERT, and other vulnerability tracking
sites to be aware of newly identified vulnerabilities
that would affect your assets
• Where possible, implement mitigation measures
for the newly identified vulnerability
61
Windows XP Embedded
• Cyber Assets running the Microsoft Windows XP
Embedded SP3 operating system have until
January 12, 2016, before support ends for that
version of the operating system
• Support for systems built on the Windows
Embedded Standard 2009 operating system ends
on January 8, 2019. The Windows Embedded
operating system normally runs on appliances
62
CIP-007-5 Part 2.2 Patch Evaluation
Asset level requirement
63
Part 2.2 Patch Evaluation
• At least every CIP Month (35 days) evidence of patch release
monitoring and evaluation of patches for applicability
• Evaluation Assessment
o Determination of Risk
o Remediation of vulnerability
o Urgency and timeframe of remediation
o Next steps
• Entity makes final determination for their environment if it is more of a
reliability risk to patch a running system than the vulnerability presents
o Date of patch release, source, evaluation performed, date of
performance and results
o Listing of all applicable security patches
64
Part 2.2 Patch Evaluation
65
Guidelines
• DHS
o “Quarterly Report on Cyber Vulnerabilities of Potential Risk
to Control Systems”
 http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_1339_Feb13.pdf
o “Recommended Practice for Patch Management of Control
Systems”
 http://ics-cert.uscert.gov/sites/default/files/recommended_practices/Patch
ManagementRecommendedPractice_Final.pdf
66
Vulnerability Footprint
67
http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf
CIP-007-5 Part 2.3
68
Asset level requirement
CIP-007-5 Part 2.3 [Patch Response]
High Impact
BCS
R2.1
Document Patch
Management process &
sources
PCA
EACM
Medium
Impact BCS
EACM
R2.2
Documented Patch
evaluation (max 35 days)
PACS
R2.3 Within 35
days
YES
Required
patch
identified?
OR
69
Create
Mitigation plan
Update
Mitigation plan
PACS
NO
Install patch
OR
PCA
Asset level requirement
Implement
Plan within
time frame
Part 2.3 Actions
• Evidence of performance of:
o Installation of patches
 Not an “install every security patch” requirement
o Mitigation plan created – includes specific
mitigation/mediation of identified security
vulnerability, date of planned implementation and
rational for delay
o Mitigation plan update evidence
o Evidence of Mitigation plan completion with dates
70
Note: referenced mitigation plan is a entity plan and
not associated at all with the Enforcement Mitigation
plans.
Timeframe
• Timeframe is 70 days total
o 35 days for tracking and determining
applicability
o 35 days for either installing or determining the
mitigation plan
71
Maximum Timeframes
• It is compliant with the requirement to state
a timeframe of the phrase “End of Life
Upgrade”
• Mitigation timeframe is left up to the entity
o Requirement is to have a plan
 Date of the plan in requirement part 2.3 is what part
2.4 depends upon
o Must work towards that plan
72
Timeframes Guidelines
• Timeframes do not have to be designated
as a particular calendar day but can have
event designations such as “at next
scheduled outage of at least two days
duration”
73
CIP-007-5 Part 2.4
74
Asset level requirement
CIP-007-5 Part 2.4 [Mitigation Plan]
High Impact
BCS
Medium
Impact BCS
R2.1
Document Patch
Management process &
sources
PCA
EACM
PCA
EACM
R2.2
Documented Patch
evaluation (max 35 days)
PACS
R2.3 Within 35
days
YES
Required
patch
identified?
PACS
NO
R2.4
Implement Plan
within time frame
Install patch
OR
OR
75
Create
Mitigation plan
Update
Mitigation plan
CIP SM or
Delegate
approval
Plan
R2.4 Revision or
Extension?
YES
Part 2.4 Mitigation Plan
• Evidence of CIP Senior Manager’s approval
for updates to mitigation plans or extension
requests
o Per Mitigation plan
• Revising the plan, if done through an
approved process such that the revision or
extension, must be approved by the CIP
Senior Manager or delegate
76
Part 2.3 Mitigation
• Some patches may address vulnerabilities
that an entity has already mitigated through
existing means and require no action
• Lack of external routable connectivity may
be used as a major factor in many
applicability decisions and/or mitigation
plans where that is the case
77
Part 2.3 Mitigation Guidelines
• When documenting the remediation plan
measures it may not be necessary to
document them on a one to one basis
• The remediation plan measures may be
cumulative
78
Part 2.4 Implement
• The ‘implement’ in the overall requirement
is for the patch management process
o ‘Implement’ in R2.4 (Mitigation Plan) is for the
individual patch
o If R2.4 does not have an implement
requirement at the patch level, then the
‘implement’ in the overall requirement only
applies to drafting a plan
79
Demonstrating implementation of
Mitigation Plan
• Measures –
o Records of the implementation of the plan
o Installing the patch/record of the installation
o Disabling of any affected service
o Adding of a signature to an IDS
o Change to a host based firewall
o Record of the completion of these changes
80
Proposed CIP-007 R2.5
81
R2 Issues & Pitfalls
• Asset level requirements
• Know, track, and mitigate the known software
vulnerabilities associated with BES Cyber Assets
• Not including a complete listing of BES Cyber Systems
and assets that are applicable
o Firmware devices (relays, appliances, etc.)
o Infrastructure devices within ESP
o OS based systems
• Cyber Asset applications (tools, EMS, support
applications, productivity applications, etc.)
• If something is connected to or running on the BES
Cyber Assets that releases security patches
o required to be included in the monitoring for patches
82
CIP-007-5 Part 3.1
BES Cyber System level requirement
83
CIP-007-3  CIP-007-5 Change
84
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)
Part 3.1 Malicious Code
• Deter OR detect OR prevent - any one or
combination will meet the wording of the requirement
o Avoids zero-defect language
o R3.2 requires ability to detect malicious code
• Methods = processes, procedures, controls
• Applicability is at the ‘system’ level
o Methods do not have to be used on every single
Cyber Asset
• Allows entities to adapt as the threat adapts while
also reducing the need for TFEs
85
AV/Anti-Malware
86
Defense-N-Depth
87
https://www.lumension.com/vulnerability-management/patch-management-software/third-party-applications.aspx
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
88
http://www.asd.gov.au/publications/csocprotect/application_whitelisting.htm
Application Whitelisting
•
•
•
•
•
•
•
•
89
Application File Attributes
Digital Certificates
File Hash
File Ownership
Location
Reference Systems
Signed Security Catalogs
Software Packages
Virtual Systems
90
http://www.vmware.com/products/vshield-endpoint/overview.html
Guidelines
• Network isolation techniques
• Portable storage media policies
• Intrusion Detection/Prevention (IDS/IPS)
solutions
91
Part 3.1 Malicious Code
• Is an awareness campaign to deter ok?
o ‘or’ and ‘deter’ to avoid zero-defect language
• Requirement is not to detect or prevent all
malicious code
• Approach is not to require perfection in an
imperfect environment with imperfect tools
92
‘Associated PCAs’
• Associated PCAs’ are included at a Cyber
Asset (device) level, not system level
• How will the ‘system’ concept apply?
o Malware prevention is at a BCS level
o The associated PCA’s could be included by
reference in the documentation an entity
supplies for Requirement R3.1
93
CIP-007-5 R3.2
BES Cyber System level requirement
94
Part 3.2 Detected Malicious Code
• Requires processes
• No maximum timeframe or method
prescribed for the removal of the malicious
code
• Mitigation for the Associated Protected
Assets may be accomplished through other
applicable systems
o Entity can state how the mitigation covers the
associated PCA’s
95
CIP-007-5 R3.3
BES Cyber System level requirement
96
Requires process for updates
• Requires processes that address:
• Testing
• Does not imply that the entity is testing to ensure that
malware is indeed detected by introducing malware into the
environment
• Ensuring that the update does not negatively impact the BES
Cyber System before those updates are placed into
production
• Installation
• No timeframe specified
• Requirement R3.1 allows for any method to be used and does not
preclude the use of any technology or tool
97
Part 3.3 Signatures
• Specific sub requirement is conditional and
only applies to “for those methods identified
in requirement part 3.1 that use signatures
or patterns”
o If an entity has no such methods, the
requirement does not apply.
o Requirement does not require signature use
o Can an entity rely on AV vendor testing?
98
TFEs
• Requirement has been written at a much
higher level than previous versions
• Requirement no longer prescriptively
requires a single technology tool for
addressing the issue
o TFEs are not required for equipment that does
not run malicious code tools
99
R3 Issues & Pitfalls
•
•
•
•
•
Technical selection and implementation
Coverage for all cyber assets
Combination of solutions
BCS and ESP coverage
Clear documentation demonstrating
coverage
• Identification, alerts and response
procedures
100
CIP-007-5 Part 4.1
BES Cyber System and/or Asset level requirement
101
CIP-007-3  CIP-007-5 Change
CIP-007-3
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
Log reviews every 90 days
when applicable
102
CIP-007-5
CIP-007-5
Log reviews for High Impact Cyber Systems
must be reviewed every 15 days (R4)
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)
o Successful and failed logins
o Failed ACCESS attempts
 blocked network access attempts
 successful and unsuccessful remote user access attempts
 blocked network access attempts from a remote VPN
 successful network access attempts or network flow information
o Detection of malicious code
103
Part 4.1 Log Events
• Types of events
• Requirement does not apply if the device does not log the events
o Devices that cannot log do not require a TFE
o logging should be enabled wherever it is available
• 100% availability is not required
o Entity must have processes in place to respond to outages in a
timely manner
104
CIP-007-5 Part 4.2
BES Cyber System and/or Cyber Asset (if
supported) level requirement
105
Part 4.2 Alerting
• Detected known or potential malware or
malicious activity (Part 4.2.1)
• Failure of security event logging
mechanisms (Part 4.2.2)
• Alert Forms
o Email, text, system display and alarming
• Alerting Examples
o Failed login attempt threshold exceeded
o Virus or malware alerts
106
Part 4.2 Alerting Guidelines
• Consideration in configuring real-time alerts:
o Login failures for critical accounts
o Interactive login of system accounts
o Enabling of accounts
o Newly provisioned accounts
o System administration or change tasks by an unauthorized
user
o Authentication attempts on certain accounts during nonbusiness hours
o Unauthorized configuration changes
o Insertion of removable media in violation of a policy
107
Question
• Is an alert required for malicious activity if it
is automatically quarantined?
o Alerts are required for detection of malicious
code regardless of any subsequent mitigation
actions taken
108
Guidance
• Guidance implies that only technical means
are allowed for alerting on a ‘detected cyber
security event’
o Requirement language is the ruling language
and guidance is not auditable and is provided
to provide further context, examples or
assistance in how entities may want to
approach meeting the requirement
o Requirement does not preclude procedural
controls
109
CIP-007-5 Part 4.3 – Part 4.4
110
BES Cyber System and/or Cyber Asset (if
supported) level requirement
Part 4.3 ‘Retain Applicable Event Logs’
• Timeframe:
o Response timeframe begins with the alert of the
failure
o After something or someone has detected the
failure and has generated an alert as in R4.2
o For the compliance period, the applicable cyber
systems maintain 90 days of logs. (All High BCS as
well as Medium BCS at Control Center)
• Retention methods are left to Responsible
Entity
o On or before April 15, 2016
111
Part 4.3 ‘Retain Applicable Event Log’s’
112
Part 4.3 ‘Retain Applicable Event Logs’
• Is the audit approach to ask for any single
day’s logs in past three years?
o Compliance evidence requirement is that the
entity be able to show that for the historical
compliance period, the applicable cyber
systems maintained 90 days of logs
o ‘records of disposition’ of logs after their 90
days is up
113
Part 4.4 Review Logs Guidelines
• Summarization or sampling of logged events
o log analysis can be performed top-down
starting with a review of trends from
summary reports
o Determined by the Responsible Entity
• Electronic Access Points to ESP’s are EACMs,
this is one of the primary logs that should be
reviewed
114
Part 4.4 Review Logs
• Purpose is to identify undetected security
incidents
• Paragraph 525 of Order 706
o Even if automated systems are used, the manual
review is still required
o Manually review logs ensure automated tools are tuned
and alerting on real incidents
• What if an entity identifies events in R 4.4 that
should have been caught in R4.1 is this a
violation?
115
116
R4 Issues & Pitfalls
• Ensure all EACMs are identified
o “Cyber Assets that perform electronic access control or
electronic access monitoring of the Electronic Security
Perimeter(s) or BES Cyber Systems. This includes
Intermediate Systems.’ – NERC glossary
• Documentation of log collection architecture
o Log collection data flows
o Aggregation points
o Analysis processes and/or technologies
• Validation of the required logs and alert
configurations
117
Cloud Computing
Storage-aaS
118
Backup-aaS
Monitoring-as-a-Service
Infrastructure-as-a-Service
DR-as-a-Service
Platform-as-a-Service
Firewall - aaS
Software-as-a-Service
Load Balancing - aaS
IT-as-a-Service
Database-aaS
http://www.ipspace.net/Webinars
Monitoring-as-a-Service
ESP
EAP
Syslog/Event Log
Vendor SOC
SSL
Vendor Server/
EACM?
Firewall
ESP
Syslog/Event Log
EAP
119
Vendor Server managed by vendorPull of config updates and patches from vendor
Log correlation occurs offsite at the vendor SOC
http://www.symantec.com/content/en/us/enterprise/other_resources/b-nerc_cyber_sercurity_standard_21171699.en-us.pdf
CIP-007-5 Part 5.1
120
BES Cyber System and/or Cyber Asset
level requirement
CIP-007-3 CIP-007-5 Highlights
CIP-007-3
121
CIP-007-5
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
• Ensure the BES Cyber System or Cyber
Asset authenticates individuals with
interactive access
o GPO (Group Policy Object)
• Interactive user access
o Doesn’t include read-only
 front panel displays, web-based reports
• Procedural Controls
122
Part 5.1 Enforce Authentication
123
CIP-007-5 Part 5.2
BES Cyber System and/or Cyber Asset
level requirement
124
Part 5.2 Identify Accounts
• Identifying the use of account types
o Default and other generic accounts remaining enabled must be
documented
o Avoids prescribing an action to address these accounts without
analysis
 Removing or disabling the account could have reliability
consequences.
• Not inclusive of System Accounts
• For common configurations, documentation can be performed at a
BES Cyber System or more granular level
• Restricting accounts based on least privilege or need to know covered
in CIP-004-5
125
CIP-007-5 Part 5.3
126
BES Cyber System and/or Cyber Asset
level requirement
CIP-007-3 Requirement 5.1.2
127
Part 5.3 Identify Individuals
• CIP-004-5 to authorize access
o Authorizing access does not equate to knowing
who has access to a shared account
• “authorized”
o An individual storing, losing or inappropriately
sharing a password is not a violation of this
requirement
• Listing of all shared accounts and personnel
with access to each shared account
128
CIP-007-5 Part 5.4
BES Cyber System and/or Cyber Asset
level requirement
129
Part 5.4 Known
o Cases where the entity was not aware of an
undocumented default password by the vendor
would not be a possible violation
o Once entity is made known of this default
password may require action per CIP-007-5 R2
130
Part 5.4 Timeframe
• When is a default password required to be
changed?
o No timeframe specified in requirement
 As with all requirements of CIP-007-5, this
requirement must be met when a device
becomes one of the applicable systems or
assets
131
CIP-007-5 Part 5.5
132
BES Cyber System and/or Cyber Asset
level requirement
Part 5.5 Passwords
• Eight characters or max supported
• 5.5.2 Three or more different types of chars
or maximum supported
133
Part 5.5 Passwords
• CAN-0017
o Compliance Application Notices do not carry forward to
new versions of the standard
• Requirement explicitly addressed the issue raised
by CAN-0017 that either technical or procedural
mechanisms can meet the requirement
• Guidelines Section
o Physical security suffices for local access configuration
if the physical security can record who is in the Physical
Security Perimeter and at what time
134
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
135
CIP-007-5 Part 5.6
BES Cyber System and/or Cyber Asset
level requirement
136
Part 5.6 Password Changes
• Password change procedures
• Evidence of password changes at least
every CIP Year (15 months)
• Disabled Accounts
o Password change is not required because
these do not qualify as providing interactive
user authentication
137
CIP-007-5 Part 5.7
BES Cyber System and/or Cyber Asset
level requirement
138
Part 5.7 Authentication Thresholds
• Requirement does not duplicate CIP-007-5
part 4.2
o Part 4.2 alerts for security events
o Part 5.7 alert after threshold is not required to
be configured by the R4.2 Requirement
• TFEs
o TFE triggering language qualifies both options
o TFE would only be necessary based on failure
to implement either option (operative word ‘or’)
139
Part 5.7 Authentication Thresholds
• Threshold for unsuccessful login attempts
o “The threshold of failed authentication attempts
should be set high enough to avoid falsepositives from authorized users failing to
authenticate.”
• Minimum threshold parameter for account
lockout
o No value specified
140
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
141
Questions?
Morgan King
CISSP-ISSAP, CISA
Senior Compliance Auditor, Cyber Security
Western Electricity Coordinating Council
Salt Lake City, UT
mking@wecc.biz
(C) 801.608.6652 (O)801.819.7675