ICS-CERT issued an Advisory on Friday titled Rockwell Allen-Bradley MicroLogix, SLC-500, and PLC-5 Fault Generation Vulnerability. This is just a distraction from the PLC insecure by design issue.
The impact of this vulnerability is denial of service. You don’t need to exploit a vulnerability to take a PLC running EtherNet/IP out of service; the pro’s will use the features in these PLC’s. Just send it a EtherNet/IP Stop CPU command. If you want to do something more permanent upload bad logic or firmware.
A few comments on the players in this Advisory:
ICS-CERT
Thanks for nothing; truly pathetic effort. Is this an important vulnerability? Does it increase risk to owner/operators who own these products (not really). Are they living with insecure by design features that make attacks on integrity and availability trivial to an attacker with manuals, protocol standards and a PLC to test on? (Yes) Should they have a plan to upgrade or replace these insecure by design PLC’s if availability and integrity is a requirement? (Yes)
And ICS-CERT left out the most important part of the disclosure. From the Rockwell Automation Bulletin (free login required):
The MicroLogix controller is susceptible to a remotely exploitable Denial of Service (DoS) attack should it receive certain messages that change specific status bits in the controller’s Status file. Under these specific conditions, an attack will be successful regardless of controller’s mode switch setting. A successful attack will cause the controller to cease its logic execution and enter a fault state. Recovery from this fault state requires the controller’s operating mode selector to be switched via direct physical interaction. (emphasis added)
This requirement for physical interaction is a bigger recovery effort than recovering from a Stop CPU command but less than using the insecure by design features to brick the device.
And the ICS-CERT advisory actually includes an advertisement for Rockwell Automation Consulting, “Enlist additional security expertise by engaging Rockwell Automation’s Network & Security Services team for specialized, consultative services. For more detail visit http://www.rockwellautomation.com/services/security/”
Rockwell Automation
Nice job on the vulnerability handling. The researcher, Matthew Luallen of CYBATI, found the vulnerability in a MicroLogix 1400. RA took the initiative to determine and disclose what other products were affected. They have good technical detail in the RA bulletin, and RA doesn’t try to downplay the issue. The only fault I have with the bulletin is they don’t name the researcher who found the vulns.
RA and other vendors shouldn’t be spending time trying to secure legacy field devices like the SLC-500 and may choose to not have a secure upgrade path for older devices like the PLC-5. They were designed for a different time and a naive security threat environment.
I’d also argue that RA should not be focused on fixing these vulns in the MicroLogix because they will not affect the risk these insecure by design devices contribute to the SCADA or DCS risk. RA should be focusing on two things:
- Adding security to the EtherNet/IP protocol. I have heard, but not confirmed, there is now a Special Interest Group (SIG) in ODVA to add security to the CIP family of protocols that includes EtherNet/IP. Accelerate this as much as possible and get the result implemented in the RA PLCs, beginning with the PLCs being purchased for new deployments.
- Focus on improving the Security Development Lifecycle so vulnerabilities like this will not be introduced in new code, or at least significantly reduced. This code was almost certainly developed before RA had an SDL. RA will need to start going through older code that will live on in new products or a steady stream of vulns will continue.
Matthew Luallen of CYBATI
Nice work. The comments on the insignificance of the vulnerabilities to changing known and accepted risk are not a reflection on the research. Hopefully it is another data point that leads owner/operators to realize they need to upgrade or replace their PLC’s in the next 1-3 years. CYBATI offers ICS security training, and my guess is he uses this as one of his examples or labs.
Image by underminingme
“and my guess is he uses this as one of his examples or labs.”
He does :-) and it’s a great training course.
Dale,
Yes we are barraged with tonnes of information by the millisecond, but aren’t you shooting the messenger?
US-CERT is simply providing the information to a wider group than might not be subscribed to – in this case – Rockwell’s PSA’s. As a reference, I am subscribed to Rockwell’s PSA’s for their full product line, never received this vulnerability notice. Being subscribed to US-CERT notices, I received the notice from US-CERT that allowed me to go search for it – just as you did.
So to me, this notice was not meaningless, it caused me to seek out the information directly from Rockwell and then be able to assess and manage the risk for my customers.
In ICS as you well know, 100% system availability / reliability at the lowest possible cost has always been the ICS priority, security was never a design specification. As such, the barn door to the pasture and the gate from the pasture to the road have been wide open for over 30 years. We know the vulnerabilities are there as ripe, low hanging fruit discovered during playtime. The challenge of our work product is to make the farmer / rancher understand that his gates are indeed open, some livestock is missing, then provide a solution to close and lock the gates to the pasture and barn door with the parts we have when the hinges and locks were not part of the original design. It is only within a few short years that Industry has realized the financial and availability/reliability impacts of ICS Security
The ICS vendor community is far behind the curve to solve these problems for industry and their end users considering 90% of the installed ICS base have little or no security or features properly deployed, and a high percentage of end users have no budget, knowledge or motivation to implement even the simplest risk mitigation techniques.
I fully agree however with your point regarding the massive amounts of information that is disbursed per millisecond from all corners of the Internet regarding potential vulnerabilities and exploits that must be evaluated for relevance.
This correlation of targeted information is one of the Missions, Visions and many goals for ICS-ISAC.org, being focused to collect information from all sources, analyse and distribute the relevant information to the correct audience for appropriate action in a responsive time frame. It is our goal to properly categorize and disburse this deluge of seeming meaningless and facially unrelated data into reports that are extremely useful to the end recipient.
Cheers!
Glenn – The key is what are our, the ICS community’s, expectations. In your comment you refer to US-CERT, but the issue really is ICS-CERT.
US-CERT was handling ICS vulnerabilities along with all other vulnerabilities before ICS-CERT was created. Having worked with them on coordination of the early SCADA and DCS vulns, US-CERT with an assist from CERT/CC did a fine job on coordination.
ICS-CERT also does a fine job on coordination. They are bulldogs who never let the issue drop no matter how long it takes. We have praised their coordination capabilities many times on this site.
The issue is ICS-CERT was created because there was a viewpoint that additional ICS context was required in the Alerts, and the ICS-CERT expertise needed to provide this context did not exist at US-CERT.
If you look at the ICS-CERT bulletins, it is very rare to find any useful context. They take the vendor’s bulletin and add some ICSsec boilerplate to the end. Or in the case of alerts they repeat the researchers assertions. I agree that they push it out to a wider audience, but US-CERT could have done this just fine.
This current vuln is a great example, which is why I chose to highlight how ICS-CERT could have provided additional context.
If this is all we are going to get from ICS-CERT, just pull it out of INL, assign a few more resources to US-CERT, and have those talented INL researchers do something useful.
But there are politics involved in the big picture, no doubt.
I am not a believer that it is governments role to mandate private industry behavior UNTIL it becomes a matter of National Security (Constitutionally) or imminently affects Regulated CIP (regulatory).
So the ICS community expectation should be that the vendor will timely fix vulnerabilities under Product Liability statutes and good corporate citizenship, and vulnerabilities elevated to a higher threat level should then then go to CSSP/ICS-CERT for risk management IF it falls within the CIP 18 Industry Sectors.
As to organization -
US-CERT/ CSSP and ICS-CERT are government agencies operating in a silo structure under the Executive Branch of the US government DHS to provide for CIP of the 18 Industry Sectors. That’s its main delegation. Anything else must be specifically delegated from up the silo organization i.e delegation of authority.
US-CERT itself extends far outside the narrow focus of ICS CIP for the 18 Industry Sectors to leverage the full effect of the Critical Infrastructure Information Act of 2002 (CII Act)
Fairly, ICS-CERT is charged with some sort of analysis, but specific to ICS to segregate the huge range of topics US CERT has to deal with under the CSSP for CIP, and doesn’t some of that come from INL now? Yes, for the Energy Sectors!
Let’s consider for a moment,
does INL have the resources to replicate or comment on precise and detailed solutions provided by the vendor for adequacy across all CIP Sectors? NO. Next let’s ask, SHOULD they? NOT in their Mission Statement -(see below), and that is the politics and organization structure.
What is the charter CSSP’s ICS-CERT can operate within?
I will recommend that if the vendor is not capable to provide a timely solution for a disclosed vulnerability, AND it is a matter of CIP, then ICS-CERT, using whatever laboratory resources are available to them both Governmental – public and private, MUST step in to provide analysis and solutions support in great detail; but then again, that is the politics!
BUT, isn’t the issue: resolution of vulnerabilities and full disclosure which are the responsibility of the manufacturer vendor community, not ICS-CERT?
That is what ICSJWG Vendor Subgroup has documented in the Vendor Disclosure Framework document with cooperation of the Private Sector.
ICS-CERT, through DHS US -CERT as the main chartering agency, is simply the facilitator and messenger to promote awareness and supplemental analysis specifically for the ICS arena for CIP of the 18 Industry Sectors. That is the mission limits and chain of command, that is the politics.
So, what is the true range of responsibility – or limits, held by ICS-CERT within DHS US-CERT?
Here is ICS-CERT Mission:
“The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) provides a control system security focus in collaboration with US-CERT to
-respond to and analyze control systems related incidents,
-conduct vulnerability and malware analysis,
-provide onsite support for incident response and forensic analysis,
-provide situational awareness in the form of actionable intelligence,
-coordinate the responsible disclosure of vulnerabilities/mitigations, and
-share and coordinate vulnerability information and threat analysis through information products and alerts.
The ICS-CERT serves as a key component of the Strategy for Securing Control Systems, which outlines a long-term, common vision where effective risk management of control systems security can be realized through successful coordination efforts.”
So where is ICS-CERT not operating within their Mission statement? ICS-CERT is charged with handling all the stuff specific to ICS CIP of the 18 Industry Sectors. They can not own the product, they can not legally reverse engineer the product, nor can they own the solution to an exploit vulnerability. Maybe there are another set of mitigating factors fro summarizing an Advisory?
Can the ICS-CERT Advisory message be more succinct and resolute? No argument there, but only if the vendor has disclosed outside the internal disclosure framework; only if the vendor has a working solution -, then yes, it should be linked, discussed and rated for the potential of achieving a quick, safe and proper solution. Otherwise, it may still be under control of the vendor as the vendor owns the product and its liability by law.
As a subset of CSSP/ICS_CERT ICS CIP of the 18 Industry Sectors: Let’s look at what the INL’s mission statement says. it is:
“Mission
Ensure the nation’s energy security with safe, competitive, and sustainable energy systems and unique national and homeland security capabilities.
Vision
By 2015, INL will be the pre-eminent nuclear energy laboratory with synergistic, world-class, multi-program capabilities and partnerships.”
So INL can NOT step in for the full range of scope that ICS-CERT has, which is across all 18 CIP Industry Sectors because their charter is, and has always been the ENERGY Sector. ICS-CERT nor INL may implement a solution and mandate its application to an industry. There is too much liability. Yes, that is the politics … And the energy sector is under strict Federal Regulation. That is the politics.
This is also where CSSP ICS-CERT moves – albeit cautiously, its responsibility into the full range of ICS in CIP Industry Sectors and within the limits of Product Liability with the Private sector – the fine line for moving the political football, which includes, Advisory Disclosures written for limiting the risk of lawsuits brought from the private sector for defamation or dilution of business. Think deeply about that statement because that vulnerability is real risk.
Shall we Nationalize any US industry failing to provide vulnerability solutions on a timely basis where it affects CIP, or just dissolve ICS-CERT in favor of tossing all that work to diversify tasks back to US-CERT? Neither. I believe CSSP ICS-CERT is the natural progression for task segregation responsibility of ICS in the CIP for the 18 Industry Sectors within the existing jurisdiction of its charter and limitations placed upon its activity by law. They simply need to grow into the role as budget and control from Congress and the President allow.
So let’s place responsibility to the product manufacturer for resolving vulnerabilities; let ICS-CERT work with the private sector under their mission to improve ICS infrastructure within the 18 Industry Sectors by supporting private industry to develop solutions in a competitive market; and not look to the FedGov to solve all the problems created by capitalism and free enterprise.
and unfortunately, that is the politics.
Cheers!