SGSB Webcast 5: Smart Grid Software Security

  • 2,525 views
Uploaded on

The Smart Grid is being built out of hundreds of thousands of software applications totaling billions of lines of code. Current cyber security best practices for IT systems including network IDS and …

The Smart Grid is being built out of hundreds of thousands of software applications totaling billions of lines of code. Current cyber security best practices for IT systems including network IDS and IPS, anti virus and platform patch management systems, are necessary but far from sufficient for keeping attackers at bay. Most custom developed apps are full of high severity vulnerabilities and hackers have repeatedly shown they know how to get through perimeter defenses to reach apps and exploit their weaknesses. This presentation discusses the challenges posed by the extensive use of software systems to achieve the smarter functionality we all seek, and offers high-level solution paths to get begin to get this problem under control.

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • softgrid
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,525
On Slideshare
0
From Embeds
0
Number of Embeds
10

Actions

Shares
Downloads
54
Comments
1
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Smart Grid Software (Softgrid) Security Andy Bochman Editor : The Smart Grid Security Blog (SGSB) September 2010 Webcast Series Volume 5
  • 2.
    • How much software’s in the Smart Grid?
    • Give me one good reason to care about this
    • Some answers + questions, questions, questions
    • Resources
    • What’s next in series
    Overview
  • 3. All Smart Grid software could fit in this http://www.flickr.com/photos/gem66/52306307/
  • 4. But it is more than many of these http://www.flickr.com/photos/faisalsaeed/212339449/
  • 5. Ballparking grid software volumes
    • Counting and accounting for software:
      • Invisible + weightless = hard to quantify/track
      • Expensive
      • Complex and confusing
      • Often not deterministic
    • Here are some approaches:
      • How many apps in one large utility?
      • How many lines of code in an average utility app?
      • How much code in a new COTS Smart Grid app?
      • How much code is in a Smart Meter? In an EV?
      • How many of these apps/systems will be connected to the Smart Grid (sometimes/all the time)?
    • So that’s how much?
    http://www.flickr.com/photos/arenamontanus/1469686231/
  • 6. Top 10 reasons to avoid software security
    • Haven’t heard of it
    • Bigger (more fundamental) security fish to fry
    • Don’t know what apps we have
    • Don’t want to make other energy co’s look bad
    • Sympathy for hackers
    • No budget
    • No security staff
    • Might save money
    • We already have firewalls
    • Might be prepared for new security standards too soon
    http://www.flickr.com/photos/andryone/120278573/
  • 7. 2 reasons utilities need to embrace software security
    • Future NERC CIPS will begin folding in NISTIR 7628 (Guidelines for Smart Grid Cyber Security) & NIST 800-53 policy on security controls for Federal IT Systems Here’s what 7628, Section 7.3, wants you to check in your software:
      • Input and output validation
      • Authorization vulnerability
      • Password and password management
      • Error handling
      • Cyrpto
      • Logging and auditing
      • More …
    • Customer Portals are coming
      • Public web apps
      • Connected to many other utility systems
  • 8. Some widespread vulnerability types in software
    • Buffer overflows
    • Format string vulnerabilities
    • Race conditions
    • Resource leaks
    • Input/ Output validation and encoding errors
      • SQL injection
      • Cross-site scripting
      • Cross-site request forgery
      • OS injection
    • Error handling and logging vulnerabilities
      • Insecure error handling
      • Insecure or inadequate logging
      • Native code loading
      • Data storage vulnerability
    • Insecure Components
      • Malicious Code
      • Unsafe native methods
      • Unsupported methods
      • Custom Cookies/ hidden fields
    • Cryptography
    • Network communication
    • Application configuration
    • Access control
    • Database and file system use
    • Dynamic code
    • Access control and authentication errors
    Coding Mistakes Configuration, Policy and Design Flaws Smart Grid Software Security
  • 9.
    • Software you already made or bought
      • Identify it
      • Prioritize it
      • Probe it
      • Analyze it
      • Protect it
      • Fix it (if you can)
      • Rinse and repeat whenever it changes
    • Software you’re going to make (or have made for your org)
      • Spec it
      • Develop it securely and test it
      • Deploy it
      • Rinse and repeat whenever it changes
    Software security strategies depend on origin
    • COTS software you’re going to buy
      • What is and is not acceptable to you
      • What to ask vendor re: security during development and in ongoing releases
      • Can you protect it with systems already in place
    And wherever possible: Automate
  • 10. Best practices
    • (Breathe), crawl, walk, run
      • Plan
      • Policy
      • Prioritize
      • Perform
    • Other key concepts
      • Secure by Design, Build Security In
      • White Box and Black box testing
    Smart Grid Software Security http://www.flickr.com/photos/clearlyambiguous/
  • 11. Questions to ask about data and testing
    • What is the software's provenance?
    • Where did the software come from?
    • Who made it?
    • What was it made from?
    • Is it new software built for me?
    • Is it existing software that has run similar systems elsewhere?
    • Why ask the question?
    • Unless you know about the origins of software, it is very hard to put together a plan to ascertain its security
    • Knowing who built it provides a resource to ask about the way in which it was built
    • Knowing about its components provides information to use in testing it or researching testing done by others
    • What does the software do with data?
    • What kinds of data does the app gather?
    • Where does it come from, and how does it enter the system?
    • Once the data has entered the system, does it get stored, and is it stored with appropriate protection of privacy and integrity?
    • If the data ever moves between components of the system or between multiple systems, is it appropriately protected by the software for privacy and integrity?
    • Why ask the question?
    • Data is central to the smartness of the Smart Grid, and its protection is expected by subscribers, is in many cases mandated by regulation, and is certainly necessary to ensure reliable operation of the Smart Grid.
    • How has the software been tested?
    • What testing has been done, and on what components?
    • What approaches were used, and with what results?
    • Have all components been considered for security issues prior to their inclusion, and how were they vetted prior to selection?
    • Why ask the question?
    • Understanding the testing process for the software can uncover blind spots to some sets of security issues, and can also identify weaknesses in methodology that can indicate systemic problems from the provider
    • Testing has many facets, and security must be among them
    Questions to ask about provenance and governance
    • What is the plan for ongoing governance?
    • How will the software be updated?
    • Who will make those decisions?
    • What is the process to initiate or approve a change?
    • Why ask the question?
    • Instability = Insecurity
    • Haphazard or non-existent governance leads to more frequent changes, less testing time for the solution in place, and to inevitable discontinuities if the software is a component of a larger system.
    • Weak governance also increases the opportunity for malicious code
    A boatload of questions to get you in the mood
  • 12. Additional resources
    • NIST
      • NISTIR 7628 1.0
    • DHS
      • Software Assurance working group and “Build Security In”
    • MITRE CVE and CWE
      • Common Vulnerabilities and Exploits , and Common Weakness Enumeration
    • OWASP
      • Open Web Application Security Project
    • Cigital BSIMM
      • Building Security in Maturity Model
    • IBM X-Force
      • Worldwide cyber threat and risk analysis team
    Smart Grid Software Security
  • 13. What’s next in the SGSB series
    • October
      • Securing AMI Systems – looking at current and future security issues for Smart Meters and the old and new infrastructure that supports them
    • November
      • Smart Grid Security and Privacy from the Customers’ Point of View – putting ourselves in the customers’ shoes on these issues
    • December
      • Understanding and Empowering a Smart Grid CSO – these guys have a heck of a lot on their plates and we’re all counting on them doing well. Here’s how you can help.
    • Already covered:
      • Intro to SG Sec
      • SG Data Sec
      • SG IT Security
      • SG Sec Stds
      • SG Software Sec
  • 14. Watch out for @sgsblog Twitterstorms !!! http://www.flickr.com/photos/emzee/199257941/ r
  • 15. Thanks! Andy Bochman [email_address] The Smart Grid Security Blog smartgridsecurity.blogspot.com