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

2. Agenda DayTimeslotSubjectGroup Monday1500-1700SG Security Boot CampSG Sec WG Tuesday0800-1000Opening PlenaryOpenSG 1030-1200Agenda & Status Updates Testing & Certification Support ASAP-SG Process Review & Update SG Sec WG 1300-1500SG Security / SG NetworkJoint Session Wednesday0800-1000SG Security / OpenADR* Embedded Systems Security TF Joint Session SG Sec WG 1030-1200Embedded Systems Security TF (continued)SG Sec WG 1300-1500Usability Analysis TFSG Sec WG 1530-1730CyberSec-Interop / Lemnos Topic: Vulnerability Disclosure Planning & Prioritization SG Sec WG *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.combobby@enernex.com Darren Highfill darren@utilisec.orgdarren@utilisec.org 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.combobby@enernex.com Darren Highfill darren@utilisec.orgdarren@utilisec.org

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

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

8. Security Profile Impact Early adoption: Utilities and commissions referencing AMI SP (CPUC, SCE, NV Energy…)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 draftProcess for developing a security profile has evolved substantially since initial AMI SP draft AMI Security Profile now under revisions by CSWG AMI Security SubgroupAMI Security Profile now under revisions by CSWG AMI Security Subgroup

9. Security Profile Impact Use cases in 3PDA form foundation of ESPI workUse cases in 3PDA form foundation of ESPI work Common functional model facilitates definitive mapping of security requirementsCommon 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 PROPOSED COMPLETE NISTIR 7628 Published August 2010 COMPLETE

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

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

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. Comparison & Validation Map Validate Actors Interface Categories Controls Roles Failure Analysis Controls

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