1 / 20

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

UCAIug: AMI Security Update – September 2008  AMI-SEC Task Force  AMI Security Acceleration Project (ASAP). AMI-SEC Task Force Chair: Darren Reece Highfill, CISSP darren@enernex.com. AMI-SEC Task Force. AMI-SEC is concerned with securing AMI system elements. Contextual Definition:

thaddeus-oneill
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

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

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

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

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

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

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

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

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

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

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

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

  16. AMI-SEC / ASAP Roadmap

  17. Deliverable Usage

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

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

More Related