Comments from the U.S. Department of Transportation (CISO + All)

[aro-usdot]

• The BOD should be clarified to either explicitly include or exclude government legacy sites/services/applications hosted on .ORG, .COM, and .NET domains, and the sources from which any inventory of candidates domains and sites would be drawn for evaluation by researchers.
• The BOD should be clarified to address whether sites/applications operated under cooperative agreements with SLTT, private sector partners, universities and research centers, or grantees are within scope for assessment, reporting, and remediation.
• Title - The title of the document “Develop and Publish a Vulnerability Disclosure Policy” is misleading. It indicates that agencies have to disclose vulnerabilities on their systems, while the BOD is meant to address acceptance of report of a discovered vulnerability to an agency by/from a third party. We suggest renaming the BOD to “Develop and Publish a Policy for External Entities to Report Vulnerabilities to an Agency”.
• Introduction (Editorial) - Modify the sentence "Additionally, setting clear baselines across the Executive Branch offers equivalent protection and a more uniform experience for those who report vulnerabilities." TO: "Additionally, setting clear baselines across the Executive Branch is intended to offer equivalent protection and a more uniform experience for those who report vulnerabilities."
• p.1 - Introduction (Editorial) - Revise to clarify that "their systems" means "agency systems" so as not to confuse with systems of the third parties. Provide USC or OMB policy reference.
• p.2 - Introduction (Policy) - We would recommend clarifying the universe of agency systems to which this policy is intended to apply. The statement at the top of page 2 suggests that this document is intended to have a narrow focus on systems that provide online services to private entities and individuals: "Vulnerability disclosure policies enhance the resiliency of the government’s online services by encouraging meaningful collaboration between federal agencies and the public." It is our understanding from interagency discussions, however, that this document is intended to all agency systems that are required to comply with DHS-developed BODs under 44 USC 3554(a)(1)(B)(ii). We would recommend clarifying the intended scope of the BOD.
• p.2 - Background (Policy) - Recommend adding the following sentence to the end of the first paragraph in the Background section to broaden the perspective of the document beyond just network defense: "In some cases, fixing vulnerabilities also protects people's physical safety and the efficient operation of infrastructure, such as transportation systems, on which the public relies."
• p.2 - Background (Policy) - This sentence seems to have a different focus, i.e. "public safety," from the "resiliency of the government's online services" discussed at the top of page 2. We would recommend clarifying the universe of agency systems to which this document is intended to apply and what policy goals it is trying to achieve. Also, public safety-related vulnerability disclosures that Sector-Specific agencies receive are likely to include (and may predominately be comprised of) reports of vulnerabiliites that exist in the sector for which the SSA is responsible that may not involve the SSA's own systems but may require other action on the SSA's or another agency's part to protect public safety. We would recommend that agencies specifically address handling of misdirected reports so that they are routed to the right office or agency in their policies and procedures.
• p.2 - Background (Editorial) - The are additional scenarios. We suggest adding a statement that says these are a few of the possible situations that someone may encounter without the reporting process.
• p.2 - Background (Critical) - Change “vulnerability disclosure policy” to “Public vulnerability reporting policy”
• p.2 - Background (Critical) - The types of testing that are allowed could be in conflict with specific legal or regulatory requirements to take (legal) action when such access / actions occur. Recommend that DHS consult with OMB and DOJ on language to insert requiring legal and regulatory analysis by Department/Agency Counsel to ensure that any sites/applications included within the program are in fact eligible without consequence, or recommending potential changes to law or regulation to make such sites/applications eligible.
• p.4 (Critical) - Change title from: “Develop and Publish a vulnerability disclosure policy” TO: “Develop and Publish a Public vulnerability reporting policy”
• p.4 (Other) - The language provided is self-contradictory. If someone reports a vulnerability anonymously, the Anonymous submission will not receive reports on resolution as required in 8.b) iii because there is no/insufficient information to provide a response.
• p.4 (Resourcing) - Fifteen business days from publication of this document may not provide sufficient time for Departments/Agencies to ensure that they have adequate staff, and legally sound processes and procedures, in place to handle these reports.
• p.4 (Definition) - In the statement "Before the publication of a vulnerability disclosure policy, an agency must have the capability to receive unsolicited reports about potential security vulnerabilities." What constitutes the ability to receive unsolicited reports about potential security vulnerabilities? Is that capability defined somewhere, or can it be acquired as a commercial service offering? Under what terms? Are such services required to be FedRAMP authorized?
• p.4 (Definition) - We would recommend defining "internet-accessible production system or service," as that term is used in this policy.
• p.4 (Editorial) - Are the timelines for agency actions in this section intended to match those in draft OMB memoranda? If so, we would recommend the creation of a single timeline. As currently drafted, the documents reviewed each ground their timelines in their respective dates of publication. While they are probably intended to go final on the same day, it may be useful to those who are referring to the documents in the future for them to reference each other and include a single set of timelines for agency actions.
• p.5 Section 4 - The requirement as written is incorrect for Departments/Agencies operating under multiple domains, and would result in DHS, researchers, and others not seeing the file and associated security directives and attributes for sites/domains not operating under the agency primary .GOV domain. The language should be rewritten to simply require the security.txt file implemented as per the associated Internet Draft, and then examples for various use cases provided as an attachment to the BOD, or as implementation guidance on a supporting Federal CIO Council or DHS site, such as was done for BOD 18-01 and HTTPS/HSTS/TLS.
• p.5 Section 3.a (Critical) - Transparency level should be prudent. Departments/Agencies should be careful about disclosing too much information on how they fix the vulnerabilities or methods used, as this could be use against the agency. A vendor could use this informaitlon to pursuade the agency to buy their product. A hacker could use this informaiton to launch new attacks against the Agency.
• p.5 (Critical) - There seems to be a conflict. Contact information email address and name are considered PII. The minimum contact information is name and email address. How do Departments/Agencies requesting information to enable contacting the reporter violates the prohibition of collecting PII in 3.b) i, and may impede contacting the reporter.
• p.6 (Editorial) - Modify the statement as follows "Within 270 calendar days after the issuance of this directive, and within every 90 calendar days thereafter, the scope of the VDP must increase by at least one internet-accessible system or service until 100% of all applicable systems have implemented the VDP."
• p.6 (Other) - Please clarify - This statement is unclear: "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."
• p.7 (Policy) - It would be helpful to include a brief explanation of what actions CISA may take in the event of agency non-compliance.
• General Comment (Resourcing) - The BOD as written and structured will require additional resources and support to fulfill the requirements, resources which are or may not be available within Department/Agency budgets. We recommend that DHS coordinate with OMB Management on the estimated costs of implementing these requirements and provide budget and investment guidance to agency CFOs and CIOs.
• General Comment (Policy) - The policy seeks voluntary reporting and therefore may be an information collection under the Paperwork Reduction Act, unless an exception applies. DHS/CISA and OMB should evaluate whether an OMB control number is necessary and provide guidance to agencies.
• General Comment (Policy) - Other than indicating that agencies may limit the types of testing that good faith cybersecurity researchers are allowed to perform on any given system, the BOD and the OMB memoranda provide no guidance to agencies or the public on the appropriate balance between the potential benefits of crowdsourced cybersecurity testing and the potential risks of disruptions, which may be unintentional and unforeseen, to agency systems, that support public safety and security and the efficient flow of commerce. It also does not address the interdependencies that exist, in some cases, between one agency's mission and another agency's systems. For example, the FAA's National Airspace System domain systems support the agency's ability to provide safe and efficient air traffic control services and also support the national defense and homeland security missions of our interagency partners. For example, while the FAA has processes and procedures in place to manage cybersecurity risks, the accidental disruption of those systems by a good faith cybersecurity research could potentially result in significant loss of life, injuries, and property damage, and/or substantial economic impacts, that may be similar to the exploitation of the vulnerability by a malicious actor. More specific guidance to agencies about what is expected for systems where such risks may be present and possible alternatives to mitigate those risks in the context of a VDP, would be helpful.
• Question (Policy) - Are systems directly supporting Department/Agency PMEFs and NEFs to be considered within scope of the BOD? If not, we recommend coordination with FEMA and the respective stakeholders to ensure that those outside of the Federal IT/Cyber community have been consulted and their response or input considered in development of the final BOD.
• General Comment (Policy) - As written, the BOD does not account for the FISMA authorities of Agency Heads and CIOs to waive certain requirements, and fully manage (and accept) risks for systems/sites/applications for which they are responsible and accountable. This seems inconsistent with OMB A-130, EO 13800, and other DHS BODs that respect and preserve these authorities for Agency Heads and CIOs.
• Question: Will or are Departments/Agencies able to leverage the vulnerability disclosure policies of FedRAMP authorized cloud service providers without additional enhancement or modification, or must those providers and associated hosted applications be included within the scope of assessment, reporting, and remediation under this BOD?
• Question: Will the FedRAMP PMO be developing model contract clauses and associated modifications to FedRAMP control requirements to support implementation of the BOD for cloud services and cloud-hosted applications?
• Question (Policy): Will Departments/Agencies be required to amend all of their system of records notices to account for potential disclosures of PII that may occur under these programs?
• Question: Is it intended that agencies will need to have a mechanism for communicating with reporters who choose to remain anonymous?
• Question: Public (crowdsourced) penetration testing of federal systems might inadvertently penetrate past the federal systems to penetrate federal contractor systems or entirely private sector systems (air carriers’ systems for example) in violation of federal law, as may have happened in the past. What protections should the Government adopt to assure that crowdsourced penetration testing does not go beyond federal systems?
• Question: Please clarify the intent of the language "What is the level of interaction the reporter is willing to commit?"
• Question (Policy): To what extent is inclusion of systems/sites/applications governed by multi-agency committees or bodies subject to unanimous consent by all parties in the governing body? Or is the determination of inclusion of a system/site/application the sole responsibility of the primary/parent Department/Agency under which it operates and is maintained?
• Question (Policy): To what extent are systems operated by foreign partners, but used or leveraged by Departments/Agencies, within scope of the BOD? To what extent should Departments/Agencies include DoS and DHS in discussions with foreign partners when considering systems for inclusion within scope of the BOD?

[aro-usdot]

(DOT CISO) Additional comment - Large portions of the VDP requirements set forth in the BOD could and should be provided as a (cyber) shared service to Departments/Agencies both for efficiency of implementation and cost, and the consistency of execution and operation.

The envisioned flowing down of requirements, and unfunded mandates with requirements for Departments/Agencies to develop and implement their own solutions, and architect/engineer the appropriate data exchanges/uploads to DHS for visibility and reporting is an approach guaranteed to ensure slow progress, inefficiency and data quality issues.

If the matter of vulnerability management is important, as has been stated, then the fastest way forward is for the Department/Agency with the primary mission - and budget - to do the necessary acquisitions and provide it as a service to other agencies.