- ISA’s Automation Standards Compliance Institute (ASCI) shared some details on the ISA 100 Wireless Compliance Institute, a parallel organization to the Security Compliance Institute. The WCI is looking for a $10K contribution which is substantially less than the SCI’s $50K annual contribution. The WCI should be able to leverage SP100 to a greater degree than the SCI can directly leverage any standards effort (except for perhaps SP99 WG4 a few years from now)
- The NERC CIP standards are a step closer to having the force of law behind them. FERC has issued a 197-page Notice of Proposed Rulemaking (NOPR) stating they intend approve the standards and requests some modifications. People have 60 days to comment on this decision.
Archives for July 2007
This honeywall update includes our four latest IDS signatures which aid in detecting points list and function code scans on DNP3 and Modbus TCP. These signatures play an important role in identifying a reconnaissance scan on PLC’s, RTU’s, and IED’s in a control system environment. In regards to the honeywall, roo-1.2 has been released for a month or so, but testing (and the bug fix db) revealed some odd problems so we’ll wait until 1.3 or later for a full upgrade.
Don’t forget, Dale will be speaking about the results from our SCADA Honeynet deployments at Joe Weiss’ event in Knoxville on August 14th.
Some of the team members from the TCIP initiative were at the Dept of Energy Open Science meeting. This five year, $7.5M program is funded by the NSF with involvement of DHS and DoE. It has been up for almost two years now and has been relatively quiet in terms of publicity as compared to I3P.
So we took a look at it and started a SCADApedia page on TCIP. Most of the available output to date is a set of one-page “posters”, but there are some related papers on the site and the researchers from TCIP indicated there would be many more papers coming.
The project is on the broad topic of “cyber”, but security is mentioned prominently in the project area descriptions. I need to spend some time with these papers. Here are some projects that caught my eye:
- Attack Container – A lightweight anomaly detection capability distributed in IED’s.
- Attested Metering – A security architecture and simulation for AMR
- A series of papers on Gridstat – a middleware framework for real-time data exchange. There are a number of security and QoS programs under the Gridstat umbrella.
There were quite a few projects that seemed to be a waste of time, but that is to be expected in research especially with those new to this field. Also, that is only my opinion, sometimes you never know where a brilliant idea will come from.
My biggest criticism of this program, I3P and many others is any good work done rarely sees the light of day. Without this we are essentially paying money to educate grad students which is not a bad thing, but a lot more can be done with the 10’s of millions spent.
TCIP appears to be a bit better as at least technical papers are being made available. It would be even better if the code and tools were provided for the community.
After two days the group working on control system security identified two potential Priority Research Directions (PRD’s). These were written up in a one page quad chart, and now a smaller team is writing them up in the DoE format for funding consideration.
The organizers brought in a few speakers to get the group thinking; Steve Lipner, Microsoft’s Senior Director of Security Engineering Strategy and author of the Security Development Lifecycle, was one of the speakers. A lot of the information was from his books, but there were a couple of interesting nuggets.
- Microsoft uses a term called “Security Science” that describes their efforts to identify and remove new classes of vulnerabilities. Microsoft typically does not make this information public because some of their older architectures, such as Windows 2000, are often vulnerable to these new attack classes. They monitor the vulnerability research and hacking communities to see if these are found by others. Steve said some have, but many have not.
- Microsoft added fuzzing to their testing in the 2004/2005 time frame.
Microsoft is almost universally scorned in the security community, and the knee-jerk reaction to the mention of Microsoft in the control system community is almost always negative. However my feeling is that most control system applications and devices would be found to be far worse than Microsoft if even a fraction of the effort spent on exploiting Microsoft OS and applications was applied.
Why? Look at Microsoft’s Security Development Lifecycle and compare this to the integration of security into the development lifecycle of control system vendors. It took Microsoft getting bloodied in the late 90’s and early this decade to get serious. That has not happened yet in the control system community and many are naively thinking the bugs leading to vulnerabilities are not there.
The summer 2007 edition of InfraGard’s Gardian publication has an article we wrote on SCADA Honeynets. The article provides a brief overview of the topic and some of the results from the SCADA Honeynets, which appears to the attacker to be a PLC, we have deployed in substations and on the Internet
Today and tomorrow I’m participating with about 150 others in the Dept. of Energy’s Cyber Security Research Needs for Open Science Workshop, and a significant portion of this is related to control system research needs. The workshop is sponsored by Office of Science (Advanced Scientific Computing Research) and Office of Electricity Delivery & Energy Reliability.
The goal of the workshop is to develop Priority Research Directions (PRD’s) for the Dept. of Energy that identify research needs for opportunities in cyber security for open science, and follows a similar workshop that was held in January with a smaller, more DoE group.
There are a few things that are unique here:
- PRD’s are aimed at research that will produce results in 3 to 10 years (and some have said 5 to 10 years). They are not looking for research PRD’s that will provide near-term, operational results. These have already been funded by other programs. This will be an interesting challenge for me, because Digital Bond’s focus and raison d’etre for research programs is to make an significant near term impact. It is always a good idea to break up typical thought patterns, so I’m looking forward to these break out discussions.
- The PRD’s must be focused on “Open Science” which I’m not sure exactly what this means. One quote was “Open Science means that potentially everyone can participate”. It is significantly different than the 0 – 3 year research where commercialization plans are a major driver.
After the introductions that start the day, participants will breakout in four sessions:
- Securing Hardware, Software and Data
- Monitoring and Detection
- Future Security Technologies and Information Assurance Technologies
- Human Factors Analysis
- Protecting our Utility Architecture
Summer is slowing down but there are two items from the CSSP for this Friday’s News and Notes.
- A recommended practice is now available for Securing ZigBee. It was written by Lawrence Livermore for DHS.
- A large (139 page) Catalog of Control System Security Requirements was developed by the National Labs for DHS. This document is a compilation of a large number of security guideline and standards documents.
I have some pro’s and con’s on the Catalog that I’ll blog on next week
Update: The USA Today has a front page article, “Cities work to fix signs of aging: NYC blast highlights infrastructure woes”. It mentions the city of Atlanta is spending $3.9B to update their water and wastewater infrastructure. Is even .01% of this going to spent on cyber security? There are different types of money in a budget, politics, and other issues to getting projects funded, but it shows money can be found if we do a better job of making the business case. The best time to do this is when savings and increased capabilities of automation are in the picture. Once the network and applications are deployed it is harder to get security funded after the fact.
I must admit to being pleasantly surprised by the poll results. My expectation was a 50 / 50 split between vendor only and vendor + US-CERT responses. We will leave the poll open, but at this time 87% of respondents chose disclosure to the vendor + US-CERT. Based on this sample the preferred response for consultants, researchers, asset owners and vendors is clear – – disclose vulnerabilities to the vendor and US-CERT.
This differs substantially from the impression at the 2006 PCSF annual meeting in San Diego where the vocal majority was very much against disclosing to US-CERT. That meeting was heavily attended and led by vendors, and I always wondered if the asset owners just didn’t want to get into the high-spirited discussions between Matt and some of the vendors. Perhaps asset owners don’t believe all faith and discretion should be left to the vendor regarding a vulnerability.
Another possibility is the community has more faith in US-CERT after seeing them in action with the first few disclosures.
Admittedly this sample size is small and represents a cross-section of the regular blog readers. These are likely people very active in control system security and perhaps people that react favorably to our approach towards disclosure and sharing tools and technical details with the control system community.
The latest Friday News and Notes entry has an interesting comment thread going on the value of government regulation of SCADA security with myself, Jake, Ron, Ralph and Bryan weighing in.
Some think it is the only way to get action from the majority of asset owners. Others feel it results in a bureaucratic mess that costs a lot and doesn’t address the real problem. And other opinions in the middle and other sides. The authors explain their cases best in the comments.
We didn’t want our regular readers to miss it so check it out.
Now that we have this polling figured out there is a question we have been interested in asking for a long time on the controversial issue of vulnerability disclosure in control systems.
Digital Bond’s published responsible disclosure policy is to disclose to the vendor and US-CERT and let them determine what further disclosure is warranted unless a NDA or contractual agreement limits disclosure. However we know there are many divergent opinions on this in the control system community.
While the fourth answer of disclosing to the highest ‘responsible’ bidder may seem flippant, it is a real and growing option as IPS vendors are paying for new vulnerabilities. There even is a web site now that has an auction for new vulnerabilities.