Post-Release Support (PRSA1–5) 235
and is used to prioritize responses to a particular externally discovered
vulnerability. In addition, most PSIRTs will consider modifying the final
score to account for factors that are not properly captured in the CVSS
score. PSIRTs typically use the following CVSS guidelines when deter-
mining the severity of a particular vulnerability and the need to report it:
•
High (H)—Critical—CVSS base score of 7.0–10.0
•
Medium (M)—CVSS base score of 4.0–6.9
•
Low (L)—CVSS base score of 0.1–3.9
2
If there is a security issue involving a third-party software component
in the product the PSIRT is responsible for, then, depending on the situa-
tion, and whether the third party has a CVSS score, the PSIRT may use
the CVSS score provided by the component creator and/or may adjust
the score to reflect the impact on the overall software product.
Public disclosure, including the relevant base and temporal CVSS
scores and a CVE ID
3
report, is typically made for an external post-release
discovery event when one or more of the following have occurred:
•
The incident response process has been completed and has deter-
mined that enough software patches or other remediations exist
to address the vulnerability. Public disclosure of code fixes can be
issued to address high-severity vulnerabilities.
•
Active exploitation of a vulnerability that could lead to increased
risk for the PSIRT company’s customers has been observed that
requires a published security vulnerability announcement. The
announcement may or may not include a complete set of patches
or other remediation steps. When possible, compensating con-
trols are included in the public announcement to provide interim
protection that will limit exposure until the permanent fix is
announced.
•
A zero-day announcement or other potential for increased public
awareness of a vulnerability affecting the PSIRT company’s pro-
duct is probable that could lead to increased risk for customers. In
these cases, the PSIRT has worked closely with the company PR
team to help assess public indicators and warnings such as Twitter
feeds and blogs that this exposure is imminent and will have
prepared for a statement ahead of time. Again, this accelerated
public vulnerability announcement will not include a complete
236 Core Software Security
set of patches or other remediation steps, but, ideally, interim
compensating controls to limit exposure can be identified.
A typical step-by-step PSIRT case-handling process will include the
following steps.
1. Notification of vulnerability as assessed by an individual discoverer
or organization is received.
2. The responsible software product development group is identified,
together with resources required for assessment of the discoverers’
vulnerability claim.
3. If the claim is credible, an impact assessment is made and a timeline
for a fix is determined. The level of effort needed and priority to
develop a fix is balanced against the likelihood of public disclosure
of the severity and risk of the vulnerability. In some cases, external
resources may be required due to other critical tasks the develop-
ment team is carrying out. If the claim is not credible, additional
information is requested from the discoverer to ensure the threat was
properly re-created in the testing environment. If it is not credible
after the testing environment has been confirmed, then the discov-
erer is notified of the company’s findings. If the discoverer goes pub-
lic claiming the vulnerability is credible even though the company
has determined it is not, then the PSIRT typically works with the
company’s PR team to publish the results of the company’s finding
as a counter to the discoverer.
4. The timeframe for remediation, the resources needed to fix a con-
firmed vulnerability, and the reporting format (e.g., security bulle-
tin, knowledge base article, or other form of public notification) are
committed to.
5. After patch or other remediation methods have been identified, all
customers are notified simultaneously on the date of the availability
of the fix through the reporting format determined in Step 4.
8.2.1.1 ISO 29147 and ISO 30111
Two International Standards Organization (ISO) standards expected to
be released by the end of the year 2013 relate to the proper functioning
of a vendor PSIRT:
Post-Release Support (PRSA1–5) 237
• ISO Standard on Vulnerability Disclosure (29147)
• ISO Standard on Vulnerability Handling Processes (30111)
The following information is derived from a presentation of Katie
Moussouris at the 2013 Carnegie Mellon CERT Vendor Meeting in San
Francisco.
4
ISO 29147 provides guidance on how vendors should deal with vul-
nerability reports from external finders and the recommended process for
interfacing between vendors and the external discoverers or finders. These
discoverers can be either benevolent or adversarial in nature. In order for
vendor to optimize their ability to respond to externally discovered vul-
nerabilities in their products they should, as a minimum:
• Have a clear way to receive vulnerability reports
• Acknowledge receipt of vulnerability reports within 7 calendar days
• Coordinate with finders
• Issue advisories that contain useful information, as a minimum:
o
Some unique identifier
o
Affected products
o
Impact/severity of damage if vulnerability is exploited
o
How to eliminate or mitigate the issue (guidance or patching
instructions)
o
Consider giving finders credit in the advisory if the finder wishes
to be publicly acknowledged
ISO 30111 provides guidance on how vendors should investigate, tri-
age, and resolve all potential vulnerabilities, whether reported by external
finders or via the vendor’s internal testing. In order for vendors to opti-
mize their ability to respond to discovered vulnerabilities in their prod-
ucts, they should, as a minimum:
• Have a process and organizational structure to support vulnerability
investigation and remediation
• Perform root-cause analysis
• Weigh various remediation options to adjust for real-world risk fac-
tors and balance speed with thoroughness
• Try to coordinate with other vendors if appropriate, such as in cases
involving multi-vendor or supply-chain issues
238 Core Software Security
A detailed five-step process recommended for handling and processing
vulnerability reports is
1. Vulnerability report received
2. Verification
3. Resolution development
4. Release
5. Post release
The overall process is similar for either an external finder or a vulner-
ability discovered as a result of internal testing, but the risks may be dif-
ferent. If an external finder is involved, ISO 29147 should be followed
and it is important to
• Understand the communication expectations
• Take into consideration the finder’s intentions and publication plans
during the resolution-development phase
• Release the remediation via an advisory, as outlined in the processes
defined in ISO 29147
8.2.2 Post-Release Privacy Response
In addition to post-release security issues that may be discovered and dis-
closed, potential privacy issues may also be discovered. In our experience,
privacy-related issues do not get as much attention as security vulnerabili-
ties, nor is a group charted specifically to deal with such issues. A software
development company may have a chief privacy officer (CPO) or equiva-
lent, such as a specialized counsel on retainer, but most do not have a staff
and are likely limited to one privacy support expert at best. This neces-
sitates a close alignment and working relationship between the PSIRT
function and the centralized software security group and the privacy func-
tion of the company, whether the latter is in- or out-sourced. Post-release
privacy response should be built into the PSIRT process just as security
should be built into the SDLC. Given the potential legal nature of privacy
issues or privacy control vulnerability exploitations, the privacy advisor
should script basic talking points, response procedures, and legal escala-
tion requirements for the response team to use to respond to any potential
privacy issues discovered post-release. Some basic guidelines follow:
Post-Release Support (PRSA1–5) 239
• Privacy experts should be directly involved in all incidents that fall
into the P1 and P2 categories described earlier in this book.
• Additional development, quality assurance, and security resources
appropriate for potential post-release privacy issue discovery issues
should be identified during the SDL process to be participate in
post-release privacy incident response issues.
• Software develop organizations should develop their own privacy
response plan or modify the Microsoft SDL Privacy Escalation
Response Framework (Appendix K)
5
for their own use. This should
include risk assessment, detailed diagnosis, short-term and long-
term action planning, and implementation of action plans. As with
the PSIRT responses outlined above, the response might include
creating a patch or other risk-remediation procedures, replying to
media inquiries, and reaching out to the external discoverer.
8.2.3 Optimizing Post-Release Third-Party Response
Collaboration between different teams and stakeholders provides the
best possible chance of success in post-release response. The collective of
software security champions, software security evangelists, and an ongo-
ing formal software security programmatic relationship with the software
development product managers and quality team to support and collabo-
rate with the centralized software security team as proposed in this book
provides several distinct advantages over solely dedicated teams to handle
post-release PSIRT and privacy support:
• Direct PSIRT and privacy response ownership is achieved by imbed-
ding these functions into the engineering and development groups
directly responsible for fixing the product directly affected by the
discovered vulnerability or privacy issue.
• Direct knowledge of the code, architecture, and overall software
product design and functionality with a direct influence on the
remediation process will result in increased efficiency, control,
and response over an external organizational entity without direct
knowledge of the product. Essentially, this removes the middleman
and streamlines the process.
• This process provides for better return on investment for both the
PSIRT and the privacy response function through the leverage
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.