Cyber Security Standards Update: Version 5 by Scott Mix

Cyber Security Standards Update:
Version 5Version 5
 August 1 2013August 1, 2013
 Scott Mix, CISSP
 CIP Technical Manager

Agenda
• Version 5
– Impact Levels
F t– Format
– Features
– NOPR
2 RELIABILITY | ACCOUNTABILITY

CIP Standards – Version 5
• CIP Version 5 ‐ Draft 4 – Final Version
 Approved by industry on Nov 5, 2012
 Approved by NERC Board of Trustees on Nov 26.
2012
 Filed with FERC on February 1 2013 Filed with FERC on February 1, 2013
oFERC Docket RM13‐5
o10,483 page filing, p g g

• CIP‐002‐5: BES Cyber Asset and BES Cyber System
Categorization
i l• CIP‐003‐5: Security Management Controls
• CIP‐004‐5: Personnel and Training
• CIP‐005‐5: Electronic Security Perimeter(s)• CIP 005 5: Electronic Security Perimeter(s)
• CIP‐006‐5: Physical Security of BES Cyber Systems
• CIP‐007‐5: Systems Security Management
• CIP‐008‐5: Incident Reporting and Response Planning
• CIP‐009‐5: Recovery Plans for BES Cyber Assets and
S tSystems
• CIP‐010‐1: Configuration Management and Vulnerability
Assessments
Assessments
• CIP‐011‐1: Information Protection

• New / Modified Terms:
 BES Cyber Asset
 BES Cyber System
 Electronic Access Point (EAP)
 Electronic Security Perimeter   BES Cyber System
 BES Cyber System
Information
 CIP Exceptional
y
(ESP)
 External Routable Connectivity
 Interactive Remote Access CIP Exceptional
Circumstance
 CIP Senior Manager
C t l C t
Interactive Remote Access
 Intermediate Device
 Physical Access Control Systems
(PACS) Control Center
 Cyber Assets
 Cyber Security Incident
(PACS)
 Physical Security Perimeter
(PSP)
 Protected Cyber Asset (PCA)
 Dial‐up Connectivity
 Electronic Access Control
and Monitoring Systems
 Protected Cyber Asset  (PCA)
 Reportable Cyber Security
Incident
g y
(EACMS)

• Retired Terms
 Critical Assets
C iti l C b A t Critical Cyber Assets

• CIP‐002
 Builds on “bright lines” in CIP‐002‐4g
 “Version 4” Critical Asset control centers – High
 Other “Version 4” Critical Assets – Medium
 Some “Version 4” non‐critical asset control centers –
Medium
 Transmission now looking at “capacity” rather than
number of lines at a voltage level
C t h ll t f ifi ll t i d L Catch‐all category for non‐specifically categorized – Low
o“Something everywhere” – within the BES
oProgrammatic requirement: CIP 003 5 Requirement R2
oProgrammatic requirement: CIP‐003‐5 Requirement R2

• High Impact
– Large Control Centers
– CIP‐003 through 009 “plus”CIP 003 through 009 plus
• Medium Impact
– Generation and Transmission
C l C– Control Centers
– Similar to CIP‐003 to 009 V4
• All other BES Cyber Systems
(Low Impact) must implement a
policy to address:
– Cybersecurity Awareness
– Physical Security Controls
– Electronic Access Controls
– Incident Response
Incident Response
• High Watermarking

Rationale,
Guidance &
Changes,
Main
Requirement
and Measure
Applicable Systems for
requirement part
Requirement part text Requirement part
Measure text
Requirement part Reference Requirement part change rationale

• Format
 Following Results‐based Standards format
 Background section before requirements
 Requirement and Measurement next to each other
 Rationale and guidance developed in parallel with
requirements – still being developed and augmented
T i f i h id / i l Two posting formats – one with guidance/rationale text
boxes inline; other with guidance and rational text
grouped at endg p
 Still must audit only to the requirement
 Guidelines and Technical Basis section at end

• Applicable Systems column in tables
 What systems or entities the row in the table apply to
 Listed in each standard
 Specific phrases – consistent across all standards
 A requirement part (row) may have multiple applicability A requirement part (row) may have multiple applicability
statements
 Examples:
o High Impact BES Cyber Systems
o Medium Impact BES Cyber Systems
o Medium Impact BES Cyber Systems at Control Centers
o Medium Impact BES Cyber Systems with External Routable
Connectivity
o Protected Cyber Assets
y
o Electronic Access Control Systems

• Connectivity
 No longer a blanket exemption
 Now listed in applicability section – Routable Connectivity or
Dial‐up Connectivity
 “Routable protocol” applicability now applies where large Routable protocol applicability now applies where large
volume, real‐time communications requirements are listed –
e.g., logging
• Low Impact
 CIP‐003‐5 Requirement R2
 “Programmatic” controls (i.e., have a program for …)
 Requires physical and cyber security protections for
“locations” containing low
locations containing low
 Does not require lists of every low impact BES Cyber System

• TFEs
 Attempting to minimize required TFEs (e.g., anti‐malware on
switches)
 Reduced from 14 requirements to 10
 But still have TFEs (including new ones where existing V1 V4 But … still have TFEs (including new ones where existing V1 – V4
problems exist)
 Have added “per Cyber Asset capability” language to allow strict
compliance with the language of the requirement, without
requiring a TFE (~5 requirements)
• Measures• Measures
 Guidance to auditors as well as entities
 “An example of evidence may include, but is not limited to, …”
An example of evidence may include, but is not limited to, …
 No longer a “meaningless restatement of the requirement”

CIP-002-4
• Notes when reading NERC Standards:
 Capitalization is very important.
 Capitalized words refer to terms in the NERC Glossary of
Terms Used in Reliability Standards
(http://www.nerc.com/pa/Stand/Glossary%20of%20Terms(http://www.nerc.com/pa/Stand/Glossary%20of%20Terms
/Glossary_of_Terms.pdf)
 Non‐capitalized terms do not refer to NERC glossary terms
i “R l i ” i h “ l i ”o i.e., “Real‐time” is not the same as “real‐time”
o “Facilities” is not the same as “facilities”
 Terms with well known and authoritative definitions defer
to those authoritative sources (e.g., “FACTS”)
 Not all terms used have either NERC Glossary definitions or
authoritative definitions (e g “control center”)
authoritative definitions (e.g., control center )

• Bulleted lists vs. numbered lists
 Bulleted lists are separated by “or”p y
 Bulleted lists imply that not all of the items in the list
are required
 Numbered lists are separated by “and”
 Numbered lists imply that all of the items in the lists
dare required
• Both bulleted and numbered lists are used in
both requirements and measures

Features of Version 5
• Closes out directives in FERC Order No. 706 (also, FERC
Order No. 761 imposes March 31, 2013, filing deadline)
• Results‐based standards
 Focus on reliability and security‐related result
 Non‐technology specificNon technology specific
 Smarter use of Technical Feasibility Exception (TFE) process
 “Plain language of the requirement”, i.e., “per device
bili ”capability”
• Risk‐informed systems approach
 Adopt solutions and tailor security based on function andAdopt solutions and tailor security based on function and
risk
 No longer a harsh “in or out” demarcation for applicability
 Impact and connecti it informs applicabilit
 Impact and connectivity informs applicability

Features of Version 5
• Systems approach illustration
 Cyber Assets function together as a complex system
 Identify the system and apply requirements to the whole
rather than the part
 “High Watermarking” inside boundary

CIP V5 Approach to
Correcting Deficiencies
• Empowers industry
 Shifts focus from whether deficiencies occur to correcting
d fi i ideficiencies
 Continuous Improvement
o From: backward‐looking, individual violationso From: backward looking, individual violations
o To: forward‐looking, holistic focus
• Reliability and security emphasis that promotes the
identification and correction of deficiencies
• Consistent with NERC “Internal Controls” approach to
licompliance
• Version 5 triggering language: “… implement, in a manner
that identifies assesses and corrects deficiencies ”
that identifies, assesses, and corrects deficiencies, …

CIP V5 Approach to
Correcting Deficiencies (Continued)
• Corrected deficiency is a component of satisfying the
requirement
• Does not require “internal controls” or additional
process
d d h f d f• Standards approach of correcting deficiencies
complements the compliance concept of internal controls
• Reliability Standard Authorization Worksheets (RSAWs)• Reliability Standard Authorization Worksheets (RSAWs)
and Violation Severity Levels (VSLs) must support
approachapproach
 Does not expand obligations
 Clarifies that method of identifying, assessing, and correcting
deficiencies is not evaluated

Draft RSAW
• Deficiencies refer to possible non‐compliances with
the standard; not all deficiencies would become
issues of non‐compliance
• Entities are not required to self‐report deficiencies if
h id if i i d i hthey are identifying, assessing and correcting them
• CEA samples identified, assessed and corrected
d fi i ideficiencies
 CEA considers impact of correction in determining the
sample sizesample size

When to Self-Report
• Plan does not exist
• Plan has not been implemented
• Did not assess or correct identified deficiencies
• Deficiencies that create high risk to the Bulk Electric g
System

Implementation Plan
• Proposed Effective Date (from CIP‐002‐5;
all standards use the same language):
1. 24 Months Minimum – CIP‐002‐5 shall become effective
on the later of July 1, 2015, or the first calendar day of
the ninth calendar quarter after the effective date of thethe ninth calendar quarter after the effective date of the
order providing applicable regulatory approval.
2. In those jurisdictions where no regulatory approval is j g y pp
required CIP‐002‐5 shall become effective on the first
day of the ninth calendar quarter following Board of
Trustees’ approval or as otherwise made effectiveTrustees approval, or as otherwise made effective
pursuant to the laws applicable to such ERO
governmental authorities.

Implementation Plan
• Implementation issues:
 Specified initial performance of all periodic requirements in
implementation plan
 24 months following regulatory approval for all
requirementsrequirements
 Identity Verification does not need to be repeated
 Discussion of unplanned re‐categorization to a higher p g g
impact level
 Discussion of disaster recovery actions
 Discussion of requirements applied to access control
systems (physical and electronic), and Protected Cyber
Assets

Applicability
• Applicability Section:
 Section 4.1 Functional Entities
oDescribes which asset owners, based on their functional
model designation, and specific ownership of assets,
must comply with the standardsmust comply with the standards
oMay have no qualifications – applies to all entities
registered for that function
 Section 4.2 Facilities
oDescribes which assets must comply with the standards
oMay have no qualifications – applies to all BES assets
owned by that function

Applicability
• Applicability Example:
 For Distribution Providers – only those registered DPs that
own specifically called out pieces of equipment, such as
UFLS systems, must comply with the standards
 For those DPs only the specifically called out pieces ofFor those DPs, only the specifically called out pieces of
equipment must comply with the standards
• If a DP does not own any called out equipment, it y q p
does not need to comply with the standards
• If a DP owns a piece of called out equipment, only
that called out equipment must comply with the
standards

Applicability

• CIP‐002‐5 through CIP‐009‐5, CIP‐010‐1, CIP‐011‐1
• “Results‐based Standard” format
 Requirements and measures together
 Guidance and rational in text boxes
• “Looks” bigger
 ~1” printout for Version 5 (includes VSLs) compared to
¼” i t t f V i 4~¼” printout for Version 4
 Includes much more guidance and rationale for each
requirementequ e e t

Version 5 Requirement Counts
• CIP‐002
 2 Requirements; 5 Parts; Attachment with bright lines for High and Medium
• CIP‐003
 4 Requirements; 13 Partsq ;
• CIP‐004
 5 Requirements; 18 Parts
• CIP‐005
• CIP‐006
• CIP‐007
 5 Requirements; 20 Partsq ;
• CIP‐008
• CIP‐009
 3 Requirements; 10 Parts 3 Requirements; 10 Parts
• CIP‐010
• CIP‐011
2 R i 4 P
• Total: 32 Requirements; 110 Parts

Version 4 Requirement Counts
• CIP‐002
 3 Requirements; 0 parts, Attachment with Bright Lines
• CIP‐003
6 R i 18 / b 6 Requirements;  18 parts/sub‐parts
• CIP‐004
 4 Requirements;  12 parts/sub‐parts
• CIP‐005• CIP‐005
• CIP‐006
 8 Requirements; 15 parts/sub‐partsq ; p / p
• CIP‐007
• CIP‐008
 2 Requirements; 6 parts
• CIP‐009
 5 Requirements; 2 parts
• Total:
• Total:

• Sub‐Requirements
 Each Requirement / Sub‐Requirement is a compliance
touch‐point
 Non‐compliance with a sub‐requirement stands on its own
 Sub requirements have independent VSLs (unless rolled up) Sub‐requirements have independent VSLs (unless rolled‐up)
• Requirement Parts
 Only the Requirement is a compliance touch point Only the Requirement is a compliance touch‐point
 Cannot be independently in non‐compliance with a Part
 VSLs written only at the Requirement level (making very S s tte o y at t e equ e e t e e ( a g e y
long and complicated VSL language)
 Parts allow flexibility in development and implementation
f h i
of the requirement

• “Annual” – interaction with CAN – now “15 months”
• Monthly requirements – changed to 35 days
l h b ll d l f• Measures are examples with bulleted lists; format,
wording
• Compliance artifacts in requirements (e gCompliance artifacts in requirements (e.g.,
“documentation of …”)
• LSE (removed), replaced with DP
 LSE functions changed since original standards development
timeframe
• 300 MW threshold on UFLS/UVLS• 300 MW threshold on UFLS/UVLS
 No justification for a different value
• Notifications: IROL, “must run” (resolving as part of V4)
• IROL’s in WECC

• Definition / threshold of Control Center
 Includes “data centers”
C ti it ( t bl di l )• Connectivity (routable, dial‐up)
• Low Impact (policy only)
 List not requiredq
• Date tracking (PRA, training, access, etc)
• Access revocation (reassignments, timing, immediate)
d l b l h• Removed 99.9% availability phrasing
 Difficult to track and audit
 Replaced with “IAC” languagep g g
• Interactive Remote Access
 Clarify encryption and multi‐factor authentication points
R l f i t / f ti
 Remove examples from requirements / purpose of encryption

• Ports & Services –
 Physical ports ‐ FERC Directive
N di ti l if i t ll t h ithi 35 d• No remediation plan if install patches within 35 days
 Allow updates to existing plans rather than new plans all the
time
• Periodic review of patch sources – not individual patches
• Anti‐malware – clarify system level
• “Per device capability” clauses added
• Password changing / pseudorandom passwords
(RuggedCom vulnerability impacts)(RuggedCom vulnerability impacts)
• Evidence Retention (compliance vs. security monitoring)

• Take back reporting requirement from
EOP‐004 into CIP‐008
• Guidance on “active” vs. “passive” vulnerability
assessment
• V4 bypass language still in implementation plan• V4 bypass language still in implementation plan

Version 5 NOPR
• Issued April 18, 2013
 Posted at http://www.ferc.gov/whats‐new/comm‐
meet/2013/041813/E‐7.pdf
 75 pages
 Comments due June 24 2013 (60 days after publication in Comments due June 24, 2013 (60 days after publication in
Federal Register)
 Contains 48 specific requests for comment (may be overlap)p q ( y p)
 Proposes 11 directives for change
 Proposes 16 areas where FERC “may” direct changes

Version 5 NOPR
• Major Themes:
 “Identify, Assess and Correct” language
 Impact Categorization
o No reference to studies supporting bright‐line thresholds
o No consideration of coordinated attack on multiple low impacto No consideration of coordinated attack on multiple low impact
systems
o Only based on BES impact (i.e., no assessment of “confidentiality,
integrity or availability”)integrity or availability )
 Low Impact BES cyber Systems
o Specificity of requirements
o Lack of inventory

Version 5 NOPR
 Definitions:
o 15 minute impact in BES Cyber Asset
Generation Control Centers (vs control rooms)o Generation Control Centers (vs. control rooms)
o Removal of “communication networks” from Cyber Asset
o Use of “reliability tasks” phrase
o “Intermediate System” vs. “intermediate device”

Version 5 NOPR
 Implementation Plan
o Proposes to accept the “Version 4 bypass” language
Are 24 /36 months necessary?o Are 24 /36 months necessary?
 Violation Risk Factors
o Inconsistent with prior versions
 Violation Severity Levels
o Inconsistent with Commission guidelines
M d t b difi d b d t f “IAC” di io May need to be modified based on outcome of “IAC” discussion

Version 5 NOPR
• New Topics (post Order No. 706)
 Communications Security
o Including encryption, protections for serial communications
 Remote Access (more than proposed Version 5 language?)
o May already be covered by Version 5 languageo May already be covered by Version 5 language
 NIST topics
o Maintenance devices
o Separation of duties
o Threat / risk based categorization
o May include other areaso May include other areas
 May be others

Version 5 NOPR
• NERC Response:
 60 page response (largest response)
 Supports standards as filed:
o IAC:
- Discusses meaning of IAC languageDiscusses meaning of IAC language
- Reliability Benefit of IAC Language
- Compliance obligations of IAC language
- Consistency with NIST FrameworkConsistency with NIST Framework
oBES Cyber Asset Categorization and Protection
- Supports Facility rating approach
P i f l i BES C b A- Protections of low impact BES Cyber Assets
- Supports not requiring inventory of low impact BES Cyber Assets

Version 5 NOPR
• NERC Response (continued):
o Definitions: BES Cyber Asset
15 i- 15‐minute parameter
- 30‐day exclusion
o Definitions: Control Center
- Geographically disperse generating plants
o Definitions: Cyber Assets
- Removal of “communications networks”
o Definitions: Reliability Tasks
- Well‐understood term
o Definitions: Intermediate Deviceso Definitions: Intermediate Devices
- Filing oversight

Version 5 NOPR
• NERC Response (continued):
o Implementation Plan:
24 d 36 h i f i d- 24‐ and 36‐month timeframes appropriate and necessary
- Transition guidance and pilot program
o VRF & VSL
- Severity of violation as expressed in duration of violation
- Not two separate violations
o Other Technical Concerns
- Technical conferences to discuss issues
- Use Reliability Standards Development Process
o Remote Accesso Remote Access
- Concerns addressed in CIP‐004

Version 5 NOPR
• NOPR Comments:
 65 files submitted from 62 parties
 782 pages
 Generally supportive of NERC positions
I i h IAC lo Issues with IAC language
o Issues with RFA analysis and estimates (cost & time)
• Next Steps:Next Steps:
 FERC must read, summarize and react to all comments while
writing final rule

References
• Standard project 2008‐06 page:
 http://www.nerc.com/filez/standards/Project_2008‐
06_Cyber_Security.html
• Version 4 page:
// / / / http://www.nerc.com/filez/standards/Project_2008‐
06_Cyber_Security_PhaseII_Standards.html
• Version 4 Guidance Document• Version 4 Guidance Document
 http://www.nerc.com/docs/standards/sar/Project_2008‐
06_CIP‐002‐4_Guidance_clean_20101220.pdf
• Version 5 page:
 http://www.nerc.com/filez/standards/Project_2008‐
06_Cyber_Security_Version_5_CIP_Standards_.html

Questions
Scott Mix, CISSP
scott mix@nerc netscott.mix@nerc.net
215-853-8204

Cyber Security Standards Update: Version 5 by Scott Mix

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Cyber Security Standards Update: Version 5 by Scott Mix (20)

More from TheAnfieldGroup (8)

Recently uploaded (20)

Cyber Security Standards Update: Version 5 by Scott Mix