Comment from Jake Brodsky
Time: May 20, 2008, 2:07 pm

Wonderware SuiteLink vulnerability: Note that while Tech Alert 106 had a date of March, 2008 on the annoncement; however, the actual PDF file had a date of April 28, 2008. I believe that’s a day or two before the formal release of this bulletin came out. As your guests pointed out, I would be more annoyed with Wonderware, except that there are damned few vendors who seem capable of doing better. At the end of the day, at least we have a fix for this problem.

As for field security appliances, there are two issues that I feel will be crucial. First, Layer 3 sensitivity to various protocols found in industrial automation applications is critical.

Second, remote management. We need to gather traffic statistics on this. We need to have these things monitored in some fashion so that we can use them as a part of an IDS.

And this brings up “Secure by Default.” Security By Default looks like pain-in-the-@$$ by default unless there is some remote way to monitor and manage these devices.

Right now many people seem to be using SNMP. SNMP has its own problems. While there are plenty of drivers out there, they don’t all integrate well with COTS control systems gear.

Personally, I would love to see secure systems by default, but we’re not equipped well to handle a distributed password system managed individually by the technicians who install these devices.

So in that respect these latter two issues are very much intertwined.

Comment from Ralph Langner
Time: May 20, 2008, 2:50 pm

Jake, I haven’t tuned into the podcast (simply because I don’t keep speakers on my computer), but as for the application layer industrial firewall issue, Tofino does it. Perhaps Eric was too polite to mention this. So there is a product out on the market that people can buy today, and it will be interesting to see how the market responds to this fascinating capability.

Regarding the traffic stats issue, my favorite would be to include netflow or rflow in such a device.

Comment from Dale Peterson
Time: May 20, 2008, 3:01 pm

Jake – we are using Netflow data in the Portaledge attack detection project. The PI server has a Netflow interface and also has a pseudo-netflow interface that you can hang off the span port and gather netflow info for the low end infrastructure products that don’t have Netflow or similar capability.

We see this as a fantastic data source. Of course it will identify new communications, but also increases or decreases in data flows between valid communicating pairs.

Regarding the April date on PDF file, I believe you are seeing the date of the last revision.

Comment from Ron Southworth
Time: May 20, 2008, 6:28 pm

Dale, Eric and Mark.

Thanks for this podcast.

Gents, I am interested that you are having difficulty in encouraging Vendors to reply to vulnerability issues.

Perhaps this is an area where end users can help?

Comment from Jake Brodsky
Time: May 20, 2008, 8:36 pm

Dale, ideally I would like to see the IDS data show up on an operator’s screen and on the alarm processor. That’s what I meant by integrating with COTS SCADA.

The date on the PDF file wasn’t the only thing in April. Inside the Zip file with the patch, the dates of the key patch files were from April 24, 2008.

Comment from Dale Peterson
Time: May 20, 2008, 11:29 pm

Jake – the attack detection and other security information, which could include correlated events from IDS sensors, OS logs, control system app logs, firewall logs, PLC logs, …, can appear on a ProcessBook display or any third party control system that can pull data via ODBC, OPC or a variety of other methods can pull and display attack detection.