The Secure Development Lifecycle 29
The goal of CVE is to make it easier to share data across separate vulner-
ability capabilities (tools, repositories, and services) with this “common
enumeration.” Information security vulnerability is a mistake in software
that can be used directly by a hacker to gain access to a system or network.
See the Terminology page of the CVE website for a complete explanation
of how this term is used in the CVE. An information security exposure
is a mistake in software that allows access to information or capabilities
that can be used by a hacker as a stepping-stone into a system or network.
Using a common identifier makes it easier to share data across separate
databases, tools, and services, which, until the creation of CVE in 1999,
were not easily integrated. If a report from a security capability incor-
porates CVE Identifiers, you may then quickly and accurately access fix
information in one or more separate CVE-compatible tools, services, and
repositories to remediate the problem. With CVE, your tools and services
can “speak” (i.e., exchange data) with each other. You will know exactly
what each covers, because CVE provides you with a baseline for evaluat-
ing the coverage of your tools. This means that you can determine which
tools are most effective and appropriate for your organization’s needs. In
short, CVE-compatible tools, services, and databases will give you better
coverage, easier interoperability, and enhanced security.
Bugtraq IDs are identifiers for a commercially operated vulnerability
database that are used in security advisories and alerts, as well as for dis-
cussions on the Bugtraq mailing list. CVE Identifiers are from an interna-
tional information security effort that is publicly available and free to use.
CVE Identifiers are for the sole purpose of providing a common name.
For this reason, CVE Identifiers are frequently used by researchers and
the makers of security tools, websites, databases, and services as a standard
method for identifying vulnerabilities and for cross-linking with other
repositories that also use CVE Identifiers. A CVE Identifier will give you
a standardized identifier for any given vulnerability or exposure. Knowing
this identifier will allow you to quickly and accurately access information
about the problem across multiple information sources that are CVE-
compatible. For example, if you own a security tool whose reports contain
references to CVE Identifiers, you may then access fix information in a
separate CVE-compatible database. CVE also provides you with a base-
line for evaluating the coverage of your tools.
The CVE List feeds the U.S. National Vulnerability Database
(NVD), which then builds upon the information included in CVE
entries to provide enhanced information for each CVE Identifier such as
30 Core Software Security
fix information, severity scores, and impact ratings. NVD also provides
advanced searching features such as by individual CVE-ID; by OS; by
vendor name, product name, and/or version number; and by vulnerabil-
ity type, severity, related exploit range, and impact.
CVE is sponsored by the National Cyber Security Division (NCSD)
at the U.S. Department of Homeland Security. US-CERT is the opera-
tional arm of the NCSD. US-CERT incorporates CVE Identifiers into
its security advisories whenever possible and advocates the use of CVE
and CVE-compatible products and services to the U.S. government
and all members of the information security community. The MITRE
Corporation maintains CVE and this public website, manages the com-
patibility program, and provides impartial technical guidance to the CVE
Editorial Board throughout the process to ensure that CVE serves the
public interest.
24,25
2.4.5 SANS Institute Top Cyber Security Risks
The SANS Top Cyber Security Risks, formerly the SANS Twenty Most
Critical Internet Security Vulnerabilities, is a consensus list of the most
critical problem areas in Internet security that require immediate reme-
diation if present on your systems. Step-by-step instructions and point-
ers to additional information useful for correcting these security flaws
are included as part of the list. The SANS list includes CVE Identifiers
to uniquely identify the vulnerabilities it describes. This helps system
administrators use CVE-compatible products and services to make their
networks more secure.
26,27,28
2.4.6 U.S. Department of Defense Cyber Security
and Information Systems Information
Analysis Center (CSIAC)
In September 2012, the Data & Analysis Center for Software (DACS),
Information Assurance Technology Analysis Center (IATAC), and
Modeling and Simulation Information Analysis Center (MSIAC)
were merged to create the Cyber Security and Information Systems
Information Analysis Center (CSIAC). The CSIAC, one of eight
Information Analysis Centers (IACs) sponsored by DTIC, performs
The Secure Development Lifecycle 31
the Basic Center of Operations (BCO) functions necessary to fulfill the
mission and objectives applicable to the Department of Defense Research
Development Test and Evaluation (RDT&E) and Acquisition communi-
ties’ needs for cyber security, information assurance, knowledge manage-
ment and information sharing, software-intensive systems engineering,
and modeling and simulation.29 In the past, the DACS has produced
some great documents on software security and the SDL for the commu-
nity, most notably, Enhancing the Development Lifecycle to Produce Secure
Software: A Reference Guidebook on Software Assurance (2008)
30
and the
joint IATAC/DACS report Software Security Assurance: State-of-the-Art
Report (SOAR) (2008),
31
and we expect them to continue to do so under
the umbrella of the CSIAC.
2.4.7 CERT, Bugtraq, and SecurityFocus
In addition to the sources we have discussed so far, the Carnegie Mellon
Computer Emergency Readiness Team (CERT),
32
Bugtraq,
33
and
SecurityFocus
34
are three other sources to be aware of.
CERT provides timely alerts on security vulnerabilities as well as a
weekly summarized bulletin on vulnerabilities (CERT Cyber Security
Bulletin). Information in the bulletin includes CVSS scores as well as CVE
IDs to uniquely identify vulnerabilities. The compilation is based on vul-
nerabilities recorded in the NIST NVD
35
over the previous week. We will
be discussing the CVSS scoring process in more detail later in the book.
Bugtraq is an electronic security mailing list that provides information
on security vulnerabilities as well as security bulletins and announcements
from vendors. The list often contains additional information such as
examples of exploitations as well as fixes for the issues identified. Bugtraq
is part of the SecurityFocus security portal which is currently owned by
Symantec. Bugtraq is one of the many security mailing lists available
through SecurityFocus. There are other useful mailing lists as well, such
as those dedicated to Microsoft, Linux, IDS, and incidents.
2.5 Critical Tools and Talent
As with all security tasks, whether they are offensive or defensive in their
approach, there is always a blend of process, technology, and people that
32 Core Software Security
are required to make it successful. So far, the processes and models that
are available for software security have been discussed in this section.
There are two elements of the technology (tool) side of the triad that
will make or break you in terms of software security, and another on the
people (talent) side.
2.5.1 The Tools
Three primary tools are basic to the SDL, which are categorized as fuzz-
ing, static, and dynamic analysis tools. Although we will go over the
details of the best practices for their use in the SDL later in the book, a
high-level overview follows.
2.5.1.1 Fuzzing
Fuzz testing or fuzzing is a black-box software testing technique which
can be automated or semiautomated, which provides invalid, unexpected,
or random data to the inputs of a computer software program. In other
words, it finds implementation bugs or security flaws by using malformed/
semimalformed data injection in an automated fashion. Inputs to the soft-
ware program are then monitored for exception returns such as crashes,
failing built-in code assertions, and potential memory leaks. Fuzzing has
become a key element in the testing for software or computer system
security problems. Fuzz testing has a distinct advantage over other tools in
that the test design is extremely simple and free of preconceptions about
system behavior
Fuzzing is a key element of software security and must be embedded in
the SDL. There are many vendors to choose from in this space, and some
developers even develop their own tools. Two popular fuzzing tools are
Codenomicon,
36
which is one of the most mature fuzzing tools available
commercially, and the Peach Fuzzing Tool,
37
which is one of the more
popular open-source tools. As you will see later on in the book, the timing
at which the fuzzing tools are used in the SDL is critical. It should also be
noted that fuzzing is used for both security and quality assurance testing.
Fuzzing has recently been recognized as both a key element and a major
deficiency in many software development programs, so much so that it is
now a Department of Defense Information Assurance Certification and
Accreditation Process (DIACAP) requirement.
The Secure Development Lifecycle 33
2.5.1.2 Static Analysis
Static program analysis is the analysis of computer software that is per-
formed without actually executing programs. It is predominantly used to
perform analysis on a version of the source code; however, this kind of
analysis may also be done on some form of the object code. In contrast,
dynamic analysis is performed by actually executing software programs.
Static analysis is performed by an automated software tool and should
not be confused with human analysis or software security architectural
reviews, which involve manual human code reviews, program under-
standing, and comprehension. When used properly, static analysis tools
have a distinct advantage over human static analysis in that analysis can
be performed much more frequently and with security knowledge gener-
ally superior to that of the standard software developer. It also frees up the
time of seasoned software security architects or engineers so that they only
need be brought in when absolutely necessary.
Static analysis, also known as static application security testing (SAST),
identifies vulnerabilities during the development or quality assurance
phase of a project. It provides line-of-code level detection that enables
development teams to remediate vulnerabilities quickly.
The use of static analysis tools and your choice of the appropriate
vendor for your environment is another technology factor key to your
success. Any technology that beneficially automates any portion of the
software development process should be welcome, but this software has
become “shelf-ware” in many organizations because the right people and
right process was not used in selecting the tool or tools. Not all tools in
this space are created equal, and some are better at some languages than
others while others have great governance/risk/compliance (GRC) and
metric analysis front ends. In some cases you may have to use up to three
different tools to be effective. In the end, you need to choose tools which
support your language, are scalable, can be embedded with your develop-
ment processes, and have minimum false positives.
Software development is a complex business, and anything you can do
to make the process more repeatable, predictable, and reduce “friction” is
a big win for most organizations. There are many benefits to using static
analysis tools. The most important reasons include the following.
• Static analysis tools can scale. They can review a great deal of code
very quickly, something humans cannot do very well.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.