AMI Security 101 - Smart Grid Security East 2011


Published on

This is the slide deck from the Smart Grid Security East 2011 pre-conference workshop (

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • AMI Security 101 - Smart Grid Security East 2011

    1. 2. AMI Security Workshop <ul><li>Introductions </li></ul><ul><li>AMI Security Essentials </li></ul><ul><li>The Road Ahead </li></ul><ul><li>Grid Operator Perspective </li></ul><ul><li>Review/ Q&A </li></ul>
    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
    3. 4. Agenda <ul><li>System Overview </li></ul><ul><li>AMI Security Challenges (Top Down) </li></ul><ul><li>How AMI Impacts The Grid </li></ul><ul><li>How Are Vendors and Utilities Managing Security </li></ul><ul><li>Vulnerability Testing </li></ul><ul><li>Physical Security </li></ul><ul><li>Lessons Learned (Bottom Up) </li></ul><ul><li>The Road Ahead </li></ul>
    4. 5. Gartner Hype Cycle – Where Are We? You Are Here
    5. 6. Merging Two Infrastructures Electrical Infrastructure “ Intelligence” Infrastructure
    6. 7. The Smart Grid
    7. 8. Utility WAN NAN HAN Securing Communications
    8. 9. IT-based & Web-based WAN RF & Embedded Technologies & Protocols
    9. 10. Smart Meters and Infrastructure
    10. 11. AMI Concerns (consumers)
    11. 12. AMI  HAN Concerns
    12. 13. AMI Security for Sale <ul><li>FIPS-validated cryptography, including required algorithms for Zigbee & Smart Energy profiles </li></ul><ul><li>Performance tested for secure remote access to/from network services and AMI </li></ul><ul><li>Scalable server infrastructure for fast authentication, signing & verification of trusted AMI devices </li></ul><ul><li>Common security framework supports both Zigbee and HomePlug AMI services </li></ul><ul><li>Protects AMI devices from malware, unauthorized code or counterfeit services </li></ul><ul><li>Advanced AMI connection handling and efficient key management techniques </li></ul>
    13. 14. SDL Requirements and Recommendations <ul><li>Education. </li></ul><ul><li>Risk assessment. </li></ul><ul><li>Threat modeling. </li></ul><ul><li>Coding. </li></ul><ul><li>Testing. </li></ul><ul><li>Final security review. </li></ul><ul><li>Maintenance. </li></ul>
    14. 15. Embedding Security Into Software And Culture Delivering secure software requires <ul><li>Analyze security and privacy risk </li></ul><ul><li>Define quality gates </li></ul><ul><li>Threat modeling </li></ul><ul><li>Attack surface analysis </li></ul><ul><li>Specify tools </li></ul><ul><li>Enforce banned functions </li></ul><ul><li>Static analysis </li></ul><ul><li>Dynamic/Fuzz testing </li></ul><ul><li>Verify threat models/attack surface </li></ul><ul><li>Response plan </li></ul><ul><li>Final security review </li></ul><ul><li>Release archive </li></ul><ul><li>Response execution </li></ul>Executive commitment  SDL a mandatory policy Source: Microsoft, 2009 <ul><li>Core training </li></ul>Ongoing Process Improvements  6 month cycle
    15. 16. Software Development Lifecycle (SDL) Models <ul><li>Microsoft </li></ul><ul><ul><li>SDL </li></ul></ul><ul><ul><li>Simplified SDL </li></ul></ul><ul><li>OWASP CLASP </li></ul><ul><li>Cigital TouchPoints </li></ul>Source: Microsoft, 2009
    16. 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
    17. 18. What Products Should Apply SDL? <ul><li>Any software the regularly stores, processes or communicates PII (Personally Identifiable Information) or other sensitive information </li></ul><ul><li>Any software that regular connects to the internet or other networks </li></ul><ul><ul><li>Always online </li></ul></ul><ul><ul><li>Designed to be online </li></ul></ul><ul><ul><li>Exposed online </li></ul></ul><ul><li>Any software that automatically downloads updates </li></ul><ul><li>Any software that accepts or process data from an unauthenticated source. </li></ul><ul><ul><li>Callable interfaces that “listen” </li></ul></ul><ul><ul><li>Functionality that parses any unprotected file types that should be limited to system administrators </li></ul></ul><ul><li>Any product that has control capabilities </li></ul>
    18. 19. A Security Framework : SD 3 +C <ul><li>Threat Modeling </li></ul><ul><li>Code Inspection </li></ul><ul><li>Penetration Testing </li></ul>Source: Microsoft, 2009 <ul><li>Unused features off by default </li></ul><ul><li>Reduce attack surface area </li></ul><ul><li>Least Privilege </li></ul><ul><li>Prescriptive Guidance </li></ul><ul><li>Security Tools </li></ul><ul><li>Training and Education </li></ul><ul><li>Community Engagement </li></ul><ul><li>Transparency </li></ul><ul><li>Clear policy </li></ul>
    19. 20. Attack Surface Reduction <ul><li>What is a system ’s attack surface? </li></ul><ul><ul><li>Varies by product </li></ul></ul><ul><ul><li>Doesn ’t always mean just the exposed areas </li></ul></ul><ul><li>What is attack surface reduction? </li></ul><ul><ul><li>Lowering the exposed footprint of an application or process </li></ul></ul><ul><ul><li>Eliminating exposure/vulnerability points </li></ul></ul>
    20. 21. Attack Surface Example Source: Microsoft, 2009
    21. 22. Threat Modeling <ul><li>Must consider both scenario-based threat modeling and feature-based threat modeling </li></ul><ul><li>Scenario-based </li></ul><ul><ul><li>Develop attack tree </li></ul></ul><ul><ul><li>Start with goal and work backwards </li></ul></ul><ul><li>Feature-based </li></ul><ul><ul><li>Analyze product features </li></ul></ul><ul><ul><li>Scrutinize interfaces </li></ul></ul><ul><ul><li>Evaluate component interaction </li></ul></ul>
    22. 23. Developing Attack Trees <ul><li>Describes system security in formal, methodical way </li></ul><ul><li>Attack trees are represented in a “tree” structure </li></ul><ul><ul><li>Goal is root node </li></ul></ul><ul><ul><li>Attack steps are leaf nodes </li></ul></ul>
    23. 24. Example Attack Tree Source: Schneier, Bruce, Attack Trees, Dr. Dobbs Journal, December 1999, accessed at:
    24. 25. Coding <ul><li>Development of standards </li></ul><ul><ul><li>Cryptographic </li></ul></ul><ul><ul><li>Coding </li></ul></ul><ul><li>Code reviews </li></ul><ul><ul><li>Not just bug hunts </li></ul></ul><ul><ul><li>Look at the code itself </li></ul></ul><ul><ul><ul><li>Canonicalization of input </li></ul></ul></ul><ul><ul><ul><li>Input validation </li></ul></ul></ul><ul><ul><ul><li>Bounds checking </li></ul></ul></ul>
    25. 26. Testing <ul><li>All products and components must be test vigorously </li></ul><ul><ul><li>Software </li></ul></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>Interaction </li></ul></ul><ul><li>Use threat model as a guide </li></ul><ul><li>Be creative </li></ul>
    26. 27. Final Security Review <ul><li>Provides for a final validation of products </li></ul><ul><li>Input from development and testing teams </li></ul><ul><li>Allows for attestation of product security state as shipped </li></ul><ul><li>Feeds into the next development cycle </li></ul>
    27. 28. Maintenance <ul><li>Includes security and incident response </li></ul><ul><li>Requires a pre-established plan </li></ul><ul><li>Should include: </li></ul><ul><ul><li>How will vulnerabilities be reported </li></ul></ul><ul><ul><li>Disclosure </li></ul></ul><ul><ul><li>Incident response </li></ul></ul><ul><ul><li>Support </li></ul></ul>
    28. 29. Multi-Generational Equipment Issues <ul><li>Meters are considered to be long-term investments </li></ul><ul><li>Changes in technology happen on 3 – 5 year cycles </li></ul><ul><li>Technology cycle is out of sync with meters </li></ul><ul><li>How do we solve this problem? </li></ul>
    29. 30. Meter Design Lifecycle <ul><li>Design must be secure from the outset </li></ul><ul><li>Flexibility to mix and match components </li></ul><ul><ul><li>Possibly within meter hardware </li></ul></ul><ul><li>Firmware is key </li></ul><ul><ul><li>Must be upgradeable </li></ul></ul><ul><ul><li>Must be secure </li></ul></ul>
    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
    31. 32. Selecting Penetration Testers <ul><li>Rate security partners on the following criteria: </li></ul><ul><ul><li>What is their security maturity? </li></ul></ul><ul><ul><li>What is their organizational maturity? </li></ul></ul><ul><ul><li>What is their industry maturity? </li></ul></ul><ul><li>Grade the potential partners on the following scale: </li></ul><ul><ul><li>Tier 1: Met all 3 criteria </li></ul></ul><ul><ul><li>Tier 2: Met 2 out of the 3 </li></ul></ul><ul><ul><li>Tier 3: Met only 1 out of the 3 </li></ul></ul>
    32. 33. Security Focus and AMI Security Goals
    33. 34. Some Initial Truths <ul><li>The Smart Grid is Cyber-Physical, comprised of various physical, information, cognitive, and behavioral assets </li></ul><ul><li>The more secure a system is, the more difficult it is to deal with </li></ul><ul><li>Professional bad guys take the path of least resistance (trained opportunists) and others are up for the challenge </li></ul><ul><li>Most enterprise security professionals are concerned with building systems not breaking them </li></ul><ul><li>Generally, people do not think about way that systems can be abused </li></ul><ul><li>Security is a continuous process </li></ul><ul><li>False alarm is one of the most critical security falilures </li></ul><ul><li>Plenty of People Know How, But Have No Motive... </li></ul>
    34. 35. Outside the Fence <ul><li>Devices are no longer behind fences </li></ul><ul><ul><li>Sides of home </li></ul></ul><ul><ul><li>Back yards </li></ul></ul><ul><ul><li>Back allies </li></ul></ul><ul><ul><li>Poles on street corners </li></ul></ul><ul><ul><li>PS3 attack </li></ul></ul>
    35. 36. Security vs Operations Mount the Box How High?
    36. 37. Security vs Operations Mount the Box How High?
    37. 38. Security vs Operations Mount the Box How High?
    38. 39. Security vs Operations Mount the Box How High?
    39. 40. Security vs Operations Mount the Box How High?
    40. 41. Inside the Box Memory Coms Module Coms Module USB Serial Sensor Relay Switch Actuator
    41. 42. The Cyber-Physical Line Memory Coms Module Coms Module USB Serial Sensor Relay Switch Actuator
    42. 43. We Are Secure…It Is Encrypted <ul><li>Encryption is not enough </li></ul><ul><li>Where is just as important as how </li></ul><ul><li>Don't forget “what” ! </li></ul>
    43. 44. Embedded-OS's <ul><li>Flavor is not the issue </li></ul><ul><li>Security updates/maintenance </li></ul><ul><li>Policies </li></ul><ul><li>Testing </li></ul><ul><li>Test environments </li></ul><ul><li>Embedded-embedded- OS's/Firmware </li></ul>
    44. 45. Why Perform Vulnerability Testing? <ul><li>Completely new architecture with end-points / network reaching out to customer homes </li></ul><ul><li>Never before seen devices and applications </li></ul><ul><li>Validating vendor security statements </li></ul><ul><li>Regulators </li></ul><ul><li>Media coverage </li></ul>
    45. 46. Things To Consider <ul><li>Perform your risk assessment (ongoing process) </li></ul><ul><ul><li>New equipment </li></ul></ul><ul><ul><li>Legacy equipment </li></ul></ul><ul><ul><li>Multiple vendors </li></ul></ul><ul><li>Where to begin? </li></ul><ul><li>What is your approach? </li></ul><ul><ul><li>White, Grey, Black Box </li></ul></ul><ul><li>Who is going to actually do the work? </li></ul><ul><ul><li>Internal </li></ul></ul><ul><ul><li>External </li></ul></ul><ul><li>Communication </li></ul><ul><ul><li>Walking gently </li></ul></ul>
    46. 47. Internal Resources <ul><li>Some technology similar to standard pen testing </li></ul><ul><ul><li>Linux </li></ul></ul><ul><ul><li>Wi-Fi </li></ul></ul><ul><ul><li>Can utilize familiar tools (i.e., Backtrack, Wireshark) </li></ul></ul><ul><li>Great experience for internal teams </li></ul><ul><li>Inexpensive </li></ul><ul><li>Might not have exposure to certain technologies (i.e., embedded systems, RF, cellular, electrical engineering) </li></ul>
    47. 48. External Resources <ul><li>Everyone is a smart grid security expert </li></ul><ul><li>New revenue stream for the big players </li></ul><ul><li>Just my opinion - You get what you pay for </li></ul><ul><li>Non-disclosure agreement </li></ul><ul><li>Organizing the effort </li></ul><ul><li>Getting internal people comfortable with a 3 rd party </li></ul><ul><li>Knowledge transfer to your internal teams </li></ul>
    48. 49. Common Findings <ul><li>Password management </li></ul><ul><li>Physical security </li></ul><ul><li>Unnecessary services </li></ul><ul><li>Insecure protocol versions </li></ul><ul><li>Access control </li></ul><ul><ul><li>Interfaces </li></ul></ul><ul><ul><li>Console timeouts </li></ul></ul>
    49. 50. Communication <ul><li>Keeping everyone informed is key </li></ul><ul><li>Status updates </li></ul><ul><ul><li>Internal teams </li></ul></ul><ul><ul><li>Vendors </li></ul></ul><ul><li>Reporting </li></ul><ul><ul><li>Put findings in buckets </li></ul></ul><ul><ul><li>Meet one-on-one with the key stakeholders </li></ul></ul><ul><ul><li>Remediation (have a plan) </li></ul></ul>
    50. 51. Other Tips <ul><li>Great information on design and can influence purchasing decisions </li></ul><ul><li>Be careful with your report </li></ul><ul><li>Update risk assessment </li></ul><ul><li>Feed information to your vendors </li></ul>
    51. 52. Lessons Learned <ul><li>What should we NOT do? </li></ul><ul><li>Best practices change over time. </li></ul><ul><li>Less productive practices generally do not change over time (bad ideas remain bad ideas). </li></ul><ul><li>Learn from those who have blazed the trail. </li></ul><ul><li>Pay attention to the dynamic security environment. </li></ul>