ICS-CERT Publishes Havex Advisory

Earlier today the DHS ICS-CERT upgraded their Havex alert updated last Friday to an advisory today and included new information in the released document. They also explain some of the additional data that is available on the US-CERT secure portal.

The new information includes references to a Symantec blog post about the Dragonfly Group. Their information is very similar to the report I mentioned yesterday from CrowdStrike. The fact that the two reports agree on so many areas is a good indication that the base intellignece may be being properly interpreted.

The advisory also expands on some of the information that Havex has been searching for. ICS-CERT provides some examples of the search results found by the Trojan as it searched for OPC linkages.

The advisory also provides the following list of information that is available on the US-CERT secure portal:

• Three C2 IP addresses and 105 C2 Domains

• Eighty-seven SHA1 hashes of unique Havex Variants

• Sixteen Havex payload SHA1 and four Havex Installer SHA1 signatures and filenames

• Six Karagany filenames/MD5 hashes, 4 Karagany filenames, 2 Karagany C2 Domain IPs, and seven misc directory paths, agent strings, outbound traffic, and directories to watch.

• A STIX /TAXI file (IB-14-20124.stix.xml) containing details on the Trojan.Karagany.

It is kind of odd (from a counter-intelligence perspective) that ICS-CERT would publish this descriptive list of sensitive files that are being held on a secure server. Typically information security folks would tell ICS-CERT that the simple list above would allow the perpetrators to successfully determine how well the investigation against them is proceeding. It also explains to the Havex creators what areas of their tool suite will be less effective in the Wild.

US-CERT Secure Portal Update

I got an interesting email today from Monica Maher, the Chief of Operations at ICS-CERT about access to the control system security area within the US-CERT secure portal. She wrote:

“I wanted to let you know that about a year or so ago, we updated our policies and procedures to allow a variety of ICS stakeholders to obtain membership.  Previously, we vetted asset owners and operators as well as ICS vendors into our portal.  Due to feedback, we created a process to also allow ICS consultants and systems integrators into the portal.”

With this information I would like to expand my suggestion that system owners should sign-up for access to the US-CERT secure portal to include control system vendors, integrators and ICS security consultants. The more ICS security people that are involved in this information sharing, the better off the community will be.

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.

ICS-CERT Updates Havex Alert

Last night the DHS ICS-CERT published an updated version of their alert for the Havex Trojan. The update provides a more complete description of the actions of the Havex Remote Access Trojan (RAT), though still not as detailed as the original F-Secure blog post. It does, however, report for the first time a separate operational issue with the Havex RAT:

“It is important to note that ICS-CERT testing has determined that the Havex payload has caused multiple common OPC platforms to intermittently crash. This could cause a denial of service effect on applications reliant on OPC communications.”

This would not be expected to be a deliberate design element of the Trojan, but it could serve as an indicator of a potential Havex attack for organizations that do not have operational system logging capabilities.

ICS-CERT Still Restricting Information

ICS-CERT is still restricting information about the known ‘watering hole’ sites to the US-CERT secure portal. I agree with Dale Peterson’s Tweet that this probably slows the community response to this threat vector as only a very limited number of control systems organizations currently have access to this information source. ICS-CERT continues to provide information on how to request access the US-CERT secure portal:

“ICS-CERT encourages US asset owners and operators to join the control systems compartment of the US-CERT secure portal. To request access to the secure portal send your name, email address, and company affiliation to ics-cert@hq.dhs.gov.”

This is a very low threshold to pass to gain access to this information. While we can (and should) debate whether or not ICS-CERT should be restricting access to information that the source of the Havex attack already knows (and the F-Secure blog post identifies clearly enough for the attacker to know which compromised sites have been identified), any organization that uses an OPC server in their control system architecture should apply for access to this information.

Mitigation Measures

The update also significantly expands the mitigation measures that organizations can use to limit the activity of the Havex Trojan. There is not anything new here, but this appears to be a pretty good list of actions to take to secure control systems in general. ICS-CERT does not provide any specific indicators of compromise in this alert, but they do provide a link to the F-Secure blog post on this RAT from Monday that does contain some of those indicators.

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.

Information Sharing

ICS-CERT continues to request that organizations that know or suspect that they have been compromised by Havex contact ICS-CERT. Any new information that may be provided by users will make the ICS-CERT investigation of this malware more complete.

This would be a very good point in time to have federal legislation in place that would provide safeguards for organizations that wish to share this type of information with ICS-CERT. At a minimum such information sharing activities should be protected to limit liability concerns and restrict what detailed data the government can share with other organizations, both governmental and private sector.

Lacking such specific cybersecurity information sharing protections, anyone submitting detailed information to ICS-CERT should attempt to avail themselves of the protections provided by Protected Critical Infrastructure Information (PCII) program. At an absolute minimum any information submitted to ICS-CERT should specifically include the following PCII Express Statement:

“This information is voluntarily submitted to the Federal Government in expectation of protection from disclosure as provided by the provisions of the Critical Infrastructure Information Act of 2002.”

A better method would be to include the ‘Express and Certification Template’ found in Appendix 5 of the PCII Procedures Manual.