CISA Publishes Coordinated Vulnerability Disclosure 60-day ICR Notice

Today, CISA published a 60-day information collection request (ICR) notice in the Federal Register (89 FR 86352) for a new ICR on Vulnerability Reporting Submission Form. According to the discussion in this notice:

“CISA is responsible for performing Coordinated Vulnerability Disclosure, which may originate outside the United States Government (USG) network/community and affect users within the USG and/or broader community, or originate within the USG community and affect users both within and outside of it. Often, therefore, the effective handling of security incidents relies on information sharing among individual users, industry, and the USG, which may be facilitated by and through CISA. A dedicated form on the CISA website will allow for reporting of vulnerabilities that the reporting entity believe to be CISA Coordinated Vulnerability Disclosure (CVD) eligible. Upon submission, CISA will evaluate the information provided, and then will triage through the CVD process, if all CISA scoped CVD requirements are met.”

CISA provides the following initial estimate of the annual burden that will be imposed by this collection:

Background

Back in April of 2022 I wrote about [removed from paywall] changes in CISA’s new landing page for industrial control system security. That page included a link to a form to be used for reporting control system vulnerabilities, described as “CISA’s vulnerability disclosure platform, VINCE.” That page (and link) still exists on the CISA website. I explained in that post:

“The ‘Report a Vulnerability’ link takes you to the CMU Software Engineering Institute’s Vulnerability Information and Coordination Environment (VINCE) page for reporting vulnerabilities. This is the reporting page that has been used by CERT-CC and typically has resulted in the well-known VU#s issued by CERT-CC. It is not yet clear if the information shared with CERT-CC via this page will be primarily addressed in advisories published by NCCIC-ICS or advisories published by CERT-CC. The link from the CISA page does automatically check the “Significant ICS/OT impact?” box a third of the way down the page, so that may bifurcate the vulnerability reporting and coordinating responsibilities. Or CISA may just be contracting those responsibilities to CERT-CC. It is too early to tell, and this new landing page is not explaining much.”

In June of 2022, I followed up that post with a discussion about another CISA web page, the Coordinated Vulnerability Disclosure Program page. That page described the coordination process and concluded with the following:

To report an IT Vulnerability, please use the form here: https://www.kb.cert.org/vuls/report

That IT Vulnerability reporting page includes a link for “Report an ICS/OT Vulnerability” which is the same form I discussed in the April post described above. So, both purely IT and control system vulnerability reporting pages use the same KB.CERT.org (Carnegie Mellon) reporting system.

The point to remember is that KB.CERT is not part of the US government, 44 USC 3507(a) mandates that an “agency shall not conduct or sponsor the collection of information unless in advance of the adoption or revision of the collection of information” the agency goes through ICR publication and comment process outlined in 44 USC 3506(c), that is the process that this notice is initiating.

Public Comments

CISA is soliciting public comments on this information collection request. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket #CISA-2024-0027). Comments should be submitted by December 30^th, 2024.

Commentary

What is not clear in this relatively brief ICR notice is whether CISA is owning up to the ‘sponsorship’ of Carnegie Mellon’s reporting process (see the ‘sponsored by’ notice on the bottom of the KB.CERT.org reporting page) or if CISA is going to be standing up a vulnerability coordination process separate from the MITRE system. From the perspective of a response to this ICR, this is an important distinction. If CISA is simply taking ownership of the MITRE process, then we have public access to the data collection documentation and can appropriately comment on that collection effort and the burden estimate based upon that system.

On the other hand, if CISA is starting a new program from scratch, there is no way that we can comment on the appropriateness of, for instance, the estimate of 10 minutes per response upon which the burden estimate is predicated. We would need to see a copy of the reporting format to be able to judge the accuracy of the estimate.

In either case, CISA has not provided, in today’s notice, the basis for their estimate of 2,725 ‘respondents’ per year. Presumably, this is based upon the agency’s experience with MITRE’s Vince process, but I have a nit-picking complaint, the use of the term ‘respondents’ implies that 2,725 unique individuals will be making a single 10-minute report to CISA in a given year. I think that the more appropriate term would be ‘responses’; the number of unique individuals involved in this reporting process is not important.

Unfortunately, CISA’s burden estimate is missing a very important component. If CISA is going to be coordinating the vulnerability disclosure, they are also going to be receiving responses from the vendors of the vulnerable devices or programs. Even if CISA ignores the mitigation development effort in this ICR (which is totally reasonable in my opinion) there are still going to be required responses from the vendors, frequently multiple coordination-responses for a given reported vulnerability. I would not like to be responsible for developing a reasonable estimate of the average number of responses that would be involved for each coordination effort, but I would bet that CISA has internal documentation of the vendor communications that is has received as part of their coordination efforts. That information could be used to provide a reasonable burden estimate.

There is one final component of this information collection effort that I would like to see included (but do not really expect to happen) is the preparation of vendor vulnerability advisories. Ultimately, the users of these vulnerable systems need to understand how the exploitation of these vulnerabilities would affect their use of the affected systems, so they can properly conduct a hazard analysis to prioritize their mitigation efforts.