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