AMI-SEC Task Force Chair: Darren Reece Highfill, CISSP darren@enernex

1. UCAIug: AMI SecurityUpdate – September 2008AMI-SEC Task ForceAMI Security Acceleration Project (ASAP) AMI-SEC Task Force Chair: Darren Reece Highfill, CISSP darren@enernex.com

2. AMI-SEC Task Force • AMI-SEC is concerned with securing AMI system elements. • Contextual Definition: “…those measures that protect and defend AMI information and systems by assuring their ability to operate and perform in their intended manner in the face of malicious actions.” • Purpose • Produce technical specification • Used by utilities to assess and procure • Used by OpenAMI – part of AMI/DR Reference Design • Determine baseline level of detail • Prescriptive in nature • Compliant products will have known functionality and robustness

3. AMI-SEC Task Force • Formation: August 23, 2007 • Q4 2007: Initial exploration, definition of scope, consensus on approach • January 2008: Identification of 4 Deliverables • Risk Assessment • Architectural Description • Component Catalog • Implementation Guide • Current Participation: • 127 Subscribers to Listserv • More than a dozen major utilities actively engaged

5. AMI-SEC 2008 – Original Plan Risk Assessment / System Requirements Architectural Description Component Catalog Implementation Guide

6. System Requirements • Problem: Q1 2008 AMI-SEC work to generate Risk Assessment was significant task • Substantially tapped volunteer resources • Risk Assessment very thorough, but only implied requirements (not explicit) • System Requirements document needed to be separated • Utilities expressing need for requirements to use in procurement process

7. Outrunning the Train • Initial Concept: Late January 2008 (hat tip to Consumers Energy) • Challenge:AMI-SEC TF is volunteer-based • Operates somewhat like a standards body • Heavy deliverable schedule, pressing industry need • Utilities strapped for human resources • Solution: Utility-initiated collaborative project with DOE and EPRI • Band together to fund SME’s • Make the team directed, agile, and accountable • Do “AMI-SEC homework” for utilities (off-load utility personnel) • Utilize FFRDC resources (INL, ORNL, SEI) • Perform independent 3rd party testing • Collaborative R&D at EnerNex, EPRI Living Laboratory, Utility Laboratories, and Pilot Locations

8. AMI Security Acceleration Project (ASAP) Roadmap to Secure Control Systems in the Energy Sector • Outcomes: Support utilities procuring and deploying AMI • Roadmap Challenges: Lack of security standards, guidance, best practices • Approach: • Provide "drop-in" RFP security requirements • Develop test plans and methodologies • Perform vulnerability testing of AMI solutions • Produce recommendations for AMI security architecture • Progress/accomplishments: Team built, research underway, documentation emerging • Schedule:Jan08 – Dec08 • Level of Effort: High • Performers: EnerNex, Intelguardians, SEI, INL, ORNL • Partners: Utilities, DOE, EPRI

9. AMI-SEC 2008 – Revised Plan (includes ASAP)

10. Risk Assessment • What must be addressed by the system and why • Provide traceability for eventually selected mitigation methods back to organizational value • Features: • Asset Catalog • Threat Profiles • Vulnerability Analysis • Threat-Vulnerability-Asset Mapping • Scenario Prioritization

11. System Security Requirements • Catalog of available requirements • Pulled from wide library of many sources • Common Criteria • DHS Control Systems Catalog • FIPS 140-2 • NIST 800-53, 800-82 • NERC CIP • … (more coming) • Features • System Constraints • States and Modes • Security Objectives • Assembled and Categorized Requirements

12. Architectural Description • Abstract (logical, platform-agnostic) mitigation plan for addressing requirements identified in the Risk Assessment. • Features: • Architectural Representation of Security Systems • Logical Function Descriptions • System, Subsystem, and Function Boundaries

13. Component Catalog • Commonly found patterns of functions and services performed by individual components • Include specific technologies, but will not be competitive in nature – patterns will overlap • Note: Any single system implementation will use only a subset of the catalog. • Features: • Design Patterns • Functional Primitives • Technological Applications and Considerations

14. Implementation Guide • Guidance to utilities and vendors for selection, assembly, and implementation of components from the Component Catalog • Integration Patterns • Procedures, Considerations, Guarantees, and Risks for Component Assembly • Performance Parameters and Relative Metrics • Recommendations and Guidance for Technology Selection • Best Practices to Ensure Component Interoperability and System Longevity

15. ASAP – Participants • Current Signees: • Consumers Energy, SCE, PG&E, Duke, Oncor, AEP, BC Hydro • Two more in-process, two more committed EnerNex Process management and draft contributions / editing Software Engineering Institute (Carnegie Mellon) Process review / support and targeted analytical reports Red Team Testing procedures / methodologies and first-level evaluation of landscape Idaho National Lab Detailed analytical report and recommendations for AMI communications architecture

16. ASAP – Objectives • Ease utility HR demands of participating in volunteer task force • Dedicated, accountable resources • Utility personnel needed for requirements gathering • Provide “drop-in” set of RFP security requirements • Vendor-oriented summary of requirements • Develop test plans and methodologies • Evaluate security functionality • Perform vulnerability testing of AMI solutions • Establish 3rd party collaborative testing • First-cut cross-section • Produce recommendations for AMI communications security architecture • Underlying protocols and technologies • Survivability and the Systems Development Life Cycle (SDLC)

17. AMI-SEC / ASAP Roadmap

18. Deliverable Usage

19. Goals & Objectives – Status • Ease utility HR demands • Done and continuing: utilities have been able to guide the process through AMI-SEC with occasional email and phone calls. • Provide RFP material • Almost done: System Security Requirements document at 95% mark. • Develop test plans • Underway: Red Team and Idaho National Laboratory have been working on these since early summer. • Perform vulnerability testing • Ready to start: Red Team currently awaiting vendor equipment. • Produce recommendations for security architecture • Underway: Architectural Description document at 95% mark, INL recommendations in progress.

20. Questions? darren@enernex.com AMI-SEC Collaboration Site http://osgug.ucaiug.org/utilisec/amisec