ICS-CERT may be relieved the spotlight has been focusing on Siemens as their performance and information provided in the Stuxnet and Beresford vulnerabilities has been consistently late and of little or no added value. This makes no sense given the quantity and quality of ICS security talent at INL.
The easy question would be why has INL in its role as ICS-CERT performed so poorly? The related and more important question is … Can INL perform as ICS-CERT?
My answer is no, and I should have realized it much sooner. The reasons INL was selected to run ICS-CERT are also the reasons they cannot perform this role.
I always found it interesting that the need for an ICS-CERT was never mandated from above. It appeared to materialize from the INL itself. In the early years, it seemed that the INL pretty much set the strategy for DHS CSSP, and then executed (bake the cake and eat it too!). That kind of contractor-led direction setting resulted in the creation of the ICS-CERT at the INL – a bid that the INL seemingly won without any bidding process at all. $25M plopped down because it seemed like the right place. At best, the INL “already had the relationships in place;” they had been doing assessments of ICS for vendors for several years – so they had familiarity with the products and contacts.
And that’s exactly right – the relationships did exist – but they weren’t assets; they were liabilities. Under any outside eye those relationships would be called “conflicts of interest”.
Those vendors have paid INL to review their systems, on top of putting hundreds of thousands of dollars of their equipment in the INL computer lab test beds. Many vendors used the INL review as “security due diligence marketing.” It works even though the real results of the reviews are forever protected from disclosure to critical infrastructure owner/operators who need to know by a very restrictive CRADA or NDA.
With the launch of the ICS-CERT, INL took on a new role of facilitating the disclosure of vulnerabilities affecting the products of the vendors they’ve come to know and love (because they’ve paid them). This leads to a number of problems.
- INL has to be able to prove all information related to ICS-CERT work was developed independently to not violate the CRADA/NDA, and they therefore lose all the benefit of their experience.
- They risk making a paying customer angry, and this could spread to other vendor customers who may not trust INL any more.
- They probably cannot use the vendor systems to do the work, since they would be part of the restrictive agreement.
They have another problem, much like Siemens. A question with only two bad answers. Why didn’t INL disclose/confirm the important and accurate information from the multiple Beresford vulnerabilities?
Answer 1: INL did not know of the Beresford vulnerabilities, despite a long and expensive assessment. An assessment that was at least 20 times the size and cost of the Beresford work by a cracker-jack team of ICS security experts. I cannot believe they did not know about the replay vulnerability because they have been highlighting this type of vulnerability for years now.
Answer 2: They knew about the all or most of the vulnerabilities and chose not to tell owner/operators even after presented with evidence of independent discovery by Dillon.
ICS-CERT has clearly failed all of the important tests to date. They are hamstrung by conflicts and CRADA’s. It is time to either shut it down and rely on the general purpose CERT/CC or US-CERT for coordination only — or put out a RFP for an independent ICS-CERT.
Image by Idaho National Laboratory