Enabling Enterprise Resilience & Cyber Security … Enterprise Resilience & Cyber Security Assurance...

© 2016 Synopsys, Inc.

OMG Cyber Risk Summit

Pillars of Cyber Risk as Competitive Advantage: Enabling Enterprise Resilience & Cyber Security Assurance

through Software Supply Chain Management

mailto:[email protected]


Real Value of Assets

Analytics

&

Accuracy

Speed

&

Flexibility Transparency

Cyber Risk Governance

Culture

Leadership

Alignment

Structure & Systems




1 Microsoft

2 Oracle

3 SAP

4 Symantec

5 VMware

6 Salesforce

7 Intuit

8 CA Technologies

9 Adobe

10 Teradata

11 Amdocs

12 Cerner

13 Citrix

14 Autodesk

15 Sage Group

16 Synopsys

17 Akamai Technologies

18 Nuance

19 Open Text

20 F5 Networks

Top 20 Global

Software Companies

Synopsys Financial Snapshot

2015 Revenue: $2.242B

$-

$500

$1,000

$1,500

$2,000

Engineering Culture

Total Employees: ~10,000

Engineers: 50%

Software Integrity Group: ~500

Global Reach

#1 global market

leader in

Electronic Design

Automation (EDA)

#2 in

Semiconductor IP

From Silicon to Software


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 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 • Life-essential Systems • Business Systems • Financial Systems • Human Resources • …..

Logic-baring 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

• Railway Systems • Transportation Vehicles • Highway Bridges • Pipelines • Ports • Cable and Fiber

• Financial 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

Cyber Infrastructure is enable and controlled by software

© 2016 Synopsys, Inc. 5

Physical and Cyber Security Are Fundamentally Different

Anytime – Persistent Risk

Vulnerabilities Are Deeply

Hidden

• Very hard to find even with

sophisticated tools and methods

• Small change of code or

configuration can open new security

holes

Massive – Largescale Attack

Attacks Can Be Automated

• Single vulnerability in widely shared

software can be exploited

everywhere at the same time by

automation

• Example – All traffic lights in a city

disabled at the same time

Anyone – Lone Wolf or Nation State

Attacks Can Be Done Remotely

• Network access sufficient to attack from

anywhere in the world

• Very difficult to trace

• Impossible to prosecute


An ever-more connected world . . .

People

•Wellness monitoring

•Medical case management

•Social needs

Communities

•Traffic status

•Pollution alerts

• Infrastructure checks

Goods & Services

•Track materials

•Speed distribution

•Product feedback

Environment

•Pollution checks

•Resource status

•Water monitoring

Homes

•Utilities control

•Security monitoring

•Structure integrity


Cyber Risks and Consequences in IoT Solutions

• Edge Devices (including Applications, Sensors, Actuators, Gateways & Aggregation)

–Device Impersonation and Counterfeiting

–Device Hacking

–Snooping, Tampering, Disruption, Damage

• IoT Platform (Data Ingestion/Analytics, Policy/Orchestration, Device/Platform Mgmt)

–Platform Hacking

–Data Snooping & Tampering

–Sabotaging Automation & Devices

• Enterprise (Business/Mission Applications, Business Processes, etc)

–Business/Mission Disruption

–Espionage & Fraud

–Financial Waste


Growing 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, me dical devices, etc.

– Sloppy manufacturing ‘hygiene’ is compromising privacy, safety

and security – incurring risks for faster time to market

– IoT risks provide more source vectors for financial exploitation

– IoT risks evolving from virtual harm to physical harm

– Cyber exploitation with physical consequences;

– Increased risk of bodily harm from hacked devices


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 Business Concerns: Increased Software Liability

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

Standalone Software Apps Internet & WWW

Quality / Security / Safety & Privacy Quality / Security Quality

Financial Liability

Software Controlled Devices


Increased risk from supply chain due to:

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

• Increasing reliance on globally-sourced ICT/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 Unauthentic/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 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


1. Consider “supply chain security issues for all resource planning and management activities throughout the system development life cycle;”

2. Analyze risks (including supply chain risks) associated with potential contractors and the products and services they provide, for all IT acquisitions; and

3. Allocate risk responsibility between Government and contractor when acquiring IT.

4. Develop, implement, document, maintain, and oversee agency-wide information security and privacy programs;

5. Implement supply chain risk management principles to protect against the insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software, as well as poor manufacturing and development practices throughout the system development life cycle;

6. Develop supply chain risk management plans as described in NIST SP 800-161 (SCRM Practices) to ensure the integrity, security, resilience, and quality of information systems.

Office of Management and Budget (OMB) Circular A-130, Revised July 28, 2016, specifies six specific requirements directly related to improving agencies’ supply chain risk management (SCRM) capabilities


NIST SP 800-161 SCRM Plan Flow Chart (Acquisition)


“2015 US State of Cybercrime Survey”

• 19% of CIOs are not concerned about supply-chain risks

• Only 42% of respondents consider supplier risks

• 23% do not evaluate third parties at all

• Most companies do not have a process for assessing

security of third-party partner capabilities before they do

business with them

Blind spot: Emerging Threat from Cyber Supply Chains


Assurance Required for Gaining Confidence and Trust

Quality Safety

Security

Managing Effects of Unintentional

Defects in Component or System

Integrity

Managing Consequences of

Unintentional Defects

Managing Effects and 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


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)

19

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.


21 • 92% of vulnerabilities are 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)

• 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

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

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


• Enable ‘scalable’ detection, reporting and mitigation

of tainted ICT/software 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 software

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

enterprises and users at risk

UNAUTHENTIC / COUNTERFEIT

AUTHENTIC

DEFECTIVE

Exploitable

weakness

Malware

Unpatched

Vulnerability

Exploitable

weakness

Unpatched

Vulnerability

TAINTED [exploitable weakness,

vulnerability, or

malicious construct]

Malware

International uptake in security automation standards via ITU-T CYBEX 1500 series


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 & USG SCAP

https://capec.mitre.org/about/glossary.html



https://cwe.mitre.org/

https://cve.mitre.org/


https://capec.mitre.org/





• X.1500 Overview of cybersecurity information exchange

• X.1520 Common vulnerabilities and exposures (CVE)

• X.1521 Common vulnerability scoring system (CVSS)

• X.1524 Common weakness enumeration (CWE)

• X.1525 Common weakness scoring system (CWSS)

• X.1526 Language for open definition of vulnerabilities and for assessment of a system state

• X.1528 Common platform enumeration (CPE)

X.1528.1 CPE naming /.2 CPE name matching /.3 CPE dictionary /.4 CPE applicability language

• X.1541 Incident object description exchange format

• X.1544 Common attack pattern enumeration and classification (CAPEC)

• X.1546 Malware attribute enumeration and characterization (MAEC)

• X.1570 Discovery mechanisms in the exchange of cybersecurity information

• X.1580 Real-time inter-network defence

• X.1581 Transport of real-time inter-network defence messages

• X.1582 Transport protocols supporting cybersecurity information exchange

ITU-T X.1500 series: structured cybersecurity information exchange techniques


Security Automation “Pipework”

CVE – enabling reporting and

patching of vulnerabilities

CWE – identifying and mitigating root

cause exploitable weaknesses

CybOX – cyber observables and

supply chain exploit indicators

CAPEC – schema attack patterns

and software exploits

“Making Security Measureable” measurablesecurity.mitre.org

http://measurablesecurity.mitre.org/


CVE & CWE 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 to detect CWEs/CVEs and 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?

• Do projects utilize CVSS/CWSS scores to prioritize remediation efforts?

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

when selecting commercial and open source applications?

CVE & CWE are some of the means for sharing information about

risk exposures in software supply chain management


•

•

•

•

•

•


Weakness

Weakness

Weakness

Weakness

Asset

Attack

Impact

Item

Item

Item

Attack

Attack

Function

Asset

Impact

Impact

Known Threat Actors

Attack Patterns

(CAPECs)

Weaknesses (CWEs)

Controls* Technical Impacts

Operational Impacts

* Controls include architecture choices, design choices, added security functions, activities & processes, physical decomposition choices, code assessments, design reviews, dynamic testing, and pen testing – See NIST SP 800-160 Systems Security Engineering, Appendix J Software Security and Assurance (2nd draft released May 2016

System & System Security

Engineering Trades

Assurance: Mitigating Attacks That Impact Operations


SW components

Supply Chain

SW development process

Software Development

Software Today Is Assembled

Part Original Part Third Party


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


Taking Action

• Software and applications have to ship.

– That is the bottom line.

– Organizations need software to do things, often

unaware of the risk; sometimes regardless of the risk.

• Organizations need to signoff on security, and will do

so regardless of the veracity of their information.

• True cybersecurity 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.


Addressing Security of 3rd Party Software

SDLC

App Testing

Protocol and

policy testing

Software

Composition

Analysis

Procurement

language

Source: FS-ISAC 3rd Party Software Security Working Group


Operate at high velocity

Agile & Faster Speed Development

• Continuous integration and

deployment

• Increased agility

• Fast response to malfunction and

security incidences

Change culture and process

Organizational Inertia

• Lack of knowledge of modern

tools/languages/frameworks

• Opposition to limit development

“freedom"

• Legacy flows and tools - “NIH” ("Not

Invented Here”)

Growing Challenges in Software Development

Track disparate sources

Multiple Sources Combined

• Code is more “assembled” than

“developed

• Outsourced development

• Use of open source components

• Reuse of older code


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 Consider Not Exhaustive…But A Good Start

• SANS CWE Top 25 – A list of top 25 most commonly encountered Cyber Weakness Enumerators (CWEs),

found in (https://www.sans.org/top25-software-errors/)

• Object Management Group (OMG) Automated Source Code Security Measure (ASCSM)TM v1.0, 2016 at

http://it-cisq.org/wp-content/uploads/2016/01/Automated-Source-Code-Security-Measure-OMG-Formal-

January-2016.pdf -- A list of top-22 code-level CWEs

• OWASP Top 10 Vulnerabilities – A list of Most Critical Web Application Security Risks compiled by OWASP

(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) – includes CVEs & CWEs

• Verizon Report Top 10 CVEs – List of most commonly encountered Common Vulnerabilities & Exposures

(CVEs) used in exploits (http://news.verizonenterprise.com/2015/04/2015-data-breach-report-info/ )

https://www.sans.org/top25-software-errors/





http://it-cisq.org/wp-content/uploads/2016/01/Automated-Source-Code-Security-Measure-OMG-Formal-January-2016.pdf





















https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://news.verizonenterprise.com/2015/04/2015-data-breach-report-info/










Static

Code

Analysis

Penetration

Test

Data

Security

Analysis

Code

Review

Architecture

Risk

Analysis

Cross-Site Scripting (XSS) X X X

SQL Injection X X X

Insufficient Authorization Controls X X X X

Broken Authentication and Session

Management

X X X X

Information Leakage X X X

Improper Error Handling X

Insecure Use of Cryptography X X X

Cross Site Request Forgery (CSRF) X X

Denial of Service X X X X

Poor Coding Practices X X

Different assessment methods are effective at finding different types of weaknesses

Some are good at finding the cause and some at finding the effect

Take Advantage of the Multiple Detection Methods


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).

These tests can be used to enumerate CVE’s, CWE’s, and malware which can be further categorized into prioritized lists.

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


Synopsys’ Software Integrity Group Built Through Acquired Products & Technology

ACQUISITION TIMELINE

Code Adviso

r Quality & Security Issues

AbuseSA Situation Analysis

Protecode 3rd Party License

Compliance

Seeker Dynamic Security Testing

AppCheck Bill of

Materials Vulnerability

Defensics Protocol Fuzzing

March 2014 July 2015 June 2015 November 2015

* ECCN / CCATS#

5D992/G157185* 5D992/G161908* 5D992/G166851* 5D992/G164231* 5D992/G161908* 5D002/G161908*


PLATFORM

Reporting Bug tracking integration Workflow integration IDE plugins &

Test Advisory SCM integration

PRODUCTS

Coverity

Static

Analysis

Defensics

Protocol

Fuzzing

Protecode

Software

Composition

Analysis

Seeker

Interactive

Application Security

Testing

Abuse SA

Threat

Situational

Awareness

Synopsys Software Integrity Platform

Signoff for


Signoff for

Supply Chain Management


|

47

|

Structured Threat

Information

eXpression (STIX)


|

48

|

Coverity

AbuseSA

Defensics

Protecode

Seeker


Kill Chain – Exploit Targets – Courses of Action

Using Structured Threat Information eXpression (STIX)

What you are looking for Why were they doing it?

Why should you care

about it?

What exactly were they

doing?

Who was doing it?

What were they

looking to exploit?

What should you do about it?

Where was it seen?


Kill Chain – Exploit Targets – Courses of Action

Using Structured Threat Information eXpression (STIX)

What you are looking for Why were they doing it?

Why should you care

about it?

What exactly were they

doing?

Who was doing it?

What were they

looking to exploit?

What should you do about it?

Where was it seen?

What could/should have been done to

harden the attack surface/vector to prevent

the target from being exploitable?


Developers and consumers of software

and systems falsely assume security is an

upstream responsibility, bearing the risk

of an unchecked cyber supply chain

- Tamulyn Takamura, Marketing analyst

“

”


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


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 to prioritize mitigation

since not all identified vulnerabilities are

necessarily exposed. CVSS v3 now

available.


What Software Composition Analysis (SCA) Provides:

Components of Software

Composition Analysis

(SCA) solution:

• Vulnerability assessment

and tracking

• [FOSS] license management

and export compliance

• Software Bill of Materials

(BOM) identification and

management

Securing Software Through Software

Composition Analysis (SCA):


Software Ingredient List (Bill of Materials)

Simply knowing software “ingredients” or “code genetics” arms a

user with an enormous resource for determining risk.


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


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

Source: Financial Services Sector Coordinating

Council for Critical Infrastructure Protection and

Homeland Security


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/


Introducing test gates in the

SW delivery process

Introducing test gates in the

SW development process

• Legal compliance

• Regulatory compliance

• Industry compliance

• Best practices compliance

Signoff for


• Release criteria

• Agile feature acceptance

• Required for successful build

• Required for code check-in

Software Signoff for

Supply Chain Management

Code Check-in

Compile & Build

Feature Readiness

Product Release

Signoff


Ingredients of Software Signoff

Best-in-class solutions

Technologies

• Static Code Analysis

• Software Composition Analysis

• Malformed Input Testing

• IAST

• Automated Test Optimization

Fully integrated into existing workflows

Methodology

• SDLC Integration

• Workflow automation

• Third party certification

• Internal policy enforcement

• International standards compliance

Tailored solutions

People

• Training

• Engineering

• Security assessment

• Vulnerability remediation

• SSDLC


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 …


“Enterprises look for

vulnerabilities at the time

they build and deploy their

software; yet most security

vulnerabilities emerge,

enabling exploitation at a

later point in time as

software decays.”

“Software is no longer

written, it is being

assembled.”

“Testing is required to

understand risk exposures

attributable to tainted

components in software.”

“Software Composition

Analysis (SCA) provides a

high level impact in

security, liability and risk

mitigation almost instantly

for its adopters; it reduces

the risk introduced by

inclusion of third-party and

open source software and

components.”

Software Supply Chain Management

Software Signoff at various phases of software lifecycle provides a

secure, safe and risk-free experience.


Real Value of Assets

Analytics

&

Accuracy

Speed

&

Flexibility Transparency

Cyber Risk Governance

Culture

Leadership

Alignment

Structure & Systems




OMG Cyber Risk Summit





Enabling Enterprise Resilience & Cyber Security … Enterprise Resilience & Cyber Security Assurance...

Documents

Transcript of Enabling Enterprise Resilience & Cyber Security … Enterprise Resilience & Cyber Security Assurance...