Figure 8.3 The right people.
Figure 8.4 SDL A1–A5 activities and best practices.
232 Core Software Security
core activities and best practices, we have added the activities and best
practices highlighted in Figure 8.1. Given the continued pressure to do
more with less, we don’t believe most organizations will have the luxury
of having most of the elements of PRSAs 1–5 as separate organizations
but will need to provide for innovative ways to include them in their over-
all software security program to optimize the leverage of use of available
resources. Sections 8.2–8.6 of this chapter will provide our approach to
the activities and best practices required to make this a success in every
organization in which it is appropriate.
8.2 PRSA1: External Vulnerability
Disclosure Response
One of the key elements of our post-release methodology is that the
typical Product Security Incident Response Team (PSIRT) function can
be a shared responsibility within our proposed leveraged organizational
structure for software security and privacy that covers responses to both
post-release security vulnerability and privacy issue discoveries. No mat-
ter how good your software security program and associated SDL is,
the fact is that something will be missed at some point, and you need a
plan to respond to this. Most important, if discovery of software secu-
rity vulnerabilities and privacy issues in post-release software products
is a common occurrence, that is a clear sign that building security into
the organization’s SDLC through an SDL-like process is weak or non-
existent. Such weakness can result in negative visibility due to publically
disclosed exploitation of vulnerabilities or security flaws inherent to the
post-release software, subsequent loss of market share due to brand defa-
mation, lawsuits or breach of contracts, and a resultant major target for
further exploitation by adversarial opportunists.
Based on our experiences, we cannot emphasize enough how impor-
tant it is to have a single group that acts a focal point of all communica-
tions with customers about security vulnerabilities. Often we have seen
at least three different groups communicating with customers: customer
support, sales, and an information security group. PSIRT may or may not
be part of the information security organization in a particular company,
though this is certainly desirable. To summarize, a clearly defined chain
of communications with customers is of critical importance to prevent
Post-Release Support (PRSA1–5) 233
disclosure of unintended information and to avoid panic and putting
entire accounts at stake.
8.2.1 Post-Release PSIRT Response
In relation to software security, a Product Security Incident Response
Team (PSIRT) is responsible for responding to software product security
incidents involving external discoveries of post-release software product
security vulnerabilities. As part of this role, the team manages the investi-
gation of publicly discovered security vulnerabilities of their company’s
software products and the systems they interact with. The external dis-
coverers might be independent security researchers, consultants, industry
organizations, other vendors, or benevolent or possibly even nefarious
hackers who identify possible security issues with software products for
which the PSIRT is responsible. Issues identified are prioritized based on
the potential severity of the vulnerability, typically using the CVSS scor-
ing system described earlier in the book as well as other environmental
factors. The resolution of a reported incident may require upgrades to
products that are under active support from the PSIRT’s parent company.
Shortly after its identification and during the investigation of a claim of
vulnerability, the PSIRT should work collaboratively with the discoverer
to confirm the nature of the vulnerability, gather required technical infor-
mation, and ascertain appropriate remedial action.
When the initial investigation is complete, the results are delivered
to the discoverer along with a plan for resolution and public disclosure.
If the incident reporter disagrees with the conclusion, the PSIRT should
attempt to address those concerns.
The discoverer(s) will be asked to maintain strict confidentiality until
complete resolutions are available for customers and have been published
by the PSIRT on the company’s website through the appropriate coordi-
nated public disclosure typically called a security bulletin (SB). During
the investigation and pre-reporting process, the PSIRT coordinates com-
munications with the discoverer, including status and documentation
updates on the investigation of the incident. Further information may also
be required from the discoverer to validate the claim and the methods
used to exploit the vulnerability. Discoverers will also be notified that
if they disclose the vulnerability before publication by the PSIRT, then
234 Core Software Security
the discoverers will not be given credit in the public disclosure by the
company and the case will be treated as a “zero day,” no-notice discovery
that has been reported publically by an external source. In the case of a
zero-day discovery, the PSIRT and development teams work together to
remediate the vulnerability as soon as possible, according to the severity of
the Common Vulnerability Scoring System (CVSS) (http://nvd.nist.gov/
cvss.cfm) scoring for the particular vulnerability. In the case of a zero-day,
highly scored vulnerability, the company PR team will work closely with
the PSIRT to manage potential negative press and customer reaction.
During the investigation of a reported vulnerability, the PSIRT coordi-
nates and manages all sensitive information on a highly confidential basis.
Internal distribution is limited to those individuals who have a legitimate
need to know and can actively assist in resolution of the vulnerability.
The PSIRT will also work with third-party coordination centers such
as the CERT Coordination Center (CERT/CC) (http://www.cert.org/
certcc.html), and others to manage a coordinated industry disclosure for
reported vulnerabilities affecting the software products they are respon-
sible for. In some cases, multiple vendors will be affected and will be
involved in the coordinated response with centers such as CERT. If a
coordination center is involved, then, depending on the circumstances,
the PSIRT may contact the center on the behalf of the discoverers, or
assist them in doing it themselves.
If a third-party component of the product is affected, this will compli-
cate the remediation process because the PSIRT will be dependent on a
third party for remediation. A further complication is that the PSIRT will
have to coordinate and in many cases notify the vendor directly to ensure
coordination with the third-party coordination center and likely direct
involvement with the discoverer. Even though a third-party component
has been used, the assumption is that the owner of the primary soft-
ware product is ultimately responsible for all components of the software,
whether they own them or not.
As mentioned above, PSIRTs generally use the CVSS to assess the
severity of a vulnerability as part of their standard process for evaluat-
ing reported potential vulnerabilities in their products and determining
which vulnerabilities warrant external and internal reporting.
The CVSS model uses three distinct measurements or scores that
include base, temporal, and environmental calculations, and the sum of
all three scores should be considered the final CVSS score. This score
represents a single moment in time; it is tailored to a specific environment
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.