How to Handle Reports From Security Researchers

TL;DR

Create a clear channel for vulnerability reports, acknowledge each report within seven calendar days, and maintain an internal process for investigation, triage, remediation, and release. Coordinate with finders, perform root cause analysis instead of patching only the reported proof of concept, and publish an advisory identifying affected products, potential impact, and available fixes or mitigations.

Transcript

Okay, good morning, and thank you for joining me for Application Security Response When Hackers Come A-Knockin'. This is the twenty-minute redux version, and we've got a lot of material to cover, so I'm gonna lightly touch through a lot of topics here. Okay. So first of all, uh, we'll go through some introductions, and then I will go through a tale... Read More

Key Insights

• ISO 29147 is a vulnerability disclosure standard that addresses how vendors receive reports from external finders, coordinate with those finders, and communicate resolved issues to users through advisories covering products, online services, and potentially firmware embedded in hardware.
• ISO 30111 is an internal vulnerability-handling standard that applies whether a potential security flaw was reported by an external hacker or discovered through the vendor's own testing. It encompasses investigation, triage, remediation, and the eventual release of an update or other resolution.
• A clear vulnerability-reporting channel is essential because researchers may use unexpected routes, including the media, when they cannot identify a private way to contact a vendor. Suggested entry points include a dedicated security email address or a web form.
• Acknowledgment of a vulnerability report must occur within seven calendar days, according to the presentation. This acknowledgment only confirms receipt and does not mean that the vendor has validated the vulnerability, completed its investigation, or developed a remediation.
• Human acknowledgment is preferable because researchers may invest substantial effort in discovering and documenting a vulnerability. An automated reply can serve as an initial response when resources are limited, provided that a human follows up fairly quickly to begin the working relationship.
• A complete initial report makes vulnerability investigation more efficient because missing technical information creates additional coordination work. Vendors should document the information they need and ask finders to provide as much of it as they are willing and able to share.
• A useful vulnerability advisory is specific enough for users to determine whether they are affected and understand the consequences of successful exploitation. It should include unique identifiers, affected products or services, impact or severity, and instructions for obtaining a fix or applying a mitigation.
• Root cause analysis is necessary because fixing only one proof-of-concept vector may leave the underlying security weakness unresolved. The presentation illustrates the danger with vendors that patch only the demonstrated path, or misunderstand a demonstration so badly that they remove the application launched by the exploit.

Questions & Answers

Q: How should a company receive vulnerability reports?

A company should provide an obvious, documented entry point through which security researchers can submit vulnerability reports privately. The presentation suggests options such as a dedicated security email address or a web form. If researchers cannot find the proper front door, they may resort to unexpected channels, including contacting the media, rather than reporting the issue directly to the vendor.

Q: How quickly should a vendor acknowledge a vulnerability report?

A vendor should acknowledge receipt within seven calendar days. This is the only explicit time limit identified in the two standards discussed in the presentation. The acknowledgment merely confirms that the report arrived. It does not assert that the issue is valid, that an investigation is complete, or that the vendor has already prepared a fix.

Q: Is an automated reply sufficient for a vulnerability report?

A human response is preferable because a researcher may have invested substantial time in finding and documenting the vulnerability, and personal acknowledgment helps begin the relationship well. An automated reply may be acceptable when the vendor lacks resources for an immediate personal response, but a human should follow up fairly quickly to confirm receipt and continue coordination.

Q: What information should a vulnerability advisory contain?

A vulnerability advisory should include a unique identifier, the affected products, platforms, or online services, the issue's impact or severity, and directions for eliminating or mitigating the risk. It should tell users whether they are affected, what a successful attacker could accomplish, and where they can obtain the fix or read the documentation needed to make appropriate changes.

Q: Why does a security advisory need unique identifiers?

Unique identifiers allow users and vendors to distinguish one vulnerability from another and one advisory notice from another. The presentation describes using an identifier for the vulnerability itself, such as a CVE, alongside the vendor's identifier for the advisory. Notice identifiers are particularly useful because a vendor may need to revise the advisory as its understanding or guidance changes.

Q: What is the difference between ISO 29147 and ISO 30111?

ISO 29147 covers vulnerability disclosure, including receiving reports from external finders and disseminating advisories after resolution. ISO 30111 covers the internal process for handling potential vulnerabilities, including investigation, triage, remediation, and release. The internal standard applies to issues reported externally as well as vulnerabilities discovered through a vendor's own testing methods.

Q: Why should vendors coordinate with vulnerability finders?

Vendors should coordinate with finders because an investigation may encounter missing details, reproduction problems, or other snags that require clarification from the person who discovered the issue. Requesting thorough information in the initial report reduces this work, but ongoing communication may still be necessary. The presentation also recommends crediting finders in the final advisory when they choose to reveal their names.

Q: Why is root cause analysis important in vulnerability response?

Root cause analysis helps ensure that remediation addresses the underlying weakness rather than only the exact proof of concept supplied by a researcher. Patching a single demonstrated vector can leave related paths exposed. The presentation gives an extreme example in which an exploit launched Calculator and the vendor merely removed Calculator, mistaking the visible demonstration for the actual security problem.

Summary & Key Takeaways

• ISO 29147 addresses interactions between vendors and external vulnerability finders. Vendors should publish an obvious reporting channel, request useful technical information up front, acknowledge receipt within seven calendar days, coordinate with the finder during investigation, and eventually disclose enough information for users to understand and reduce their exposure.

• ISO 30111 covers the vendor's internal handling process for vulnerabilities discovered through external reports or internal testing. Its scope includes investigation, triage, remediation, and release. The process should extend existing bug management while adding organizational support for security issues whose timelines and risk considerations may not fit ordinary product development cycles.

• A useful security advisory distinguishes both the vulnerability and its notice through unique identifiers, identifies affected products, platforms, or services, describes what a successful attacker could accomplish, and directs users to a fix or mitigation. Vendors should also credit vulnerability finders when those researchers choose to reveal their names.