Friday News and Notes
- Cisco and OSIsoft have partnered to offer the PI server on a Cisco infrastructure system through the Application Extension Platform [AXP]. A router and PI server in one Cisco hardware box. Very cool, although I don’t think even a PI fanboy like me would call it ‘legendary’.
- Innominate and their field security appliance, mGuard, have joined Industrial Defenders Enabled Partner Program. This means Industrial Defenders SEM can manage and monitor mGuard. More interesting in the press release was the hard numbers on Industrial Defenders MSSP. They claim to monitor 160 control systems in 21 countries.
- Patching is more than Microsoft. Next Tuesday Oracle will be releasing a number of critical security patches. Some of the patches, “The vulnerabilities addressed allowed for some Oracle products to be remotely exploited without authentication. That is, they may be exploited over a network without the need for a username and password”, according to SC Magazine.
- Dueling Incident Databases. Joe Weiss has his personal incident database. Wurldtech recently announced a their new Delphi vulnerability database. Now Automation World reports that Eric Byres will be resurrecting the BCIT Industrial Security Incident Database thanks to some new funding source.
- This humble blog received its 1000 comment this week. Thanks again to all readers who take the time to intelligently comment on the various topics.
Author: Dale Peterson
Posted: April 18th, 2008 under Uncategorized.
Comments: 6
Comments
Comment from Ralph Langner
Time: April 18, 2008, 11:13 am
What do we make out of the database issue?
If well respected folks like Joe, Nate and Eric don’t manage (or don’t want) to combine and consolidate their efforts, I think we can bury the whole db idea for the next couple of years.
Comment from Jake Brodsky
Time: April 18, 2008, 2:28 pm
Ralph, I think there is room for more than one opinion on what constitutes an industrial cyber incident.
This problem is rife in other industries too.
For example, there is a subtle difference in the aviation incident versus accident databases. An incident is something that happened while an aircraft is not flying, the engines may be running, the aircraft may be taxiing but there is no intention of leaving the ground. An accident is something which happens during any phase of an intentional flight, whether starting, taxiing, taking off, landing, shutting down or whatever.
Both incidents and accidents destroy aircraft. They involve many of the same operations. But incidents do not involve an intentional flight.
Likewise, it is possible to have two different databases of security incidents and attacks, where the results may be very similar, but the intentions are different.
Comment from Ron Southworth
Time: April 19, 2008, 1:26 am
Hi Jake that is a great way to possibly describe different incidents.
I seem to recall someone mentioning an industrial contrls system incident as being any event that causes and adverse effect on the availability integrity and confidentiality of a control system.
I am open to suggestions on what qualifies as an incident but I think the above is probably a good catchall. As to the root cause of the problem limiting it to simply cyber related I think this is too narrow a term of reference.
Thanks Dale for keeping you blog going and making it so relivant
Comment from Ralph Langner
Time: April 19, 2008, 5:13 am
Jake, with so little fact pouring out of the corporate barriers regarding incidents, accidents, vulnerabilities and whatever you may call them, I don’t see a need for multiple databases. How many entries will each db have, 50? And why not have some of our most acknowledged opinion leaders combine their efforts to convince asset owners about the need for and benefit of reporting?
Talking about incidents, BMW recently disclosed that they had a malware outbreak in one of their Bavarian plants “several years ago” that caused disrupted production. Allegedly they sent 5000 workers home while fixing their systems.
Comment from Frank Marcus
Time: April 19, 2008, 2:27 pm
Hi Ralph (and others in the data game),
Disclaimer: I’m an employee of Wurldtech, I work specifically on the Delphi project, as well as Achilles, and work as a consultant for vendors and asset owners, so recongize my bias. However, I hope to avoid all marketing in this post, naive as it may seem.
I think there’s a bit of a misunderstanding about what exactly Delphi is, as in what kind of data it will contain. As Dale wrote in the original entry, Delphi is a “vulnerability” database, whereas ISID (as far as I know, I worked on it a bit in 2005 at BCIT before I joined Wurldtech so things may have changed) and Joe Wessis’ databases track specific incidents. Those incidents of course have technical components, and as a student of data security I am interested in those components, but they go into details beyond the technical, like consequences and strategies to help avoid future incidents, at a policy and procedural level as well as a technical one, details of the perpetrator(s) if known, and even the politics of the incident.
Ralph, I completely agree with you… the Incident scene looks well covered to me and I don’t want to play that game. Delphi started as my own database of “vulnerabilities”, as in the problems i found, during technical assessments and certification projects. Given the NDA-centric nature of the ICS universe, none of that data can be released to the public, and that’s why we’re starting Delphi, as a “product” or whatever business people call these things, to hopefully provide the “sheltered haven” for those who want to (or we can convince to) contribute data to help improve industrial security but aren’t willing to broadcast it to the open world. I know how politically sensitive this particular issue is, so I don’t really want to touch it here.
My primary tool is of course Achilles, and as one would expect it is well-integrated to provide data to the Delphi project, but when I’m working as a consultant it’s not my only tool. Just like IT has BugTraq and US CERT (each serving distinct roles in the “vulnerability” game, managed by a commerical (Symantec) or government entity but open for public contribution and consumption), I hope Delphi will become such a database for the ICS world. BugTraq has been around forever with tons of people contributing, that’s why its successful, and who takes a vulnerability seriously without a CVE number? Those of us in the ICS game have to deal with a lot of politics around the disclosure issue, as Dale as often blogged on. Dale is one of the few to have contributed vulnerabilities related to ICS, and I’m thinking the ICCP here stuff amongst others. I don’t do nearly as much independent research as I wish I could (stupid bills), but we are doing work in such a way that at least santizied versions will be accessible to vetted groups. A step in the right direction I believe. I see a lot of device and application level data, but compared to what we could be harvesting its a drop in the bucket.
Delphi is NOT an incident database, although I’m certainly interested in the vulnerabilities that allowed incidents to occur. I, personally, am less interested in the politics there-in, although I recongize that those politicis will guide the development of new policies and procedures that I will then become interested in again as I seek technical means to measure compliance to them.
ISID and Mr. Wessis’ work is actually pretty unique to ICS. I can’t really think of an “Incident Database” analog in Enterprise Security. Unless you count “The Media” as a database, which works pretty well with Google. But if someone knows of a more formal database I’d love to hear of it.
Sorry for the length of my post. Its Saturday and I’m too lazy to be concise.
Comment from Bryan Owen
Time: April 19, 2008, 9:57 pm
…following the path about Oracle critical patches to MAD’s log leads to interesting plea to universities.
_http://www.oracle.com/security/docs/mary-ann-letter.pdf_
Secure programmer certification work by SANS/GIAC is also referenced.
Likely to be plenty of database fodder if the root issues continue to be left out. Of course, metrics on secure programmer effectiveness are even harder to come by.
Write a comment