Showing posts with label Coordinated Disclosures. Show all posts
Showing posts with label Coordinated Disclosures. Show all posts

Wednesday, March 12, 2014

More on Yokogawa Advisory

Overnight I have been hearing some interesting information about the Yokogawa Advisory issued by ICS-CERT late yesterday afternoon. It seems as if at least a couple of folks had received emails from ICS-CERT notifying them that an advisory about Yokogawa vulnerabilities had been released to the US-CERT restricted portal.

This would normally have been a standard action to be taken with vulnerabilities in a device/application that is widely used in critical infrastructure or in cases where the vulnerabilities were severe enough that exploitation of the vulnerabilities could reasonably be expected to put facilities at risk. It would certainly seem as if both those conditions were relevant in this case.

The whole point of releasing advisories to the secure portal is to allow critical infrastructure a window of opportunity to take action to protect themselves against exploitation of a control system vulnerability before disclosure is made to the public. People working in critical infrastructure get information about such vulnerabilities pushed to them if they are registered with US-CERT (quite obviously I am not so certified, nor do I, quite correctly, have access to the secure portal; I don’t have an appropriate need-to-know).

In a true coordinated disclosure, I would assume that ICS-CERT would reach an understanding with the vulnerability discoverer about public disclosure of the vulnerability while the corresponding advisory was being closely held within the Secure Portal. There is no indication that Rapid7 disclosed this vulnerability to ICS-CERT. Their disclosure policy (which I noted last night) clearly indicates that they coordinate their disclosure with the Carnegie Mellon CERT (CERT/CC).

I would have like to have thought (and certainly did before last night) that with vulnerabilities as potentially serious as this one, that ICS-CERT would have initiated conversations with the vulnerability disclosure to arrange for a reasonable period of at least limited disclosure to allow the release of the vulnerability in the Secure Portal for some reasonable amount of time. With an organization like Rapid7, that might include allowing them to privately notify their paying clients, but not making general public notification of the vulnerability until ICS-CERT published their public advisory.

For whatever reason, that does not appear to have been done in this case; or at least not effectively. With ICS-CERT apparently releasing this to the secure portal at about the same time that Rapid7 was publishing public notice (with Metasploit modules) indicates that there was some serious miscommunication between the two organizations.

Since yesterday afternoon’s advisory release from ICS-CERT did not include the standard Secure Portal disclosure statement it doesn’t seem that they are willing to publicly discuss this issue for whatever reason. I suspect that it is a political (small ‘p’) issue with ICS-CERT trying to maintain reasonably good relations with the security research community, particularly those that coordinate their disclosures with vendors and/or CERTs. I understand that kind of effort since ICS-CERT has little enough that they can give in the way of incentives to that community to responsibly disclose these vulnerabilities.

This particular situation, however, is quite serious. The disclosure of the Metasploit modules at the same time as the public disclosure of the vulnerability always gives an edge to the potential attackers. Given the fact that that Yokogawa systems are used in critical infrastructure this potentially puts the public at risk. If miscommunication was responsible for that risk, then we need to know about what steps are being taken to prevent such incidents from happening in the future.

At the very least the DHS OIG needs to take a look at this particular incident. Congressional committee’s looking at cybersecurity issues also need to look at this situation and determine what their legislative responsibilities are to help prevent such occurrences from being repeated.


Let’s hope that the owners of these Yokogawa systems, particularly those in critical infrastructure, are able to get these vulnerabilities mitigated before someone aggressively exploits them. I sure don’t like relying in hope.

Saturday, May 5, 2012

ICS-CERT Monthly Monitor – April 2012


Yesterday afternoon the folks at ICS-CERT published the latest edition of their Monthly Monitor. As is usual there is lots of good information, but this one may be especially important because of the description of another industry-wide spear phishing attack.

Gas Phishing


As I would expect from an open-distribution intelligence report there is a large dearth of information available in the report. We do know that it is a spear phishing attack targeted on the gas pipeline industry and that it is ‘tightly focused’ in its targeting. The closest we get to specifics is that “the e-mails have been convincingly crafted to appear as though they were sent from a trusted member internal to the organization”. This would seem to indicate that there has already been some intelligence collection effort put into the attack before the targeted emails had been sent.

There is also nothing in this report that specifically mentions if control systems were (or were not) ultimately targeted in this attack. Since this is an ICS-CERT report about their response to the attacks, one could be forgiven for making the assumption that the ‘tightly focused’ targeting was directed at personnel within the organizations with direct control system access from their lap top or desk top computers.

Because of my brief exposure to military intelligence (and even more briefly counter-intel) many years ago I fully understand why this report had to be so vague. I wouldn’t be truthful if I didn’t note that my curiosity was severely annoyed by the lack of details, but I do understand. Fortunately the article does note that people in the affected industry can get additional details about this attack via the US-CERT Control Systems Secure Portal. As one would expect, there is a vetting process, but critical infrastructure owner/operators can apply for access via an email to


I would certainly recommend that security managers or cybersecurity managers petition for this access as soon as possible. The Monitor article notes that an alternative source for this information would be the critical infrastructure sector Informa­tion Sharing and Analysis Center (IS AC). NOTE: The chemical sector does not have and ISAC.

I would like to reiterate a point that is made in the closing paragraph of this article in the Monitor; ICS-CERT is only able to share this information because affected personnel reported the suspected attack to them in a timely manner. The article notes (page 1):

“In this particular campaign, reporting organizations enabled ICS-CERT to analyze the data and create an overall view of the activity in progress. This would not have been possible without the active cooperation of the reporting organizations, so ICS-CERT commends those involved and requests continued private sector reporting whenever possible.”

While the information sharing bill (HR 3523) recently passed in the House had no real provisions included for encouraging or requiring information sharing between the government and the private sector, this situation shows that at least within the control system security community there may not be a real need for such legislation. In this instance, at least, there appears to have been the type of cooperation and information sharing that should be a model for other sectors.

More information on the US-CERT Secure Portal is included in a separate article on page 5 of the Monthly Monitor.

Situational Awareness


The ‘Situational Awareness’ section of the Monitor again has a number of brief but interesting articles covering a wide spectrum of control system security issues. The articles address:

• Risk management planning for the electricity sector;

• ICS tabletop security exercises; and

• Planning for a cyber-incident.

Again, because of my military background, I am a firm believer in conducting emergency response exercises of all types. There is an old military adage that no plan survives contact with the enemy, but the more often you practice anything the better you will be at it when the real thing comes around. As the table top security exercise article notes, if you need more information on, or want assistance with, an ICS exercise contact the folks at ICS-CERT (cssp@hq.dhs.gov; Note: this is a different email address than normally given for ICS-CERT).

Coordinated Disclosures


All of the normal features that we have come to expect in the Monthly Monitor (Have I mentioned recently how much I appreciate the effort that has gone into this publication?) are in this issue and well worth the brief time necessary to review them.

I do want to make one specific point about the ‘Coordinated Vulnerability Disclosure’ section. This boxed section includes a monthly list (February 2012 in this case) of ‘Notable Coordinated Disclosure Researchers’ that ICS-CERT wants to acknowledge for their on-going efforts to coordinate the disclosure of their reported vulnerabilities. A prominent name (5 of the 7 listed disclosures) is that former poster-child for uncoordinated disclosures, Luigi Auriemma.

While I am certainly not an adamant believer in the absolute necessity for coordinated disclosures, I do believe that, all things being equal, the control system community is better served if researchers, vendors, and CERTS can cooperate in the reporting and remediating process. It is certainly heartening to see a ‘notorious’ researcher like Luigi working within the process where possible.

Again, another good job by the folks at ICS-CERT in publishing this month’s Monitor. This should be read and shared by all within the control system security community and up the chain of command to those with ultimate responsibility for the security of these systems.
 
/* Use this with templates/template-twocol.html */