Sean McBride’s Finding SCADA Honeypots on Shodan article is a twist on the Internet connected ICS story. He finds 58 Conpots and 67 honeypots listed as Water Control Valve #27. Two points in this article. One, some basic analysis is required to weed out honeypots. And two, you need to add more reality and interaction to your SCADA Honeypot if you want it to be believable.
Wonderware released a new version of their SmartGlance mobile app. We regularly beat up these ICS mobile apps for promoting remote control from any untrusted phone anywhere in the world. It was refreshing to read the Wonderware press release that focused on making plant information available anywhere, not control.
The Nuclear Energy Institute (NEI) is petitioning the US Nuclear Regulatory Commission (NRC) for a rule change “to ensure the regulation is not overly burdensome for NRC licensees, and adequately protects the public health and safety and common defense and security”. It reduce the types and number of devices, applications and subsystems that are subject to cybersecurity regulation. Joe Weiss stirred things up with his “The Arrogance of the US Nuclear Power Industry” article.
Admiral Rogers, Director of the NSA, testified in Congress yesterday. He stated that China and one or two other countries have the capability to attack ICS and affect the US electric grid and other critical infrastructure. This quote was thought provoking, “We need to define what would be offensive, what would be an act of war,” he said. “Being totally on the defensive is a very losing strategy to me.” I need to hear that in context.
The second price tier of S4x15 tickets (51-100) will sell out before Thanksgiving. Get yours now, save $100 and reserve your spot.
Image by Carbon Arc
Stephen Hilt and a team of volunteers are working furiously on the ICS Village for S4x15. The ICS Village at S4x14 had a large amount of ICS devices, 6 different vendor PLC’s, HMI, industrial switches, historians, …, and we allowed attendees to play and attack them at will. Of course, every year near needs to get better.
One thing we learned from our past ICS Villages and the recent Defcon ICS Village is that a lot of people are at a loss of what to do in the Village. So the ICS Village at S4x15 will have a capture the flag (CTF) competition with a ICS flags in five different categories.
The CTF will be scored and prizes will be awarded to the top individuals or teams.
We will be releasing information on the ICS Village every two weeks that will help attendees gather their tools and plan their attacks. To begin, the diagram below shows a simplified network diagram of the ICS Village. Some specific product names will be added in future updates.
The flags and scoring will be on a Jeopardy style board with the following categories. Each category will have different levels of difficulty with corresponding point values.
- Reconnaissance. Example easy flag: identify a historian on the network. Example medium flag: pull tag names from a PLC.
- Exploitation. Example medium flag: use Modicon password recovery to recover a super secret password. Example hard flag: downgrade software on a PLC.
- Process. Example medium flag: modify an HMI display.
- Forensics. Example easy flag: review firewall logs for signs of ICS specific malware. Example hard flag: Identify hacker identity via evidence left in firmware.
- Protection. Example easy flag: write ICS signature for an earlier discovered flag.
If you would like to participate in the preparation or running of the ICS Village, or just have an idea for a flag, contact Stephen Hilt.
The CLUSIF (Club de la sécurité de l’information français) has issued “an overview of existing documents, standards, guidelines and best practices” (link is for the document in English). The 24-page document gives an overview of the most popular and useful documents, and some advice on determining which documents might be most helpful to the reader based on a variety of criteria.
Robert Lee and Thomas Rid’s paper OMG CYBER! Thirteen Reasons Why Hype Makes for Bad Policy is available for free download. I’d like to see a follow up paper OMG CYBER! Thirteen Thing Your Vendor and Government Are Not Telling You About Cyber Risk in Your ICS.
Waterfall Security, best known for their Unidirectional Security Gateways, has announced Application Data Control. While technical details are still limited, it appears to add deep packet inspection to their product line.
Perry Pederson of Langner Communications has written a 28-page RIPE Crosswalk document that compares and maps RIPE to NERC CIP, NEI, WIB, NIST CSF, …
We are well into the second tier pricing of S4x15 Week tickets (51-100). The price goes up $100 each tier so register early to save money. We were happy to add to Tim Yardley as a speaker this week as well as some additional OTDay sessions.
We added a bunch of info to the S4x15 site including the newly designed banner, see below. We are almost through the first 50 tier ticket pricing (42 sold).
“DHS ICS-CERT” and FBI announced, a bit clumsily, that they will be touring 13 cities across the US and providing ”a series of SECRET briefings …for cleared asset owners/operators. … These briefings will provide additional context and information about the BlackEnergy campaign as well as the Havex malware that both targeted industrial control systems.” Sounds like a worthwhile program if they have unique information. I always wonder why these briefings happen after, rather than before, the information is released publicly by researchers and vendors. This is related to an ICS-CERT Alert issued this week.
Some good news on the INL front, they recently added Andy Bochman to the team. I’ve always admired Andy’s writing on Smart Grid security and other ICSsec matters when at IBM and in his own startup. Good luck Andy.
Fireeye released a whitepaper on a Russian organization they are calling APT28. It does not appear to have any critical infrastructure ICS aspects, although some of the government systems being attacked or having intelligence gathered could be ICS.
The team at Netrecsec wrote a nice blog summarizing the three vendors who were distributing Havex infected software.
This post was inspired by two tweets from Reid.
First, DHS needs to stop putting everything they do under the ICS-CERT umbrella. There is a CERT function, and there is a bunch of other non-CERT activity. The naming confuses everyone, and you would almost think that is intentional.
Next, as Reid suggested they should be very clear about their vulnerability handling processes. Right now it is coordination of what researchers submit and the vendor response. There is no analysis, no evaluation of impact, no validation of the vulnerabilities, and no validation of the fix. If the vendor says it is fixed, the alert or advisory says it is fixed. The vendor is not even asked how they fixed the vuln. The process, the best that we can tell, is simply coordination of messaging from other peoples info. Figure out what boilerplate fits best, pull some info from the vendor announcements, and put out an Alert or Advisory.
You probably surmise from my tone that I think this is inadequate and actually of little use. It is particularly harmful when they measure success based on the number of alerts and advisories issued. My recommendation would be to shut ICS-CERT down and just roll it into US-CERT. The whole purpose of ICS-CERT at its creation was to provide second level support for US-CERT when ICS vulns were found. We did not need to replicate the existing coordination function.
However, I realize some see value from the Alerts and Advisories, so I would count it a success if ICS-CERT was simply forthright about how they handle ICS vulnerabilities and generate Alerts and Advisories. Reid is right that the public has assumptions about what they are doing that are totally wrong.
I’ve been sitting back and watching to see what activity Reid’s S4xJapan talk would generate. When he found the vulnerabilities in Version 2 of CoDeSys it generated some Advisories that eventually stated the problem was fixed in Version 3 based on the vendor provided information. As we now know Version 3 has the same vulnerabilities as Version 2.
Yet two weeks later there has been no correction or updated Advisory. This is an issue that affects PLC’s and RTU’s from over 100 different vendors, and many of these vendors and their customers believe all is well since they are running on Version 3 of CoDeSys.
Reid showed the exploits on two Japanese products, one from Hitachi and the other from Sanyo-Denki. The later is used to control robot arms. There have been no Alerts or Advisories for these specific examples or the 100′s of affected products.
To be clear, I’m not saying ICS-CERT should jump every time a researcher demonstrates a vulnerability. The whole vulnerability in ICS is overplayed given that ICS-CERT does not consider insecure by design as a vulnerability.
They should have a clear and public set of procedures for vulnerability handling so the community can understand what they can expect and how they should interpret the Alerts and Advisories.
One of the most thought provoking sessions at S4xJapan was Wataru Machii of the Nagoya Institute of Technology’s session on Dynamic Zoning in an ICS. One of the great things about S4xJapan is it provides videos and sessions in the Japanese language. The downside is it is not accessible if you don’t speak or read Japanese.
The basic concept is that the security zones and conduits in an ICS should change dynamically based on the state of the ICS. There are two parts to this. The first is how to set up the zone and conduit states that you will switch between based on ICS state. And second, what triggers the change in state. Machii san had good ideas on both of these questions, but it is an area worth further investigation to identify a methodology that can be applied across sectors and customized by owner/operators.
This session was the inspiration for our S4x15 Great Debate: Can Operators Use a Security Display. The control room is often staffed 24×7 by Operators, but they have little security knowledge. The S4xJapan session made me consider if the Security Display could be simple enough that an Operator could trigger a change in the dynamic zone based on the information in a security display.
This is only one possibility.
In the Great Debate we will have attendees submit their single screen security display, and importantly, explain the defined Operator actions based on information shown in the security display. A handful of attendees will explain their security displays, others will be flashed on the screen for consideration, and their will be skeptics voices heard I’m certain.
By the way, this was one of two sessions at S4xJapan from the Nagoya Institute of Technology. They have an active ICS security program there and seem to be working on research with real world implications.
At S4xJapan in Tokyo I presented on a couple things, this post is about Havex. During the talk I am speaking slowly and plainly as the conference was being simultaneously translated into Japanese. Altering your speaking style to help translators is a good exercise that everyone should do. It forces you to be concise and use simple language but warning: it’s a bit dry.
There has already been some excellent articles/research published on the ICS relevant aspects to Havex. Regarded as the second major ICS malware, Havex garnered some media attention which prompted the need for more analysis, writeups, and talks like this. The goal of the talk is to give an overview of what Havex is, what ICS components it has, and then to dive in to the codeflow of the downloadable OPC scanning module. At the end of the talk hopefully the What and How questions are answered but Who and Why still remain.
After the presentation we had some good discussion about OPC module internals/encryption as well as general ICS malware campaigns. The conference did well to foster that type of communication and I appreciated working with everyone there.
I received my samples from insecure Command & Control servers as well as from professional contacts. Shoutouts to Kyle Wilhoit, Daavid, other Kyle, Kaspersky, and Daniel.
Google is maybe a little TOO helpful in trying to save us from ourselves. In attempting to forward on samples I discovered that Google seems to try basic password attempts on encrypted zip files. Putting the samples in a zip archive with the standard password “infected” was insufficient to get past Google virus detection but changing to “infected1234″ worked fine (without changing any file names). Creepy….
We have opened the S4x15 website and registration. There still is a lot to add to the site, like the Conference Hotel, ICS Village CTF, Social Events, Area Info, FAQ, … But we have always believed it is important to provide attendees with information on the sessions and speakers so you can make an informed decision.
The agenda looks great and very different than anything you have seen before at an ICSsec event.
Register right away if you want to get one of the first 50 tickets at the same price we have charged every year since 2007. We will be providing event updates on this site. There is a lot to say about the event, but we wanted to get this open for registration.
Registration for S4x15 was scheduled to open today at noon. We have a one day delay, and registration will open tomorrow, Friday, at noon EDT.
Sorry for the one day delay, but we wanted to get all of the accepted sessions into the site so you know what you will be registering for.
Reid Wightman of Digital Bond Labs presented Vulnerability Inheritance in ICS at S4xJapan, and he posted the video and a technical article yesterday. I’d like to weigh in on the duplicity of 3S, the ineffectiveness of ICS-CERT, and the challenge passed and failed by integrators.
What Reid showed clearly in his presentation, and in the tools he released, is that the six categories of Version 2 vulnerabilities had not been fixed in Version 3. All that CoDeSys did was modify the software slightly so the previous tools did not work.
Here is a simple analogy. Imagine Version 2 was a door that had no lock. All a burglar had to do was turn the doorknob clockwise and the door opened. Rather than putting a lock on the door in Version 3, CoDeSys simply made it so the door would not open if you turned the doorknob clockwise. But if you turned the doorknob counterclockwise, the door opens. What was needed was security, a lock on the door, rather than some trick.
I don’t know what else to say about 3S/CoDeSys except they have done their vendor customers and the end users a major disservice by saying Version 3 fixes the security problems. At least Festo was honest when they said they were not going to fix the vulns.
ICS-CERT is a vendor megaphone, little more. I know they should expect a forthright answer from the vendor, but is it too much for them to ask a couple of questions on how the vulnerabilities were fixed? These are vulnerabilities that affect 100′s of vendor products.
DHS touts the number of vulnerabilities they have handled as a measure of their value and effectiveness. They add little or no useful information to other disclosures, and they don’t perform even basic evaluation of the information.
It is hard to see any benefit to the DHS/ICS-CERT role in disclosure. Close down shop and move the resources to something more useful. My recommendations for years now is for ICS-CERT to ignore 95% of the vulns and to a great job providing value information on the 5% they deem important.
Which leaves the vendors that integrated the CoDeSys software. We are aware of two vendors that looked at the 3S fixes in Version 3, realized they didn’t address the security problems, and built their own protection into the integrated product. A great example of internal Red Teams and SDL doing its job.
The examples of Hitachi and Sanyo-Denki that Reid used at S4xJapan are the case where the vendor did not adequately test third party software that is integrated into their product. Hopefully this will be a learning experience for the CoDeSys customer base.
All ICS vendors are going to have security issues. The important point in evaluating ICS vendor security is how they fix identified problems, and the root cause of the problem in the development lifecycle.
Image by Lyn Matthews