Security Vulnerability Reporting Policy - RFP

n.runs professionals GmbH Security Vulnerability Reporting Policy details how n.runs professionals GmbH manages the public reporting of security vulnerability information we hold to computer industry vendors, our customers and the public. This policy intends to enable all parties to understand and address vulnerabilities expeditiously in their environment and to minimize the risks that vulnerability information poses.

n.runs professionals GmbH Security Vulnerability Reporting Policy November 3, 2003


PURPOSE:

This policy details how n.runs professionals GmbH manages the public reporting of security vulnerability information we hold to computer industry vendors, our customers and the public. This policy intends to enable all parties to understand and address vulnerabilities expeditiously in their environment and to minimize the risks that vulnerability information poses.

The goals of the policy are:
To assist in the identification and remediation of vulnerabilities in a manner which is effective and efficient for all parties. To minimize the risk to all parties from such vulnerabilities. To provide all parties with information that supports independent corroboration of these vulnerabilities. To provide the security community with the information necessary to learn from these vulnerabilities and thus identify, manage, and reduce the risks of future vulnerabilities in information technology as may occur. To minimize the amount of time and resources that all parties would otherwise be required to manage these vulnerabilities. To facilitate long-term research and development of techniques, products, and processes for understanding, avoiding or mitigating security vulnerabilities. To circumvent such antagonism as can sometimes arise in the absence of a formal disclosure policy such as this one.

PROCESS OF VULNERABILITY REPORTING:
The basic steps of the n.runs professionals GmbH Security Vulnerability Reporting Process, with details in the subsequent section of this document, are below. These steps are aspirational in nature, and while n.runs professionals GmbH will attempt to follow them and encourages the other parties involved to follow them, there can be no guarantees that differing factual situations will not affect any parties' implementation of the process:

Discovery:
n.runs professionals GmbH discovers a security vulnerability ("The Flaw") either by accident or while working on specific security research.

Notification:
n.runs professionals GmbH notifies the vendor of the product that contains the Flaw ("Initial Notification"). In turn, the vendor provides n.runs professionals GmbH with evidence that the Initial Notification was received ("Vendor Receipt").

Validation:
The vendor tries to verify and validate n.runs professionals GmbH claims ("Reproduction").

Resolution:
The vendor tries to identify where the Flaw resides ("Diagnosis"). The vendor develops a patch or workaround that eliminates or reduces the risk of the vulnerability ("Fix Development"). The Fix Development is then optionally tested by n.runs professionals GmbH to ensure that the Flaw has been corrected ("Patch Testing"). n.runs AG notifies the vendor of the outcome of the Patch Testing.

Release:
In a coordinated fashion, the vendor and n.runs professionals GmbH publicly release information about the vulnerability, along with its resolution ("Security Advisory"). The vendor may initially release this information to its customers and other organizations with which it may have special relationships ("Limited Release").

POLICY:
The following describes how n.runs professionals GmbH intends to operate during each phase of the n.runs professionals GmbH Security Vulnerability Reporting Process.

Phase 1:
Discovery n.runs professionals GmbH will validate its findings and draft a written Vulnerability Summary Report. The written report will include succinct examples to enable the owner/vendor/developer ("vendor" hereafter) to quickly assess the potential flaw. Where possible, n.runs professionals GmbH will ascertain whether or not the vulnerability is previously known. The Vulnerability Summary Report will include:

High-level non-technical description of what was discovered and the potential scope of risk in plausible settings Detailed technical description including versions of the product(s) tested, the platform(s) used, and step-by-step instructions for reproducing the issue

Phase 2:
Notification and Acknowledgement Upon internal validation and summary of the potential flaw, n.runs professionals GmbH will inform the vendor via an email, which will include the Vulnerability Summary Report. n.runs professionals GmbH will record the initial notification date. The email sent to the vendor will also reference this document (http://www.nruns.com/rfp/policy.html). PGP will be used to encrypt all email if an encryption key is provided by the vendor.

If n.runs professionals GmbH is not able to identify the appropriate security-related email address for that vendor, an email will be sent to one or more of the following contacts if available from the vendor's Web site:

the official domain contacts for the vendor sales@ info@ support@ security@, and secalert@. Once the notification is sent by n.runs professionals GmbH, n.runs professionals GmbH will expect a response by email, not from a mail bot, from the vendor within 7 days that:

acknowledges that they have received and read the n.runs professionals GmbH Security Vulnerability Reporting and describes any plans to address what is described in the n.runs professionals GmbH Security Vulnerability Reporting.

Phase 3:
Validation During this phase, it is anticipated that the vendor will attempt to address the vulnerability. The following is a list of suggestions for vendors to ensure that the resolution is satisfactory for their customers. These suggestions are expressed as "should" consistent with n.runs professionals GmbH understanding of best practices at this time.

If the vulnerability is found in a supported product, the vendor should reproduce the vulnerability, determine if there is enough evidence for the existence of the vulnerability if it cannot be reproduced, determine if the vulnerability is already known (and possibly already resolved), or work with n.runs professionals GmbH or other security experts to determine if the vulnerability is related to the specific environment in which it was discovered (including configuration errors or interactions with other products). As resources permit, n.runs professionals GmbH will help the vendor with the validation phase when requested.

If the vulnerability is found in an unsupported or discontinued product, the vendor may refuse to validate the vulnerability. However, the vendor should undertake measures to ensure that the reported vulnerability does not exist in supported product versions or other supported products based on the vulnerable product. The vendor should examine its product to ensure that it is free of other problems that may be similar to the reported vulnerability. Related vulnerabilities in the same product are often found by others after a specific vulnerability is publicly disclosed. Finding multiple vulnerabilities up front during the validation phase saves the vendor and customers time and money by minimizing the need to create and install multiple patches.

The vendor should provide status updates to n.runs professionals GmbH every 7 days. The vendor and n.runs professionals GmbH may come to an agreement for sharing less frequent updates. The vendor should notify n.runs professionals GmbH when they are able to reproduce the vulnerability. The vendor should attempt to resolve the vulnerability as described in phase 4 within 30 days of initial notification.

There are valid reasons why vulnerabilities cannot be resolved within this time period. If a good faith effort is being made by the vendor to validate the vulnerability, n.runs professionals GmbH will delay the public disclosure of information about the vulnerability until a resolution is found or created. If the vendor is aware of other vendors that share the same codebase as the affected product, the vendor should either (1) notify those vendors, or (2) notify a vulnerability coordinator, such as CERT/CC, that other vendors may be affected by the reported vulnerability.

Phase 4:

Resolution The resolution of a vulnerability should involve action regarding one or more of the following:

patch creation recommendation of configuration change design change workaround During this phase, n.runs professionals GmbH recommends that the vendor should:

Identify the fundamental nature of the flaw within the source code or in the design of the product ("Diagnosis"). Determine whether to

provide a patch, configuration change, or workaround that appropriately reduces or eliminates the risk of the vulnerability ("Fix Development"), or

provide n.runs professionals GmbH with specific reasons for their decision to pursue an alternative to fixing the vulnerability

Request time extensions from n.runs professionals GmbH when necessary. Test the patches, configuration changes, and workarounds sufficiently to clarify how it might or may not adversely affect the operation of the product Provide n.runs professionals GmbH with all known configuration changes or workarounds that address the vulnerability ("Fix Development"). The vendor should also provide n.runs AG with any patches so we may optionally conduct our own testing of the fix ("Patch Testing"). This helps us confirm that the vulnerability has been reduced or eliminated. A vendor may have existing policies in place that require that only supported customers have access to this information; these policies should also be communicated to n.runs professionals GmbH by email. If the vendor does not participate in the validation or resolution phases, or if the vendor is unresponsive to n.runs AG, we believe that it is unlikely that the vendor's customers will be fully satisfied.

Phase 5:
Release n.runs professionals GmbH will work with the vendor to create a timetable pursuant to which the vulnerability information may be released to n.runs professionals GmbH customers, the vendor's customers and the general public in a coordinated fashion.

However, if the parties cannot agree to a coordinated release of the vulnerability information, n.runs professionals GmbH will honor a "Grace Period" of up to 30 days, during which we will unilaterally release only summary information ("Advance Security Advisory") to the public. The Advance Security Advisory will not include details of the vulnerability in an effort to reduce the likelihood that attackers might exploit the product based on receiving the new vulnerability information.

n.runs professionals GmbH will take every effort to describe or publish workarounds, configuration changes, or even patches where this information is not available from the vendor. After the expiration of the 30-day grace period n.runs professionals GmbH will publicly release the full Security Advisory.

If the vendor has not resolved the vulnerability within the timeframe determined in the this Release Phase, then n.runs professionals GmbH may work with a coordinator, such as CERT/CC (http://www.cert.org) to announce the vulnerability to customers and the public. If another reporter has publicly announced the vulnerability before the release date agreed to by n.runs professionals GmbH and the vendor, n.runs professionals GmbH may immediately share details of the vulnerability with its customers who might be exposed to the newly public vulnerability.

n.runs professionals GmbH public release ("Security Advisory") will contain the following information:

Advisory Name: a descriptive name Release Date: the date the Security Advisory is released to the public Product: the name of the vulnerable product(s) with the specific affected versions Platform: the operating system(s) or other platform information Severity: A one-line description of the severity such as "remote execution of code" or "local privilege escalation". Author: the author or authors of the Security Advisory Vendor Status: information about the anticipated availability of a bulletin or patch from the vendor CVE Candidate: CVE candidate vulnerability reference number (information regarding CVE is available at cve.mitre.org). Reference: a URL to the security advisory within the archives on the n.runs professionals GmbH web site Overview: an executive overview of the vulnerability. Details: The details may contain some or all of the following: a description of how the vulnerability presents itself, components and configurations that are affected, mitigating factors, workarounds or configuration changes to resolve the vulnerability, and/or preventative measures for similar problems in the future. Vendor Response: n.runs AG will include vendor information, if provided, such as a brief statement, a link to a security bulletin or patch information in our public release. This makes it easier for customers to find the information they need in order to address the vulnerability in their environment Recommendations: n.runs AG will recommend available courses of action for customers to eliminate or mitigate the vulnerability in their environment. The customer must decide the course of action, if any, which is best for their environment. This section will include one or more of the following: vendor patch information, configuration changes, additional software or hardware protection methods, methods for detecting and finding vulnerable systems. Disclosure Policy: a link to this document and other disclosure policies pertinent to this vulnerability reporting process. Signature Information: a link to the key used to sign the Security Advisory on the n.runs professionals GmbH web site.

REFERENCES:
Portions of this policy are based on "Full Disclosure Policy (RFPolicy) v2.0" by Rain Forest Puppy and @stake Security Vulnerability Reporting Policy - updated June 5, 2002 by @stake Inc.

SUGGESTIONS FOR VENDORS:
Vendors should provide a security contact address on their web site and make it easy to find. Vendors should set up a security response process to respond to security issues in a timely manner. Vendors should incorporate lessons learned into training for their security, IT, product and marketing organizations.

Vendors should notify customers that someone has reported a problem, present a temporary work-around and/or tell customers that they are working to provide a final resolution.

Vendors should clearly notify customers and the public when a resolution is (a) faulty, or (b) revised. Vendors should credit the reporter who notified them of the vulnerability if the reporter was working to responsibly protect customers.

Vendors should create and communicate a vulnerability response policy which details how they respond to and assess reports of vulnerabilities, how long customers should expect to wait for a typical resolution, and information about vulnerability reporting standards, if any, that they follow.

SUGGESTIONS FOR CUSTOMERS:

The customer must not assume that the lack of details in a public vulnerability report will prevent the creation of an exploit.

If a vendor has released information regarding a vulnerability, then the customer should assume that the information is credible. The customer should not require that the vulnerability be demonstrated before applying the resolution.

If a vendor has not released such information, but a well-established reporter or coordination center has, then the customer should assume that the information is credible. The customer should not require that the vulnerability be demonstrated before applying the resolution.

If vulnerability information has been released and a grace period exists, then the customer should apply the resolution to its system during the grace period immediately.

Where possible, the customer should test any patches, configuration changes, or workarounds on test systems before making the changes in an operational environment.

The customer should inform the vendor and the public if a patch, configuration change, or workaround does not appear to work as described.

The customer should give preference to products whose vendors follow responsible disclosure practices.

n.runs professionals GmbH Security Vulnerability Reporting Policy details how n.runs AG manages the public reporting of security vulnerability information we hold to computer industry vendors, our customers and the public. This policy intends to enable all parties to understand and address vulnerabilities expeditiously in their environment and to minimize the risks that vulnerability information poses.

© n.runs professionals GmbH

fon: +49 (0) 6171 / 699-0
fax: +49 (0) 6171 / 699-199
contact(at)nruns.com

website relaunch by attentio