Eric Weston Compliance Auditor – Cyber Security Mick Neshem · 9/24/2014 · CIP 101 . CIP-007-6...

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

Agenda

• CIP-007-6 Overview • New/Redefined Terminology • CIP-007-6 Audit Approach • Mach Audit • Issues & Pitfalls • Questions

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

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)

3


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

4


Billiam EMS Architecture 5


CorpNet EMS WAN

WKS1-2

Billiam Electronic Security Perimeters

LogRhythm Syslog1

BUCC WAN

WON

Access Point

HMI-2

DMZ1

BUCC

EMS Net

SUB1

BCA BCA BCA BCA

EMS 1- 4

BCA BCA

ICCP 1- 2

EMS Console 1-4

BCA BCA

DC1 HMI1

HPUX 1- 2

EMS Net

BCA BCA

EMS 5 - 6

BCA BCA BCA BCA

BCA BCA

EMS Console 5-6

BCA

DC2

BCA BCA BCA

Relay 1- 3

Access Point

Access Point

Access Point

PIX FW

ASA FW2

ASA FW1

WKS3

HP PTR1-2

ASA FW3

RTR 1-2 CCA

BCA

RTR 3

SW3 BCA

BCA RTR 4

SW4 BCA

BU1

CC1

SU1

CIP CONFIDENTIAL

EMS ESP [IP network] 6


CorpNet

EMS WAN

Firewall

Firewall

Router

Workstations

Workstations

File Server

Access Control Server

EMS Servers

Printer

Printer

Router

Switch

Switch

BCA

BCA

BCA

BCA

BCA

BCA

BCA BCA

CIP-007

EMS Electronic Security Perimeter

EAP

CIP-005

CIP-005

Intermediate Server


EACM

Switch

EACM

DMZ

EAP

EMS ESP/BCS [IP network] 7


CIP-002

CorpNet

EMS WAN

Firewall

Firewall

Router

Non-BCS Workstations File Server

Intermediate Server

Printer

Router

Switch

CIP-007


EAP CIP-005

CIP-005

PCA

PCA

PCA PCA

Workstations

BCA

EMS Servers

Printer Switch

BCA

BCA

BCA

BCA

BCA

BCA

BCA PCA BCA/PCA

BCA/PCA

PCA


EACM

Switch

EACM

EAP

DMZ

All PCA devices take on the

impact level of the BCS

Multi-BCS ESP 8


CIP-002

CorpNet

EMS WAN

Firewall

Firewall

Router

BCS Workstations BCS Server

Intermediate Server

Printer

Router

Switch

CIP-007


EAP CIP-005

CIP-005

PCA

BCA

BCA BCA

Workstations

BCA

EMS Servers

Printer Switch

BCA

BCA

BCA

BCA

BCA

BCA

BCA PCA BCA/PCA

BCA/PCA

BCA


EACM

Switch

EACM

EAP

DMZ

HIGH

MEDIUM

EMS ESP [High Water Mark] 9


CIP-002

CorpNet

EMS WAN

Firewall

Firewall

Router

BCS Workstations BCS Server

Intermediate Server

Printer

Router

Switch

CIP-007


EAP CIP-005

CIP-005

PCA

PCA

PCA PCA

Workstations

BCA

EMS Servers

Printer Switch

BCA

BCA

BCA

BCA

BCA

BCA

BCA PCA BCA/PCA

BCA/PCA

PCA


EACM

Switch

EACM

EAP

DMZ

All PCA devices take on the

impact level of the BCS

HIGH

V5 Effective Dates 10


CIP Version 5 Effective Dates Requirement Effective Date

Effective Date of Standard April 1, 2016 Requirement-Specific Effective Dates

CIP-002-5 R2 April 1, 2016 CIP-003-5 R1 April 1, 2016

CIP-003-5 R2 for medium and high impact BES Cyber Systems April 1, 2016 CIP-003-5 R2 for low impact BES Cyber Systems April 1, 2017 CIP-007-5 Part 4.4 April 15, 2016 CIP-010-2 Part 2.1 May 6, 2016 CIP-004-5 Part 4.2 July 1, 2016 CIP-004-5 Part 2.3 April 1, 2017 CIP-004-5 Part 4.3 April 1, 2017 CIP-004-5 Part 4.4 April 1, 2017 CIP-006-5 Part 3.1 April 1, 2017 CIP-008-5 Part 2.1 April 1, 2017 CIP-009-5 Part 2.1 April 1, 2017 CIP-009-5 Part 2.2 April 1, 2017 CIP-010-2 Part 3.1 April 1, 2017 CIP-009-5 Part 2.3 April 1, 2018 CIP-010-2 Part 3.1 April 1, 2017 CIP-010-2 Part 3.2 April 1, 2018 CIP-004-5 Part 3.5 Within 7 years after previous

Personnel Risk Assessment

Requirement Count

• 7 Requirements (Version 3) – 26 sub-requirements

• 5 Requirements (Version 5) – 20 Parts

11


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

12


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

13


Project 200806 Cyber Security Order 706 DL_Mapping_Document_012913.pdf

Applicable Systems 14


IAC • CIP-007-6 R1-R5

– contain Identify, Assess and Correct language in requirement. • 17 requirements that include IAC

– Filing deadline Feb. 3, 2015

15


CIP-007-6 TFEs

• 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

16


Continuing Standards Development 17


Serial Exemption 18


Substation Serial-Only Communications

19


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)

20


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

21


SEL-2890 Ethernet Transceiver [2890_PF00011.pdf]

22


SEL-351R account & Default Passwords 23


351R-4_QS_20140207.pdf

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

24


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

25


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)

26


CIP-007-6 Part 1.1 27


Asset level requirement

CIP-007-6 Part 1.1 [Ports/Services] 28


Identify and document required ports and services

High Impact BCS

Medium Impact BCS

PCA

P1.1

EACM

PACS

PCA

EACM

PACS


External Routable

Connectivity? Yes

Ports and Services

• en.able, en.a.ble

• Logical network accessible ports

29


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

30


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)

31


What We Expect [Sample only] 32


Device ID Device Name TCP Ports UDP Ports Service Justification

Question

• Is it required to capture not only the need for a port to be open, but also the authorization request for the port to be opened? – 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.

33


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"

34


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 (CIP-

010-2)

35


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

36


Mock Audit of Billiam

• Audit Approach • Bad Evidence Examples • Typical Data Request • Typical Interview Questions • Good Evidence Examples

37


Part 1.1 Evidence 38


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

Part 1.1 Audit Steps 39


• 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.

[CIP-007-6 Part 1.1] Audit Approach – What are we looking for?

• 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?

40


[CIP-007-6 Part 1.1] Audit Approach – What are we looking for? [continued]

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

41


[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]

42


[CIP-007-6 Part 1.1] Typical Interview Questions

• 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

43


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

44


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 TCP HMI-1:netbios-ssn 172.16.105.1:56762 TIME_WAIT TCP HMI-1:netbios-ssn 172.16.105.1:56765 TIME_WAIT TCP HMI-1:netbios-ssn 172.16.105.1:56766 TIME_WAIT

45


HMI-1 Baseline Evidence [netstat] C:\Documents and Settings\HMI-1>netstat -b -o -a -n > netstat_boan.txt Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 952 C:\WINDOWS\system32\svchost.exe TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 [System] TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING 428 [spnsrvnt.exe] TCP 0.0.0.0:7001 0.0.0.0:0 LISTENING 248 [sntlkeyssrvr.exe] TCP 0.0.0.0:7002 0.0.0.0:0 LISTENING 248 [sntlkeyssrvr.exe] TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING 1656 [dirmngr.exe] TCP 127.0.0.1:1029 0.0.0.0:0 LISTENING 2484 [alg.exe] TCP 127.0.0.1:5152 0.0.0.0:0 LISTENING 1764 [jqs.exe] TCP 127.0.0.1:33333 0.0.0.0:0 LISTENING 1856 [PGPtray.exe] TCP 172.16.105.220:139 0.0.0.0:0 LISTENING 4 [System] TCP 127.0.0.1:2111 127.0.0.1:33333 ESTABLISHED 1616 UDP 0.0.0.0:7001 *:* 248 [sntlkeyssrvr.exe] UDP 0.0.0.0:500 *:* 700 [lsass.exe] UDP 0.0.0.0:4500 *:* 700 [lsass.exe] UDP 0.0.0.0:445 *:* 4 [System] UDP 127.0.0.1:123 *:* 1084 c:\windows\system32\WS2_32.dll UDP 172.16.105.220:6001 *:* 428 [spnsrvnt.exe]

46


HMI-1 Evidence [nmap tcp] 47


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 SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 777/tcp open multiling-http? 6002/tcp open http SafeNet Sentinel License Monitor httpd 7.3 7001/tcp open afs3-callback? 7002/tcp open 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

HMI-1 Evidence [nmap udp] 48


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

EMS1 Evidence [netstat tcp & udp] 49


Router Ports/Services 50


Manual Review of Configs 51


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.

52


CIP-007-6 Part 1.2 53



CIP-007-6 Part 1.2 [Physical Ports] 54


Physical port protections

High Impact BCS

Medium Impact BCS

PCA

P1.2

PCA

Nonprogrammable communications equipment inside

ESP & PSP


Control Center?

Yes

Nonprogrammable communications equipment inside

ESP & PSP

CIP-007-3 CIP-007-6 Change 55


CIP-007-3 CIP-007-6

Logical Ports only Includes Physical Ports (R1.2) and includes non-programmable 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.

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

56


http://www.tditechnologies.com/whitepaper-nerc-cip-007-5-r1

Part 1.2 Physical Ports

• Physical I/O ports – Network – Serial – USB ports external to the device casing

57


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

58


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

59


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

60


Port Locks 61

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 http://www.blackbox.com/resource/genPDF/Brochures/LockPORT-Brochure.pdf

Physical Access to Ports

62

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 http://www.supernap.com/supernap-gallery-fullscreen/

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

63


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

64


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

65


CIP V5 Questions with Draft Responses.pdf – Part 1.2

66




67


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

68


Part 1.2 Evidence 69


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

Provide the following evidence: 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

CIP-007-6 Part 2.1 70





CIP-007-3 CIP-007-6

No time frames to implement patches

Patch management required actions and timelines (R2)

CIP-007-6 Part 2.1 [Patch Process] 72


Document Patch Management process &

sources

High Impact BCS

Medium Impact BCS

PCA

P2.1

EACM

PACS

PCA

EACM

PACS


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

73


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

74


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

75


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

76


https://www.esisac.com/

http://cve.mitre.org/

http://www.securityfocus.com/vulnerabilities

http://nvd.nist.gov/

http://ics-cert.us-cert.gov/all-docs-feed

Sources 77

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 https://ics-cert.us-cert.gov/ICS-CERT-Vulnerability-Disclosure-Policy

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

78


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

79


Graphic Driver Patch 80


CIS CYBER SECURITY ADVISORY NUMBER:2014-058

81


DATE(S) ISSUED:07/02/2014 SUBJECT:Multiple Vulnerabilities in Apple Mac OS X Prior to 10.9.4

‘that are updateable’ [XP Support] 82


Windows XP (EOL 4-8-2014)

• April 2014 there are no more security patches forthcoming for XP – No Software Updates from Windows Update – No Security Updates – No Security Hotfixes – No Free Support Options – No Online Technical Content Updates

83


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)

84

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 http://www.computerworld.com/s/article/9237019/Microsoft_gooses_Windows_XP_s_custom_support_prices_as_deadline_nears?pageNumber=1

Windows XP (EOL 4-8-2014)

• April 2014 there are no more security patches forthcoming for XP – 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

85


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

86


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

87




88


Part 2.1 Audit Approach 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

Part 2.1 Data Request 90


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

[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

91



• 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

92



• 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?

93


Insufficient Evidence – Why? 94


Sufficient Evidence – Why?

• Software listings • Patch sources • Assessment procedure – who, what, when,

how, --timing, criteria • Assessment results and rationale

95


CIP-007-6 Part 2.2 Patch Evaluation 96



CIP-007-6 Part 2.2 [Patch Evaluation] 97



sources

High Impact BCS

Medium Impact BCS

PCA

P2.1

EACM

PACS

PCA

EACM

PACS Documented Patch

evaluation (max 35 days)

P2.2


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

98


Guidelines • DHS

– “Quarterly Report on Cyber Vulnerabilities of Potential Risk to Control Systems”

• http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_13-39_Feb13.pdf

– “Recommended Practice for Patch Management of Control Systems”

• http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf

99


http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_13-39_Feb13.pdf

http://www.oig.dhs.gov/assets/Mgmt/2013/OIG_13-39_Feb13.pdf

http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf



Vulnerability Footprint 100

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 http://ics-cert.us-cert.gov/sites/default/files/recommended_practices/PatchManagementRecommendedPractice_Final.pdf

CIP V5 Questions with Draft Responses.pdf – Part 2.2

101




102


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

103




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

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: – BCA – EACM – PACS – PAs

105


Part 2.2 Patch Evaluation 106


Evidence – Sample spreadsheet 107


CIP-007-6 Part 2.3 108

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 Asset level requirement

CIP-007-6 Part 2.3 [Patch Response] 109



sources

High Impact BCS

Medium Impact BCS

PCA

P2.1

EACM

PACS

PCA

EACM

PACS Documented Patch

evaluation (max 35 days)

P2.2

Required patch

identified?

Install patch

NO YES Within 35 days

Create Mitigation plan

Update Mitigation plan

OR

OR

Implement Plan within time frame

P2.3


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

110


Note: referenced mitigation plan is a entity plan and not associated at all with the Enforcement Mitigation plans.

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

111


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

112


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

113


Timeframe

• Timeframe is 70 days total – 35 days for tracking and determining applicability – 35 days for either installing or determining the

mitigation plan

114


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

115


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”

116




117


Part 2.3 Audit Approach 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. The patch was applied to all devices for which it is applicable; or b. A mitigation plan was created; or c. A mitigation plan was revised.

2. In the case where a mitigation plan was created or revised: a. Verify the mitigation plan addresses each vulnerability addressed by the security

patch; b. Verify the mitigation plan is sufficient to mitigate each vulnerability addressed by the

security patch; c. Verify the mitigation plan includes a timeframe for completion; d. Review the timeframe specified by the mitigation plan to determine if it results in

mitigation of each vulnerability within a reasonable period; and e. 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.

118




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


• Describe the patch assessment process • Describe the patch implementation process • Describe the Mitigation Plan documentation

process – why, what, who, when

120


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.

121


Part 2.3 Audit Evidence Examples 122


Part 2.3 Audit Evidence Examples 123


CIP-007-6 Part 2.4 124

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 Asset level requirement

CIP-007-6 Part 2.4 [Mitigation Plan] 125



sources

High Impact BCS

Medium Impact BCS

PCA

P2.1

EACM

PACS

PCA

EACM

PACS

Required patch

identified?

Documented Patch evaluation (max 35 days)

P2.2

Install patch

NO YES Within 35 days

Create Mitigation plan

Update Mitigation plan

OR

OR

Implement Plan within time frame

CIP SM or Delegate approval

Plan Revision or Extension?

P2.3

P2.4

P2.4

YES

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

126


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

127




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.



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.

Part 2.4 Evidence

Mitigation Plan with signed Senior Manager approval

130


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

131


CIP-007-6 Part 3.1 132


BES Cyber System level requirement



CIP-007-3 CIP-007-6

AV on ALL cyber assets or TFE

Malicious code controls can be at cyber system level, rather than per asset (R3)

CIP-007-6 Part 3.1 [Malicious Code] 134


Deploy method(s) to deter, detect, or

prevent malicious code.

High Impact BCS

Medium Impact BCS

PCA

P3.1

EACM

PACS

PCA

EACM

PACS


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

135


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.”

136


AV/Anti-Malware 137


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.

138


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.

139


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?

140


Defense-N-Depth

141

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 https://www.lumension.com/vulnerability-management/patch-management-software/third-party-applications.aspx

Application Whitelisting

• Identifying specific executable and software libraries which should be permitted to execute on a given system

• Preventing any other executable and software libraries from functioning on that system

• Preventing users from being able to change which files can be executed

142

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 http://www.asd.gov.au/publications/csocprotect/application_whitelisting.htm

Application Whitelisting

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

143


Guidelines

• Network isolation techniques • Portable storage media policies • Intrusion Detection/Prevention (IDS/IPS)

solutions

144


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

145


‘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

146


CIP-007 FAQ Question: What is “malware?” Answer: Malware generally means malicious software such as viruses, worms, time-bombs, 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.

147




148


Part 3.1 Audit Approach 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.

149



• 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

150


[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?

151


Part 3.1 Audit Evidence – Needs update

152


Part 3.1 AV/Ant-Malware Status 153


CIP-007-6 Part 3.2 154



CIP-007-6 Part 3.2 [Threat Mitigation] 155




High Impact BCS

Medium Impact BCS

PCA

P3.1

EACM

PACS

PCA

EACM

PACS

Mitigate the threat of detected

malicious code.

• Requires processes • Requires evidence of

processes utilized

P3.2

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

156


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)

157




158




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.



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

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.

161


Part 3.2 Evidence

• Documentation of events • Mitigation processes completed • How does the mitigation efforts specifically

address the malicious code

162


CIP-007-6 Part 3.3 163



CIP-007-6 Part 3.3 [Signature Updates] 164




High Impact BCS

Medium Impact BCS

PCA

P3.1

EACM

PACS

PCA

EACM

PACS

Mitigate the threat of detected

malicious code.

P3.2

• Requires processes • Requires evidence of

processes utilized R3.3

Signature or pattern based

controls?

Requires process for updates

Requires processes that address: • Testing • Installation

P3.3

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

165


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?

166


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

167




168


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

169


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.

170



• Describe the procedures for testing of signatures prior to implementation

• How often are the signatures updated?

171


Part 3.3 Evidence

• Documented signature testing and updating procedures

• Evidence of performance of the signature testing

172


R3 Issues & Pitfalls

• Technical selection and implementation • Coverage for all cyber assets • Combination of solutions • BCS and ESP coverage • Clear documentation demonstrating coverage • Identification, alerts and response procedures

173


CIP-007-6 Part 4.1 174


BES Cyber System and/or Asset level requirement

CIP-007-6 Part 4.1 [Event logging] 175


Deploy cyber security event logging capabilities

High Impact BCS

Medium Impact BCS

PCA

P4.1

EACM

PACS

PCA

EACM

PACS

4.1.1. Detected successful login Attempts; 4.1.2. Detected failed access attempts and failed login attempts; 4.1.3. Detected malicious code.

BES Cyber System and/or Asset level requirement



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 every 90 days when applicable

Log reviews for High Impact Cyber Systems must be reviewed every 15 days (P4.4)

Part 4.1 Log Events • 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

177


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

178


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.

179




180




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.

2. Verify logs are being generated by the Cyber Asset and associated devices.



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.


• 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]

183



• 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

184



• 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

185


Part 4.1 Evidence

• Device configurations for logging of required events

• Examples of required events being identified

186


Part 4.1 Good Evidence 187

User Access Log [sample] 188


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 ...

189


CIP-007-6 Part 4.2 190


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

CIP-007-6 Part 4.2 [Alerts] 191



High Impact BCS

Medium Impact BCS

PCA

P4.1

EACM

PACS

PCA

EACM

PACS


External Routable

Connectivity?

Deploy cyber security event alert capabilities

P4.2

4.2.1. Detected malicious code 4.2.2 Detected failure of event logging

YES


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

192


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

193


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

194


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

195




196


Audit Approach

• Verify the entity has documented one or more 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

197




Provide the following evidence: 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


• Describe the alert processes • Describe the alert configurations for required

asset types • Describe the alert types and required

responses

199


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

200


CIP-007-6 Part 4.3 202



CIP-007-6 Part 4.3 [Log Retention] 203



High Impact BCS

Medium Impact BCS

PCA

P4.1

EACM

PACS

PCA

EACM

PACS


External Routable

Connectivity?


P4.2

4.2.1. Detected malicious code 4.2.2 Detected failure of event logging

YES

Control Center?

90 day log retention P4.3

YES


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

204


Part 4.3 ‘Retain Applicable Event Log’s’

205


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

206




207


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.

208




• 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


• 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

210


Part 4.3 Evidence

• Log retention procedures • Reports showing log management • Evidence of audit period compliance – log file

procedures fro grater than 90 days

211


CIP-007-6 Part 4.4 213



CIP-007-6 Part 4.4 [Log Review] 214



High Impact BCS

Medium Impact BCS

PCA

P4.1

EACM

PACS

PCA

EACM

PACS


External Routable

Connectivity?


P4.2

4.2.1. Detected malicious code 4.2.2 Detected failure of event logging Control

Center?

YES

90 day log retention P4.3

YES PCA

EACM Log event reviews (15 days)

On or before April 14, 2016

P4.4

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

215


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

216


Cloud Computing 217

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 http://www.ipspace.net/Webinars

Monitoring-as-a-Service 218

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 http://www.symantec.com/content/en/us/enterprise/other_resources/b-nerc_cyber_sercurity_standard_21171699.en-us.pdf

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

219




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



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


• 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?

222


Part 4.4 Evidence

• 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

223


Part 4.4 Evidence

• Procedures • Evidence of reviews – validating the 15 day

maximum review timeframes

224


Part 4.4 Log Review Evidence 225


CIP-007-6 Part 5.1 227


BES Cyber System and/or Cyber Asset level requirement

CIP-007-6 Part 5.1 [Authentication] 228


Enforce Authentication for interactive access

High Impact BCS

Medium Impact BCS

PCA

P5.1

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES


CIP-007-3 CIP-007-6 Highlights 229


CIP-007-3 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)

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

230




231


Audit Approach

• Verify the entity has documented one or more processes which address this Part.

• Verify the entity has documented one or more 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

232




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.


• Describe the process to ensure authenticated interactive access to required cyber assets is enforced

• Identify the controls to enforce authentication for all interactive access

234


Part 5.1 Evidence

• Procedures for implementation of authenticated interactive access

• Evidence of controls in affect

235


Part 5.1 Enforce Authentication 236


CIP-007-6 Part 5.2 237



CIP-007-6 Part 5.2 [Default/Generic Accounts]

238



High Impact BCS

Medium Impact BCS

PCA

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES

P5.1

Identify & inventory default and generic accounts

P5.2


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

239


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)

240


CIP-007 Part 5.2 Question • 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.

241


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.

242




243


Audit Approach


• Verify the entity has identified and inventoried all known or enabled generic accounts.

244




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.


• Describe the account management procedures to include default and shared accounts

• Procedure to ensure identification of default and shared accounts

246


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

247


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

248


CIP-007-6 Part 5.3 249



CIP-007-6 Part 5.3 [Shared account access]

250



High Impact BCS

Medium Impact BCS

PCA

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES

Identify &inventory default and generic accounts

P5.1

P5.2


Identify individuals with access to shared accounts

P5.3

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

251




252




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.


• Describe the procedures to assign and track all users with access to shared accounts

254


Part 5.3 Evidence

• Procedures documentation • Listing of default and shared accounts • Identification of all users with access to the

default and shared accounts

255


CIP-007-6 Part 5.4 256



CIP-007-6 Part 5.4 [Default passwords]

257



High Impact BCS

Medium Impact BCS

PCA

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES



Change default passwords

P5.1

P5.2

P5.3


P5.4

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

258


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

259




260


Audit Approach

• Verify the entity has documented one or more 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

261




• 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


• 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?

263


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

264


SEL Relay Default Accounts/Passwords 265


SEL Relay Default Accounts/Passwords 266


Part 5.4/5.5 Good Evidence 267


Part 5.4/5.5 Good Evidence 268


CIP-007-6 Part 5.5 269



CIP-007-6 Part 5.5 [Password complexity]

270



High Impact BCS

Medium Impact BCS

PCA

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES




Utilize password complexity P5.5

5.5.1. Eight chars or max supported 5.5.2 Three or more different types of chars or maximum supported

P5.1

P5.2

P5.3

P5.4


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

271


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

272


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

273




274


Part 5.5 Audit Steps

• 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

275


Part 5.5 Data Request • 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 the procedure used to enforce this requirement

• Provide evidence (e.g., training content, email notification, etc.) that this procedure is enforced

276



• 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?

277


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

278


CIP-007-6 Part 5.6 279



CIP-007-6 Part 5.6 [Password changes]

280



High Impact BCS

Medium Impact BCS

PCA

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES




Utilize password complexity


Enforce password changes (15 month max) P5.6

P5.1

P5.2

P5.3

P5.4

P5.5


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

281




282


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

283


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

284


Part 5.6 Data Request

• 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 password-only 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 the procedure used to enforce this requirement

• Provide evidence (e.g., training content, email notification, etc.) that this procedure is enforced

285



• 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?

286


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

287


CIP-007-6 Part 5.7 288



CIP-007-6 Part 5.7 [Unsuccessful logins]

289



High Impact BCS

Medium Impact BCS

PCA

P5.1

EACM

PACS

PCA

EACM

PACS

External Routable

Connectivity?

Control Center?

YES

YES


P5.2


P5.3

Change default passwords P5.4

Utilize password complexity P5.5


Enforce password changes (15 month max) P5.6

YES

BES

Cybe

r Sys

tem

and

/or

Cybe

r Ass

et le

vel

requ

irem

ent

Limit & alert on unsuccessful login attempts

P5.7

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

290


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

291



• Audit Approach • Typical Data Request • Typical Interview Questions • Bad Evidence Examples • Good Evidence Examples

292


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

293


Part 5.7 Data Request

• 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

294



• 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

295


Part 5.7 Evidence

• Configuration evidence for assets that can meet this requirement

• Procedures for devices that do not support this capability

296


Part 5.7 Good evidence 297

R5 Issues & Pitfalls

• 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

300


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_CLEAN_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, CIP-005-5, and CIP-008-5 were not modified), from: http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Mapping_Document_CLEAN_09032014.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_CLEAN_06022014.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_RSAW-Draft1v0.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/CIP-007-6_RSAW-Draft2v0.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Consideration_of_Issues_and_Directives_CLEAN_09032014.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Consideration_of_Issues_and_Directives_CLEAN_09032014.pdf

http://www.nerc.com/pa/Stand/Prjct2014XXCrtclInfraPrtctnVr5Rvns/Mapping_Document_CLEAN_09032014.pdf

Eric Weston Compliance Auditor – Cyber Security Mick Neshem CISSP, CISA

Senior Compliance Auditor, Cyber Security Western Electricity Coordinating Council Salt Lake City, UT [email protected] (C) 360-773-8490 (O) 801-734-8187

Questions?

mailto:[email protected]

Eric Weston Compliance Auditor – Cyber Security Mick Neshem · 9/24/2014 · CIP 101 . CIP-007-6...

Documents

Transcript of Eric Weston Compliance Auditor – Cyber Security Mick Neshem · 9/24/2014 · CIP 101 . CIP-007-6...