Copyright© 2018 UL LLC. All rights reserved. No portion of this material may be reprinted in any form without the express written permission of UL LLC. or as otherwise provided in writing.

Measuring and Evaluating Cyber Risk in ICS Components, Products and Systems

3

The Problem

With the growth of IIoT in the ICS space, there is a need for cybersecurity testing of • Components

• Products

• Systems

to mitigate the risk of cyber incidents in operational networks.

4

The Problem

While many specifications and guidance documents provide information on secure product development principles,

there is still a need to test and measure the security posture of products using comprehensive testing criteria and an important certification management process throughout the life of a component.

5

The Problem

What should the security testing include and what are important attributes to measure and evaluate?

What are supply chain considerations?

How do you maintain certified status in the age of ICS vulnerabilities?

Testing and Certifying Products and Systems

7

How to Measure Security

Component Security

• Device Security

• Device Configuration

• Device Implementation

System Security

• Implemented Security Controls

• Site Policies

• Site Continuous Assessment and Monitoring

Evaluate Service Suppliers

• Supply Chain Logistics

• Service Suppliers Competency

• Service Suppliers Security Risks

Vendor

• Security Practices

• Secure Development Cycle

• Suppliers Security Risks

Implementation

• Security Practices

• Risk Assessment

• Monitoring

70% of IoT devices are vulnerable to attack (Source:HP)

The IoT Cyber Threat

28% to 47% of organizations have experienced IoT-related breaches

(Source: Forrester/CISCO)

By 2018, 66% of networks will have experienced an IoT security breach

(Source: IDC Research)

In 2016, the average consolidated total cost of a data breach was $4M USD

(Source: 2016 Ponemon Study)

70% 66%

28% to47%

3.5

M

3.8

M

4.0

M

2014 2015 2016

9

WHAT EXISTS TODAY

STANDARDS LANDSCAPESecurity Standards and Guidance

Documents

• UL 2900

• FISMA

• HIPAA

• PCI

• ISO/IEC TR 15443

• ISO/IEC 15408

• DHS C3 VP & CRR

• CIS Controls (formerly 'SANS Top 20’)

• ISO/IEC 27000 Series

• Cyber Essentials (UK)

• NERC CIP

• NIST SP 800-82

• KRITIS(Germany)

• ANSSI CIIP(France)

• EU-NIS Directive

• EU-GDPR

• Top 35 Mitigation Strategies (AU)

• ISO/IEC DIS 20243 / O-TTPS

• NIST Cybersecurity Framework & SP 800-53r4 Security Controls

• ITU-T CYBEX 1500 Series

10

Supply Chain

11

Security can be measured effectively if it is planned

Where to focus your resources

RISK

THREAT

OPPORTUNITY VULNERABILITY

Nation States

Professional Activity

Hobbyists

Insiders/Employees

Inadequate Security Attributes

Hard Coded Passwords

Improper Installation

Poorly Written Code

Building

Access Control

Control Center Control

The Attacker:

A Flaw: The Asset to be Appropriated:

Understanding Security Risks Through Threat Modeling

Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application.

RISK

Impact Possibility Ease Of Exploitation

Damage Potential

Number of Affected

Components

Discoverability

Exploitability

Degree of Mitigation

Reproducibility

14

The First Measure

A risk analysis framework

• A list of identified threats for the product , device and systems and its security objectives

• An assessment of the impact of each identified threat

• An assessment of the likelihood of each identified threat

• Risk management criteria

15

Products and Systems have 2 Bill of Materials

Internal General Release

Customers

Dev

elo

per

s

Internal

External

Commercially off-the-shelf Components

Open-Source Components

Internally Developed Software

Externally Developed

Custom Software

So f twareBILL OF MATERIALS (SBOM)

HardwareBILL OF MATERIALS (BOM)

CWE and CVE Relationship

Weaknesses

Vulnerabilities

ReportedUnreported

Prior to Exploit

Non-Disclosed VulnerabilitiesWeaknesses with little known undisclosed exploits, not yet publicly exploited

Zero-Day VulnerabilitiesPreviously unmitigated weaknesses that have been exploited with littleor no warning and donot yet have a patch

CVEsPublicly known vulnerabilities and exposures with patches

Unknown WeaknessesUncharacterized flaws with unknown exploit potential

CWEsCharacterized, discoverable, and potentially exploitable weaknesses withknown mitigation

Software Composition Analysis

In 2014, a Synopsys engineer downloaded a SCADA software package from the vendor’s developer website.

It was discovered that over 700 known vulnerabilities affected the product.

*https://www.synopsys.com/software-

integrity/resources/case-studies/software-composition-analysis-case-study.html

18

The Second Measure

A Software Composition Analysis

• A list of CVEs found in the product

• Severity of CVEs applicable

• Solutions of resolving CVEs

19

The Third Measure

• https://owasp.blogspot.com/• http://http://cwe.mitre.org/top25

20

The Third Measure

A Software Weakness Analysis

• A list of CWEs found in the product

• Severity of CWEs applicable

• Solutions of resolving CWEs

Common Attack Mechanisms

MALWARE• Viruses, Trojans, and Worms• Botnets• Ransomware

ADVANCED PERSISTENT THREATS• Requires Resources• Specific Target

DENIAL OF SERVICE (DoS)• Overwhelm System• Degrade Performance

COMMON• Phishing• Brute Force• Back Door

01

02

03

04

Recent Security Breaches

ZDI researchers reviewed the 2015 and 2016 ICSCERT HMI

advisories to identify all of the solutions that had bugs fixed within

the last two years* Hacker Machine Interface The State of SCADA HMI Vulnerabilities Trend Micro Zero Day Initiative Team

23

The Fourth Measure

Assess and Evaluate the Security Controls in the product

• Authentication• Remote Communications• Cryptography• Software Updates• Security Event Logging

24

Penetration Testing

Conditions • DOS• Authentication• Privilege

Escalation• Vulnerabilities

found• Security

configuration

25

The Fifth Measure

Structured Penetration Testing OF

• Risk Analysis

• Security Controls

• CVEs remaining in product

• CWEs remaining in product

Testable CriteriaRepeatable and Reproducible

27

The Fifth Measure

CONTENTS

STRUCTURED PENETRATION TESTINGRisk

ManagementProduct Assessment

Software Composition

Analysis

Fuzzing Static Code Analysis

Risk Management

Process

Security Controls

STRUCTURED PENETRATION TESTING

YOUR REPORT AND/OR CERTIFICATION

What is UL 2900?

TESTING

YOUR NETWORK CONNECTABLE PRODUCT

AND/OR SYSTEM

AUTOMOTIVE LIGHTING SMART HOME HVAC BUILDING AUTOMATION

APPLIANCES ALARM SYSTEMS

SMART METERS

MEDICALDEVICES

FIRE SYSTEMS

INDUSTRIAL CONTROL SYSTEMS

loT

NETWORK-CONNECTABLE PRODUCTS & SYSTEMS

UL CAP Services

TRAINING SERVICES

ADVISORY SERVICES

REVIEW SERVICES

Submit product or system for discrete testing

(One or more individual tests)

Submit product or system for certification testing

(All tests)

RISK MANAGEMENT

Test Report

Certificate

KEY TAKEAWAYS: RISK MITIGATION INNOVATION COMPETITIVE ADVANTAGE

• Known Vulnerabilities

• Fuzz Testing

• Code & Binary Analysis

• Access Control & Authentication

• Cryptography

• Remote Communication

• Software Updates

• Structured Penetration Testing

UL 2900 Standards

General Product Requirements

Industry Product Requirements

General Process Requirements

UL 2900-1Software Cybersecurity

UL 2900-2-1Healthcare Systems

UL 2900-3-1General Process

Requirements

UL 2900-2-2Industrial Control Systems

UL 2900-2-3Building Security Controls

UL 2900-3-2SDL

UL 2900-2-4New Initiatives

LEGEND:

Published

Not Yet Published

UL 2900-2-5New Initiatives

UL 2900-3-1General Process

Requirements

UL 2900-3-2SDL

Copyright© 2017 UL LLC. All rights reserved. No portion of this material may be reprinted in any form without the express written permission of UL LLC. or as otherwise provided in writing.

Q&A