Reorient problem statements to future desired state

Great work! A few suggestions:

Choosing to disclose a vulnerability can be an exercise in frustration for the reporter when an agency has not defined a vulnerability disclosure policy -- the effect being that those who would help ensure the public's safety are turned away:

The reporter cannot determine how to report: Federal agencies do not always make it clear where a report should be sent. When individuals cannot find an authorized disclosure channel (often a web page or an email address of the form security@agency.gov) they may resort to their own social network or seek out security staff's professional or personal contact information on the internet. Or, if the task seems too onerous, they may decide that reporting is not worth their time or effort.

The reporter has no confidence the vulnerability is being fixed: If a reporter receives no response from the agency or gets a response deemed unhelpful, they may assume the agency will not fix the vulnerability. This may prompt the reporter to resort to uncoordinated public disclosure to motivate a fix and protect users, and they may default to that approach in the future.

The reporter is afraid of legal action: To many in the security community, the federal government has a reputation for being defensive or litigious in dealing with outside security researchers. Compounding this, many government information systems are accompanied by strongly worded legalistic statements warning visitors against unauthorized use. Without clear, warm assurances that good faith security research is welcomed and authorized, researchers may fear legal reprisal, and some may choose not to report at all.

I would turn the bold headings in this bullet list into positive Should statements. "The reporter should be able to report" "The reporter should have confidence that the vulnerability will be fixed" "The reporter should not fear legal action"

the substance of the paragraphs is good, perhaps bookend each with a reiteration of the goal: This is how it should be. This is how it is currently and it's bad. This is how it should be different.

Which systems are in scope. At least one internet-accessible production system or service must be in scope at the time of publication.

Would be good to make this more broad, and more specific - e.g., all major systems and websites that will be reported to Congress for 21st Century IDEA need to be included from the get-go.

When agencies integrate vulnerability reporting into their existing cybersecurity risk management activities, they can weigh and fix a wider array of concerns.

I think a VDP should be presented as one tool in the suite of scanning tools used to screen for vulnerabilities on an ongoing basis. If it's taken as another control systems need to satisfy, there may be objections about which baseline applies.

Within 15 business days after the issuance of this directive

This doesn't anticipate the likely lag in communication from when the BOD goes out and when word gets to the relevant POCs for each domain that they need to take action.

A vulnerability disclosure policy facilitates an agency's awareness of otherwise unknown vulnerabilities. It commits the agency to authorize good faith security research and respond to vulnerability reports, and sets expectations for reporters.

I think there's a possibility that agency staff need a complementary policy, internal to the agency, about how the agency will respond to vulnerabilities reported through the VDP. Or the response to VDP-reported issues needs to be incorporated into the larger vulnerability remediation policies, so that system owners know how and when they need to respond.

Create a security.txt[^15] file at the "/.well-known/" path[^16] of the agency's primary .gov domain.

Give a full example path here, there's a possibility that people will not click through, and will misunderstand what's meant by well-known path. Also, please make outbound link straight to the security.txt documentation, rather than burying it in a footnote.

Within 180 calendar days following the issuance of this directive, CISA will begin scanning for security.txt files.

Provide a template for the security.txt file format, so that the files posted will match what the CISA scanners are expecting to find.

Actual, past impact (i.e., not those that occurred in the discovery/reporting of the vulnerability) will be assessed and treated as an incident, as applicable.

Revise to "Actual past incidents related to the reported vulnerability (i.e., not those that occurred in the discovery/reporting of the vulnerability) will be assessed and treated as an incident, as applicable."

cisagov / cyber.dhs.gov

Reorient problem statements to future desired state #95