The document outlines the agenda for an AMI security workshop, including introductions, an overview of AMI security challenges from both top-down and bottom-up perspectives, how utilities are managing security, vulnerability testing, lessons learned, and the road ahead. Presenters are from security companies and utilities to discuss topics like threat modeling, attack surfaces, software development lifecycles, penetration testing, and ongoing security processes.
Truly Secure: The Steps a Security Practitioner Took to Build a Secure Public...
AMI Security 101 - Smart Grid Security East 2011
1.
2.
3. Presenters Slade Griffin – Penetration Testing & Incident Handling Engineer, EnerNex Kevin Brown – RF & Embedded Security Engineer, EnerNex Ido Dubrawsky – Security Engineering Team Lead, Itron Robert Former – Head of Security Research and Testing, Itron Stephen Chasko – Principal Security Engineer, Landis+Gyr Edward Beroset – Director of Technology and Standards, Elster Robert Humphrey – Lead IT Security Analyst, Duke Energy
17. Security Development Lifecycle vs. Traditional Development Lifecycle Threat Modeling Complete and Mitigations Reflected in Specifications Product Code Complete Final Release Candidate Requirements Design Implementation Verification Release Support & Servicing Feature Lists Quality Guidelines Architecture Docs Schedules Functional Specifications Design Specifications Testing and Verification Development of New Code Bug Fixes Code Signing & Signoff RTM Product Support Service Packs/QFEs Security Updates Security Kickoff Security Design Best Practices Security Architecture & Attack Surface Review Threat Modeling Use Security Development Tools & Security Best Dev & Test Practices Create Security Documentation And Tools for Products Prepare Security Response Plan Security Push Pen Testing Final Security Review Signoff On Security Requirements Security Servicing & Response Execution Security Training
24. Example Attack Tree Source: Schneier, Bruce, Attack Trees, Dr. Dobbs Journal, December 1999, accessed at: http://www.schneier.com/paper-attacktrees-ddj-ft.html
25.
26.
27.
28.
29.
30.
31. Attack Tree Threat Assessment Security Goals Privacy Assessment Incident Response Periodic Threat Assessment Process Audits Security Test Results Audit against threat model External Penetration Testing Process Compliance Release Verification Peer Review Resolution Automated Review Results Tool Review Security Architecture Cryptography Review Security Test Plan – Attacks, Cryptography, Functionality Coding Practices
41. Inside the Box Memory Coms Module Coms Module USB Serial Sensor Relay Switch Actuator
42. The Cyber-Physical Line Memory Coms Module Coms Module USB Serial Sensor Relay Switch Actuator
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
Hinweis der Redaktion
And applications. As utilities begin to trust the information and availability of these systems the are being automated; taking the human out of the loop. Vulnerabilities are constantly changing - algorithms broken - faster computers, cloud computing, parallel computing at desktop (graphics cards) - increased availability to commodity components - etc., etc.
May indicate this as Risk Management.. this is an ongoing process too.
I get the notion that many utilities get just one person to do their testing vs. selecting a team where each brings value within a given skill set. Even if a utility picks a company to do their testing, only one person gets assigned. I think it is important to get the diverse skill set: power systems understanding, understanding regulation, standards, and best practices for the given industry, embedded security, network security, platform security, project management and so on. I think another thing for external engagements is knowing what the information sharing agreement is. I treat the Duke-EnerNex relationship as a closed one. Meaning we do not disclose any findings or information except to Duke. I’ve noticed in some instances where the researcher wants to retain rights to the information or set a time-limit on when they can release their findings to the general public. Another arrangement would be where there is open information sharing between the utility and vendor. In whatever the case, I think utilities should know what they are signing up for.