240 Core Software Security
of resources, and direct knowledge of the software product at
the source through the direct involvement and ownership by the
develop ment teams.
• Direct empowerment of the development teams and project manag-
ers, their more direct ownership of the remediation process, and a
centralized software security group embedded in the engineering/
software development group provide single-organizational responsi-
bility for the response.
• Software security champions and software security evangelists oper-
ate locally with the software product manager and appropriate
product development resources to directly drive the assessment and
remediation (if needed) of the claimed vulnerability by an external
discoverer.
• All the above result in faster time to execution and response and,
most important, help speed up the mitigation of negative press
exposure and customer risk. We believe there is an advantage to our
proposed organizational infrastructure in providing a cost-effective,
minimal resource, and an efficient way to respond to this type of
incident while reducing the burden on resources dedicated to the
development of the software itself.
8.3 PRSA2: Third-Party Reviews
Over the last few years, customers of software vendor have increasingly
requested independent audits to verify the security and quality of soft-
ware applications they have either purchased or are evaluating for pur-
chase. Software vulnerabilities have increasingly been tied to high-profile
data breaches over the last few years and have resulted in more customers
requiring independent and visible proof that the software they purchase
is secure. This, of course, has helped put pressure on companies that
develop software to ensure that the secure software development processes
are built into the SDLC to avoid the very costly discovery of vulnerabili-
ties that are caught post-release—often a sign of an immature, ineffective,
or nonexistent software security program. Because of the preponderance
of post-release code having security vulnerabilities and privacy issues
that should have been caught during development, third-party assess-
ment of post-release or near-release code has become the norm in the
industry, whether the company producing the software has a reputation
Post-Release Support (PRSA1–5) 241
for producing secure code or not. In some cases it is demanded by the
prospective or current customer, and in other cases it is conducted pro-
actively by the company producing the code.
Even for companies that have outstanding software security programs,
software applications can alternate in and out of compliance with poli-
cies or regulatory requirements over long periods of time for a variety of
reasons. For example, a new functionality or use case in a new version
of the application may introduce new vulnerabilities or planes of attack,
causing the application to drop out of compliance. Additionally, these
requirements may change over time. Many companies use third-party
code reviews to help identify these situations rather than spend the lim-
ited resources of their internal teams.
Third-party testing should include testing the entire stack, not just
your product. That means performing testing as outlined in earlier chap-
ters as well as continuous post-release testing. At a minimum, post-release
testing should include annual penetration testing (application and soft-
ware stack). Any new code released after initial release should follow the
SDL requirements outlined in previous chapters.
The biggest challenge is to do this in a timely and cost-effective man-
ner while also protecting the source code and other intellectual property
during the process. Some of the choices for third-party testing include
the following.
1. Hand over source code to a third party for inspection. This is not a real
option for those who want to protect the most precious intellectual
property that a software development organization possesses—their
source code.
2. Contract manual penetration testing services that can also do deep-dive
code and software architectural design reviews for each new release. To
avoid the risk of source code leaving the control of the company
that is developing it, contractors must be required to work onsite in
a controlled environment, under special nondisclosure agreements
and under specific guidelines. These typically include a source-code
protection policy and IP protection guidelines. An alternative to this
approach is to employ a company that only uses tools that require
the exposure of binary code only. In this case, the contractor inspects
the application at the same level as it is attacked, the binaries, and
can ensure that all threats are detected. This type of testing can be
done onsite or remotely as a service.
242 Core Software Security
3. Purchase, install, and train development teams to use on-premise tools
and function as lower-level software security architects as an extension
of the software security group to conduct the “people side” of the software
security architectural review. Then invite auditors into your organiza-
tion to document your processes. Many mature software security
organizations have done this. A mature software security program
such as that described in this book will help scale and reduce the
need for additional headcount to do this work. Building this into
your SDL/SDLC process is a cost-effective, efficient, and manage-
able way to do this.
4. Require third-party suppliers of code in your application to do the same.
In today’s software development environments, a majority of software
development organizations make use of code developed elsewhere,
either Commercial Off-The-Shelf (COTS) or open-source software.
Just as with internally developed software, a third party should prepare
an attestation report per the software application owner’s requirements,
which may include an attack surface review, review of cryptography,
architecture risk analysis, technology-specific security testing, binary
analysis if source code is unavailable, source code analysis if it is, and
fuzz testing in addition to a general pen testing routine.
8.4 PRSA3: Post-Release Certifications
There are numerous security-focused certifications that a software
develop ment team may face after the release of the product that are
added on as a requirement rather than during the development process
for a variety of reasons. These reasons may include use of the software in
industry or government sectors that were not planned for during design
and development, new uses for the software, and new government, coun-
try, regional, business or industry sector, or regulatory requirements that
did not exist prior to the release of the product. Post-release certifica-
tion requirements that did not exist prior to the release of the product
are a forgivable offense, but missing any that are currently required and
were missed early in the SDL are not. Avoiding noncompliance to cer-
tifications required for the use of the software that is being developed
requires either an internal resource in the company dedicated to follow-
ing software use certifications and other requirements, including privacy
requirements, or an individual or organization that specializes in this area
Post-Release Support (PRSA1–5) 243
of experience. This becomes particularly challenging as the number of
these types of certifications and requirements increases rapidly around the
globe. Following is a short list of examples of security or privacy certifica-
tions or standards that could become necessary for a software product to
comply with post-release requirements due to market or use-case changes:
• The Federal Information Security Management Act (FISMA)
6
• Federal Information Standard 140-2 (FIPS 14-2)—Security
Requirements for Cryptographic Modules
7
• The U.S. Department of Defense Information Assurance Certifica-
tion and Accreditation Process (DIACAP)
8,9
• The Health Insurance Portability and Accountability Act of 1996
(HIPAA) (privacy and security rules)
10
• Safe Harbor (privacy)
11
• The Federal Service for Technical and Export Control (FSTEK of
Russia) Certification (Privacy and Security)
12,13
8.5 PRSA4: Internal Review for New Product
Combinations or Cloud Deployments
In our profession, we continue to encounter the misconception that once
software has been through a SDL, you can re-use the software code any
way you want. This presumption is false because any architectural changes
that have occurred after release of a software product will likely introduce
new attack vectors in the previously secure code. For this reason, software
code must be put through the SDL process again when there is a new use
of the software or an architectural change to the code post-release. Any
new code must also be vetted through the various types of security testing
outlined in earlier chapters.
8.6 PRSA5: Security Architectural Reviews
and Tool-Based Assessments of Current,
Legacy, and M&A Products and Solutions
8.6.1 Legacy Code
Although they may have once been viewed as an unnecessary cost bur-
den, the best activities and best practices we have outlined in our SDL
244 Core Software Security
are a consequence of the discovery that security was not always a key
element of the software development process and sometimes led to
security vulnerabilities and risk mitigation costs that rivaled the initial
cost of the software to be developed. The acceptance of legacy code
is based on an assumption of what is expected to happen, in that the
software must be proven to be functionally correct and operationally
viable. However, when it comes to software security, the unexpected
is what typically causes the vulnerabilities. Not only are these security
vulnera bilities financially unacceptable, they are also unacceptable from
an operational, functional, and overall risk perspective. This is particu-
larly true when the software supports embedded critical systems and
applications such as those found in national and regional infrastruc-
tures, transportation, defense, medicine, and finance. In these applica-
tions, the liabilities, costs, mission, and business impacts associated with
unexpected security software and system vulnerabilities are considered
unacceptable. Unless the architecture of legacy software is correctly
assessed and analyzed from a security perspective, the impact of changes
cannot be predicted, nor can changes be applied effectively. This is why
the same testing and review rigor that is followed during the SDL must
be followed during legacy code reviews: as a means of mitigating the
unexpected. If done with the proper process and rigor, this will go far in
ensuring secure code implementation that is consistent between legacy
and new code.
A legacy software application is one that continues to be used because
of the cost of replacing or redesigning it and often despite its poor compet-
itiveness and compatibility with newer equivalents. The most significant
issue in this regard is that the organization has likely been depending on
this legacy software application for some time, and it pre-dates software
development security activities such as those described in our SDL and
the mandates that currently drive these practices. Further, a considerable
amount of money and resources may be required to eliminate this secu-
rity “technical debt.” Technical debt is the difference between what was
delivered and what should have been delivered. The importance of work-
ing with legacy code and technical debt is critical for most companies that
develop software.
14
Legacy code with technical debt can also exist because even though
the product should be have been put in “end of life” status, one or more
customers do not or cannot upgrade to a newer version of the software,
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.