deliverable d2.1 - reference scenarios and use cases - reference... · project full title:...

This document is part of a project that has received funding from the European Union’s Horizon 2020 research and innovation

programme under grant agreement No 779899. It is the property of the SecureIoT consortium and shall not be distributed or reproduced without the formal approval of the SecureIoT Management Committee.

Project Acronym: SecureIoT

Grant Agreement number: 779899 (H2020-IoT03-2017 - RIA)

Project Full Title: Predictive Security for IoT Platforms and Networks of Smart

Objects

DELIVERABLE D2.1 - Reference Scenarios and

Use Cases

Deliverable Number D2.1Deliverable Name ReferenceScenariosandUseCasesDissemination level Public

Type of Document Report

Contractual date of delivery 30/04/2018

Deliverable Leader SILO

Status & version Final-1.0

WP / Task responsible WP2(FUJI) / Task T2.1(SILO)

Keywords: Abuse Cases, Cyber Threats, Vulnerabilities, IoT, Factory 4.0,

Socially Assistive Robots, Autonomous Vehicles

Abstract (few lines): The aims of the deliverable are to define the use cases related to

cyber attacks that can be performed in IoT ecosystems of three

distinct domains.

Deliverable Leader: Kostas Kalaboukas (SingularLogic)

Contributors:

Adam Evangelos (SingularLogic), Vidali Peggy (SingularLogic),

Tsatsoulas Apostolos (SingularLogic), Panagiotis Gouvas

(UBITECH), Juergen Neises (Fujitsu), Pouyan Ziafati (LuxAI),

David Evans (IDIADA), Sofoklis Kyriazakos (iSPRINT) , Daniel

Calvo (ATOS)

Reviewers: Daniel Calvo (ATOS), John Soldatos (AIT)

Approved by: George Koutalieris (INTRA)

Project Title: SecureIoT

Contract No. 779899 Project Coordinator: INTRASOFT International S.A.

D2.1 - Reference Scenarios and Use Cases,

Ve rs ion: v1.0 - Final, Date 30/04/2018

Executive Summary The purpose of this deliverable is to elaborate on reference scenarios related to cyber attacks

on emerging IoT ecosystems that correspond to several domains. In order to perform this

identification, a cyber-risk-oriented methodology has been adopted. In the frame of this

methodology, the assets that participate in the ecosystems are identified. These may be cyber

assets, physical assets or cyber-physical. Each asset may be associated with one or more

vulnerabilities. Each vulnerability can be (potentially) exploited by one or more attacks that can

make use this vulnerability. It should be clarified that, in the context of cyber security, the

concept of ‘attack’ coincides with the context of ‘threat’.

Regarding assets, vulnerabilities and threats there are already existing enumerations/standards

that have been introduced by the security community in order to resolve semantic mismatch of

concepts. The enumeration which is highly critical for this document is the adoption of an

attack enumeration. For the sake of completeness, CAPEC1 has been used which is considered a

dominant attack classification.

Taking into consideration the specificities of each domain specific adversarial models have been

explored. Based on these adversarial models the distinct attack patterns have been aggregated.

These patterns include spoofing, tampering, repudiation, information disclosure, denial of

service, elevation of privilege, etc. The exploration of all scenarios led to an exhaustive listing of

attack patterns. Annex I provides detailed information derived by CAPEC per identified abuse

case.

The produced output is valuable information, especially for the subsequent tasks of WP2 and

WP3, since identified attack patterns will be prioritized and corresponding mitigation

mechanisms, that will be developed in the frame of the project, will be mapped to the

produced list.

1 https://capec.mitre.org/





Document History

Version Date Contributor(s) Description

0.1 06/03/2018 Kostas Kalaboukas Initial ToC

0.2 15/03/2018

Kostas Kalaboukas,

Panagiotis Gouvas,

Tsatsoulas

Apostolos

Methodology first version

0.3 21/03/2018 Pouyan Ziafati,

Sofoklis Kyriazakos Socially Assistive Robots draft version

0.4 06/04/2018 Juergen Neises Factory 4.0 scenarios added

0.5 13/04/2018 David Evans, Autonomous vehicle scenarios added

0.7 19/04/2018

Kostas Kalaboukas,

Tsatsoulas

Apostolos

Introduction, Execution Summary and

Conclusions added

0.8 23/04/2018

Panagiotis Gouvas,

Pouyan Ziafati,

Daniel Calvo,

Juergen Neises,

Adam Evangelos

Input from all partners refined

0.9 26/04/2018 Kostas Kalaboukas Version Delivered for internal review

1.0 30/04/2018 Kostas Kalaboukas Reviewers Comments Integrated





Table of Contents Executive Summary ......................................................................................................................... 2

Definitions, Acronyms and Abbreviations ...................................................................................... 8

1 Introduction ............................................................................................................................. 9

2 Adopted Methodology .......................................................................................................... 10

2.1 Definitions related to Cyber Risk Assessment .............................................................. 10

2.2 Mapping of Cyber Risk Assessment Methodology to SecureIoT Context .................... 12

3 Factory 4.0 Scenarios ............................................................................................................. 13

3.1 Head-mounted device @factory/supermarket/shop ......................................................... 13

3.1.1 Description.................................................................................................................... 13

3.1.2 Abuse Cases .................................................................................................................. 13

3.2 Control Cabinet ................................................................................................................... 15

3.2.1 Scenario Description ..................................................................................................... 15

3.2.2 Abuse Cases .................................................................................................................. 16

3.3 Manufacturing facility ......................................................................................................... 19


3.3.2 Abuse Cases .................................................................................................................. 20

3.4 Production related Transactions in an Eco2Eco System ..................................................... 23


3.4.2 Abuse Cases .................................................................................................................. 24

3.5 Order-Controlled Production .............................................................................................. 26


3.5.2 Abuse Cases .................................................................................................................. 27

3.6 Smart Process Automation.................................................................................................. 29


3.6.2 Abuse Scenarios ............................................................................................................ 31

4 Connected Vehicles and Autonomous Driving Scenarios...................................................... 35

4.1 Description .......................................................................................................................... 35

4.2 Abuse Cases ......................................................................................................................... 36

5 Socially Assistive Robots Scenarios........................................................................................ 41

5.1 Description .......................................................................................................................... 41





5.2 Abuse Cases ......................................................................................................................... 42

6 Smart Cities Scenarios ........................................................................................................... 45

6.1 Description .......................................................................................................................... 45

6.2 Abuse Cases ......................................................................................................................... 47

7 Smart Home Scenarios .......................................................................................................... 50

6.1 Description .......................................................................................................................... 50

6.2 Abuse Cases ......................................................................................................................... 50

8 Identified Threat landscape and the role of SecureIoT ......................................................... 54

9 Conclusions ............................................................................................................................ 57

References .................................................................................................................................... 58

Annex I – Elaboration on Relevant Abuse Cases based on CAPEC classification.......................... 59





Table of Figures FIGURE 1 - CONCEPTS OF CYBER RISK ASSESSMENT ................................................................................................................. 10 FIGURE 2 - HEAD MOUNT DEVICE USAGE .............................................................................................................................. 13 FIGURE 3 - INDICATIVE CABINET ........................................................................................................................................... 15 FIGURE 4 - IOT DEPLOYMENT IN MANUFACTURING FACILITY ..................................................................................................... 20 FIGURE 5 – ECO2ECO SYSTEM ............................................................................................................................................. 23 FIGURE 6 - ORDER STAKEHOLDERS ....................................................................................................................................... 26 FIGURE 7 – ORDER WORKFLOW .......................................................................................................................................... 27

FIGURE 8 - TRUST CENTER .................................................................................................................................................. 27 FIGURE 9: TYPICAL CONVEYOR BELTS FOR SCHEDULING PALLETS FOR SHIPMENT............................................................................. 30 FIGURE 10: ARCHITECTURE OF THE FORWARDING PLATFORM .................................................................................................... 31 FIGURE 11 - WIRELESS AND WIRED CONNECTIONS OF CLOUDCARE2U DEPLOYMENT ..................................................................... 41 FIGURE 12 - QT’S ANIMATED FACE EXAMPLES ....................................................................................................................... 42 FIGURE 13 - QT APPLICATIONS EXAMPLES (AUTISM THERAPY, ELDERLY REHABILITATION) .............................................................. 42 FIGURE 14 - FIWARE FOR SMART CITIES .............................................................................................................................. 46 FIGURE 15 – INDICATIVE TYPE OF SENSORS/ACTUATORS USED IN A SMART HOME ......................................................................... 50 FIGURE 16 - IMPACT OF EARLY WARNING/PREDICTION IN THE MITIGATION LOOP........................................................................... 54 FIGURE 17 - OVERVIEW OF SECUREIOT HIGH LEVEL ARCHITECTURE ........................................................................................... 55





List of Tables TABLE 1 - INDICATIVE CAPEC ATTACK TREE CLASSIFICATION.................................................................................................... 11

TABLE 2 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 14 TABLE 3 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 17 TABLE 4 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 21 TABLE 5 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS............................................................................................ 24 TABLE 6 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 28 TABLE 7 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 32 TABLE 8 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 38 TABLE 9 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS ............................................................................................ 43 TABLE 10 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS .......................................................................................... 47 TABLE 11 - CAPEC ATTACK CLASSIFICATION OF RELEVANT THREATS .......................................................................................... 51





Definitions, Acronyms and Abbreviations Acronym Title

AMQP Advanced Message Queuing Protocol

CAPEC Common Attack Pattern Enumeration and Classification

CASD Context-Aware Safety Driving

CC2U CloudCare2U IoT healthcare platform

CIA Confidentiality, Integrity and Availability

CO Confidential, only for members of the consortium (including Commission Services)

CPE Common Platform Enumeration

CVE Common Vulnerability and Exposure

DoS Denial of Service

DSRC Dedicated Short-Range Communications

IoT Internet of Things

LiDAR Light Detection and Ranging

MES Manufacturing Execution System

PU Public

RobAPL Robot Agent Programming Language

ROS Robot Operating System

SDLC Software Development Lifecycle

TL Task Leader

WP Work Package





1 Introduction The scope of the deliverable is to identify reference scenarios related to cyber security taking

into consideration the specificities of different vertical sectors. The ultimate goal of this

deliverable is to conclude on specific use cases that are meaningful in each domain related to

cyber attacks that can occur on the environment of these domains, with particular emphasis on

attacks that could highlight and justify the added-value of the SecureIoT project. Therefore, it

could be argued that identified use cases are actually abuse cases since they model adversarial

models. However, a crucial aspect of this exercise is the identification of a methodological

framework which will help us to produce an unified outcome.

Towards these lines, a methodology that builds on top of existing abstractions has to be

introduced in order to model the abuse cases. Such unified modelling is essential since the

outcome of this deliverable will be used in a multifold way. More specifically, the requirements’

analysis and the architectural design of the SecureIoT architecture will at some extend rely on

the tangible outcome of this deliverable.

Another critical issue regarding the identification of abuse cases is the alignment with

international standards. Part of the analysis that has to be performed relates to concepts that

are formally defined in standards that are considered de-facto. These include vulnerabilities,

threats, controls etc. It is of major importance to respect these standards since the project aims

to deliver results which will be swiftly exploitable to the industry.

During the definition of the abuse case emphasis will be paid in scenarios involving security

functions distributed at both the edge and the core of an IoT deployment. Moreover, the

definition will take under consideration multi-platform interactions and the use of smart

objects in IoT applications, which two characteristics that are at the very core of SecureIoT’s

developments.

The structure of the deliverable is performed in a way which helps the reader comprehend the

identified abuse cases of the analyzed domains independently. More specifically, Chapter 2

elaborates on the adopted methodology that is used in order to document the abuse cases. It is

highly substantial for a reader to comprehend the definitions that are elaborated in this chapter

since these definitions will accompany practically all future deliverables.

Chapters 3,4,5,6 and 7 follow exactly the same structure. Each chapter is devoted to one

thematic area i.e. Industry 4.0, Connected Vehicles, Social Assistive Robots, Smart Cities and

Smart Home. Per each thematic area, distinct scenarios will be discussed in order to introduce

the reader to the operational ecosystem of the domain. Upon elaboration of the functional

ecosystem, the identified attack patterns that are applicable to the scenario are listed, and the

attack patterns per se constitute the identified abuse cases. Finally, Chapter 8 provides a

correlation of the outcomes with the vision of SecureIoT while Chapter 9 concludes the

deliverable.



D2.1 - Refe rence Scenarios and Use Cases,


2 Adopted Methodology 2.1 Definitions related to Cyber Risk Assessment In the context of cybersecurity, the identification of abuse cases is practically identical with the

process of exploring the attack surface of each potential target. Exploiting a target contributes

to several consequences which may span from financial, environmental etc. However, a

successful exploitation can be performed by an adversary only through the usage of an

existing/identified vulnerability. During the security analysis of an ecosystem, it is highly crucial

to have a clear view of the concepts that are used during the analysis. In order to come up to a

common model that will be used during the lifecycle of the entire project, we will adopt

concepts from the domain of Risk Assessment. Figure 1 provides a high-level view of concepts

that are widely used in the (Cyber) Risk Assessment domain.

Figure 1 - Concepts of Cyber Risk Assessment

The starting point is “Asset”. An asset can be a cyber, physical or cyber-physical element within

an organization that is used in the frame of business operations. Furthermore, an asset can be

something tangible or intangible. Furthermore, an asset may entail a specific business value by

itself. Irrelevant of the nature and the type of an asset, each asset may entail several

Vulnerabilities.

A vulnerability is the stepping stone of the adversary since s/he must identify one in order to

harm an Asset. It should be clarified that vulnerabilities are inherent properties of assets and

depend on their nature/type. Creating an abstract model for a vulnerability is rather challenging

since many parameters have to be taken into consideration. Although there are many models





that have been proposed, the Common Vulnerability and Exposure (CVE2) model is considered

predominant. According to this model a vulnerability is characterized by two properties;

exploitability, i.e. how easily you can make use of the vulnerability and impact i.e. how

dangerous is the exploitation of this vulnerability. The model defines sub-scores for

Confidentiality, Integrity and Availability (a.k.a. CIA) consequences. An open repository for

disclosed vulnerabilities can be found here: https://www.cvedetails.com.

As it is inferred, a vulnerability may be exploited during an ‘Attack’ that is able to make use of

this vulnerability. In the cyber security domain, the terms Attack and Threat coincide. In the

frame of this document and in the scope of the entire project these terms will be semantically

equivalent. Analogous to the Vulnerabilities, Threats maintain their own metamodel. A widely

used model/taxonomy is Common Attack Pattern Enumeration and Classification (CAPEC3). The

objective of the CAPEC effort is to describe most common attack patterns classified in an

intuitive manner. The attacks were defined using the CAPEC taxonomy which is defined and

described below. As seen in Table 1 several types of threats are identified and categorized per

domain and mechanism.

Table 1 - Indicative CAPEC Attack Tree Classification

Category Attack Excavation – 1164 JSON Hijacking (aka JavaScript Hijacking) - 111

Directory Indexing -127

Common Resource Location Exploration - 150 Cross-Domain Search Timing - 462

Generic Cross-Browser Cross-Domain Theft - 468 Probe Application Screenshots - 498

Probe Application Error Reporting - 54

Probe Application Queries - 545 Probe Application Memory - 546

Interception – 117 Sniffing Network Traffic - 158 Accessing/Intercepting/Modifying HTTP Cookies - 31

Harvesting Usernames or User IDs via Application API Event Monitoring - 383 Intent Intercept - 499

Footprinting – 169 Host Discovery – 292

Port Scanning – 300 Network Topology Mapping – 309

Malware-Directed Internal Reconnaissance - 529 Fingerprinting – 224 OS Fingerprinting - 311

Application Fingerprinting - 541 Social Information Gathering Attacks – 404

Social Information Gathering via Research - 405 Social Information Gathering via Dumpster Diving - 406

Social Information Gathering via Pretexting - 407 Information Gathering from Traditional Sources - 408

2 http://cve.mitre.org/ 3 https://capec.mitre.org 4 The number following each CAPEC category or member represents its unique identification number, CAPEC-ID, which enables a fast discovery and retrieval of its description.





Information Gathering from Non-Traditional Sources - 409

Information Elicitation via Social Engineering - 410

Social Information Gathering via Pretexting - 407

Injection - 152 Code Injection – 241

The successful exploitation of a vulnerability through an attack leads to Impact. In order to

prevent this impact, specific Control elements should be installed. However, as depicted in

Figure 1 a control element can be applied at the Vulnerability Level or at the Threat Level

(never to both of them). Imagine of a scenario where a software remotely exploitable

vulnerability is identified. If the administrator patches this vulnerability s/he applies a control at

the vulnerability Level. If an administrator setup a Web Application Firewall (a.k.a. WAF) in a

virtual machine s/he applies a control at the Threat Level since many attacks can be

simultaneously mitigated (e.g. SQL injection, Remote File inclusion etc.)

The knowledge of assets, vulnerabilities and applicable threats are the prerequisites that have

to be defined in order to quantify Risk. Sometimes, the concept of Risk is misunderstood with

the concept of Threat; yet it is not. In general, risk is calculated through an equation as follows:

Risk =f( TL , VL, IL ) [Equation 1]

where TL represents the possibility of an attack being materialized, VL represents the

exploitability of the Vulnerability and IL the impact of an exploitation.

2.2 Mapping of Cyber Risk Assessment Methodology to SecureIoT

Context Taking a close look at the equation above, one can observe that two out of the three

parameters are static and one is dynamic. In fact, Vulnerability Level and Impact Level are

always known a-priori. However, threat level is not. Therefore, it is highly crucial to

comprehend that quantifying a risk for a cyber ecosystem implies the knowledge of the

possibility of being attacked. Furthermore, minimizing the risk implies that you have the

mechanism to predict an attack. Both knowing and predicting a Threat are hard tasks; yet they

are in the central core of the SecureIoT framework. The mechanisms that will be developed will

act as mitigation elements for specific threats and will also contribute to the quantification of

the Threat Level in near real time. Therefore, it is crucial for the design of the system, to set the

boundaries of the threats that will be handled. In this deliverable, an exhaustive list of Threats

that are relevant to the IoT ecosystem should be explored. The quantification of risk is highly

importance since it is a tangible way to achieve privacy and regulatory compliance.





3 Factory 4.0 Scenarios 3.1 Head-mounted device @factory/supermarket/shop 3.1.1Description

The rise of Industry 4.0, or smart manufacturing, has provided manufacturers with the ability to

utilize complex IoT devices to achieve operational goals such as cost reduction, improved floor

safety, increased efficiency and productivity, and continuous innovation. A perfect example

towards this direction is the use of head-mounted IoT devices in plant facilities that undertake

partial or complete supply chain activities.

Figure 2 - Head Mount Device Usage

Workers, when equipped with head-mounted devices, receive constant feedback in all aspects

of individual task execution. With the assistance of embedded cameras and object recognition,

the devices are acting as ubiquitous context-aware information centers, instructing workers in

tasks such product assembly and in-plant navigation. Furthermore, the IoT devices can provide

invaluable information about the manufacturing process to Manufacturing Execution Systems

(MES), further automating the production pipeline and achieving better overall performance.

3.1.2AbuseCases

For the head-mounted device scenario, the attack surface is considered relatively contained.

Under the assumption that no data exchange takes place over public insecure networks (or at

least in this case VPNs are employed to address security issues), the main security concern lies

with the wireless communication link between the IoT devices and MES (Manufacturing

Execution System).

Adversaries can sniff wireless traffic for sensitive system information that may be transmitted in

clear text (unencrypted). Furthermore, they can perform a range of attacks (WEP/WPA attacks,

brute force password cracking, etc.) in order to gain unauthorized access to internal network

resources. Lack of proper security controls, policies, and awareness (e.g. modern wireless

network encryption standards, strong passwords, controlled signal coverage, rogue access

points, etc.) contribute to the overall probability and consequent risk of such exploitation

attempts.





Provided that access to internal network resources is achieved, the attack surface is

significantly extended. Employing techniques like device fingerprinting can reveal invaluable

information about software/hardware components in use, as well as their respective

vulnerability profiles. Adversaries can exploit the latter and target both IoT devices and MES in

terms of gaining remote control or spreading falsified information. Similar attacks can also

occur indirectly through compromised devices. Malware running on workers’ handheld devices

(e.g., smartphones) can provide access to internal resources via reverse shells.

Table 2 - CAPEC Attack Classification of relevant Threats

Category (Attack Mechanism) Meta Attack Pattern Attack Pattern

Collect and Analyze Information - 118

Interception - 117 Sniffing Network Traffic - 158

Fingerprinting - 224 Application Fingerprinting - 541

Subvert Access Control - 225 Exploiting Trust in Client - 22

Man in the Middle Attack - 94

Employ Probabilistic Techniques - 223

Brute Force - 112 Password Brute Forcing - 49

Inject Unexpected Items - 152

Local Execution of Code - 549

Targeted Malware - 542

Engage in Deceptive Interactions - 156

Manipulate Human Behavior - 416

Influence Perception - 417

Influence via Incentives - 426

Identity Spoofing - 151 Fake the Source of Data -

194





3.2 Control Cabinet 3.2.1ScenarioDescription

Industry 4.0 aims to industrialize the product manufacturing process and achieve sustainably

improved productivity through product digitalization, standardization, and automation. The

example studied in this scenario describes the development of a control cabinet to be used in

industrial plants for production lines.

Figure 3 - Indicative Cabinet

The process benefits from individual component digitization and allows virtual engineering and

testing before moving to production. In the case of the control cabinet, the concrete steps are

as follows:

● Preparation of the electrical circuit diagram / electrical design engineer / E-CAD system

● Selection of products for implementation of the manufacturer's electrical schematic /

electrical constructor / configurator of the manufacturer's electrical schematic /

electrical constructor.

● Placement of Products / Electrical Constructor / Switch Cabinet Manufacturer's

Configurator.





● Technical testing of the construction (standards; e. g. dimensioning of the cooling of the

switch cabinet) / electrical designer / certification tool of the certifier.

● Preparation of the production documentation (electrical / mechanical) / electrical

constructor / tool of the switch cabinet manufacturer.

● Start of production

Collaboration between participating stakeholders and an AI-based incorporation of existing

experience and knowledge can further improve product quality and reduce implementation

times.

3.2.2AbuseCases

Data is key to Smart Engineering and Industry 4.0. From component digitalization and virtual

prototyping to intelligent production, digital pre-certification, and final assembly, data

undoubtedly drive intelligence and automation throughout the process. The same principle

applies to the case of the control cabinet development. The main emerging risk translates to

data integrity and availability. Databases and data stores, in all their forms (commercial/open-

source, embedded/centralized/distributed, flat files/RDBMS/NoSQL, or even simple files of

well-known standards like XML/CSV), have publicly disclosed vulnerability profiles and

constitute common attack targets. Adversaries are able to explore a broad range of attacks and

expose specific security weaknesses (e.g., insecure configuration, software vulnerabilities).

Successful exploitation can lead to - among others - unauthorized access to classified

information, data falsification, data deletion, and full compromise of the underlying hosts.

The validity of the above analysis extends to include the hosts running the software that

enables all phases of the control cabinet development. The vast majority of these applications

run on typical servers, workstations, and computing devices; thus, they inherit the attack

surface of the supporting OS, hardware, and all the additional set of applications installed.

Internet and network access can further expand the effective attack surface. An indicative

exploitation consists of a workstation running software like:

○ an information portal that provides up-to-date device data from leading

component manufacturers or

○ a CAE (computer-aided engineering) utility that enables planning of electrical

automation projects

that gets compromised either by a crafted PDF document sent by a malicious actor to

the user of the workstation or by a vulnerability associated with an embedded CAD

library.

In spite of the proprietary and specialized nature of the applications used in Industry 4.0, which

generally indicates lack of known exploitable vulnerabilities, the risk associated with software-

based weaknesses should also be assessed, especially as their use and the support of open

standards (e.g., eCl@ss) get more common (e.g., vulnerabilities associated with parsing of





eCl@ss configurations). It is also worth mentioning that such software solutions usually

undergo longer Software Development Lifecycles (SDLC), mainly due to their business criticality.

The latter results in longer turnaround times of applying software security patches and can

potentially form a barrier to updating dependent components (e.g., databases, software

libraries, browsers, etc.).





Fingerprinting - 224 Application Fingerprinting -

541



Bypassing Physical Security - 390

*






Parameter Injection - 137 *

Resource Injection - 240 *

Code Inclusion - 175 *

Code Injection - 242 *

Command Injection - 248 *

Object Injection - 586 *





Traffic Injection - 594 *

Fault Injection - 624 *






194

Manipulate System Resources - 262

Configuration/Environment Manipulation - 176

Disable Security Software - 578

Manipulating Writeable Configuration Files -75

Modification During Manufacture - 438

Development Alteration - 444

Design Alteration - 447

Malicious Logic Insertion - 441

Malicious Logic Inserted into To Product Software - 442

Malicious Logic Insertion

into Product Hardware - 452

Malicious Logic Insertion into Product Memory - 456

Obstruction -607 Blockage - 603

Physical Destruction of Device or Component - 547

Route Disabling - 582





Abuse Existing Functionality - 210

Functionality Misuse - 212 *

3.3 Manufacturing facility 3.3.1ScenarioDescription

In the era of Industry 4.0, manufacturing facilities need data and analytics in order to become a

part of the unfolding industry evolution. Novel IoT sensors are deployed in numerous locations

within the facility. In addition, IoT components are integrated into existing equipment. The

latter is called retrofitting and describes the process of indirectly improving the interoperability

of existing machines, through modern IoT devices.

In a typical use case scenario, autonomously deployed IoT sensors would provide general

facility-related information such as humidity, temperature, and exposure to hazardous

substances. Furthermore, machines would utilize attached IoT components to share critical

information regarding their status (e.g., tool status, power supply, quality checks, etc.).

On-premises fog computing infrastructures would then receive IoT sensor data through IoT-

optimized wireless networks (Narrowband IoT, LoRa, etc.), as well as machine-related

information via wired network communication. The purpose of the fog computing subsystem is

to:

● aggregate data from all sensors and IoT components

● perform edge processing of the collected data

● provide automated decision-making functionality based on the IoT input data (e.g. issue

notification for machine maintenance in case of gradually exploding power

consumption)

● provide big-data analytics related to the durability of the installed equipment

● forward filtered data to the cloud for storage and further processing.





Figure 4 - IoT Deployment in Manufacturing Facility

3.3.2AbuseCases

The “Manufacturing facility” scenario includes numerous actors that contribute to the total

exposed attack surface. Comprehensive analysis indicates the following attack domains:

● IoT sensors’ software.

● Wireless networks bridging IoT sensors to the Fog Computing infrastructure-(s)

● Manufacturing devices, embedded IoT sensors and remote control API (e.g., through

PLC)

● Wired connection between manufacturing devices and the Fog Computing

infrastructure-(s)

● Fog Computing Infrastructure.

● Cloud infrastructure.

● Fog Computing - Cloud link.

IoT sensors’ software vulnerabilities can vary significantly depending on the underlying

hardware and software stacks. Read-only sensors that solely broadcast data do not impose

considerable risk in the overall process. On the other hand, more powerful IoT devices (e.g.,

Raspberry Pi based) constitute direct attack targets and can be used as pivoting nodes if root-

compromised.

As per previous use cases, the wireless link between IoT sensors and the Fog Computing should

be assessed in terms of risk. The security of the wireless network medium is key to preventing

data sniffing and unauthorized access attempts. For example, Narrowband IoT inherits the





entire body of LTE’s well-established security techniques like authentication and encryption and

benefits greatly from security features developed by commercial cellular technologies over

many generations of cellular signaling in contrast with alternatives like LoRa.

The hardware, software and network components that form the computing fog, the cloud, and

their interconnection are also key to the effective attack surface. Insecure configurations,

component vulnerabilities and lack of proper security controls, policies and awareness can

result in data and state falsification and manipulation, unauthorized remote access and control,

the disclosure of sensitive information and others with a huge impact in business continuity and

workers’ safety.











*





















194












Malicious Logic Insertion into Product Hardware - 452









3.4 Production related Transactions in an Eco2Eco System 3.4.1ScenarioDescription

Increasing demands by consumers for customized, high-quality products at favorable prices are

posing new challenges for industrial enterprises. Acknowledging the pressure for high return on

investment (RoI) rates, it is clear that Industry 4.0 will also affect the business models of

product manufacturers.

Figure 5 – Eco2Eco system

Digitalization serves act as enablers of new business models in industrial manufacturing.

Industrial manufacturers typically sell products and services or provide bundled solutions.

Others have already moved to equipment-as-a-service. Indicative business services that fit a

pay-per-use model include:

● products such as (configurable) machines, equipment or parts

● aftermarket service

● value-added services





● solutions, by bundling products with other products, software, contracts, service, and

value-added services

● equipment-as-a-service

Given the ever-growing information transmitted by IoT devices of the modern era, each

industrial manufacturer can be considered as an ecosystem that can interact with others and

offer rich services to clients. Collaboration, smart analytics and prediction can significantly

enhance the quality of the provided end-services.

3.4.2AbuseCases

The attack surface is a subset of the one described in the “Manufacturing facility” use case.



Collect and Analyze Information – 118



Subvert Access Control - 225 Exploiting Trust in Client -

22

Man in the Middle Attack -

94


*























194





















3.5 Order-Controlled Production

3.5.1ScenarioDescription

Over the past years, the manufacturing industry did undergo a sustained transformation.

Currently, it is facing diverse challenges in the light of digitalization and changing market

requirements. Many products are changing at an ever-increasing rate. Companies have to react

quicker and make investment decisions on an ad-hoc basis to remain competitive. In order to

put such dynamic industrial relationships into practice, in a cost-efficient manner, external

production characteristics have to be incorporated into self-owned production pipelines.

Therefore, an increasing number of industrial companies is starting to counteract this trend and

to avoid protracted decision processes on investments. What is their strategy? It is to interlink

their capacities along with production capabilities. The latter, enables them to adapt quickly to

market changes and customized orders, as well as to make the best use of internal and

contracting resources in a holistic and unified manner. An indicative example is the controlled

production of a bike with a personalized handlebar.

Figure 6 - Order Stakeholders





As shown in the figure above, the two main stakeholders are the bicycle manufacturer (the

Client) and the handlebar supplier (the Contractor). The workflow of a personalized bicycle

order is as follows:

Figure 7 – Order Workflow

The bike manufacturer offers to its end-customers an online application with an embedded

bicycle configurator. End-customers decide upon the bicycle characteristics and the customized

handlebar and submit their order. Then, the bike manufacturer hosts an automated

procurement procedure to award the contract to a specific handlebar supplier. The identities of

the bike manufacturer and the numerous potential handlebar suppliers are verified through

certificates (PKI) published by a commonly trusted entity.

Figure 8 - Trust Center

3.5.2AbuseCases

The attack surface is a superset of the one described in the “Manufacturing facility” use case.

The existence of a publicly accessible web application that enables ordering of customized bikes





makes the overall process susceptible to denial of service attacks (DoS). While a DoS or a DDoS

(distributed DoS) attack can potentially impact any public service, in the previous use cases

examined a VPN could be employed to protect access in cloud services; hence, the imposed risk

is not among the significant ones.






























194







Sustained Client

Engagement - 227

HTTP DoS - 469

Flooding - 125 TCP Flood - 482

HTTP Flood -488

SSL Flood - 489

3.6 Smart Process Automation 3.6.1ScenarioDescription

Manufacturers typically produce large volumes of different products each day. After completion of the manufacturing and quality control testing these newly produced products have to be channeled to the premises of distributors or points of sale. The products are usually packaged, the packages are placed into pallets and the pallets are prepared for shipping. This last part of the whole process, i.e. scheduling the pallets for shipment, is a crucial one as it solves an optimization problem, namely, minimization of the duration the pallets stay in the manufacturers’ warehouse. Storing pallets in a warehouse is a mere cost for any manufacturer, therefore their efficient forwarding is a high priority task.





The present reference scenario concerns manufacturer of white appliances, who makes use of conveyor belt platform for placing its products to the appropriate queue for loading and

shipment. Figure 9 shows a typical array of conveyor belts. Upon reaching the head of the conveyor belt, a pallet is transferred by forklifts to the appropriate truck for shipment.

Figure 9: Typical conveyor belts for scheduling pallets for shipment

The decision to which conveyor belt the next pallet will go to is crucial as noted above, as the load (number of pallets) on each one has to be balanced among them. To maintain such a balanced progress of forwarding pallets, inputs are taken from the sensors that are deployed on the conveyor belts as well as on the expected load, i.e., number of new pallets expected from the production. The corresponding algorithm, then, decides on which conveyor belt the next pallet should be directed.

Figure 10 shows the architecture of the conveyor belt platform. The bottom of the figure shows a number of conveyor belts (Bays), each one having sensors for reporting its status. Bays comprise the edge nodes of the overall architecture. The Sorter, a central component in the overall architecture, decides which bay the next pallet will be directed to. As shown in the figure, there is a bidirectional communication link between the Sorter and each of the bays: status reports are sent from each bay to the sorter and control signals are sent from the sorter back to the bays. This communication takes place through the edge gateways of the architecture. The architecture shows also a Simulator component. It role is to provide responses to dynamic changes of the load and/or outages of bays. Based on information received form the Sorter, the Simulator decides a new forwarding plan, which communicates back to the Sorter. As shown in the architecture, the Simulator runs on the Cloud.





Figure 10: Architecture of the forwarding platform

Two stakeholders are involved in the present scenario: the Manufacturer and the Service

Provider. The Sorter and the Bays belong to the domain of the white appliances manufacturer,

whereas the Simulator belongs to the Service Provider.

3.6.2AbuseScenarios

In the Conveyor Belt Management use case, there are two main risks that can affect business continuity:

information theft

service disruption.

Information theft includes attacks that target either the disclosure of specific information (e.g., the product shipment plans of a manufacturer), or the implicit knowledge and intelligence present in a solution or component used throughout the process (e.g., adversaries can target the algorithm that the Simulator uses in order to schedule product shipment plans and offer it to competitors for return rewards).

While information theft is a perfectly valid risk, it would be more probable in the case where the equipment under shipment was of more critical nature (e.g., equipment that is associated with public health, safety, etc.) than the white appliances studied in this scenario. Furthermore, exposing internal characteristics of specific components (e.g., hardware, software, algorithms, etc.) is a very thorough process which

requires a lot of reverse engineering and expertise,

Simulator

Sorter

Bay #1 Bay #n Bay #2

Bay #3 Conveyor





assumes certain levels of access on the key process components (e.g., the adversary must be in a location with network access to the cloud hosting the Simulator and the relative services to attempt an attack against them), and

becomes significantly more complicated when proprietary solutions are employed for specific parts of the process (e.g., a proprietary API between the Simulator and the Sorter is more difficult to exploit than a publicly documented API, since the adversary will have to reverse engineer and discover the exposed functionality).

Undoubtedly, the key risk requiring extra analysis is the service disruption one. Service disruption can manifest itself either as partial or complete system unavailability or system malfunction. The Conveyor Belt Management process is a data-centric one and consists of the following key communication links:

bidirectional communication between the Sorter and the Bay nodes; namely, Bay nodes communicate their status and integrated sensor data to the Sorter, while the latter orchestrates the loading of pallets to the bays through control signals

bidirectional communication between the Sorter and the Simulator; the Simulator receives a handful of data from the Sorter with regards to the Bay nodes, analyses them, constructs a shipment plan and communicates it back to the Sorter for execution.

Adversaries can disrupt the pallet loading process by attacking directly the Bay nodes, the Sorter and/or the Simulator. Depending on the underlying technology stack, they can cause a denial of service either by flooding the network with crafted network traffic or by exploiting a specific confirmed component vulnerability.

In addition, man-in-the-middle attacks can be utilized in order to target the key data exchanges. If successfully materialized, adversaries can manipulate the data exchanged and alter

the control signals being sent to the Bay nodes, the sensor data received by the Sorter,

the data sent as input to the Simulator in order to build the shipment plan, and

the shipment plan itself, as received by the Sorter.

Any of the above-mentioned interventions will cause an indirect service disruption through falsified and manipulated data, which is more difficult to identify and resolve than a denial of service attack against a specific node.

In conclusion (and apart from the cyber-based attack surface), service disruption by means of physical destruction of devices or components must be assessed for a holistic and comprehensive risk analysis. Authorized personnel with malicious intent could potentially bring specific devices or components out of service, causing a great impact to the process as-a-whole.



Collect and Analyze Interception - 117 Sniffing Network Traffic -





Information - 118 158







*





















194





















4 Connected Vehicles and Autonomous Driving

Scenarios 4.1 Description The automotive industry has suffered a progressive transformation with the objective of

increasing the security and comfort of the vehicles during the last decades. Modern cars

integrate complex HW/SW systems which monitor and potentially control in real-time diverse

aspects, such as the performance of the different components and subsystems, environmental

conditions or the status of the driver and the passengers. This trend is being boosted by the

digital transformation happening in almost any aspect of our lives and all OEMs are starting to

offer new services and applications, which imply the final digitalization of the vehicles and their

connection to the Internet (V2Internet), to the Infrastructure (V2I) or even to other vehicles

(V2V). Nevertheless, the final outcome will be much more ambitious; adding more sensors with

a higher degree of accuracy (e.g. Light Detection and Ranging (LiDAR)) will enable a better

understanding of the surrounding environment, combining this with onboard artificial

intelligence (AI) and machine learning algorithms will make possible to reach full-automated

driving systems (autonomous cars).

Starting from the V2Internet, it could be argued that from the IoT perspective, connected

vehicles shall be observed as mobile networks of smart objects which have the potential to

produce over 4000 signals per second and whose behavior can be influenced remotely. The

continuously aggregated vehicle Big Data has a great potential interest for a variety of cross-

sectoral service providers: weather forecasting, map providers, insurance companies and

obviously to the own vehicle manufacturers.

An example of a usage scenario is analyzing vehicle data to assess driver behavior and hence

determine risk in order to better tailor insurance premiums. Vehicle data is gathered on the IoT

device relating to the driver’s vehicle operation and driving behavior (acceleration, steering,

braking, etc.). The information gathered will be transmitted from the host vehicle to a cloud-

based service for analysis. This data will be used to gain a deeper insight into the driver’s

behavior and vehicle usage, and will, therefore, determine the insurance premium.

Let us elaborate on the V2Infrastructure case. In a more advanced scenario which will be

feasible in medium-term, the connected vehicle is integrated as part of a bigger IoT deployment

where multiple infrastructures are also smart objects: vehicle detection loops installed near a

traffic light, traffic signals, trolling collection systems, parking management or electrical

charging stations.

Indicative examples of use-cases could be in-vehicle signage, warning about roadworks and

weather conditions, green light optimal speed advisory systems, traffic priority request by

designated vehicles, etc. Furthermore, the eCall service, which will be mandatory for new





vehicles in Europe from 2018, is a fine example of the possible services for this scenario.

Although the current approach is based on cellular communications, an alternative may use

Dedicated Short-Range Communications (DSRC).

Finally, concerning V2Vehicle, it could be argued that in the mid or long term, the exchange of

data between vehicles will result in a distributed peer-to-peer network of smart objects based

on underlying short-range communications. In a first approach, the driver may receive

notifications about approaching emergency vehicles or traffic jams ahead (Context-Aware

Safety Driving (CASD)). However, the possibilities are almost endless and services like

cooperative cruise control are also in the roadmap of OEMs, public authorities and service

providers.

4.2 Abuse Cases

Connected vehicles form a very special case cybersecurity-wise since there are multiple assets

that can be defined. Initially, the focal point is the Communication Control of the Vehicle. The Communication Control domain is a set of communication features offered by a Telematics control unit (TCU) which is acting as a gateway. The gateway provides both the connectivity and most of the security protections intended for the communications (firewalling, authentication features…). It collects data from the various ECUs using one of the vehicle data buses and provides Internet remote connectivity through an embedded GSM module or using driver’s smartphone for instance. This unit is generally also coupled with a GNSS to obtain vehicle positioning information. A number of functions that are leveraging TCU connectivity are:

Remote diagnostic (e.g. failure notifications, updating ECU SW/FW or ECU parameters) Remote transmission of vehicle data

Crash reporting and emergency warning (eCall, that will be mandatory in Europe in 2018)

Stolen vehicle tracking or geo-fencing

Remote engine start

Fleet management, for instance for rental car companies (for example for trip tracking or diagnosis)

Insurance, for pay-as-you-drive insurance plans “smart driving assistant” (e.g. for fuel efficiency or to improve driving habits)

Inform driver on the battery State of Charge (SoC) for Electric Vehicles (EV)

Eco-driving

Big Data applications

The TCU typically provides 3G or Wi-Fi connectivity to provide several kinds of services. Other protocols are possible, as shown in the list below, which gives an example of external and internal interfaces found in a smart car. These typically include interfaces intended for long range communication, as well as wired or wireless interfaces intended for local use.

External Communication Networks:

Wired Protocols o USB





o OBD II (for diagnostics)

Intra-vehicle wireless protocols o Wi-Fi o Bluetooth o ZigBee o Passive RFID o UWB o DASH7 (used for Tire Pressure Monitoring Systems)

Long-range wireless protocols o GSM/GPRS/3G/4G/UMTS/LTE (for i.e. eCall service or OTA updates to car

component firmware) o GNSS (for localization) o LoRa and SIGFOX (IoT protocols solutions)

Vehicle-to-infrastructure wireless protocols o WAVE (Wireless Access in Vehicular Environments) (IEEE 802.11P) o WiMax

o DSRC (Dedicated Short Range Communications) (IEEE 802.11a)

Therefore, it could be argued that each connected vehicle represents a mobile network of IoT

components, that is able to:

● stream data across multiple destinations (e.g., cloud, private infrastructures, other

connected vehicles) and through a variety of wireless protocols,

● perform edge processing of the collected data in order to reduce the content that has to

be communicated to the different destinations, and

● receive, validate and execute commands for remote control.

Apart from the apparent attacks that might target the software, the hardware and

communication protocols of all components within a connected vehicle, an extra threat

emerges with reverse engineering. Adversaries have in this use case the possibility to further

examine the individual components via white-box and black-box techniques and attempt

identity theft, identity spoofing, data corruption, data falsification, data manipulation, as well as

remote control and command injection. A hypothetical scenario would require the adversary to

discover a sensor vulnerability, force certain values on it and consequently fire an alarm causing

the vehicle to slow down and pull over on the side of the road when feasible. A connected

vehicle is at least as vulnerable as any typical computer system. The notable difference is the

potential immediate impact on personal and public safety.

The wireless communication links and the remote APIs used to support the V2Internet (Vehicle

to Internet/Cloud) and V2I (Vehicle to Infrastructure) extend the attack surface. Adversaries can

employ standard techniques (e.g., man-in-the-middle, identity spoofing, identity theft) in order

to:





● manipulate the data sent by connected vehicles to the cloud and private infrastructures

and affect services and 3rd parties that rely on data validity (e.g., abuse GPS tracking

info and correlate it with erroneous temperature data).

● manipulate the data sent to connected vehicles in order to achieve remote control or

deception of the driver.

● gain unprivileged access to sensitive information and disrupt drivers’ right to privacy.

● perform DoS or distributed DoS against any sub-system with immediate impact on

business continuity, service and safety..

Similar threats are present to the V2V scenario. The distributed nature of the communication

between connected vehicles increases the level of magnitude of the V2Internet & V2I threat

taxonomies since any connected vehicle can act as a malicious actor under certain

circumstances (in contrast with V2V and V2I use case scenarios where communication was

bound to specific endpoints).

Finally, it is worth mentioning that since most vendors (at least for the time being) develop

proprietary solutions, cyber attacks against one vendor won’t necessarily affect others. It is

anticipated though, that as autonomous cars evolve, open standards will be made available and

vendors will share common modules, libraries, software and IoT components, making cyber

attacks applicable on a cross-vendor basis.





Reverse Engineering - 188 White Box Reverse Engineering - 167

Black Box Reverse Engineering - 189
















Subvert Access Control - 225 Exploiting Trust in Client – 22









194





Obstruction - 607 Jamming - 601



Sustained Client

Engagement - 227

HTTP DoS - 469





Flooding - 125 TCP Flood - 482

HTTP Flood -488

SSL Flood - 489





5 Socially Assistive Robots Scenarios 5.1 Description

Nowadays, most robots and robotics platforms [1] tend to deliver functionalities independently of other internet-connected devices [2]. Hence, i.e. despite their pertinence and possible integration, IoT platforms and robots operate in isolation [3], which is a lost opportunity for a host of innovative functionalities. Security concerns are among the main barriers and concerns against the integration of IoT with smart semi-autonomous objects such as robots. In the scope of the SecureIoT socially assistive robots use case, we will demonstrate the secure integration of LuxAI’s QT robot(s) in an environment provided by iSPRINT’s CloudCare2U (CC2U) IoT healthcare platform, which holds the promise to enhance the functionalities offered by both QT and CC2U, while offering a host of business opportunities for both companies (LuxAI, iSPRINT). CC2U integrates a wide range of sensors and wearable devices (e.g., fitbit, motion trackers) in order to accurately detect the users’ context and provide relevant personalized services. CC2U includes already a virtual robot as an output interface. As part of this use case, QT will become CC2U’s interface for interaction with end-users.

Figure 11 - Wireless and wired connections of CloudCare2U deployment

The envisaged integration of QT with CC2U will focus on the delivery of personalized ambient assisted living functionalities, fully in-line with the business strategies of both partners. In





particular, QT will be used to deliver personalized rehabilitation and coaching exercises, as part of wider (rehabilitation or coaching) programs, managed and delivered through CC2U.

Figure 12 - QT’s Animated Face Examples

Figure 13 - QT Applications Examples (autism therapy, Elderly Rehabilitation)

In order to support these applications, a dense IoT network enabling continuous interaction

between IoT devices managed by CC2U, QT robots, human users and the environment will be

established. The integration between QT and CC2U can be directly realized, as CC2U has already

a virtual robot interface for interaction with end-users, which will be replaced by QT. The

integration challenge will however lie on keeping track of the state of QT and the environment,

as well as on implementing distributed task assignment strategies, such as the Consensus-Based

Bundle Algorithm (CBBA), which enable the distribution of application logic across different

smart objects.

5.2 Abuse Cases It could be argued that the socially assistive robot scenario exposes a huge attack surface. The

distribution of the assets and their diversification in terms of applications, operating systems





and communication protocols is large. Thus, in the frame of this document, an indicative (i.e.

high level) set of applicable threats will be discussed.

Initially, home-deployed devices and cloud servers constitute distinct targets. The

communication channel that interconnects these targets is a target per se since it can be

subjected to interception, protocol manipulation, traffic injection & obstruction. Interception

can lead to loss of privacy in case sensitive data are extracted or to privilege escalation in case

of the interception of administrative accounts.

On the other hand, protocol manipulation and injection can cause the alternation of messages

and thus alter the commands of the IoT devices or the server-side business logic. The impact

will be to deliver low-quality services causing possible damage to the users/patients, thus

considered as a breach of contract with financial consequences. Such events will also cause a

significant damage to the reputation of the product, which is the intangible asset of the iSprint-

LuxAI partnership. Same applies in case of privilege escalation, the software stack of the robots

can be considered compromised. Finally, any misuse of the programming interfaces or even

unintentional misconfiguration of the behavior of the components can lead to issues in the

rehabilitation/coaching operations.

The following table summarizes in detail the attacks that are considered relevant for the

scenario above based on the CAPEC classification.










Inject Unexpected Items - 152 Local Execution of Code - 549



















194





Obstruction - 607 Jamming - 601







6 Smart Cities Scenarios 6.1 Description

One of the first scenarios where IoT technologies started to be deployed and demonstrated was the Smart City. In fact, several European projects acted as lighthouse initiatives and real testing environments. One of the most representative examples is SmartSantander5, which promoted the deployment of 20.000 sensors in Belgrade, Guildford, Lübeck and Santander.

The main objective of an IoT-based Smart City platform is the creation of high-value-added services relying on advanced ICT mechanisms to improve the efficiency in the management of the municipal resources or to benefit the citizens living conditions. To reach this ambitious goal, they must not limit their functionalities on just collecting and reporting data but semi-autonomous actuation is also a fundamental aspect.

Within the Smart City environment, there are a huge plethora of different possible IoT based services, i.e. structural monitoring, waste management, water management, environmental

monitoring, traffic management, energy metering, lighting management, parking management and public transport

Each one of them could be analyzed independently and constitute different sub-scenarios. In any case, a Smart City IoT deployment is a good example of a complex system involving devices and smart objects provided by different manufacturers, interconnected through a great diversity of communication protocols and resulting in the co-creation of advanced services and

applications, some of them implying semi-autonomous control.

For instance, as part of the environmental monitoring service, sensors will gather data regarding the air-quality, pollution, allergens or even noise levels. In the simplest approach, this information will be used to inform the citizens and suggest changes in the daily activity or to apply anti-pollution policies. But the integration of AI at the edge thanks to the increasing computing power of smart objects may also lead to a more advanced scenario where smart traffic lights could be adjusted dynamically in order to redistribute most of the vehicles through less contaminated routes.

5 http://www.smartsantander.eu





The number and characteristics of the connected objects strongly depend on the specific conditions of the city, the already existing ICT infrastructure and the type of services to deliver. Typical objects could cover intelligent waste level detectors, pressure sensors in water distribution systems, air quality and noise sensors, cameras, traffic detectors, energy meters, smart bulbs, presence detectors, parking sensors and GPS installed in public transport vehicles.

Although all these elements may implement some kind of semi-autonomous behavior, the most typical configuration implies the interconnection of all of them to a central IoT Cloud platform, where different layers provide functionalities for data consolidation, persistence, analytics, and visualization. FIWARE could be considered as one of the reference architectures to implement solutions within a Smart City and it proposes the following stack:

Figure 14 - FIWARE for Smart Cities

The communication protocols to connect together all these smart objects also vary and may go cover:

WPAN/WLAN solutions: Bluetooth6, 6LoWPAN7, ZigBee8 or WiFi9.

WWAN: SigFox10, LoRaWAN11

Cellular: GPRS12, 3G/4G/5G

As it was mentioned before, the goal of a Smart City is the creation of new services oriented to the improvement in the management of the municipal resources. Therefore, different

6 https://internetofbusiness.com/smart-city-aarhus-bluetooth-traffic/ 7 https://ubidots.com/blog/zolertia-tutorial-weather-station-over-6lowpanipv6-using-ubidots/ 8 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4299117/ 9 http://www.libelium.com/products/meshlium/smartphone-detection/ 10 https://www.sigfox.com/en/solutions/use-cases-smart-cities 11 http://ieeexplore.ieee.org/document/8115748/ 12 http://ieeexplore.ieee.org/document/5716183/?section=abstract





stakeholders may have access to the collected and processed information: the city governance bodies, the IoT platform administrator, the service providers and finally the citizens. In order to ensure the scalability of the solution and also to make possible near-real-time actuation, data will be processed both at the Edge and at the Cloud.

6.2 Abuse Cases The Smart City scenario is arguably one of the largest IoT use-cases; consequently, a similar scale has to be assumed for its underlying attack surface. Applying a security-by-design modus operandi to such a humongous deployment is an extremely difficult task due to a number of reasons:

unparalleled diversity in vendors, hardware and software components and communication protocols

numerous wired and wireless communication technologies with different levels of security

numerous data-bridges and system workflows complex policies guiding data visibility and interdependencies among all stakeholders the huge number of deployed sensors and IoT devices and their physical security the business criticality of the offered services with immediate impact on human safety

and human well-being the complexity of the analysis required to power up the different consumer services the infinite number of exploitation scenarios that result from the huge graph of

interconnected devices and services. It is clear, that any attempt to enumerate the exhaustive list of all the abuse cases results in a practically infinite number of scenarios. The same applies to the most critical attacks in terms of risk and impact. Indicative, high profile attack scenarios are:

data manipulation and data falsification; poisoning complex analytics systems with

incorrect data can lead to the improper training of highly innovative AI-based decision-making solutions and significantly impact the quality of services being provided (e.g., improper traffic signaling)

data theft; data is the cornerstone of the current era. Gaining unauthorized access to such diverse information can be used by adversaries in numerous ways in their attempt to monetize their malicious acts

services’ availability and integrity; being able to remote control or disrupt critical services is an imminent threat to public safety and well-being (e.g., terrorism)















*


Local Execution of Code -

549















194





7 Smart Home Scenarios 6.1 Description

A smart home constitutes a typical IoT deployment. In a smart home scenario, we consider a smart home, where surveillance cameras, motion detectors, fire detectors and a smart door lock operate under the same coordinator (e.g. a device that acts as a device manager). All the IoT devices are behind a pre-configured firewall of the same network. These IoT connected

devices can used both to detect anomalies in the home environments (e.g. burglar intrusion, fire detection etc.) and to lock/unlock the smart door lock.

A typical usage scenario is whenever the fire sensor detects increase temperature and motion sensor and surveillance camera detect movement activities (e.g. somebody is inside the house), an unlock command is sent to the smart door lock. First, the camera, the motion and the fire sensor sends the obtained information along with the appropriate command to its coordinator. The coordinator forwards the command to the smart door lock, prepares a report aggregating the information about this event, and sends to the IoT service provider.

Figure 15 – Indicative type of sensors/actuators used in a Smart Home

Surveillance IP cameras, motion sensors, fire detectors, smart door locks and the firewall are

connected on the same network. Real time video, motion and temperature information

processed to alert the end user and/or to lock/unlock the smart door lock. In addition, the end

user can access the video streaming anytime, anywhere and check his home remotely from the

cloud.

6.2 Abuse Cases One of the most notable characteristics of many cyber-attacks is their asymmetric nature. This

asymmetry explains how a relatively small vulnerability can have a disproportionately

significant impact (e.g., a vulnerability in an open-source JSON deserialization library used by an

e-commerce solution can lead to remote code execution and consequently disclose personal

and financial data of all end-customers).





This “asymmetry” analogy concisely describes the attack surface of the Smart Home

deployment under study. Namely, the comparatively bounded attack surface of the Smart

Home can have a huge impact both on data privacy and human safety.

Firstly, adversaries can decide to attack the cloud service that provides access to IoT sensor

data and, more importantly, surveillance camera feeds. It is typical of such cloud system

offerings to be globally accessible (e.g., with no location-based access control (IP whitelisting))

in order to ease real-time monitoring of Smart Homes by their respective owners. Therefore,

the attack surface of such a cloud solution is similar to that of any web-based application or API.

Brute-force password cracking, web application vulnerabilities (e.g., vulnerabilities related to

code injection, parameter injection, etc.) allowing session hijacking or credential theft, and

sniffing of unencrypted network traffic are only a few among the applicable attacks. Successful

exploitation results to complete loss of data subjects’ privacy since adversaries can identify

when a Smart Home is inhabited and analyze and extract patterns related to the owners’

everyday life to further use for their malicious intents.

The other main point of interest is the IoT ecosystem hosted in each Smart Home individually. It

is safe to assume that most of the IoT sensors communicate data through wireless connections,

which makes the “report-and-control” subsystem of a Smart Home deployment vulnerable to

sniffing, data falsification, data manipulation and malicious remote control. In that aspect,

adversaries can manipulate the sensor data received on the device manager end and force

certain behavior (e.g., trick the movement detector and fire sensors so that the device manager

assumes fire in an inhabited home and issues a command to open the smart lock). The latter

constitutes a huge liability which can lead to financial or property loss (burglary) or even

casualties (e.g., smart lock does not open when house is on fire).

Lastly, the communication link between the device manager and the cloud represents an

additional layer in the effective attack surface. Disruption of the link’s availability can allow

adversaries to isolate the Smart Home from the cloud, giving them the ability to act their

malicious intent undetected. It is worth mentioning though that the risk of this last type of

threat is considerably lower than the one in the previous paragraphs, as compromising the IoT

ecosystem or owners’ data privacy are significantly more impactful and consequently more

appealing to adversaries.















*


Local Execution of Code -

549















194





8 Identified Threat landscape and the role of

SecureIoT Judging from the attack surface that has been identified above there are two major findings that we can emphasize on. The first is that some threats, related to the scenarios above, can be prevented (not mitigated a-posteriori) using design-time techniques. Indicative threats include “Exploiting Trust in Client” (CAPEC-22), “Manipulating Writeable Configuration Files” (CAPEC-75), “Abuse Existing Functionality” (CAPEC-210), “Functionality Misuse” (CAPEC-212), “Subvert Access Control” (CAPEC-225) etc. Most of these attacks make use of an inappropriate authorization layer and allow adversaries tamper with the existing functionality and resources.

The second finding relates to the fact that handling a risk related to an IoT deployment infers the capability of estimating with a good precision the likelihood of an attack since at it is implied by Equation-1 [ R= f (TL,VL,IL) ] the Threat Likelihood is the only parameter that can be adjusted. The Vulnerability Level and the Impact Level (upon exploitation) are considered given while TL varies. In fact, strictly speaking, there is no such term as “severe Threat” since a Threat can be only considered highly-probable (i.e. high criticality) or unlikely to happen (i.e. low

criticality). Yet, a highly probable threat may contribute to a low risk and vice versa a less probable threat may contribute to a severe risk. Therefore, the minimization of risk is directly connected to the ability of early warning upon an attack or even the prediction of the attack prior to its conduction ( Figure 16 ). Not to mention that, as already emphasised, the quantification of risk is the way to achieve regulatory compliance and tackle privacy issues.

Figure 16 - Impact of early warning/prediction in the mitigation loop





SecureIoT will provide a framework where situation awareness and secure design-time policies will be first class citizens. Through the platform it would be able to achieve anomaly detection and early warning as well as near real time risk assessment. The aim of anomaly detection is to provide to stakeholders (e.g. administrators, CERT team members) indications of suspicious activity based on sophisticated algorithms. These algorithms rely on statistical analysis (e.g. linear/non-linear regression, classification, clustering) and machine learning models

(supervised and unsupervised) in order to generate indications that would not be generated by the traditional systems that rely on pattern matching of pre-existing suspicious signatures. Data that will be used as an input for the various analytics processes (statistical-based and/or machine-learning-based) will derive by the field level, the fog-level, the enterprise-level and the systemic level as depicted on Figure 17.

Figure 17 - Overview of SecureIoT High Level Architecture

Finally, it should be clarified that SecureIoT will make use of sophisticated techniques that are proposed; yet it will take under consideration, during its concrete architectural design, the IoT specificities (i.e. resource constraints, mobility patterns etc). Although the scope of this deliverable is not to emphasize on these IoT specific techniques, it is worth mentioning some indicative ones. For example, in [12], intrusion detection techniques are classified, based on the applied analysis mechanisms for patterns identification. Statistical analysis is applied for comparing current trends in data to a predetermined set of baseline criteria, leading to anomaly detection. Evolutionary algorithms are used for providing normal behaviour models, exploited for detection of error conditions and attempted intrusions. Artificial neural networks are used to form complex hypotheses and evaluate them based on real-time data, leading to the identification of advanced security events. Neural network system undergoes training in order to learn the pattern created in the system. In [13], it is presented a novel data-driven





framework to semantically model IoT configurations and then employ that model to automatically arrest security configuration anomalies and analyze IoT-specific threat vectors. Configuration analytics are performed automatically by describing the context of complex IoT interactions and dependencies through rules-supported reasoning and queries. Finally, in [14], evolving mechanisms are presented for applying analytics and machine learning for network security analysis as well as analysis of the security of the overall IoT devices, apps, the OS and

the data on the device. Based on analytic techniques, the sensitivity of the device, the vulnerability rank of apps and of the device, the degree of compromise of apps and of the device are provided. Such metrics can be used further in machine learning models in order to predict the users of the device of high risk states, and how to avoid such risks. The aforementioned approaches are indicative and their presentation targets at emphasizing the evolving trend in the design, implementation and evaluation of novel threat intelligence

techniques in IoT ecosystems. The elaboration of the reference scenarios and the exploration of the threat landscape based on the exposed attack surfaces will affect the Analysis of the Stakeholders’ requirements (D2.2) and the Architectural and Technical Specifications (D2.4).





9 Conclusions The goal of the deliverable was to identify abuse cases for several distinct IoT-centric domains;

namely Factory 4.0, Autonomous Vehicles and Social Robots in the context of Ambient Assisted

Living. Identified abuse cases correspond to the definition of (cyber) attack patterns. In the

frame of SecureIoT, the concept of cyber attack and threat is identical. This clarification is

essential since, in order to identify relevant attack patterns, a cyber-risk-oriented methodology

has been adopted.

More specifically, per scenario the used assets, the type of communication among them and

their usage patterns are explored. During this exploration, vulnerabilities and corresponding

threats are identified. Each asset may be associated to one or more vulnerabilities. Each

vulnerability can be (potentially) exploited by one or more attacks that can make use this

vulnerability. The reporting of identified threats follows a standardized way. Regarding,

vulnerabilities and threats there are already existing standards that are considered de-facto.

Therefore, CAPEC has been used based on its wide adoption. To this end, several threats

related to spoofing, tampering, repudiation, information disclosure, denial of service, elevation

of privilege, etc have been identified and reported per scenario. The exploration of all scenarios

led to an exhaustive listing of attack patterns. The exhaustive list is summarized on Annex I

where detailed information derived by CAPEC is provided.

The detailed listing of identified threats comprises a valuable input for both the requirements’

analysis task and the architectural clarification task. The reason for that is that prioritized

attacks will be mitigated by SecureIoT mechanisms. Such mechanisms will provide security

guarantees for one part of the attack surface.





References

[1] O. Siciliano, B.; Khatib, Springer Handbook of Robotics, Springer, 2008

[2] L. Atzori, A. Iera, G. Morabito, The internet of things: A survey, Comput.Netw. 54 (15)

(2010) 2787–2805.

[3] L.A. Grieco , A. Rizzo , S. Colucci , S. Sicari , G. Piro , D. Di Paola , G. Boggia, IoT-aided

robotics applications, Computer Communications, v.54 n.C, p.32-47, December 2014

[4] The eWALL project Deliverable D2.7: Final user and system requirements and

architecture. March 2015.

[5] TS 102 921, “Machine-to-Machine communications (M2M); mIa, dIa and mId

interfaces,” ETSI, 2012.

[6] Spring Framework http://spring.io/

[7] http://www.rabbitmq.com

[8] http://projects.spring.io/spring-amqp/

[9] http://microservices.io/patterns/microservices.html

[10] http://projects.spring.io/spring-boot/

[11] Pouyan Ziafati. 2014. Plexil-Like Plan Execution Control in Agent Programming.

http://www.aaai.org/ocs/index.php/WS/AAAIW14/paper/view/8810

[12] E. Hodo et al., "Threat analysis of IoT networks using artificial neural network intrusion

detection system," 2016 International Symposium on Networks, Computers and

Communications (ISNCC), Yasmine Hammamet, 2016, pp. 1-6. doi:

10.1109/ISNCC.2016.7746067

[13] Mujahid Mohsin, Zahid Anwar, Farhat Zaman, Ehab Al-Shaer, IoTChecker: A data-driven

framework for security analytics of Internet of Things configurations, Computers &

Security, Volume 70, 2017, Pages 199-223, ISSN 0167-4048,

https://doi.org/10.1016/j.cose.2017.05.012.

[14] Security Analytics of Network Flow Data of IoT and Mobile Devices, Available Online:

https://arxiv.org/abs/1704.03049





Annex I – Elaboration on Relevant Abuse Cases

based on CAPEC classification The following table provides a description of the attacks that are relevant to the explored

scenarios.

Attack Identifier

Attack

Friendly Name

Description

22 Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client. There are numerous

variations of this type of attack.

49 Password Brute Forcing

In this attack, the adversary tries every possible value for a password until they succeed. A brute force attack, if feasible computationally, will always be successful because it will essentially go through all possible passwords given the alphabet used (lower case letters, upper case letters, numbers, symbols, etc.) and the maximum length of the password.

A system will be particularly vulnerable to this type of an attack if it does not have a proper enforcement mechanism in place to ensure that passwords selected by users are strong passwords that comply with an adequate password policy.

In practice a pure brute force attack on passwords is rarely used, unless the password is suspected to be weak. Other password cracking methods exist that are far more effective (e.g. dictionary attacks, rainbow tables, etc.).

75 Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

94 Man in the Middle Attack

This type of attack targets the communication between two components (typically client and server). The attacker places himself in the communication channel between the two components. Whenever one component attempts to communicate with the other (data flow, authentication challenges, etc.), the data first goes to the attacker, who has

the opportunity to observe or alter it, and it is then passed on to the other component as if it was never intercepted. This interposition is transparent leaving the two compromised components unaware of the potential corruption or leakage of their communications. The potential for Man-in-the-





Middle attacks yields an implicit lack of trust in communication or identify between two components.

112 Brute Force In this attack, some asset (information, functionality, identity, etc.) is protected by a finite secret value. The attacker attempts to gain access to this asset by using trial-and-error to exhaustively explore all the possible secret values in the hope of finding the secret (or a value that is functionally equivalent) that will unlock the asset. Examples of secrets can include, but are not limited to, passwords, encryption keys, database lookup keys, and initial values to one-way functions.

The key factor in this attack is the attackers' ability to explore the possible secret space rapidly. This, in turn, is a function of the size of the secret space and the computational power the attacker is able to bring to bear on the problem. If the attacker has modest resources and the secret space is large, the challenge facing the attacker is intractable. While the defender cannot control the resources available to an attacker, they can control the size of the secret space. Creating a large secret space involves selecting one's secret from as large a field of equally likely alternative secrets as possible and ensuring that an attacker is unable to reduce the size of this field using available clues or cryptanalysis. Doing this is more difficult than it sounds

since elimination of patterns (which, in turn, would provide an attacker clues that would help them reduce the space of potential secrets) is difficult to do using deterministic machines, such as computers. Assuming a finite secret space, a brute force attack will eventually succeed. The defender must rely on making sure that the time and resources necessary to do so will exceed the value of the information. For example, a secret space that will likely take hundreds of years to explore is likely safe from raw-brute force attacks.

117 Interception An adversary monitors data streams to or from a target in order to gather information. This attack may be undertaken to gather information to support

a later attack or the data collected may be the end goal of the attack. This attack usually involves sniffing network traffic, but may include observing other types of data streams, such as radio. In most varieties of this attack,

the attacker is passive and simply observes regular communication, however in some variants the attacker may attempt to initiate the establishment of a data stream or influence the nature of the data transmitted. However, in all variants of this attack, and distinguishing this attack from other data collection methods, the attacker is not the intended recipient of the data stream. Unlike some other data leakage attacks, the attacker is observing explicit data channels (e.g. network traffic) and reading the content. This differs from attacks that collect more qualitative information, such as communication volume, or other information not explicitly communicated via a data stream.

118 Collect and Analyze Information

Attack patterns within this category focus on the gathering, collection, and theft of information by an adversary. The adversary may collect this information through a variety of methods including active querying as well as passive observation. By exploiting weaknesses in the design or configuration of the target and its communications, an adversary is able to get the target





to reveal more information than intended. Information retrieved may aid the adversary in making inferences about potential weaknesses, vulnerabilities, or techniques that assist the adversary's objectives. This information may include details regarding the configuration or capabilities of the target, clues as to the timing or nature of activities, or otherwise sensitive information. Often this sort of attack is undertaken in preparation for some other type of attack, although the collection of information by itself may in some cases be the end goal of the adversary.

125 Flooding An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack

prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests

made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target.

137 Parameter Injection

An adversary exploits weaknesses in input validation by manipulating the content of request parameters for the purpose of undermining the security of the target. Some parameter encodings use text characters as separators. For example, parameters in a HTTP GET message are encoded as name-value pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in these parameters, then they can inject special characters used in the encoding scheme to add or modify parameters. For example, if user input is fed directly into an HTTP GET request and the user provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a new parameter (new_param) is also added with a value of myValue. This can significantly change the meaning of the query that is processed by the server. Any encoding scheme where parameters are identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET encoding used above is just one example.

151 Identity Spoofing Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come

from a different principle or use stolen / spoofed authentication credentials. Alternatively, an adversary may intercept a message from a legitimate sender and attempt to make it look like the message comes from them without changing its content. The latter form of this attack can be used to hijack credentials from legitimate users. Identity Spoofing attacks need not be limited to transmitted messages - any resource that is associated with an identity (for example, a file with a signature) can be the target of an attack where the adversary attempts to change the apparent identity. This attack differs from Content Spoofing attacks where the adversary does not wish to change the apparent identity of the message but instead wishes to change what the message says. In an Identity Spoofing attack, the adversary is





attempting to change the identity of the content.

152 Inject

Unexpected Items

Attack patterns within this category focus on the ability to control or disrupt

the behavior of an target either through crafted data submitted via an interface for data input, or the installation and execution of malicious code on the target system. The former happens when an adversary adds material to their input that is interpreted by the application causing the targeted application to perform steps unintended by the application manager or causing the application to enter an unstable state. Attacks of this type differ from Data Structure Attacks in that the latter attacks subvert the underlying structures that hold user-provided data, either pre-empting interpretation of the input (in the case of Buffer Overflows) or resulting in values that the

targeted application is unable to handle correctly (in the case of Integer Overflows). In Injection attacks, the input is interpreted by the application, but the attacker has included instructions to the interpreting functions that

the target application then follows.

156 Engage in Deceptive Interactions

Attack patterns within this category focus on malicious interactions with a target in an attempt to deceive the target and convince the target that it is interacting with some other principal and as such take actions based on the

level of trust that exists between the target and the other principal. These types of attacks assume that some piece of content or functionality is associated with an identity and that the content / functionality is trusted by the target because of this association. Often identified by the term "spoofing", these types of attacks rely on the falsification of the content and/or identity in such a way that the target will incorrectly trust the legitimacy of the content. For example, an attacker may modify a financial transaction between two parties so that the participants remain unchanged but the amount of the transaction is increased. If the recipient cannot detect

the change, they may incorrectly assume the modified message originated with the original sender. Attacks of these type may involve an adversary crafting the content from scratch or capturing and modifying legitimate

content.

158 Sniffing Network Traffic

An adversary monitors network traffic between nodes of a public or multicast network in an attempt to capture sensitive information. The adversary doesn't prevent reception or change content but simply observes and reads the traffic. The attacker might precipitate or indirectly influence the content of the observed transaction, but the attacker is never the intended recipient of the information.

167 White Box Reverse Engineering

An attacker discovers the structure, function, and composition of a type of computer software through white box analysis techniques. White box techniques involve methods which can be applied to a piece of software when an executable or some other compiled object can be directly subjected to analysis, revealing at least a portion of its machine instructions that can be observed upon execution.





175 Code Inclusion An adversary exploits a weakness on the target to force arbitrary code to be retrieved locally or from a remote location and executed. This differs from code injection in that code injection involves the direct inclusion of code while code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

176 Configuration/Environment Manipulation

An attacker manipulates files or settings external to a target application which affect the behavior of that application. For example, many applications use external configuration files and libraries - modification of these entities or otherwise affecting the application's ability to use them would constitute a configuration/environment manipulation attack.

188 Reverse Engineering

An adversary discovers the structure, function, and composition of an object, resource, or system by using a variety of analysis techniques to effectively determine how the analyzed entity was constructed or operates. The goal of

reverse engineering is often to duplicate the function, or a part of the function, of an object in order to duplicate or "back engineer" some aspect of its functioning. Reverse engineering techniques can be applied to mechanical objects, electronic devices, or software, although the methodology and techniques involved in each type of analysis differ widely.

189 Black Box Reverse

Engineering

An attacker discovers the structure, function, and composition of a type of computer software through black box analysis techniques. 'Black Box'

methods involve interacting with the software indirectly, in the absence of direct access to the executable object. Such analysis typically involves interacting with the software at the boundaries of where the software interfaces with a larger execution environment, such as input-output vectors, libraries, or APIs.

194 Fake the Source of Data

An adversary provides data under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or it might be an attempt by the adversary to assume the rights granted to another identity. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. Results of the attack vary depending on the details of the attack, but

common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

210 Abuse Existing Functionality

An adversary uses or manipulates one or more functions of an application in order to achieve a malicious objective not originally intended by the application, or to deplete a resource to the point that the target's functionality is affected. This is a broad class of attacks wherein the adversary is able to alter the intended result or purpose of the functionality

and thereby affect application behavior or information integrity. Outcomes can range from information exposure, vandalism, degrading or denial of service, as well as execution of arbitrary code on the target machine.





212 Functionality Misuse

An adversary leverages a legitimate capability of an application in such a way as to achieve a negative technical impact. The system functionality is not altered or modified but used in a way that was not intended. This is often accomplished through the overuse of a specific functionality or by leveraging functionality with design flaws that enables the adversary to gain access to unauthorized, sensitive data.

223 Employ Probabilistic Techniques

An attacker utilizes probabilistic techniques to explore and overcome security properties of the target that are based on an assumption of strength due to the extremely low mathematical probability that an attacker would be able to identify and exploit the very rare specific conditions under which those security properties do not hold.

224 Fingerprinting An adversary compares output from a target system to known indicators that uniquely identify specific details about the target. Fingerprinting by itself is not usually detrimental to the target. However, the information

gathered through fingerprinting often enables an adversary to discover existing weaknesses in the target.

225 Subvert Access Control

An attacker actively targets exploitation of weaknesses, limitations and assumptions in the mechanisms a target utilizes to manage identity and authentication as well as manage access to its resources or authorize functionality. Such exploitation can lead to the complete subversion of any trust the target system may have in the identity of any entity with which it

interacts, or the complete subversion of any control the target has over its data or functionality. Weaknesses targeted by subversion of authentication mechanisms are often due to assumptions and overconfidence in the strength or rigor of the implemented authentication mechanisms. Weaknesses targeted by subversion of authorization controls are often due to three primary factors: 1) a fundamental dependence on authentication mechanisms being effective; 2) a lack of effective control over the separation of privilege between various entities; and 3) assumptions and over confidence in the strength or rigor of the implemented authorization mechanisms.

227 Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource

tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied

up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource. The degree to which the attack is successful depends upon the adversary's ability to sustain resource requests over time with a volume that exceeds the normal usage by legitimate users, as well as other mitigating circumstances such as the target's ability to shift load or acquire additional resources to

deal with the depletion. This attack differs from a flooding attack as it is not entirely dependent upon large volumes of requests, and it differs from





resource leak exposures which tend to exploit the surrounding environment needed for the resource to function. The key factor in a sustainment attack are the repeated requests that take longer to process than usual.

240 Resource Injection

An adversary exploits weaknesses in input validation by manipulating resource identifiers enabling the unintended modification or specification of a resource.

242 Code Injection An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code

inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

248 Command Injection

An adversary looking to execute a command of their choosing, injects new items into an existing command thus modifying interpretation away from what was intended. Commands in this context are often standalone strings that are interpreted by a downstream component and cause specific

responses. This type of attack is possible when untrusted values are used to build these command strings. Weaknesses in input validation or command construction can enable the attack and lead to successful exploitation.

262 Manipulate System Resources

Attack patterns within this category focus on the adversary's ability to manipulate one or more resources in order to achieve a desired outcome. This is a broad class of attacks wherein the attacker is able to change some aspect of a resource's state or availability and thereby affect system behavior or information integrity. Examples of resources include files, applications, libraries, infrastructure, and configuration information. Outcomes can range from vandalism and reduction in service to the execution of arbitrary code on the target machine.

390 Bypassing Physical Security

Facilities often used layered models for physical security such as traditional locks, Electronic-based card entry systems, coupled with physical alarms. Hardware security mechanisms range from the use of computer case and cable locks as well as RFID tags for tracking computer assets. This layered approach makes it difficult for random physical security breaches to go unnoticed, but is less effective at stopping deliberate and carefully planned break-ins. Avoiding detection begins with evading building security and surveillance and methods for bypassing the electronic or physical locks which secure entry points.

416 Manipulate Human Behavior

An adversary exploits inherent human psychological predisposition to influence a targeted individual or group to solicit information or manipulate

the target into performing an action that serves the adversary's interests. Many interpersonal social engineering techniques do not involve outright deception, although they can; many are subtle ways of manipulating a target to remove barriers, make the target feel comfortable, and produce an





exchange in which the target is either more likely to share information directly, or let key information slip out unintentionally. A skilled adversary uses these techniques when appropriate to produce the desired outcome. Manipulation techniques vary from the overt, such as pretending to be a supervisor to a help desk, to the subtle, such as making the target feel comfortable with the adversary's speech and thought patterns.

417

Influence Perception

The adversary uses social engineering to exploit the target's perception of the relationship between the adversary and themselves. This goal is to

persuade the target to unknowingly perform an action or divulge information that is advantageous to the adversary.

426 Influence via Incentives

The adversary incites a behavior from the target by manipulating something of influence. This is commonly associated with financial, social, or ideological incentivization. Examples include monetary fraud, peer pressure, and preying on the target's morals or ethics. The most effective incentive against one target might not be as effective against another, therefore the adversary

must gather information about the target's vulnerability to particular incentives.

438 Modification

During Manufacture

An attacker modifies a technology, product, or component during a stage in

its manufacture for the purpose of carrying out an attack against some entity involved in the supply chain lifecycle. There are an almost limitless number of ways an attacker can modify a technology when they are involved in its manufacture, as the attacker has potential inroads to the software composition, hardware design and assembly, firmware, or basic design mechanics. Additionally, manufacturing of key components is often outsourced with the final product assembled by the primary manufacturer. The greatest risk, however, is deliberate manipulation of design specifications to produce malicious hardware or devices. There are billions of

transistors in a single integrated circuit and studies have shown that fewer than 10 transistors are required to create malicious functionality.

441 Malicious Logic Insertion

An attacker installs or adds malicious logic into a seemingly benign component of the system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts.

442 Malicious Logic Inserted into To Product Software

An attacker inserts malicious logic into software, typically in the form of a traditional virus or trojan backdoor.

444 Development Alteration

An attacker modifies a technology, product, or component during its development. The product is then delivered to the user where a negative

impact is achieved.





447 Design Alteration An attacker modifies the design of a technology, product, or component. The product is then delivered to the user where a negative impact is achieved.

452 Malicious Logic Insertion into Product Hardware

An attacker modifies the design of a technology, product, or component and affects the produced hardware component. The product is then delivered to the user where a negative impact is achieved.

456 Malicious Logic Insertion into Product Memory

An attacker inserts malicious logic into memory enabling them to achieve a negative impact.

469 HTTP DoS An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP

connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP.

The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web

server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.

482 TCP Flood An adversary may execute a flooding attack using the TCP protocol with the

intent to deny legitimate users access to a service. These attacks exploit the weakness within the TCP protocol where there is some state information for the connection the server needs to maintain.

488 HTTP Flood An adversary may execute a flooding attack using the HTTP protocol with the intent to deny legitimate users access to a service by consuming resources at the application layer such as web services and their infrastructure. These attacks use legitimate session-based HTTP GET requests designed to consume large amounts of a server's resources. Since these are legitimate sessions this attack is very difficult to detect.

489 SSL Flood An adversary may execute a flooding attack using the SSL protocol with the intent to deny legitimate users access to a service by consuming all the available resources on the server side. These attacks take advantage of the asymmetric relationship between the processing power used by the client and the processing power used by the server to create a secure connection. In this manner the attacker can make a large number of HTTPS requests on a low provisioned machine to tie up a disproportionately large number of resources on the server. The clients then continue to keep renegotiating the SSL connection. When multiplied by a large number of attacking machines, this attack can result in a crash or loss of service to legitimate users.

519 Documentation Alteration to

An attacker with access to a manufacturer's documentation containing requirements allocation and software design processes maliciously alters the





Cause Errors in System Design

documentation in order to cause errors in system design. This allows the attacker to take advantage of a weakness in a deployed system of the manufacturer for malicious purposes.

541 Application Fingerprinting

An adversary engages in fingerprinting activities to determine the type or version of an application installed on a remote target.

542 Targeted Malware

An adversary develops targeted malware that takes advantage of a known vulnerability in an organizational information technology environment. The malware crafted for these attacks is based specifically on information gathered about the technology environment. Successfully executing the malware enables an adversary to achieve a wide variety of negative technical impacts.

547 Physical Destruction of Device or

Component

An adversary conducts a physical attack a device or component, destroying it such that it no longer functions as intended.

549 Local Execution of Code

An adversary installs and executes malicious code on the target system in an effort to achieve a negative technical impact. Examples include rootkits, ransomware, spyware, adware, and others.

578 Disable Security Software

Adversaries may disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.

582 Route Disabling An adversary disables the network route between two targets. The goal is to completely sever the communications channel between two entities. This is often the result of a major error or the use of an "Internet kill switch" by those in control of critical infrastructure. This attack pattern differs from most other obstruction patterns by targeting the route itself, as opposed to the data passed over the route.

586 Object Injection An adversary attempts to exploit an application by injecting additional,

malicious content during its processing of serialized objects. Developers leverage serialization in order to convert data or state into a static, binary format for saving to disk or transferring over a network. These objects are

then deserialized when needed to recover the data/state. By injecting a malformed object into a vulnerable application, an adversary can potentially compromise the application by manipulating the deserialization process. This can result in a number of unwanted outcomes, including remote code execution.

594 Traffic Injection An adversary injects traffic into the target's network connection. The adversary is therefore able to degrade or disrupt the connection, and potentially modify the content. This is not a flooding attack, as the adversary





is not focusing on exhausting resources. Instead, the adversary is crafting a specific input to affect the system in a particular way.

601 Jamming An adversary uses radio noise or signals in an attempt to disrupt communications. By intentionally overwhelming system resources with illegitimate traffic, service is denied to the legitimate traffic of authorized users.

603 Blockage An adversary blocks the delivery of an important system resource causing the system to fail or stop working.

607 Obstruction An attacker obstructs the interactions between system components. By interrupting or disabling these interactions, an adversary can often force the system into a degraded state or even a failure more.

624 Fault Injection The adversary uses disruptive signals or events (e.g. electromagnetic pulses, laser pulses, clock glitches, etc.) to cause faulty behavior in electronic devices. When performed in a controlled manner on devices performing cryptographic operations, this faulty behavior can be exploited to derive secret key information.

deliverable d2.1 - reference scenarios and use cases - reference... · project full title:...

Documents