Ship (A5): SDL Activities and Best Practices 209
also be managed as an asset, the license obligations observed, and it must
be as secure as internally developed software standards and requirements
require. These sometimes unique and complex license and business risks
can delay, and potentially prevent, software deployment or shipment if
not properly managed. It is essential to be in compliance with applicable
open-source requirements to avoid costly and time-consuming litigation.
The two primary areas that need to be of concern for those managing an
SDL in which open-source software is used as part of the product or solu-
tion are license compliance and security.
1. Open-source software license compliance. Noncompliance with
open-source software licensing requirements can result in costly
and time-consuming litigation, court time, copyright infringe-
ment, public press exposure, bad publicity, and negative risk to the
noncompliant organization’s reputation and business relationships.
Mismanagement and noncompliance with open-source licenses
may also result in difficulty or inability to provide software product
support, delay of current release and ship dates, or the stoppage of
orders currently scheduled to ship.
2. Open-source software security. SDL and development teams, as
well as their executive sponsors, need to be aware of and understand
vulnerabilities associated with open-source software code to be used
in their own software product. As with the software being developed
in-house, all vulnerabilities known to the open-source and software
security community must be identified, assessed, and mitigated
throughout the SDL process and include the same threat modeling,
architectural security and privacy review, and risk assessment rigor
and as the code being developed in-house.
To put this into perspective, a few examples of the consequences of
not properly managing open-source software license or security are given
below.
• Diebold and PES. Artifex Software, the company behind the
open-source Ghostscript PDF processing software, filed a lawsuit
against voting machine vendor Diebold and its subsidiary Premier
Election Solutions. Artifex said that Diebold violated the General
Public License (GPL) by incorporating Ghostscript into commercial
210 Core Software Security
electronic voting machine systems. Ghostscript, which was origi-
nally developed in the late 1980s, is distributed free under the GNU
GPL. This license permits developers to study, modify, use, and
redistribute the software but requires that derivatives be made avail-
able under the same terms. Companies that want to use Ghostscript
in closed-source proprietary software projects can avoid the copy-
right requirement by purchasing a commercial license from Artifex.
Among commercial Ghostscript users who have purchased licenses
from Artifex are some of the biggest names in the printing and
technology industries, including HP, IBM, Kodak, Siemens, SGI,
and Xerox.
1
• Skype. Skype was found guilty of violating the GNU GPL by a
Munich, Germany, regional court. This decision has influenced the
way companies approached GPL compliance since.
2
• Verizon. Two software developers reached a settlement in a lawsuit
against Verizon Communications in which they claimed the tele-
com giant’s broadband service violated the terms of the widely used
open-source agreement under which their product was licensed. The
issue centered on claims that a subcontractor used an open-source
program called BusyBox in Verizon’s wireless routers. As part of the
settlement, Verizon subcontractor Actiontec Electronics must pay
an undisclosed sum to developers Erick Andersen and Rob Landley.
It must also appoint an internal officer to ensure that it is in compli-
ance with licenses governing the open-source software it uses.
3
• Google. Google and other companies continue to receive bad pub-
licity because they use the Android mobile platform, which was
launched with known security vulnerabilities and continues to be
a major target for hackers. Mobile malware tracked by McAfee
exploded in 2012, growing almost 700 percent over the 2011 num-
bers. Close to 85 percent of this malware targets smart phones
running Android. The big surprise in the huge increase is not that
Android is being attacked: Google’s smartphone platform has been
a key focus for the bad guys for some time. The big surprise is that
Google has not managed to stem the tide in any significant way.
Security concerns about Android should not be news to Google, and
Google should be putting security at the top of its list of priorities.
4
• Oracle. Security experts accused Oracle of not paying attention to
its flagship database software and underreporting the severity of a
“ fundamental” flaw. Even as Oracle fixed numerous flaws across
Ship (A5): SDL Activities and Best Practices 211
multiple products in their January 2013 Critical Patch Update, secu-
rity experts criticized the company for the low number of database
fixes and claimed that the company is downplaying the severity of a
flaw in its flagship relational database. As Oracle expands its prod-
uct portfolio and increases the total number of products patched
through the quarterly CPU, there appears to be a “bottleneck”
in Oracle’s patching process. This CPU was the first time Oracle
included the open-source MySQL database, which it acquired in
2010 as part of the Sun Microsystems acquisition.
5
• CNET Download.com. CNET Download.com was caught add-
ing spyware, adware, and other malware to thousands of software
packages that it distributes, including their Nmap Security Scanner.
They did this even though it clearly violated their own anti-adware
policy. (They did remove the anti-adware/spyware promise from the
page.) After widespread criticism of the practice, Download.com
removed its rogue installer from Nmap and some other software,
but the company still uses it widely and has announced plans to
expand it. For these reasons, we suggest avoiding CNET Download.
com entirely. It is safer to download apps from official sites or more
ethical aggregators such as FileHippo, NiNite, or Softpedia.
6
Using manual methods to find, select, monitor, and validate open-
source code is time-consuming, inefficient, and an unnecessary drain on
scarce development team resources. Automation through tools such as
Black Duck Software (www.blackducksoftware.com) or Palamida (www.
palameda.com) is essential to effectively and efficiently incorporate open-
source software into SDLC development efforts to drive down develop-
ment costs and manage the software and its security throughout the SDL.
Black Duck Software’s products and services allow organizations to ana-
lyze the composition of software source code and binary files, search for
reusable code, manage open-source and third-party code approval, honor
the legal obligations associated with mixed-origin code, and monitor
related security vulnerabilities.
7–9
Palamida enables organizations to man-
age the growing complexity of multisource development environments by
answering the question, “What’s in your code?” Through detailed analysis
of the code base, customers gain insight into their code inventory—a
critical component of quality control, risk mitigation, and vulnerability
assessment with the goal of eliminating legal and vulnerability concerns
associated with its use.
10
212 Core Software Security
7.5 Final Security Review
During final security review of software being developed, all of the secu-
rity activities performed, including threat modeling, tools output, and
performance against requirements defined early in the process, are assessed
again to determine whether the software product is ready for release and
shipping. This process will result in one of three outcomes:
1. The final security review is passed. In this case, all final security
review issues that have been identified have been corrected, the soft-
ware is certified to have met all SDL requirements, and it is ready for
release from a security perspective.
2. The final security review is passed with exceptions. In this case,
not all issues that have been identified have been corrected, but an
acceptable compromise has been made for one or more exceptions
that the SDL and development team were not able to resolve. As
exceptions, the unresolved issues will not be resolved in the cur-
rent release and will be addressed and corrected in the next patch or
release.
3. The final security review is not passed and requires an escala-
tion. In this case, the SDL and development team cannot reach a
compromise on a specific security vulnerability and its remediation,
and so the software cannot be approved for release and shipment.
There is typically a business justification identified earlier in the
SDL process that prevents the identified issue from being compliant
with an SDL security requirement. The SDL requirements that are
blocking the release cannot be resolved by the two teams and must
be escalated to higher management for a decision, which of course
will take into account the risk and consequences identified if the
software is released without meeting the requirement. The escalation
to management should be a consolidated report composed by both
the SDL and development teams that includes a description and
rationale of the security risk.
The final security review must be scheduled carefully in order to maxi-
mize the time needed to fully analyze and remediate both known and any
security issues that may be discovered during the final review, in ample
time to account for the software product release and ship dates.
Ship (A5): SDL Activities and Best Practices 213
The final security review process should include the following:
• Scheduling. The product security review must be scheduled so that
all required information from the SDL to complete this step has
been acquired and is available, and enough time has been allowed to
minimize any delay in the release date. The start date cannot be set
until all security review activities defined and agreed to at the begin-
ning of the SDL process have been completed, including in-depth
security vulnerability reviews, threat modeling, and appropriate and
relevant static, dynamic, and fuzz testing tool analysis.
• Specific final security review tasks.
o
The SDL and development team will meet to review and ensure
that satisfactory responses have been made for all questions that
have arisen and documented during the SDL process.
o
Threat models developed earlier in the process have been reviewed
and updated as of the start date of the final security review, to
ensure that all known and suspected threats identified through
the process have been mitigated.
o
All security vulnerabilities have been reviewed against the criteria
established for release early in the process, and at least the mini-
mum security standard has been enforced throughout the SDL.
Any security vulnerabilities that were rejected or deferred for the
current release of the software product must be reviewed as well.
It is important to note that if the SDL and development team is
not constantly evaluating the severity of security vulnerabilities
against the standard that is used during the SDL process, then a
large number of security vulnerabilities may re-appear or be dis-
covered during the final security review and result in unnecessary
and possibly significant use of resources and time, thus delaying
the release of the product.
o
The static, dynamic, and fuzz testing tools should be run before
final security review so that results can be fully evaluated before
a decision is made for final release. In some cases the tools may
provide inaccurate or unacceptable results, in which case you may
need to re-run the tools or find more acceptable alternatives to the
ones used during the process.
o
You must review and ensure that all of the relevant internal secu-
rity policies and external regulatory requirements have been
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.