Previous blog entries have covered Day 1 and the Vulnerability Disclosure Panel. Here is a bit of news from Day 2 and summary thoughts.
Summary Thoughts
- DHS puts on a quality event both in the organization and agenda. It’s definitely worth attending if you haven’t before, and the price is right (free).
- I’m not sure what ICSJWG is now. What is the theme or purpose of the event? I think it is an opportunity for the government to explain to industry what they are doing in ICS security and to foster the “public/private partnership”. Personally I find the government process presentations to be dull and not particularly helpful to the community, and I confirmed this general impression with some of the usual suspects.The best part of ICSJWG is always the break out sessions, but these are not in line with the theme. PCSF struggled with this same problem and finally just gave in and tried to make PCSF the harmonic convergence where every group involved in ICS security came. You went there to get updated on what had happened over the last year and see everybody.
- The audience is very much the usual suspects. Mostly government types, niche consultants and vendor reps. Quality people who know the topic well. Some owner/operators but mainly the people that attend a lot of these events. It would be interesting to find out the percentage of owner/operators and percentage of new owner/operator attendees.
- This year I attended both the spring and fall ICSJWG; one a year is enough mainly because of the previous bullet. It’s great to see and catch up with everyone, but the limited new attendees and new information doesn’t warrant twice a year attendance.
- There was a very large Japanese contingent at ICSJWG this time. Even a film crew from NHK (think BBC of Japan). I’ll check with my NHK friends to see when it will be available online.
- I get a lot of blog ideas and future stories from ICSJWG.
Day 1
I attended three talks besides the vuln disclosure panel on Day 1.
Tim Roxey of NERC gave a keynote type presentation on how things had changed over the last thirty years.
Zach Tudor of SRI provided some interesting information on LOGIIC 2. This is the consortium of oil companies, BP, Shell, Chevron, Total, who fund some research. LOGIIC 2 looked at the integration of safety systems and control systems. There were three architecture cases:
- Safety and control integrated on the same LAN
- Safety and control on separate LAN’s connected by a gateway
- Safety and control separated with only a serial connection between the two.
The results were surprising, borderline unbelievable. “The technical integrity of the safety function was not impacted during any of our evaluations.” I know it’s happening, but I can’t fathom how a company can select architecture 1. And I would only recommend architecture 2 if there was a one-way firewall preventing an attacker or malware on control system from getting to the safety system.The report did come to an agreement on a compromise general statement, “Greater integration may introduce greater risk”. There will be a paper on LOGIIC 2 released shortly, and we will link to it.
Finally I attended the WIB / IEC 62443-2-4 briefing by Holstein and Ahmadi. There is a lot of action in the certification realm between the Achilles, WIB, and ISASecure certs. The WIB document is helpful, but … Let me stop there. You should read the WIB document, and it will help you levy requirements on your vendor. Shell and some other large owner/operators are getting behind it and requiring or considering the certificate in procurement decisions. It is a positive force, and kudos to Wurldtech, Shell, Dennis, Tom and others for bringing it forward to this point.
But … pretending the certificate portion is anything more than a Shell/Wurldtech effort that they are kindly sharing with the rest of the community is a bit of a joke. There are no requirements for a vendor to become a certifying entity besides WIB approval. If you look at ISASecure there is a process and set of requirements to become a certifying entity. For WIB you just need to prove that you are testing the requirements sufficiently. Each certification entity process could be different. Basically they wanted a certification entity fast, wanted it to Wurldtech, and chose this path.
It is perfectly appropriate for Wurldtech or any other organization to offer an independent certification, and the industry can assign a value to that. Personally I think that a vendor having this Wurldtech certificate does likely mean the vendor has a reasonable security program in place. But at this point it is a far cry from the rigorous, industry based certification program that ISASecure has put together.
The other issue is with the characterization and reality of the WIB document in IEC. Attending the presentation and reading the release they emailed out with Version 2, you would think this document would go through IEC like a greased pig. This is so far from the truth. The document barely got enough votes, ~55%, to continue to be worked on in IEC. And many of these votes were because voting members did not want the document to move to another organization where they would have no control on the final version. There were over one thousand negative comments on the document, and this number was primarily limited by time.
It may be an IEC document at some date, but they way it was created and arrived at IEC will make its path much tougher.
Image by wseltzer