SG Security WG Chair: Darren Highfill darren@utilisec

1. SG Security Working GroupFace-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

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

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

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

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

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

7. Funding & Workflow • Feeding and accelerating smart grid standards development • Model of public-private partnership

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

9. Security Profile Impact • Use cases in 3PDA form foundation of ESPI work • Common functional model facilitates definitive mapping of security requirements

10. Security Requirements Relevant to SG

11. 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 COMPLETE COMPLETE COMPLETE NISTIR 7628 Published August 2010 COMPLETE PROPOSED PROPOSED

12. ASAP-SG Process: Basic Steps Black Box White Box Justification Reqmts • Scope • Nominate functionality (i.e., use case titles) • Delineate real-world application/component coverage • Logical Architecture • Nominate logical architecture • Define roles by functionality • Refine use cases & logical architecture • Security Constraints • Define security & operational objectives • Perform failure analysis • Security Controls • Define controls (including recommended network segmentation) • Map and tailor controls to roles • Validation

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

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

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

16. 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…)

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

18. Scope

19. Roles and Functionality Application of Logical Architecture: Post-Event Analysis

20. WAMPAC Logical Architecture Communications Architecture Use Cases

21. Recommended Network Segmentation

22. Role Assignment to Segments

23. Mapping Controls to Roles

24. Control Definition

25. Security Profile Development Process

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

27. Mapping Roles to Actors

28. Security Principles  NISTIR Use Case Objectives

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

30. Interface Categories Controls Actors Comparison & Validation Map Validate Controls Roles Failure Analysis

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