Cybersecurity Architectural Risk Assessment (ARA) Overview

ATIS Cyber Security Adhoc

July 2020

Cybersecurity

Architectural Risk Assessment (ARA)

Overview Presentation

What is the Architectural Risk Analysis?

The Architectural Risk Assessment (ARA) is a security analysis tool/process intended for ICT end-to-end services, applications and solutions to enable:

• Proactive development of a cybersecurity risk management plan

• Identification of application/solution level security gaps

• Assessment of cost-effective mitigation options consistent with the business needs and potential negative impacts of security breaches

• Key questions:

– Are we considering the entire end-to-end architecture in assessing security?

– Do we have the most effective and non-overlapping (independent) set of mitigations in place (Consistent with a specific strategy for Security in Depth and layering of security mitigations)?

– Are we providing complete coverage of the solution?

2

Application/Service Security is more than the sum of the security profiles of each separate component.

ATIS has Produced Many Reports on the ARA

• These reports are available at https://www.atis.org/whitepapers/.• Completed An Architectural Risk Analysis for Internet of Things (IoT) Services in March 2019.

– The report uses the ARA to establish a framework for assessing cybersecurity risk to a generic IoT asset:

• IoT assets share many common features that differentiate them from non-IoT networked assets

• Identifies primary, secondary, and other IoT real-world assets, in accordance with the ARA methodology

• Establishes a complete set of consistent and useful attributes for each IoT asset

• Shows how the ARA methodology is used to pinpoint the attacks/attack classes exposed for each attribute and appropriate mitigations

– The report also provides a simple though plausible example of how the ARA can be applied realistically to an IoT asset.

• Completed Cybersecurity Architectural Risk Analysis Process in May 2017.

• Completed Securing Internet of Things (IoT) Services Involving Network Operators in May 2017.

3

https://www.atis.org/01_resources/whitepapers/

https://www.atis.org/01_resources/whitepapers/#AIOT

https://www.atis.org/resources/an-architectural-risk-analysis-for-internet-of-things-iot-services/

https://access.atis.org/apps/group_public/download.php/35401/ATIS-I-0000057.zip

https://access.atis.org/apps/group_public/download.php/34714/ATIS-I-0000056.pd

https://www.atis.org/whitepapers/

In this Presentation

• We review each of the 6 steps (organized in 3 lanes per the diagram below) in the ARA providing additional detail and lessons learned from previous ARA work.

• Specifically, we provide a baseline set of attributes, attack classes and attacks that can be used to jump start any new ARA effort.

4

Risk AnalysisThreat Mitigation Plan

Develop Mitigation Plans to Cover Threats, Attack Points on Network Diagrams and Abuse Cases

Coverage Test: Mitigation Steps <-> Threats, Attack Points and Abuse Cases

Threat IdentificationThreat Model* Abuse Cases*

Identify Threats, DetermineAsset and Path Weights*

Prioritized Test Cases Based Upon Covering Abuse Cases*

Coverage Test <-> Threats, Assets, Use Cases, Abuse Case Rakings*

Architectural DiscoverySecurity Objectives* Use Cases* Network Diagrams*

Identify Primary and Priority Secondary Assets, Note Assets on Diagrams*

Threat Library

Abuse Case Library

* Items to be completed/handed off prior to next stage/swim lane

1 2 3

4 5

6

The ARA Process is comprised of 6 steps:1. Creation of security objectives2. Identification of key use cases3. Development of associated network diagrams4. Development of a threat model5. And associated abuse cases6. Development of threat mitigation plan

Organized into three major lanes of activity:

1. Architectural Discovery2. Threat Identification3. Risk Analysis

Architectural Risk Analysis: Connecting the Dots

E2E System Requirements

1. ARA Focuses on Security Analysis of Whole E2E Systems (e.g., Network Architectures)

2. Process Steps Include:

• Architectural Discovery -> Security Objectives, Use Cases and Assets

• Threat Analysis -> Asset Attributes, Attack Classes and Attacks

• Risk Analysis -> Threat Mitigation Plan

ARA AnalysisE2E System,

Architecture & Design

Implement/ Deploy

MonitorAnalyze

Mitigations

Security

5

ARA Summary







Coverage Test <-> Threats, Assets, and Use Cases

Abuse Case Rakings*



Threat Library Abuse Case Library


1 2 3

4 5

6

Outcomes/Deliverables:• Descriptive text of security

objectives and key assets and attributes

• List of Use Cases (operational and maintenance)

• Network and/or data flow diagrams

• Asset attack dependency diagrams

• Table of interfaces and protocols

6

Security Objectives

• Document security objectives that correlate to the functionality and services provided by the system/application under analysis.

• Objectives can be categorized by the key actors within the system, for example:

– Operator(s) providing the necessary architecture infrastructure

– Network/system management entity, commonly associated with the operator(s)

– Identity providers used

– Application providers (which may ride on top of the infrastructure operator)

• Objectives should focus on key/primary assets e.g., specific functions or data that are primarily responsible for the operation of the system/application.

• Objectives can identify the most critical attributes (e.g., Confidentiality, Integrity, or Availability) of the identified primary assets.

7

Security Objectives should be updated as assets/attributes are identified.

Security Objective Considerations

• Based on known risks and concerns relative the valuable aspects of the system, for example:

– DDoS

– Alteration of Service

– Theft/Fraud

• Development of objectives can include:

– Assessment of potential attacker strategies

– Well organized (nation-state scale) complex attack vectors using simultaneous attacks (e.g., Ukraine power grid attacks)

8

Examples of Security Objectives

• Ensure the following:

– Availability of the asset to the system/application provider

– The asset:

• Operates under the correct software load and configuration data and that this data has not been compromised

• Behaves as specified when configured properly and key behaviors can be identified (e.g., charging)

• Communicates to known authenticated entities and has properly authorized access to resources and controls

– Confidentiality, integrity, and availability of communications over the network

– The availability, confidentiality and integrity of data assets

– Credentials and cryptography choices are sufficiently strong

9

Use Cases and Network Diagrams

• Identify/document functional Use Cases with security impacts:

– Identify key functions and how they work/interwork within the architecture

– Work includes relevant third-party use cases including functions provided by third parties (e.g., network services, cloud services)

– Show control/data flow diagrams within the architecture for key functions

• Identify primary and secondary assets and their attributes that may be of interest to attackers:

– Based on use cases and function/data flow analysis

– Revisit security objectives for each asset/attribute

10

IoT Device or

Controller

LAN(optional)

Devices

…

Devices

WAN Gateway(optional)

WAN

Servers

ClientDevices

Operational• Object Control• Data Reporting

Management• Programmable• Configurable• State Retrieval

Compute• CPU• Memory / Storage

Network• Transport• FW/NAT & ACLs• DNS, DHCP• VPN• Packet Services

Access Type• Mobile• Unlicensed• Wired/Optical

Types• Smartphones• Tablets• PCs

OS/Platform

Application

Device Management

Identity Provider

Network Control (DNS, DHCP, etc.)

Operational• Transport• NAT/FW• UPnP• VPN• Routing

Management• Programmable• Configurable• State Retrieval

Access Type• Wired• Wi-Fi• Bluetooth• Zigbee• Other

Capabilities• Discovery• Segmentation• QoS

Architectural Discovery: Example IoT System

11

Examples of Use Case Network Flows

12

IoTDevice or Controller

LAN(optional)

Devices

…

Devices

Optional

WAN

Gateway(optiona

l)WAN

Servers

Client Devic

esDevice DHCP and DNS Services• DHCP for device IP address (and other IP parameters)

may be provided by the LAN or WAN• DNS services may be provide by the WAN, LAN or a 3rd

party DNS server

Trust Boundaries

IoTDevice or Controlle

r

LAN(optional)

Devices

…

Devices

Optional

WAN Gateway

(optional)

WAN

Servers

Client Devices

Device FW/NAT Traversal• TURN/STUN/ICE and other protocols specifically designed for network

NAT/FW traversal• Other protocols can be used in a periodic fashion to keep a port open on

the NAT/FWs (SIP register messages have been used in SIP signaling applications

• UPnP can be used to open ports within a LAN• ALGs may be used if supported for specific protocol applications• Mobile devices can use SMS messages to trigger device connection

setup

Trust Boundaries

IoTDevice

or Controll

er

LAN(optional)

Devices

…

Devices

Optional

WAN

Gateway

(optional)

WAN

IoT Device Operation – Options• Connection established between IoT Device and IoT Application

server to exchange IoT control and data. Server data may be accessible by Client Devices independently

• Peer-to-Peer connection may established between IoT Device and Client Device via the aid of a P2P service which may be integrated with the IoT application server. The server may also support NAT/FW Traversal services as well as services for authentication and authorization directly or via delegation or authentication “tickets” in support of session keys.

Servers

Client Devices

Trust

Boundaries

DHCP and DNS ServicesFW/NAT Traversal

IoTDevice

or Control

ler

LAN(optional)

Devices

…

Devices

Optional

WAN Gateway(optional)

WAN

Device Manageme

nt

Device Management (remote or local)• IoT device to Device Manager (or local personnel) connection

established – used to …• Program the device (update software)• Configure the device (update provisionable data)• State Retrieval

• Software and configuration attestation services and overall security posture

• Location• Performance metrics and Logs

Trust Boundaries

Device Management Operation (incl P2P aspects)

Example of Asset Identification

13

IoT Device or

Controller

LAN(optional)

Devices

…

Devices

OptionalWAN

Gateway(optional)

WAN

Devices

P2P Device Client that has access to

IoT Device

Servers

DevicesDevices

WE DEFINE:• Primary assets – Resources that represent the primary or

fundamental value delivered (or that has the potential for the highest damage if compromised) relative to the IoT service or application.

• Secondary assets – Resources upon which the primary asset depends to the extent that they can be attacked with the intent of enabling the likely threat actors’ goals associated with the primary asset (e.g., secondary asset attack could cause loss of availability of the primary).

IN ADDITION:• An analyzable asset can be a functional object (system/SW/HW)

or an informational object (data) within the architecture.• An analyzable asset can be uniquely identified and located within

the architecture (e.g., Data in a server may be a different asset than Data on a LAN).

• All assets within the architecture that, if compromised, will negatively impact the proper operation should be identified.

• Any overlap of assets should be noted.• Attack points and attack paths through secondary assets to a

primary can be considered.

Deeper Look at Assets within an Architecture

ASSETS COULD BE:• A network element or client devices• Core HW, OS/hypervisor, SW platform• An interface/data link• Include data or data treated separately• Application or service function:

– Application uses services in the implementation of the app

– Services may be comprised of one or more functions

• Singular elements or an aggregation• Primary -> directly necessary for

proper system operation• Secondary -> supporting function that

could be a launch pad for attacks on primary assets

HW

Ap

ps

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

HW

Ap

ps

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

HWA

pp

s

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

Intf

Intf

Intf

NE1

NE2

NE3

Trust

Boundaries

14

Deeper Look At Assets Within an Architecture

HW

Ap

ps

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

HW

Ap

ps

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

HWA

pp

s

Serv

ices

SW Platform

OS/Hypervisor

Serv

ices

Ap

ps

…

Ap

ps

DATA

DATA

DA

TA

DA

TA

Intf

Intf

Intf

NE1

NE2

NE3

Trust

Boundaries

Additional attack Interfaces

include the Supply Chain and

physical/local attacks

An ARA Threat Model Analysis for each asset should consider architectural aspects such as

attack points and attack path through (secondary) assets.

OTHER ASPECTS OF ASSETS:• The set of assets should completely cover the

architectural system be analyzed• Assets are often inter-related in that the

compromise of one asset might then be used to attack other assets:

- Some assets by be hidden behind a chain of other assets (harder to attack)

- Attack vectors must be considered

• Security mitigations affect asset threat models

15

Asset Attack Dependency

Asset

For eachprimary asset

Secondary Assets

Secondary Assets

Secondary Assets

For each entry pointand associatedsecondary assetor threat surface

Attack 1

Attack 3

Attack 2

…

Identify how many layers of defense

exist e.g., how many secondary/intermediate assets that could

block the attack

Map this new measure of “layers of defense” into the attack weight in the

threat model (more layers, less probability of

attack success)

…

16

Example of Asset Attack Dependency

SOME ASSETS MAY BE HIDDEN FROM DIRECT ATTACK BY SECONDARY ASSETS:• Proxy/Firewalls may hide a database/key

server from direct internet access• VLAN may hide devices from direct internet

access• Data/database files may be hidden within

protected storage servers• VPNs can hide servers/clients from direct

Internet access

17

PrimaryAsset

e.g., Data or

Database

FW or Proxy Server

Internet

For certain attack classes, the dependency chain can be identified as input into the threat modeling phase.

ARA Summary

18








Abuse Case Rakings*





1 2 3

4 5

6

Outcomes/Deliverables:• Ranked list of threats

correlated to assets and interfaces.

• List of Abuse Cases.• Annotated diagrams

indicating attack points.

Threat Modeling* Example

Primary Target

Availability IntegrityAuthenticity Confidentiality

Surface 1 Surface 4Surface 3Surface 2

Attack Class 3Attack Class 2Attack Class 1

Attack 3 Attack 5Attack 1 Attack 2

Attributes

Threat Surfaces

Attack Classes

Attack 4

IoT Device

Attacks

Attack Class 1 Attack Class 2

Attack 5 Attack 5 Attack 5

* Many different Threat Model Methodologies Exist

Each of the asset’s attributes are exposed to harm via one or more threat surfaces which may be attacked through a variety of means (classes of attack).

Attributes: Developing Baseline Values for Each Asset

Typical attributes include:

• Availability – Ensuring timely and reliable authorized access to and use of an uncompromised asset.

• Integrity – Ensuring that the asset has not been modified by unauthorized identities and thus operates consistent with non-altered instances of the asset.

• Authenticity – Reflecting the property of being verifiably genuine (i.e., associated with the identity as claimed by the asset and/or an independent root of trust).

• Confidentiality – Ensuring that the asset is protected from unauthorized use (i.e., the asset can only be disclosed to or used by authorized, authenticated identities).

20

An ATTRIBUTE is a defining quality of an asset and consequently reflect the asset’s attackable

characteristics. Attributes should exhibit characteristics of completeness and independence.

Threat Surface: Availability for Functional Assets

Threat surfaces presented by the availability attribute may include:

• Power – loss of power can affect device availability though not data availability when non-volatile storage

• Environmental (physical environment) factors can affect device and data availability (e.g., physical destruction)

• Interfaces can be used to affect availability:

– Physical / Manual device interface such as control switches

– Network Interfaces by Layer:

• Layer 1 – Physical (e.g., Jamming a radio signal)

• Layer 2 – Link (e.g., Traffic overload (DDoS))

• Layer 3 – Network (Prevent access to the device (DNS, routing, etc.))

21

Environmental(Physical) In

terf

ace

s

ASSET - Availability

Power

Compromise of availability of a primary asset may be accomplished by attacking the integrity of a secondary asset.

Threat Surface: Availability for Data Assets

Threat surfaces presented by the availability attribute may include:

• Encryption – attacker encrypts the data to make it unavailable for normal use

• Deletion – data may be deleted to make it unavailable until it can be retrieved from a backup or renewed though normal processes*Note: deletion could also be considered an attack on integrity though should not be shown associated with both attributes to prevent double counting of deletion attacks.

22

Encryption

ASSET - Availability

Compromise of availability of a primary data asset often assumes loss of integrity of a secondary asset (e.g., network interface or

data storage system).

Dele

tion

Threat Surface: Integrity for Functional Assets

23

Social Engineered

Supply Chain(code/HW Insertion)

Inte

rface

s

ASSET - Integrity

Threat surfaces presented by the integrity attribute may include:• Supply Chain

- Code insertion to create back doors, access to debug capabilities or- HW/FW modification- Integration – malicious capabilities inserted during integration- Inserted during the development, integration or manufacturing process

• Network Interface Attacks (at all layers)- Code insertion and execution via an access interface

(public facing app exploit or drive by)- Code Insertion via interface vulnerability (protocol vulnerability)- Application Exploits (e.g., SQL injection)- Data insertion via an access interface for malicious purposes (e.g., invalid

configuration data)

• Social Engineered- User initiated code insertion (e.g., code downloaded and executed, or config

data modified via local user deception, phishing attacks)- Local manual HW intervention (e.g., download of executables through separate

hardware device such as a USB device)

Applicable to functional assets

Threat Surface: Integrity for Data Assets

Threat surfaces presented by the integrity attribute may include:

• Data at Rest - modification

– Attacks enabling access to memory (RAM/ephemeral data)

– Attacks enabling access to permanent storage (disk, SSD, ROM, etc.)

• Data in Motion - modification

– Attacks enabling access to communication links (MITM) and associated interfaces

24

Data at RestD

ata

in M

otion

ASSET - Integrity

Applicable to data assets -generally requires compromise of secondary functional assets for access

Threat Surface: Confidentiality for Functional Assets

Threat surfaces presented by the confidentially attribute may include:

• Access to resources through valid accounts using “stolen” credentials

– Access using valid keys (gained though malicious means)

– Access via brute force attacks

• Access to resources through privilege escalation for authorization

25

Privilege Escalation C

redentials

ASSET – Confidentiality

Threat Surface: Confidentiality for Data Assets

Threat surfaces presented by the confidentiality attribute may include:

• Data at Rest - data theft/capture in a system

– Attacks enabling access to memory (RAM/ephemeral data)

– Attacks enabling access to permanent storage (disk, SSD, ROM, etc.)

– Including some capability for exfiltration – transfer of the data to unauthorized parties outside the system (the attacker)

• Data in Motion - data theft/capture on an interface

– Attacks enabling access to communication links (MITM, snooping) and associated interfaces

– Including some capability for exfiltration – transfer of the data to unauthorized parties outside the system (the attacker)

26

ASSET – Confidentiality

Data at RestD

ata

in M

otion

Threat Surface: Authenticity for Functional Assets

Threat surfaces presented by the authenticity attribute may include:

• Supply Chain - introduction of selected non-authentic assets masquerading as a valid asset

• Asset Insertion (Spoofing) - malicious insertion of a non-authentic asset into the system:

– Replicated asset

– New/false system asset that may then be used to launch new attacks (MITM, passive network/link monitoring device, etc.)

27

Malicious Asset Insertion

(Spoofing)

ASSET – Authenticity(property of being verifiably genuine)

Supply Chain(code/HW Insertion)

Threat Surface: Authenticity for Data Assets

28

Threat surfaces presented by the authenticity attribute may include:

• Data at Rest - Authentic data – insertion of false/invalid

data- Attacks enabling access to memory (RAM/ephemeral data)- Attacks enabling access to permanent storage (disk, SSD, ROM, etc.)

• Data in Motion - Authentic data – insertion of false/invalid

data - Attacks enabling access to communication links (MITM) and associated

interfaces

ASSET – Authenticity

Data at RestD

ata

in M

otion

Attacks and Attack Classes: Developing Baseline Values

1. Every asset/attribute has one or more attackable surfaces (threat surface in our threat model)

2. Attacks are launched onto an attackable surface

3. Attacks can often be categorized into groups that share common characteristics. These groups are called attack classes.

4. Attacks can be filtered out when the surface does not exist for asset under analysis

5. We can use industry standard attack libraries [e.g., MITRE Att&ck Matrix(s)] to identify attack classes and attacks:

– Attack classes are categorized by the “why” (Tactics) and “how/what” (Techniques)

– MITRE Att&ck matrix does not address all possible attacks on all assets – but its an excellent starting resource

– From an ARA perspective we are most interested in tactics attacking the asset from an external source (i.e., architecture related) such as Initial Access with Execution of malicious software. Other interesting tactics may include:

• Privilege Escalation (for confidentiality/false authorization)

• Credential Access (for subsequent access to this and other assets)

• Lateral Movement (particularly when it provides “initial access” to another asset)

• Exfiltration (mitigations can be applied in the architecture to detect)

• Impact (particularly related to confidentiality of data)

29

* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.

MITRE Att&ck Matrix: Enterprise

1

5

6

7

8

9

10

2

3

4

IA CADEPEPSEX EFCOLMDI CC IM

11


MITRE Att&ck: Initial Access Attacks (1)

1. Drive-by Compromise

– An adversary gains access to a system through a user visiting a website over the normal course of browsing. The user's web browser is targeted for exploitation e.g., via scripts targeting vulnerable plugins, extensions and other browser vulnerabilities.

2. Exploit Public-Facing Application

– The use of software, data, or commands to take advantage of a weakness in an Internet-facing system to cause unintended or unanticipated behavior. The weakness in the system can be a bug, a glitch, or a design vulnerability. These applications are often websites, but can include databases (like SQL) , standard services (like SMB or SSH), and any other applications with Internet accessible open sockets, such as web servers and related services.

3. External Remote Services

- VPNs, Citrix, and other access mechanisms allow users to connect to internal enterprise network resources from external locations.

4. Hardware Additions

– Computer accessories, computers, or networking hardware may be introduced into a system as a vector to gain execution. While public references of usage by APT groups are scarce, many penetration testers leverage hardware additions for initial access.Commercial and open source products are leveraged with capabilities such as passive network tapping , man-in-the middle encryption breaking , keystroke injection , kernel memory reading via DMA, adding new wireless access to an existing network , and others.

5. Replication Through Removable Media

– Adversaries may move onto systems by copying malware to removable media and taking advantage of Autorun features when the media is inserted into a system and executes

31


MITRE Att&ck – Initial Access Attacks (2)

6. Spearphishing Attachment

– Spearphishing attachment is a specific variant of spearphishing that employs the use of malware attached to an email. All forms of spearphishing are electronically delivered social engineering targeted at a specific individual, company, or industry. In this scenario, adversaries attach a file to the spearphishing email and usually rely upon User Execution to gain execution.

7. Spearphishing Link

– Spearphishing with a link is a specific variant of spearphishing that employs the use of links to download malware contained in email, instead of attaching malicious files to the email itself, to avoid defenses that may inspect email attachments.

8. Spearphishing via Service

– Spearphishing via service is a specific variant of spearphishing that employs the use of third-party services rather than directly via enterprise email channels (e.g. via social engineering to get the user to use webmail to deliver exploit)

9. Supply Chain Compromise

– Supply chain compromise is the manipulation of products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise. Supply chain compromise can take place at any stage of the supply chain including:

10.Trusted Relationship

– Adversaries may attack organizations who have access to intended victims. Access through trusted third-party relationship exploits an existing connection that may not be protected or receives less scrutiny than standard mechanisms of gaining access to a network.

11.Valid Accounts

– Adversaries may steal the credentials of a specific user or service account using Credential Access techniques or capture credentials earlier in their reconnaissance process through social engineering for means of gaining Initial Access.

32


Mapping MITRE Attack Classes to Threat Surfaces

33

ATTRIBUTE THREAT SURFACE ATTACK CLASSES

Availability(functional)

Power Various attacks on the power system/grid or UPS as a secondary asset

Environmental (physical environment)

Various attacks on the HVAC system as a secondary asset

Interfaces (L1+) Various jamming, link overload, network/app overload attacks (DoS/DDoS), IM.6 Endpoint Denial of Service, IM.9 Network Denial of Service

Availability(data)

Encryption IM.2 Data Encrypted for Impact

Deletion IM.1 Data Destruction, IM.4 Disk Content Wipe, IM.5 Disk Structure Wipe



34


Integrity(functional)

Supply Chain – insertion of code, hardware functions to be used to damage the integrity of the device

IA.9 Supply Chain Compromise – hardware/firmware, software or services (e.g., Integration). Depends on number components.

Network Interface Attacks (at all layers)

IA.1 Drive By Compromise, IA.2 Exploit Public-Facing Application, IA.3 External Remote Services,

Social Engineered IA.5 Replication Through Removable Media, IA.6 Spearphishing Attachment, IA.7 Spearphishing Link, IA.8 Spearphishing via Service, IA.10 Trusted Relationship, IA.11 Valid Accounts

Integrity(data)

Data in Motion MITM attacks, IM.14 Transmitted Data Manipulation

Data at Rest IM.7 Firmware Corruption, IM.13 Stored Data Manipulation



35


Confidentiality(functional)

Access to resources through valid accounts (authentication)

IA.11 Valid Accounts, CA Credential Access (MITRE – 22 classes/techniques)

Access to resources through privilege escalation (authorization)

PE Privilege Escalation (MITRE – 28 classes/techniques)

Confidentiality(data)

Data in Motion Snooping / Routing based attacks to capture or replicate data to an attacker’s server/deviceTypically on communication links and associated interfaces

Data at Rest EX Exfiltration attack classes as well as Collection and Command and Control classes (MITRE)



36


Authenticity(functional)

Supply Chain – used to create an asset which can be inherently controlled by the adversary

IA.9 Supply Chain Compromise – hardware/firmware, software or services (e.g., Integration). Depends on number components.

Asset Insertion - Spoofing IA.4 Hardware Additions (internal to the asset or external e.g. new non-authentic asset in the architecture)

Authenticity(data)

Data in Motion Authentic data - False Data Insertion on interfaces

Data at Rest Authentic data - False Data Insertion in memory/storage


Availability

Authenticity

Integrity

Environmental

Asset Insertion

Asset (Functional

Asset)

Attributes Threat Surfaces

Attack Classes

Asset

Attacks

Confidentiality

Interfaces

Power

Valid Accounts

Privilege Esc

Network Intf

Supply Chain

Social Eng

IA.5 Replication Through Removable Media

IA.3 External Remote Services

IA.2 Exploit Public-Facing Application

IA.1 Drive By Compromise

IA.11 Valid Accounts

IA.10 Trusted Relationship

IA.8 Spearphishing via Service

IA.7 Spearphishing Link

IA.6 Spearphishing Attachment

IA.9 Supply Chain – non authentic component

Privilege Escalation (MITRE – 28 classes)

IA.11 Valid Accounts, CA - Credential Access(MITRE – 22 classes/techniques)

IA.4 Hardware Additions(internal to the asset or external)

Various attacks on the power system/grid or UPSas a secondary asset

Various jamming, link overload, network/app overload attacks (DoS / DDoS), IM.6, IM.9

Various attacks on the HVAC systemas a secondary asset

Evaluate relative probability of attack within each class based on:• Security objectives• Compromise of

secondary assets• Architectural

attributes• Existing mitigations• Application usage and

deployment factors• Business risk analysis• Known attack library

data

For each attack class, identify dependent secondary assets whose compromise enables an attack for this class

Supply Chain

Threat Modelling: Path and Weight MetricsExample Model With Functional Assets

IA.9 Supply Chain – modified component – HW/SW

Simplifying the Threat Model

• As seen from the previous slides, particularly when specific attacks are listed, the threat model can be large.

• But not all threat surfaces are relevant depending upon the scope of the analysis and nature of the asset itself, for example:

– Assets with no exposure to a human interface may not have a “social engineering” surface

– Assets with no exposure to the internet may not need to consider Internet based attacks such as IA.1 Drive By Compromise, IA.2 Exploit Public-Facing Application and IA.3 External Remote Services, etc.

– Supply Chain threat surfaces may be addressed outside of the architecture (via supply chain processes) and thus may be out of scope

– Environmental threats may common and separated out as part of an analysis of facility requirements

• Nevertheless, some of these attacks may come via secondary assets and all assumptions should be documented.

38

Using a Threat Agent Library to Help Prune the Threat Model Tree

• Not all adversaries will be willing or able to carry out all the attacks.

• Use an adversary-centric assessment to determine:

– What kinds of adversaries would be interested in the asset, and

– What kinds of attacks those adversaries are capable, based on their motivation, their technical expertise, and other factors

• Intel Threat Agent Library (TAL) is a comprehensive catalog of threat agents and their attributes (built on a mutually-orthogonal multi-dimensional model).

• Using the TAL filter unlikely adversaries and then use the information on the remaining adversaries to build an attacker profile:

– For each adversary, prune the tree by removing the branches that are out of scope for that adversary

– This gives an improved picture of the realistic dangers to the asset, the most dangerous adversaries, and the most likely avenues of attack

– Comparing the pruned trees with one another suggests most common attacks

39

Threat Model and Assumed AdversariesIntel Threat Library: Classifies Adversaries into Two Dimensions

1. INTENT

– Non-Hostile (accidental, etc.):

• Employee Reckless

• Employee Untrained

• Info Partner

– Hostile:

• Anarchist Civil Activist

• Competitor

• Corrupt Government Official

• Data Miner

• Employee Disgruntled

• Government Cyberwarrior

• Government Spy

• Internal Spy

40

• Irrational Individual

• Legal Adversary

• Mobster Radical Activist

• Sensationalist

• Terrorist

• Thief

• Vandal

• Vendor

Threat Model and Assumed AdversariesIntel Threat Library: Classifies Adversaries into Two Dimensions

2. Attributes

– Access:

• Internal or External

– Outcome/Goal:

• Acquisition/Theft

• Business Advantage

• Damage

• Embarrassment

• Technical Advantage

– Limits (legal and ethical)

• Code of Conduct

• Legal:

– Extra-legal, minor

– Extra-legal, major

41

Resources: • Individual• Club • Contest• Team • Organization• Government

Skill Level: • None • Operational• Adept

Objective:• Copy• Deny Access• Destroy• Damage• Take • Don’t care/all of the above

Visibility • Overt• Covert • Clandestine• Don’t care/multiple

Threat Models: Creating Metrics

Key Aspects:

1. We can associate a weight that reflects the probability of occurrence (or success) relative to each attack (right hand column in the Threat Model).

2. We can utilize attack dependency graphs (e.g., Slide 16-17) to adjust attack metric based on the architecture (assets may not be attackable directly relative to all Attributes and Threat Surfaces which means secondary assets may need to be compromised (typically the integrity or potentially availability attribute) to launch the attack.

3. We can add attack metrics (right to left) through the tree to assess which attributes are more attackable (Path Metric).

4. We can prioritize attributes (say 1- 4, 4 is the highest priority) and add priorities left to right to determine which attacks have the most serious impact (i.e., attack the most critical attributes) (called the Weight Metric).

42

Example of Splitting the PathThreat Surfaces

43

Integrity

Asset (Functional

Asset)


Attack Classes

Asset Authenticity Supply Chain

IA.9 Supply Chain – non authentic componentSupply Chain


Supply Chain IA.9 Supply Chain

SHOULD YOU DO THIS (A)

OR

THIS (B)

OPTION A: Splits the supply chain threat surface into two categories: 1) Supply chain attacks that substitute a non-authentic component into the supply chain (e.g., at the warehouse) and 2) HW/SW modifications of an otherwise authentic component with the aim of compromising the integrity (SW backdoor)

OPTION B: Branches/Splits the generic supply chain surface into both attributes

Example of Splitting the Path MetricThreat Surfaces

44

Integrity

Asset (Functional

Asset)


Attack Classes

Asset Authenticity Supply Chain

IA.9 Supply Chain – non authentic componentSupply Chain


Supply Chain IA.9 Supply Chain

Assign Metrics• “Authenticity” supply chain attacks

are less likely (assume metric of 7) as compared to the remaining supply chain attacks which can occur at any point in the supply chain (assume metric of 25)

30

7

23

7

237

23

30

30

30Path Metric indicates the

most “attackable attributes” - Radically

Different Answers possible with splitting

Unless ALL attacks associated with a Threat Surface equally affect all attributes in the Path, Threat Surfaces should NOT be branched but rather replicated, with each

addressing only the set of attacks appropriate for that attribute.

Example of Splitting the PathAttack Classes

45

Integrity

Asset (Functional

Asset)


Attack Classes

Asset Confidentiality

Valid Accounts

Social Eng

If ALL attacks associated with an attack class equally affect Threat Surfaces in the Path, Attack classes need NOT be replicated but rather branched (but replication

does not hurt).



SHOULD YOU DO THIS (attack class feed both

Threat Surfaces)

OR

THIS (Separate attack classes for each surface)


Calculating Weight Metric

• FOR EACH ASSET:

– First prioritize attributes (say 1-4, 4 is the highest priority) based on security objectives

– Then add priorities left to right across the threat model to determine which attacks have the most serious impact

– The priority set may be different for each asset, for example:

46

AN IOT DEVICE ASSET

May be very redundantly deployed to the extent that availability is less critical than for other assets.

A FUNCTIONAL ASSET (e.g., function in a server)

Might value integrity as most important.

A CRITICAL DATA ASSET

Might value confidentiality above other assets (or authenticity).

b

Availability

Authenticity

Integrity

Environmental

Asset Insertion

Asset (Functional

Asset)


Attack Classes

Asset

Attacks

Confidentiality

Interfaces

Power

Valid Accounts

Privilege Esc

Network Intf

Supply Chain

Social Eng

IA.5 Replication Through Removable Media

IA.3 External Remote Services

IA.2 Exploit Public-Facing Application

IA.1 Drive By Compromise


IA.10 Trusted Relationship

IA.8 Spearphishing via Service

IA.7 Spearphishing Link

IA.6 Spearphishing Attachment

IA.9 Supply Chain – non authentic component

Privilege Escalation (MITRE – 28 classes)

IA.11 Valid Accounts, CA - Credential Access(MITRE – 22 classes/techniques)

IA.4 Hardware Additions(internal to the asset or external)

Various attacks on the power system/grid or UPSas a secondary asset

Various jamming, link overload, network/app overload attacks (DoS / DDoS), IM.6, IM.9

Various attacks on the HVAC systemas a secondary asset

• Map weights to specific attacks

• Of critical interest are attacks that feed into multiple attributes as they would be weighted heavier due to their broader impact

• In addition … add weights taken from all asset threat models for a specific attack to evaluate total architectural impact of an attack.

Supply Chain

Calculate Weight MetricsExample Model For Functional Assets


4

3

2

1

1

1

1

1

1

1

2

2

2

2

3

3

3

3

4

4

4

4

4

4

4

4

4

4

4

4

4

Weight Metrics Across the Architecture

Add weights taken from all asset threat models for a specific attack to evaluate total architectural impact of an attack, for example:

48

AvailabilityThreat Surface 2

Asset 1Threat Surface 3

Threat Surface 1

1

1

1

1

Primary Asset

AttackAvailabilityThreat Surface 5


Threat Surface 4

11

IntegrityThreat Surface 8


Threat Surface 7

44

Attack Class 1

Attack Class 3

Attack Class 2

Attack Class 2

Attack Class 2

1

1

1

1

4

9

Example for an attack that affects 3 different ASSETS across multiple attributes (e.g., integrity and availability) and multiple threat surfaces

Identify Attacks Relevant to

Multiple Assets / Attributes

ARA Summary








Abuse Case Rakings*





1 2 3

4 5

6

Outcomes/Deliverables:• Revised diagrams and

reference material that reflect coverage of security controls and any threats that may not be fully mitigated.

• Actions that may be required to strengthen security.

49

Risk Analysis and Mitigation Plan

• Threat modeling step provides a wealth of information to create a relative view of solution security.

• Sensitivity analysis allows a comparative mechanism for potential modifications of network and/or asset security posture.

• This provides the ability to selectively choose additional security mitigations to maximize coverage for a particular risk level with minimal added complexity and cost.

50

Assess threats and use industry security controls references to determine if threat is mitigated.

Evaluate each

threat

Identify actions required to address

now or in future activity

.

,

. ,

.

Is threat

mitigated ?

Annotate diagrams

with security control

and indicate

mitigation

Yes

No

If additional controls are considered now, then process may iterate. Otherwise, gaps are part of final report.

Objective: Assess effectiveness of security controls and countermeasures.

Ris

k A

naly

sis

6a

6c

6b

Considerations:• Use data from Threat Identification activities.• Iterate through entire list of threats individually until each are

fully evaluated.Outcomes/Deliverables:• Revised diagrams and reference material that reflect coverage

of security controls and any threats that may not be fully mitigated.

• Actions that may be required to strengthen security.

Formulate

Security

Objectives

Identify Use Cases

DevelopDiagrams

Objective: Develop view of network that identifies major assets, interfaces, dataflows, and functions.

Define primary security objectives considering CIA principles for the services offered.

Document key Use Cases representing functionality and services provided by network.

Graphically represent the architecture and/or dataflows of the network with trust boundaries.

Considerations:• The process may begin with either of these three steps and may iterate

among them as more information is gathered and developed.• When applying the process to an existing network, prior information may be

reused.• Network may need to be divided into segments using the process for each

segment.Outcomes/Deliverables:• List of Use Cases / Key functions• Network and/or data flow diagrams• Table of interfaces and protocols• Descriptive text of security objectives and key assets

Arc

hitect

ura

l D

isco

very

Identify assets

and their

attributes

Identify risks,

threats, threat

vectors & actors

Refine and rank threats. identify

Abuse Cases

Objective: Identify major threats and attack points.

Assets may be network elements, services or data stores that are of interest to attackers.

Use industry info on common attacks related to interfaces and apply asset-based threat modeling.

Apply pruning and weighting methods to prioritize threats. Identify Abuse Cases to quantify impact of attack.

Considerations:• These steps rely on the deliverables from the Architecture Discovery steps.• Each interface may be an attack point.• Abuse Cases are a combination of Use Cases and attack vectors.• Iterating among the three activities is recommended until thorough

coverage is achieved.• Annotating diagrams with potential attack points is recommended.Outcomes/Deliverables:• Ranked list of threats correlated to assets and interfaces.• List of Abuse Cases.• Annotated diagrams indicating attack points.

Thre

at

Identifica

tion

Architectural Risk Analysis – WALL MAP

Assess threats and use industry security controls references to determine if threat is mitigated.

Evaluate each

threat

Identify actions required to

address now or in future activity

.

,

. ,

.

Is threat mitigated?

Annotate diagrams with security control

and indicate mitigation

Yes

No

If additional controls are considered now, then process may iterate. Otherwise, gaps are part of final report.

Considerations:• Use data from Threat Identification activities.• Iterate through entire list of threats individually until each are fully

evaluated.• The Cloud Controls Matrix published by the Cloud Security Alliance is a

good security controls reference.Outcomes/Deliverables:• Revised diagrams and reference material that reflect coverage of security

controls and any threats that may not be fully mitigated.• Actions that may be required to strengthen security.

Objective: Assess effectiveness of security controls and countermeasures.

Ris

k A

naly

sis

1 2 3

54a 4b

6a

6c

6b

Documents

Cybersecurity Architectural Risk Assessment (ARA) Overview