INL Presentation at OSIsoft’s DevCon 2008
I attended OSIsoft’s DevCon 2008 this week. While parts of the conference seemed to be more marketing than technology, there was some good information that I will be able to use for the Portaledge project. The most interesting talk was from Shane Hansen and Ken Rohde of Idaho National Laboratory (INL).
The presentation started with a review of the x86 architecture and networking. After the review, the presenters introduced the Man-in-the-Middle (MITM) attack. The presenters focused the majority of their talk on MITM. They showed ettercap performing arp cache poisoning and ettercap altering packets on the fly.
After speaking with people who have been in the control systems field longer than I, it appears the control systems security group at INL loves to show off MITM attacks. While the Man-in-the-Middle is an interesting and valid attack vector, once an attacker has situated himself in a network where he is able to perform a MITM attack, there are typically more useful and dangerous attacks that can be launched.
Eventually the presenters discussed their methodology with respect to protocol analysis and protocol fuzzing. There was even a demo showing a poorly written application crashing due to fuzzing. I felt it was, by far, the most interesting part of the discussion.
At the end of the talk, the presenters challenged the audience to build applications using secure coding techniques and better software designs. My challenge to the control systems security group at INL is to show attack vectors other than their MITM crutch. INL boasts their partnerships with numerous control system vendors; I hope they are giving the vendors more than a demo of what can be done with ettercap.
Author: Charles Perine
Posted: March 21st, 2008 under Conferences, Dept. of Energy, US Government.
Comments: 5
Comments
Comment from Matthew Franz
Time: March 21, 2008, 9:28 am
Wow, INL is still talking about MITM with Ettercap, isn’t that like so 2002? But I guess given the lag (and experience gap) between the “SCADA Security Experts” and the broader/deeper security community this should not be a shock.
Comment from Bryan Owen
Time: March 22, 2008, 6:24 pm
Thanks for the ack and constructive challenges; this was my first go at providing developer targeted security content in a forum for OSIsoft and value add partners.
I am also very appreciative of INL collaboration with industry. Given that historian and reporting systems are a likely vector to SCADA; it seemed appropriate to have government authority present on this topic. Our primary objective was to generate broad interest in secure coding.
This is a difficult task. As you suggest audience reaction was easily accepting of the MITM attack. However, it does reinforce advice for developers to know what their application does on the wire.
There is always more to do in security and it’s difficult to quantify success; but I hope there are more DevCon+DefCon initiatives. There is an interesting blog from MS on this very topic:
http://blogs.msdn.com/sdl/archive/2008/01/29/sexy-development-lifecycle.aspx
Comment from Ralph Langner
Time: March 24, 2008, 2:19 pm
Matt, that was almost my exact thinking — except that I was first wondering if the conference date was mistaken as 2008 for 1998.
I hope that the INL folks at least presented attack scenarios which would give such a MITM attack any level of likelihood, including an explanation why an attacker with access to the network and ability to launch rogue applications would mess with Ettercap instead of manipulating the process straight. I also hope they pointed out how easy the ARP poisoning of a MITM done this way is detected by an IDS.
Comment from Charles Perine
Time: March 25, 2008, 11:10 am
Bryan,
I did not attend any of the labs which were probably more technical than the talks. I feel that a developers conference is absolutely the correct place to have presentations on security. Providing developers information about security and their code is easily as important as the security conferences. A secure coding lab or secure software life cycle lab may be a good idea next year.
I was disappointed that most of the content INL release is the same content they have been releasing for many years. I would have liked INL to expand more on the protocol analysis or other techniques they use. The biggest problem I have with INL rehashing the same information on MITM is that MITM is relatively easy to protect against. The protection against MITM is typically encryption of the network traffic but encryption does not fix all of the other potential problems with software. I will be blogging about encryption and it’s role in security in the next week or so. Encryption is not security, just an aspect of security that protects data.
I hope somebody from INL goes through the review and approval process (if needed) and will respond to this post.
Ralph,
I don’t remember INL making any statements regarding how easily the arp cache poisoning can be detected by IDS.
Comment from Bryan Owen
Time: March 27, 2008, 12:59 pm
The message about knowing what can and can’t be trusted in a distributed application is important.
Perhaps manipulation of bytes on the wire is too simple or there might be a more interesting way to make the point.
This year’s learning lab workstations included secure coding; I will consider highlighting this kind of material in a group workshop format.
I clearly missed the mark if developers left with the idea that security is an add-on.
Write a comment