Irresponsible? Wrong Question – What is 3com/Tipping Point’s Motivation?
Is a presentation on fuzzing SCADA protocols and vulnerabilities like Ganesh Devarajan of 3com/Tipping Point is making at a variety of events widely aimed and attended by hackers of all hat colors irresponsible? We get asked the same question for much more mundane activities including something as “innocent” as disclosing vulnerabilities to US-CERT or items in our blog or publishing the S4 papers.
While this is an interesting question, and probably triggers the always popular vulnerability disclosure discussion, there is a more interesting question. What is the vendor’s motivation, in this case 3com/Tipping Point, in allowing or even encouraging this presentation at LayerOne, Defcon, and the Black and White Ball?
Companies and individuals almost always do these things for some self-interest so the choice of event and presentation details, approach and language tells us something.
If Tipping Point’s motivation in performing and presenting SCADA security research and tools was to build a reputation and sell products and services to asset owners wouldn’t this presentation be made at a control system security event such as PCSF, Weiss’s event, ISA, UTC, SANS SCADA Summit, … or of course the premier event – S4. There is no shortage of venues. This is where the community could benefit from this information and tool, and more importantly where the potential asset owners that care about SCADA security congregate.
In fact, presenting at Defcon and similar events is likely to turn off the control system community. If you watch the Ganesh’s presentation from the LayerOne event (link, description and analysis below), it would clearly deter almost all asset owners I know from working with Tipping Point.
The motive for Tipping Point is more likely to be viewed as an edgy, vulnerability research leader by the larger IT security community. Which is also a much larger market. There Zero Day Initiative where they pay for vulnerabilities is an example of this as well. It may help Tipping Point recruit talent and win them customers from IT Staff that are comfortable with and admire, to some extent, the gray and black hat community. This is only my best guess.
I’ve asked a couple of friends at Tipping Point this question and will include a response if received and permitted to share.
——————– Start Detour ———————-
One could reasonably ask what Digital Bond’s motivation in our presentations, tools, and other public efforts since we have self interest as much as anyone else.
1. We are trying to make our website an important information portal for control system asset owners, vendors and others in the community. This helps achieve marketing goals for our research and consulting and potentially creates a valuable asset for anyone trying to reach this niche market. We currently have over 7000 unique visitors per month and 100’s of paid subscribers and steady progress on this.
2. We are trying to be viewed as a thought and research leader in the control system community so we can pick and choose amongst the most interesting research projects.
So hopefully our presentations, tools, standards participation, blog and other marketing tools support those self interests and similarly we try to avoid actions that would hurt those purposes. We are very upfront with new consultants and researchers on what will be allowed and not allowed and try to find those that will appreciate and not chafe under this approach.
——————– End Detour ————————
The presentation Ganesh gave at the LayerOne event is available on YouTube.
Watching the first fifteen minutes of the presentation (the sound is out in the first 4:12) it is clear that Ganesh knows little about control systems, but this is not required to write a control system protocol fuzzer. He explains Modbus in some detail, DNP3 in less detail and glosses over ICCP. The fuzzer framework, which includes modules for Modbus TCP and DNP3 fuzzing, is being released in conjunction with a book on fuzzing by one of Ganesh’s colleagues.
At the end of the presentation Ganesh gives an example where he fuzzes the function code and boundary conditions of the subsequent four bytes and mentions a performance of about 10 tests per second. He runs it against a Modbus software implementation on another virtual machine on his PC and it causes a crash. The subsequent discussion is interesting because it is unclear if the team has tested it with any field devices or just Modbus software running on a PC.
My thoughts on the presentation:
- There is nothing new here in terms of information. The community know most control system protocols lack authentication and many protocol implementations can be easily crashed because of some combination of poor protocol stacks and resource limitations.
- The concept of identifying when field devices fail during testing appeared to be not understood and at least not discussed. This is old hat in the SCADA community as Eric Byres discussed the false negatives in testing and the importance of a watchdog concept at least three years ago and numerous times in increasing detail since then. Wurldtech has extended this quite a bit and I’m thinking of doing a podcast on this.
- The details on failures was far behind what is known and published in the control system community (my belief is this was due to lack of knowledge rather than reticence). There was an excellent paper on this at S4 that discussed specific failures that were common across multiple controllers.
- Let me close by trying to say something nice. The value of this presentation is probably the introduction of a new, free tool. I’ll have Landon review the tool sometime soon, but it looks like something that could be used for awareness if you are having difficulty convincing management of the risk. It also may spur the field firewall market a bit.
Author: Dale Peterson
Posted: July 8th, 2007 under Assessment Tools, Vulnerability Disclosure.
Comments: 5
Comments
Comment from Matthew Franz
Time: July 9, 2007, 12:30 am
I could be wrong, but I doubt there is a TPTI strategy with regard to SCADA. And if there were an unpolished and poorly delivered presentation like this would undermine such as strategy in addition to turning off asset owners as you mention. I believe it is more that researchers and TPTI are encouraged to find new/unexplored areas to do research which results in IPS filters for the product.
It will be interesting to see the reaction to these presentations from those (such as INL) who were so critical of Digital Bond for disclosing the ICCP vulnerabilities to US-CERT (the horror!) Will they voice the same indignation? Or perhaps they will keep mum because there is no competition for SCADA Security mindshare between Tippingpoint and DoE labs?
Comment from Jake Brodsky
Time: July 9, 2007, 7:13 am
Let’s get real here: in a true defense in depth system, you wouldn’t see protocols such as DNP or Modbus running around in the wild. They’d be confined to isolated LAN segments and forwarded via other protocols, and then those boxes would deliver their data to history servers using yet another protocol. Only the latter boxes would be exposed to the DMZ.
So where does Tipping Point’s exercise fit in to this? Well, it turns the heat up on the embedded system vendors. But even then, what have they achieved here? Nothing. Unless new embedded firmware comes out that forces me to go a re-validation effort, they’re just a bunch of foolish teen-agers pointing at someone’s dirty laundry.
The real costs aren’t even the distribution of firmware. It’s the VALIDATION effort after the firmware is installed.
THAT’s why I rant about the irresponsible behavior of such firms. It’s like throwing a wrench in to the works and then presenting your services to the victim companies as a professional mechanic. As long as I have something to say about it, they’re not going to get a dime of our money. And if this results in any new firmware releases we’d need to install, I’d be strongly tempted to sue these folks for the costs of an unscheduled re-validation of our I/O.
Comment from Ralph Langner
Time: July 9, 2007, 7:37 am
Give me a break, Matt — the strategy is simple and straightforward. Just convince the folks in IT department that they can use their favorite vendors and products throughout the corporation, and therefore on the plant floor, too.
The bigger the company, the more powerful the IT department. And most of the time, they’re the people in charge for IT security no matter where. They’re the buying center. An IT guy has no desire to understand the nitty gritty SCADA stuff. He wants a do-it-all solution from a vendor that he is used to buy from. Now if companies like Tipping Point, Checkpoint, Cisco and others, with their perceived authority and world-class know-how, are doing RESEARCH in an area like SCADA security, who would doubt that this will lead to breakthrough products? Ok, you would doubt, as many other researchers will. But IT decision makers won’t. So I’m afraid the “strategy” will work, and my bet is that other companies will join the bandwagon and come up with more “research” on Modbus.
The funny thing here is that companies such as Byres/MTL, innominate and ruggedCom, who are selling security products for the plant floor are actually not competing against one another. They are competing against the well establish vendors from office IT networking.
Comment from Ron Southworth
Time: July 9, 2007, 7:50 am
HI Guys,
I have resisted posting on this subject but Matt’s comments are designed to provoke a rational response and touched a nerve with me so here goes.
Vulnerability Disclosure and Mitigation of any aspect of a control system is something I think we need to discuss and debate for certain. This has been mentioned here on previous postings.
We need to be responsible for our actions and with the best of our intentions so that they are not used for something other than what was originally desired to achieve. The parable about the first person to split the atom springs to mind.
I know Matt that you see the traditional IT model as the method for disclosure for the control systems sphere but I think a lot of end users may just disagree with this view. I am keen to hear what the consensus of opinion amongst the community truly is. Life cycles are still far longer than IT systems are and I cannot see this changing too much in the future.
Defence in depth is more than just a phrase it is a philosophy for this community to be mindful of.
The what, where and when we discuss certain things can effect Critical Infrastructure. The fact that industrial control systems are receiving attention at the various colour hat conventions does raise the Newtonian type questions for most of us end users. It certainly is helping distil my view on the timing of the when question!
I must confess I feel some sense of sadness with your dig at a great bunch of hard working people that I consider do a great job like many in the industry and I would be genuinely interested to hear where and when anyone from INL was critical of you Matt or even you Dale for that matter. I do confess to having spent a bit of time with some of the INL guys & gals recently Both in the USA and most recently here in Australia. From my experience they show a deep respect for all of the active participants within the industry, yourselves included so I am a bit sad to hear you express your feeling regarding this subject. You may say that I am somewhat biased and perhaps I am and I don’t apologise for this either. I think I would also say I would equally defend you guys in a similar situation if that makes any sense.
My line of we’ve all got to eat applies, as always. I think we need to try to separate the commercial aspects from the good work that everybody contributes to so willingly. Sometimes this can be difficult. Perhaps you may have taken what was said out of context or were they merely voicing the concern of a number of end users?
An interesting subject Dale I hope we see some vigorous debate and that you will still talk to me in the morning!!!!
Comment from Julian L. Rrushi
Time: July 9, 2007, 1:49 pm
—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1
I usually try to identify the contribution of each research work presentation, and would be interested in Mr. Devarajan’s work. Of course, it would have been easier for me to understand the contribution of his work if he could have avoided investing a lot of time and dedication on stressing the fact that SCADA systems are so vulnerable… you don’t need authentication to send commands… you send commands and server devices just execute them… it’s so easy to attack!
In particular, it could have been interesting to the SCADA security community to know the logic behind test frame generation and vulnerability identification. In my opinion there is some very good work on these directions done by Franz and Zhivic, just to name a few people. Cisco CIAG has also done a great work, I believe, and several security testing tools have been devised and coded, such as for example the DEADBOLT vulnerability analysis framework by MIT, the INL control system plant assessment, or the Achilles SCADA Assurance Platform. Thus, it could be interesting to know in what feature, algorithm, or novelty in general Mr. Devarajan’s work is more advanced than the state of the art knowledge.
Thank you,
Julian L. Rrushi
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFGkiCTyHNOxuxOkNIRAmIHAJ9/lh9HhsJ7Ugb3yuWeCtU9wruMtgCbBkz/
HDJb8PtRSJCHKjaoX7BRCak=
=8EUc
—–END PGP SIGNATURE—–
Write a comment