Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AMI Security 101 - Smart Grid Security East 2011

2,510 views

Published on

This is the slide deck from the Smart Grid Security East 2011 pre-conference workshop (www.smartgridsecurityeast.com)

  • Be the first to comment

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: http://www.schneier.com/paper-attacktrees-ddj-ft.html
  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>

×