CISA Announces VINCE-NT

Earlier this week CISA announced their upgraded coordinated vulnerability disclosure platform, VINCE-NT. This new platform will replace the VINCE CVD hosted by Carnegie Mellon University’s Software Engineering Institute; which was primarily focused on vulnerabilities in industrial control systems. The old VINCE site reports that “after November 17, 2026, all CISA vulnerability reports must be submitted through VINCE-NT.” 

According to CISA’s CVD landing page the new VINCE-NT program is designed to expand the CISA CVD program to include: 

• Operational technology (OT) and industrial control systems (ICS),  
• Internet of things (IoT) devices,    
• Medical devices,  
• Open source software,  
• Artificial intelligence (AI), and 
• IT systems.  

The new VINCE-NT data collection form is hosted on a CISA.gov web page. As such it is required to provide a reference to the OMB Control Number for that information collection to show that it has been appropriately reported to, and reviewed by, OMB’s Office of Information and Regulatory Affairs (OIRA) to ensure that it conforms to the requirements of the Paperwork Reduction Act (PRA). This new VINCE-NT data collection page does not provide an OMB Control Number. Back in February, OIRA did approve a new ICR for a “CISA Coordinated Vulnerability Disclosure (CVD) Platform” with an OMB Control Number of 1670-0058. 

Looking Back – 9-17-13 – Disclosure – An Opposing View

 Nearly every morning I start my computer time by looking at information from Google about what happened in my blog in the previous 24 hours. Google, and blogspot.com is a Google service, provides interesting pieces of analytical data about my blog readership. One item of particular interest is the top ten blog posts each day. As you would expect, most of those posts were from the last couple of days, but with 16 years of publishing this blog, every once-in-a-while, a blog post from ancient history rises into that list. 

Today a blog post from September 2013, “Reader Comment – 09-17-13 – Disclosure – An Opposing View”, made the list. It takes a look at the issue of coordinated (and uncoordinated) disclosures of vulnerabilities. The reader comments on the post, from respected names in the community, point out how much interest this topic has driven. The discussion holds up today; it just has gotten more complex now that AI-detected vulnerabilities have been added to the mix. 

HR 680 Introduced – Energy Sector Security

Last month Rep. Ruppersberger (D,MD) introduced HR 680, the Securing Energy Infrastructure Act. This is a companion bill to S 174 that I discussed yesterday. Ruppersberger introduced a similar bill last session (HR 3958), but no action was taken on that earlier bill.

Moving Forward

Neither Ruppersberger nor his single cosponsor {Rep. Carter (R,TX)} are members of the House Science, Space, and Technology Committee to which this bill was assigned for consideration. This means that the bill is unlikely to receive consideration in that Committee unless additional sponsors are signed. As I mentioned yesterday, this study and report bill is unlikely to attract serious opposition other than the fact that it would require the appropriation of $11.5 million.

Interestingly, both Ruppersberger and Carter are on the House Appropriations Committee. That Committee has not been assigned consideration of the bill, but their bipartisan support could help alleviate concerns about the spending aspects of this bill if it were to make it to the floor of the House. Unfortunately, neither are on the Energy and Water Development, and Related Agencies Subcommittee which controls appropriations for DOE.

Commentary

Yesterday, in a LinkedIn comment on my S 174 post, Kenneth Crowther made the comment that “I hope when they. ... "discover new classes of vulnerabilities" they have a plan for responsible disclosure to the vendor...”  Unfortunately, there is nothing in the legislation that would require the pilot program to effect coordinated disclosures. It would certainly hamper the effort to increase grid security if they did not.

Crowther’s point is well taken, and I would suggest that language be added to §3 of both bills to require that vulnerabilities detected during the program be coordinated with the appropriate vendors via the DHS NCCIC-ICS. More importantly, that language should include provisions for delayed public disclosure of the vulnerabilities while secure disclosure is made to utilities after vendors have developed adequate mitigation measures. Here is how that language could read:

(b) Coordinated Disclosure

(1) Any vulnerabilities identified during the pilot program will be reported to vendors in coordination with the industrial control system team at the National Cybersecurity & Communications Integration Center (NCCIC-ICS) in the Department of Homeland Security;

(2) Once a vendor provides NCCIC-ICS with notification that appropriate mitigation measures have been developed, NCCIC-ICS would provide limited disclosure of the vulnerability through the Electricity Sector - Information Sharing and Analysis Center (ES-ISAC);

(3) Ninety days after the ES-ISAC is notified the NCCIC-ICS will provide public notification of the vulnerability; and

(4) If a vendor has not provided a reasonable schedule for mitigation of the reported vulnerabilities within 45 days of initial notification of the vulnerability by NCCIC-ICS, NCCIC-ICS will prepare an alert about the vulnerability and publish that report in accordance with (2) and (3) above.

NTIA Announces Vulnerability Disclosure Meeting – 4-8-16

The Commerce Department’s National Telecommunications and Information Administration (NTIA) published a meeting notice in today’s Federal Register (81 FR 17146) concerning a multi-stakeholder process concerning the collaboration between security researchers and software and system developers and owners to address security vulnerability disclosure. The meeting will be held in Chicago, IL on April 8^th, 2016.

This will be the third in a series of meetings. The first two were held last year in September and December. The meeting in April will build on the previous work in an open, transparent, consensus-driven process to develop voluntary principles guiding the collaboration between vendors and researchers about vulnerability information.

The meeting will be open to the public, both in person and via the web. Information on access to the meeting will be posted on the Multi-Stakeholder Process web site.

Coordinated Disclosure is Complicated

The problem of when to publicly disclose discovered vulnerabilities in control systems is a much debated topic. Theoretically, I think that everyone in the control system vender and owner world would prefer to see researchers coordinate their disclosures so that the vendor has a chance to correct the vulnerability and the owner/operators have a chance to fix their systems before the vulnerability becomes public knowledge. But even when a researcher is committed to coordinated disclosure things can get complicated.

Coordinated Disclosure or Not

Yesterday Adam Crain, a well-known and well documented researcher, posted an interesting blog entry on his web site. In it he discusses a method of dealing with recalcitrant vendors that apparently make no effort to correct a vulnerability in their product that has been identified by an independent researchers and coordinated with both the vendor and ICS-CERT.

Historically (an odd term to use is in this young field) one of the reasons given by many grey hat researchers for not coordinating disclosures is that vendors have ignored them or failed to take action to correct identified vulnerabilities. In general the control system industry has gotten much better at responding to coordinated disclosures. This has been a major contributor to the decline in the number of Alerts that ICS-CERT has had to publish recently.

Unresponsive Vendors

But for every trend, there is an outlier. In this case it appears that Adam has identified one such outlier. Now Adam and his partner Chris Sistrunk have been the poster children for the coordinated disclosure process with the series of DNP3 vulnerabilities in 28 products that they have reported over the last year or so. They have been active proponents of fuzz testing of control system components, but they have been scrupulous in coordinating the disclosure of their serious vulnerability discoveries with vendors and ICS-CERT. But, even Adam and Chris have their breaking point.

Hidden Components

What is particularly disconcerting in this case is that this is not a vulnerable device that can be exposed to the community and provide owner/operators with the choice of how to deal with their vulnerable systems. In this case the identified vulnerability is in software library that may have been used by any number of vendors in developing the software and firmware for a wide range of control system products.

And the system owner/operators have no way knowing if that library has been used in any of their devices, so there is no way for them to protect their systems or even know if their systems need protecting. Okay, I suppose there is a way; Adam has made his fuzzing tool available free of charge and an energetic and system savvy owner could probably use the tool to find the hidden vulnerabilities. I’ll have to ask Adam about how likely is that his fuzzer would find these particular vulnerabilities in an off-line control system (NOTE: Never fuzz test a live control system).

This is an ongoing problem in the control system community (okay in the entire Cybersecurity community) where few organizations have the necessary talent or time to produce every line of code in-house that goes into their control system components. When a control system device (or software) vender buys (or uses open source) software they also get any vulnerabilities in that software. Identifying those underlying vulnerabilities and tying them to all other uses of that code is complicated at best.

We, the ICS security community, need to develop a methodology for identifying and tracking down all of the vulnerable iterations of code that are identified in one place as being vulnerable and used in other systems and applications. The ICS ISAC SARA program is designed to address part of this problem, but I am not sure that it will be capable of going deep enough into the architecture of control systems to really help alleviate this problem.

Continuing the Fight

Adam, of course, is not going to rely solely on outsiders to get this problem fixed. While he has still not publicly identified the particular vulnerability he is doing more than just writing this blog post of his about this specific vender. He is also taking the information to the ICS community; outing the vendor as one of the uncooperative ones. Not only is he attempting to use community coercion to encourage cooperative compliance, but he is in effect warning other vendors that there may be a bug in their systems that needs to be addressed.

I wish him the best of luck, but I don’t expect to see much action, at least publicly. Very few vendors have gotten to the point that they self-identify vulnerabilities in their systems (Siemens is a major exception) even if the vulnerability comes in with outside code.

UPDATED 4-17-14 7:30 CDT - Adam's blog post got an interesting response  (see first comment) from the company involved. They did not like him outing them. Too bad. If they had just talked with ICS-CERT and Adam this whole thing would never have blown-up like this.

ICS-CERT Publishes Another Web Browser Advisory

Yesterday the DHS ICS-CERT published another web browser (no not IE9) advisory, this time with Fultek WinTR (a Turkish web based SCADA system). The directory traversal vulnerability was reported by Daiki Fukumori of Cyber Defense Institute. Fultek has not verified the vulnerability (ICS-CERT has) and has not offered any mitigations (since they don’t have a problem why should they fix it).

The Vulnerability

This is an increasingly common (read: it is being increasing reported) vulnerability (CVE-2012-3011) in SCADA/ICS web browsers. The web server does not adequately sanitize user inputs allowing relatively unskilled attackers to retrieve arbitrary files from the server. There is nothing in this advisory that describes the limits of what files could be retrieved.

Denying Vulnerabilities

As far as I can tell this is the first time the ICS-CERT has published an advisory for a vulnerability that the vendor has denied exits. There have been alerts and advisories where the researcher blew the whistle in the situation, but not one where ICS-CERT called out the vendor. I think that this is a good move on their part for a number of reasons. First it makes it easier for ICS-CERT to convince researchers to coordinate their disclosures. Second, and maybe most important in my opinion, is that it provides a little more pressure on recalcitrant vendors to respond more promptly to fix the vulnerabilities identified.

Kudos to ICS-CERT for publishing this Advisory.

Another HMI SCADA Advisory from ICS-CERT

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published yet another advisory about a vulnerability in a SCADA Human Machine Interface system, this time from a vendor in China, Sunway. The heap-based buffer overflow vulnerability affects two Sunway systems, the ForceControl and pNetPower applications.

There are no published exploits for the vulnerabilities and ICS-CERT estimates that it would take an attacker with an intermediate skill level to exploit them. Sunway has published separate patches for each system.

The interesting thing about this particular set of vulnerabilities is that the security researcher who reported them is Dillon Beresford of recent Siemens vulnerability fame. Obviously Dillon is no one-hit-wonder.

ICS-Monthly Monitor Published

ICS-CERT also published the second issue of their Monthly Monitor today. There is a very interesting description of the vulnerability disclosure procedures used by ICS-CERT; an appropriate topic given recent complaints about their apparent inaction on Dillon’s Siemens disclosure.

The interesting bit of disclosure here that was new to me was that, in the coordinated disclosure process, ICS-CERT publishes a limited edition advisory to be released the day that the vendor publishes the patch/mitigation-strategy. This is published, according to the Monitor, on a ‘secure portal library’, “which is available only to a limited vetted membership— primarily CIKR asset owners, federal, state, local, and tribal agencies”. No word on how one gains membership in this elite group.

As a blogger/reporter on chemical security issues I would not expect to be invited/allowed to join such a group. Even if I could, I don’t think that I would accept because of the undoubted limitations on disclosure that would accompany such membership.

I would suspect that any cyber security manager at a high-risk chemical facility, or any facility on the Critical Infrastructure Key Resources (CIKR) list should be interested in joining this group. I’m not sure how you would go about requesting membership, but I suspect that an email to ICS-CERT@dhs.gov would be a good place to start asking the questions.