Speakers: Put your Name and Title here:---------xxxSWE2016xxx

Enhancing Enterprise Resilience through

Software Assurance and Supply Chain Risk Management

Enhancing Enterprise Resilience

through Software Assurance and Supply Chain Risk Management

Joe Jarzombek, CSSLPGlobal Manager, Software Supply Chain Management

Synopsys Software Integrity Group

Former Director, Software and Supply Chain Assurance,

Department of Homeland Security

Member, (ISC)2 Application Security Advisory Council

Gaining confidence in ICT/software-based technologies

• Dependencies on software-reliant

Information Communications

Technology (ICT) are greater

then ever

• Possibility of disruption is greater

than ever because hardware/

software is vulnerable and

exploitable

• Loss of confidence alone can

lead to stakeholder actions

that disrupt critical business

activities

Services• Managed Security• Information Services

Software• Financial Systems• Human Resources

Hardware• Database Servers• Networking Equipment

Internet• Domain Name System• Web Hosting

Control Systems• SCADA• PCS• DCS

Cyber Infrastructure

• Agriculture and Food

• Energy

• Transportation

• Chemical Industry

• Postal and Shipping

• Water

• Public Health

• Telecommunications

• Banking and Finance

• Key Assets

Critical Infrastructure / Key Resources

• Railroad Tracks• Highway Bridges• Pipelines• Ports• Cable• Fiber

• FDIC Institutions• Chemical Plants• Delivery Sites• Nuclear power plants• Government Facilities• Dams

Physical Infrastructure

• Reservoirs Treatment plants• Farms• Food Processing Plants• Hospitals• Power Plants• Production Sites

Today Everything’s Connected and Co-Dependent

When this Other System gets subverted through an un-patched vulnerability, a mis-configuration, an application weakness, or susceptibility to attack…

Your System is attackable or susceptible

to a hazard…

PrivacyCybersecurity

Interoperability

(Includes

Connectivity)

System

Performance

Software Upgrade Support

System

Reliability

50 billion devices

are expected to be

connected by 2020

By 2018, 66% of

networks will have

an IoT security

breach

What is the Need?

The success of IoT growth accelerates the need for connectivity solutions.

http://www.nibodha.com/blog/how-fog-computing-can-outsmart-cloud-computing/

What’s the Concern with Internet of Things (IoT)

• Lax security for the growing number of IoT embedded devices in

appliances, industrial applications, vehicles, TVs, smart homes,

smart cities, healthcare, medical devices, etc.

–Sloppy manufacturing ‘hygiene’ is compromising privacy, safety

and security for faster time to market

–IoT risks evolving from virtual harm to physical harm

–Cyber exploitation with physical consequences;

–Increased risk of bodily harm from hacked devices–…..

12

Barr Group: “Industry is not taking

safety & security seriously enough”

Based on results of survey of more than 2400

engineers worldwide to better understand the

state of safety- and security-aware embedded

systems design around the world (Feb 2016).

Engineering Community concerns: • Poorly designed embedded devices can kill;

• Security is not taken seriously enough;

• Proactive techniques for increasing safety

and security are used less often than they

should be.

Safety/Security Risks with IOT embedded systems

Shifting Concerns for Software Liability

1980’s 1990’s 2000’s 2010’s

Standalone Software Apps Internet & WWW Software Controlled Devices

Quality / Security / Safety &

Privacy

Quality / SecurityQuality

Financial Liability

Assurance relative to Trust

Quality Safety

Security

Managing Effects of Unintentional

Defects in Component or System

Integrity

Managing Consequences of

Unintentional Defects

Managing Consequences of Attempted/Intentional Actions Targeting Exploitable

Constructs, Processes & Behaviors

TRUST

Enterprises Have Used Reactive Technologies to Defend…They are good; designed for known threats. What about broader risks to enterprises and users?

Enterprises cannot stop the threats; yet can control their attack vectors/surfaces

© 2016 Synopsys, Inc.

Cross-site Scripting (XSS) Attack

(CAPEC-86)

Improper Neutralization of Input

During Web Page Generation

(CWE-79)

Security

Feature

SQL Injection Attack (CAPEC-66)

Improper Neutralization of Special

Elements used in an SQL Command

(CWE-89)

17

Exploitable Software Weaknesses (CWEs) are exploit targets/vectors

for future Zero-Day Attacks

Software-related Expectations for 2016

• Major breaches will be enabled by unpatched known vulnerabilities over 2 years old;

• Chained attacks and attacks via third-party websites will grow;

• Vulnerable web applications will remain easiest way to compromise companies;

• SQL Injection and XSS will constitute more frequent and dangerous vector of attacks;

• Third-party code and plug-ins will remain the Achilles heel of web applications;

• Server misconfigurations will continue to be a top source of vulnerability;

• Many vulnerabilities will be exploited in devices and systems that cannot be patched;

• Most software will be composed third party & open source (often unchecked) components;

o Primary causes of exploited vulnerabilities will be software defects, bugs, & logic flaws;

o Application logic errors will become more frequent and critical;

• Mobile apps will constitute a growing source of attack vectors, especially since many (in rush to

release) won’t be adequately tested for known vulnerabilities prior to use;

• More network-connectable devices in the Internet of Things will have exploitable weaknesses and

vulnerabilities publicly reported because of consumer risk exposures.

19• 92% of vulnerabilities in application layer not in networks (NIST)

• Over 70 % of security breaches happen at the Application (Gartner)

• Insufficient Application Security testing

– Often only done at the end of all development; security is often, at best, ‘bolted on.’ not ‘built in’

– Most developers lack sufficient security training

• If only 50% of software vulnerabilities were removed prior to production, costs would be reduced

by 75 % (Gartner)

• Data breaches exploit vulnerabilities in applications with root causes in unsecure software

• 90% of a typical application is comprised of open source components

– 58.1 million components with known vulnerabilities were downloaded from (maven) repository

– 71 % of applications have a critical or severe vulnerability in their open source components

– This causes a Software Supply Chain Issue

US DHS CIO Enterprise Services reported:

Source: US Department of Homeland Security “CARWASH” program presentation to

interagency Software & Supply Chain Assurance Forum, Dec 2014

90% of all reported security incidents result from

exploits against defects in software

Exploitable Weaknesses, Vulnerabilities & Exposures• Weakness: mistake or flaw condition in ICT

architecture, design, code, or process that, if left unaddressed, could under the proper conditions contribute to a cyber-enabled capability being vulnerable to exploitation; represents potential source vectors for zero-day exploits -- Common Weakness Enumeration (CWE) https://cwe.mitre.org/

• Vulnerability: mistake in software that can be directly used by a hacker to gain access to a system or network; Exposure: configuration issue of a mistake in logic that allows unauthorized access or exploitation – Common Vulnerability and Exposure (CVE) https://cve.mitre.org/

• Exploit: take advantage of a weakness (or multiple weaknesses) to achieve a negative technical impact --attack approaches from the set of known exploits are used in the Common Attack Pattern Enumeration and Classification (CAPEC) https://capec.mitre.org

• The existence (even if only theoretical) of an exploit designed to take advantage of a weakness (or multiple weaknesses) and achieve a negative technical impact is what makes a weakness a vulnerability.

CVEs(reported, publicly known vulnerabilities and exposures)

VULNERABILITIES

WEAKNESSES

CWEs(characterized, discoverable, possibly exploitable weaknesses with mitigations)

Zero-Day Vulnerabilities(previously unmitigated weaknesses that are exploited with little or no warning)

Uncharacterized Weaknesses

Unreported or undiscovered Vulnerabilities

CVE, CWE, & CAPEC are part of the ITU-T CYBEX 1500 series

• Enable ‘scalable’ detection and reporting of tainted

ICT components

• Leverage related existing standardization efforts

• Leverage taxonomies, schema & structured

representations with defined observables &

indicators for conveying information:

o Tainted constructs:

Malicious logic/malware (MAEC),

Exploitable Weaknesses (CWE);

Vulnerabilities (CVE)

o Attack Patterns (CAPEC)

• Leverage Catalogued Diagnostic Methods, Controls,

Countermeasures, & Mitigation Practices

• Use publicly reported weaknesses and vulnerabilities

with patches accessible via National Vulnerability

Database (NVD) sponsored by DHS; hosted by NIST

*Text demonstrates examples of overlap

Components can become tainted intentionally or unintentionally

throughout the supply chain, SDLC, and in Ops & sustainment

Software & Supply Chain Assurance Focus on Components Mitigating risks attributable to tainted, exploitable non-conforming constructs in ICT

“Tainted” products are those that are corrupted with malware, and/or exploitable weaknesses & vulnerabilities

that put enterprises and users at risk

COUNTERFEIT

AUTHENTIC

DEFECTIVE

Exploitable

weakness

Malware

Unpatched

Vulnerability

Exploitable

weakness

Unpatched

Vulnerability

TAINTED[exploitable weakness,

vulnerability, or

malicious construct]

Malware

International Uptake in Standards Bodies..

ISO/IECSPANISH

FRENCH

RUSSIANCHINESE

ARABIC

CVE Can Be Used to Assess Software Maturity

• Are the commercial and open source applications being used as part of the system, the

development environment, the test environment, and the maintenance environment

patched for known CVEs?

• Are any components/libraries incorporated in the system that have CVEs?

• Have pen testing tools/teams found any CVEs?

• Does the project team monitor for Advisories?

• Does the project team utilize CVSS scores to prioritize remediation efforts?

• Is the use of CVE Identifiers and public advisories a consideration when selecting

commercial and open source applications?

Assurance Comes From Mitigating/Managing Weaknesses

& Vulnerabilities that represent attack vectors/surfaces

Threat

Threat Vector

Weakness

Eliminate Mitigate

Block from Attack Alarm for Attack/Exploit

Vulnerability

Control

Implementation

Test

STOP Acceptable Impact

CWE

CAPEC

CVE

Increased risk from supply chain due to:

• Increasing dependence on commercial ICT for enterprise business/mission critical systems

• Increasing reliance on globally-sourced ICT hardware, software, & services

• Varying levels of development/outsourcing controls

• Lack of transparency in process chain of custody

• Varying levels of acquisition ‘due-diligence”

• Residual risk passed to end-user enterprise

• Defective and Counterfeit products

• Tainted products with malware, exploitable weaknesses and vulnerabilities

• ICT services lacking adequate security controls

• Growing technological sophistication among our adversaries

• Internet enables adversaries to probe, penetrate, and attack us remotely

• Supply chain attacks can exploit products and processes throughout the lifecycle

Software Integrity / Supply Chain Risk Management Imperative

Risk Management (Enterprise Project):Shared Processes & Practices Different Focuses

•Enterprise-Level:– Regulatory compliance

– Changing threat environment

– Business Case

•Program/Project-Level: – Cost

– Schedule

– Performance

Who makes risk decisions?

Who determines ‘fitness for use’ for ‘technically acceptable’ criteria?

Who “owns” residual risk from tainted/counterfeit products?

* “Tainted” products are those that are corrupted with malware, or exploitable weaknesses & vulnerabilities

Have Products on your Whitelisted, Approved or

“Assessed & Cleared” Products List been Tested

for Exploitable Weaknesses (CWEs)?

If suppliers do not mitigate exploitable

weaknesses or flaws in products (which are

difficult for users to mitigate), then those

weaknesses represent vectors of future of

exploitation and ‘zero day’ vulnerabilities.

Have Products on your Whitelisted, Approved

or “Assessed & Cleared” Products List been

Tested for Known Vulnerabilities (CVEs)?

If suppliers cannot mitigate known

vulnerabilities prior to delivery and use, then

what level of confidence can anyone have that

patching and reconfiguring will be sufficient

or timely to mitigate exploitation?

Today, Up to 90% of an Application

Consists of Third-Party Code

Today, Up to 90% of an Application

Consists of Third-Party CodeThird-Party Code

( Free Open Source

Software or FOSS )

First-Party

Custom Code

Third-Party Code

(Commercial Off-

The-Shelf,

Internally

developed, …)

Do you trust what’s in your Third-Party Code?

0

100

200

300

400

500

600

700

4/2

/200

8

7/2

/200

8

10/2

/20

08

1/2

/200

9

4/2

/200

9

7/2

/200

9

10/2

/20

09

1/2

/201

0

4/2

/201

0

7/2

/201

0

10/2

/20

10

1/2

/201

1

4/2

/201

1

7/2

/201

1

10/2

/20

11

1/2

/201

2

4/2

/201

2

7/2

/201

2

10/2

/20

12

1/2

/201

3

4/2

/201

3

7/2

/201

3

10/2

/20

13

1/2

/201

4

4/2

/201

4

7/2

/201

4

10/2

/20

14

1/2

/201

5

4/2

/201

5

7/2

/201

5

10/2

/20

15

Co

mp

ilati

on

da

te f

or

the

old

est

3rd

pa

rty c

om

po

ne

nt

is A

pr,

2008

Software released circa Aug 2008.

Total of 22 unique CVEs affecting total of

2 unique 3rd party components when the software was released.

None of these had CVSS score of 10.

Un

iqu

e k

no

wn

vu

lne

rab

ilit

ies

( C

VE

s )

Software ‘decays’ over time without patches

Same software in Feb 2015. Total of 582 unique CVEs

affecting total of 60 unique 3rd party components.

74 of these had CVSS score of 10.

• Commercial product

• Released in Feb 2010

• Leverages total of 81 3rd

party components

• Near clean bill of health on

release

• New vulnerability affects

one of products

components on average

every 5 days

• 7 years later product

should no longer be

considered safe to use

Challenge: Many products are delivered with unpatched, known vulnerabilities

Implications for Leading Network Equipment Manufacturer

99% of all the products

use Open Source

60% of all the code is

Open Source

69% of all security

defects are from Open

Source

(post release)

Average defect age: 441

days

10% of high

visibility

vulnerabilities

originate from

open source

400 new products a year

Software Composition Analysis is Needed

Because Code Travels …

Commercial off the shelf

(COTS) 3rd party code

Free Open Source

Software (FOSS) under

GPL, AGPL, MPL,

Apache and other

licenses

Unauthorized, potentially

malicious and counterfeit code

Out-dated, vulnerable code

Outsourced code development

Floodgate – Software Signoff

Sea of downstream businesses

that use software from upstream

Copy - paste code

First party code

Taking Action

• Software and applications have to ship. That is the bottom line. We need software to do things, regardless of the risk.

• Organizations need to sign off on security, and will do so regardless of of the veracity of their information.

• True cyber assurance means having a signoff process that enables advancement in technologies and ultimately product features, rather than expending too many cycles reacting to big security challenges.

FS-ISAC 3rd Party Software Security Working Group

SDLC

App Testing

Protocol and policy testing

Software Composition Analysis

Procurement language

Who Should Be Testing and Why

Why: Because all stakeholders are affected by failures in cyber security (but in different ways).

However, not all links in the chain are as well-suited to perform testing.

At some point someone

(usually the end user) has to validate and

verify.

Who: All Stakeholders In

The Supply Chain

Some Prioritized Lists To ConsiderNot Exhaustive…But A Good Start

• SANS CWE Top 25 – A list of the top 25 most commonly encountered Cyber Weakness Enumerators (CWEs), found in (https://www.sans.org/top25-software-errors/ )

• OWASP Top 10 Vulnerabilities – A list of the 10 Most Critical Web Application Security Risks compiled by OWASP (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project )

• Verizon Report Top 10 CVEs – List of the 10 most commonly encountered Common Vulnerabilities and Exposures (CVEs) used in exploits (http://news.verizonenterprise.com/2015/04/2015-data-breach-report-info/ )

Types of Automated Tools/Testing

• Dynamic Runtime Analysis – Finds security issues during runtime, which can be categorized as CWE’s

– Malformed input testing (fuzz testing, DoS testing) – Finds zero-days and robustness issues through negative testing.

– Behavioral analysis – Finds exploitable weaknesses by analyzing how the code behaves during “normal” runtime.

• Software Composition Analysis – Finds known vulnerabilities and categorizes them as CVE’s and other issues.

• Static Code Analysis – Finds defects in source code and categorizes them as CWE’s.

• Known Malware Testing – Finds known malware (e.g. viruses and other rogue code).

Generally speaking, all of these tests can be used to enumerate CVE’s and CWE’s (and CQE’s when available), which can be further categorized into prioritized lists.

What They Find; How They Support Origin Analysis & Risk Management

PLATFORM

Reporting Bug tracking integration Workflow integration IDE plugins SCM integration

PRODUCTS

Coverity

Static

Analysis

Defensics

Protocol

Fuzzing

Protecode

Software

Composition

Analysis

Seeker

Interactive

Application Security

Testing

Test Advisor

Test Optimization

Synopsys Software Integrity Platform

Signoff for

Software Development

Signoff for

Supply Chain Management

What Malformed Input Testing Finds

• Essentially, ways to get a system or application to misbehave or fail through misuse (intentional or otherwise).

• This can be as simple as a single bad packet.

• Once failure modes occur they can lead to ways to ways to take down a system or introduce malware (or both).

Software Composition Analysis (SCA):

Components of Software

Composition Analysis (SCA)

solution:

• Software Bill of Materials (BOM)

identification and management

• Vulnerability assessment and

tracking

• [FOSS] license management and

export compliance

Securing Software Through Software

Composition Analysis (SCA):

Comprehensive Software Composition Analysis (SCA)

Development Teams

IT

Software

Composition

Analysis (SCA)

Solution

Scan and Report Components

with Known Security

Vulnerabilities

Detect and manage 3rd party

and open source components

or portions thereof

The versatility and breadth of

this solution makes it viable for

many use cases and appealing

to many personas

Ensure Licensing, IP, and

Export Control Compliance

What Software Composition Analysis Finds

• Looks at compiled code and determines what third-party (or proprietary) components it is built from.

• Queries databases of known vulnerabilities for identified components and lists them out. Finds CVEs.

• Can automatically track vulnerabilities in a software package over time.

• Leverage CVSS (v3 now available) to prioritize mitigation since not all identified vulnerabilities are necessarily exposed.

An Ingredient List (Bill of Materials)

Simply knowing software “ingredients” arms a user with an

enormous resource for determining risk.

What Static Code Analysis Finds

• Identifies defects in source

code.

• Identifies CWEs and quality

issues (CQEs in future)

• Like software composition

analysis, can be used for

prioritizing risks because

identified defects can range

from trivial (low or no real

risk) to critical (high risk).

What Known Malware Analysis Finds

• This is the new generation of antivirus type tools with a lot of additional capabilities and features.

• Malware is created to exploit vulnerabilities, or simply run “uninvited” as privileged applications in an environment that allows such actions.

• Tools need to check for existence of malware against a known database. Some tools use heuristics.

2016 Cyber Insurance Buying Guide

Adopted By The World Of Finance

• Joint effort between US Treasury,

American Bankers Association,

and Financial Services

Coordinating Council

• Guidance document US Treasury

is expecting banks to follow

• Banks currently held liable for

third-party vulnerabilities

2016 Cyber Insurance Buying Guide

Source: Financial Services Sector Coordinating Council

for Critical Infrastructure Protection and Homeland Security

2016 Cyber Insurance Buying Guide

• Cyber Risk and Cyber Insurance

• The Cyber Insurance Market

• The Value Proposition for Cyber Insurance

• Where and How to Begin

• How Much Insurance Should be Purchased

• Existing Policy Cyber Coverage Exposure Gaps

• Awareness When Shopping for a Cyber Policy

– Policy Construction – Insuring Agreements

– Key Exclusions/Sublimits

• Supply Chain Cyber Assurance –

Procurement RequirementsSource: Financial Services Sector Coordinating Council

for Critical Infrastructure Protection and Homeland Security

Supply Chain Cyber Assurance – Procurement Requirements

• Product Development Specification and Policy

• Security Program

• System Protection and Access Control

• Product Testing and Verification

– Communication Robustness Testing

– Software Composition Analysis

– Static Source Code Analysis

– Dynamic Runtime Analysis

– Known Malware Analysis

– Bill of Materials

– Validation of Security Measures

• Deployment and Maintenance

American Banking Associon (ABA) and FSSCC

Cyber Insurance Purchasing Guide

• Regulators now hold banks and FIs accountable for third party cyber failure.

– Regulators and Financial Institutions (Fis) have no mechanism to manage or measure third party cyber risk.

– This procurement language creates such a mechanism for both regulators and banks.

• Procurement language helps them be better manage risk.

Automotive Cybersecurity Moving Ahead

• Huge support from automotive OEM

and suppliers for cybersecurity testing

standards.

• SAE security committee members have

agreed to create cybersecuity testing

requirements

• SAE is presenting procurement

language to all software working

groups and also considering making

me the chair of my own group.

Strengthening Our Nation’s Cybersecurity

“The Department of Homeland Security is

collaborating with UL and other industry

partners to develop a Cybersecurity

Assurance Program to test and certify

networked devices within the “Internet of

Things,” so that when you buy a new

product, you can be sure that it has been

certified to meet security standards.”https://www.whitehouse.gov/the-press-office/2016/02/09/fact-sheet-cybersecurity-

national-action-plan

Issued February 9th, 2016

UL Cybersecurity Assurance Program

UL Cybersecurity Assurance Program (UL CAP) will be Product

Oriented & Industry Specific with these goals:

Reduce software vulnerabilities

Reduce weaknesses, minimize exploitation

Address known malware

Increase security awareness

Product service offerings apply to:

Connectable Products

Products Eco-Systems

Products System Integration

Critical IT Infrastructure Integration

UL 2900-3: Organizational Process

UL 2900-2-1, -2-2: Industry Specific Requirements

UL 2900-1: CAP General Requirements/

The UL Cyber Assurance Program (UL CAP)

• Program in includes:

– Malformed Input Testing (Fuzz Testing and DoS Testing)

– For all externally accessible protocols

– Other programs only include a small subset (for example 1 well

know program only covers 6 protocols - none are application level

protocols)

– Software Composition Analysis

– Compiled code

– Up to 90% of all code is third-party

– Malware Analysis

– Know malware

– Static Code Analysis – Source Code

– Runtime Analysis – Running code

– Penetration Testing – Hands on testing

UL Cybersecurity Assurance Program

• Underwriters Labs CAP

2900 series –

–Addresses known vulnerabilities at the

time of certification (i.e. CVEs

catalogued in the NVD)

–Performs baseline weakness

assessment for potential “zero day”

vulnerabilities (CWSS and scoring

priorities from others’ Top ‘N’ lists)

–Addresses known malware at time of

certification

Addressing the most relevant CWEs, establishes a baseline to

mitigate weaknesses that, if otherwise exploited, could be vectors of

attack; becoming zero-day vulnerabilities

Underwriters Labs Cybersecurity Assurance Program

(CAP) Scope Assessment of Product and Organizational Processes

CAP Elements

Product Assessment

Organizational

Assessment

Description

• The absence, with a reasonable degree of certainty, of any known vulnerabilities

(NVD), weaknesses that could turn into zero-day vulnerabilities, and known

malware in the assessed product

• The presence of applicable security controls in (the design of) the assessed product

and the correct implementation of these: security controls needed to address the

identified risks for a certain product type

• The software lifecycle processes of the vendor for the software in the assessed

product.

• Patch management (general)

• Secure Development Life Cycle

• Industry-specific processes, such as for the medical industry:

• Application of risk management

• Quality management systems

• Software life cycle processes

Best-in-class solutions Fully integrated into existing workflows

Technologies Methodology

• Static Analysis

• Protocol Fuzzing

• Software Composition Analysis

• Interactive Application Security Testing

• Test Optimization

• Integrated third party certification

• Internal policy enforcement

• Software Development Lifecycle integration

• International standards compliance

+

Ingredients for Software Signoff

Software Signoff in the Supply Chain

Introducing test gates in the

SW development process

Signoff for

Software Development

• Release criteria

• Agile feature acceptance

• Required for successful build

• Required for code check-in

Code Check-in

Compile & Build

Feature Readiness

Product Release

Introducing test gates in the

SW delivery process

• Legal compliance

• Regulatory compliance

• Industry compliance

• Best practices compliance

Signoff for

Supply Chain Management

The Benefits of Software Signoff

Legal Compliance Risk Management Accountability …

Purchasing Cost Management Compliance Quality …

CEO Risk Management Accountability Competitive Advantage …

Security VP Risk Management Compliance Accountability …

R&D VP/Manager Predictability Quality Cost Management …

Developer Efficiency Quality Predictability …

© 2016 Synopsys, Inc.

Joe Jarzombek, CSSLP

Global Manager, Software Supply Chain Management

Synopsys Software Integrity Group

Joe.Jarzombek@synopsys.com

+1 (703) 627-4644

Enhancing Enterprise Resilience

through Software Assurance and

Supply Chain Risk Management