Presentation - WECC_V5 CIP 101 CIP-007

Transcription

Eric Weston
Compliance Auditor – Cyber Security
Mick Neshem
CISSP, CISA
Senior Compliance Auditor – Cyber Security
CIP 101
CIP-007-6
September 24-25, 2014
Henderson, NV
2
Agenda
•
•
•
•
•
•
W
E
CIP-007-6 Overview
New/Redefined Terminology
CIP-007-6 Audit Approach
Mach Audit
Issues & Pitfalls
Questions
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
3
Transition Guidance
• NERC. (2014 August 12). Cyber Security Reliability
Standards CIP V5 Transition Guidance: ERO
Compliance and Enforcement Activities during
the Transition to the CIP Version 5 Reliability
Standards. Retrieved
from http://www.nerc.com/pa/CI/Documents/V3
-V5%20Transition%20Guidance%20FINAL.pdf
• (NERC, 2014, CIP V5 Transition Guidance)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
4
Mock Audit Approach
• Review of what is expected by the auditors for
each CIP-007-6 requirement
• Review of Billiam Evidence
• Sample Data Requests
• Sample Interview questions
• Discussion and interactive audit of
requirements
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
5
CIP CONFIDENTIAL
Billiam EMS Architecture
ASA
FW3
Access
Point
BUCC
BCA
SW3 BCA
RTR 3
BCA
BCA
BCA BCA
EMS Console 5-6
BU1
BCA
WKS3
EMS 5 - 6
CC1
EMS Net
BUCC WAN
ASA
FW1
CorpNet
Access
Point
HP PTR1-2
WKS1-2
RTR 12
CCA
HPUX 1- 2
EMS Console 1-4
BCA
BCA
BCA
BCA
Access
Point
BCA
BCA BCA BCA BCA
W
Syslog1
E
S
T
BCA
BCA BCA
R
N
RTR 4
PIX FW
BCA
Access
Point
LogRhythm
E
SU1
SUB1
SW4 BCA
DC1 HMI1 ICCP 1- 2
EMS 1- 4
HMI-2
BCA
EMS WAN
ASA
FW2
EMS Net
DMZ1
Billiam
Electronic
Security
Perimeters
DC2
BCA
BCA
Relay 1- 3
WON
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
6
EMS ESP [IP network]
EMS Electronic Security Perimeter
Workstations
Printer
EMS WAN
File
Server
CIP-005
CorpNet
Router
Access
Control
Server
Switch
EAP
Firewall
CIP-007
CIP-005
Router
EAP
BCA
Firewall
Switch
DMZ
Switch
BCA
Printer
BCA
BCA
EACM
BCA
BCA
Intermediate
Server
W
E
S
T
E
EMS
Servers
EACM
R
Access
Control
Server
N
E
BCA
BCA
Workstations
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
7
EMS ESP/BCS [IP network]
All PCA devices
take on the
impact level of
the BCS
Non-BCS Workstations
File Server
PCA
Printer
PCA
EMS WAN
PCA
PCA
Router
PCA
Switch
CIP-005
CorpNet
EAP
CIP-007
EAP
CIP-005
BCA/PCA Router
BCA
Firewall
Switch
CIP-002
Printer
DMZ
Switch
BCA
BCA/PCA
PCA
BCA
BCA
EACM
EACM
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
EMS
Servers
BCA
BCA
Access
Control
Server
Intermediate
Server
BCA
Workstations
BCA
W
Firewall
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
8
Multi-BCS ESP
BCS Workstations
BCS Server
BCA
Printer
BCA
EMS WAN
PCA
BCA
MEDIUM
EAP
CIP-007
CIP-005
CorpNet
Router
BCA
Switch
EAP
Firewall
CIP-005
BCA/PCA Router
BCA
Firewall
DMZ
Switch
Switch
CIP-002
Printer
BCA
BCA/PCA
PCA
BCA
BCA
EACM
EACM
BCA
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
EMS
Servers
BCA
BCA
Access
Control
Server
Intermediate
Server
BCA
Workstations
O
R
D
HIGH
I
N
A
T
I
N
G
C
O
U
N
C
I
L
9
EMS ESP [High Water Mark]
All PCA devices
take on the
impact level of
the BCS
BCS Workstations
BCS Server
PCA
Printer
PCA
EMS WAN
PCA
PCA
Router
PCA
Switch
CIP-007
CIP-005
CorpNet
EAP
EAP
Firewall
HIGH
BCA/PCA Router
CIP-005
BCA
Firewall
DMZ
Switch
Switch
CIP-002
Printer
BCA
BCA/PCA
PCA
BCA
BCA
EACM
EACM
BCA
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
EMS
Servers
BCA
BCA
Access
Control
Server
Intermediate
Server
BCA
Workstations
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
10
V5 Effective 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
CIP-003-5 R2
for low impact BES Cyber Systems
CIP-007-5 Part 4.4
CIP-010-2 Part 2.1
CIP-004-5 Part 4.2
CIP-004-5 Part 2.3
CIP-004-5 Part 4.3
CIP-004-5 Part 4.4
CIP-006-5 Part 3.1
CIP-008-5 Part 2.1
CIP-009-5 Part 2.1
CIP-009-5 Part 2.2
CIP-010-2 Part 3.1
CIP-009-5 Part 2.3
CIP-010-2 Part 3.1
CIP-010-2 Part 3.2
CIP-004-5 Part 3.5
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
April 1, 2016
April 1, 2017
April 15, 2016
May 6, 2016
July 1, 2016
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2017
April 1, 2018
April 1, 2017
April 1, 2018
Within 7 years after previous
Personnel Risk Assessment
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
11
Requirement Count
• 7 Requirements (Version 3)
– 26 sub-requirements
• 5 Requirements (Version 5)
– 20 Parts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
12
CIP-007-6 Requirements
• CIP-007-6
– R1 Ports and Services
– R2 Security Patch Management
– R3 Malicious Code Prevention
– R4 Security Event Monitoring
– R5 System Access Control
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
13
CIP-007 V3 to V5 Summary
C-007-3 R1  CIP-010-2 R1.4 & R1.5
C-007-3 R2  CIP-007-6 R1
CIP-007-6 R1.2 – NEW – restrict physical ports
CIP-007-3 R3  CIP-007-6 R2
CIP-007-6 R2.1 – NEW – identify patch sources
CIP-007-3 R4  CIP-007-6 R3
CIP-007-6 R4.3 – NEW – Alerts
CIP-007-3 R5  CIP-007-6 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-6 R5.7 – NEW – unsuccessful login thresholds and alerts
CIP-007-3 R6  CIP-007-6 R4
CIP-007-3 R7  CIP-011-2 R2
CIP-007-3 R8  CIP-010-2 R3
CIP-007-3 R9  Deleted
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Project 200806 Cyber Security Order 706 DL_Mapping_Document_012913.pdf
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
14
Applicable Systems
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
15
IAC
• CIP-007-6 R1-R5
– contain Identify, Assess and Correct language in requirement.
• 17 requirements that include IAC
– Filing deadline Feb. 3, 2015
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
16
CIP-007-6 TFEs
•
•
•
•
•
W
E
P1.1 – TFE language – but not required
P4.3 – 90 log retention for Control Centers
P5.1 – Enforce interactive authentication
P5.6 – Annual password changes
P5.7 – Failed login threseholds
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
17
Continuing Standards Development
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
18
Serial Exemption
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
19
Substation Serial-Only Communications
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
20
Non-Routable BCS
• BES Cyber System and associated BES Cyber
Assets are not dependent upon a routable
protocol
• A BES Cyber System may include only serial
devices with no routable devices at all
• End point devices (relays, meters, etc.) are to be
included within the V5 requirements and may be
BES Cyber Assets or even a BES Cyber System,
even if no routable communications exist
• Therefore, there are V5 requirements to be
addressed (i.e. CIP-007-6)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
21
BCS with External Routable Connectivity
• CIP-007-6 Applicable Requirements:
– Part 1.2 – Physical Ports
– R2 – Patch Management - Firmware
– R3 – AV & Malicious code prevention – multiple
controls
– Part 4.1, Part 4.3, Part 4.4 – Logging
– Part 5.2 – Default/Generic accounts
– Part 5.4 – Change default passwords
– Part 5.5 – Password complexity
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
22
SEL-2890 Ethernet Transceiver
[2890_PF00011.pdf]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
23
SEL-351R account & Default Passwords
351R-4_QS_20140207.pdf
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
24
CIP-007-6 Asset Level Requirements
– Most of CIP-007 can NOT be performed at a
‘system’ level, but at the Cyber Asset level for the
following assets:
•
•
•
•
BES Cyber Asset (BCA)
EACM (EAP)
PACS
PCA
– BCA groupings and BES Cyber Systems are
permitted where indicated
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
25
V5 Asset Level Requirements
PACS systems (CIP-006-5 Part 3.1)
Ports and Services (CIP-007-6 Part 1)
Patch Management (CIP-007-6 Part 2)
Security Event Monitoring (CIP-007-6 Part 4)
•
•
•
•
• BES Cyber System and/or Cyber Asset (if supported)
• System Access Control (CIP-007-6 Part 5)
• local system accounts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
26
V5 Asset Level Requirements
• Baseline requirement (CIP-010-2 Part 1.1)
• Baseline change managements (CIP-010-2 Part 1.2 –
1.5)
• Active monitoring -35 days (CIP-010-2 Part 2.1)
• Cyber Vulnerability Assessment (CIP-010-2 Part 3.1,
3.2, 3.4)
• Testing of new asset (CIP-010-2 Part 3.3)
• System reuse or destruction (CIP-011-2 Part 2)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
27
CIP-007-6 Part 1.1
Asset level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
28
CIP-007-6 Part 1.1 [Ports/Services]
High Impact
BCS
Medium
Impact BCS
PCA
PCA
EACM
EACM
PACS
PACS
P1.1
Identify and document
required ports and services
Yes
External
Routable
Connectivity?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
29
Ports and Services
• en.able, en.a.ble
• Logical network accessible ports
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
30
Ports and Services
• Control required to be on the device itself or may be positioned inline
(cannot be bypassed)
• Host based firewalls, TCP_Wrappers or other means on the Cyber Asset to
restrict access
• Dynamic ports
– Port ranges or services
– 0-65535 (tcp & udp)
• Blocking ports at the EAP does not substitute for the device level
requirement
• Know what ports are opened and provide a business reason for enabling
service
• Measures
– Listening ports (netstat -boan/-pault)
– Configuration files of host-based firewalls
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
31
Tools/commands
• Netstat:
– Netstat -b -o -a -n > netstat_boan.txt
– Netstat -p -a -u -l -t > netstat_pault.txt
• NMAP scan results
– Nmap -sT -sV –p T:0-65535 <IP_address> >>nmap_tcp.txt
– Nmap –sU -sV –p U:0-65535 <IP_address> >>
nmap_udp.txt
• show control-plane host open-ports
• show running configurations (router or firewall)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
32
What We Expect [Sample only]
Device ID
W
E
S
T
E
Device Name
R
N
E
L
E
C
TCP Ports
T
R
I
C
I
T
UDP Ports
Y
C
O
O
R
Service
D
I
N
A
T
I
Justification
N
G
C
O
U
N
C
I
L
33
Question
• Is it required to capture not only the need for a port to
be open, but also the authorization request for the port
to be opened?
– CIP-010-2 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;’
– NO
• need for a port to be open and not an actual
authorization request for the port to be opened.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
34
Authorizations
• CIP-010-2 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"
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
35
CIP-007-6 / CIP-010-2 Relationship
• CIP-010-2 baseline configuration requirements
– CIP-010-2 Part 1.1.4
• Develop a baseline configuration of any logical
network accessible ports
• Documented list of enabled ports
• CIP-007-6 Part 1.1 is concerned only with the
enabling of needed ports
• Performance (CIP-007-6) versus documentation (CIP010-2)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
36
Double Jeopardy?
• Failing to maintain the baseline configuration and
failing to disable unnecessary ports are two different
requirement violations
– CIP-007-6 Part 1.1 refers to listings of ports as evidence,
but that evidence could be the same evidence required for
CIP-010-2.
– Utilizing a single piece of evidence for proof of compliance
with two different requirements is not double jeopardy
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
37
Mock Audit of Billiam
•
•
•
•
•
W
E
Audit Approach
Bad Evidence Examples
Typical Data Request
Typical Interview Questions
Good Evidence Examples
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
38
Part 1.1 Evidence
Provide the following evidence:
a. Identification of the enabled logical ports which are network accessible. Include , if
applicable, documentation of the configuration of host firewalls or other methods of
restricting network access to a listening port. For Electronic Access Points, this
information is only required for the device’s management ports.
a. If dynamic ports are in use, provide the following:
I. The name of each service that requires dynamic ports.
II. The port range used by each service.
III. The method used to associate service with the dynamic port (e.g., netstat, etc.)
b. Documentation of the need (e.g., operational purpose) for all enabled logical network
accessible ports. For Electronic Access Points, this information is only required for the
device’s management ports.
a. The comparison of the list of ports actually network accessible to the list of ports
needed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
39
Part 1.1 Audit Steps
• Verify the documentation includes the need for each enabled logical network
accessible port on the device
• Where a port range is required, verify the associated service is also identified
• If a logical network accessible port is deemed needed by the inability to disable
the port, verify the documentation of the inability to disable the port
• Review the list of logical network accessible ports on the device.
• Review the comparison of the needed ports and services with the listening
ports and services. Verify that this comparison is complete and correct.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
[CIP-007-6 Part 1.1] Audit Approach –
What are we looking for?
40
• Required ports defined – documented
– Cyber Asset specific
• What service is running on what port
• Port ranges – must include service
• Documentation of procedures to identify and manage required
ports/services
– TCP and UDP ports
– listening/established state (disregard loopback addresses)
• Vendor documentation may assist in defining required ports and services
and their operational purpose
• Documentation of ports and services used in normal or emergency
operation
• Are high risk ports/services running? Operational requirement?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
[CIP-007-6 Part 1.1] Audit Approach –
What are we looking for? [continued]
41
• Procedures to ensure only required
ports/services are enabled for new/changed
devices (Part 1.1)
• What tests are performed to validate correct
configurations– who, when, how, tools (Part
1.1)
• If a device has no provision for disabling ports
they are deemed needed, No TFEs (Part 1.1)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
42
[CIP-007-6 Part 1.1] Typical Data Requests
• For the following servers and workstations (Bes
cyber assets) provide current “netsat” (netstat –b –
o –a -n / netstat –p –a -l) or port scan (TCP/UDP)
results. [sample list]
• For the following network devices, provide current
configuration files (i.e., show run), ports and
services running (scan results if exists) and
evidence of any firmware/software updates since
10/1/2010, [sample list]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
[CIP-007-6 Part 1.1] Typical Interview
Questions
43
• Describe the procedures used to identify the
required ports/services
• Are vendors involved with the definition of
required ports/services?
• Are there Cyber Assets, which ports and
services cannot be disabled?
– If so, what are the compensating measures in
place
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
44
Part 1.1 Issues & Pitfalls
• Accurate enablement of required ports, services and port
ranges
• Understanding critical data flows and communications within
ESP and EAPs
• Logical ports include 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-2 and CIP-007-6)
• Focus on EAPs inward to ESP Cyber Systems and Cyber Assets
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
45
Part 1.1 Insufficient Evidence – Why?
C:\HMI-1>netstat
Active Connections
Proto Local Address
Foreign Address
State
TCP HMI-1:2111
localhost:33333
ESTABLISHED
TCP HMI-1:3616
localhost:10525
ESTABLISHED
TCP HMI-1:5152
localhost:1573
CLOSE_WAIT
TCP HMI-1:10525
localhost:3616
ESTABLISHED
TCP HMI-1:33333
localhost:2111
ESTABLISHED
TCP HMI-1:netbios-ssn 172.16.105.1:56761 TIME_WAIT
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
46
HMI-1 Baseline Evidence [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
W
E
S
T
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]
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
47
HMI-1 Evidence
[nmap tcp]
root@bt# nmap -sT -sV -p T:1-65535 172.16.105.220
Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-03 10:28 EST
Nmap scan report for 172.16.105.220
Host is up (0.00084s latency).
Not shown: 65528 closed ports
PORT STATE
135/tcp open
139/tcp open
445/tcp open
777/tcp open
6002/tcp open
7001/tcp open
7002/tcp open
SERVICE
VERSION
msrpc
Microsoft Windows RPC
netbios-ssn
microsoft-ds Microsoft Windows XP microsoft-ds
multiling-http?
http
SafeNet Sentinel License Monitor httpd 7.3
afs3-callback?
http
SafeNet Sentinel Keys License Monitor httpd 1.0 (Java Console)
MAC Address: 00:0C:29:07:09:3B (VMware)
Service Info: Host: HMI-1; OS: Windows
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
48
HMI-1 Evidence
[nmap udp]
root@bt# nmap -sU -sV -p U:1-65535 172.16.105.220
Starting Nmap 5.59BETA1 ( http://nmap.org ) at 2012-01-03 10:28 EST
Nmap scan report for 172.16.105.220
Host is up (0.00084s latency).
Not shown: 65527 closed ports
PORT STATE
SERVICE
VERSION
123/udp open
ntp
Microsoft NTP
137/udp open
netbios-ns Microsoft Windows NT netbios-ssn (workgroup: WORKGROUP)
138/udp open|filtered netbios-dgm
445/udp open|filtered microsoft-ds
500/udp open|filtered isakmp
1900/udp open|filtered upnp
4500/udp open|filtered nat-t-ike
6001/udp open|filtered X11:1
MAC Address: 00:0C:29:07:09:3B (VMware)
Service Info: Host: HMI-1; OS: Windows
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
49
EMS1 Evidence [netstat tcp & udp]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
50
Router Ports/Services
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
51
Manual Review of Configs
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
52
Part 1.1 Ports/Service – Sufficient Evidence
– Why?
McAfee Engine Service
What is it? EngineServer service loads instances of the Engine and DATs to facilitate scanning for the features
Email Scan, Script Scan, and the memory scan portion of On Demand Scan.
Is it required? YES - For systems belonging to the CIP Domain
IP Port numbers used: None
(https://kc.mcafee.com/corporate/index?page=content&id=KB66797)
Reference: https://kc.mcafee.com/corporate/index?page=content&id=KB59389
McAfee Framework Service
What is it? The Framework Service controls the scheduled tasks and updating portion of the VirusScan Enterprise
application.
Is it required? YES - If disabled, the McAfee VirusScan agent will not function correctly.
IP Port numbers used: https://kc.mcafee.com/corporate/index?page=content&id=KB66797
Default Port Protocol Traffic direction
8081 TCP Inbound connection to the McAfee server.
8082 TCP Inbound connection to the McAfee server.
80 TCP Outbound connection from the McAfee server.
443 UDP Outbound connection from the McAfee server.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
53
CIP-007-6 Part 1.2
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
54
CIP-007-6 Part 1.2 [Physical Ports]
High Impact
BCS
Medium
Impact BCS
PCA
PCA
Nonprogrammable
communications
equipment inside
ESP & PSP
Nonprogrammable
communications
equipment inside
ESP & PSP
P1.2
Control
Center?
Yes
Physical port protections
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
55
CIP-007-3  CIP-007-6 Change
CIP-007-3
CIP-007-6
Logical Ports only
Includes Physical Ports (R1.2) and includes nonprogrammable communications equipment
Guidance-- apply to only those nonprogrammable communication components that are
inside both an ESP and a PSP in combination, not those components that are in only one
perimeter.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
56
Configuration Ports - capability
Change Bios
Upgrade Firmware
Set Baseline Configuration
Build-out devices that have components (like
servers)
• Perform a variety of Administrative functions
• Perform emergency repair or failure recovery
when no other port is accessible
•
•
•
•
http://www.tditechnologies.com/whitepaper-nerc-cip-007-5-r1
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
57
Part 1.2 Physical Ports
• Physical I/O ports
– Network
– Serial
– USB ports external to the device casing
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
58
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
59
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
60
Part 1.2 Physical Ports - Evidence
• Documented approach to ensure unused physical
ports are controlled (identify controls in place)
• Controls in place for ensuring that attempts of
physical port usage are identified
– Think before you plug anything into one of these
systems
– Controls: 802.1x, physical plugs, port block, signage
• Physical port usage documentation – know what is
in use versus existing ports not required
• Site tours may validate physical port
documentation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
61
Port Locks
W
E
http://www.blackbox.com/resource/genPDF/Brochures/LockPORT-Brochure.pdf
E
S
T
E
R
N
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
62
Physical Access to Ports
W
E http://www.supernap.com/supernap-gallery-fullscreen/
S T E R N
E L E C T R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
63
Question
• Signage for physical port protection (CIP-007-6 R1.2) – is it
acceptable to place signs at the PSP doors, rather than on each
individual device port?
– NO, this is a device specific requirement. There must be clear notice
regarding the use of physical ports or a physical/electronic method to
ensure that ports are not inadvertently connected to a
network/device. Policies also need to be in place to control the use of
transient devices (USB stick, etc.)
• Would a Cyber Asset locked in a cage meet this requirement?
– No, the required control needs to be applied on the Cyber Asset level
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
64
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
65
CIP-007-6 Part 1.2
Is the use of tamper tape a compliant method to
address this requirement?
– It depends upon the placement. The placement
must be obvious to the asset
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
66
CIP V5 Questions with Draft Responses.pdf
– Part 1.2
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
67
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
68
Part 1.2 Audit Approach
1. Verify the entity has documented one or more processes which
address this Part.
2. Verify the list of physical input/output ports is complete and
correct.
3. Verify the list of physical input/output ports required for operations
appears correct.
4. Verify that the unnecessary physical input/output ports are
protected against use.
Protections provided to unnecessary physical input/output ports may
include, but are not limited to:
a. Logically disabling
b. Physically disabling
c. Physical signage
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
69
Part 1.2 Evidence
Sample of BES Cyber Systems:
a. The list of all BES Cyber Assets and Cyber Assets which comprise the BES
Cyber System.
b. The list of all PCA associated with the BES Cyber System.
c. The list of all nonprogrammable communication components associated
with the BES Cyber System and located inside both a PSP and an ESP
a. List of all physical input/output ports (capable of network connectivity,
console commands, or Removable Media)
b. List of all physical input/output ports (capable of network connectivity,
console commands, or Removable Media) that are required for
operations, and the basis for that requirement
c. Documentation of the protections provided to physical input/output ports
(capable of network connectivity, console commands, or Removable
Media) that are not required for operations
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
70
CIP-007-6 Part 2.1
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
71
CIP-007-3
CIP-007-6
No time frames to
implement patches
W
E
S
T
E
R
N
E
L
Patch management required actions and timelines
(R2)
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
72
CIP-007-6 Part 2.1 [Patch Process]
High Impact
BCS
P2.1
PCA
Medium
Impact BCS
Document Patch
Management process &
sources
PCA
EACM
EACM
PACS
PACS
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
73
Part 2.1 Patch Management Process
• Patch management documented process
• List of sources monitored for BES Cyber Systems and/or
BES Cyber Assets
• List of Cyber Assets and software used for patch
management
• Watching and being aware of vulnerabilities within BES
Cyber Systems, whether they use routable
communications or not, and mitigating those
vulnerabilities
• Applicable to BES Cyber Systems that are accessible
remotely as well as standalone systems
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
74
Part 2.1 Tracking
• Requirement allows entities to focus on a
monthly ‘batch’ cycle of patches rather than
tracking timelines for every individual patch
• Tracking can be on a CIP monthly basis (35
days) for all patches released that month
rather than on an individual patch basis
• Decision to install/upgrade security patch left
to the Responsible Entity to make based on
their specific circumstances
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
75
Tracking for Applicability
• Is applicability based on original source of patch (e.g.
Microsoft) or the SCADA vendor?
– Some may consider it a best practice that
vulnerabilities be mitigated in the shortest timeframe
possible, even before the patch is certified by the
SCADA vendor
– Appropriate source dependent upon the situation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
76
Vulnerability-Patch Sources
• Electricity Sector Information Sharing and Analysis Center (ES-ISAC)
– https://www.esisac.com/
• Common Vulnerabilities and Exposures
– http://cve.mitre.org/
• BugTraq
– http://www.securityfocus.com/vulnerabilities
• National Vulnerability Database
– http://nvd.nist.gov/
• ICS-CERT
– http://ics-cert.us-cert.gov/all-docs-feed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
77
Sources
W
E https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy
S T E R N
E L E C T R I C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
78
Patch Update Issues
• Cyber Security focused
– Requirement does not cover patches that are
purely functionality related, with no cyber security
impact
– Cyber Asset Baseline documentation with patch
tracking (CIP-010-2 Part 1.1.5)
– Operating system/firmware, commercially
available software or open-source application
software, custom software
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
79
Cyber Security software patches
-------- ALERT------------• Hardware vendors may provide security
patches and security upgrade to
mitigate/eliminate vulnerabilities identified in
their drivers and firmware
• These need to be patched
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
80
Graphic Driver Patch
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
81
CIS CYBER SECURITY ADVISORY
NUMBER:2014-058
DATE(S) ISSUED: 07/02/2014
SUBJECT: Multiple Vulnerabilities in Apple
Mac OS X Prior to 10.9.4
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
82
‘that are updateable’ [XP Support]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
83
Windows XP (EOL 4-8-2014)
• April 2014 there are no more security patches
forthcoming for XP
–
–
–
–
–
W
E
S
T
No Software Updates from Windows Update
No Security Updates
No Security Hotfixes
No Free Support Options
No Online Technical Content Updates
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
84
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)
W
E
C
http://www.computerworld.com/s/article/9237019/Microsoft_gooses_Windows_XP_s_custom_support_prices_as_deadline_nears?pageNumber=1
E
S
T
E
R
N
L
E
C
T
R
I
C
I
T
Y
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
85
Windows XP (EOL 4-8-2014)
• April 2014 there are no more security patches
forthcoming for XP
– No patches to assess or apply
• No patches issued means no action required
• No TFEs in R2 language
– TFEs are not required at any step in the R2 process
• Still required to track, evaluate and install security
patches outside of the OS
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
86
End of Life Evidence
Document vendor end dates
Document BCS Assets affected
Ensure latest applicable patch is implemented
Deploy mitigation measures for vulnerabilities not
able to patch
• Monitor US-CERT, and other vulnerability tracking
sites to be aware of newly identified vulnerabilities
that would affect your assets
• Where possible, implement mitigation measures for
the newly identified vulnerability
•
•
•
•
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
87
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
88
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
89
1. Verify the entity has documented one or more
processes
2. Verify the documented process(es) include provisions
for tracking, evaluating, and installing cyber security
patches
3. Verify the tracking portion of the documented
process(es) includes the identification of one or more
sources for cyber security patches
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
90
Part 2.1 Data Request
Provide identification of:
a. The operating system; or firmware
b. Identification of any commercially available software
installed on the device
c. Identification of any open-source application software
installed on the device
d. Identification of any custom software installed on the device
Software identified:
a. Name or other identification of the software installed
b. Version, release number, and/or revision date of the
software installed
c. Identification of the source being tracked for cyber security
patches, or documentation that no patch source exists
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
91
[CIP-007-6 Part 2.1] Audit Approach – what
are we looking for?
•
Documented procedures for the tracking, evaluating, testing and implementing of
patches and updates
•
Evidence of monitoring of all installed software and firmware
– Develop a list of all monitored applications/OS/firmware
– Identify and document process and location for notifications of updates
– Look to vendors where possible
•
Evidence of identification and evaluation of applicability within 35 days of availability
•
Evidence of implementation of patches as defined in documented procedures,
evidence of testing prior to release to production
•
Evidence of the patch analysis and implementation of compensating measures if
applicable patch/updates will not be implemented within 30 days
– Risk of NOT implementing patches/updates – expectation of implementation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
92
• Provide evidence of Cyber Security patch
management tracking for the audit period for the
following devices …
• Provide list of all software (OS, firmware,
applications) being monitored for security
updates/patches and method used for
monitoring
• Provide evidence of security patch assessment of
applicable systems within 35 days
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
Questions
93
• Describe your patch management process
• What technical and procedural controls are in
place?
• Describe the process to determine if a security
patch/update is applicable
– Are vendors involved with the determination?
• Describe the decision process to decide if an
update/patch will be installed
• What is the process if an applicable patch will not
be installed?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
94
Insufficient Evidence – Why?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
95
Sufficient Evidence – Why?
• Software listings
• Patch sources
• Assessment procedure – who, what, when,
how, --timing, criteria
• Assessment results and rationale
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
96
CIP-007-6 Part 2.2 Patch Evaluation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
97
CIP-007-6 Part 2.2 [Patch Evaluation]
High Impact
BCS
P2.1
PCA
EACM
Medium
Impact BCS
Document Patch
sources
PCA
EACM
P2.2
Documented Patch
evaluation (max 35 days)
PACS
PACS
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
98
Part 2.2 Patch Evaluation
• At least every CIP Month (35 days) evidence of patch release monitoring
and evaluation of patches for applicability
• Evaluation Assessment
– Determination of Risk
– Remediation of vulnerability
– Urgency and timeframe of remediation
– Next steps
• Entity makes final determination for their environment if it is more of a
reliability risk to patch a running system than the vulnerability presents
– Listing of all applicable security patches
– Date of patch release, source, evaluation performed, date of
performance and results
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
99
Guidelines
• DHS
– “Quarterly Report on Cyber Vulnerabilities of Potential Risk to
Control Systems”
• http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_1339_Feb13.pdf
– “Recommended Practice for Patch Management of Control
Systems”
• http://ics-cert.uscert.gov/sites/default/files/recommended_practices/Patch
ManagementRecommendedPractice_Final.pdf
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
100
Vulnerability Footprint
W
http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf
E S T E R N
E L E C T R I C I T Y
C O O R D I
N
A
T
I
N
G
C
O
U
N
C
I
L
101
CIP V5 Questions with Draft Responses.pdf
– Part 2.2
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
102
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
103
Audit Approach
Verify that security patches from the patch
source have been evaluated for applicability at
least once every 35 calendar days during the
audit period
Verify the results of the evaluations –
documented results
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
104
For each patch source identified, provide the following:
a. Identification of each security patch released by each
patch source during the audit period, including the date
of release;
b. Evidence of the evaluation of each security patch for
applicability, including:
i. Date of evaluation
ii. Results of the evaluation (i.e., applicable or not
applicable)
iii. If not applicable, the reason the patch is not
applicable
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
105
Sample Interview Questions
•
•
•
•
Describe the patch management process
Describe the evaluation criteria
Describe patch source identification process
Describe the patch identification process for asset
types:
–
–
–
–
W
E
S
T
BCA
EACM
PACS
PAs
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
106
Part 2.2 Patch Evaluation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
107
Evidence – Sample spreadsheet
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
108
CIP-007-6 Part 2.3
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
109
CIP-007-6 Part 2.3 [Patch Response]
High Impact
BCS
P2.1
PCA
EACM
Medium
Impact BCS
Document Patch
sources
PCA
EACM
P2.2
Documented Patch
PACS
Required
patch
identified?
YES
P2.3 Within 35
days
PACS
NO
Implement
Plan within
time frame
Install patch
OR
OR
W
E
S
T
E
R
Create Mitigation
plan
Update Mitigation
plan
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
110
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.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
111
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
112
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
113
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
114
Timeframe
• Timeframe is 70 days total
– 35 days for tracking and determining applicability
– 35 days for either installing or determining the
mitigation plan
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
115
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
116
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”
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
117
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
118
1.
For each applicable security patch, verify that one of the following actions was
taken within 35 calendar days of the completion of the evaluation for
applicability:
a.
b.
c.
2.
The patch was applied to all devices for which it is applicable; or
A mitigation plan was created; or
A mitigation plan was revised.
In the case where a mitigation plan was created or revised:
a.
Verify the mitigation plan addresses each vulnerability addressed by the security
patch;
Verify the mitigation plan is sufficient to mitigate each vulnerability addressed by the
security patch;
Verify the mitigation plan includes a timeframe for completion;
Review the timeframe specified by the mitigation plan to determine if it results in
mitigation of each vulnerability within a reasonable period; and
If the mitigation plan is complete, verify the mitigation plan was completed within the
timeframe specified by the mitigation plan, or within the approved extension period
per Part 2.4.
b.
c.
d.
e.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
119
1. Provide the following:
a. Identification of each security patch released by each patch source during the
audit period
b. The date of completion of the evaluation of each applicable patch; and
c. A list of the devices comprising or associated with the BES Cyber System for
which each patch is applicable
2. Provide evidence of the action taken regarding the patch:
a. For each device to which the patch was applied provide:
i. Evidence of the application of the patch
ii. Evidence of the date the patch was applied
b. If the patch was not applied to all devices comprising or associated with
the BES Cyber System for which the patch is applicable, provide:
I. The associated mitigation plan
II. The implementation status of the mitigation plan
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
120
• Describe the patch assessment process
• Describe the patch implementation process
• Describe the Mitigation Plan documentation
process – why, what, who, when
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
121
Performance Notes
• Results-based Requirement: The end result of this
Requirement must be the mitigation of vulnerabilities
addressed by applicable security patches. The entity has
been granted wide latitude by the language of the
Requirement regarding how this result is accomplished. It is
the function of the auditor to verify that the end result is
sufficient to protect the BES.
• Implementation Timelines: Due to the large variety of
circumstances to which this Requirement may apply, there
is no specific requirement regarding the time to
implement a mitigation plan. The auditor must use
professional judgment to accept or express concern over
the time frame to implement mitigation plans.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
122
Part 2.3 Audit Evidence Examples
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
123
Part 2.3 Audit Evidence Examples
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
124
CIP-007-6 Part 2.4
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
125
CIP-007-6 Part 2.4 [Mitigation Plan]
High Impact
BCS
P2.1
PCA
EACM
Medium
Impact BCS
Document Patch
sources
PCA
EACM
P2.2
Documented Patch
PACS
Required
patch
identified?
YES
P2.3 Within 35
days
PACS
NO
P2.4
Implement Plan
within time frame
Install patch
OR
OR
W
E
S
T
E
R
Create Mitigation
plan
Update Mitigation
plan
N
E
L
E
C
T
R
CIP SM or Delegate
approval
I
C
I
T
Plan
P2.4 Revision or
Extension?
Y
C O O R
YES
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
126
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
127
Part 2.4 Implement
• The ‘implement’ in the overall requirement is
for the patch management process
– ‘Implement’ in Part 2.4 (Mitigation Plan) is for the
individual patch
– If Part 2.4 does not have an implement
requirement at the patch level, then the
‘implement’ in the overall requirement only
applies to drafting a plan
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
128
W
For each completed mitigation plan:
1. Verify the mitigation plan was completed by implementing all
provisions of the mitigation plan;
2. Verify the mitigation plan was completed within the specified
timeframe.
3. If a revision or an extension was made to a mitigation plan, verify the
revision or extension was approved by the CIP Senior manager or
delegate.
4. For each active mitigation plan:
a. Verify the mitigation plan has not exceeded its implementation
timeframe, or its approved extension, if any.
b. If a revision or an extension was made to a mitigation plan, verify
the revision or extension was approved by the CIP Senior
manager or delegate.
c. If one or more of the “verify” steps above fails, a finding of
Possible Violation should be returned.
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
129
For each mitigation plan identified, provide the following:
a. The mitigation plan;
b. The status of the mitigation plan (i.e., completed or
active);
a) For completed mitigation plans:
i. Evidence of the work performed to complete the
mitigation plan;
ii. Evidence of the completion date of the mitigation
plan.
b) For active mitigation plans:
i. Evidence of the status of the mitigation plan;
ii. The expected completion date of the mitigation
plan.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
130
Part 2.4 Evidence
Mitigation Plan with signed Senior Manager
approval
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
131
R2 Issues & Pitfalls
• Asset level requirements
• Know, track, and mitigate the known software vulnerabilities
associated with BES Cyber Assets, Pas, EACMS and PACS
• Include 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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
132
CIP-007-6 Part 3.1
BES Cyber System level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
133
CIP-007-3
CIP-007-6
AV on ALL cyber assets or
TFE
W
E
S
T
E
R
N
E
L
E
C
T
Malicious code controls can be at cyber system level,
rather than per asset (R3)
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
134
CIP-007-6 Part 3.1 [Malicious Code]
High Impact
BCS
Medium
Impact BCS
P3.1
Deploy method(s) to deter,
detect, or
prevent malicious code.
PCA
PCA
EACM
EACM
PACS
PACS
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
135
Part 3.1 Malicious Code
• Deter OR detect OR prevent - any one or combination
will meet the wording of the requirement
– Avoids zero-defect language
– Part 3.2 requires ability to detect malicious code (also
Part 4.1.3 requires detection)
• Methods = processes, procedures, controls
• Applicability is at the ‘system’ level
– Methods do not have to be used on every single Cyber
Asset
• Allows entities to adapt as the threat changes while also
reducing the need for TFEs
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
136
Part 3.1 Guidance
• “… the Responsible Entity determines on a BES
Cyber System basis which Cyber Assets have
susceptibility to malware intrusions and
documents their plans and processes for
addressing those risks and provides evidence that
they follow those plans and processes. There are
numerous options available including traditional
antivirus solutions for common operating
systems, white-listing solutions, network isolation
techniques, Intrusion Detection/Prevention
(IDS/IPS) solutions, etc.”
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
137
AV/Anti-Malware
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
138
20140725 - FAQ - CIP-007-6 R3
What constitutes malicious code detection for relays which
are not computers and do not have an operating system
where traditional antivirus software can be applied?
To demonstrate compliance a Registered Entity should track its firmware
versions and keep firmware versions current from the vendor, particularly any
upgrades having to do with security enhancements. This combined with a
demonstrated security model for securing both physical and logical access to
these Cyber Assets, including logging, is a sufficient deterrence program
aimed at preventing malware introduction or firmware code
injection. Contact with the vendor and knowledge of evolving product lines
with more security options should also be considered and documented.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
139
CIP-007-6 R3
• For the implementation of malicious code prevention,
should entities choose to deter, detect, or prevent
malicious code? If an entity chooses to deter, how
should they plan on complying with 3.2 since there
would be no mechanism to detect?
– Best practice is to perform all three, however the
requirement allows for choosing which technology will be
implemented. However, Part 3.2 “requires” detection
capabilities, if deter is the choice as above, there must be
additional capabilities to detect as well, to meet
requirement 3.2. Therefore, the minimum must include
detection capabilities.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
140
CIP-007-6 R3
• How did pilot participants provide malicious
code prevention and collect logs for security
event monitoring where there was no external
routable protocol? Or, in general, what issues
did the pilot participants find in trying to
become V5 compliant for substations with
serial communications?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
141
Defense-N-Depth
W
Ehttps://www.lumension.com/vulnerability-management/patch-management-software/third-party-applications.aspx
S T E R N
C O O R D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
142
Application Whitelisting
• Identifying specific executable and software
libraries which should be permitted to execute
on a given system
• Preventing any other executable and software
libraries from functioning on that system
• Preventing users from being able to change
which files can be executed
W
E http://www.asd.gov.au/publications/csocprotect/application_whitelisting.htm
S T E R N
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
143
Application Whitelisting
•
•
•
•
•
•
•
•
W
E
Application File Attributes
Digital Certificates
File Hash
File Ownership
Location
Reference Systems
Signed Security Catalogs
Software Packages
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
144
Guidelines
• Network isolation techniques
• Portable storage media policies
• Intrusion Detection/Prevention (IDS/IPS)
solutions
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
145
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
146
‘Associated PCAs’
• Associated PCAs’ are included at a Cyber Asset
(device) level, not system level
• How will the ‘system’ concept apply?
– Malware prevention is at a BCS level
– The associated PCA’s could be included by
reference in the documentation an entity supplies
for Requirement Part 3.1
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
147
CIP-007 FAQ
Question:
What is “malware?”
Answer:
Malware generally means malicious software such as viruses, worms, timebombs, and Trojan horses. This software may be distributed through email
attachments, unsecured remote procedure calls, Internet downloads, and
opening infected files. Malware may delete or modify files, attempt to crack
passwords, capture keystrokes, present unwanted pop-ups on screen, fill-up
disc space, or other malicious and destructive activity, without the
authorization or knowledge of the person using the infected computer.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
148
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
149
1. Verify the entity has documented one or more processes which address this Part
2. Verify that each device comprising the BES Cyber System has one or more
methods documented and deployed to deter, detect, or prevent malicious code
3. Verify that each EACMS, PACS, and PCA associated with the BES Cyber System has
one or more methods documented and deployed to deter, detect, or prevent
malicious code
Note:
• System Approach: The intent of the requirement is that the BES Cyber System as a
whole has malware prevention deployed
• Each individual component is not required to have the same protection
• Not all components will be vulnerable to malware. Of those that are, differing
protections may be appropriate for each type of device.
– For example, a firmware-based device may not be vulnerable to malware if its
USB port is protected, such that only authorized personnel may update the
firmware. This protection could be considered sufficient to deter the
introduction of malicious code.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
150
are we looking for?
Documentation of the AV/anti-malware technical and procedural controls in
place
Evidence that each device comprising the BES Cyber System, EACMS, PACS and
PAS has one or more methods documented and deployed to deter, detect, or
prevent malicious code
Identification of all Cyber Assets that are unable to run AV/anti-malware
– What appropriate compensating controls are in place
Validate real-time scanning is active or performed on an appropriate cycle where
applicable
Validate that users cannot disable the AV or anti-malware or have alert
mechanism to monitor
Validate that signature updates are being performed on a regular basis after
defined testing is performed
Evidence that AV alerts are generated and notification is performed
Evidence of defined procedures to respond to virus or malware alerts
•
•
•
•
•
•
•
•
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
151
[CIP-007-6 Part 3.1] Interview Topics
• Describe your AV/anti-malware technical and procedural
controls for all BCS assets and associated Pas, EACMs and
PACS
• Is the AV/anti-malware application at the current release
version
• What is the testing and approval process for AV signature
updates?
• How current are the signature files? How long of delay
between release and implementation?
• How often is the application updated?
• Are “Application Whitelist” techniques used?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
152
Part 3.1 Audit Evidence – Needs update
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
153
Part 3.1 AV/Ant-Malware Status
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
154
CIP-007-6 Part 3.2
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
155
CIP-007-6 Part 3.2 [Threat Mitigation]
High Impact
BCS
Medium
Impact BCS
P3.1
Deploy
method(s) to deter,
detect, or
PCA
PCA
EACM
EACM
PACS
PACS
P3.2
Mitigate the threat of
detected
malicious code.
Requires processes
Requires evidence of
processes utilized
•
•
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
156
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
157
CIP-007-6 R3
Clarify that entities are required to mitigate the
threat of detected malicious code regardless of
the methods they choose to deter, detect, or
prevent malicious code (Part 3.1)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
158
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
159
1. Verify the entity has documented one or more processes which
address this Part
2. Verify the entity uses one or more methods to detect malicious
code
3. For each instance of detected malicious code reviewed, verify the
mitigating steps taken are consistent with the process and mitigate
the threat of the malicious code
Results-based Requirement: The Requirement assumes malicious code
will be detected – the entity is therefore required to do so, but the
approaches used to perform this detection are not specified.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
160
List of all instances of detected malicious code,
including:
1. Type of malicious code detected
2. Date the malicious code was detected
3. Devices affected by the malicious code, if any
4. Method of detection
5. Mitigation actions taken
6. Date the mitigation actions were taken
7. If the threat of the detected malicious code has not
been fully mitigated, the action plan, including
timetable, to complete the mitigation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
161
Part 3.2 Sample Interview Questions
• Describe the malicious code identification and
mitigation processes
• Have there been malicious code events
identified?
• Have there been malicious code events that
have not been mitigated?
• Have mitigation activities been performed?
Please describe these efforts.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
162
Part 3.2 Evidence
• Documentation of events
• Mitigation processes completed
• How does the mitigation efforts specifically
address the malicious code
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
163
CIP-007-6 Part 3.3
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
164
CIP-007-6 Part 3.3 [Signature Updates]
High Impact
BCS
Medium
Impact BCS
P3.1
Deploy
method(s) to deter,
detect, or
PCA
PCA
EACM
EACM
PACS
PACS
P3.2
P3.3
Signature or
pattern based
controls?
Mitigate the threat of
detected
malicious code.
Requires processes
Requires evidence of
processes utilized
•
•
R3.3
W
E
S
T
E
R
N
Requires process for
updates
E
L
E
C
T
R
I
C
I
Requires processes that
address:
• Testing
T • Y Installation
C O O R D I
N
A
T
I
N
G
C
O
U
N
C
I
L
165
Requires process for updates
• Requires processes that address:
• Testing
• Does not imply that the entity is testing to ensure that malware
is indeed detected by introducing malware into the
environment
• Ensuring that the update does not negatively impact the BES
Cyber System before those updates are placed into production
• Installation
• No timeframe specified
• Requirement Part 3.1 allows for any method to be used and does not
preclude the use of any technology or tool
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
166
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?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
167
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
168
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
169
Audit Approach
• Verify the entity has documented one or more
processes to address this Part
• Verify the processes address testing and
installing updates to signatures or patterns
• Verify the processes are implemented
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
170
Data Request
• All applicable documented processes for
implementation
• List of all methods used to deter, detect, or prevent
malicious code which use signatures or patterns
• For each method used to deter, detect, or prevent
malicious code which uses signatures or patterns,
provide the process used to update the signatures or
patterns
• For each method used to deter, detect, or prevent
malicious code which uses signatures or patterns,
provide evidence of the implementation of each
process.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
171
• Describe the procedures for testing of
signatures prior to implementation
• How often are the signatures updated?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
172
Part 3.3 Evidence
• Documented signature testing and updating
procedures
• Evidence of performance of the signature
testing
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
173
•
•
•
•
•
•
W
E
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
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
174
CIP-007-6 Part 4.1
BES Cyber System and/or Asset level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
175
CIP-007-6 Part 4.1 [Event logging]
High Impact
BCS
P4.1
Deploy cyber security event
logging capabilities
PCA
EACM
E
S
PCA
EACM
4.1.1. Detected successful login Attempts;
4.1.2. Detected failed access attempts
and failed login attempts;
4.1.3. Detected malicious code.
PACS
W
Medium
Impact BCS
PACS
BES Cyber System and/or Asset level requirement
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
176
CIP-007-3
CIP-007-6
Security logs
Identification of specific log collection events (P4.1)
Sampling and or
summarization not
mentioned
Log reviews for High impact Cyber Systems can be
summarization or sampling (P4.4)
CIP-007-3
CIP-007-6
Log reviews for High Impact Cyber Systems must
be reviewed every 15 days (P4.4)
Log reviews every 90 days
when applicable
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
177
Part 4.1 Log Events
W
•
Entity determines which computer generated events are necessary to log (beyond
minimum required), provide alerts and monitor for their particular BES Cyber
System environment
•
Logging is required for both local access at the BES Cyber Systems themselves, and
remote access through the EAP
•
Evidence of required logs (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
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
178
Part 4.1 Log Events
• Types of events
• Requirement does not apply if the device does not
log the events
– Devices that cannot log do not require a TFE
– logging should be enabled wherever it is available
• 100% availability is not required
– Entity must have processes in place to respond to
logging outages in a timely manner
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
179
Part 4.1 Log Events
• For system event monitoring, per 4.1, should entities log at a system level?
If so, how is it recommended that they monitor at that level?
– The requirement does not explicitly define which one to use; system
level or asset level logging. The entity has the option to do one or the
other or both, based upon asset capabilities. Typically, these logs are
sent to a syslog or SIEM device for log aggregation and analysis
• How should entities provide capability proof for 4.1?
– this is usually provided via log aggregation systems (syslog, SIEM).
Configuration files and manual log reviews may also help to provide
proof of performance.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
180
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
181
If logging is performed at the BES Cyber System level, for each sampled BES Cyber System
and associated EACMS, PACS and PCA:
1. For each of the following event types: successful login attempts, failed access
attempts, failed login attempts, and detected malicious code, verify:
a. The BES Cyber System or associated device is capable of, and configured for,
logging the event type; or
b. The BES Cyber System or associated device is not capable of logging the event
type.
2. Verify logs are being generated by the BES Cyber System and associated device.
If logging is performed at the Cyber Asset level, for each Cyber Asset comprising the
sampled BES Cyber System and associated EACMS, PACS and PCA:
1. For each of the following event types: successful login attempts, failed access
attempts, failed login attempts, and detected malicious code, verify:
a. The Cyber Asset or associated device is capable of, and configured for,
logging the event type; or
b. The Cyber Asset or associated device is not capable of logging the event
type.
S T EVerify
R N logs
E are
L E being
C T R generated
I C I T Y by the
C OCyber
O R DAsset
I N and
A T associated
I N G
C devices.
O U N C I
W E 2.
L
182
Indication of whether logging is performed at the BES Cyber System level or the Cyber Asset level.
1. If logging is performed at the BES Cyber System level:
a. Provide evidence of the types of logging events enabled for the BES Cyber Systems, EACMS,
PACS and associated PCAs
b. If any component of the BES Cyber System or any associated device is not capable of
logging at least the required event types, provide evidence of the lack of capability.
c. Provide evidence that logs for the BES Cyber System, EACMS, PACS and associated PCAs are
being generated.
2. If logging is performed at the Cyber Asset level:
a. Provide evidence of the types of logging events enabled for each Cyber Asset comprising
the BES Cyber System, EACMS, PACS and associated PCAs
b. If any component of the BES Cyber System or any associated device is not capable of
logging at least the required event types, provide evidence of the lack of capability.
c. Provide evidence that logs for the BES Cyber Asset, EACMS, PACS and associated PCAs are
being generated.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
183
• Provide evidence that all cyber assets security monitoring logs are
enabled. [sample list]
• Provide evidence of security event logging for [period of time] – failed
logins, etc.
• Provide security alerts and alert contact list for [period of time]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
184
are we looking for?
• Evidence that all cyber assets (BCA, EACMS,
PACS, PAS) are enabled for logging (if feasible)
for required security events
– Consider using a central Syslog server when
possible – aggregation of devices logs – easier to
review
– Consider implementing a Security Information and
Event Management (SIEM) tool (provides logging,
monitoring and alerts)
– Ensure OS and critical application logs are included
in logging
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
185
Questions
• Describe the logging and monitoring tools and
procedures
• Describe the log monitoring for required
events
• Describe the Alerting tools and response
procedures – triggers, who receives, what
response required, escalation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
186
Part 4.1 Evidence
• Device configurations for logging of required
events
• Examples of required events being identified
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
187
Part 4.1 Good Evidence
188
User Access Log [sample]
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
189
Manual Review of Configs [logging]
#show run
…
no logging
ip http server
!
access-list 23 permit 172.16.105.200 0.0.0.0
access-list 23 permit 172.16.105.201 0.0.0.0
!
line vty 5 15
transport input ssh
!
access-class 23 in
!
no logging console
debug condition interface
no snmp-server
ntp-server 172.16.105.88
...
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
190
CIP-007-6 Part 4.2
BES Cyber System and/or Cyber Asset (if supported)
level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
191
CIP-007-6 Part 4.2 [Alerts]
P4.1
High Impact
BCS
Medium
Impact BCS
PCA
PCA
EACM
PACS
EACM
External
Routable
Connectivity?
P4.2
PACS
YES
alert capabilities
4.2.1. Detected malicious code
4.2.2 Detected failure of event logging
BES Cyber System and/or Cyber Asset (if supported)
level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
192
Part 4.2 Alerting
• Detected known or potential malware or malicious
activity (Part 4.2.1)
• Failure of security event logging mechanisms (Part
4.2.2)
• Alert Forms
– Email, text, system display and alarming
• Alerting Examples
– Failed login attempt
– Virus or malware alerts
– Failure of logging
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
193
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
194
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
195
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
196
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
197
Audit Approach
processes which address this Part
• Verify the list of security events determined to
necessitate an alert includes:
– 1. Detected malicious code
– 2. Detected failure of logging
• Verify the security events determined to
necessitate an alert are configured to generate an
alert
• Verify alerts are being generated for applicable
security events
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
198
1. The list of security events determined to necessitate
an alert and at a minimum includes:
a. Detected malicious code
b. Detected failure of logging
2. Evidence that such detected security events are
configured to generate an alert
3. Evidence that such detected security events generate
an alert
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
199
• Describe the alert processes
• Describe the alert configurations for required
asset types
• Describe the alert types and required
responses
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
200
Part 4.2 Evidence
• Procedures for alert configuration setup that
meet the minimum requirements
• Configuration settings and alert thresholds
• Evidence of alerts being generated
• Documented responses to alerts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
201
202
CIP-007-6 Part 4.3
BES Cyber System and/or Cyber Asset (if
supported) level requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
203
CIP-007-6 Part 4.3 [Log Retention]
P4.1
High Impact
BCS
Medium
Impact BCS
PCA
PCA
EACM
PACS
EACM
External
Routable
Connectivity?
P4.2
PACS
YES
alert capabilities
Control
Center?
P4.3
90 day log retention
YES
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
204
Part 4.3 ‘Retain Applicable Event Logs’
• Timeframe:
– Response timeframe begins with the alert of the
failure
– After something or someone has detected the failure
and has generated an alert as in Part 4.2
– For the compliance period, the applicable cyber
systems maintain 90 days of logs. (All High BCS as well
as Medium BCS at Control Center)
• Retention methods are left to Responsible Entity
– On or before April 15, 2016
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
205
Part 4.3 ‘Retain Applicable Event Log’s’
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
206
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
207
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
208
Audit Approach
• Documented procedures to meet the required Parts
• For each BES Cyber System and its associated EACMS,
PACS, and PCA, verify logs are retained for at least 90
calendar days unless:
– An approved TFE covers one or more of the devices. If this
applies, verify the TFE’s compensating measures are in
place, and review the log retention for the devices not
covered by the TFE
– A documented CIP Exceptional Circumstance exists. If this
applies, review the log retention for devices and
timeframes not covered by the CIP Exceptional
Circumstance.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
209
• Provide documented procedures to ensure 90 days of logs
are maintained as required
• Provide evidence that logs pertaining to the BES Cyber
System and its associated EACMS (including EAP), PACS,
and PCA are retained for at least 90 calendar days for all
High impact systems and Medium Control Center devices
• Provide evidence that the 90 day log requirement has
been maintained for the audit period
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
210
• Describe the log retention procedures for
required assets for 90 days
• Describe the log management processes for
logs greater than 90 days to show compliance
for the audit period
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
211
Part 4.3 Evidence
• Log retention procedures
• Reports showing log management
• Evidence of audit period compliance – log file
procedures fro grater than 90 days
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
212
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
213
CIP-007-6 Part 4.4
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
214
CIP-007-6 Part 4.4 [Log Review]
P4.1
High Impact
BCS
Medium
Impact BCS
PCA
PCA
EACM
PACS
EACM
External
Routable
Connectivity?
P4.2
PACS
YES
alert capabilities
P4.3
Control
Center?
90 day log retention
YES
PCA
P4.4
EACM
W
E
S
T
On or before
April 14, 2016
Log event reviews (15 days)
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
215
Part 4.4 Review Logs Guidelines
High Impact BCS/BCA, associated EACMS and PAs
• Summarization or sampling of logged events
– log analysis can be performed top-down starting
with a review of trends from summary reports
– Determined by the Responsible Entity
• Electronic Access Points to ESP’s are EACMs, this is
one of the primary logs that should be reviewed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
216
Part 4.4 Review Logs
• Purpose is to identify undetected security incidents
• Paragraph 525 of Order 706
– Even if automated systems are used, the manual review is
still required
– Manually review logs ensure automated tools are tuned
and alerting on real incidents
• What if an entity identifies events in Part 4.4 that
should have been caught in Part 4.1 is this a
violation?
– NO, modify event setting to include newly identified event
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
217
Cloud Computing
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
http://www.ipspace.net/Webinars
C
O
U
N
C
I
L
218
Monitoring-as-a-Service
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
Thttp://www.symantec.com/content/en/us/enterprise/other_resources/b-nerc_cyber_sercurity_standard_21171699.en-us.pdf
Y
C O O R D I N A T I N G
C O U N C I L
219
Part 4.4 Issues & Pitfalls
• Ensure all EACMs are identified
– “Cyber Assets that perform electronic access control or
electronic access monitoring of the Electronic Security
Perimeter(s) or BES Cyber Systems. This includes
Intermediate Systems.’ – NERC glossary
• Documentation of log collection architecture
– Log collection data flows
– Aggregation points
– Analysis processes and/or technologies
• Validation of the required logs and alert configurations
• 15 day review documentation
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
220
1. Verify the entity has documented one or more
processes
2. Verify the entity reviews a summary or sampling of
logged events
3. Verify the entity reviews logged events at least every
15 calendar days
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
221
For each BES Cyber System, provide:
1.The process or method used to review
logged events.
2.For each calendar month selected, provide
evidence of the review of logged events at
least every 15 calendar days
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
222
• Describe the procedures for reviewing logs as
required
• Describe the log selection procedures for
review of logs
• How is the 15 day review ensured?
• Describe the review process and evidence
documentation
• Have there been findings of events that were
previously unidentified?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
223
Part 4.4 Evidence
•
•
•
•
W
E
Log selection evidence
Evidence of log review performance
Evidence of issues identified
Foe identified issues what are the mitigation
plans to ensure the events are identified prior
to the log reviews
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
224
Part 4.4 Evidence
• Procedures
• Evidence of reviews – validating the 15 day
maximum review timeframes
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
225
Part 4.4 Log Review Evidence
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
226
227
CIP-007-6 Part 5.1
W
E
S
T
BES Cyber System and/or Cyber Asset level
requirement
E R N
C O O R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
228
CIP-007-6 Part 5.1 [Authentication]
P5.1
High Impact
BCS
Medium
Impact BCS
Enforce Authentication
for interactive access
PCA
PCA
YES
EACM
EACM
External
Routable
Connectivity?
PACS
PACS
YES
Control
Center?
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
229
CIP-007-3 CIP-007-6 Highlights
CIP-007-3
W
E
CIP-007-6
TFE required for devices that
cannot meet password
requirements
Password requirement may be limited to device
capabilities as opposed to filing TFE (P5.5)
Not specified in V3
Failed access threshold and alerts (P5.7)
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
230
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
231
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
232
Audit Approach
processes which address this Part.
methods to enforce authentication of interactive
user access.
• Verify either:
– The entity has implemented the method(s) to enforce
authentication of interactive user access, or
– An approved TFE is in place. If a TFE is in place, verify
the compensating measures have been implemented
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
233
For each BES Cyber and the associated EACMS (including
EAP), PACS, and PCA, provide the following:
1. Evidence of the method(s) used to enforce
authentication of interactive access.
2. Evidence of the implementation of the method(s)
used to enforce authentication of interactive access.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
234
• Describe the process to ensure authenticated
interactive access to required cyber assets is
enforced
• Identify the controls to enforce
authentication for all interactive access
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
235
Part 5.1 Evidence
• Procedures for implementation of
authenticated interactive access
• Evidence of controls in affect
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
236
Part 5.1 Enforce Authentication
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
237
CIP-007-6 Part 5.2
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
238
CIP-007-6 Part 5.2 [Default/Generic Accounts]
Enforce Authentication for
interactive access
P5.1
High Impact
BCS
Medium
Impact BCS
P5.2
PCA
PCA
Identify & inventory default
and generic accounts
EACM
EACM
External
Routable
Connectivity?
YES
PACS
PACS
YES
Control
Center?
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
239
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-6
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
240
CIP-007-6 Part 5.2 Question
• How did pilot participants treat the devices
that do not have accounts but use separate
passwords to delineate the role the user has?
(substations)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
241
CIP-007 Part 5.2 Question
W
•
How should entities approach inventorying all known enabled default or generic account
types?
– There are a number or ways to identify default and/or generic accounts. Typically the
vendors will provide listing of the required accounts on a system. Also, there are tools
that can be run to identify user accounts created on a local system. The AD also, will
have listing of accounts with access to systems. It is not uncommon for EMS operators
to use shared accounts. Talking with the operators will identify these shared accounts.
Another method is to review the device/application web sites or support to identify if
there are default accounts
•
Are password safe’s recommended?
– Although WECC does not give specific recommendations of vendor tools, we have seen
successful utilization of this technology during our audits.
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
242
CIP-007 Part 5.2 Question
• Do assets in use for years (e.g. relays installed 6 years ago) have to
have be current with security patches and does every security patch
in history for the device need to be documented. If not, how far
back does an entity need to go?
– It has always been recommended that patch management be applied
to any critical devices that can affect the BES. However, with V5,
patch/firmware management is a requirement (CIP-007-6 Part 2). If
these assets are now being brought into V5 compliance, then when V5
is in effect, or the entity has officially stated that according to the
approved implementation plan they are moving to V5, then the
patch/firmware management must be in place. This will require a
baseline be established and it would be expected that the assets be
updated to current firmware that has security related updates to the
device. It would not be required to go back to the initial
implementation of the device and implement and document all
patches/firmware since the asset was installed into production.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
243
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
244
Audit Approach
• Verify the entity has identified and inventoried
all known or enabled generic accounts.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
245
For each BES Cyber System and associated EACMS
(including EAP), PACS, and PCA, provide the following
evidence:
1. The inventory of all known default or generic account
types
2. Evidence of the status (i.e., enabled or disabled) of
each account in the inventory.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
246
• Describe the account management
procedures to include default and shared
accounts
• Procedure to ensure identification of default
and shared accounts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
247
Evidence
• Procedures documentation
• Listing of default and shared accounts
• Identification of all users with access to the
default and shared accounts
• Password management of default and shared
accounts
• Evidence of default and shared account access
reviews
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
248
SEL 351R Meter Access Levels
Higher access level can access the serial port commands in a lower access
level.
–
–
–
–
–
–
–
Access Level 0 (the lowest access level)
Access Level 1
Access Level E (EZ access level)
Access Level B
Access Level 2 (the highest access level)
Access Level C (restricted access level; should be used under
direction of SEL only)
• As a security measure, entry to a particular access level (except Access
Level 0) requires a unique password. This allows the user to set up a
password system to deny unqualified or unauthorized personnel access to
higher levels.
• SEL document from website: 351R-4_QS_20140207.pdf
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
249
CIP-007-6 Part 5.3
W
E
S
T
requirement
E R N
C O O R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
250
CIP-007-6 Part 5.3 [Shared account access]
interactive access
P5.1
High Impact
BCS
Medium
Impact BCS
P5.2
PCA
PCA
Identify &inventory default
EACM
P5.3
YES
Identify individuals with
access to shared accounts
PACS
EACM
External
Routable
Connectivity?
PACS
YES
Control
Center?
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
251
Part 5.3 Identify Individuals
• CIP-004-5 to authorize access
– Authorizing access does not equate to knowing
who has access to a shared account
• “authorized”
– An individual storing, losing or inappropriately
sharing a password is not a violation of this
requirement
• Listing of all shared accounts and personnel
with access to each shared account
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
252
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
253
For each BES Cyber System and the associated EACMS
(including EAP), PACS, and PCA, provide the following
evidence:
1. The list of individuals with authorized access to shared
accounts.
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
254
• Describe the procedures to assign and track all
users with access to shared accounts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
255
Part 5.3 Evidence
• Procedures documentation
• Listing of default and shared accounts
• Identification of all users with access to the
default and shared accounts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
256
CIP-007-6 Part 5.4
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
257
CIP-007-6 Part 5.4 [Default passwords]
interactive access
P5.1
High Impact
BCS
Medium
Impact BCS
P5.2
PCA
PCA
EACM
P5.3
YES
PACS
EACM
External
Routable
Connectivity?
P5.4
PACS
YES
Change default passwords
Control
Center?
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
258
Part 5.4 Known
– Cases where the entity was not aware of an
undocumented default password by the vendor
would not be a possible violation
– Once entity is made known of this default
password may require action per CIP-007-6 R2
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
259
Part 5.4 Timeframe
• When is a default password required to be changed?
– No timeframe specified in requirement
• As with all requirements of CIP-007-6, this
requirement must be met when a device
becomes one of the applicable systems or
assets
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
260
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
261
Audit Approach
processes which address this Part.
• For devices with the ability to change default
passwords, verify the entity has changed the
default passwords
• For Cyber Assets that do not have the ability
to change default passwords, verify the
inability to do so
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
262
• For each BES Cyber System and the associated EACMS
(including EAP), PACS, and PCA, provide:
1. Evidence of change of the known default
password(s) for each device
2. For Cyber Assets that do not have the ability to
change one or more default passwords, provide
evidence of the inability to change the passwords
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
263
• Describe the password management
procedures for shared accounts
• Are there any shared accounts that do not
allow for password changes?
• How are the above assets managed?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
264
R5.4 Evidence
• Password management procedures for shared
accounts
• Evidence of shared account default password
management
– Logs
– Change Control
– Reports
– Tool output – last password change date
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
265
SEL Relay Default Accounts/Passwords
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
266
SEL Relay Default Accounts/Passwords
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
267
Part 5.4/5.5 Good Evidence
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
268
Part 5.4/5.5 Good Evidence
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
269
CIP-007-6 Part 5.5
W
E
S
T
requirement
E R N
C O O R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
270
CIP-007-6 Part 5.5 [Password complexity]
interactive access
P5.1
High Impact
BCS
Medium
Impact BCS
P5.2
PCA
PCA
EACM
P5.3
YES
PACS
EACM
External
Routable
Connectivity?
P5.4
PACS
YES
Control
Center?
P5.5
Utilize password complexity
5.5.1. Eight chars or max supported
5.5.2 Three or more different types of
chars or maximum supported
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
271
Part 5.5 Passwords
• 5.5.1 Eight characters or max supported
• 5.5.2 Three or more different types of chars or
maximum supported
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
272
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
273
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
274
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
275
• This Part does not apply to multi-factor authentication.
• This part does not apply to read-only access to a Cyber
Asset, in which the configuration of the Cyber Asset
cannot be changed and there is no way for the Cyber
Asset to affect the BES.
• If a device has the technical capability to enforce
password length and/or complexity, then that method
should normally be used. If the entity chooses a
procedural method of enforcement when a technical
method is available, the circumstances regarding this
choice should be reviewed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
276
• For each BES Cyber System and the associated EACMS (including EAP),
PACS, and PCA, provide:
– The method used to enforce the password length requirement (i.e., technical
or procedural) for password-only authentication for interactive user access
• If password length is enforced by a technical method, provide evidence of configuration
to enforce this requirement
• If password length is enforced by a procedural method:
– Provide the procedure used to enforce this requirement
– Provide evidence (e.g., training content, email notification, etc.) that this procedure is enforced
– The method used to enforce the password complexity requirement (i.e.,
technical or procedural) for password-only authentication for interactive user
access
• If password complexity is enforced by a technical method, provide evidence of
configuration to enforce this requirement
• If password complexity is enforced by a procedural method:
• Provide evidence (e.g., training content, email notification, etc.) that this
procedure is enforced
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
277
• Describe the password management
procedures for meeting the password length
and complexity requirements
• Are there devices which do not support the
required length and password requirements?
• How are these devices identified and
managed?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
278
Part 5.5 Evidence
• Password configuration settings
• Vendor documentation that identifies device
password capabilities for those devices that
cannot support the defined requirements
• Attestation of compliance –referencing
documented procedures followed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
279
CIP-007-6 Part 5.6
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
280
CIP-007-6 Part 5.6 [Password changes]
High Impact
BCS
interactive access
P5.1
Medium
Impact BCS
P5.2
PCA
PCA
EACM
P5.3
PACS
EACM
External
Routable
Connectivity?
YES
P5.4
PACS
YES
Control
Center?
P5.5
Enforce password changes
(15 month max)
P5.6
W
E
S
T
E
requirement
R N
C O O R D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
281
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
282
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
283
Audit Approach
• For password-only authentication for interactive
user access, verify password length is enforced by
either technical or procedural methods
• For password-only authentication for interactive
user access, verify password complexity is
enforced by either technical or procedural
methods
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
284
Audit Approach [continued]
1. Does not apply to multi-factor authentication
2. Does not apply to read-only access to a Cyber Asset,
in which the configuration of the Cyber Asset cannot
be changed and there is no way for the Cyber Asset to
affect the BES.
3. If a device has the technical capability to enforce
password length and/or complexity, then that method
should normally be used. If the entity chooses a
procedural method of enforcement when a technical
method is available, the circumstances regarding this
choice should be reviewed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
285
• For each BES Cyber System (BCAs) and the associated
EACMS (including EAP), PACS, and PCA, provide:
– The method used to enforce the password change
requirement (i.e., technical or procedural) for passwordonly authentication for interactive user access
• If password change is enforced by a technical method, provide
evidence of configuration to enforce this requirement
• If password change is enforced by a procedural method:
• Provide evidence (e.g., training content, email
notification, etc.) that this procedure is enforced
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
286
• Describe the password change procedures for
all required asset types
• Are there any devices that do not support
password changes?
• Is vendor documentation available as
evidence?
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
287
Part 5.6 Evidence
• Password change procedures
• Password configuration settings
• Vendor documentation that identifies device
password capabilities for those devices that
cannot support the defined requirements
• Evidence of password changes
• Attestation of compliance –referencing
documented procedures followed
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
288
CIP-007-6 Part 5.7
requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
289
CIP-007-6 Part 5.7 [Unsuccessful logins]
interactive access
P5.1
High Impact
BCS
Medium
Impact BCS
P5.2
PCA
PCA
EACM
P5.3
YES
PACS
P5.4
E
S
T
PACS
YES
BES Cyber System and/or
Cyber Asset level
requirement
W
EACM
External
Routable
Connectivity?
Control
Center?
YES
P5.5
Enforce password changes
(15 month max)
P5.6
P5.7
E
R
N
E
L
Limit & alert on unsuccessful
login attempts
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
290
Part 5.7 Authentication Thresholds
• Requirement does not duplicate CIP-007-6
part 4.2
– Part 4.2 alerts for security events
– Part 5.7 alert after threshold is not required to be
configured by the Part 4.2 Requirement
• TFEs
– TFE triggering language qualifies both options
– TFE would only be necessary based on failure to
implement either option (operative word ‘or’)
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
291
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
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
292
•
•
•
•
•
W
E
Audit Approach
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
293
Audit Approach
• If the number of unsuccessful authentication attempts
is limited, verify the evidence of configuration supports
this method
• If alerts are generated after a threshold of unsuccessful
authentication attempts, verify the evidence of
configuration supports this method
• If neither method is used, verify an approved TFE
covers this circumstance, and verify the compensating
measures described by the TFE are in place
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
294
• For each BES Cyber System and the associated
EACMS (including EAP), PACS, and PCA,
provide:
– The method used to address unsuccessful
authentication attempts (i.e., limiting attempts or
alerting)
• Evidence of the configuration used to enforce
this requirement
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
295
• Describe the authentication lockout
configuration for all required cyber assets
• Where no support exists for automatic
lockout, describe additional security controls
implemented to identify successive failed
authentication attempts
• Describe response required for authentication
lockout and of identification of successive
failed login attempts
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
296
Part 5.7 Evidence
• Configuration evidence for assets that can
meet this requirement
• Procedures for devices that do not support
this capability
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
297
Part 5.7 Good evidence
298
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
299
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
300
• Setting the lockout setting too low can shut
out account access – Caution
• TFEs [P5.1, P5.6, P5.7]
• Password change management
• Identification and documentation of device
password limitations
• Ensuring all interactive access has
authentication implemented
W
E
S
T
E
R
N
E
L
E
C
T
R
I
C
I
T
Y
C
O
O
R
D
I
N
A
T
I
N
G
C
O
U
N
C
I
L
References
•
CIP-007-6 — Cyber Security – Systems Security Management dated June 2, 2014 from,
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_CLEAN_06022014.pdf
•
RSAW Version: RSAW CIP‐007‐6 DRAFT1v0 Revision Date: June 17, 2014 , RSAW Template: RSAW2014R1.3:
Reliability Standard Audit Worksheet, CIP-007-6 — Cyber Security – System Security Management, from:
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_RSAW-Draft1v0.pdf
•
DRAFT NERC Reliability Standard Audit Worksheet, RSAW Version: RSAW CIP-007-6 DRAFT2v0 Revision Date:
September 17, 2014 RSAW Template: RSAW2014R1.3, from:
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_RSAW-Draft2v0.pdf
•
NERC Consideration of Issues and Directives, Federal Energy Regulatory Commission Order No. 791 September 3,
2014, from:
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Consideration_of_Issues_and_Directives_CLE
AN_09032014.pdf
•
NERC Project 2014-02 - CIP Version 5 Revisions, Mapping Document Showing Translation of the Version 5
standards into CIP-003-6, CIP-004-6, CIP-006-6, CIP-007-6, CIP-009-6, CIP-010-2, and CIP-011-2 (CIP-002-5, CIP005-5, and CIP-008-5 were not modified), from:
http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Mapping_Document_CLEAN_09032014.pdf
Questions?
Eric Weston
Compliance Auditor – Cyber Security
Mick Neshem
CISSP, CISA
Senior Compliance Auditor, Cyber Security
Western Electricity Coordinating Council
Salt Lake City, UT
mneshem@wecc.biz
(C) 360-773-8490 (O) 801-734-8187

Presentation - WECC_V5 CIP 101 CIP-007

Transcription

Similar documents

VOITTAVA KYBERSTRATEGIA Jarno Limnéll

about berewick flyer

Read More - NTT Security

Cyber Security

International Summer School DEFENCE SECURITY CYBER

iPPlus Sales Sheet - IP Plus Consulting, Inc.

Anadolubank Nederland N.V. aims for optimal data security and

Realistic, real world, best practice in legal IT