# A Continuous Risk Assessment Methodology
for Cloud Infrastructures

Immanuel Kunz, Angelika Schneider and Christian Banse  Fraunhofer AISEC
Garching b. München, Germany
<EMAIL_ADDRESS>
###### Abstract

Cloud systems are dynamic environments which make it difficult to keep track
of security risks that resources are exposed to. Traditionally, risk
assessment is conducted for individual assets to evaluate existing threats;
their results, however, are quickly outdated in such a dynamic environment. In
this paper, we propose an adaptation of the traditional risk assessment
methodology for cloud infrastructures which loosely couples manual, in-depth
analyses with continuous, automatic application of their results. These two
parts are linked by a novel threat profile definition that allows to reusably
describe configuration weaknesses based on properties that are common across
assets and cloud providers. This way, threats can be identified automatically
for all resources that exhibit the same properties, including new and modified
ones. We also present a prototype implementation which automatically evaluates
an infrastructure as code template of a cloud system against a set of threat
profiles, and we evaluate its performance. Our methodology not only enables
organizations to reuse their threat analysis results, but also to collaborate
on their development, e.g. with the public community. To that end, we propose
an initial open-source repository of threat profiles.

###### Index Terms:

Semi-Automated Risk Assessment, Semi-Automated Threat Modeling, Cloud
Discovery, Cloud Security, Risk Assessment Tool

##  I Introduction

Risk assessment is an essential part of security management, and is commonly
used to identify and prioritize risks, and to derive mitigative measures. This
process usually identifies individual assets and protection goals, then
conducts threat and impact analyses, and finally deduce risk scores. Yet, this
sequential risk assessment method assumes a static system for which a once
conducted risk assessment can be assumed to be valid for a long period of
time. This approach is not suitable for cloud systems that are frequently
modified and scaled, e.g. by changing access rights and port configurations,
temporarily adding resources like jump servers, and by scaling containers and
serverless functions.

In the past decade, various approaches have been proposed to adapt traditional
risk assessment to the cloud. Some automatically assess risks based on known
vulnerabilities, e.g. from the National Vulnerability Database [1, 2]. Others
focus on different types of risks, e.g. risk assessment of compositional cloud
systems or various risks beyond security [3].

There are two gaps that remain in the application of risk assessment to the
cloud. First, expert analyses are still necessary to identify system-specific
threats that go beyond known vulnerabilities—yet, their results are quickly
outdated. What is required for the cloud is therefore a risk assessment
process that adequately integrates both manual, in-depth analyses, and
continuous, automated assessments.

Second, such a process needs to be enabled by a set of technical innovations
that allow to automatically discover an up-to-date snapshot of a cloud system
and automatically evaluate this snapshot regarding potential threats. Most
importantly, however, potential threats need to be described in a highly
reusable way that is independent from single resources, and ideally also
independent from cloud providers.

In this paper, we redesign the risk assessment process for the cloud by
loosely coupling manual expert analyses with the automatic application of the
results to cloud resources. For the discovery of existing cloud resources, we
use infrastructure as code (IaC) templates, and evaluate them using a policy
engine. We furthermore propose threat profiles that can describe sophisticated
attack vectors, and which are generically applicable across assets and cloud
providers. When, e.g., a threat is identified in a specific combination of
resource configurations, like their location and network configuration, it can
then automatically be identified across all such resources—quickly after they
have been created or modified. This approach increases the reusability of
expert analyses, and allows to share threat descriptions with others across
organizations or with the public community.

The contributions of the paper are the following:

  * •

A risk assessment process adapted to continuous cloud assessment, consisting
of two modules: An analysis module conducted by experts, and an automated
module that continuously applies identified threats to applicable resources,

  * •

A novel way to create threat profiles—either based on IaC descriptions or on
an ontological description of cloud resources—that make threat descriptions
automatically applicable across resources and cloud providers,

  * •

A prototype implementation of the automated module: It uses IaC templates and
a policy engine to identify applicable threats,

  * •

An initial open-source threat profile repository that cloud users can reuse
and contribute to.

##  II Related Work

As traditional risk assessment does not work well for the cloud, numerous
works have investigated the adaptation of risk assessment for cloud systems.

Note that we define a cloud provider as an organization, like Amazon Web
Services (AWS) or Microsoft Azure, who provide infrastructure cloud resources,
such as virtual machines (VMs). A cloud user is an individual or an
organization using these resources, e.g. for the purpose of storing data. When
a cloud user builds a cloud service, e.g. a web shop, on cloud infrastructure,
she becomes a cloud service provider. In contrast, the term cloud service is
sometimes also used to describe services offered by cloud providers, e.g. AWS
S3.

###  II-A Threat Assessment in the Cloud

While the topic of automated threat analysis of traditional IT-systems has
been investigated for a long time, e.g. by Ou et al. [4], its application to
the cloud is more recent. The CloudSafe tool, proposed by An et al. [5],
implements an almost completely automated security analysis of cloud systems.
They combine an automatically generated reachability graph of cloud VMs
(constructed based on security group definitions) and vulnerabilities of open
VM ports acquired from the NIST National Vulnerability
Database111https://nvd.nist.gov to evaluate security threats. Other approaches
similarly assess risks based on known vulnerabilities [2]. Also the approach
by Chih and Huang [1] is based on known vulnerabilities. It is comprised of an
offline mode and an online mode where the offline mode is based on historical
data about vulnerabilities, whereas the online mode is designed to assess
threats at runtime, e.g. based on current Common Vulnerabilities and Exposures
(CVEs). Note that our approach does not target software vulnerabilities, but
rather targets configuration vulnerabilities of a cloud infrastructure.

Note that while we use attack trees for threat modeling in this paper, various
other methods for modeling threats exist [6] and can also be used with our
approach.

For the threat analysis in this paper, we propose reusable threat profiles.
The concept of reusable security profiles has been applied before as well,
e.g. in the Common Criteria approach[7] where Protection Profiles define
threats and other information. It is, however, not targeted at cloud
resources.

###  II-B Risk Assessment

The general approach to risk assessment and management has been covered in
various standards [8, 9, 10]. A number of works have also proposed adaptations
that are, e.g., more flexible and scalable, or target specific domains [11,
12, 13]. An overview of different risk assessment methods is given by
Gritzalis et al. [14].

Concerning risk assessment in the cloud, Djemame et al. [3] propose a
framework that monitors various risks, including security, policy, and legal
risks. It also targets different cloud environments, like private, federated,
and multi-cloud. They use a risk database that holds assessments of threats
and vulnerabilities for certain assets. Still, their approach is focused on
unique assets rather than generically applicable threats. Their later proposal
[15] features risk assessment both from an infrastructure provider’s and a
customer’s perspective. It overlaps partly with what we propose in this paper,
i.e. in their considerations about risk assessment from the customer’s
perspective during service operation. They do not, however, provide a way to
assess risks resource- and vendor-independently, and they do not provide a
collaborative way of assessing risks. It is furthermore rather a framework
than a concrete proposal of how to discover and evaluate cloud resources’
states.

Others base their risk assessment on high-level cloud threats. Saripalli and
Walters [16] for example, identify six threat categories for the cloud and
calculate their probabilities based on quantitative studies. They integrate
experts only to evaluate impacts, using the wide-band Delphi method.

###  II-C Cloud Security Certification

In our approach we separate expert analyses from the automatic application of
their results. In the context of continuous security certification for the
cloud, often a similar separation between experts, i.e. auditors, on the one
hand, and the automatic verification of results on the other, is employed.

For instance, Anisetti et al. [17] propose a framework in which a
certification scheme is first defined based on requirements established by a
certification authority. Thereafter, the framework verifies gathered evidences
of the certification target for consistency with these requirements. Krotsiani
et al. [18] develop a monitoring-based approach to continuous certification
which also allows for incremental analysis of measurements.

A central challenge in cloud security certification is to evaluate if a set of
measurements is sufficient to prove a pre-defined certification requirement.
The goal of our approach is to quickly assess new threats, rather than
complying with a pre-defined set of requirements. As such, we do not only
decouple expert analyses from the application of their results, but integrate
them in periodic re-assessments.

###  II-D Cloud Monitoring Tools

Commonly used tools for threat modeling and analysis include OWASP Threat
Dragon222https://owasp.org/www-project-threat-dragon and Microsoft Threat
Modeling Tool333https://docs.microsoft.com/en-
us/azure/security/develop/threat-modeling-tool. Using these tools, a data flow
diagram (DFD) can be built and analyzed to identify potential security and
privacy threats. They do not, however, support a continuous discovery and
threat analysis, since the DFD is built manually.

Also, configuration monitoring tools and approaches, like GMonE [19] and
Clouditor444https://github.com/clouditor, exist. Yet, they lack the
possibility to identify combinatorial CWs, since they just identify vulnerable
configurations of single resources. A continuous threat assessment tool for
multi-cloud systems is proposed by Torkura et al. [20] who combine cloud
monitoring with state transition analysis. Their approach, however, is also
aimed at detecting threats based on expected configurations rather than
comprehensive CWs.

In summary, current literature does not sufficiently integrate regular expert-
based threat analyses in the risk assessment process. Yet, we would argue that
while expert analyses are costly, they are also essential in the assessment of
security risks. One reason for this gap is that the analysis results need to
be made reusable and automatically applicable across resources. In the
following sections, we address these gaps by making threat assessment results
reusable and shareable in the form of policy-based threat profiles, and
integrate them into a continuous process model.

##  III Process Model

The cloud risk assessment methodology we propose in this section is targeted
at organizations that build and operate cloud systems in public cloud
infrastructures. Note that we assume a risk assessment methodology similar to
how NIST describes it [10]: A risk assessment consists of a threat assessment
that identifies potential threat vectors for all assets, and evaluates their
probabilities of occurrence. Then, impacts, e.g. financial and privacy
impacts, of these attacks are evaluated. Finally, risks can be derived from
the combination of threat probabilities and their potential impacts.

Running example: Company Cloudara sells smart home appliances, that are
connected to Cloudara’s cloud platform service. Security experts are worried
about various risks on the infrastructure layer: cloud resources could be
misconfigured allowing customers and outside attackers access to sensitive
data, customers’ appliances could inject malicious data into the system,
customer data may be lost due to missing backups, etc. Moreover, there are
several teams developing applications for the cloud platform who frequently
change resource configurations. Additionally, subcontractors deliver code for
cloud apps, and have temporary access to the platform, which is a hybrid
system hosted using infrastructure provided by different infrastructure as a
service (IaaS) providers. Cloudara’s security experts have conducted a risk
assessment and also manually monitor the platform, but are overwhelmed by the
many changes: theoretically, any change needs to be evaluated in combination
with all other configurations to check whether a change results in a new or
modified risk.

Figure 1 shows an overview of the process model of our approach. It consists
of two modules that together form the continuous risk assessment process.

###  III-A Module 1: Manual Preparation and Analysis

Module 1 covers some of the traditional steps to prepare a risk assessment, as
well as a modified threat analysis that creates threat profiles. A threat
profile is the structured description of a number of infrastructure-level
configuration weaknesses that enable an attack vector.

Before the continuous process starts, the risk assessment activities are
prepared. For instance, relevant assets, i.e. cloud resources that should be
assessed, are identified. These can be any resources that can be provisioned
and configured by a cloud user, like virtual machines, blob storages, and
security groups. In AWS for example, an asset can be any resource of the AWS
resource-types555see
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-
resource-type-ref.html for a list of AWS resource types per service, and see
https://docs.microsoft.com/en-us/azure/azure-resource-
manager/management/resource-providers-and-types for guidance on how to achieve
the same for Microsoft Azure..

We take into account the three classic protection goals confidentiality,
integrity, and availability for all assets rather than excluding one that is
not relevant to an asset momentarily, since their analysis results are
designed to be applicable for all future assets of that type also.

Also, the risk model is defined here. For example, scales for the
quantification of threats and impacts, as well as risks, may be defined. Since
our methodology integrates shared threat descriptions, respective repositories
are set up or identified which may be shared with the public, or with a
selected set of organizations, e.g. across organizations.

Figure 1: An overview of the process model: We reorganize the traditional risk
assessment phases in two modules of which the first one is conducted manually
and the second one is completely automated. We also integrate collaboratively
identified threats.

####  III-A1 Identify threat vectors

In this activity, the traditional process of expert-based threat analysis is
performed, i.e. threat vectors are identified and evaluated regarding their
threat probabilities. Various methods to identify such threats are usable to
that end. For example, attack trees can be created to identify potential
attack vectors and derive weaknesses that would enable these attacks (see next
section). In our approach we use attack trees as an example as explained in
the following.

Running example: Cloudara’s analysts create an attack tree for the integrity
of a blob storage (see Figure 2) which, e.g., reveals possible attacks via
spoofing an authorized user’s identity or injecting data via other privileged
resources.

Figure 2: An excerpt of the attack tree from our running example. The leaf
node that refers to access via other privileged resources is a reference to
respective attack tree of that respective resource. This way, complex attack
vectors can be modeled.

####  III-A2 Create threat profiles

First, the new threat profiles from shared threat profile repositories are
reviewed, adapted if necessary, and integrated into the local threat profile
repository. When using attack trees, a CW can represent one leaf of an attack
tree, or a combination of leaves that are connected via and conditions.

Running example: The attack tree is now analyzed regarding its underlying
weaknesses: For example, a bad password policy may enable the spoofing attack
branch. In the following we focus on the branch that obtains access via
another privileged resource: the company employs several IoT Hubs that accept
traffic and store messages in the blob storage. The underlying configurations
that enable this threat therefore include public reachability of the IoT Hub,
and its access to the blob storage (see also Figure 3). A corresponding threat
profile is shown in Listing 1.

⬇

storageaccount_integrity_uploadFromMaliciousIoTDevice[account_names]{

input.resources[i].type == ”Microsoft.Storage/storageAccounts”

input.resources[j].type == ”Microsoft.Devices/IotHubs”

contains(input.resources[j].properties.routing.

endpoints.storageContainers[_].connectionString,

input.resources[i].name)

input.resources[j].properties.publicNetworkAccess == Enabled}

Listing 1: A simplified example of a configuration weakness represented as a
Rego policy: It checks whether any IoT Hub exists that has an access key
(”connectionString”) for a Storage Account configured—effectively checking
whether a malicious IoT device could inject data into that Storage Account.
Additionally, it checks whether the IoT Hub allows public access (last line).

Generally, our approach allows three different possibilities of defining
threat profiles. First, they can be written for specific cloud resources (or
combinations thereof), e.g. configurations of a specific virtual machine and
object storage. Example 1) in Listing 2, for instance, shows a simple
confidentiality threat description for a specific resource that results from
an insecure endpoint configuration.

Second, they can be written for cloud resource types (or combinations
thereof), e.g. configurations of virtual machines and object storages in
general (example 2) in Listing 2).

Figure 3: Constructing machine-readable threat profiles: First, attack trees
are constructed via an expert analysis. Every branch’s underlying conditions,
i.e. the CWs, are then described in a threat profile.

Third, they can be written according to their classification in a cloud
provider-independent ontology. In a previous work666We will add the reference
here for the camera-ready version. we have proposed such a cloud resource
ontology which systemizes cloud resources and their security features, and
defines relationships between them. For example, an Azure VM is classified as
a Computing Resource, which in turn inherits properties from Cloud Resource.
Similarly, an AWS S3 Bucket is classified as an ObjectStorage, which in turn
inherits properties from Storage, and Cloud Resource as well. The ontology
then defines relationships from these concepts to security features, e.g.
every Cloud Resource offers a GeoLocation, and every Storage offers at-rest
encryption. This abstraction allows us to define threat profiles that are
independent of cloud providers and cloud resource types. The example 3) in
Listing 2 shows how general configuration options, like transport encryption,
can be targeted independently of the resource type and cloud provider.

⬇

1) resource_confidentiality_eavesdropOnConnection[”vm1”]{

input.resources[i].name == ”vm1”

input.resources[i].properties.supportsHttpsTrafficOnly == false}

2) VM_confidentiality_eavesdropOnConnection[resource_names]{

resource_names := input.resources[i].name

input.resources[i].type == ”Microsoft.Compute/VirtualMachine”

input.resources[i].properties.supportsHttpsTrafficOnly == false}

3) all_confidentiality_eavesdropOnConnection[resource_names]{

resource_names := input[i].name

input[i].securityFeatures.transportEncryption != ”enabled”}

Listing 2: Simplified examples of threat profiles written in Rego, the policy
language we use in our implementation (Section IV). The policies each show a
list of conditions that enable an eavesdrop attack. In Rego, a policy is
evaluated to be true if all its conditions are true. In this example, it also
returns the affected resources’ names.

Analysts have to choose the most appropriate option depending on the cloud
system and identified threats: while threat vectors that are specific for
certain resources are better targeted with the first option, and threat
vectors that concern a single cloud system are well targeted with the second,
threats for hybrid cloud systems are more adequately covered with ontological
threat profiles.

It is possible that threat profiles overlap when they are defined using
several of the presented options; they will not, however, conflict. Redundant
definitions are also easily identifiable later in the assessment results.

Newly identified CWs may also be shared with collaborators by contributing
them to the shared repository. To prevent the creation of duplicates in the
shared repository, we propose following naming schema for threat profiles:
`<assetType>_<protectionGoal>_` `<attackShortDescription>`. Further
descriptions can be added in comments to exactly describe the CW. Note that
the actual implementation of the CW does not need to be standardized.

Running example: Imagine furthermore that Cloudara is owned by a parent
organization which holds several companies that develop cloud applications.
Since their security experts are doing a lot of redundant work analysing
similar threats, they benefit from knowledge sharing using a common repository
of threat profiles.

####  III-A3 Assess threat and impact values

In the final activity of Module 1, experts assess the threat values of the
identified threat profiles and the potential impacts of a successful attack.
For every threat profile, the probability of a successful attack is evaluated,
e.g. a value of low or a respective numerical value. Impacts are evaluated per
asset and protection goal. For example, a qualitative impact value of medium
or a quantitative impact value of 2.5 may be identified for a successful
attack on the availability of a virtual machine. These assessments are stored
in the Impact & Threat Level Repository (see Figure 1).

Note that threat and impact levels can be omitted, if only potential threats
shall be identified automatically. Missing threat and impact assessments are
then reflected in the risk score (see below).

In summary, Module 1 consists of manually conducted activities that are
repeated periodically. It is not the goal of this module to remove the
necessity of expert analyses, but to design a risk assessment process that
integrates them appropriately for assessing cloud systems, making their
results reusable and automatically applicable.

There are different possibilities to define triggers for a repetition of
Module 1. For example, a time-based trigger, like a monthly repetition, can be
used. Also, new contributions to the shared threat profile repository may
trigger a repetition since these may need to be reviewed and integrated. Also,
a trigger from Module 2 may be used when the automatic assessment identifies
resources that have no threat values or impact values defined yet.

Running example: The storage account is assessed with a medium impact level of
$2$ since it holds valuable customer data of which, however, secure backups
exist. To save time, Cloudara’s experts furthermore apply this assessment to
the storage’s complete resource group since all resources in that group work
with the data. The threat profile that describes the CWs for a data injection
attack is also assessed with a medium value of $2$ because authentication
mechanisms are in place, but customers’ home networks may not be well secured.

###  III-B Module 2: Continuous Application

Module 2 covers the continuous application of the previously defined threat
profiles to the cloud system. We describe the activities of this module on a
high-level here, and present an implementation in Section IV.

####  III-B1 Resource discovery

The first activity of Module 2 executes the discovery of existing cloud
resources in the target system. The discovery results are forwarded to the
next activity in a machine-readable description.

In this paper, we use Azure IaC descriptions, i.e. Azure Resource Manager
(ARM) templates, for the discovery of cloud resources. Our approach, however,
can also be used for other cloud systems, e.g. AWS and Google Cloud Platform
(GCP). We discuss the respective differences to AWS and GCP in Section V-C. In
Azure, IaC templates can be retrieved automatically via the respective APIs
(see Section IV).

In our implementation, we furthermore translate the IaC template to a cloud
provider-agnostic representation that is based on the ontology of cloud
resources described above (see also Section IV). This way, we enable the
assessment of threat profiles that target the ontology-based threat profiles.

####  III-B2 Threat assessment

Next, the IaC templates are evaluated against the previously defined threat
profiles, as depicted in Figure 4. For the task of this evaluation, a policy
engine can be used. Usually, a policy engine evaluates incoming authorization
requests against predefined policies and then approves or rejects the request.
We use this mechanism for a different purpose, i.e. to evaluate cloud
infrastructure descriptions (used as the authorization request) against
predefined threat profiles (used as the predefined policies).

The policy engine then outputs a mapping between CWs and a set of vulnerable
assets from the input template. For instance, the output may indicate that a
denial of service attack is possible for a list of resources, such as
serverless functions or virtual machines, or that a data injection attack is
possible for a storage container. The outputs are reassembled construct a
mapping of all applicable CWs per asset (see Figure 4) to make these results
available for a possible manual inspection.

####  III-B3 Risk calculation

Finally, risk scores are calculated using the previously defined impact and
threat assessments stored in the Impact & Threat Level Repository. Risk scores
are then calculated according to the defined risk model. For example,
numerical threat values and impact values may be multiplied to calculate the
risk value per asset and protection goal. We do not, however, impose a
specific way of calculating risks here, since our approach is independent from
the underlying risk model.

In case no threat or impact values have been defined for a resource, the
respective value is evaluated to $0$, allowing for a simple identification of
resources that are lacking an evaluation. As mentioned above, this case can be
used as a trigger for a new execution of Module 1.

In summary, Module 2 of the risk assessment process is completely automated
and is performed independently of Module 1, creating an automatic assessment
that can significantly improve the longevity of the manual activities. We
envision Module 2 to be executed continuously, i.e. in short intervals,
possibly of few minutes. Apart from this, it may be appropriate to trigger an
execution based on changes in the cloud infrastructure, e.g. based on log
data. The identification of such changes, however, is outside the scope of
this paper.

Figure 4: Attack Tree Reconstruction: The current IaC template is evaluated
against the threat profiles from the local threat profile repository and CWs
for every resource are identified. Finally, these CWs are merged per asset to
form a momentary attack tree.

##  IV Prototype Implementation

In this section, we describe our prototype implementation of the automated
Module 2 which we instantiate for Microsoft Azure. It is implemented as an
open-source project777https://github.com/clouditor/continuous-risk-assessment.
Considerations for extending the implementation to AWS and GCP are discussed
in Section V-C. The prototype comprises the three activities discovery, threat
assessment, and risk calculation. Finally, we describe the results of our
performance evaluation. The prototype is implemented in Go and uses the policy
engine Open Policy Agent (OPA), its policy language
Rego888https://www.openpolicyagent.org/docs/latest as well as parts of
Clouditor999https://github.com/clouditor/clouditor for cloud resource
discovery.

###  IV-A Module 2 Implementation

####  IV-A1 Discovery

In a first step, we discover existing cloud resources of the target cloud
system as IaC templates, which in the case of Microsoft Azure are called ARM
templates. The discovery step is specific to the cloud provider and in this
example realized via APIs provided by
Azure101010https://docs.microsoft.com/en-
us/rest/api/resources/resourcegroups/exporttemplate, which allow to export ARM
templates for single resources, complete resource groups as well as for a
whole subscription. A sample excerpt of an ARM template is shown in Listing 3.

⬇

{”template”: {”$schema”: ”https://schema.management.azure.com/

schemas/2015-01-01/deploymentTemplate.json#”,

…},

”resources”: [{

”type”: ”Microsoft.Storage/storageAccounts”,

”name”: ”risky_storage”,

”properties”: {

”azureFilesIdentityBasedAuthentication”: {

”directoryServiceOptions”: ”None”},

”encryption”: {

”keySource”: ”Microsoft.Storage”,

”services”: {”blob”: {

”enabled”: true,

”keyType”: ”Account”}}},

”minimumTlsVersion”: ”TLS1_0”,

”supportsHttpsTrafficOnly”: false, …},…},…],…}

Listing 3: An excerpt of an ARM template. The resources section includes all
resources and their configurations.

We then iterate through the resources defined in the template, and create a
second resource definition according to the ontology definition, as shown in
Listing 4.

⬇

{”id”: ”/subscriptions/…/storageAccounts/risky_storage”,

”type”: [

”ObjectStorage”,

”Storage”,

”Resource”]

”atRestEncryption”: {

”enabled”: true,

”keyManager”: ”Microsoft.Storage”},

”httpEndpoint”: {

”transportEncryption”: {

”enabled”: true,

”enforced”: false,

”tlsVersion”: ”TLS1_0”}, …}, …}

Listing 4: An excerpt of the custom, ontology-based resource definition.

####  IV-A2 Threat Assessment

In this step, the automatic threat assessment is conducted which primarily
comprises the evaluation of the infrastructure description against the
previously defined threat profiles.

For the evaluation of a given infrastructure description against predefined
CWs, we use the previously discovered IaC template, and its ontology-based
version, as the data input and the threat profiles defined in Module 1 as the
policy input for the policy engine. The output is a mapping of threat profiles
to vulnerable assets (in the following called identified threats).

Hereafter, the process is independent of the chosen cloud provider. The
identified threats are now used to output a mapping of CWs per asset. This
output is both the input for the final risk calculation, and represents a
valuable insight for manual inspection of potential weaknesses.

####  IV-A3 Risk Calculation

The risk calculation is performed according to the initially defined risk
model. In our example we multiply the threat value of an asset’s protection
goal with the respective impact value—both of which are within the interval of
$[1,3]$—resulting in a risk value in the interval of $[1,9]$. This calculation
is done again using Rego policies.

The inputs for the risk calculation policies are the identified threats, as
well as the threat and impact values defined in Module 1. The output then
contains the risk scores for all assets and their protection goals which are
calculated again using a Rego policy. This policy calculates the risk values
for all assets and their protection goals according to the threat values that
have been assessed before before.

###  IV-B Performance Evaluation

We conducted a benchmark test of the automatic threat assessment, i.e. the
functionality that evaluates an IaC template against a set of policies, with
varying sizes of templates and policies, since this is the part of the
implementation that may be a bottleneck when the number of templates and
policies increases. The measurements were performed on an Azure VM Standard
B2s with 2 vCPUs and 4 GiB memory. We used the Go Testing library for the
measurement which also provides benchmarking functionality. Note that the
tests are published along with our source code and threat profiles on GitHub.

We measured the performance of the threat assessment varying the number of
resources of the IaC template between $1000$ and $10,000$. Likewise, we varied
the size of the policies, or threat profiles, in the same range. Figure 5
shows the measured runtimes. Our benchmarking results show that the
performance of the threat analysis increases linearly with the number of
threat profiles and resources in the template. It can be seen that even in
case both threat profiles and cloud resources need to be evaluated in high
numbers, the application of our methodology using OPA is still feasible. The
resources that were used in the benchmark were generic resources with a simple
security property similar to firewall rules. The threat profiles that were
used in the benchmark checked if this security property equals the String
allow.

Summarizing, we would argue that our approach allows to perform assessments of
a cloud system’s IaC description against a (large) number of threat profiles
in frequent intervals of few minutes111111For more details on the performance
of OPA, see its documentation:
https://www.openpolicyagent.org/docs/latest/policy-performance.

Figure 5: Threat assessment performance

##  V Discussion

###  V-A Module 1: Analysis and Threat Profiles

####  V-A1 Manual analyses

A limitation of our approach is that it does not completely alleviate the
necessity for conducting manual risk assessments since the Module 1 activities
still need to be performed periodically. It does, however, extend the
longevity of manually performed analyses considerably by generating reusable
threat profiles that can automatically be applied to newly created (or
modified) resources. It is also an improvement towards an appropriate
adaptation of risk assessment to cloud systems, proposing a systematic way to
approach risk assessment in the cloud. Furthermore, it integrates shared
repositories that may include previously unidentified threat profiles as well
as threat profiles for asset types that may be used in the future.

####  V-A2 Sharing and Reusing Threat Profiles

The reusability of threat profiles across resources and organizations depends
on how they are defined. As described in Section III-A2, they can be defined
for specific resources—limiting their reusability—or defined on a more
abstract level—increasing their generality and reusability. To improve
reusability, we have defined a naming scheme in Section III-A. Yet, the
applied naming can still differ depending on the results of the manual threat
analysis. Note, however, that in case of duplicate threat profiles, the final
risk scores for the respective assets would not change as long as their
probabilities are evaluated equally.

Concerning the shared threat profile repositories, cloud users may see a risk
in sharing their threat profiles with others, since they reveal information
about the architecture of their system. Yet, contributing threat profiles to
shared repositories also shows that a cloud user is aware of the respective
CWs. Also note that it would be possible to make anonymous contributions to a
shared repository, e.g. using a form of mix networks, to obscure which
participant has contributed which threat profiles. The general problem of
sharing security information across cloud users has been investigated in other
works [21, 22].

###  V-B Module 2: Limitations of IaC Templates

Our approach is furthermore limited by the properties that IaC templates
offer, i.e. resource configurations on infrastructure-level. Risk assessments,
however, may also include other types of CWs, such as social engineering or
application-level threats. Note that such threats can still be integrated into
the threat profiles, e.g. by adding a social engineering weakness to every
resource of the system.

Furthermore, when sharing threat profiles, in many cases, organizations will
have to adapt the threat profile syntax to their own usage of IaC templates,
since e.g. ARM templates can be customized with extra properties like variable
names that may need to be integrated into such threat profiles. This approach
is also limited by the fact that some resource types cannot be exported via
the respective APIs121212https://docs.microsoft.com/en-us/azure/azure-
resource-manager/templates/export-template-portal#limitations (yet), e.g. the
environment variables of Azure Function Apps.

In summary, Module 2 is limited by the possibilities that are provided by the
cloud providers’ IaC templates. We would expect, however, that cloud providers
will expand the capabilities of such templates in the future as the usage of
IaC is becoming more popular as part of the DevOps approach.

###  V-C Module 2: IaC Discovery in AWS and GCP

The AWS CloudFormation service uses templates and so-called stacks to manage
IaC deployments. Exporting an existing AWS infrastructure as an IaC template
is not as straightforward as in Azure. In AWS, IaC templates can be exported
only if a template describing these resources has been created in another way
beforehand (as discussed below)131313https://aws.amazon.com/blogs/aws/new-
import-existing-resources-into-a-cloudformation-stack/.

In GCP, the Cloud Deployment Manager141414https://cloud.google.com/deployment-
manager/ can be used for describing resources for a deployment. In GCP, IaC
templates are called configurations and are written as YAML files, while the
term templates in GCP represents a reusable module of a configuration. Similar
to AWS, the GCP Cloud Deployment Manager does not offer the possibility to
export a template of existing resources or an existing resource group.

In summary, the automatic discovery of resources in AWS and GCP differs
significantly from Azure since they do not (yet) offer the possibility to
automatically export an IaC template of existing resources. Using AWS or GCP
with our methodology is, however, still possible if the templates are created
in a different way. Consider that many organizations already define their
infrastructures using IaC templates in which case an export from the existing
cloud system is not necessary for the discovery. Popular tools that are used
to manage the deployment of IaC templates automatically include Chef, Puppet,
and Ansible151515https://www.chef.io/, https://puppet.com/,
https://www.ansible.com/. Also, AWS and GCP may offer a similar export
functionality in the future.

###  V-D Practical Feasibility

The set up and maintenance of the Module 2 components can introduce an
overhead in comparison to traditional security audits and infrastructure
monitoring tools. The biggest overhead our approach introduces may be the
maintenance of threat profiles which can be necessary for several reasons.

First, there may be changes in the configuration options provided by the cloud
provider which should be reflected in existing threat profiles. In comparison
to other security monitoring alternatives, however, our approach is not more
or less laborious, since service providers always need to keep up with the
changes a cloud provider introduces. Second, threat profiles may be deprecated
due to other reasons, e.g. when a certain configuration is not considered
vulnerable anymore. Consider, however, that such profiles can be changed or
deleted once they alert a risk that is considered a false-positive, rather
than maintaining all threat profiles periodically. Third, sharing threat
profiles may be tedious if the respective repositories become large. Therefore
we have discussed possibilities to further standardize the definition of
threat profiles (see above), and we allow for the definition of generic,
ontology-based threat profiles. Note also that a similar idea to our proposal
of a shared repository of cloud vulnerabilities has recently been discussed in
the cloud security community.

###  V-E Effectiveness

Table I gives a comparative overview.

In comparison to other threat and risk assessment approaches, we would argue
that our approach combines the advantages of manual risk assessments with
automated monitoring solutions. Consider the following examples:

####  V-E1 Temporary resources

In cloud systems it may, for instance, be practical to implement temporary
jump servers to enable easy access to application resources, e.g. for external
partners. In this case a VM with SSH access may be set up and combined with a
network security group that makes port 22 publicly available. Temporary,
vulnerable resources like these would quickly be identified in our
approach—independently of its resource type.

####  V-E2 Conditional threat vectors

Often, automatic threat identification results in many false positives, since
they depend on certain resource properties. For example, cloud service
providers often employ different environments with varying security
requirements, e.g. different resource groups for development and production.
In the threat profiles we have proposed, policies can easily be scoped to
certain environments, like resource groups, or single resources.

A further example is the location management of resources. While usually,
resources and sensitive data should be kept in the same geographic region,
e.g. due to the restrictions of data protection regulations, there are cases
in which a cloud service provider may move data, like backups, to another
geographic location. In our approach, a specific threat profile can be defined
that identifies risky storage resources by evaluating their location in
combination with their encryption mechanism: if it uses customer-managed keys
it may be considered a low threat even if it is in a disallowed location.

####  V-E3 Cross-resource threats

We can also represent threat vectors across many resources, possibly
independently of their resource type, which is not possible in standard cloud
monitoring, and may be difficult even in manually conducted assessments. For
example, we can identify a threat to any storage resource that results from
any computing resource that is connected to a networking resource which in
turn opens up a vulnerable port—combining many resource properties.

####  V-E4 Hybrid clouds

Since we also allow to define threats based on all levels of a cloud resource
ontology, we simplify the security management of hybrid cloud systems.
Ontology-based threat profiles are not only applicable to several cloud
providers, but can also represent threat vectors across cloud providers, e.g.
if a threat vector is identified across a computing resource in one cloud
system, which has access to a storage resource in another.

In summary, we expect our approach to be significantly more effective than
traditional assessments since it makes expert analysis results applicable
continuously across resources. Thus, it allows for a quick identification of
risks as described above, also if they only occur temporarily. Also, it
results in less false positive alerts than standard infrastructure monitoring
tools which usually only monitor single configurations or single resources
rather than combinations of configurations. Our approach would also recognize
these risks unambiguously due to the standardized format of IaC and ontology-
based resource descriptions which presents another advantage over automated
monitoring solutions.

TABLE I: Comparison of cloud monitoring tools: DARGOS, Sensu, and GMonE are taken from Ward and Barker, the others have been added by us. We have furthermore added the criterion of resource-/vendor independence. System |  Scalable |  Cloud-Aware |  Fault-Tolerant |  Multiple-Granular |  Compre-hensive |  Time-Sensitive |  Autonomic |  Resource-/Vendor-Independent
---|---|---|---|---|---|---|---|---
DARGOS |  |  |  |  |  |  |  |
Sensu |  |  |  |  |  |  |  |
GMonE |  |  |  |  |  |  |  |
MRA |  |  |  |  |  |  |  |
CRA |  |  |  |  |  |  |  |

While our approach is a risk assessment methodology, its main contribution
lies in the automated module that functions similarly to cloud monitoring
tools. We therefore present Table I which adds our approach (CRA), as well as
manual risk assessment (MRA), to the comparison done by Ward and Barker [23].
In their work they compare different cloud monitoring tools according to the
following criteria.

Scalability refers to the ability of a system to “adapt to elasticity”. As
shown in the performance evaluation, the automated module of our approach
scales well with the increasing size of resources. Cloud-awareness refers to a
system that minimizes delays and costs, e.g. by being location-aware of VMs.
Our approach is not cloud-aware in this sense, since it is not “aware” of
resource locations. We would argue, however, that this criterion is not
relevant for our approach, since the data traffic our approach generates does
not incur costs—the relevant API calls are free of charge—and because the data
collection is done by the cloud provider—which we assume could not be done
more efficiently with a self-deployed system. Our approach is furthermore
fault-tolerant, since it discovers available resources rather than expecting
ones which may not be available. Multiple granularities are given if a system
presents visualizations on different levels of detail, and if it taps
different sources for data collection, e.g. different layers of the cloud
stack. Our approach does not fulfill this criterion (yet); we regard the
addition of visualizations and the addition of threat detection on, e.g., the
software layer as future work. Our approach is also comprehensive in some
respects, as it covers different cloud providers and services. It does not,
however, use other sources for monitoring data, such as hardware and operating
systems, which we regard as out of scope for this paper. Time-sensitivity
refers to the property of providing time guarantees or reducing latencies.
Again, this is not covered by our approach, but we would argue that it is not
relevant since the resource discovery is done by the cloud provider.
Similarly, we expect latencies to be low as long as the cloud provider
conducts the data collection. Autonomic systems “require no significant
configuration or manipulation at runtime” which is fulfilled by our approach,
since manipulations and configurations are completely decoupled from the
automated monitoring and assessment steps. With our approach we have
introduced two new criteria, namely resource-/vendor-independent assessments,
i.e. expected states can be defined independently of the resource type and
cloud provider.

##  VI Conclusions

Mitigating security problems quickly is especially important in the cloud
where changes on the infrastructure-level occur frequently. The automation of
risk assessment allows to keep up with these changes.

We have proposed a redesigned risk assessment methodology that partly
automates the risk assessment process for cloud systems. It employs reusable
threat profiles that can be applied across assets, and it integrates shared
threat profile repositories that allow organizations to collaborate on threat
profiles. Such a collaboration can speed up the threat analysis of new
resources and configurations, and can complement existing ones. We have
supported our methodology by an extendible prototype implementation that
continuously applies threat profiles to cloud resources using the Open Policy
Agent. Our implementation is built in a modular fashion allowing for
adaptations to other requirements, e.g. changes to the risk model. We envision
our methodology being used in a collaborative way by the cloud community, as
well as between organizations. To that end, we have created a public shared
repository that can be used and contributed to by others.

In future work, we want to bridge the gap between infrastructure-level and
application-level risk assessment by integrating static code analysis methods
in our approach. We also plan to extend our methodology and threat profile
repository, e.g., with Kubernetes resources, and add suggestions for
mitigations.

## References

  * [1] Chi-An Chih and Yu-Lun Huang.  An adjustable risk assessment method for a cloud system.  In IEEE International Conference on Software Quality, Reliability and Security-Companion, pages 115–120. IEEE, 2015.
  * [2] Patrick Kamongi, Mahadevan Gomathisankaran, and Krishna Kavi.  Nemesis: automated architecture for threat modeling and risk assessment for cloud computing.  In Proc. 6th ASE International Conference on Privacy, Security, Risk and Trust (PASSAT), 2014.
  * [3] Karim Djemame, Django Armstrong, Mariam Kiran, and Ming Jiang.  A risk assessment framework and software toolkit for cloud service ecosystems.  Cloud computing, 5:119–126, 2011.
  * [4] Xinming Ou, Sudhakar Govindavajhala, and Andrew W Appel.  Mulval: A logic-based network security analyzer.  In USENIX security symposium, 2005.
  * [5] Seongmo An, Taehoon Eom, Jong Sou Park, Jin Bum Hong, Armstrong Nhlabatsi, Noora Fetais, Khaled M Khan, and Dong Seong Kim.  Cloudsafe: A tool for an automated security analysis for cloud computing.  In 2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), pages 602–609. IEEE, 2019.
  * [6] Jin B Hong, Dong Seong Kim, Chun-Jen Chung, and Dijiang Huang.  A survey on the usability and practical applications of graphical security models.  Computer Science Review, 26:1–16, 2017.
  * [7] Iso/iec 15408-1:2009: Information technology - security techniques - evaluation criteria for it security., 2009.
  * [8] Iso 31000: Risk management – principles and guidelines., 2009.
  * [9] Iso 27005: Information technology – security techniques – information security risk management., 2011.
  * [10] Rebecca M Blank.  Guide for conducting risk assessments.  2011\.
  * [11] Jrn Eichler and Daniel Angermeier.  Modular risk assessment for the development of secure automotive systems.  In Proceedings of the 31st VDI/VW joint conference Automotive Security, Wolfsburg, Germany, pages 21–22, 2015.
  * [12] Jason RC Nurse, Sadie Creese, and David De Roure.  Security risk assessment in internet of things systems.  IT professional, 19(5):20–26, 2017.
  * [13] Valentina Casola, Alessandra De Benedictis, Massimiliano Rak, and Umberto Villano.  Toward the automation of threat modeling and risk assessment in iot systems.  Internet of Things, 7:100056, 2019.
  * [14] Dimitris Gritzalis, Giulia Iseppi, Alexios Mylonas, and Vasilis Stavrou.  Exiting the risk assessment maze: A meta-survey.  ACM Computing Surveys (CSUR), 51(1):1–30, 2018.
  * [15] Karim Djemame, Django Armstrong, Jordi Guitart, and Mario Macias.  A risk assessment framework for cloud computing.  IEEE Transactions on Cloud Computing, 4(3):265–278, 2014.
  * [16] Prasad Saripalli and Ben Walters.  Quirc: A quantitative impact and risk assessment framework for cloud security.  In IEEE 3rd international conference on cloud computing, pages 280–288. Ieee, 2010.
  * [17] Marco Anisetti, Claudio Agostino Ardagna, Ernesto Damiani, and Filippo Gaudenzi.  A semi-automatic and trustworthy scheme for continuous cloud service certification.  IEEE Transactions on Services Computing, 13(1):30–43, 2017.
  * [18] Maria Krotsiani, George Spanoudakis, and Christos Kloukinas.  Monitoring-based certification of cloud service security.  In OTM Confederated International Conferences” On the Move to Meaningful Internet Systems”, pages 644–659. Springer, 2015.
  * [19] Jesús Montes, Alberto Sánchez, Bunjamin Memishi, María S Pérez, and Gabriel Antoniu.  Gmone: A complete approach to cloud monitoring.  Future Generation Computer Systems, 29(8):2026–2040, 2013.
  * [20] Kennedy Torkura, Muhammad IH Sukmana, Feng Cheng, and Christoph Meinel.  Continuous auditing & threat detection in multi-cloud infrastructure.  2020\.
  * [21] Charles Kamhoua, Andrew Martin, Deepak K Tosh, Kevin A Kwiat, Chad Heitzenrater, and Shamik Sengupta.  Cyber-threats information sharing in cloud computing: A game theoretic approach.  In 2015 IEEE 2nd International Conference on Cyber Security and Cloud Computing, pages 382–389. IEEE, 2015.
  * [22] Yun Zhang, Farhan Patwa, and Ravi Sandhu.  Community-based secure information and resource sharing in aws public cloud.  In 2015 IEEE Conference on Collaboration and Internet computing (CIC), pages 46–53. IEEE, 2015.
  * [23] Jonathan Stuart Ward and Adam Barker.  Observing the clouds: a survey and taxonomy of cloud monitoring.  Journal of Cloud Computing, 3(1):1–30, 2014.


# Autonomous Driving Data Chain & Interfaces

Benjamin Kahl This work was not supported by any organization

###### Abstract

Recent developments in autonomous driving technology have proven that map data
may be used, not only for general routing purposes, but also for to enhance
and complement common sensor data. This document reviews the most commonly
used interfaces and formats at each step of a self-healing map data chain.

##  I Introduction

The utilization of digital maps on smartphones and navigation devices has
become a widely common practice in many areas of the world. Digital mapping
services, such as those offered by Here WeGo, TomTom or Google, have made
navigational instructions based on simple road descriptions accessible to a
large consumer basis.

However, the modern surge of interest in advanced driver assistance systems
and autonomous vehicles has brought forth an ever increasing need for a whole
new set of maps, purposefully built for robotic systems.

The commonly termed High Definition Maps, or simply HD Maps, are advanced road
descriptions specifically built for self-driving purposes. Including highly
valuable information down to centimeter precision such as lane- and road-
boundaries, these maps can provide indispensable data to be incorporated into
the wider sensor-fusion concept.

##  II Autonomous Driving Setups

###  II-A Static map caching

Self-driving vehicles are typically equipped with a plethora of sensors aiding
them in building a virtual model of their surrounding environment. Commonly
employed sensors such as LiDARs, cameras and radars feed their gathered
measurements into an on-board, intelligent controller program which identifies
any objects around the vehicle, determines the correspondingly desired driving
action and sets the cars actuators accordingly.

The limitations of this rudimentary setup emerge from the intrinsic
restrictions common sensors are bound to:

  * •

Most consumer-grade LiDAR scanners can only provide reliable data in a range
of up to 300 meters. [11]

  * •

Due to sub-pixel disparity, the metric distance error in stereoscopic cameras
increase non-linearly in relation of object distance. [8] [9]

  * •

Radar sensors cannot provide reliable measurements on an objects size and
suffer from similar range limitations as LiDAR scanners. [11]

Furthermore, none of the above listed sensors are capable of measuring data
through solid obstacles such as other vehicles, trees or buildings.

To remedy these limitations a map can be employed, providing data well beyond
the immediate vicinity of the vehicle. Indeed, maps are becoming increasingly
popular in many automated driving systems and are often integrated as an
additional sensor, complementing the data measured by conventional means.

###  II-B Hybrid map streaming

As is the case with HD maps, a vast number of inaccuracies can arise from a
single, static copy when the environment is subject to changes.

Thus, this system may be evolved to employ a real-time streaming approach in
which current map data is continuously transmitted to the car from a dynamic
content repository. As an extension, a locally cached copy of the most recent
version can be kept on-board the vehicle at all times, with updates being
fetched in regular intervals.

This hybrid, cloud-based approach entails a permanent, low-latency and high
bandwidth connection, providing a significant advantage over static methods
only if host maps are regularly updated.

###  II-C Self-healing map stream

Steady corrections and updates to a provided map database can be achieved
through sensor-crowdsourcing. Here, the sensor data collected by vehicles is
sent back to the map provider and used to repair and renew outdated
information. This type of data chain is commonly called a self-healing setup
and is depicted in fig. 1.

The subsequent sections will focus on the individual steps of generalized map
production as well as the cloud-to-vehicle and vehicle-to-cloud interfaces.

Figure 1: Self-healing map data chain and most commonly used interfaces.

##  III Map Production

The production of high-accuracy maps is a complex process that begins with the
collection of vast amounts of raw data.

Specially designed mapping vehicles that are equipped with high-quality LiDAR,
precision GPS and further critical components can garner a large sum of
detailed information about the environment. Combining this with satellite
imagery, government provided data and legacy maps provides a solid basis for
the desired HD map.

After going through a selection and verification process, sensor-crowdsourced
data is organized, harmonized and finally merged into the published map
layers. Sensors that may provide useful data range from LiDAR and image data
to V2X sensors.

Figure 2: Common steps in the production of HD maps.

The result is a complete map-database containing a global model of all
collected information. The de-facto standard used for databases of these types
is the Navigation Data Standard (NDS).

##  IV Navigation Data Standard

The Navigation Data Standard is a standardized format for navigation databases
which aims to enable a seamless fusion of map and sensor data for advanced
driving automation. It is being developed and maintained by the NDS
association consisting of BMW, Volvo, TomTom and several more members.

In order to enable its usage in autonomous driving systems, NDS maps strive
towards providing following key benefits over their peers:

  * •

Independence from vehicle or navigation-system manufacturer.

  * •

Flexible content management and consistent versioning.

  * •

Allow incremental updates to be delivered to select regions.

  * •

Serve a variety of use cases.

In order to accommodate these requirements, NDS uses the SQLite database file
format as an underlying basis. This enables NDS databases from different
suppliers to be merged and consistently versioned.

Each product database covers a specific geographic area (Example: Europe basic
navigation by TomTom) which is divided into a multitude of update regions.
Update regions (Example: Germany) can be subject to incremental or partial
updates. Similarly to regular version-control repositories, each map update is
delivered in the form of change-only information, which dramatically reduces
the size of content updates and thus enables over-the-air map transmissions.

All data ultimately belongs to a specific building block or layer, each of
which addresses a specific domain of data. Typical building blocks would be:
Traffic information, Routing data, Points of interest, etc.

Each individual application would filter the required building blocks from the
aggregate database in order to cover the intended use case. Of particular
importance to automated driving are the building blocks related to lane
geometry, volatile data and 3D geometry.

Figure 3: NDS building blocks as portrayed by Emde Grafik.

These types of large databases are often clumsy and costly to handle by real-
time applications. For instance, the exact nature of speed signage on the
other side of a country are of little concern to an autonomous driving
program.

The next section describes a standardized interface meant to provide
autonomous driving applications only with the relevant vicinity of the
vehicle.

##  V ADASIS Interface

Advanced in-vehicle applications such as headlight control, infotainment
software or even fully autonomous driving are all commonly placed under the
ADAS umbrella (Advanced driver assistance systems).

The data requirements of these systems are often limited to a vehicles
surrounding environment, known as the ADAS Horizon. Given the wide range of
use cases, the ADASIS Forum was launched in order to establish an industry
wide standard for the provision of such data.

###  V-A ADASIS Forum

The ADASIS Forum was formed in May 2001 with the primary goal of developing a
standardized map data interface between stored map data (NDS databases) and
rudimentary ADAS applications.

The forum is hosted and coordinated by ERITCO, including prominent members
from the automotive industry such as BMW, Ford and Opel.

After its release in 2010, the ADASIS v2 specification has become the widely
accepted de-facto standard for ADAS Horizon Providers, with 2011 giving light
to the first products making use of this interface.

A third version of the specification was launched in 2018, specifically
targeted at autonomous driving systems.

###  V-B ADAS Horizon

The immediate vicinity of the vehicle that is extracted from an NDS database
and passed on to individual ADAS applications is known as the ADAS Horizon.

The extent of the calculated horizon is derived from the road ahead, which
equates to the Most Probable Path (MPP) the car is likely to take. Each road
segment is assigned a probability of the car driving through it, depending on
each individual use case.

Figure 4: MPP (in blue) and ADAS horizon (in orange) as shown by Ress et
al.[3]

###  V-C ADASIS System Architecture

The ADAS horizon is extracted from an NDS map database by a so-called ADAS
Horizon Provider and subsequently delivered on a CAN (Control Area Network)
bus system. The horizon mainly consists of road segments and their respective
attributes. The receiving applications decode the message with a Horizon
Reconstructor.

Figure 5: Core components of the ADASIS architecture as portrayed by Ress et
al.[3]

Thus, the core entities of an ADAS System could be condensed to the following
few component types:

  * •

ADAS Horizon Provider (AHP), which extracts the ADAS horizon and sends it to
the respective applications.

  * •

The ADASIS Protocol, which describes how the horizon is to be encoded or
decoded at each end of the communication line.

  * •

An on-board vehicle CAN bus which serves as a communication interface for each
component.

  * •

ADAS applications, each with their own Horizon Reconstructor (AHR).

A system of this architecture scales poorly with the amount of data being
transmitted, particularly if the underlying CAN bus supports no multiplexing.

As a result, the primary focus in the ADASIS v2 specification is the
minimization of bus load.

###  V-D ADASIS v1 and v2

The ADASIS v1 specification was implemented as a prototype and proof of
concept. It having successfully passed performance and interoperability tests,
the Forum moved on to the development of the v2 standard intended for
implementation by an OEM.

Fig. 6 lists some of the primary differences between the two specifications.
Most of these advances concern the flexibility of the CAN bus communication-
line, with v2 not requiring a polymorphic CAN frame but enabling the recovery
of corrupted data upon CRC error detection should multiplexing be available.

Further improvements, such as differentiation between an increased number of
traffic sings, attachment profiles and curvature interpolations are also
available.

The most important difference, however, lies in the utilized data structure
for the representation of the horizons roads (Transport Concept). The v1
specification maintains the horizon as a network, meaning a set of
interconnected nodes where other paths may branch off from the position of a
given node.

Instead, the main logical entity of the v2 specification is a simple PATH
element, where other branching paths are treated just as any other attribute
(for example traffic sings).

This concept greatly decreases the overall size of the transmitted data and is
particularly adequate for horizons based on a single path concept.

Figure 6: Core differences between the ADASIS v1 and v2 specifications, as
documented by Ress et al.[3]

###  V-E ADASIS v2 Message types

The ADAS horizon is provided in the form of a message stream, where the first
three bits of each message are reserved for CRC purposes in order for the
Horizon Reconstructors to detect missing data. If a bidirectional
communication is available, Reconstructors may issue a re-transmission request
to the Horizon Provider, ensuring the robustness of the system.

####  V-E1 Segment Message

An ADAS horizon consists primarily of a series of segment objects, where each
path is made up of one or more non overlapping segments. Each segment includes
a reference index of its respective path as well as a plethora of information
about the underlying road.

Effective speed limits, number of lanes as well as the route type are all
included, in addition to a series of boolean fields designating the segment to
be part of a tunnel, bridge or emergency lane.

####  V-E2 Profile Message

A profile object determines the exact curvature of a segment, where the Value0
field indicates the profile value at Offset and the Value1 field indicates the
profile value at Offset+Distance1, where Distance1 equates to the pre-
calculated length of the curve.

Profiles can be discrete (zero order), linear, quadratic or of a higher order
with certain interpolation types (such as bezier-curves) requiring additional
control points.

####  V-E3 Attachment Message

Attachment objects represent signs or similar attributes on a path. The path
is referenced via an index with an interpolation number (or offset)
designating the exact location on said path. The Offset variable is stored as
a 13 bit number, limiting the given accuracy to
$\frac{1}{13^{2}}*(pathlength)$.

Figure 7: Composition of an attachment message, as documented by Ress et
al.[3]

####  V-E4 Stub Message

As stated earlier, the ADASIS v1 specification requires a separate node for
each path junction, while v2 allows the usage of STUB objects. Stubs act in
almost the exact same way as regular attachments by referencing a certain
point on a path through an index and offset variable. However, instead of a
single attribute like a traffic sign, stubs point to a path that branches off
at the given location.

Furthermore, the angular predicament, number of lanes and MPP probability are
also referenced.

This results in a far simpler reconstruction process than would be the case in
a network dataset. Whether if the paths referenced by the given stubs are also
transmitted depends on whether if the OEM prefers a single path or multi path
horizon.

####  V-E5 Position Message

In a similar fashion, the vehicles current position is also stored through a
path index and offset value with a position probability and confidence value
indicating the certainty of the given information. In addition, a GPS
timestamp, vehicle speed value and the current lane are also included in a
position message.

###  V-F ADASIS v3

The ADASIS v3 specification was released to all ADASIS Forum members in 2018
and is specialized for use with autonomous driving applications, incorporating
native support for HAD maps and significantly larger horizons. Detailed
information such as precise lane boundaries, 3D obstacle descriptions and
geometry lines for guardrails are also being extracted from NDS databases and
transmitted to ADAS applications.

Finally, the v3 specification allows local changes to be made on cached map
data such that faulty information can be modified on the fly by the control
program.

##  VI Sensoris Interface

The Sensor Interface Specification (SENSORIS) is the preferred standard for
sensor-crowdsourcing purposes. The specification differentiates between three
layers of actors: Individual vehicles belong to a vehicle fleet which
communicates with a corresponding vehicle cloud. Multiple vehicle coulds
communicate with a single service cloud.

Common use cases of this interface include but are not restricted to:

  * •

Real-time traffic, weather etc.

  * •

Map repair and healing.

  * •

Statistical data analysis.

###  VI-A Sensoris Message Types

Sensoris defines three types of messages transmitted between vehicle fleets
and clouds:

  * •

Data messages contain vehicle sensor data of one of three hierarchical
definition-classes. Standard Definition (SD) for GPS, odometry and gyro data,
High Definition (HD) for video, radar and ultrasonic data, Automated Driving
(AD) for 360-degree video and LiDAR data.

  * •

Job request messages can be described as data requests by OEMs made to the
vehicles. The job requests contain the requested type of sensor as well as a
detailed set of constraints.

  * •

Job status messages contain the current status of job requests.

Figure 8: Multiple actor roles and interface as seen in the Sensoris v1.0
specification [6]

###  VI-B Sensoris Architecture

The interface architecture limits itself to defining only content and encoding
methods in order not to restrict different implementation methods and be
agnostic to the communication channel used.

There is an emphasis on the minimization of serialized data by choosing a
compact data format. The Sensoris v1.0 specification recommends either Apache
Avro, Apache Thrift or Google Protocol Buffers, as these fulfill all necessary
requirements.

##  VII CONCLUSIONS

The NDS format builds on modular SQLite data structures, enabling dynamic
feature upgrades, such as the download of specific content layers while
keeping the required connection bandwidth reasonably low by utilizing change-
only updates. NDS maps work worldwide with group members offering coverage
over most geographic regions. The format has proven itself through a variety
of consumer products available since 2012, including BMW and Volkswagen cars.

On the other hand, ADASIS and SENSORIS, both part of the Open AutoDrive Forum,
are being supported on an industry-wide basis by a multitude of OEMs, but only
few implementation have actually been deployed. The problematic bus load of
ADASIS v1 was addressed in its second iteration but concerns about costly bus
load due to the increased horizon and data accuracy in ADASIS v3 remain
largely unaddressed. SENSORIS provides a flexible, yet clearly defined
specification but also lacks completed and deployed products making use of it.

Further testing may be required before passing a final verdict on the
suitability of these interfaces in self-healing autonomous driving setups.

## References

  * [1] Jean-Charles Pandazis - ERITCO, "Introduction to ERTICO & platforms" slides, Tokyo 2018. URL: https://sensor-is.org/wp-content/uploads/sites/21/2018/06/slide-1-japan-1.pdf
  * [2] Jean-Charles Pandazis - ERITCO, "ADASIS and SENSORIS platforms and their impact Automotive Ecosystem" slides, IAEC 2018. URL: https://www.iaec.ist/2018/assets/sunum2018/Adasis\%20&\%20Sensoris\%20at\%20Automotive\%20Ecosystem\%20-\%\%20Charles\%20Pandazis\%20-\%20ERTICO.pdf
  * [3] C. Ress, D. Balzer, A. Bracht, S. Durekovic, J. Löwenau, "ADASIS Protocol For Advanced In-Vehicle Applications", on behalf of the ADASIS Forum. URL: http://durekovic.com/publications/documents/ADASISv2\%20ITS\%20NY\%20Paper\%20Final.pdf
  * [4] N. Karamanov, D. Andreev, M. Pfeile, H. Bock, M. Otto, M. Schulze, "Map Line Interface for Autonomous Driving" Viseton.com White Paper. URL: https://www.visteon.com/wp-content/uploads/2019/01/map-line-interface-for-autonomous-driving.pdf
  * [5] SENSORIS Sensor Interface Specifications Description, 2018. URL: https://sensor-is.org/presentations/#
  * [6] SENSORIS Version 1.0.0 official public specification, 2017. URL: https://sensor-is.org/presentations/#
  * [7] Maxime Flament, ERITCO - ITS Europe, "Automated Driving Data Chain Challenges" slides, Automated Vehicle Symposium 2017. URL: https://higherlogicdownload.s3.amazonaws.com/AUVSI/14c12c18-fde1-4c1d-8548-035ad166c766/UploadedImages/2017/PDFs/Proceedings/BOs/Bo3-1.pdf
  * [8] Sophian, Ali, Wahju Sediono, Muhammad Salahudin, Mohd Sataarie Mohd Shamsuli and Dayang Qurratu’aini Awang Za’aba. “Evaluation of 3D-distance measurement accuracy of stereo-vision systems.” (2017). URL: https://pdfs.semanticscholar.org/1d03/ffe4dea327c22b243d6f84fb1fbd30e4273e.pdf
  * [9] Pinggera P., Pfeiffer D., Franke U., Mester R. (2014) "Know Your Limits: Accuracy of Long Range Stereoscopic Object Measurements in Practice." In: Fleet D., Pajdla T., Schiele B., Tuytelaars T. (eds) Computer Vision – ECCV 2014. ECCV 2014. Lecture Notes in Computer Science, vol 8690. Springer, Cham. URL: https://link.springer.com/chapter/10.1007/978-3-319-10605-2_7
  * [10] K. Burke, 2019, "How Does a Self-Driving Car See?", Nvidia Blogs. URL: https://blogs.nvidia.com/blog/2019/04/15/how-does-a-self-driving-car-see/
  * [11] A. Osman Ors, 2011, "RADAR, camera, LiDAR and V2X for autonomous cars". URL: https://blog.nxp.com/automotive/radar-camera-and-lidar-for-autonomous-cars
  * [12] ABI research, HERE WeGo, 2018, abiresearch.com "The Future Of Maps: Technologies, Processes And Ecosystem".
  * [13] Navigation Data Standard TomTom Product Service URL: https://www.tomtom.com/automotive/products-services/real-time-maps/navigation-data-standard/#