Software Integrity Controls An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain June 14, 2010 Editor
Stacy Simpson, SAFECode
Contributors
Diego Baldini, Nokia Gunter Bitz, SAP AG David Dillard, Symantec Corporation Chris Fagan, Microsoft Corporation Brad Minnis, Juniper Networks, Inc. Dan Reddy, EMC Corporation
ii
Table of Contents
Introduction
1
The Risks to Software Integrity in a Supply Chain
2
The IT System Supply Chain
3
Software Integrity Controls
4
Vendor Sourcing Integrity Controls
5
Vendor Software Development Integrity Controls
10
Vendor Software Delivery Integrity Controls
16
Future Directions
21
Conclusion
23
Acknowledgments
23
Introduction Software assurance is most commonly discussed in the context of preventing software
Security
vulnerabilities that arise from unintended coding errors and other quality issues ranging from incomplete requirements to poor implementation. The reduction of vulnerabilities
ASSURANCE Authenticity
Integrity
in code is achieved through the application of secure development practices to the software development lifecycle, sometimes
Three Pillars of Software Assurance
referred to as software security engineering. However, as a more distributed approach to commercial software development has
requires software vendors1 to apply practices and controls to meet three key goals:
evolved, questions have been raised about
Security: Security threats to the soft-
what additional product security and com-
ware are anticipated and addressed during
mercial risks are introduced in the global
the software’s design, development and
software supply chain. One emerging area
testing. This requires a focus on security-
of concern is software integrity, an example
relevant code quality aspects (e.g., “free
of which is the risk that malicious code could
from buffer overflows”) and functional
be either intentionally inserted by a threat
requirements (e.g., “passport numbers
agent or unintentionally inserted due to poor
must be encrypted in the database”).
process controls into a software product as it moves through the global supply chain.
Integrity: Security threats to the software are addressed in the processes used to source
Analyzing this risk in the context of software
software components, create software com-
engineering requires an understanding not
ponents and deliver software to customers.
only of software security engineering, but also
These processes contain controls to enhance
the other essential pillars of software assur-
confidence that the software was not modi-
ance—software integrity and authenticity.
fied without the consent of the supplier.
SAFECode defines software assurance as “confidence that software, hardware and services are free from intentional and unintentional vulnerabilities and that the software functions as intended.” Achieving this confidence
1. This paper uses both the terms “supplier” and “vendor” to mean an entity that produces software. These terms may be used interchangeably in the real world, and the “vendor” practices listed in this document apply to all software “suppliers.” However, in order to be able to describe the relationship between software suppliers without confusion, we are using the term “vendor” throughout the document to identify a specific entity in a supply chain. Thus, in this context, “supplier” refers to an entity that provides software components to the “vendor.”
1
Authenticity: The software is not To help others in the industry initiate or improve their own secure development
Security
programs, SAFECode has published “Fun-
ASSURANCE Authenticity
damental Practices
Integrity
for Secure Software Development: A Guide to the Most Effective Secure
Development Practices
counterfeit and the software supplier provides customers ways to differentiate genuine from counterfeit software. This paper is focused on examining the software integrity element of software assurance and provides insight into the controls that SAFECode members have identified as effective for minimizing the risk that intentional and unintentional vulnerabilities could be inserted into the software supply chain.
in Use Today.” Based on an analysis of the individual software assurance
This paper has been developed
efforts of SAFECode members, the paper
in conjunction with SAFECode’s
outlines a core set of secure develop-
previously published “Soft-
ment practices that can be applied
ware Supply Chain Integrity
across diverse development environ-
Framework,” which outlines
ments to improve software security.
a taxonomy for the software
The brief and highly actionable paper describes each identified security practice across the software develop-
The Software Supply Chain Integrity Framework
supply chain and a framework for analyzing and establishing software integrity controls.
ment lifecycle—Requirements, Design, Programming, Testing, Code Handling mentation advice based on the real-world
The Risks to Software Integrity in a Supply Chain
experiences of SAFECode members.
The risk of an attacker using the supply
These practices are designed to be used
chain as an attack vector deserves some
and Documentation—and offers imple-
in conjunction with the software integ-
further examination. Evidence suggests
rity practices outlined in this paper.
that attackers focus their efforts on social
To obtain a free copy of the paper, visit www.safecode.org.
engineering or finding and exploiting existing vulnerabilities in the code, which are usually the result of unintentional coding errors. Thus, experts have concluded that
2
Defining Risks and Responsibilities for Securing Software in the Global Supply Chain July 21, 2009 Editor
Stacy Simpson, SAFECode
Contributors
Dan Reddy, EMC Brad Minnis, Juniper Networks Chris Fagan, Microsoft Corp. Cheri McGuire, Microsoft Corp. Paul Nicholas, Microsoft Corp. Diego Baldini, Nokia Janne Uusilehto, Nokia Gunter Bitz, SAP Yuecel Karabulut, SAP Gary Phillips, Symantec
a supply chain attack is not the most likely
integrity controls to achieve these objectives
attack vector. Notably, the experiences of
by addressing the security of the processes
leading reputable software companies who
used to source, develop and deliver software.
work with their suppliers support this finding. Further, there is growing recognition that 1) there is no one way to defend against
The IT system supply chain is a glob-
every potential vector a motivated attacker
ally distributed and dynamic collection of
may seek to exploit; 2) focusing on the
people, processes and technology. Software
place where software is developed is less
is one component of a larger IT solution
useful for improving security than focus-
and each software vendor is only one part
ing on the process by which software is
of a complex chain of suppliers, systems
developed and tested; and 3) there are
integrators and ultimate end users. As such,
circumstances when the insertion of malicious
each vendor is only one link of a larger,
code would be almost impossible to detect.
more complex IT system supply chain.
These challenges highlight that a risk from
As a vendor’s customer may not be the
the supply chain could indeed undermine
ultimate end user in the IT system supply
a product’s intended function or damage
chain, it is important to analyze where along
customer trust. Accordingly, major software
the supply chain software security, integ-
suppliers take preventative action against any
rity and authenticity practices and controls
unauthorized changes in the form of software
can be applied effectively and efficiently.
integrity controls. These controls preserve the quality of securely developed code, prevent the inadvertent introduction of vulnerabilities and help to prevent the intentional insertion of malicious code. Vendors leverage these
Security
Security
ASSURANCE Authenticity
The IT System Supply Chain
Integrity
Tier n Supplier
has both an opportunity and a responsibility to apply software assurance practices and controls in order to preserve software integrity,
Security
ASSURANCE Authenticity
Each supplier along the IT system supply chain
Integrity
Tier 2 Supplier
Security
ASSURANCE Authenticity
Integrity
Tier 1 Supplier
ASSURANCE Authenticity
Customer
Integrity
Integrator
Software Assurance Is a Shared Responsibility In the IT System Supply Chain
3
security and authenticity within the portion of
It is within these three processes that effective
the software supply chain it controls. Naturally,
software security, integrity and authentic-
a vendor has the most direct control over its
ity practices and controls must be applied in
own internal practices. A vendor’s reach into
order to improve the assurance of delivered
its own suppliers for their software assurance
software. This paper will focus specifically
practices and controls may not be as direct.
on the software integrity controls that ven-
Within their respective links of the IT systems
dors apply to each of these processes.
supply chain, all software vendors control and
It should be noted that SAFECode member
manage three key lifecycle processes where
companies, like industry companies at large,
they can effectively and efficiently implement
are still sharing information and examining
software assurance practices and controls:
practical and meaningful means of measur-
1. Software Sourcing: Vendors select their
ing and verifying software assurance in the marketplace. As that work matures, we can expect more consistency in how information about internal processes is asserted
Software Sourcing • Procurement
Software Development and Testing • Environment • Personnel • Software Development
Software Delivery • Distribution • Sustainment
and evaluated between trading partners. Thus, while this paper focuses on the practices and controls involved along the supply chain, it was developed with the recognition that more work in this area needs to be done, and it does not attempt to be highly
component and services suppliers, estab-
prescriptive with respect to measurement.
lish the specifications for a supplier’s deliverables and have activities to “on-
Software Integrity Controls
board” software and hardware components
The following sections will detail the soft-
and services received from suppliers.
ware integrity controls that SAFECode has
2. Software Development: Vendors
identified as effective for minimizing the
build, test, assemble, integrate and
risk that vulnerabilities could be intention-
package components for delivery.
ally or unintentionally inserted into the
3. Software Delivery: Vendors deliver the software product to customers and provide ongoing sustainment.
software supply chain. This analysis is based on the real-world experiences of SAFECode members. These integrity controls aim to preserve the base level of security in a product achieved through each supplier’s
4
secure development practices by helping to
SAFECode has organized the integrity
prevent the introduction of vulnerabilities as
controls listed in the following sections
a product moves along the supply chain.
by the three key lifecycle processes each
The controls identified in the following sections are based on the seven basic principles for software integrity outlined in SAFECode’s previously published “Software Supply Chain Integrity Framework:”
software vendor has control over—supplier sourcing, product development, and product delivery and sustainment.
Vendor Sourcing Integrity Controls
• Chain of Custody • Least Privilege Access • Separation of Duties • Tamper Resistance and Evidence
Software Sourcing • Procurement
Software Development and Testing • Environment • Personnel • Software Development
Software Delivery • Distribution • Sustainment
• Persistent Protection • Compliance Management • Code Testing and Verification These principles support the development of the software integrity controls outlined in this paper and identified by SAFECode as practical, repeatable and auditable. The software integrity controls described in the following sections do not represent a minimum control list, but rather are designed to be integrated with other security practices and tailored to meet a product’s specific risk profile. Furthermore, they are to be integrated into the vendor’s software engineering process and performed in conjunction with corporate security functions. These may include physical security, network security, IT infrastructure security and business continuity management.
During the sourcing process vendors establish component specifications, select suppliers of components and services and receive supplied components. The selection and application of software integrity controls for use during sourcing is a risk-based decision and largely influenced by the nature of the relationship between a vendor and its software component supplier. There are three types of vendor-supplier relationships: First, “arms length” relationships where vendor A licenses a component from supplier B. Second, work-for-hire relationships where vendor A engages supplier B to provide a software component. Third, work-for-hire relationships where vendor A engages supplier B to provide a staff augmentation service.
5
Relationships between a vendor and a sup-
The next section describes integrity
plier based on licensing finished components
controls that can be used in a vendor’s
like databases, enterprise resource manage-
sourcing process.
ment systems, or operating systems are examples of arms length relationships. It
Vendor Contractual Integrity Controls
is incumbent on suppliers that license their
A vendor’s engagement with a supplier
software—typically suppliers of commercial-
should be governed by a written agree-
off-the-shelf (COTS) products or Open
ment, for example a license or a contract.
Source Software (OSS) components— 1) to
The written agreement must explicitly state
assure that security threats to the product
the vendor’s and supplier’s expectations,
or component are anticipated and addressed
as well as the consequences of any non-
during its design, development and test-
compliance with the terms of the agreement.
ing; 2) to assure that the processes used to source and create components, and to
Defined Expectations
deliver the product to their customers are
• Clear language regarding the requirements
secure; and 3) their suppliers provide ways
to be met by the code and the develop-
for their customers to differentiate genuine
ment environment should be set forth
products and components from counterfeit.
during the contracting process. Among
In relationships based on work-for-hire, the software delivered by a supplier to a vendor is owned by the vendor. The integrity controls used by the supplier may be the supplier’s, the vendor’s or any combination thereof. Typically, in staff augmentation engagements
ments to provide security testing, code fixes and warranties about the software development and delivery process used. Overall this helps to set the expectation of delivering a product with integrity.
the vendor’s and supplier’s staff work collab-
Ownership and Responsibilities
oratively on projects that share code libraries,
• Intellectual property ownership and
tools and resources, and all project members utilize the same software integrity controls. In each of the above relationships, the vendor has different degrees of control over the integrity practices and controls used by its supplier. It is this level of control that guides the selection of the software integrity practices and controls necessary to minimize software integrity risks.
6
other things, this should include commit-
responsibilities for protecting the code and development environment should be clearly articulated.
Vulnerability Response • In today’s world, vendors must push for a more formal understanding of how well their suppliers are equipped with the capability to collect input on vulnerabilities from
researchers, customers or sources and turn around a meaningful impact analysis
The contracts between companies regard-
and appropriate remedies in the short
ing software have typically been focused
timeframes involved. The fact is that the
on expectations regarding functional
handling of such vulnerabilities will likely
performance, defect handling, licensing
become a joint responsibility in the face of
issues and other challenges like end-of-
downstream visibility to customers. No one
life support. As concerns about protecting
can afford to be surprised about a suppli-
software’s integrity have escalated along
er’s potential immaturity in handling these
with reducing the risk of counterfeit com-
challenges in the middle of a situation.
ponents and products, contracts evolved
Suppliers provide common terminology
further to address this in language.
for these discussions by using now-default references to well-known specifications like Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System (the CVSS). Each party should identify contact personnel and review timing and escalation paths as appropriate to be prepared to provide a prompt response.
New language that specifically addresses the issue of integrity and authenticity of COTS product components from external suppliers that will be included in the ultimate product can also be explored. The language would ask suppliers to self-certify that the supplier’s software aligns with security standards
Security Training
and that the supplier’s practices align
• Another important area for discussion
with best practices of industry code
between trading partners is assessing a supplier’s capability to effectively train
security and integrity organizations like SAFECode or its equivalent.
its developers on secure development practices. While it is not necessary to be highly prescriptive about a particular curriculum or certification regime, a company cannot credibly assert that it has a secure development framework or that it follows integrity practices if there is no evidence of any relevant training.
7
Open Source Software The use of open source software presents alternative challenges in the context of supply chain integrity.
As a result, the process used to evaluate and select open source software components deserves consideration. Software vendors analyze the reputation and release engineering practices of the community
While in some cases a commercial entity may
supporting an open source component to
package and support open source software,
help assess its competence and reliability
other open source software is managed by a
in dealing with security matters. While
community with which a direct relationship
the vetting practices will vary depend-
cannot be established. In the latter case, the
ing on the specific product needs and risk
trust and accountability between a vendor
profile, means to validate open source pack-
and the community supplying software is
ages and their distribution sites need to
different. Notably, the contractual terms
be adopted and developed, respectively.
that vendors establish with commercial suppliers do not apply to community-supplied components as there is no direct supplier with whom to establish an agreement. Existing license terms governing the use of open source software are focused on ensuring that combinations of the software with other software are consistent with the community’s expectations. Those license terms may not provide sufficient support for efforts to protect software integrity. Other controls similar to those present in commercial vendor-supplier agreements may need to be implemented for community-supplied software. For instance, as vulnerabilities are visible to anyone and because their exploitability can be readily assessed, open source communities may call
A viable integrity control for community open source components is for a vendor to get the source, review it and build it. Validating the quality of open source software needs to happen after acquisition of the code. Vendors may choose to include an open source component or leave it up to the acquirer to obtain and evaluate the component. For vendor-supported OSS, an acquirer can transfer risk to the vendor through appropriate language in their agreement. Otherwise in either case, procedures must be implemented for the inspection of software components for the presence of vulnerabilities and for the assessment of the trustworthiness of the component’s distribution site.
for more active vulnerability management
In general, a vendor must under-
and incident handling, and users in the field
stand how each of its suppliers
may request quicker software updates.
handles the open source components that are shipped with its own code.
8
Vendor Technical Integrity Controls for Suppliers Secure Transfer • Delivered code should be transferred securely, using authenticated endpoints and encrypted sessions. Content being delivered should be encrypted for transit. This requires that suppliers use the best available technology, mechanisms and
automatically at contract expiration or at another fixed period. A robust procedure is required so that when a supplier’s employee leaves the supplier company, the former employee’s credentials immediately expire. A combination of automatic disabling and manual notification is best to ensure completeness of privilege removal.
procedures when exchanging deliverables.
Malware Scanning
A secure end-to-end automated process
• Supplier content to be transmitted to
can often strengthen the protection that could be resident in a manual procedure.
Sharing of System and Network Resources • The digital identities a vendor issues to suppliers to enable access to the vendor’s network and resources should be established with strong controls enforced to limit access to only those resources needed to perform the supplier’s role. –– Each resource that is shared should
the vendor should be scanned for malware using the most recent malware signature files and more than one commercial scanning engine. While today’s malware scanning tools are generally not designed to identify malicious code that is perfectly formed, this standard integrity control should be performed at points of exchange between parties. Depending on the relationship and the practicality of doing so, suppliers should inform recipi-
have its own independent assess-
ents of the code as to what scanning has
ment as to what authentication and
taken place up to the point of transfer.
authorization is required. For example, staff access to a vendor’s development
Secure Storage
project requires additional authoriza-
• Source code for software components
tion over and above the authorization
and products should be stored securely
a staff member receives in order to
with need-to-know access controls
access a vendor’s corporate network.
applied. Code packages that are trans-
–– A supplier’s access to development assets should expire as soon as it leaves the project. A fail-safe check should also be in place to end all privileges
ferred should be moved to a secure asset repository as soon as practical so that they can be managed more precisely with respect to access privileges.
9
Code Exchange
Within a software vendor’s organiza-
• Processes using digitally signed pack-
tion, additional software integrity controls
ages and verifiable checksums or hashes
may exist within the context of other IT
should be in place to ensure that received
functions such as backup and recovery,
code is complete and authentic. Verifying
business continuity, physical and network
the digital signatures with validated time
security, and configuration management
stamps of the software packages proves
systems. The following are examples of
authenticity and establishes that the
controls employed by SAFECode members:
download or transfer process delivered an intact version of the intended package.
Vendor Software Development Integrity Controls
People Security • It should be noted that while criminal background checks are often the focus of public debate, in practice SAFECode members have found that they are not as effective as other controls and processes.
Software Sourcing • Procurement
Software Development and Testing • Environment • Personnel • Software Development
Software Delivery • Distribution • Sustainment
Focusing on organizational and process controls in conjunction with technology to minimize risks coming from within the company is more efficient and effective. For that reason, many of the following controls to minimize the risk from malicious insiders are based on practices
In software development and test-
such as the segregation of duties and the
ing, software vendors build, assemble,
use of controlled automated processes.
integrate and test software components to finalize them for delivery.
ties and access rights are clearly defined
Software vendors have a great deal of
in development processes to achieve a
experience implementing powerful man-
defense-in-depth approach. Development
agement, policy and technical controls to
management must be knowledgeable as
achieve sound engineering practices and
to who has what access. A team of people
intellectual property protection. The secure
with well-planned responsibilities must
development practices that focus primar-
maintain appropriate operations for guard-
ily on achieving the “security” circle in the
ing code assets while meeting the demands
software assurance triad described above
of the global engineering environment.
become the baseline for internal development.
10
• It is important that roles, responsibili-
• In addition to the expected training in
periodically re-assessed using a risk-based
secure development practices, there
process. Physical security controls should
should be training in the secure techni-
be strong enough to ensure that devel-
cal controls used by other integrity
opment assets cannot be accessed by
practices. Does each organization know
outsiders. Physical protection of source
how to verify a digital signature with
code should go beyond a single layer of
a validated timestamp? Does each
building security and include additional
organization understand which hash algo-
distinct physical access controls that limit
rithms are best used in a checksum?
access to those with a “need to know.” For example, additional badge restricted
Physical Security
access beyond the normal building access
• Building security and physical access
should be required for administrators
control should be applied to develop-
to access code assets protected in a
ment locations and code repositories and
repository. Physical assets and credentials
Integrity Controls vs. Development Practices While SAFECode’s Development Practices
by another. Without proper integrity controls,
paper describes how to identify and avoid
this change might go undetected and could
typical coding errors such as buffer over-
cause problems elsewhere because nobody
flows, SQL injection, cross site scripting
was expecting the function to have changed.
and more, this current work deals with the question of preserving the integrity of an IT product. The integrity practices serve as controls to prevent unauthorized or inadvertent changes to the source code.
A combination of good access controls, testing and peer review of changes could minimize this risk. Thus integrity controls can aim at preserving the well-constructed code for the approved specification while
Without proper controls, vulnerabilities
preventing careless or inadvertent changes.
can be introduced by ”good faith” develop-
Integrity controls throughout the supply
ers. For example, while fixing a problem in
chain will also reduce the risk of a malicious
their part of the code with dependencies
attacker being able to change code inten-
elsewhere, a developer might inadvertently
tionally or perhaps detect a virus before it
change code while merging it with a related
spreads into the production environment.
function (e.g., an interface) primarily owned
11
(e.g., keys, badges, security tokens,
the minimum code necessary to carry
smartcards, laptops, etc.) loaned to an
out their responsibility. Access to code
individual should be retrieved and veri-
stored on local machines should also be
fied against a list of expected assets as
controlled based on a “need-to-know” and
part of a managed termination process.
“least-privilege” basis to the extent possible
Network Security • Network security standards should be established and applied using a risk-based
Code Repository Security • All code-related assets should be
process for the code-related assets. For
housed in source code repositories
example, security protections could include
(also known as configuration manage-
intrusion detection or other defensive
ment systems or source code control
measures on source code repositories
systems), to enable additional atten-
with alerting to appropriate event sys-
tion to security and access control.
tems that would alarm during an attack. Session traffic involving source code should be encrypted to acceptable company or applicable industry standards. • Access to developer workstations should
• The servers that host the source code repositories should be housed securely. In most major software vendors, these machines are located in data centers with appropriate physical security, hardened
be controlled. For example, workstations
server security and business disaster
can be tied to corporate authentication to
recovery controls. Be mindful that source
ensure that terminated workers are imme-
code is sometimes copied and kept in
diately denied further access. Accounts
separate databases after being run through
of departing employees and other autho-
some static code analysis tools. The confi-
rized workers should be properly disabled
dentiality of code files should be protected
immediately to allow appropriate review of
in all locations. This avoids unauthorized
their work. It is important to disable, and
people from seeing the code structure
not delete, accounts so that a full forensic
and test results. Combined access to such
analysis is still possible after termination. • Workstation and virtual machine security should be secured to standards to mini-
12
given the goals of the project at hand.
information might enable them to better target particular code files in a later attack. • The “out of the box” defaults of any such
mize the opportunity for malicious code to
system must be examined and configured
be introduced during the coding process.
to be secure by default, ideally accord-
Developers should have write access to
ing to a well-understood standard for a
system holding an acquirer’s precious
distinct identities to provide accountability.
assets such as its customers’ personal
Administrative practices should observe
identifiable information. One objective
the separation of duties principle, and
would be for the system to operate without
elevated permissions should be subject
the risk of allowing exploits through eas-
to management approval. For instance,
ily inherited system-level root privileges.
project engineering administrators require
Many detailed settings such as authen-
a higher level of access to code assets
tication handling, session variables and
to perform their duties than network
external interfaces must be addressed to
security administrators. Other person-
deliver secure-by-default deployment. A
nel such as IT or Security Operations
software’s default state should promote
may have responsibility for base-level
security. For example, software should
configurations and the overall platform
run with the least necessary privileges
profile including security patch levels, etc.
and services that are not widely needed should be disabled by default or only accessible to a small population of users. • Once enabled as secure by default, that
• Within the repositories, access to branches, work areas or code sets must be understood by development management, and access privileges
configuration status itself must be pro-
should be granted using the principles
tected. As more systems like repositories
of least privilege and need to know.
become compliant with specifications like the emerging Security Content Automation Protocol (SCAP) specifications, the configuration state of the repository and subsequent changes can be expressed and consumed in machine-readable form, offering greater initial and ongoing protection supported by automation. • Ideally, access to source code repositories should be controlled through the use of corporate identity systems, with strict control maintained over access to any system account. Engineering administrators responsible for managing application repositories should be named users with
• Code segments can be tied to specific requirements in a requirements management, enhancement or bug tracking system that allows for cross mapping of functionality to code. • Change management practices with review and approval paths should be formalized and well understood for code logic and asset changes, repository application and underlying system configuration changes. • Change logs for all modifications to a product’s code assets should be maintained and preserved for future analysis. Logs should provide file names, account name of the person checking in the file,
13
A company can have source code policy
who created and ran the scripted environ-
and standards that product engineer-
ment that produced a particular build. In
ing teams are expected to meet in the
addition, build scripts need protection as
context of protecting source code and
critical assets. This internal standard also
product artifacts throughout the product
ties into corporate security polices and con-
development cycle. For example, these
trols such as the credentialing requirements
could include detailed corporate expecta-
for personnel and handling of digital identi-
tions regarding the protection of source
ties, a key bridge to best practices around
code repositories and build environments.
the protection of source code repositories.
Some might be simple requirements, like
An active, ongoing relationship with engi-
“Source Code Systems should leverage
neering teams places the internal security
corporate identity stores for authentication,”
team in the best position to effect ongoing
and perhaps obviously that “no anonymous
improvements to the protection of code
access can be allowed to a repository.”
throughout its lifecycle. The requirements
Others are more detailed, such as which
should not distract by simply attempt-
particular systems for handling internal
ing to force everyone to use an identical
request and approval routing for source
repository, but to set the standard for how
code repository privileges must be used
a repository should be set up and operated
by each engineering team. Setting up the
securely. The approach taken in working
linkage between source code repositories
with engineering teams is to assess the
and the set of build tools is challenging
gaps that exist between where a group is
since automation and accountability must
today on each item in the standard and to
be blended. A practical approach is needed
build an improvement plan for closing the
such that the sets of tools can be consistent
gaps as part of a risk-based approach.
and automated, while still making it known
14
check-in time stamp, and the line changes
and build tools should be traceable to
made. They should be kept for a suf-
individuals with the authority to execute
ficient time in a protected environment
the automated scripts or procedures.
to assist with any forensics or ongoing security improvement initiatives. • A manifest of all code assets contributing to a product, including those developed in-house and by third parties, should be maintained and managed, similar to a Bill of Materials in the manufacturing domain. • Versions of software assets with their known security characteristics should be tracked in the repository. Change or configuration management should be tracked as well to find the balance between getting the latest patches and updates and having stable, predictable code.
Build Environment Security • Build environments should be as automated as possible. This minimizes the opportunity for human intervention in the regular build process. However, the “owners” of the build environment should be few. The traceability of actions on build scripts and of access to code files during build should be high. • Build automation scripts should be treated
Peer Reviews and Security Testing One security engineering practice that all SAFECode members use in conjunction with their software integrity controls is security testing. Source code and binary analysis tools, and sometimes manual code review, are performed on code to identify common coding patterns that are known to have been attacked previously. Testing techniques are continually upgraded. Security engineering practices complement software integrity controls because security engineering practices represent an ever-rising threshold against software supply chain vulnerabilities. The testing techniques below are primarily software security engineering practices, not software integrity controls.
Peer Review • Peer reviews and the manual inspection of code are not often popular given issues of scalability. Automated tools can enable some scalability by collecting and processing more artifacts in preparation for peers
in a manner similar to other source
performing a focused review. Also, when
code assets and checked in to the code
teams are assigned to work together on
repository. This means that changes to
code files, an important dynamic is present
the automated build process can be attrib-
whereby reviewers can more readily iden-
uted to the person checking in the file.
tify code that does not belong within a code
• Service accounts that run in an automated fashion between source code repositories
set. Focusing peer reviewers on changed code that is scanned again and awaiting
15
approval during a two-stage check-in to
While security testing is a fundamental part
the repository can be an effective approach.
of supply chain security, software vendors
Another approach is to couple peer reviews
recognize that testing alone is not likely to
in relation to exercised code paths in the
catch malicious code that is intentionally
context of overall code coverage. In gen-
inserted, perfectly crafted and disguised to
eral, questions about the structure and
appear as legitimate. Due to these limitations,
purpose of sections of code that arise dur-
software testing must be augmented with
ing peer review are more likely to uncover
the other listed software integrity practices
intentional malicious code or inadvertent
that control access to development assets to
code errors than automated testing alone.
more effectively address potential software
Testing for Secure Code • The size of the code base for many software projects today requires automated code review and testing tools. Additional
security risks in this stage of the supply chain.
Vendor Software Delivery Integrity Controls
information on secure code testing can be found in SAFECode’s “Fundamental Practices for Secure Software Development” paper. Building these tests to run in a repeatable automated manner
Software Sourcing • Procurement
Software Development and Testing • Environment • Personnel • Software Development
Software Delivery • Distribution • Sustainment
increases the assurance that they will be performed and analyzed often. • The list below identifies the most common categories of testing tools used: –– Static code analysis tools (source code) –– Network and web application vulnerability scanners (dynamic testing)
covers new product delivery and the delivery of maintenance patches. It is important to note that while this may be the last stage of the supply chain directly under a software vendor’s control, it is not
–– Binary code analysis tools
always the final step in the supply chain from
–– Malware detection tools (dis-
the end user’s point of view, as software
cover backdoors, etc.) –– Security compliance validation tools (hardening, data protection) –– Code coverage tools
16
This stage of the software supply chain
vendors often do not provide their products directly to end-user organizations. In many cases, the software vendor’s products are passed to system integrators, resellers and authorized service providers before reaching
the end-user. Thus, as software components
Delivery
leave the supplier, software integrity and
• A vendor’s process for delivering
authenticity become a shared responsibil-
products both online and through dis-
ity between supplier and customer.
tributions using physical and electronic
Publishing and Dissemination
media should be secured. Informa-
The controls for product delivery are
should be available to customers.
tion on code signing and checksums
similar to those for the receipt of code components from software suppliers to the software vendor as described in the Sourc-
Transfer • Transfer products in such a way that the
ing section of this paper. However, additional
receiver can confirm that the product
security needs arise once the software
is coming from the software vendor.
product is complete. These include stateof-the-art anti-malware checks and the
Authenticity Controls
availability of a mechanism that provides
For all the work that software vendors do
a way for customers to assure themselves
in ensuring they produce a quality product
of the integrity of the delivered package.
free from vulnerabilities, there remains
Malware Scanning • Products should be scanned for malware
residual supply chain risk after the product has been released. Millions of customers every year unsuspectingly acquire coun-
using the most recent malware signature
terfeit software. According to the Business
files and more than one commercial scan-
Software Alliance, over one in five software
ning engine. As mentioned earlier and
packages are counterfeit or pirated.2
depending on the nature of the relationship, it may be appropriate to communicate what scanning was done prior to the handover.
Code Signing • The software vendor’s product should be
While not a central focus of this paper, authenticity or anticounterfeiting controls are
Security
one of the three essential elements of software
strongly digitally marked with the software
assurance and thus
vendor’s identity in a way that can’t be
are tightly integrated
altered, yet may be verified by customers.
with software integrity
ASSURANCE Authenticity
Integrity
controls, especially as
2. Business Software Alliance, “Sixth Annual BSA-IDC Global Software Piracy Study,” May 12, 2009.
17
software is prepared for delivery. Thus, it is important to highlight the key authentic-
offer proof of authenticity for the many
ity controls used by software vendors in the
predictable aspects of the software.
software delivery link of the supply chain. Counterfeit products often look authentic, but they pose serious risks to customers. Counterfeit software cannot be assured to function as intended and often contains malicious code aimed at data destruction or theft. Protecting customers and businesses from the risks of counterfeit software requires both engineering efforts by software vendors and awareness and recognition by acquirers and end users. The risk of counterfeit software can be greatly reduced through purchase from only authorized resellers, careful examination of product packaging and
Notification Technology • With a variety of distribution channels for software, including online distribution, customers often can’t tell that they have a counterfeit product until it is installed on their computer. Vendors can leverage technology to detect certain aspects of the product’s integrity and notify the user if the software is deemed to be counterfeit. Sometimes introduced by vendors to prevent license piracy, this technology has evolved into an effective integrity control.
media, and technology to notify users when
Authentic Verification during Program Execution
they may be victims of counterfeit software.
• In practice, the integrity of an applica-
Cryptographic Hashed or Digitally Signed Components • As mentioned above, digitally signed components or checksum hashes are an essential authenticity control to prove that components are genuine. With any system there are characteristics of the software being shipped that are stable, while there may be other items that vary with particular configuration options as installed. Today the “signing” of an application provides a capability to detect that an application has not been tampered with since the time it was signed.
18
Vendors must find the right balance and
tion can be verified when the application is installed on a computer. Additionally, each time an application runs on a user’s computer, similar technology can verify the integrity of the files that make up the application. The hardware and software technology used to verify the claims applications and files make about their validity and integrity is well understood, efficient and broadly available. Software vendors who already make use of this technology have invested in hardware, software, people and process, effectively “code signing” their applications.
• A vendor with the right technology
configuration. Secure configurations for the
tools can effectively pre-authorize the
supplied software should be delivered to
program execution of only a specific
the customer along with an outline of the
set of applications from a “good” list,
risk implications of the configuration state
effectively blocking any newly spawned
or choices detailed. The future of broader
code that may not be legitimate.
adoption of machine readable SCAP
Product Deployment and Sustainment in the Ecosystem
compliant configurations will strengthen this area’s contribution to integrity.
The software lifecycle extends beyond delivery
Custom Code Extensions
of the initial software vendor’s product and
• Software designed to be integrated and
into the product’s sustainment or mainte-
extended to deliver additional functionality
nance phase. As a result, patches and hot
creates another link in the supply chain.
fixes should be subject to the same software
Assume that the original software and its
integrity controls as the original code.
interfaces were secure, fully functional
It is important that authorized service personnel with ongoing access to genuine parts and proper disposal procedures are involved in the sustainment process. Authorized access should convey that the person actively works for the company providing the service and that service personnel don’t have more privileges on the installed environment than those needed to complete the task at hand. All service transactions should provide evidence that legitimate service personnel did the work, and evidence should be available
and delivered with integrity and authenticity. Software components that are added later to extend the functions of an IT System must be also be treated with the same care as originally applied by the internal development and testing of its supplier. Integrators must follow secure development practices as they extend code functionality through the provided secure interfaces. In addition, to continue integrity, their component assets should be cataloged in a repository, access to code restricted based on “need-to-know”
for audit and protected against tampering.
and peer reviews implemented. The
Secure Configurations
these controls as the sets of products
• Whenever possible, software vendors
are assembled for the solution to be
chain of custody must be preserved with
should ship products with a secure
delivered to the ultimate end customer.
configuration being set as the default
Resellers or systems integrators often manage this link in the supply chain.
19
Table 1: Summary of SAFECode Software Supply Chain Integrity Controls Processes
Controls • Defined expectations Vendor contractual integrity controls
• Ownership and responsibilities • Vulnerability response • Security training
Software sourcing
• Secure transfer Vendor technical integrity controls for suppliers
• Sharing of system and network resources • Malware scanning • Secure storage • Code exchange • People security • Physical security
Software development and testing
Technical controls
• Network security • Code repository security • Build environment security
Security testing controls
• Peer review • Testing for secure code • Malware scanning
Publishing and dissemination controls
• Code signing • Delivery • Transfer
Software delivery and sustainment
• Cryptographic hashed or digitally signed components Authenticity controls
• Notification technology • Authentic verification during program execution
Product deployment and sustainment controls
20
• Patching • Secure configurations • Custom code extension
Future Directions
research and development. Additional
As software integrity remains an emerg-
be a promising new approach similar to
ing discipline, there are a number of areas that SAFECode believes deserve further study and industry collaboration. These include, but are not limited to:
Supplier Management and Communication along the Supply Chain • The work that the software industry has undertaken to identify and implement secure coding practices, including the findings presented in SAFECode’s “Fundamental Practices for Secure Software Development” paper, takes on new implications when examined along the supply chain from one supplier to another. These security practices together with normal quality control concerns could
behavioral analysis of a piece of code might what is already implemented in some of today’s anti-virus detection software.
Authenticity Ease of Use • While cryptography can be applied with checksums, digital certificates and signatures and validated timestamps, the user experience to verify legitimate software can be confusing and daunting. Users need far easier means of validating authenticity so that they are not primarily focused on clearing their screens of any distractions to get on with the tasks at hand. Since social engineering attacks sometimes count on users dismissing warnings or errors, ongoing work in this area is important.
be reexamined in the context of the
Authentic Software at Runtime
exchange of software and related infor-
• How can end-users assure themselves that
mation from one supplier to another.
Research on Software Testing • As discussed previously, automated testing currently is limited in its ability to detect malicious code that is intentionally inserted and well disguised as legitimate. Essentially, today automated testing can only detect malware that use coding patterns that have been seen previously. Increasing the capability of software testing of source and binary code to identify vulnerabilities is an area worthy of future
all software running on their machines is authentic and trustworthy? One promising technology advancement is the Trusted Platform Module (TPM), a hardware component that can be integrated with a signed operating system, signed applications and signed add-ins to provide an end user the assurance at run time that all components are authentic. However, for TPMs to be truly effective, all software must be signed. Some vendors, both community (open source) and proprietary, have taken steps to enable this technology. However, an
21
this vision as the computers used by end
Broader Collaboration with Supply Chain Management Community
users contain an eclectic collection of
• While the well-established and mature
industry-wide effort is necessary to achieve
software sourced from a vast ecosystem of
supply chain management community
vendors, suppliers and communities. The
is becoming aware of these emerging
Trusted Computing Group (www.trusted-
threats to the IT system supply chain,
computinggroup.org) is an example of an
there is room for greater collaboration
organization actively addressing this issue.
around a shared understanding of the
More Comprehensive Data on Today’s Practices and Controls • While SAFECode has offered the best
existing disciplines that can be leveraged across an even broader community.
thinking of its member companies in this
Measurement
important emerging area, the field could
• SAFECode is currently examining its mem-
be furthered by capturing broader data
bers’ practices on measuring software
from a larger segment of information
assurance. As that work evolves, there
technology vendors about their cur-
are sure to be implications for improv-
rent or preferred practices so that the
ing the exchange of integrity-related
overall community is guided by data as
measures among trading suppliers.
continuous improvements are made.
Software Integrity and Cloud Computing • The impact of cloud computing on the “traditional” view of software supply chain risks, as addressed in this paper, needs to be assessed. Software possesses many of the same characteristics inherent in other forms of intellectual property. As a result, issues associated with jurisdiction, access authorization and compliance need to be assessed for their impact on software integrity controls.
22
challenges, common terminology and
Conclusion SAFECode views software integrity as a fundamental pillar of software assurance. Protecting the integrity of software requires a set of controls that should be implemented
controls, as well as continue further study and analysis on additional practices and controls to improve software supply chain integrity.
Acknowledgments
alongside secure development and authentic-
Brad Arkin, Adobe Systems Incorporated
ity practices; indeed, integrity preserves and
Eric Baize, EMC Corporation
supports security and authenticity across
Matt Coles, EMC Corporation
the complexity of a supply chain. However, resources and best practices for identifying
Robert Dix, Juniper Networks, Inc.
and analyzing software integrity controls are
Yuecel Karabulut, SAP AG
not yet widely available, creating challenges
Paul Nicholas, Microsoft Corporation
for both software vendors and customers. While a software vendor is only one link in a complex IT solution supply chain and has a limited ability to influence the actions of the other entities along the chain, all soft-
Gary Phillips, Symantec Corporation Tyson Storch, Microsoft Corporation Kevin Sullivan, Microsoft Corporation Janne Uusilehto, Nokia
ware vendors have both the opportunity and responsibility to protect the integrity of the software as it moves through the link they control. This requires the application of software integrity controls to a vendor’s software sourcing, development and delivery processes. SAFECode believes the industry-wide adoption of software integrity controls has the potential to greatly improve customer confidence in IT systems. It has published this collection of best practices, which are based on the lessons its members have learned in their individual implementation of these controls, in an effort to provide guidance to others in the industry. SAFECode encourages the software industry to tailor and adopt these
23
About SAFECode The Software Assurance Forum for Excellence in Code (SAFECode) is a non-profit organization exclusively dedicated to increasing trust in information and communications technology products and services through the advancement 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. Its members include Adobe Systems Incorporated, EMC Corporation, Juniper Networks, Inc., Microsoft Corp., Nokia, SAP AG and Symantec Corp. For more information, please visit www.safecode.org.
SAFECode
(p) 703.812.9199
2101 Wilson Boulevard
(f) 703.812.9350
Suite 1000 Arlington, VA 22201
(email)
[email protected] www.safecode.org
© 2010 Software Assurance Forum for Excellence in Code (SAFECode)
