- More control system info at mainstream security / hacking events. The latest is Mark Bristow of SRA International’s presentation “ModScan: A SCADA MODBUS Network Scanner” scheduled for DEFCON 16. UPDATE: Fuzzing Proprietary SCADA Protocols by Sergey Bratus of Dartmouth will be part of the BlackHat 2008
- Good interdependency example in 16.05 Wired magazine water article. An Intel plant in Chandler, AZ is storing water excess water in an aquifer – – a lot of water – – 3 billion gallons to date. This water would be used in their fab plant in case the water from the Colorado river is restricted or unavailable. Good planning, but the same power hungry fab plant and much of the region gets its power from Palo Verde Nuclear plant who uses 20 billion gallons of water annually to cool its turbines.
- Matt Franz shows some worthy skepticism about Chinese hackers affecting the US power grid in a major way.
- More interesting China story is some attack code analysis by the Internet Storm Center: “In other words, the code checks if the system language variable is set to ZH-CN (which is set on systems running in Chinese) and redirects you to the site hosting exploit only if that is not true.” [hat tip: Pauldotcom Episode 108].
Archives for May 2008
After a few days of letting the Congressional Hearings on security of electric sector control systems sink in here are the three items I found most interesting and important.
1. The fact that NERC previously provided false information to Congress on Aurora mitigation efforts by the electric sector was a huge mistake, whether intentional or inadvertent. Aurora was obviously going to be the main topic of that previous subcommittee meeting so it seems unlikely that NERC could have been unprepared. This only leaves an intention to mislead or a significant blunder, and either the blunder or misleading data allowed Congress to rail against NERC and suggest a replacement organization may be warranted.
On a related note, we are hearing a lot of rumors and stories on the origin and processing of Aurora that are disturbing. It has proven difficult to verify without signing NDA’s, but we are close to completing our fact checking so stay tuned.
2. Many of the Congressmen and women were clearly fishing for FERC to ask for additional laws and authority to regulate cyber security in the electric sector. Rep. Sheila Jackson Lee was almost begging to be asked to write additional legislation.
FERC appears to have convinced that the committee they are doing all they can and most of the fault lies with either restrictions on their authority or NERC.
3. Many of the subcommittee members focused on the need to secure everything attached to the electric system.
This is a very bad idea and flies in the face of Security 101 or Risk Management 101. The approach in CIP-002 to identify Critical Cyber Assets and focus the security protections on these Critical Cyber Assets and other assets in the same security zone is excellent. There could be more description and guidance on the criteria. There could be more rigor in auditing this very important step in the CIP. There could even be more than two categories, Critical and Non-Critical, with an escalating set of security requirements.
The last thing we need the industry needs to do now is focus precious resources, primarily time and attention, on cyber assets that would have a minimal impact if successfully attacked.
As an IT example, you would prioritize your security efforts on the email server over any single email client. You would focus your security efforts on an e-commerce server rather than an individual browser. In the control system world, you would prioritize securing your control servers that monitor and control the entire SCADA or DCS over a securing a PLC with an Ethernet card that provides helpful but non-essential monitoring data.
scadapedia. This document outlines a 10 year process to create secure and resilient control systems in the waste and drinking water sectors.]]>
The compliance checks use the severity ratings in a different way than a typical Nessus plugin. The result of a compliance check is compliant, non-compliant, or inconclusive. Every check generates one of these results in a report and they get mapped to the traditional Nessus ratings as follows:
High = Non-compliant
Medium = Inconclusive
Low = Compliant
If you have a non-compliant result in an audit check report, there is no further built-in categorization of impact. This makes sense for most systems when it comes to compliance reporting. For example, you may simply be checking “Is this Windows XP machine compliant with the FDCC standard or not?” For Bandolier, however, we anticipate that asset owners looking at a report may appreciate some type of impact or severity rating so they can better understand the risk of a non-compliant check and make good decisions about remediation.
Because the compliance checks are different than traditional vulnerability scanning, a rating system such as the Common Vulnerability Scoring System is overkill. The severity ratings for Bandolier are much simpler. Details and examples are described in the Bandolier Severity Ratings SCADApedia article, but here’s an overview:
Severe – serious potential impact to the control system, could lead to system compromise
Moderate – potential security impact to the control system but not likely to result in system compromise
Informational – checks that provide system information such as role or version
Each check is associated with one of these ratings and will show up in the description field. This means the rating will be visible in both the audit file itself as well as the reports that Nessus generates. Also included in the description field is a link to more information about the check that will be hosted in the Digital Bond subscriber pages.
Our goal is to make the Bandolier compliance checks as useful and valuable to asset owners as possible. I think the internal severity rating adds to the checks on both of those counts.
ASLR has been an interesting topic in the security world since Vistas release, but there hasn’t been a lot of discussion of it in a SCADA context. For those of you who don’t know ASLR is a technology used by Windows Vista and Server 2008 that changes the memory address space that programs are loaded into each time the program is run and each time the system is rebooted.
As more development shops move to more current versions of Visual Studio and enable protection technologies like ASLR, stack cookies, Data Execution Prevention (DEP), the asset owners of critical systems are going to have to become familair with them. While these technologies decrease the likelihood of arbitrary code being executed, it also increases the chances of Denial of Service conditions that may be less desirable. While neither option is very palatable, given the choice of having unknown code running on a system or having access to it there are a nontrivial number of owners and operaters who would choose the latter in hopes of avoiding downtime and trying to mitigate the compromise in other ways.
In the mean time, several tools have been released to analyze binaries and report if the ASLR bit, and other things are enabled. I’ve personally used LookingGlass from the folks over at Errata a fair amount and its very interesting to see what vendors are using ASLR, possibly without thought, and which ones aren’t.
I’ve written up a brief SCADApedia page with more technical information about ASLR for those interested.
- Mu Security, the vendor who makes the MU-4000 protocol stack tester and fuzzer that includes control system protocols as well as offers the MUSIC certification, has changed their name to Mu Dynamics. Probably more importantly they have raised $10M in a 3rd round of venture funding. Raising money in this economy is no small feat.
- Walt Boyes from Control was an early proponent of ISA’s efforts to certify security compliance with ISA and other standards. In a recent editorial [link fixed], he explains how he no longer supports the ASCI because of the high cost, pay to play, to participate in the effort.
A GAO report on TVA’s control system security is out. This report along with the Congressional hearings are going to be hot topics over the next days and weeks.
Unfortunately we will not have much to say on this because we have a fair amount of inside knowledge covered under NDA. TVA is a partner in Digital Bond’s Dept of Energy funded Bandolier and Portaledge projects. Even if we were able to write on this, most of the real interesting and important facets of this story are political issues rather than technical issues.
The House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology is in a hearing now to get testimony from NERC and FERC on the Aurora remediation actions and the NERC CIP regulations [which we will comment on], followed by GAO and TVA regarding the GAO report.
The Subcommittee chair has already laid down the gauntlet that NERC had better improve or it will need to be replaced and he has ‘little confidence’ in the industry to address security. FERC seems to have placated the chair.
Previously you had to allow root login via SSH to get the most out of the Nessus compliance checks and other credentialed scanning functions on *nix hosts. This goes against the typical security recommendation of setting PermitRootLogin to no in your sshd_config. Even though recent versions of Nessus had some support for sudo, it was fairly limited. That has changed since Tenable announced late last week that the Nessus credentialed scans now offer full support for both su and sudo. This is great news for Nessus users and the Bandolier project.
Joining me in the May Edition of This Month In Control System Security
This month’s topics are:
- The Wonderware Suitelink vulnerability discovered by Core Security in May included a blow by blow description of the researcher / vendor communication. What went right? What went wrong? and what can we learn from it?
- What is the market for field security appliances and what will these products look like in three years? See Dale’s business case post referenced in podcast.
- Is “Secure By Default” appropriate for control systems?
We have made it easier for you to get Digital Bond’s podcasts.
Or you can subscribe to the Podcast RSS Feed.
We have been relatively silent on the SCADApedia, but it continues to grow and is where we are putting a lot of the information gathered during our research projects. There are now over 65 technical entries, and I will try to get back in the habit of listing the new entries the first of every month.
For those new to the site, our blog is the where we share opinions and news along with small factoids. The SCADApedia is a wiki where we put factual reference material such as control system protocol and security protocol descriptions, vulnerability notes, product references, research projects from Digital Bond and others, and much more. Often we will blog on an issue and write up a more detailed SCADApedia entry.
All can read the SCADApedia, and site subscribers can edit and write entries. We even encourage vendors to place factual security information about their products on the SCADApedia. We will ride herd on the entries to make sure they stick to the facts rather than marketing fluff.