ICS-CERT and Information Sharing

An interesting series of twitversations were started yesterday about a single sentence in my post about the latest ICS-CERT update on the Havex Trojan. That dialog is important but a little more complicated than can be easily captured in 140 characters. I will try to address my outlook on the question here and welcome comments and opposing points of view to chime in on this discussion.

The Twitversation

What started this was the blog comment about mitigation measures:

“Presumably more up-to-date indicators are available through the US-CERT secure portal. This is another reason for potential targets to request access to the US Cert Secure Portal.”

Dale Peterson from DigitalBond started the twitversation from there noting that “we were told portal access is limited to asset owners”. I don’t know who the US-CERT allows to have access to their secure portal (I have not applied as I would almost certainly be turned down not being an owner or security professional, just a gadfly), but I replied “DHS ought to be fairly broadly defining 'asset owners'”.

I then made the more than a little sarcastic comment that folks in the ICS security business probably would not be included because “Ya'll are competitors after all (SAD)”. This touched a perennial sore spot with Dale who does not think that ICS-CERT/INL should be one of his business competitors (I agree).

Dale also asked: “what about integrators, resellers, vendors, industry groups ...”. To which Andy Robinson chimed in: “we are the ones who usually id and fix”. Again these are both important points.

US-CERT Portal

According to the US-CERT web site describes the US-CERT Portal this way:

“The US-CERT Portal provides a secure, web-based, collaborative system to share sensitive, cyber-related information and news with participants in the public and private sector, including GFIRST, the CISO Forum, NCRCG, ISAC members, and various other working groups. Authorized users can visit the US-CERT Portal.”

Access to the secure portal is provided to individuals or organizations that have been approved by various agencies of DHS. The ICS-CERT is apparently an approving agency for the ‘control systems compartment’ of the portal. Send requests for access to: ics-cert@hq.dhs.gov.

I do not personally know what criteria DHS uses to allow access to this portal. I would assume that representatives from critical infrastructure with cybersecurity exposure would be given access. I would hope that ICS-CERT would provide the widest possible access to control system owner.

I am extremely disappointed to hear that organizations like DigitalBond, an internationally recognized control system security company would have been denied access. I would think that it would be in the best interest of industry if security service providers, integrators and vendors were made an integral part of the information sharing community in the US-CERT secure portal. For a very large portion of the industrial control system owner community, these people are the ones that install, maintain and secure industrial control systems.

Why Restrict Access to Information

There are a number of legitimate reasons that the security and intelligence communities need to restrict access to information about control system vulnerabilities and threat information. For many control system applications, for example, there is no easy way for vendors of an application to reach out to the ultimate owners and users of those applications to ensure that they are informed of mitigation measures before a public release of vulnerability information. The ICS-CERT use of the secure portal to make such information available to the affected community before publicly announcing the vulnerability makes good sense.

When a cyber attack is first identified in the wild the cyber intelligence community needs to be able to share information with other potential targets to be able to identify and limit the effects of the attack. Conducting that outreach in a public forum would just ensure that the adversary make changes to their methodology to avoid further detection.

When cyber attack information is developed by private entities (such as F-Secure, Symantec, or CrowdStrike) using proprietary technology or techniques the sharing of that proprietary information would damage the business of those researchers and limit their ability to continue to develop threat information. Protecting information about those techniques and technology is a legitimate way to encourage those companies to continue to share their intelligence information with the government.

Questions about Status of Specific Information

It is easy for someone on the outside (like myself) to criticize government agencies for what information they share or fail to share. By definition we don’t have all of the information about a particular data release (or non-release) to be completely aware of what actually went into the release decision. Still we have a moral obligation to try to hold the officials involved accountable for their actions.

In a perfect world these decisions are made by professionals who have the best access to the information involved and complete understanding of the consequences of the release or restriction of that information. In the real world professionals are called upon to make these decisions on the fly with incomplete information about sources and consequences. And too frequently these decisions are made by professional politicians not security professionals.

From the outside, a good example of questionable information restrictions is the data about the three compromised web sites in the F-Secure report. I understand why a commercial organization like F-Secure would not publish that information; they are protecting themselves against potential libel and slander charges from the owners of the affected sites.

A government agency might take the same action based upon those concerns, but they are much better isolated from such liability claims than would be an organization like F-Secure. However, when ICS-CERT publicly announces that the identity of these sites is available on the US-CERT secure portal it is obvious that they are not trying to avoid litigation from the sites involved. Even the claim that they are protecting F-Secure from such litigation would be hard to accept in light of the public announcement of the information being available.

This is one of those times that it appears that the politicians have made a decision to protect information for a non-security related reason. And as is usual when security decisions are made for political reasons, this decision has put people (control system owners) at risk unnecessarily. This information should be given the widest possible dissemination to allow potentially affected system owners to evaluate their particular risk.

Lack of Cybersecurity Information Sharing Rules

It is situations like this one that illustrate the problem with the lack of information sharing rules for cybersecurity issues. Without a full and complete political discussion about what information should be shared by whom, with whom and under what conditions, the politicians within the executive branch are making these decisions on an ad hoc basis behind closed doors.

Now I understand and agree that the sharing of personally identifiable information is an important concern within the personal liberties community (and that community should be very large and important). How to protect individual information from abuse by large corporations and the government is a very complex and politically sensitive issue.

Fortunately, that portion of the cybersecurity problem is not very prevalent in industrial control system security issues. Perhaps Congress ought to take a first pass at cybersecurity sharing legislation that focuses on the narrow issue of information sharing about industrial control system security issues. This would allow that very important part of the security problem to be addressed and would allow the government to work out information sharing protocols that could be adopted to the broader cybersecurity problems without putting personal information at risk during the development process.