SG Security Working GroupFace-to-Face Meeting – July 2011 @ Vancouver, BC

Usability Analysis Task ForceCybersec-Interop Task ForceEmbedded Systems Security Task Force

SG Security WG Chair:Darren Highfill

darren@utilisec.com

AgendaDay Timeslot Subject Group

Monday 1500-1700 SG Security Boot Camp SG Sec WG

Tuesday 0800-1000 Opening Plenary OpenSG

1030-1200 Agenda & Status UpdatesTesting & Certification SupportASAP-SG Process Review & Update

SG Sec WG

1300-1500 SG Security / SG Network Joint Session

Wednesday 0800-1000 SG Security / OpenADR*Embedded Systems Security TF

Joint Session SG Sec WG

1030-1200 Embedded Systems Security TF (continued) SG Sec WG

1300-1500 Usability Analysis TF SG Sec WG

1530-1730 CyberSec-Interop / LemnosTopic: Vulnerability DisclosurePlanning & Prioritization

SG Sec WG

*SGSec-OpenADR joint session will be held in Pavillion Ballroom D

Status Updates• NIST CSWG & PAPs

– AMI Security Subgroup– PAP10, PAP18, others?

• NERC CIP SDT• IEC TC 57 WG 15• ICSJWG Solutions Technology Subgroup• NERC Cyber Attack Task Force• DOE-NIST-NERC collaboration: Risk Management Framework

Testing & Certification• How do we align SG Security work products to facilitate

testing & certification?• Structure and format of requirements

– [Subject] [verb] [object] [parameters/constraints]• What does conformance / certification with a users group

specification mean?– Where are we feeding this work?– What is the eventual target?

• Project Description:

– Utility-driven, public-private collaborative project to develop system-level security requirements for smart grid technology

• Needs Addressed:

– Utilities: specification in RFP

– Vendors: reference in build process

– Government: assurance of infrastructure security

– Commissions: protection of public interests

• Approach:– Architectural team produce drafts for review

– Usability Analysis TF assess effectiveness

– SG Security WG review, approve

• Deliverables:– Strategy & Guiding Principles white paper

– Security Profile Blueprint

– 6 Security Profiles

– Usability Analysis

ASAP-SG: Summary

Schedule: June 2009 – May 2011Budget: $3M/year

($1.5M Utilities + $1.5M DOE)

Performers: Utilities, EnerNex, Inguardians, SEI, ORNL

Partners: DOE, EPRIRelease Path: NIST, UCAIugContacts:

Bobby Brown bobby@enernex.comDarren Highfill darren@utilisec.org

Schedule: June 2009 – May 2011Budget: $3M/year

($1.5M Utilities + $1.5M DOE)

Performers: Utilities, EnerNex, Inguardians, SEI, ORNL

Partners: DOE, EPRIRelease Path: NIST, UCAIugContacts:

Bobby Brown bobby@enernex.comDarren Highfill darren@utilisec.org

Slide 6 Bobby Brown

ASAP-SG Funding Distribution

Labor Security Engineers System Architects Penetration Testers (White Hat Hackers)

Travel – Face-to-face Meetings Meetings – Room, Audio/Visual, Webinar, Meals Supplies/Misc. – Printing, Tech Transfer Materials

Funding & Workflow• Feeding and accelerating smart grid Feeding and accelerating smart grid

standards developmentstandards development• Model of public-private partnershipModel of public-private partnership

Security Profile Impact• Early adoption: Early adoption: Utilities and commissions Utilities and commissions

referencing AMI SPreferencing AMI SP (CPUC, SCE, NV Energy…) (CPUC, SCE, NV Energy…)

• Process for developing a security profile has Process for developing a security profile has evolved substantially since initial AMI SP draftevolved substantially since initial AMI SP draft

• AMI Security Profile AMI Security Profile now under revisions now under revisions by CSWG AMI by CSWG AMI Security SubgroupSecurity Subgroup

Security Profile Impact• Use cases in 3PDA Use cases in 3PDA

form foundation of form foundation of ESPI workESPI work

• Common functional Common functional model facilitates model facilitates definitive mapping of definitive mapping of security requirementssecurity requirements

Security Requirements Relevant to SG

ASAP-SG Security Profiles

• Security Profile status:

– Advanced Metering Infrastructure

– Third Party Data Access

– Distribution Management

– Wide Area Monitoring, Protection,& Control (Synchrophasors)

– Home Area Networks

– Substation Automation

PROPOSED

PROPOSED

COMPLETE

COMPLETE

COMPLETE NISTIR 7628 PublishedAugust 2010

COMPLETE

1. Scopea) Nominate functionality (i.e., use case titles)b) Delineate real-world application/component coverage

2. Logical Architecturea) Nominate logical architectureb) Define roles by functionalityc) Refine use cases & logical architecture

3. Security Constraintsa) Define security & operational objectivesb) Perform failure analysis

4. Security Controlsa) Define controls (including recommended network segmentation)b) Map and tailor controls to roles

5. Validation

ASAP-SG Process: Basic Steps

Process Notes: Scope• Why is this important?

– First point of entry for new audiences– Will likely dictate whether the document gets broad

review and engagement

• What does it do?– End users must be able to figure out if this document

applies to them or not– Need an easy and clear “yes” or “no” answer– Should not have to understand the rest of the

document

• What is the approach?– Define functionality covered in real-world terms– Provide examples using real-world terminology

Process Notes: Logical Architecture• Why is this important?

– Lack of coverage for functionality is the root of security vulnerabilities

– Lack of coverage is rarely intentional• Ambiguity in terminology• Changes in functionality over time

• What does it do?– Provides abstract (vendor-neutral) representation of

the system to bind controls– Removes ambiguity about functionality covered

• What is the approach?– Define roles in terms of functionality– Describe relationships between the roles– Define the functionality in terms of use cases

• Use a normalized format that facilitates verification of coverage

Process Notes: Security Constraints• Why is this important?

– Security ultimately has a cost– How do we know we are investing in the right place?

• What does it do?– Provides justification for selection of controls– Provides traceability for when (not if) system

functionality changes– Provides a means to quantifiably claim coverage

• What is the approach?– Define objectives for system operation

• What the system should do• What the system should NOT do

– Define failures the system should prevent• Bind to functionality (avoidance is one means of mitigating risk)• Look at both common and functionality-specific failures

Process Notes: Security Controls• Why is this important?

– Actions and requirements must be precisely defined• What does it do?

– Provides actionable guidance for the end user– Establishes a context to link high-level objectives to low-

level security mechanisms• What is the approach?

– Generate controls• Brainstorm controls from failures• Normalize controls into approachable and useful organization for the

end user

– Map to logical architecture• System (i.e., network segmentation)• Roles

– Adapt controls to specific context for each role• (e.g., consider resource constraints, access requirements,

maintenance…)

Document EssentialsScope• Functionality Covered• Applications, Interfaces, & Sub-Components• Explicit Examples

Scope• Functionality Covered• Applications, Interfaces, & Sub-Components• Explicit Examples

Logical Architecture• Communications Architecture• Roles• Use Cases• Mapping to Concrete Applications

Logical Architecture• Communications Architecture• Roles• Use Cases• Mapping to Concrete Applications

Security Considerations• Contextual & Operational Assumptions• Security Principles• Failure Analysis

Security Considerations• Contextual & Operational Assumptions• Security Principles• Failure Analysis

Security Controls• Network Segmentation• Control Definitions• Mapping of Controls to Roles & Segments

Security Controls• Network Segmentation• Control Definitions• Mapping of Controls to Roles & Segments

Scope

Roles and FunctionalityApplication of Logical Architecture:Post-Event Analysis

WAMPAC Logical ArchitectureCommunicationsArchitecture Use Cases

Use Case 2 – Alignment Processes PMU Data

PM

UP

haso

r G

atew

ayD

ata

Sto

reA

lignm

ent

YesYes

No4: Archive

incoming data?Use Case 3

3: Alignment validates incoming

data packet

6: Data old (max lag time exceeded)?

7: Alignment discards data

2: Alignment monitors clock

5: Alignment sends data frames to

Data Store End

8: Alignment buffers data until all data received or max lag time

reached

Use Case 5

1B: Phasor Gateway forwards

PMU data to Alignment

Start

Start1A: PMU sends

data to Alignment

Recommended Network Segmentation

Role Assignment to Segments

Mapping Controls to Roles

Control Definition

Security Profile Development Process

Mapping Use Cases• Link structure varies

depending upon level of granularity in text vs. implementation

• Traceability provided regardless

• Analysis for coverage should be performed after catalog of profiles is more complete

{

Mapping Roles to Actors

Security Principles NISTIR Use Case Objectives

NISTIR Controls as Inspiration & to Ensure Coverage

• Start with relevant NISTIR control to address identified failure scenario

• Re-write control specifically for implementation

• Ensure control is testable

• Use NISTIR to ensure coverage

Comparison & Validation

MapValidate

Actors

Interface CategoriesControls

Roles

Failure Analysis

Controls

Other Benefits

• NIST-IR 7628 and Security Profiles Traceability

• Coverage and Gap Analysis

• Addresses some GAO Cybersecurity Challenges Report concerns– Comprehensive Security– SynchroPhasor Security– Metrics for Evaluating Security Posture