6 Core Software Security
The cost associated with addressing software problems increases as the
lifecycle of a project matures (see Figure 1.1). In 1988 Barry Boehm stated
that defects found in the field cost 50–200 times as much to correct as
those corrected earlier.
11
Years later, Boehm stated that this ratio was 5:1
for small noncritical systems.
12
Data presented by Fortify in 2008 indicate
that the cost of correcting security flaws at the requirements level is up
to 100 times less than the cost of correcting security flaws in fielded soft-
ware.
13
No matter what numbers are used, it is clear from the references
above and others used in industry that there are substantial cost savings
to fixing security flaws early in the development process rather than fixing
them after software is fielded. For vendors, the cost is magnified by the
expense of developing and patching vulnerable software after release and
can be a costly way of securing applications. Furthermore, patches are not
always applied by owners/users of the vulnerable software; and patches
can contain yet more vulnerabilities.
14
We have seen patches that fix one
security problem but open (or re-open) other security issues. Companies
are not always able to give each patch (fix) the attention it deserves, or it
may not go through the regular software development cycle, resulting in
more security problems than the patch/fix is designed to mitigate.
For a number of years, the information security industry has focused
on network and application security, assuming that software is secure and
their security controls are all that is needed instead of actually protect-
ing organizations against software security failures. As we review the secu-
rity development lifecycle and its associated best practices in this book, it
should be clear that the network and application should come later in a
comprehensive and layered defense-in-depth security program, and that
software security should be considered the first step in the information
security lifecycle, not the last. In a nutshell, network and application secu-
rity programs are more about compensating controls, but it is only through
addressing security at the source that we can really address problems.
1.2 Software Security and the
Software Development Lifecycle
One significant area of confusion in the security industry over the years
has been a misunderstanding of the difference between software security
and application security. Gary McGraw has provided an excellent descrip-
tion of the difference between the two:
Introduction 7
On one hand, software security is about building secure soft-
ware: designing software to be secure; making sure that software
is secure; and educating software developers, architects, and users
about how to build security in. On the other hand, application
security is about protecting software and the systems that soft-
ware runs in a post facto, only after development is complete.
15
Software security has come a long way since first attacks on a rea-
sonably large scale started to materialize toward the end of the 1980s.
Software back then was written without much thought for security (e.g.,
UNIX code, TCP/IP stack). After the advent of Microsoft Windows and
then the Web, attacks started increasing in sophistication and frequency
and thus it became necessary to look at software security. Industry started
to look for short-term fixes through various “add-ons.” These resulted in
anti-virus, firewalls, anti-spyware, and so on. However, the real issue—
how code was being developed and written—was not addressed. This
started to change only in the last decade when SDL practices started to
be taken seriously. Many enterprises impacted by software security defects
(e.g., Microsoft) started to look seriously at how to build security in soft-
ware code by improving software development practices. This resulted in
recommended SDL practices from academia and software giants such as
Microsoft. We now had the theory and guidelines on how to build secu-
rity into the code from the start and thus lessen the possibility of software
loopholes that could be exploited by attackers.
Confidentiality, integrity, and availability are the three primary
goals that the industry considers to be of the utmost importance in any
secure software development process. What the developers do to protect,
enforce, and ensure these primary goals will equate to the “justifiably
high confidence” part of the secure code definition. A developer can write
very efficient code that is easy to maintain and reusable; however, if that
code allows an unauthorized user to access the application’s assets, then
that code is either exposed or it is not, and there is no second chance for
getting it right.
SDLs should not be confused with the standard software develop-
ment lifecycle. SDL methodology, as the name suggests, is really aimed
at develop ing secure software, not necessarily quality software. As defined
in the IT Law Wiki, the “Security Development Lifecycle is a soft-
ware develop ment process used to reduce software maintenance costs
and increase reliability of software concerning software security related
8 Core Software Security
bugs.”
16
In January 2002, many Microsoft software development groups
prompted “security pushes” to find ways to improve existing security
code. Under this directive, the Trustworthy Computing (TwC) team
formed the concepts that led to the Microsoft Security Development
Lifecycle. Established as a mandatory policy in 2004, the Microsoft
SDL was designed as an integral part of the software development pro-
cess at Microsoft.
17
The term SDL has been used by others since then
both for representing the Microsoft process and as a generic term for
the process defined in the IT Law Wiki link above. Our use of the term
SDL throughout this book will be to represent a secure development
process composed of software security best practices based on compara-
tive research on Microsoft’s SDL and alternative models developed since
2004, the authors’ experience and research into what does and does
not work in most current development organizations, and the business
realities of today’s development austerity requirements coupled with the
increasing demands for securing code at the source with relevant, cost-
effective, and realistic software security practices.
The goals of SDL are twofold: The first goal is to reduce the num-
ber of security vulnerabilities and privacy problems; the second goal is to
reduce the severity of the vulnerabilities that remain. There are industry
standards that define what needs to be done in software development,
such as ISO/IEEE which define the primary phases of a traditional soft-
ware development approach to software engineering. The elements of an
SDL are typically very adaptive and are incorporated into the standard
development lifecycle for an organization.
Static analysis and threat modeling are among the tools used to
develop secure code. Static analysis tools look for a fixed set of patterns
or rules in the code in a manner similar to virus-checking programs.
While some of the more advanced tools allow new rules to be added to
the rule base, the tool will never find a problem if a rule has not been
written for it. The greatest promise of static analysis tools derives from
their ability to automatically identify many common coding problems.
Unfortunately, implementation bugs created by developer errors are often
only part of the problem. Static analysis tools cannot evaluate design and
architectural flaws. They cannot identify poorly designed cryptographic
libraries or improperly selected algorithms, and they cannot point out
design problems that might cause confusion between authentication and
authorization. They also cannot identify passwords or magic numbers
Introduction 9
embedded in code. Static analysis tools can, however, peer into more
of a program’s dark corners with less fuss than dynamic analysis, which
requires actually running the code. Static analysis also has the potential to
be applied before a program reaches a level of completion at which testing
can be meaningfully performed. The earlier security risks are identified
and managed in the software development lifecycle, the better.
While these SDL practices have been good in theory, when applied
to enterprises, results have been mixed. There are multiple reasons for
this. Legacy code still forms a large codebase of our software industry, so
going back in time and applying these practices is very difficult. Software
outsourcing or off-shoring is another area where these practices are dif-
ficult to implement efficiently. Software developers and companies often
work under tight deadlines to put a product out before competition,
and thus software security has typically taken a back seat. There is a lack
of management commitment to effectively implement SDL practices in
such a fast-moving environment where software security is often done as
an afterthought.
Even though some security practices are common to both software and
application security, such as penetration testing, source code scanning,
security-oriented testing, and security education, there is no substitute for
integrating security into the software development lifecycle. The human
element of the process is key to the success of any security development
process and requires very seasoned software security architects and engi-
neers to be successful. Threat modeling, applying principles such as least
privilege and defense in depth, is perhaps the most understood, important,
and needed element of the software development lifecycle and requires
human expertise and not tools to accomplish. One must also gather the
real security requirements for a system and consider compliance, safety
issues, contractual requirements, what data the application will process,
and business risk.
Training is another critical element of the SDL that requires the
human element. Training helps to reduce the cost of security, and an
effective training program will motivate your development team to pro-
duce more secure software with fewer problems with more efficiency and
cost effectiveness. It should be emphasized that no point solutions will
provide a single solution for software security; rather, a holistic defense-
in-depth approach is required, including a blend of people, process, and
technology with a heavy emphasis on people. Although tools can parse
10 Core Software Security
through large quantities of code rapidly, faster than a human could, they
are no replacement for humans. For the foreseeable future, software secu-
rity will still be considered an art, but the art can be augmented through
process and technology and, contrary to myths perpetrated by some prac-
titioners, the art can be taught through proper mentorship by seasoned
software security architects and engineers. These are the team members
who have the experience, can think like an adversary, and do it through-
out the development process, which is a key element for the success of any
SDL. Some authors differentiate between secure-coding best practices
and secure-design principles; we will address both in the software security
best practices presented in this book and leverage the experience of the
seasoned architects and engineers identified above to accomplish this.
Software security requires a focused effort to be successful and is not
a natural outcome of conventional software development processes, even
from development groups that have good traditional “quality” practices.
Software security, however, should be a key of a mature quality program.
As we will explain in this book, secure code does not necessarily mean
quality code, and quality code does not necessarily mean secure code, but
the foundation of software applications and the development processes
that produce them should be based on common best practices of both
quality code and secure code.
1.3 Quality Versus Secure Code
The foundation of software applications, and the development pro-
cesses that produce them, is based on the common best principles of
quality code and secure code. These principles are the driving force
behind the concepts and design of industry best practices. To produce
secure code that will stand the test of time, you must learn how to
incorporate these principles into the development process. Remember
that secure code is not necessarily quality code, and quality code is not
necessarily secure code.
18
Secure code does not mean quality code: You must know how to write
quality code before you can write secure code. A developer can write very
secure code that authorizes and authenticates every user transaction, logs
the transaction, and denies all unauthorized requests; however, if the code
does not return expected results, then even this very secure code may
never see the light of day. Software quality characteristics are not the same
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.