24 Core Software Security
the security posture of an organization. Competition and marketing hype
drove confusion, with different organizations standardizing on differ-
ent attestations. The authors have seen organizations pushing their cus-
tomers (in most cases, other companies) to adopt their recommended
attestation. For Fortune 500 companies this meant getting multiple
attestations/certifications as a proof of security posture. It didn’t help
that most of these attestations/certifications focused on “compliance
controls” or “policy based security.” The situation became worse with
regulations such as SOX, GLBA, Safe Harbor, and HIPAA adding to the
confusion. Companies often went for a set of certifications, one each for
compliance, security, privacy, credit card, physical security, and so on.
The ISO)/IEC developed the ISO/IEC 27001 (incorporating ISO/
IEC 17799, which had been the previous de facto ISO standard for
information security). It is an information security management system
(ISMS) standard that specifies a management system intended to bring
information security under formal management control. It mandates spe-
cific requirements that need to be met when an organization adopts the
standard. The standard addresses information security holistically and
encompasses everything from physical security to compliance. Industry
has enthusiastically adopted the practices, and ISO/IEC 27001 is the
leading standard for an information security management system (ISMS)
today. Most of the controls from other standards can be mapped back
to ISO/IEC 27001. This has enabled organizations to consolidate mul-
tiple security efforts under one standard, pursue a single framework with
holistic security in mind, and collect metrics in a consistent manner to
measure and govern security in an organization.
The authors see the landscape for software security (and SDL) simi-
lar to what it was for information security as a whole a few years ago
before ISO/IEC 27001 came along. There are multiple SDL method-
ologies (open and proprietary), each claiming to be better than the next.
Confusion prevails over the best way to accomplish software security in
an organization. Applying any one framework to an organization either
requires the organization to adopt different processes or to customize an
SDL framework that will work in their environment. With the coming
of ISO/IEC 27034, the authors see consolidation on software security
standards/framework as the ISO/IEC 27001 has done for information
security. Even in its infancy, there is awareness of the importance of
ISO/IEC 27034. Microsoft has declared its SDL methodology to be in
The Secure Development Lifecycle 25
conformance with ISO/IEC 27034-1.
14
We expect to see similar results
for other frameworks in the near future.
The ISO/IEC 27034 standard provides guidance to help organiza-
tions embed security within their processes that help secure applications
running in the environment, including application lifecycle processes. It
is a risk-based framework to continuously improve security through pro-
cess integrating/improvements in managing applications. It takes a pro-
cess approach by design.
The authors’ recommended SDL framework can be mapped to ISO/
IEC 27034 frameworks. We will lay out relevant mapping with ISO/IEC
27034 in Appendix A.
2.4 Other Resources for SDL Best Practices
There are other sources for SDL best practices, and some of the most
popular are described below.
2.4.1 SAFECode
The Software Assurance Forum for Excellence in Code (SAFECode) is a
nonprofit organization dedicated to increasing trust in information and
communications technology products and services through the advance-
ment of effective software assurance methods. SAFECode is a global,
industry-led effort to identify and promote best practices for developing
and delivering more secure and reliable software, hardware, and services.
It is meant to provide a foundational set of secure development prac-
tices that have been effective in improving software security in real-world
implementations by SAFECode members across their diverse develop-
ment environments. These are the “practiced practices” employed by
SAFECode members, which we identified through an ongoing analysis of
members’ individual software security efforts. By bringing these methods
together and sharing them with the larger community, SAFECode
hopes to move the industry beyond defining theoretical best practices to
describing sets of software engineering practices that have been shown to
improve the security of software and are currently in use at leading soft-
ware companies.
15,16
26 Core Software Security
2.4.2 U.S. Department of Homeland Security Software
Assurance Program
Since 2004, the U.S. Department of Homeland Security (DHS) Software
Assurance Program has sponsored development of the Build Security In
(BSI) website.
17
BSI content is based on the principle that software secu-
rity is fundamentally a software engineering problem and must be man-
aged in a systematic way throughout the SDLC.
The Department of Homeland Security National Cyber Security
Division’s (NCSD) Software Assurance (SwA) Program seeks to reduce
software vulnerabilities, minimize exploitation, and address ways to
improve the routine development and deployment of trustworthy soft-
ware products. Consistent with the Open Government Directive, the
program enables public–private collaboration in developing, publishing,
and promoting the use of practical guidance and tools, fostering invest-
ment in more secure and reliable software. The DHS Software Assurance
Program collaborates with the private sector, academia, and other federal
departments and agencies to enhance the security of software lifecycle pro-
cesses and technologies through activities such as the Software Assurance
Forum that it co-sponsors with the Department of Defense (DoD) and
the National Institute of Standards and Technology (NIST). A key initia-
tive funded by the DHS NCSD and the National Security Agency (NSA)
is the Common Weakness Enumeration (CWE). CWE is a joint effort
of DHS with NSA and the software community, including government,
the private sector, and academia, with the MITRE Corporationproviding
technical leadership and project coordination. Over 800 software weak-
nesses have been identified and cataloged. More than 47 products and ser-
vices already use CWE in a compatible manner. With the aim of reducing
the most significant exploitable programming errors, the SANS Institute,
an active participant of the Software Assurance Forum, has promoted the
Top 25 CWEs. SANS came up with the idea of focusing on the Top 25
CWEs, and this effort represents a community collaboration to prioritize
the most exploitable constructs that make software vulnerable to attack or
failure. This promotes the DHS co-sponsored CWE efforts and plays off
the “Top XXX” brand that SANS has built since 2001, starting with their
Top 10—the first prioritized list of security problems that organizations
should address.
18
The CWE is an important component of the NCSD’s Software
Assurance Program. This list of errors brings CWE to a practical,
The Secure Development Lifecycle 27
actionable, and measurable focus that will enable people to make and
demon strate real progress. Public–private collaboration forms the foun-
dation of NCSD’s SwA Program. CWE is a good example of the type
of public–private collaboration the department has been advocating.
Consistent with the Open Government Directive, the SwA Program’s
sponsorship of CWE enables community participation, collaboration,
and transparency. CWE provides the requisite characterization of exploit-
able software constructs; thus it better enables the needed education and
training of programmers on how to eliminate all-too-common errors
before software is delivered and put into operation. This aligns with
the Build Security In approach to software assurance so that software
is developed more securely on the front end, thereby avoiding security
issues in the longer term. The CWE provides a standard means for under-
standing residual risks and thus enables more informed decision making
by suppliers and consumers concerning the security of software.
19
2.4.3 National Institute of Standards and Technology
The National Institute of Standards and Technology (NIST) continues to
be of great value in providing research, information, and tools for both
the government and corporate information security community. The fol-
lowing are some of the key areas in which NIST contributes to the soft-
ware security community.
The NIST SAMATE (Software Assurance Metrics And Tool
Evaluation) project is dedicated to improving software assurance by
developing methods to enable software tool evaluations, measuring the
effectiveness of tools and techniques, and identifying gaps in tools and
methods. This project supports the Department of Homeland Security’s
Software Assurance Tools and R&D Requirements Identification
Program—in particular, Part 3, Technology (Tools and Requirements),
the identification, enhancement, and development of software assurance
tools. The scope of the SAMATE project is broad, ranging from operat-
ing systems to firewalls, SCADA to web applications, source code security
analyzers to correct-by-construction methods.
20
NIST Special Publication (SP) 800-64, Security Considerations in
the System Development Life Cycle, has been developed to assist federal
govern ment agencies in integrating essential information technology
security steps into their established IT system development lifecycle. This
28 Core Software Security
guideline applies to all federal IT systems other than national security
systems. The document is intended as a reference resource rather than as a
tutorial and should be used in conjunction with other NIST publications
as needed throughout the development of the system.
21
The National Vulnerability Database (NVD) is the U.S. government
repository of standards-based vulnerability management data represented
using the Security Content Automation Protocol (SCAP). These data
enable automation of vulnerability management, security measurement,
and compliance. The NVD includes databases of security checklists, secu-
rity-related software flaws, misconfigurations, product names, and impact
metrics.
22
The NVD Common Vulnerability Scoring System (CVSS)
provides an open framework for communicating the characteristics and
impacts of IT vulnerabilities. Its quantitative model ensures repeatable
accurate measurement while enabling users to see the underlying vul-
nerability characteristics that were used to generate the scores. Thus, the
CVSS is well suited as a standard measurement system for industries,
organizations, and governments that need accurate and consistent vulner-
ability impact scores. Two common uses of the CVSS are in prioritizing
vulnerability remediation activities and in calculating the severity of vul-
nerabilities discovered on one’s systems. The NVD provides CVSS scores
for almost all known vulnerabilities. In particular, the NVD supports the
CVSS Version 2 standard for all CVE vulnerabilities. The NVD provides
CVSS “base scores” which represent the innate characteristics of every
vulnerability. It does not currently provide “temporal scores” (scores that
change over time due to events external to the vulnerability). However, the
NVD does provide a CVSS score calculator to allow you to add tempo-
ral data and even to calculate environmental scores (scores customized to
reflect the impact of the vulnerability on your organization). This calcula-
tor contains support for U.S. government agencies to customize vulner-
ability impact scores based on FIPS 199 System ratings. We will discuss
the use of CVSS scores for managing software security later in the book.
23
2.4.4 MITRE Corporation Common Computer
Vulnerabilities and Exposures
The MITRE Corporation Common Computer Vulnerabilities and
Exposures (CVE) is a list of information security vulnerabilities and expo-
sures that aims to provide common names for publicly known problems.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.