The blog has been very quiet because we have been fully occupied with Digital Bond’s SCADA Security Scientific Symposium (S4). Liveblogging didn’t work well because I was communicating with the Virtual Attendees, handling Q&A, and sitting right next to the speaker. So here are my notes from the event.
S4 Attendees feel free to add your thoughts on any talk in the comments.
Keynote – Dr. Whitfield Diffie
We were very fortunate to get Whit Diffie as the S4 keynote, and even more fortunate to have him actively participate throughout day one.Whit Diffie gave a fascinating review of the history of US crypto. Lots of unique insight and knowledge. He spends a lot of time on this in travel, interviews and research. It is a source of oral history that you just can’t find in any book. For example, he told a story about the life of Horst Feistel, the main designer of DES. How his crypto career was delayed because he was German and not trusted to be designing US crypto during WWII.
“Cost of evaluation” is the biggest cost of cryptosystems. SCADA relevance is right now this burden of security evaluation falls on the asset owner.Whit talked about how the inspiration for his invention of public key was from work on two very different security systems: unix password tables and IFF.
He closes with comparing some important factors between Strategic Air Command (SAC) Command and Control to a critical infrastructure SCADA system
- In both cases it is important to know your enemy, but do they know their enemies?
SAC knows. SCADA? really we don’t know.
- the volume of products sold is small in both cases
I have noted how difficult it is to make money on a SCADA security product because of the small market size compared to ecommerce, wireless comms, etc.
- diversity of authority
SAC has a centralized authority; much of the authority over the critical infrastructure is spread across numerous countries.
As an outsider without the SCADA package, Whit had a number of unique perspectives and analogies throughout the day. Not all were apt, but many were and caused the mind to examine a new line of thought. I’m convinced that we need more smart outsiders to jog the discussions from time to time.
Session 1 – ICCP Exposed: Assessing the Attack Surface of the “Utility Stack” by Matt Franz, Digital Bond (alumni)
Matt was kind enough to come down and present a paper he wrote while at Digital Bond. It was great to see him again, but it reminded me of what a loss it was to Digital Bond and the SCADA security community when he left to join Hewitt.
He went over the Utility Stack with emphasis on the TPKT (RFC 1006) and COTP. He showed the numerous packet captures and decodes and went over the types of attacks that caused the vulnerabilities that have been disclosed on ICCP servers. Vulnerability Note 1, Vulnerability Note 2 , Vulnerability Note 3
A brief review of the tool that we hope to make available to vetted asset owners was discussed.
The discussion kept trying to move to responsible vulnerability disclosure, but this was a technical, not political, event so we tried to steer away from this. Of course it was a major issue in the hallways, and probably is an area that the PCSF, KEMA, SANS, ISA type of events should continue to explore – – especially if they want some active discussions.
Foreshadowing – the research in OPC talks in day 2 resulted in more than 20 disclosures to CERT/CC and US-CERT who are now working through their processes. Don’t ask them about it, they will not give you any info.
Session 2 – Anonymous, Authenticated Communication for Secure Sharing of SCADA Control System Information, Tim Draelos, Sandia National Labs
There is an argument that asset owners would be more willing to disclose if the risk of the disclosure coming back to harm their reputation, stock price, regulatory compliance, or security exposure could be eliminated. So Sandia with a little help from Mitre tried to address this as part of an I3P project. There are a lot of details in the 31 page paper, but what I liked most is they presented on three different components of this.
1. Anonymizing the contributor of information. If an asset owner has some information, how do they put it in a centralized sharing storage without having anyone know it was placed by them? How do you restrict who can do this without providing traceability? How do you let people take back or revoke the information? The paper presented protocols to do this.
2. Anonymizing content. This is the issue I’ve been interested in. How do you strip identifying information in an automated fashion and still leave something worth sharing.
3. Anonymizing route. The concept of onion routers and other techniques were presented to prevent someone from tracking back to the originator.
Lunch
An unusually warm day for Florida in January. Sunny and in the mid-80’s. Lunch is outside on the Terrace overlooking the Intercoastal Waterway.
Session 3 – A Methodology for Estimating the Mean Time-to-Compromise of a System, Eric Byres, Byres Security
The challenge is coming up with the alpha value in the formula, but this provides a mechanism to put expert consensus opinion, honeynet results or actual production data into the equation.
The comparison to Physical Safe Cracking ratings is interesting and apt.
I have to give Eric credit. His presentation style and content encouraged the S4 physical and virtual attendees to get involved. Lots of questions, comments and challenges like we wanted for the S4 culture. After this presentation the attendees seemed to embrace the culture, and we saw very active participation from most of the attendees.
Session 4 – Using Model-based Intrusion Detection for SCADA networks, Al Valdes, SRI
The IDS work at SRI on the Emerald platform includes pattern anomaly detection, Bayes analysis of TCP headers, stateful protocol inspection and some Snort thrown in where useful. Some of this could be accomplished with signatures, but a few things to highlight.
1) The idea that traffic flows between IP addresses and on TCP/UDP ports is relative static in control system makes it ideal for modeling. This is done in Emerald and you will also see this in the passive vulnerability scanner product category.
2) The protocol inspection is highly useful because we are seeing implementation errors in most systems that receive serious scrutiny (admittedly still a small sample size for the community). Preventing malformed packets from reaching a SCADA device or application is of increased importance.
3) Everyone, including Digital Bond, starts with Modbus. It is a simple protocol at the application layer. This was true for many of the S4 presentations, and it has me thinking.
Session 5 – Crypto Algorithm Performance on Common Field Processors, Robert Lambert, Certicom
A few points came through loud and clear, to me at least.
1) The community is not looking at the right crypto primitives and protocols. We are using old and significantly less efficient algorithms. The simplest example is if you see RSA instead of ECC in the protocol there is a big problem. Some very fast authentication protocols based on symmetric algorithms also need to be in the mix.
2) Crypto protocols are running on very low power devices. A lot can be done with minimal processors and overhead.
3) The SCADA security community has a glaring lack of cryptographers. Would we let cryptographers deploy an oil pipeline SCADA? Why do we think we can do crypto? As an NSA-trained ex-cryptographer, I realize I’m not qualified to do this work because I don’t live and breath in that world anymore. How can we expect those with little or no training to develop these protocols. This may become a soap box issue for me.
The challenge is how do we engage the cryptographers in the SCADA security standards effort.
Session 6 – SCADA Protocol Obfuscation: A Proactive Defense in SCADA Systems, Julian Rrushi, University of Milan
Imagine you are a grad student presenting a new crypto algorithm and you see Whit Diffie in the front row. That is a trial by fire.
This paper had two ideas. The attendees really chewed on one. Does it make sense to have a low-security, low-performance requirement, “scrambler” algorithm for communications to controllers (PLC, RTU, etc.)? Think of the analogy of a policy radio or other voice scrambler that won’t stop a sophisticated attacker but would prevent someone from simply eavestropping.
The scrambler would prevent someone with a Modbus client and access from successfully issuing requests. Perhaps the attacker simply moves on to something easier. Maybe the delay and error messages caused by the attacker would be enough to limit or stop damage. A number of questions and suggestions on the proposed algorithm were provided, but the topic of the scrambler was very thought provoking.
The second idea was the attack requirements trees that some thought were interesting, but did get lost in the enthusiastic discussion on the scrambler.
Cocktail Party
The weather cooperated, and we were able to enjoy a nice night out on the terrace.