|
|
.Security Vulnerability Reporting Policy - RFP
n.runs AG 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 AG Security Vulnerability Reporting Policy November 3, 2003
PURPOSE:
This 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.
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 AG 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 AG 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 AG discovers a security vulnerability ("The Flaw") either by
accident or while working on specific security research.
Notification:
n.runs AG notifies the vendor of the product that contains the Flaw
("Initial Notification"). In turn, the vendor provides n.runs AG with
evidence that the Initial Notification was received ("Vendor Receipt").
Validation:
The vendor tries to verify and validate n.runs AG 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 AG 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 AG 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 AG intends to operate during each phase
of the n.runs AG Security Vulnerability Reporting Process.
Phase 1:
Discovery
n.runs AG 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 AG 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 AG will
inform the vendor via an email, which will include the Vulnerability Summary
Report. n.runs AG 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 AG 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 AG, n.runs AG 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 AG Security
Vulnerability Reporting and
describes any plans to address what is described in the n.runs AG 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 AG
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 AG 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 AG 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 AG every 7 days. The
vendor and n.runs AG may come to an agreement for sharing less frequent
updates. The vendor should notify n.runs AG 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 AG 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 AG 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 AG with specific reasons for their decision to pursue an
alternative to fixing the vulnerability
Request time extensions from n.runs AG 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 AG 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 AG
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 AG will work with the vendor to create a timetable pursuant to
which the vulnerability information may be released to n.runs AG
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 AG 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 AG 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 AG 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 AG 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 AG
and the vendor, n.runs AG may immediately share details of the
vulnerability with its customers who might be exposed to the newly public
vulnerability.
n.runs AG's 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 http://cve.mitre.org).
Reference: a URL to the security advisory within the archives on the n.runs AG 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 AG 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 AG 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. |
|
 |
|
|
|
