-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emailed comment from the Department of Energy #114
Comments
TTS mitigates this problem in our Bug Bounty by saying in our policy that "Network denial of service (DoS or DDoS) tests [are not authorized.]" In the years we have been running the program, we have no reason to believe that security researchers have contributed significantly to network load on our systems.
Unless you are providing them with special access, that vetting/determination is not necessary. A vulnerability report is a vulnerability report. The point of a vulnerability disclosure program is to provide a mechanism for good-intentioned actors to make these reports, not to catch malicious actors. |
[Responding to DOE comments 1 and 2]
Perhaps the BOD language could be more clear, but the proposition is straight forward: It is reasonable to suspect that agencies have internet-facing services with vulnerabilities that are unknown to the agency. Risk is a bigger question, primarily due to the wide variety of possible impacts to agency data and missions. Part of the threat factor is also straight forward: Adversaries scan internet-facing services and identify vulnerabilities.
Functional measurement of cybersecurity is admittedly difficult. Falling back to the proposition: Experience from many bug bounty programs and VDPs, including the DOD VDP [1], shows that despite other efforts, internet-facing services are deployed and operated with vulnerabilities. If there is lack of evidence showing that not having VDP has not hindered security, there is data showing that having VDP has improved security, by removing internet-facing vulnerabilities. |
[Responding to DOE comment 3, also partly 8] |
[Comment 12]
Malicious actors are generally not constrained by VDP policy or other law or regulation, so a VDP doesn't affect (increase) exposure to malicious actors. If a VDP removes internet-facing vulnerabilities, that would reduce exposure to malicious actors. Malicious actors can identify, exploit, publish, sell, or tell other parties about vulnerabilities with or without a VDP in place. A VDP is a way to obtain non-malicious actor contributions (and yes, there is cost to operating a VDP, including handling noise in the signal). Does the BOD prevent an agency from running a VDP or bounty program that uses vetted reporters? Assuming that an "open reporter" VDP is also provided? |
[Comments 8 and 13] My interpretation of the BOD is that agencies, including large, complex, and critical agencies like DOE, are directed to incrementally determine their own scope, within the umbrella (and 2 year goal) of "all internet-accessible systems or services." An agency can determine that a third-party system or service is out of scope, primarily because the agency lacks authority to authorize testing on such a system. The BOD points to https://www.justice.gov/criminal-ccips/page/file/983996/download#page=4 |
[Comment 14]
Is this sufficient guidance? |
[1] Given DoD's discovery of 11,000 vulnerabilities through the VDP, it is safe to assume that other agencies have vulnerabilities that could be discovered through a VDP. As a result, this BOD does safeguard systems by protecting against "suspected" vulnerabilities — those that will be discovered by establishing a VDP. [3] DoD has operated a VDP on all its public facing websites since 2016 without exclusion. It seems odd that DOE systems that "interact directly with DoD" should be out of scope when DoD includes those systems in the scope of its VDP. If DOE is concerned about classified material being exposed via an internet-accessible resource, excluding those systems from a VDP does nothing to prevent the exposures. [4] The directive make it clear that a VDP is different from a bug bounty, stating a VDP is "similar to, but distinct from, a “bug bounty”". Such clarifications provided in the guidance are helpful in illustrating the differences between such programs and the reasons why an agency may wish to separately launch a bug bounty. It is entirely up to the agency whether or not to launch a bug bounty program (and indeed, as evidenced by DoD's success with Hack the Pentagon, such programs can be valuable supplements to a VDP). [8] As described by the directive, agencies should determine which components can and cannot be included in their VDP, and should communicate those systems to researchers as such. [10] The directive allows "the agency to be as transparent as possible about what steps it is taking during the remediation process". Given that the reporter discovered the initial vulnerability, sharing remediation information is helpful to receive feedback from the reporter if a fix is incomplete. That said, the directive does already allow such flexibility in communicating with researchers if necessary. [11] As a "see something, say something", a VDP must not restrict participation. DoD has received vulnerability reports from around the world and could not have remediated these flaws without keeping its doors open. The VDP template details how agencies can exclude specific types of testing such as denial of service, and that researchers lose safe harbor if they perform those test types. Vulnerabilities exist whether or not we like them; it is the role of the VDP to identify them at every area possible. [12] The directive states agencies "must not attempt to restrict the reporter’s ability to disclose discovered vulnerabilities to others, with the exception of a request for a reasonably time-limited response period." This makes it clear that there is a timeframe in which reporters cannot share with others, contrary to DOE's statement that "reporters are not precluded from submitting their identified vulnerability to 'others' and can do so at any time". Beyond this timeframe, it is in the interest of all to patch quickly and disclose -- if DOE does choose to "remediate all vulnerabilities immediately" I would consider this a success of the directive in making systems substantially more secure. |
* Critical: Fundamental error or omission, Substantive: Preferred change, Editorial: Grammatical or stylistic
The text was updated successfully, but these errors were encountered: