SG Security F2F Vancouver - Day 1, 20110718

advertisement
SG Security Working Group
Face-to-Face Meeting – July 2011 @ Vancouver, BC
Usability Analysis Task Force
Cybersec-Interop Task Force
Embedded Systems Security Task Force
SG Security WG Chair:
Darren Highfill
darren@utilisec.com
Agenda
Day
Timeslot
Subject
Group
Monday
1500-1700
SG Security Boot Camp
SG Sec WG
Tuesday
0800-1000
Opening Plenary
OpenSG
1030-1200
Agenda & Status Updates
Testing & Certification Support
ASAP-SG Process Review & Update
SG Sec WG
1300-1500
SG Security / SG Network
Joint Session
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 / Lemnos
Topic: Vulnerability Disclosure
Planning & Prioritization
SG Sec WG
Wednesday
*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?
ASAP-SG: Summary
• 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
Schedule: June 2009 – May 2011
Budget: $3M/year
($1.5M Utilities + $1.5M DOE)
Performers: Utilities, EnerNex,
Inguardians, SEI, ORNL
Partners: DOE, EPRI
Release Path: NIST, UCAIug
Contacts:
Bobby Brown bobby@enernex.com
Darren Highfill darren@utilisec.org
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
Slide 6
Bobby Brown
Funding & Workflow
• Feeding and accelerating smart grid
standards development
• Model of public-private partnership
Security Profile Impact
• Early adoption: Utilities and commissions
referencing AMI SP (CPUC, SCE, NV Energy…)
• Process for developing a security profile has
evolved substantially since initial AMI SP draft
• AMI Security Profile
now under revisions
by CSWG AMI
Security Subgroup
Security Profile Impact
• Use cases in 3PDA
form foundation of
ESPI work
• Common functional
model facilitates
definitive mapping of
security requirements
Security Requirements
Relevant to SG
ASAP-SG Security Profiles
• Security Profile status:
– Advanced Metering Infrastructure
– Third Party Data Access
COMPLETE
COMPLETE
– Distribution Management
COMPLETE
August 2010
– Wide Area Monitoring, Protection,
& Control (Synchrophasors)
– Home Area Networks
– Substation Automation
COMPLETE
PROPOSED
PROPOSED
NISTIR 7628 Published
ASAP-SG Process: Basic Steps
1.
Scope
a)
b)
2.
Logical Architecture
a)
b)
c)
3.
Define security & operational objectives
Perform failure analysis
Security Controls
a)
b)
5.
Nominate logical architecture
Define roles by functionality
Refine use cases & logical architecture
Security Constraints
a)
b)
4.
Nominate functionality (i.e., use case titles)
Delineate real-world application/component coverage
Define controls (including recommended network segmentation)
Map and tailor controls to roles
Validation
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 lowlevel 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 Essentials
Scope
• Functionality Covered
• Applications, Interfaces, & Sub-Components
• Explicit Examples
Logical Architecture
•
•
•
•
Communications Architecture
Roles
Use Cases
Mapping to Concrete Applications
Security Considerations
• Contextual & Operational Assumptions
• Security Principles
• Failure Analysis
Security Controls
• Network Segmentation
• Control Definitions
• Mapping of Controls to Roles & Segments
Scope
Roles and Functionality
Application of Logical Architecture:
Post-Event Analysis
WAMPAC Logical Architecture
Use Cases
PMU
Use Case 2 – Alignment Processes PMU Data
Start
1A: PMU sends
data to Alignment
Data Store
Alignment
2: Alignment
monitors clock
Phasor Gateway
Communications
Architecture
3: Alignment
validates incoming
data packet
4: Archive
incoming data?
Yes
Yes
5: Alignment sends
data frames to
Data Store
7: Alignment
discards data
Use Case 5
Start
1B: Phasor
Gateway forwards
PMU data to
Alignment
6: Data old
(max lag time
exceeded)?
No
8: Alignment
buffers data until
all data received
or max lag time
reached
End
Use Case 3
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
Interface Categories
Controls
Actors
Map
Validate
Controls
Roles
Failure Analysis
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
Download