Upload
andy-bochman
View
2.594
Download
1
Tags:
Embed Size (px)
DESCRIPTION
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.
Citation preview
September 2010
Smart Grid Software
(Softgrid) Security
Andy BochmanEditor : The Smart Grid Security Blog (SGSB)
Webcast Series Volume 5
2A. Bochman 2010
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
3A. Bochman 2010
All Smart Grid software could fit in this
http://www.flickr.com/photos/gem66/52306307/
4A. Bochman 2010
But it is more than many of these
http://www.flickr.com/photos/faisalsaeed/212339449/
5A. Bochman 2010
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/
6A. Bochman 2010
Top 10 reasons to avoid software security
1. Haven’t heard of it
2. Bigger (more fundamental) security fish
to fry
3. Don’t know what apps we have
4. Don’t want to make other energy co’s
look bad
5. Sympathy for hackers
6. No budget
7. No security staff
8. Might save money
9. We already have firewalls
10. Might be prepared for new security
standards too soon
http://www.flickr.com/photos/andryone/120278573/
7A. Bochman 2010
2 reasons utilities need to embrace software security
1) 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 …
2) Customer Portals are coming
– Public web apps
– Connected to many other utility systems
8A. Bochman 2010
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 MistakesCoding Mistakes Configuration, Policy and Design FlawsConfiguration, Policy and Design Flaws
Smart Grid Software Security
9A. Bochman 2010
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
10A. Bochman 2010
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/
11A. Bochman 2010
Questions to ask about data and testingWhat 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 governanceWhat 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 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
12A. Bochman 2010
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
13A. Bochman 2010
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
14A. Bochman 2010
Watch out for @sgsblog Twitterstorms !!!
http://www.flickr.com/photos/emzee/199257941/r