What ICS-CERT Is and Isn’t

ICS-CERT Distortion

When ICS-CERT was created I expected a lot more.

I expected analysis and insight from skilled ICS security experts.

The reality is ICS-CERT is merely a coordinator of communication between vulnerability finders and the vendor. ICS-CERT Alerts and Advisories simply regurgitate what the vuln finder and vendor state, and the vendor is assumed to be correct if there is a dispute. ICS-CERT is a vendor megaphone.


In May 2006, Matt Franz, then working for Digital Bond, pushed the first ICS vulnerability through the CERT process. Back then it was Art Manion and a team at CERT/CC and US-CERT who handled the ICS vulns. They did a fine job of coordinating with the discloser and affected vendors, and our experience was the resulting advisories were even handed. The team was not filled with ICS experts and handled all types of vulnerabilities.

In 2009 ICS-CERT was launched by DHS, located and almost entirely staffed by INL. $25M was given to INL without any public bid or consideration of the conflict of interest with their vendor assessment services. Still you can say this was a logical place for ICS-CERT since INL had ICS security experts, a lab full of equipment and relationships in place. The pull quote from the launch is “the response team will monitor, collect and analyze cyber incidents reported by industrial control systems researchers and developers, owners and operators, and manufacturers from industry, government and academia.”

They have monitored and collected, but there has been little or no analysis. This is true even for vulnerabilities related to software and hardware widely used in the US critical infrastructure or systems they have in Idaho Falls.

Given the exponential increase in disclosed ICS vulns, it is not surprising that coordination is overwhelming ICS-CERT and leaving little time for analysis. However running on this coordination treadmill has led to cookie cutter descriptions and mitigation advice that is of little value. Analysis should begin on what vulnerabilities ICS-CERT should focus on and what to push off to traditional US-CERT / CERT-CC vulnerability handling.

What ICS-CERT is doing does not require ICS expertise, and is a waste of the talent at INL.


Equally disappointing is the vendor slant that is the rule at ICS-CERT. If a vendor states something, it is accepted and repeated by ICS-CERT without question, unless the discloser chooses to prove the vendor wrong. Examples:

  • Dillon Beresford’s Siemens S7 vulns where ICS-CERT repeated Siemens contention for months that it was unknown if the vulns affected the 300 & 400 series — until Dillon got his hands on a 300 series and proved it in a day. INL / ICS-CERT new the S7 very well, had it in the lab, and it was obvious the whole S7 family was vulnerable.
  • Arthur Gervais / Schneider example from this week. ICS-CERT is a ventriloquist’s dummy. Vendors speak and their words come out of ICS-CERT.
  • The CoDeSys example from Project Basecamp. Vendor says Version 3.x is not affected and voila, there it is in the advisory. Not a small thing since 261 PLC vendors use this code. Most of the vulns were finally fixed in V3.5 SP2 released in December, but any of those 261 vendors with V3.3, V3.4 or even V3.5 would be misled by the ICS-CERT advisory. Simple questioning would have led ICS-CERT to release that Reid’s exploit scripts didn’t work on V3.x due to a minor protocol change, but the vulns had not been fixed.

So ICS-CERT is what it is. A big megaphone tilted to the vendor side. Some vendors provide them with highly accurate information, such as Rockwell Automation, others are intentionally deceptive.


The sad thing about the ICS-CERT’s efforts is the vulnerability coordination hamster wheel they are on makes little difference. All it really does is point out that ICS vendors need a lot of work on their security development lifecycle (SDL).

Vulnerabilities are not necessary to take complete control of an ICS. Paraphrasing Ralph Langner — the professionals don’t use vulnerabilities; they use features.

The vulnerabilities in dispute by Arthur Gervais from yesterday are an interesting case study on ICS-CERT vendor bias, but have little impact on an owner/operator with that device. The PLC in question supports the Modicon Function Code 90, a feature, which would allow an attacker on the network to modify logic or do whatever he can imagine to the process monitored and controlled by the PLC.

All an owner/operator can take from this and other Modicon family vulns is they need to push Schneider on their SDL in addition to demanding an upgrade to address the insecure by design issues.

I’m convinced that all these poor SDL discovered vulnerabilities have become a sideshow that distracts the ICS community from the fact that the key components are insecure by design and need to be upgraded or replaced now. And it is an inefficient use of the talent at INL.


On Monday I’ll put up a longer article with suggestions for what ICS-CERT and DHS should do to make a difference. Then that’s it. ICS-CERT is what it is. Don’t rely on the information or the mitigation advice (which all too often is keep the bad guys out). Use it as a clipping service to identify when there is some public information about a security issue with your product.

Image by thechannelc


  1. says

    …indeed a ‘one stop’ service to help identify public issues is a time saver for owners of many ICS products.

    Maybe I am misinterpreting your comment on identification of public information affecting ICS. It’s not always obvious what products are affected when dependencies (reused libraries like CodeSys or Windows Common Controls) are involved.

    As a point of clarification, secure design is as much a part of SDL as more familiar practices related to code implementation, security testing and incident response.

    The hoopla over a code vuln while core design issue persist is a key point. External pressure from vuln discovery, even with the best of intentions, can be a distraction in some circumstances.

    DHS and ICS-CERT are fostering a healthy way for the ICS community to work together. Perhaps there are better methods but I am not in favor of reset (again). Looking forward to your ideas in the next post!

  2. says

    I agree with you Dale. They could be doing many things better. I suspect that some of the reasons they’re not more aggressive about the way they handle vendors is that they have CRADA agreements in place that prevent them or might be used against them if they show too much initiative.

    In my opinion, I don’t think the blame rests entirely on the folk at ICS-CERT, because they clearly do have some experience and resources at their disposal. I suspect the real reason is that the bureaucrats at Battelle and DHS do not have reasonable guidelines on what should or should not be in a CRADA, or how to handle incidents properly.

  3. Shawn Merdinger says

    I can only speak for myself here, but as a independent security researcher pretty much on his own and actively finding all kinds of security issues, ICS-CERT has been very receptive and maintained solid communications with me as the vendor-researcher-ICS-CERT comms process works it’s way through…

    Of course, nothing’s perfect, but compared to my options even a few years ago, ICS-CERT is still the best place for me to initially bring security research findings to at least get documentation of the issues and some semblance of vendor response.

    I’ll add that the ICS-CERT recognition for security researchers in ICS-CERT monthly newsletters is great feedback.


  4. Shawn Merdinger says

    Looking over previous posts here I came across this great comment by Ralph Langner on your “Can INL Perform as ICS-CERT? No” post.

    “A solid security alert by ICS-CERT, on the other hand, even makes it into the mainstream media these days, and via this path sometimes even in the brains of executives. So we really need ICS-CERT — or a similar government entity — to point out threats and mitigation strategies.

    Now how do we, the community, get ICS-CERT to perform? Well everybody can study this empirically by looking at Stuxnet and at the Beresford vulns. The answer simply is, by putting a gun at their had, with the gun being Metasploit modules.”


    The threat of a Metasploit module is significant, and quickly puts to rest the questions of whether or not a vuln exists….in effect, letting the world decide.

    And it lights the fire for vendor response.

    Looking at the recent Honeywell Enterprise Buildings Integrator alert at http://ics-cert.us-cert.gov/pdf/ICSA-13-053-02.pdf — Rapid7 states a exploit module will be released in March.


  5. says

    @Jake – CRADA protections need not get in the way of disclosure when both parties approve. In observation, norms across the ICS vendor community are starting to track closer the to ICSJWG framework for vulnerabilty disclosure. That said – it is still unnatural to self-disclose especially when a patching is difficult or not yet available.

    @Shawn – agree with your point about ICS-CERT advisories having a better chance of reaching decision and policy makers – especially for a big name product. Meanwhile common design and protocol issues seem to go unnoticed.

Leave a Reply