1 / 11

AMI Security Roadmap

AMI Security Roadmap. April 13, 2007. Security History and Status. Pre-RFP Initial security analysis focused on threat assessments, information classification, NERC CIP analysis, and functional expectations

doyon
Download Presentation

AMI Security Roadmap

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. AMI Security Roadmap April 13, 2007

  2. Security History and Status • Pre-RFP • Initial security analysis focused on threat assessments, information classification, NERC CIP analysis, and functional expectations • Conceptual security architecture based on business and regulatory requirements. This architecture showed the system capabilities and end to end cryptographic information flow • Functionality represented within the conceptual architecture focused on: • Preventing unauthorized access/control of the AMI network • Secure meter registration and revocation • AMI device authentication • Customer data integrity/confidentiality • Advanced intrusion detection • Conceptual security architecture validated with technology and method specific design example (AMI Reference Architecture). Design used AMI Lightweight Cryptographic Services (ALCS) based on robust secret sharing techniques. Reference architecture used for internal validation only… • Confirmed vendor responsibility • Continuing concerns over vendors technical capability maturity • RFP • Requirements abstracted to highest functional representation to allow for vendor design flexibility • Conceptual architecture and information shown as an example • Capability maturity risk mitigation: Recommend partnering with a third party security vender • Current • Vendors RFP security response confirmed capability concerns (varied by vendor) • In general, current industry/vendor security related capability maturity is low

  3. Strategies and Principles • AMI security artifacts are specified and designed as a response to business requirements, regulatory requirements and environmental threats • Uses Unified Information Assurance Framework (i.e., System engineering based methodologies) • Functional requirements are appropriate given risk analysis • AMI security services are part of unified business enterprise (i.e., TDBU, CSBU, IT) • Use industry engagement (when appropriate) to further industry capabilities • motivate vendors through standards • design vetting • establish best practices • Use Evolutionary/Spiral development to roll capabilities out over a several releases (realistic expectations) • Security capabilities enable functionality and ultimately add business value

  4. Goals of AMI Security Design & Implementation • Security is viewed as an enabling function to increase capabilities over time • Security Design is focused on mitigating the impact of the realization of AMI security requirements on the performance of the entire AMI solution • Security is design in the context of the overall AMI System of Systems Context • Threats and vulnerabilities are evaluated in the context of the risk to the business processes AMI enables Security Design in the context of the overall AMI System

  5. Security Technology Capability Maturity (Updated)

  6. Field Test: Capabilities and Architecture • Initial Configuration of Cryptographic Services • Field Test Configuration primarily used for Performance related testing (Crypto Latency: Computational and Network) • Vendors support Field Test Capabilities (Pre-placed keys)

  7. Release One: Capabilities and Architecture • Initial Key Management Services • Integration with Infrastructure Services (e.g., IDM, Access Controls) • Complete Network Configuration (e.g., firewall and IPS services)

  8. Release Two: Capabilities and Architecture • Add HAN Device Authentication & Confidentiality • Key Management and Cryptographic Updates (RFP Compliances)

  9. Release Three: Capabilities and Architecture • Complete set of Security Services • Cryptographic Update: Complete Registration, Authentication, Distribution • Integrated with IT PKI • HAN Security Update

  10. Unified Enterprise Context • Cryptographic scheme unified across enterprise • Complete enterprise (AMI+DA+CSN) view through audit services • All field elements are registered and authenticated • Centralized security operations for field assets • Leverages existing IT services (e.g., IDM) • Common/shared management services

  11. Next Steps • Internal engagement within SCE • Security workshops (TDBU, CSBU, IT) • Business policy alignment • External engagement with Vendors • Clarify vendor direction • Clarify adherence to industry and SCE policies • Ensure vendor integration within SCE enterprise • External engagement with Industry • Push and monitor security standards (e.g., Title-24, openHAN, utilityAMI, UtiliPoint, etc.) • Use open Innovation approach to lead the way in AMI Security

More Related