Risks in the Software Supply Chain

© 2015 Carnegie Mellon University
Risks in the Software
Supply Chain
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Mark Sherman, Ph.D.
Technical Director, CERT
Jan 15, 2015

2
Risks in the Software Supply Chain
Mark Sherman, 15-Jan-2015
Copyright 2015 Carnegie Mellon University
This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie
Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center.
Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the
views of the United States Department of Defense.
References herein to any specific commercial product, process, or service by trade name, trade mark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering
Institute.
NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS
FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE
OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON
UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK,
OR COPYRIGHT INFRINGEMENT.
This material has been approved for public release and unlimited distribution.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting
formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at
permission@sei.cmu.edu.
Carnegie Mellon®, CERT® and CMMI® are registered marks of Carnegie Mellon University.
DM-0002130

3
Conventional view of supply chain risk
Sources: http://www.nytix.com/NewYorkCity/articles/handbags.html; http://www.laserwisetech.co.nz/secret.php;
http://www.muscatdaily.com/Archive/Oman/Fake-car-parts-contribute-to-rise-in-road-accidents-Experts;
http://www.andovercg.com/services/cisco-counterfeit-wic-1dsu-t1.shtml; http://unites-systems.com/l.php?id=191

4
Software is the new hardware – IT
IT moving from specialized
hardware to software, virtualized
as
• Servers: virtual CPUs
• Storage: SANs
• Switches: Soft switches
• Networks: Software defined
networks

5
• Cellular
• Main processor
• Base band processor
• Secure element (SIM)
• Automotive
• Up to 100 networked CPUs in luxury cars
• Vehicle to infrastructure (V2I)
• Vehicle to vehicle (V2V)
• Industrial and home automation
• 3D printing (additive manufacturing)
• Autonomous robots
• Interconnected SCADA
• Aviation
• 80% of airplane function in software
• Next Gen air traffic control
• Smart grid
• Smart electric meters
• Smart metering infrastructure
• Embedded medical devices
Software is the new hardware – cyber physical

6
Software is the new hardware – everything
90 percent of [Samsung’s] products -- which
includes everything from smartphones to
refrigerator-- would be able to connect to
the Web by 2017. In five years, every
product in the company's entire catalog
would be Internet connected.
B.K. Yoon, Samsung co-CEO
CNET
Jan 5, 2015
Source: http://www.cnet.com/news/samsung-co-ceo-in-5-years-all-our-products-will-be-internet-connected/
http://www.wsj.com/articles/SB10001424053111903480904576512250915629460
Software is eating the world.
Marc Andreessen, WSJ, Aug 20,2011

7
Evolution of software development
Custom development – context:
• Software was limited
 Size
 Function
 Audience
• Each organization
employed developers
• Each organization created
their own software
Shared development – ISVs
(COTS) – context:
• Function largely understood
 Automating existing processes
• Grown beyond ability for
using organization to
development economically
• Outside of core
competitiveness by
acquirers
Supply chain: practically none Supply chain: software supplier

8
Development is now assembly
General
Ledger
SQL Server WebSphere
HTTP
server
XML Parser
Oracle DB
SIP servlet
container
GIF library
Note: hypothetical application composition
Collective development –
context:
• Too large for single
organization
• Too much specialization
• Too little value in individual
components
Supply chain: long

9
Software supply chain for assembled software
Expanding the scope and complexity of acquisition and deployment
Visibility and direct program office controls are limited (only in shaded
area)
Source: “Scope of Supplier Expansion and Foreign
Involvement” graphic in DACS
www.softwaretechnews.com Secure Software Engineering,
July 2005 article “Software Development Security: A Risk
Management Perspective” synopsis of May 2004 GAO-04-
678 report “Defense Acquisition: Knowledge of Software
Suppliers Needed to Manage Risks”

10
Corruption along the supply chain is easy
Knowledgeable
analysts can convert
packaged binary into
malware in minutes
Sources: Pedro Candel, Deloitte CyberSOC Academy , Deloitte
http://www.8enise.webcastlive.es/webcast.htm?video=08; http://www.microsoft.com/Products/Games/FSInsider/freeflight/PublishingImages/scene.jpg;
https://www.withfriendship.com/user/mithunss/easter-eggs-in-microsoft-products.php
Unexpected or
unintended
behaviors in
components

11
Substantial open source contained in supply chain
• At least 75% of organizations rely on
open source as the foundation of their
applications
• Most applications are now assembled
from hundreds of open source
components, often reflecting as much
as 90% of an application.
Distributed development –
context:
• Amortize expense
• Outsource non-differential
features
• Lower acquisition (CapEx)
expense
Source: Sonatype, 2014 Sonatype Open Source Development and Application Security Survey
Supply chain: opaque

12
Open source supply chain has a long path
App server
HTTP
server
XML
Parser
C
Libraries
C compiler
Generated
Parser
Parser
Generator
2nd
Compiler

13
Versions of Android illustrate open source
fragmentation
Source: http://opensignal.com/reports/fragmentation.php
.

14
Open source is not secure
Heartbleed and
Shellshock were found
by exploitation
Other open source
software illustrates
vulnerabilities from cursory
inspection
Sources: Steve Christey (MITRE) & Brian Martin (OSF), Buying Into the Bias: Why Vulnerability Statistics
Suck, https://media.blackhat.com/us-13/US-13-Martin-Buying-Into-The-Bias-Why-Vulnerability-Statistics-
Suck-Slides.pdf; Sonatype, Sonatype Open Source Development and Application Security Survey
46 million vulnerable open
source components
downloaded annually

15
Reducing software supply chain risk
factors
Software supply chain risk for
a product needs to be reduced
to acceptable level
Supplier follows
practices that
reduce supply
chain risks
Delivered or
updated product
is acceptably
secure
Product
Distribution
Operational
Product
Control
Product is used in
a secure manner
Methods of
transmitting the
product to the
purchaser guard
again tampering
Product
Security
Supplier
Capability

16
Supplier security commitment evidence
Supplier employees are educated as to security engineering practices
• Documentation for each engineer of training and when trained/retrained
• Revision dates for training materials
• Lists of acceptable credentials for instructors
• Names of instructors and their credentials
Supplier follows suitable security design practices
• Documented design guidelines
• Provides evidence that design and coding weaknesses that affect security
have been addressed (Common Weakness Enumeration (CWE))
• Has analyzed attack patterns appropriate to the design such as those that are
included in Common Attack Pattern Enumeration and Classification (CAPEC)

17
Evaluate a product’s threat resistance
What product characteristics minimize opportunities to enter and change
the product’s security characteristics?
• Attack surface evaluation: Exploitable features have been identified and
eliminated where possible
– Access controls
– Input/output channels
– Attack enabling applications – email, Web
– Targets
• Design and coding weaknesses associated with exploitable features have
been identified and mitigated (CWE)
• Independent validation and verification of threat resistance

18
Establishing good product distribution practices
Recognize that supply chain risks are accumulated
• Subcontractor/COTS-product supply chain risk is inherited by those that use
that software, tool, system, etc.
Apply to the acquiring organizations and their suppliers
• Require good security practices by their suppliers
• Assess the security of delivered products
• Address the additional risks associated with using the product in their context

19
Maintain attack resistance
Who assumes responsibility for preserving product attack resistance
with product deployment?
• Patching and version upgrades
• Expanded distribution of usage
• Expanded integration
Usage changes the attack surface and potential attacks for the product
• Change in feature usage or risks
• Are supplier risk mitigations adequate for desired usage?
• Effects of vendor upgrades/patches and local configuration changes
• Effects of integration into operations (system of systems)

20
What about open source?
Establish a supplier for open
source
• Self
• 3rd party focusing on open
source
Subject to same evaluation
• Supplier capability
• Product security
• Product distribution
• Operational product control
Source: http://opensource.org/

21
Business decisions are about risk
There are many risks to a business
process or mission thread
• Within a system
• Collection of systems
Supply chain is one of many risk
components
Evaluate software supply chain risk
in the larger context of
• Supply chain risk
• System risk
• System of systems risk

22
Security Engineering Risk Analysis (SERA )
1. Establish
operational context.
2. Identify risk.
3. Analyze risk.
4. Develop control
plan.
Mission Thread /
Business Process
Worksheet
Risk
Identification
Worksheet
Risk
Evaluation
Criteria
Risk
Analysis
Worksheet
Control
Approach
Worksheet
Control
Plan
Worksheet

23
Where to start
Anywhere
• 76% do not have meaningful
controls over what components
are in their applications
• 81% do not coordinate their
security practices in various
stages of the development life
cycle
• 47% do not perform acceptance
tests for third-party code
Plenty of models to choose from
BSIMM: Building Security in
Maturity Model
CMMI: Capability Maturity Model
Integration for Acquisitions
PRM: SwA Forum Processes and
Practices Group Process
Reference Model
RMM: CERT Resilience
Management Model
SAMM: OWASP Open Software
Assurance Maturity Model
Sources: Sonatype, 2014 Sonatype Open Source Development and Application Security
Survey; Forrester Consulting, “State of Application Security,” January 2011

24
Further reading
Alberts, Christopher, et al., “Introduction to the Security Engineering Risk Analysis (SERA) Fraemwork,” Software Engineering Institute, Nov
2014, http://resources.sei.cmu.edu/asset_files/TechnicalNote/2014_004_001_427329.pdf
Axelrod, C. Warren, “Mitigating Software Supply Chain Risk,” ISCA Journal Online, Vol 4., 2013, http://www.isaca.org/Journal/Past-
Issues/2013/Volume-4/Pages/JOnline-Mitigating-Software-Supply-Chain-Risk.aspx
Axelrod, C. Warren, “Malware, Weakware and the Security of Software Supply Chains,” Cross-Talk, March/April 2014, p. 20,
http://www.crosstalkonline.org/storage/issue-archives/2014/201403/201403-Axelrod.pdf
Ellison, Robert, et al, “Software Supply Chain Risk Management: From Products to Systems of Systems,” Software Engineering Institute,
Dec 2010, https://resources.sei.cmu.edu/asset_files/technicalnote/2010_004_001_15194.pdf
Ellison, Robert, et al. “Evaluating and Mitigating Software Supply Chain Security Risks,” Software Engineering Institute, May 2010,
http://resources.sei.cmu.edu/asset_files/technicalnote/2010_004_001_15176.pdf
Ellison, Robert and Woody, Carol, “Supply-Chain Risk Management: Incorporating Security into Software Development,” Proceedings of the
43rd Hawaii International Conference on System Sciences, 2010,
http://resources.sei.cmu.edu/asset_files/WhitePaper/2013_019_001_297341.pdf
Jarzombek, Joe, “Collaboratively Advancing Strategies to Mitigate Software Supply Chain Risks,” July 30, 2009,
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2009-07/ispab_july09-jarzombek_swa-supply-chain.pdf
Software Assurance Forum, Processes and Practices Working Group, “Software Assurance Checklist for Software Supply Chain Risk
Management,” https://buildsecurityin.us-cert.gov/sites/default/files/20101208-SwAChecklist.pdf
“Software Supply Chain Risk Management & Due-Diligence,” Software Assurance Pocket Guide Series: Acquisition & Outsourcing, Vol II,
Version 1.2, June 16, 2009, https://buildsecurityin.us-cert.gov/sites/default/files/DueDiligenceMWV12_01AM090909.pdf

25
Contact Information Slide Format
Mark Sherman
Technical Director
Cyber Security Foundations
Telephone: +1 412-268-9223
Email: mssherman@sei.cmu.edu
U.S. Mail
Software Engineering Institute
Customer Relations
4500 Fifth Avenue
Pittsburgh, PA 15213-2612
USA
Web
www.sei.cmu.edu
www.sei.cmu.edu/contact.cfm
Customer Relations
Email: info@sei.cmu.edu
Telephone: +1 412-268-5800
SEI Phone: +1 412-268-5800
SEI Fax: +1 412-268-6257

Risks in the Software Supply Chain

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à Risks in the Software Supply Chain

Similaire à Risks in the Software Supply Chain (20)

Plus de Sonatype

Plus de Sonatype (20)

Dernier

Dernier (20)

Risks in the Software Supply Chain