cybersecurity architectural risk assessment (ara) overview presentation · 2 days ago · overview...
TRANSCRIPT
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/01_resources/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
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
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, and 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
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
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, and 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
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
Mapping MITRE Attack Classes to Threat Surfaces
34
ATTRIBUTE THREAT SURFACE ATTACK CLASSES
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
Mapping MITRE Attack Classes to Threat Surfaces
35
ATTRIBUTE THREAT SURFACE ATTACK CLASSES
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)
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
Mapping MITRE Attack Classes to Threat Surfaces
36
ATTRIBUTE THREAT SURFACE ATTACK CLASSES
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
* © 2020 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.
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)
Attributes Threat Surfaces
Attack Classes
Asset Authenticity Supply Chain
IA.9 Supply Chain – non authentic componentSupply Chain
IA.9 Supply Chain – modified component – HW/SW
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)
Attributes Threat Surfaces
Attack Classes
Asset Authenticity Supply Chain
IA.9 Supply Chain – non authentic componentSupply Chain
IA.9 Supply Chain – modified component – HW/SW
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)
Attributes Threat Surfaces
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).
IA.11 Valid Accounts
IA.11 Valid Accounts
SHOULD YOU DO THIS (attack class feed both
Threat Surfaces)
OR
THIS (Separate attack classes for each surface)
IA.11 Valid Accounts
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)
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
• 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
IA.9 Supply Chain – modified component – HW/SW
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
Asset 2Threat Surface 6
Threat Surface 4
11
IntegrityThreat Surface 8
Asset 3Threat Surface 9
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
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, and 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
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