DELIVERABLE - SECUREIoT Project

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

Deliverable Number D5.4 Deliverable Name IoT Compliance Auditing as a Service. First

version Dissemination level PU

Type of Document Demonstrator

Contractual date of delivery 31/01/2019

Deliverable Leader FUJITSU

Status & version Final – V1.1

WP / Task responsible WP5 / T5.2, T5.5 / FUJITSU

Keywords: Compliance auditing, security controls, regulations, predictive

security, Security as a Service (SECaaS)

Abstract (few lines): The present deliverable is devoted to the description and the

documentation of the Compliance and Auditing Service (CAS) of

the SecureIoT platform. This service will be provided in the

Security as a Service (SECaaS) context of SecureIoT.

The deliverable is of a “demonstrator” nature and includes

information about the initial proof-of-concept implementation

of the service, which is destined to be enhanced and fine-tuned

in subsequent releases of the deliverable, namely deliverables

D5.5 and D5.6 that are linked to this one.

Ref. Ares(2019)926505 - 15/02/2019

Page | 2

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

D5.1 – IoT Compliance Auditing as a Service. Fir st version,

Version: v1.1 -Final, Date 15/02/2019

Deliverable Leader: Jürgen Neises, Thomas Walloschke (FUJITSU)

Contributors: José Francisco Ruiz (ATOS), Daniel Calvo (ATOS), Thorsten

Jansen (DWF), George Boukis (SiLO), Sofianna Menesidou (UBI)

Reviewers: Hendrik Eikerling (It’sOWL), Sofianna Menesidou (UBITECH)

Approved by: Stylianos Georgoulas (INTRA)

Page | 3




Executive Summary SecureIoT aims to design and implement a data-driven platform for security monitoring and

security automation of Internet-of-Things (IoT) systems. The platform will support various

security scenarios by providing a range of security services that will be accessible through

appropriate APIs (Application Programming Interfaces) or as a service. In this context, it will

provide “built-in” security services, which will be deployed and delivered based on a SECaaS

(Security as a Service) modality. These “built-in” services are designed and implemented as part

of WP5 and include a risk assessment service, a compliance auditing service, a security

programming support service for IoT developers, as well as a security knowledge base for IoT

systems.

The present deliverable is devoted to the description and the documentation of the Compliance

and Auditing Service (CAS) service of the SecureIoT platform provided under the principle of

Security as a Service (SECaaS). The deliverable serves as a “demonstrator’ nature and includes

information about the initial proof-of-concept implementation of the service, which is destined

to be enhanced and fine-tuned in subsequent releases of the deliverable, namely deliverables

D5.5 and D5.6, which will describe the refinement, evolution and conclusions of the work

presented here.

Compliance to company and regulatory policies and its auditing is a major field of information

security management. Nowadays this task is usually performed by humans supported by a

number of tools regarding the various areas of IT or OT operations. Within the future dynamic

setting in the IoT, this task will call for a new automated support covering the changing landscape

of an IoT system. The CAS shall support IoT service providers, Information Security Managers and

IoT developers in analysing and achieving compliance of an IoT system according to policies

resulting from regulatory bodies, like the NIS or the GDPR, or from Standards, e.g. ISO2700x, or

best practices as the ENISA or IOTSF Security Guidelines. Even designed as a service on request,

such a request may be issued eventually by an IoT system within a workflow or Process

Automation (RPA) like mechanism.

The implementation of the CAS is based on security information collected by other modules of

the SecureIoT platform, notably a CMDB implemented in WP6 by the pilots. As such, the CAS is

used as a basis for validating the policy related modules developed in the project. In this context,

subsequent implementations of the SecureIoT CAS SECaaS will consider and assess more

advanced versions of the data collection and data analytics prototypes.

Overall, the present deliverable provides detailed specifications for the CAS SECaaS of the

SecureIoT platform. These specifications provide a sound basis for advancing the initial MVP

(Minimum Viable Product) implementation of this deliverable, as part of its subsequent versions.

In the course of the project, it became apparent that various parts associated with this task are

still the subject of research in many respects. With this in mind, it must be evaluated in the course

Page | 4




of the implementation of the Compliance Auditing Service which characteristics can be

implemented within the planned framework. In addition, adaptations of the SecureIoT

architecture with regard to policy management are planned, which will influence the

implementation of the service in the subsequent iterations.

Page | 5




Document History

Version Date Contributor(s) Description

0.00 03/10/2018 Daniel Calvo

(ATOS) Consolidated ToC for WP5 deliverables.

0.1 15/01/2019 Jürgen Neises

(Fujitsu)

Consolidation of approach, architecture,

modules, API documentation

Draft document


(Fujitsu) Update of the ToC and content

0.3 21/01/2019

José Francisco Ruiz

(ATOS)

Jürgen Neises

(FUJITSU)

Updates on Introduction (Method and

Approach), Requirements and

Specification of API

0.4 22/01/2019


(ATOS)

Jürgen Neises

(FUJITSU)

Sofianna

Menesidou

(UBITECH)

Update of

Section 1.1 description of ABAC and

approach

Chapter 2 describing reference scenarios

and requirements, architecture and

interaction with other tasks

Chapter 3 drafting actors, scenarios and

logical view

Chapter 4 description of background

technology PaaSword tool

Chapter 5 drafting the API description

0.5 23/01/2019


(ATOS)

Jürgen Neises

(FUJITSU)

Include Challenges, adapt Chapters

0.6 25/01/2019 Jürgen Neises Preliminary version for internal review

0.7 28/01/2019


(ATOS)

Jürgen Neises

(FUJITSU)

Merging contributions

0.8 28/01/2019 José Francisco Ruiz

(ATOS) Finalizing document for internal review

Page | 6




Jürgen Neises

(FUJITSU)

0.91 25/01/2019

Sofianna

Menesidou

(UBITECH)

Internal Quality & Technical Review 1

0.92 28/01/2018 Hendrik Eikerling

(ITSOWL) Internal Quality & Technical Review 2


(Fujitsu)

Addressed reviewers’ comments, various

Edits and Fine-Tuning, Prepared for final

submission

1.01 11/02/2019 Jürgen

Neises(FUJITSU)

Including updated implementation

approach

1.02 12/02/2019

Jose Ruiz (ATOS)

Jürgen Neises

(FUJITSU)

Including Policy Modelling methodology

proposed by DWF

Cross check and refinement of

implementation plan


(FUJITSU)

Adaptation to review of Stylianos

Georgoulas (INTRA)


(FUJITSU)

Finalization, including comments of

contributors, including contributions to

tables 6


(FUJITSU)

Sanitation of document – accepting all

changes, update ToC, lists of figures and

tables

1.1 15/02/2019

Stylianos

Georgoulas

(INTRA)

Submitting the document

Page | 7




Table of Contents Executive Summary ......................................................................................................................... 3

Definitions, Acronyms and Abbreviations ...................................................................................... 9

1 Introduction ........................................................................................................................... 10

1.1 Compliance and Auditing Method and Approach ........................................................ 10

1.2 Document structure ...................................................................................................... 18

2 Analysis of requirements ....................................................................................................... 19

2.1 SecureIoT reference scenarios and use cases .............................................................. 19

2.2 SecureIoT architecture and technical specifications .................................................... 20

2.3 CAS Interactions with different tasks ........................................................................... 23

2.4 SecureIoT specification of usage scenarios .................................................................. 25

3 Specification of Compliance and Auditing Service ................................................................ 30

3.1 Architectural Model ...................................................................................................... 30

3.1.1 Actors ........................................................................................................................ 30

3.1.2 Scenarios view........................................................................................................... 30

3.1.3 Process view .............................................................................................................. 32

3.1.4 Logical view ............................................................................................................... 34

3.2 Compliance and Auditing Service API Description........................................................ 36

3.2.1 API and Interfaces Overview ..................................................................................... 36

4 Background Technologies ...................................................................................................... 41

4.1 Description of the PaaSword tool ................................................................................. 43

4.1.1 Architecture description ............................................................................................... 43

5 Experimental PoC implementation ....................................................................................... 46

5.1 CAS Implementation Objectives ................................................................................... 46

5.1.1 CAS Implementation Targets .................................................................................... 46

5.1.2 CAS Implementation Plan ......................................................................................... 47

5.2 PaaSword tool system requirements and handling ...................................................... 49

5.2.1 Code and Binaries availability ................................................................................... 50

5.2.2 System Requirements ............................................................................................... 50

6 Continuous integration (CI), testing (CT) and deployment (CD) strategy ............................. 51

7 Conclusions ............................................................................................................................ 52

Page | 8




References .................................................................................................................................... 53

Table of Figures FIGURE 1 ABAC INDICATIVE INFORMATION FLOW [XACML 17] ............................................................................................... 12 FIGURE 2 XACML DATA-FLOW DIAGRAM [XACML 17] .......................................................................................................... 14 FIGURE 3 POLICY MODELLING AND DEPLOYMENT PROCESS ........................................................................................................ 15 FIGURE 4: HIGH-LEVEL LOGICAL VIEW OF THE SECUREIOT ARCHITECTURE AND MAPPING TO TECHNICAL WORKPACKAGES 0 ................ 20 FIGURE 5 CAS COMPONENTS - LOGICAL VIEW ....................................................................................................................... 21 FIGURE 6 DEPENDENCIES TO OTHER TASKS ............................................................................................................................. 24 FIGURE 7 CAS - POLICY MODELLING .................................................................................................................................... 31 FIGURE 8 CAS COMPLIANCE AUDITING AND EVALUATION ......................................................................................................... 32 FIGURE 9 SEQUENCE DIAGRAM - CREATION OF POLICIES IN THE CAS........................................................................................... 33 FIGURE 10 SEQUENCE DIAGRAM - SELECTION OF POLICIES IN THE CAS ...................................................................................... 34 FIGURE 11 CAS LOGICAL VIEW ........................................................................................................................................... 35 FIGURE 12 CAS MODULES ................................................................................................................................................. 41 FIGURE 13 HIGH-LEVEL DIAGRAM PAE ................................................................................................................................. 44

List of Tables TABLE 1 CONNECTED CAR AND AUTONOMOUS VEHICLE USE CASE SCENARIO REQUIREMENTS TO COMPLIANCE AUDITING SERVICE ......... 26 TABLE 2 SOCIALLY ASSISTIVE ROBOTS USE CASE SCENARIOS REQUIREMENTS TO COMPLIANCE AUDITING SERVICE ................................ 27 TABLE 3 CAS API - POLICIES .............................................................................................................................................. 36 TABLE 4 CAS API - ANALYSIS ............................................................................................................................................. 38 TABLE 5 CAS API - REPORT ............................................................................................................................................... 39 TABLE 6 IMPLEMENTATION OF 1ST PROTOTYPE - TIMELINE ....................................................................................................... 49

Page | 9




Definitions, Acronyms and Abbreviations Acronym Title

ABAC Attribute Based Access Control

API Application Programming Interface

CAS Compliance Auditing Service

CMDB Configuration Management Database

DoA Description of Action

Dx Deliverable (where x defines the deliverable identification number e.g. D1.1.1)

ENISA European Network and Information Security Agency

EU European Union

GDPR General Data Protection Regulation

GSMA GSM Association

GUI Graphical User Interface

HIPAA Health Insurance Portability and Accountability Act

ITIL Information Technology Infrastructure Library

IoT Internet of Things

IOTSF IoT Security Foundation

MSx project Milestone (where x defines a project milestone e.g. MS3)

Mx Month (where x defines a project month e.g. M10)

OT Operational Technology

OBU On-board Unit

OTA Over the air update

PAE PaaSword Authorization Engine

PAP Policy Administration Point

PC Project Coordinator

PCI_DSS Payment Card Industry Data Security Standard

PEP Policy Enforcement Point

PIP Policy Information Point

PM Project Manager

PoC Proof of Concept

PRP Policy Repository Point

PU Public

R Report

RA Risk Assessment

SECaaS Security as a Service

SIEM Security Information and Event Management system

SOX Sarbanes-Oxley Act

WP Work Package

XACML eXtensible Access Control Markup Language

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language

Page |

10




1 Introduction The main goal of the SecureIoT project is to introduce, validate and promote a novel approach to

the security of IoT applications, which emphasizes a timely, predictive and intelligent approach

to the identification and mitigation of security threats and incidents. One of the main

characteristics of this approach is its ability to deal with smart objects, while at the same time

supporting security interoperability in supply chain scenarios that involve multiple IoT systems

and platforms with diverse security capabilities. The project will reflect its approach to an

architectural concept, which will serve as a basis for implementing predictive and intelligent

security systems. Based on this overarching architectural concept, the project will develop

concrete security services, like the Compliance Auditing Service (CAS), that will be validated in

the scope of the project’s use cases.

In this context, the purpose of the present deliverable is to introduce the Compliance & Auditing

Service. It lists the requirements and dependencies that drive the design and implementation of

the service. Additionally, it provides a detailed description of the CAS architecture and the

interactions with the different components of the SecureIoT solution. It provides a detailed

specification of an open API, which can be exposed in order to utilize the CAS solution. Moreover,

in this deliverable, we reuse existing background technologies for the compliance and evaluation

created from H2020 PaaSword European project and we redesign its exposed services in order

to fit the SecureIoT solution and needs. In this context, we provide an initial experimental PoC

(Proof-of-Concept) implementation of this adaptation. Finally, the deliverable points out the

Continuous Integration, Continuous Deployment and Continuous Testing methodology that will

be followed in work package WP5 and will be extended in the rest of the work packages that

offer software components.

1.1 Compliance and Auditing Method and Approach „In general, compliance means conforming to a rule, such as a specification, policy, standard or

law.” [MKGC 08]. Hence, the fulfilment of a rule or a set of rules on the IoT systems operations

needs to be evaluated by the Compliance Auditing Service. Today in the landscape of compliance

and auditing there are a number of solutions available for traditional IT systems. The vast amount

of solutions relies on some workflow and the semi-manual evaluation of reports on ITIL based

processes as user management, change management, etc.

Today’s compliance auditing security software may track user actions and data access or

modifications according to rule sets for specific regulations. For instance, HIPAA compliance audit

reports, which may be relevant in the Social Assistive Robot use case scenario, shall report on

topics like

https://en.wikipedia.org/wiki/Policy

Page |

11




• File or Folder Changes

• Group Management

• User Management (e.g. access rights, password policies)

• Login Failures and Duration

• Recent User Login Activity

Other regulations like SOX and PCI-DSS similarly focus on data access. This kind of evaluation of

compliance is closely linked to information sources user access, e.g. Microsoft Active Directory,

and system configurations, e.g. in a CMDB. Up to date those resources are accessed and

monitored, and reports are generated depending on rather static rule sets per area of

application. However, this is not adequate for a future IoT environment, which is applied to cross

companies, cross sectors and cross-countries scenarios. A more flexible approach shall be

implemented in task T5.2 to cover a more generic approach to compliance auditing applied to

IoT systems.

Considering the definition of compliance as adherence to rule sets based on policies and the

evaluation of this adherence being linked to access management and control, the application of

access control technologies is proposed. This shall be illustrated briefly.

Within several deliverables [D2.3, D4.6], Attribute Based Access Control (ABAC) [Schmohl 08] has

been described in detail (See also: https://csrc.nist.gov/projects/attribute-based-access-control

). Especially the context awareness of the ABAC approach has been emphasized. Major parts of

SecureIoT policy related components will be based on this technology. Among those are the

policy interoperability approach, the developers’ support service. In the following paragraph, the

most relevant features of ABAC related to compliance auditing are described (see also deliverable

D4.6 [D4.6]).

The attribute-based access control ABAC is a method, which considers attributes of the objects

and the boundary conditions to be adhered to as well as attributes of the subject, object and

environment when checking the access rights. These attributes can be stored centrally, e.g. in a

local network, in an Open Directory (see "Administration Shell") or locally bound to the Industry

4.0 entity [I40].

The correctness of the attributes at the time of issue can be verified by mathematical procedures

(hash, signature, etc.). It can also be used to determine and verify the identity of the issuing body.

Such attributes are called meta-attributes. In addition, "dynamic factors" can also be used as

attributes for access control. Environmental attributes such as time, location or security

requirements can be used to link precisely the conditions of access to an object to environmental

conditions.

https://csrc.nist.gov/projects/attribute-based-access-control

Page |

12




In ABAC, there are not static lists of permissions that associate subjects with objects, but instead

there are “snapshots” of such associations that can be generated and dynamically change based

on the current context. No direct relations between the subject and the object are defined as in

RBAC, but permissions are assigned via more extensive access rules (policies).

The key difference of ABAC is the fact that the concept of provided policies can express a complex

rule set that can evaluate many different attributes. This latest concept has its strengths in the

field of global systems, which do not have to be directly connected in organizational terms and

have certain agility. Its strengths, therefore, predestine it for use on the web and other global

systems. Central administrative units are not required immediately since the required trust is

solved using attribute technologies. In this way, very large numbers of participants can be flexibly

controlled.

Figure 1 ABAC Indicative Information Flow [XACML 17]

Any ABAC system should implement the conceptual flow that is depicted in Figure 1 for checking

the fulfilment of an access rule.

Page |

13




(step 1) The request of a Subject is handled by the Policy Enforcement Point (PEP) of the ABAC

Mechanism

(step 2) The PEP consults the Policy Decision Point (PDP) examined in order to reach a decision

of “Yes”, “No”, “Not Applicable”, “Not defined”.

(step 2a) The PDP obtains the relevant Access Control Policy from a Policy Repository Point (PRP)

In order to obtain the set of attributes that have to be examined in order to reach a decision the

attribute examination phase checks:

(step 2b) Subject attributes, which either are provided by the request or may be obtained by a

Policy Information Point (PIP)

(step 2c) Object attributes, which usually are obtained by a PIP

(step 2d) and environmental attributes in order to

(step3) perform the actual decision potentially granting access to the object.

The concept originating from the Attribute Based Access Control (ABAC) architecture has been

implemented in XACML [XACML 17], for example, and is the blueprint for our architecture. The

XACML data flow between the ABAC components is illustrated in Figure 2 below.

Page |

14




Figure 2 XACML Data-flow diagram [XACML 17]

With this in mind, a compliance audit request shall be described analogously to an ABAC request

for access. Thus, a subject (e.g. a developer, information security manager, auditor, component,

etc.) will issue this request considering one or more objects, which may be SecureIoT assets or

users, and a rule (set) related to a policy. Below a more formal description shall illustrate this

more detailed.

The request of compliance audit may be issued by some subject

• Subject 𝑆 ∈ {𝑆𝑢𝑏𝑗𝑒𝑐𝑡𝑠} ,

(Attributes to be defined, e.g. Roles (Auditor, …), Certifications, Domain, …)

considering one or more instances of objects, e.g. assets or users,

• Object �⃗� = (𝑂𝑗), {𝑂𝑗=1,…,𝑛} ⊂ {𝐴𝑠𝑠𝑒𝑡𝑠}

(Attributes (for Assets): CMDB (for Assets), Knowledge Base (Vulnerabilities))

if no information is provided, the result will be “not defined”

Special case: n=1

The evaluation shall result in a Decision

• Decision 𝐷 = (𝐷𝑖𝑗) → (𝐶𝑖𝑗) = 𝐶

on Compliance

• Compliance (𝐶𝑖𝑗) = 𝐶

according to a set (or vector) of Rules defining a Policy

Page |

15




• Rules �⃗� = (𝑅𝑖), 𝑖 = 1,… ,𝑚, 𝑅𝑖 ∈ {𝑅𝑒𝑔𝑢𝑙𝑎𝑡𝑖𝑜𝑛𝑠, 𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝑠, 𝐷𝑜𝑚𝑎𝑖𝑛 𝑠𝑝𝑒𝑐𝑖𝑓𝑖𝑐|𝑃𝑅𝑃}

Special case m=1

Policies and Rules are stored in a database, a so-called Policy Repository Point.

Overall this may be described as

• 𝐷 (�⃗� , 𝑆, �⃗� ) = 𝐷𝑖𝑗(𝑅𝑖 , 𝑆, 𝑂𝑗) ↦ (𝐶𝑖𝑗) = 𝐶, 𝑖 = 1, . . 𝑚, 𝑗 = 1,… , 𝑛,

𝐶𝑖𝑗 ∈ {𝑌𝑒𝑠, 𝑁𝑜,𝑁𝑜𝑡 𝐷𝑒𝑓𝑖𝑛𝑒𝑑,𝑁𝑜𝑡 𝐴𝑝𝑝𝑙𝑖𝑐𝑎𝑏𝑙𝑒}

With this, it is possible to check one object against many rules or vice versa.

Serialization over i and j results in m*n requests to the PEP.

This way, such a decision is analogous to the ABAC approach but gives an abstract result of

compliance. Moreover, existing technology may be used to implement a general context-aware

Compliance Auditing Service.

The Compliance Auditing Service will utilize this technology for assessing compliance. Policies

need to be modelled and translated into rule sets, which shall be authored and deployed in a

policy framework via the Policy Administration Point (PAP). Actually, the potential automation of

this task still is subject to research. Hence, it may be supposed, that this will need human

intervention and effort (see also deliverable D2.3 [D2.3]).

Modelling of general policies still is a complex human task. There are several approaches

available for modelling access control policies. However, a formal method for modelling legally

implied policies into technical rule sets still is subject to research. Within this task, we will assess

tools and methods to describe a scheme facilitating this process.

Figure 3 Policy modelling and deployment process

Page |

16




Within this task, the NIS directive, the GDPR and standards like ISO27001 are considered. Since

the extensive requirements framework of the GDPR also covers the policies relevant for NIS and

ISO27001 to a large extent, the GDPR is taken as starting point for developing a method for policy

modelling and rule description. The following preliminary lists illustrate the complexity and the

components, which shall be considered. A major task in developing a modelling work scheme will

be the specification of the relations of objects, object classes and the relevant context. The

development of a modelling scheme will be assessed consulting DWF, the legal partner of the

consortium. DWF proposed the following components of such a scheme with regards to the

GDPR:

Possibly involved natural or legal persons:

o (Data) controller o Employee of controller o (Data) processor o Employee of processor o Sender (of data transmission) o Recipient (of data transmission) o Internal (same legal person) business unit as… o Third party (not same legal person as…) o Non-EU (“third country”) … (controller/processor/sender/recipient/third party) o Data subject o Data protection officer o Data protection auditor o Supervisory authority

Possible actions with regard to data:

o Processing, (with the subcategories of) o Collecting o Storing o Adapting/altering o Erasing/destroying o Structuring/organising o Combining/aligning/comparing (with…) o Transmitting/disclosing (to specified recipient/s) o Disseminating/making available (to group/s of recipients) o Anonymising (with possible subcategories of) o Aggregating

Page |

17




o Partially erasing o Pseudonymising (with possible subcategories of) o Replacing of link to data subject by pseudonym o Storage separation o Restriction of processing

Data classifications (legal):

o Personal data o Biometric data o Data concerning health o Special categories of personal data (with subcategories of) o Data revealing racial or ethnic origin o Data revealing political opinions o Data revealing religious or philosophical beliefs o Data revealing trade union membership o Data concerning a person’s sex life or sexual orientation o Data obtained from data subject o Data obtained from other person than data subject

Data categories (to be completed based on input by use cases):

o Name o Address o Email address o Phone number o Login name o IP-address o Ownership of (device) o Main user of (device) o Location (e.g. GPS) o Employed by (company) o …

Information sources (data or context information):

o IoT node (all device categories, from field level to cloud level) o PEP

Page |

18




o PIP (containing multiple policies, e.g. privacy notice) o CMDB o Public information (e.g. Whois) o Consent form information o …

Therefore, policies and rules shall be authored in collaboration with the use-case scenarios and

the contributors of this task T5.2.

1.2 Document structure The structure of the deliverable is as follows:

• Section 2 lists the CAS requirements documented in the different SecureIoT tasks.

Moreover, it provides the dependencies that are used as inputs and outputs from the

SecureIoT tasks.

• Section 3 presents the CAS framework architecture by using the 4+1 view model

methodology. Additionally, it provides a detailed CAS API specification

• Section 4 provides a detailed description of the CAS background technologies that are

going to be reused for the PoC implementation and more specifically Ubitech’s PaaSword

solution.

• Section 5 provides the source code availability and requirements of an experimental PoC

implementation for the CAS.

• Section 6 revisits the CI, CT, CD strategy that will be followed more specifically in WP5

and in other work packages.

• Section 7 is the final and concluding section of the deliverable. It draws the main

conclusions from the SecureIoT architecture specification process and provides an

outlook for the subsequent version/release of this deliverable (D5.5).

Page |

19




2 Analysis of requirements This section describes the basic knowledge we have used for the design of the Compliance

Auditing Service (CAS). It is composed of different elements, each of them with a specific goal for

the design. The requirements have been elicited from different sources: use case scenarios,

stakeholders, and SecureIoT architecture. This way we could achieve a better understanding of

the requested CAS functionality and how the CAS may be integrated into the general architecture

of SecureIoT and which enhancements this architecture may need.

This initial description is preliminary, and we will update it as we foresee to enhance the

component as the work progresses and it is used in the different scenarios of the project. Finally,

we describe the different dependencies and interactions of the CAS with the SecureIoT project

tasks.

2.1 SecureIoT reference scenarios and use cases The use cases of SecureIoT cover very different scenarios of applications for IoT, which implies

different needs and compliance requirements. These pilots are Factory 4.0, connected vehicles

and socially assistive robots.

Factory 4.0 covers smart manufacturing, which aims to allow for better and improved

functionalities in industry, being able to use complex IoT devices for performing partial tasks and

obtain very valuable information and feedback of the supply chain activities. This use case has

different scenarios such as head-mounted device, control cabinet, manufacturing facility,

production in Eco2Eco systems, order-controlled production and smart process automation.

The connected vehicles scenario focuses on vehicles sharing information between them (V2V),

vehicles accessing the internet (V2Internet), or to an infrastructure (V2I). In this sense, vehicles

are treated as mobile networks of smart objects that have very dynamic connectivity and share

different types of data to trusted or untrusted nodes.

Socially assistive robots provide specific functionalities to children or elderly people. They

operate stand-alone or interconnected with other IoT devices. Since the services are related to

health, specific regulations as HIPAA apply. The issues go from the data they store to the

communications of data to other devices or over the internet.

A detailed description of those use cases has been provided in deliverable D6.1 [D6.1]. See also

section 2.3 for details.

Page |

20




2.2 SecureIoT architecture and technical specifications As mentioned in deliverable D2.4 [D2.4] and depicted in Figure 4 below, the Security Services

(SECaaS) layer comprises the SECaaS services that will be primarily provided by the SecureIoT

platform, namely Risk Assessment (RA) service, Compliance Auditing Service (CAS), Developer

Support service, and Security Knowledge Base. These services are specified in detail and

implemented in the scope of WP5 of the project. In principle, this layer will also implement other

services that will be based on the data processing outcomes of the Security Intelligence layer,

such as alerting and visualization services (e.g., presentation of security-related information in

dashboards). Note also that all these services can be implemented and offered based on the

SECaaS paradigm, which has been introduced earlier in this section.

Figure 4: High-level Logical View of the SecureIoT Architecture and Mapping to Technical Workpackages 0

The Compliance Auditing Service should provide an appropriate interface to the use case layer

either through a well-defined Open API or a graphical user interface (GUI). The CAS should

consume data streams and semantics produced from Data Collection and Analytics layers in order

to evaluate identified compliance issues and report them to the end user. CAS may either also

Page |

21




provide recommendations for mitigation actions by providing indications of the specific issue or

even allow the user to trigger the SecureIoT PEP (active actions).

Currently, adaptations of the SecureIoT architecture, especially regarding policy management,

are under discussion. Among the major topics of an adapted design there are

• Introduction of a global Policy Repository Point

• Consideration of a SecureIoT CMDB

Thus, in a first implementation of the CAS the local policy repository of the PaaSword tool and

local CMDBs of the use cases shall be considered only. Depending on the adaptation of the

SecureIoT architecture in the next iteration, the usage of global resources will be considered in

the CAS.

Figure 5 CAS Components - Logical View

The CAS is integrated into the SecureIoT architecture by means of different components that

interact for storing data, reporting, accessing data of the target system via interfaces, etc. Error!

Reference source not found. shows the initial composition of the CAS and the

integration/interaction with other components of the architecture. The CAS is composed of, from

a logical point of view (which also is described in the following sections), four different

components, each of them with a specific objective. Following we describe each of the

components and their relationship with the elements of the architecture.

• User Interface: This component is a front-end to be used by the end-users for auditing the

compliance of their systems and obtaining a report of the audit. The architecture of

SecureIoT didn’t require a specific way to provide the functionality of the CAS but we

Page |

22




wanted to make it available in as many ways as possible. Therefore, we are planning to

provide it either with an interface or an API for being integrated with existing or new

systems.

• Policy Management: One feature of the user interface is providing the policy modelling

tool for authoring, test and deployment of policies, rules and objects.

• Auditing and Compliance: The Auditing and Compliance module is provided by the user

interface in the first iteration. This element is the main functionality to be satisfied in the

CAS. The main objective of this component is to provide an auditing and compliance

module that can be used to satisfy the needs of the end-users for their IoT devices.

Therefore, this module provides the end-points of the functionality, which is then

provided to the end-users via the user interface as it is described in the previous

component.

• Reporting: The reporting module provides the audit information to the service user via

the user interface. The report shall include information on the rule, object and auditing

result. It will be stored database. The XML file may be transformed by the user according

to its needs and specifications.

• Data Storage and Data Collection: According to the needs of the policies for assurance

and compliance the system must be able to assess data of the target system and decide

on its compliance to policies and the related rules, which are defined in the user interface.

This is a critical component of the CAS and, therefore, it will be integrated with the CMDB

of the SecureIoT pilots. In the subsequent implementations the integration with the

components of data collection in order to obtain further data and use it for the analysis

of the compliance auditing will be assessed as the improved maturity of those modules

will facilitate the integration.

Moreover, the CAS requires to store and use different data elements: the policies for

assurance and compliance to be used in the target system, the information obtained from

the analysis and the report to be generated. Therefore, the CAS shall utilize an integrated

database in the first implementation. In a later iteration of the CAS the integration with

the future databases for policy storage, aka Policy Repository Point (PRP), will be

assessed. The implementation of a PRP will facilitate the management of all the

information of the CAS centralized in the architecture of SecureIoT and will facilitate the

exchange of data with other components. Additionally, the reports may be provided

either directly to the end-users via API or as raw data or in a component for showing the

requested analysis and, if possible, historical data of past ones.

Page |

23




2.3 CAS Interactions with different tasks The CAS, as also shown in Figure 5, interacts with various tasks of the SecureIoT project. Below

we list the different dependencies with these tasks and the type of dependency.

Tasks providing expected inputs:

• T2.2 Stakeholders' Requirements for Security, Privacy and Trust: Requirements in terms

of technology, functionality, needs, constraints, interaction with systems, expected

security and trust concerns, etc.

• T2.3 IoT Security and Privacy Policy Modelling: how policy creation should be fulfilled and

ways of modelling it

• T2.4 Security Services Architecture and Technical Specifications: requirements from the

SecureIoT architecture and relation with existing components of the architecture as it is

described in the previous subsection

• T4.3 Security and Privacy Policies Interoperability: how the policies to be applied in the

system for assurance and compliance should be integrated with cybersecurity and privacy

issues of the IoT target system

• T5.4 IoT Security Knowledge Base: information about how SecureIoT supports storage

and its management so it can be used for the storing of the different elements of the CAS

• T5.5 Continuous Integration and Configuration of SECaaS Services: hosting of the SECaaS

services (deployment platform) and how to perform the integration of the results of

WP4/WP5 in CAS as we described in the previous subsection

• T5.6 Legal and Regulatory Issues: Input to be used for the policy modelling of assurance

and compliance in the target system. This information is very important as helps us

describe how and which information can be compiled from the target system and how to

manage it in SecureIoT

• WP6 Usage Scenarios, Validation and Evaluation: information on the requirements of the

use cases and their implementation scenarios

Page |

24




Figure 6 Dependencies to other tasks

• T5.5 Continuous Integration: it will be used for the deployment and development of the

CAS and the tools/components that are part of it

• T5.6 Legal and Regulatory Issues: this task will analyse the policy management

implemented in the CAS for legal and privacy issues

• T6.2/T6.3/T6.4 Use Case Scenarios: integration of the CAS in their use case and evaluation

of its functionality according to the requirements defined in T2.2

• T7.1/T7.4 (Market Platform Architecture, Technical Specification, Realization): integrate

the CAS in the market platform

• T8.1 Dissemination and Communication Activities: use the CAS for dissemination and

communications activities

• T8.2 Contributions to Standards, Clusters and Associations: study if the CAS could be used

as a contribution for clusters and associations of IoT

• T8.3 Exploitation and Business Planning: use the CAS for exploitation and business

activities of SecureIoT

Page |

25




2.4 SecureIoT specification of usage scenarios There is common ground within the relevant regulations NIS, GDPR and the widest spread

security standard ISO2700. Besides looking at privacy and security from a different viewpoint the

specific policies and controls for protection of systems and data may be rather similar.

1. System logs are necessary for each regime necessary to make actions comprehensible and assignable. Accountability, which is relevant in NIS, GDPR and ISO27001 as well, can be decided based upon logged actions only. Moreover, logs are a standard means for detecting security breaches, e.g. by a SIEM.

2. Considering privacy, data classification is required to decide, if the information is sensitive

and to define how to deal with sensitive information and to protect it appropriately.

Classification of required protection is part of controls in NIS, GDPR and ISO27001.

3. Access control is relevant in NIS, GDPR and ISO as a standard measure to secure systems

and data.

4. Encrypted communications shall protect data in transit from manipulation or disclosure.

Hence, it is an important part of NIS, GDPR and ISO27001.

5. Elevation of rights by some application is an issue of privileged access management and thus a typical topic in ISO27001 related controls.

As we described in Section 2.1, we have identified in the three uses cases of the project necessities and requirements that are in line with those controls.

In deliverable D6.1 [D6.1], the use case scenarios of the Connected Car and the Socially Assistive

Robot have described similar policies to be covered within the validation of the Compliance Audit

Service. For simplicity at least, a subset of these policies shall be applied within the Multivendor

Industry use case. Table 1 (Connected Cars) and Table 2 (Socially Assistive Robots) define the

relevant policies by requested functionality of the CAS as described in deliverable D6.1 [D6.1].

These examples illustrate, that the modelling of those policies will include several sets of rules to

be checked. For instance, detection of fine-grain logs at the different layers of the system to

demonstrate accountability (2.2.1) shall include rules on existence and form of logs and several

layers involving the On-Board-Unit as well as the FIWARE cloud and for each layer and targeted

log at minimum one rule will be required.

Page |

26




Table 1 Connected Car and Autonomous Vehicle use case scenario requirements to Compliance Auditing Service

ID Required functionality D2.2 reqs Verification

mechanism

KPIs

2.2.1 Detect existence of fine-

grain logs at the different

layers of the system to

demonstrate

accountability

R5.2.1

R5.2.4

Assessment by

IDIADA / ATO

teams.

Compliance

auditing of

GDPR related

controls

(accountability)

2.2.2 Identification of

potentially sensitive

information exchanged

between vehicle OBU and

IoT Cloud Platform

R5.2.2

R5.2.4

Assessment by

IDIADA / ATO

teams.

Compliance

auditing of

GDPR related

controls

(privacy)

2.2.3 Detect existence of

detailed (per-container,

per-device, per-

component) granular

access control for users,

processes, etc.

R5.2.1

R5.2.3

R5.2.4

Assessment by

IDIADA / ATO

teams.

Compliance

auditing of

GDPR related

controls

(authentication

& authorization)

2.2.4 Identify that

communications between

vehicle OBU and IoT Cloud

platform are encrypted

and rely on mutual

authentications

R5.2.1

R5.2.4

Several tests will

be done using the

Compliance

auditing service,

enabling/disabling

different security

control

mechanisms.

Compliance

auditing of

ENISA related

controls

(privacy)

2.2.5 Vehicle OBU software

must not be able to elevate

its privileges.

R5.2.2

OBU software

running on an

IDAPT unit will be

updated using

OTA mechanism.

The new version

Compliance

auditing of

GSMA related

controls

Page |

27




will simulate a

malicious version

that tries to inject

commands in the

CAN bus and to

obtain statistics

regarding other

system processes.

Table 2 Socially Assistive Robots use case Scenarios requirements to Compliance Auditing Service

ID Required functionality D2.2 reqs Verification mechanism

KPIs

2.2.1 Detect the existence of fine-grain logs at the different layers of the system to demonstrate accountability

R5.2.1 R5.2.4 R5.2.5

Internal assessment (iSPRINT/LuxAI) + Partner support

Compliance auditing of GDPR related controls (accountability)

2.2.2 Identification of potentially sensitive information exchanged between QT robot and CC2U Cloud Platform

R5.2.2 R5.2.4


Compliance auditing of GDPR related controls (privacy)

2.2.3 Detect existence of detailed (per-device, per-component) granular access control for users, processes, etc.

R5.2.1 R5.2.3 R5.2.4 R5.2.5


Compliance auditing of GDPR related controls (authentication & authorization)

2.2.4 Verifying that communications between QT and CC2U Cloud platform are encrypted and rely on mutual authentications

R5.2.1 R5.2.4

Several tests will be done using the Compliance auditing service, enabling/disabling different security control mechanisms.

Compliance auditing of ENISA related controls (privacy)

Page |

28




2.2.5 Software modules must not be able to escalate their privileges.

R5.2.2 R5.2.3

CC2U or QT Cloud software running on a cloud platform will be updated using OTA mechanism. The new version will simulate a malicious version that tries to inject commands in the web-service communication and to obtain statistics regarding other system processes. The robot will also be affected by an OTA update (update QT base software/middleware)

Compliance auditing of GSMA related controls

These requirements illustrate the challenge of policy modelling. The five functionalities arise from various requirements of NIS, GDPR and ISO 27001. However, the related specific policies and especially controls need to be specified further:

1. Existence of (fine-grain) logs: Beyond the mere existence of logs, the granularity is subject of a refined description. In a first step it is supposed that the existence of logs shall be documented in a configuration database including a filename. This can be assessed by a rule for an asset. Therefore, the use case scenarios shall provide a probe, which provides these data to a CMDB. In a later step it shall be assessed, if this can be included in the elastic search framework of SecureIoT and how it may be included in the analytics.

2. Sensitive Information:

Information needs to be classified to detect sensitive information. Hence, there must be

some information, that there is a method for data classification in a configuration

Page |

29




database related to an asset. Therefore, the use cases need to provide such information

in the related CMDB.

3. Access Control:

The existence of access control may be assumed if there are several user accounts

registered in the system. Therefore, the number of user accounts of an asset may be

assessed from a configuration database. This number must be provided by the use cases

in their respective CMDB either automatically or manually.

4. Encrypted communications:

Considering SSL/TLS as a preferred means of encrypted configuration, a network probe

may watch if only TLS headers are used. This probe may send its information to the elastic

framework of SecureIoT. In a 1st step the information is assumed as a configuration item,

which is described in the use cases’ CMDB.

5. Elevation of rights: This may be assessed by a specific probe using a process, which needs root access, trying, if it can be performed by the various SW-users of the asset. However, as starting point this configuration item shall be provided by the use cases in their CMDBs. The use cases shall assess, if they will implement an according to probe in a later phase.

Currently, it is analysed in more detail with the use case partners how they shall integrate and use the service for assessing and ensuring compliance within their scenario. The proposal of the design of a CMDB in deliverable D2.3 [D2.3] is taken as a starting point to ensure a single format and thus simplifying the implementation of the CAS.

Page |

30




3 Specification of Compliance and Auditing

Service In this section, we describe the Compliance and Auditing Service architecture by using the 4+1

view model designed by Philippe Kruchten [KRUCHTEN 12]. First, we provide the architecture

Logical View by using a high-level block diagram, which identifies the interactions between the

different SecureIoT components and the dependencies between the SecureIoT tasks. We

continue by presenting two different high-level Scenarios where the CAS could be used. Finally,

we present the Process View with the help of UML sequence diagrams. At this stage, the CAS

design is not mature enough to present a detailed Development and Physical View which we will

provide in the next version of the deliverable. In the second part of this section, we provide a

detailed API of the CAS component.

3.1 Architectural Model

3.1.1 Actors

In general, a variety of stakeholders may take benefit from a Compliance Auditing Service. Among

them, we have defined the following although this list could be extended in the future as we

progress working in the design, development and integration of the CAS.

• A provider of SecureIoT SECaaS services. This one may create and maintain sets of policies

and rules within the CAS.

• An IoT service’s Information Security Manager, who may create and maintain sets of

policies and rules within the CAS, but who also shall request compliance audit reports

• Developers and deployers of IoT services may check compliance of the IoT service during

development or after deployment and thus request compliance audit reports

• Auditors may request reports for analysis checking the compliance of an IoT system.

Overall, two kinds of users can be identified:

• Policy and rule set modellers, who create and maintain the policies and rules within the

CAS

• Compliance audit requestors, who request an audit check and the relevant report.

3.1.2 Scenarios view

As described in section 1.1 policies need to be modelled and translated into rules. Currently, we

assume that this authoring and testing of those rules in the PAP module of the CAS will be a

Page |

31




human task. This task will also cover the deployment of the rules in the PAP and storing it in the

PRP (Figure 7). This phase will include

1. Login,

2. Authoring (setup rule sets in PAP, test rule sets in PAP),

3. Deployment (deploy rulesets to PDP and store it in the PRP)

Figure 7 CAS - Policy Modelling

When the rule sets are available to the PDP a compliance audit request may be issued and a

report may be requested for analysis and starting mitigation of non-compliances (Figure 8):

1. Login,

2. Select rule set(s),

3. Request compliance auditing

4. Get compliance report

5. Manual tasks outside of the CAS:

a. analyse report

b. mitigate non-compliances

Page |

32




Figure 8 CAS Compliance auditing and evaluation

3.1.3 Process view

The process of compliance auditing is twofold. First policies need to be modelled and rules need

to be authored, i.e. implemented, tested and deployed, in the PAP. Following we include two

sequence diagrams describing the initial functionality we defined for the CAS and interaction with

other components of SecureIoT. Figure 9 shows how policies are created in the CAS using a policy-

modelling tool integrated into the CAS and Error! Reference source not found. how a deployer

of IoT services selects the policies to be used in the target system for assurance and compliance.

For the creation of policies, as shown in Figure 9, the policy modeller (who e.g. has the role of

provider of SecureIoT SECaaS services) accesses the CAS and selects the option for creating the

policies. The CAS shows the interface for modelling policies according to the assurance and

compliance rules for IoT systems, giving support about what elements can be used and in which

way. Once the policy modeller finishes they save all these policies in the system, which uses the

SecureIoT policy models´ database. This storing is internal and transparent for the user.

Page |

33




Figure 9 Sequence diagram - Creation of policies in the CAS

In a second step, the rule sets according to which compliance shall be audited will be selected.

Then as often as required, the compliance audit request may be issued, and a report will be

generated. This second functionality is shown in Error! Reference source not found. below.

Page |

34




Figure 10 Sequence diagram - Selection of policies in the CAS

The IoT Service Deployer (role described previously) accesses the CAS for selecting the policies of

assurance and compliance that wants to apply in the target system. Through the interface of the

CAS they can check the existing policies, select the ones to be used (which are shown according

to the technical requirements of the system and other constraints so only the useful ones for her

are available) and set them to be used for the analysis of assurance and compliance. The policies,

as stated previously, are stored in the SecureIoT policy models’ database. This way the

information can be easily used for the different components of SecureIoT.

3.1.4 Logical view

The Compliance Auditing Service (CAS) provides 3 modules – Policy Manager, Audit Manager,

Report Module – through a user interface and in a later step an API (see Figure 5). It makes use

of the data storage layer of the SecureIoT architecture accessing the use case pilots CMDBs

through it.

The Policy Manager enables authoring, test and deployment of policy models and rules in the

Security Policies and Classification. These policies and rules will be stored within the CAS Policy

Manager. However, it is taken into account to assess the implementation of a SecureIoT Policy

Repository Point, which should be located in the SecureIoT Data Storage (see Figure 11 below).

Page |

35




Figure 11 CAS Logical View

Furthermore, the CAS UI utilizes the CAS Audit manager handling the audit requests regarding

the policy related rulesets and the objects to be audited. The main volume of data for compliance

evaluation will be driven by information stored in the data storage, i.e. the CMDB data of the use

case pilots. The Audit manager collects the related rule, object and audit decision in an XML file.

For storage of this file the envisioned PRP might be used.

These results produced from the CAS Audit Manager will be presented to the end-user via the UI

or an API as an XML based report. This report may be formatted by the user applying customized

XSLT transformations adapting the format of the report to the customer’s own typical

presentation format by the Report Module.

Page |

36




3.2 Compliance and Auditing Service API Description The Compliance Auditing Service is going to be used by different services, internal and external

of SecureIoT. One of the key objectives of the project is to provide CAS as a flexible solution that

can be integrated and used easily and transparently in any IoT system. Therefore, we plan to

provide the service via an API that allows for the usage of its functionalities in a local or remote

environment.

Currently, we have defined a preliminary but still detailed version of an API that can be used for

using the services of the CAS. This way, this section provides an indication aiming for contributing

to the definition of the final and more mature version of the API by describing initial

functionalities, input and output. This API will be naturally completed with more methods and

information developed in the following phases of the CAS.

3.2.1 API and Interfaces Overview

Tables 3-5 below illustrate the main API that supports the CAS functionalities. The API is

composed of three main components, each of them focusing on a specific element or action

provided by the CAS: policies, analysis and reporting. Following we describe the initial version of

the API together with a description of each method, input and expected output.

Table 3 CAS API - Policies

Policies

Name: createPolicy

Description: This method creates a policy of compliance audit

Parameters: 1. policyID: integer

2. policyBody: XML object

Output: 1. true if the policy was created successfully

2. false if any error is found

Exceptions: Exceptions will be generated for identifying if the policy

already exists or the data for creating it (policyBody) is not

correct or incomplete

Name: createPolicyModel

Page |

37




Description: It allows for the creation of a policy using a model (diagram,

etc.)

Parameters: 1. policyID: integer

2. policyModel: XML object

Output: 1. true if the policy was created successfully


Exceptions: Exceptions will be generated for identifying if the policy

already exists or the data for creating it (policyModel) is not

correct or incomplete

Name: obtainPolicy

Description: Requests a policy to the database

Parameters: 1. policyID: the id of the policy requested

Output: 1. policy: XML format

Exceptions: Exceptions will indicate if the policy doesn’t exist

Name: obtainAllPolicies

Description: This method provides all the policies stored in the system

Parameters: -

Output: 1. Policies: XML data containing all the policies

Exceptions: -

Name: deletePolicy

Description This method deletes a specific policy

Parameters: 1. policyID: the id of the policy to be deleted

Output: 1. true if the policy was deleted successfully


Exceptions: Exceptions will indicate if the policy doesn’t exist

Page |

38




Table 4 CAS API - Analysis

Analysis

Name: startComplianceAuditProcess

Description: This method starts the assurance and compliance process in the

target system

Parameters: -

Output: 1. analysis: information in XML format

Exceptions: Exceptions will be generated for identifying if the policies

selected for the assurance is not correct (or doesn’t exist),

if the analysis cannot be done due to a list of specific reasons

Name: pauseComplianceAssuranceProcess

Description: It pauses the assurance and compliance analysis of the system

Parameters: -

Output: 1. true if the process was paused successfully


Exceptions: -

Name: resumeComplianceAuditProcess

Description: Requests a paused compliance audit process to resume

Parameters: -

Output: 1. true if the process was resumed successfully


Exceptions: -

Name: stopComplianceAuditProcess

Page |

39




Description: This method stops a compliance audit process

Parameters: -

Output: 1. true if the process was stopped successfully


Exceptions: -

Table 5 CAS API - Report

Report

Name: obtainReport

Description: This method allows obtaining a report linked to a specific

analysisID

Parameters: 1. analysisID: the ID of the analysis done by the compliance

auditing process

Output: 1. report: data of the report in XML format

Exceptions: Exceptions will be generated for identifying if the analysis

specified does not exist, if the report does not exist or if

any other issue is found

Name: obtainAllReports

Description: It returns all the reports of the system

Parameters: -

Output: 1. reports: XML with all the reports of the system

Exceptions: -

Name: deleteReport

Description: Deletes a specific report

Page |

40




Parameters: 1. reportID: the ID of the report to be deleted

Output: 1. true if the report was deleted successfully


Exceptions: -

Name: updateReport

Description: This method updates a specific report

Parameters: 1. reportID: the ID of the report to be deleted

2. reportData: the new data to be used for the updating

Output: 1. true if the report was updated successfully


Exceptions: -

Page |

41




4 Background Technologies The compliance-auditing component aims to provide and quantify information of adherence to

specified policies and rule sets of the target IoT system. The component will evaluate the

compliance based on the evaluation of rules considering objects related to an evaluation subject

and provide the information on rule fulfilment as reporting. This way, and following the

architecture shown in the previous section, we studied some options for the design and

development of this component, which should satisfy the requirements obtained from the use

cases, stakeholders and SecureIoT objectives.

Figure 12 CAS Modules

Page |

42




The solution we propose to use as the basis for the compliance-auditing component is a solution

based on an ABAC type policy management engine, provided by Ubitech because of a previous

Horizon 2020 project named PaaSword. The use of an existing policy management engine made

the initial implementation feasible and permitted the SECaaS service developers to focus on IoT

specific functionalities of the risk assessment service. In the section below, we describe the

architecture, functionalities it provides and an initial plan to extend it for supporting the needs

of the IoT domain based in the SecureIoT approach. This engine will need some extensions as

illustrated in Figure 11.

In a high-level view, we see the Compliance Auditing Service Module providing the functionality

of the PaaSword engine for the intended use. Hence, it will provide a kind of wrapper and manage

rule sets, the audit request to the PEP as well as generating the report towards the use case.

The PaaSword tool will provide the PEP, the decision engine for evaluating the requests and

assessing the attributes and the PAP module for authoring and modelling the use cases policies

and respective rule sets. In a first step, we will rely on the PAP internal database storing the

rulesets of the use cases.

These modules need to be adapted and extended in the next iterations to make use of the

PaaSword tool for the compliance audit purpose.

• The PaaSword UI needs to be adapted to the processing needs of the CAS. This will include

the adaptation of the look and feel, e.g. wording, and the extension of additional features

like reporting of the compliance audit results.

• The CAS module shall provide reporting features to the UI. In a later iteration the

implementation of compliance auditing for a set of object instances shall be assessed.

Depending on the assessment the handling of the series of requests shall be developed

in the CAS module.

• The handlers for evaluating the attributes within the use-case scenarios CMDBs need to

be implemented. This shall take the descriptions of task T2.3 in deliverable D2.3 [D2.3]

into account.

The development of a general PIP assessing deliberate attribute sources and their values

will be assessed in a later iteration of the CAS.

• In the first step, the CAS will rely on the internal database of the PaaSword tool, which is

used to store the policy models and the rules. For simplicity, a preliminary set of some

rules will be introduced in the PoC. In a 2nd step, the extraction of this database and the

implementation of a general Policy Repository Point as a component of SecureIoT used

for policy modelling and storage of reports will be assessed.

Page |

43




4.1 Description of the PaaSword tool 4.1 Description of the PaaSword tool

As already described in the deliverable D5.7 [D5.7], the PaaSword project introduces a holistic

data privacy and security by design framework that allows the usage of sophisticated context-

aware policy access models and policy access, along with a decision, enforcement and

governance mechanism. These characteristics of PaaSword have been exploited and enhanced

in the frame of SecureIoT in order to allow the development and deployment of secure and

transparent applications through the Programming Support SECaaS, as explained in deliverable

D5.7 [D5.7]. However, we identified the usage of PaaSword engine as a tool suitable also for the

+needs of the CAS.

4.1.1 Architecture description

PaaSword’s high-level architecture is composed of twelve components grouped in four zones

according to the role that they possess. These components communicate internally for receiving,

processing and showing the information of the system and the authorization decisions. In terms

of the CAS SECaaS, we will utilize the PaaSword Authorization Engine (PAE) consisting of the

following components of the PaaSword high-level architecture [PaaSword D1.3]. The same

components will also be used for the Programming Support SECaaS [D5.7]. These components

communicate internally for receiving, processing and showing the information of the system.

Error! Reference source not found. below shows a high-level diagram of the architecture,

showing its components, inputs and output.

• Semantic Model Management: It is the component that manages the Context Model, a

multi-faceted and multi-purpose model. On the one hand, the model aims to define the

functional aspects that can be directly used by the developers and on the other hand it

conceptualizes parametric contextual information (e.g. Location, Time of Interaction) of an

HTTP request that can be used in order to perform policy enforcement. The Context Model

Editor will offer an interface for the creation and editing of the model and will offer

structural and business validation of the model entities. Moreover, some facets of the

model will be centrally created and maintained while some other parts will be adapted to

the customer’s need.

• Security Policy Evaluation and Enforcement & Security Policy Management: These are two

complementary components that are responsible to handle the policies and can be edited

during run-time. The Policy Editor will offer an interface for the creation and editing of the

policies. Moreover, on the one hand, the Security Policy Evaluation and Enforcement (or

Page |

44




Policy Engine) are responsible to perform the context evaluation and the policy

enforcement. Context evaluation relates to the evaluation of the context of an HTTP

request, which is a prerequisite of policy enforcement. On the other hand, Security Policy

Management is responsible to alter the instances of the context model that is used for

policy enforcement. Since the policies rely on the semantic concepts of the Context Model

and these concepts are evaluated during run-time, there should be a mechanism that

performs the ‘translation’ of the policy-related concepts.

Figure 13 High-level diagram PAE

Regarding the input to the system, we have on the one hand the context model and the policies

to be applied and on the other hand, the attributes and values need to verdict the final

permission decision. Finally, the output of the PAE is the permission decision to ALLOW or DENY

access.

4.1.2 Features offered

As aforementioned, the PAE provides functionality for authorization decisions. PAE uses as input

the context model, the security policies and the attribute values (e.g. environment attributes) in

order to output the authorization decision to a resource. The input is supported through the

provided editors’ interfaces for the context model (i.e. the Context Model Editor) and the policies

(i.e. the Policy Editor) and with APIs for providing the attribute values. This way the PAE can be

integrated with several and different attribute values. Below we summarize all the provided

interfaces, but more information can be found in the documentation of PaaSword describing in-

depth its functionality [PaaSwordD5.1].

• Interface between Context Model Editor and Model - Through the Context Model Editor,

users can perform many actions on the Context Model.

Page |

45




• Interface between Policy Editor and Model - Through the Policy Editor, users can perform

many actions on the Access Policies Model.

• Interface between Application and Policy Enforcement Mechanism - This interface

interconnects an Application with the Policy Enforcement mechanism. Every time an end

user performs a request to a Policy Enforcement Point (PEP) the Policy Enforcement

mechanism is responsible for allowing/denying it. The communication takes place through

the RESTful API of Policy Enforcement mechanism. The input data is a JSON message

containing the unique identifier of the application, the identifiers of the access policies that

are used to that specific policy enforcement point and information intercepted from the end

user’s request. The output data is a response message (ALLOW or DENY request).

• Interface between Handlers (attribute values) and Policy Enforcement Mechanism - The

Policy Enforcement Mechanism, may be derived from various sources, e.g. a request itself,

databases, IoT devices, remote services etc. In order to handle such sources, we use the

handlers to federate the raw data and process them in order to acquire the needed

information and Adapters that semantically uplift the Handlers’ output by constructing

appropriate instances of the Context Model.

4.1.3 Reuse of Components

The aforementioned components of the PAE will be extended in order to support the CAS SECaaS.

Currently, we examine possible extensions and enhancements to be done such as:

• Adapt the context model, the policies and the attributes to reflect the IoT market, business

and special constraints.

• Adapt and aggregate the authorization permission outputs to construct the necessary

report for the CAE SECaaS.

4.1.4 Technical Details

As already mentioned in D5.7 Java has been used as the implementation language of the

PaaSword tool. Moreover, Apache Maven version 3.3 is used as a build tool for the project and

for the code organization. A microservices [FOWLER 08] approach is used to develop a single

application as a suite of small services, each running in its own process and communicating with

lightweight mechanisms, often an HTTP resource API. The Drools efficient expert system will be

used in order to create enforceable access control verdicts during the runtime.

Concluding, the prerequisites in order to build and use the tool are Java 1.8 and Apache Maven

3.3

Page |

46




5 Experimental PoC implementation In this section, we present the components for an initial experimental PoC implementation. This

implementation consists of two software blocks. The first one is the PaaSword engine which is

provided as background technology from UBITECH (described in the previous subsection) and the

second one is the overall compliance and auditing management, which enables modelling of

policies and rule sets and which controls the audit request and report generation. This

component exposes the functionalities described in Section 3.2 (API specification) above and will

be used from the other SecureIoT components. Please note that in this initial stage the PoC

implementation it is not integrated with the components of the SecureIoT architecture, for which

outputs are not specified yet (e.g., the Continuous Monitoring & Analytics).

5.1 CAS Implementation Objectives

5.1.1 CAS Implementation Targets

In general, we are to enable the three CAS components:

• Policy Management Module (Policy Modelling in CAS UI)

o Creation and Management of policies and related rules

o Selection of a policy, i.e. a set of rules, to be audited for compliance

o Selection of objects to be assessed

• Compliance Auditing Module (CAS Audit Manager in CAS UI)

o Auditing: Issue the ComplianceAuditRequest (rules, objects)

In the MVP we will cover only the special case of one policy and one object.

We will assess the handling of a job of ComplianceAuditRequests for a set of n

rules and m object instances (CAS module). This will include

▪ Generation of requests for PEP

▪ Bookkeeping of requests(rule, object instance) and result from PEP

• Request Decision on rule, subject, object

• Get the decision

• Reporting Module (in CAS UI)

o Generate report out of a list of requests and according to results

o Store report, publish report identifier

o Visualize Report in readable format

Page |

47




5.1.2 CAS Implementation Plan

The implementation plan for the CAS components is outlined below. Table 6 illustrates the

state of planning the timeline for the implementation until M18.

CAS Policy Manager

As described in section 2.4 the MVP will start with 5 policies, which shall be applied in the use

case pilots according to their requirements using the existing features of the PaaSword tool.

The data sources, i.e. the use case CMDBs in the first step, will be defined in collaboration with

the use cases following the descriptions in deliverable D2.3 [D2.3]. A SecureIoT-specific CMDB

format for CAS needs to be aligned with the use cases during the integration of the CAS by the

use cases.

In subsequent iterations it will be assessed, if further data may be provided utilizing the SecureIoT

data collection and analytics. These policies are closely related to the NIS directive, the GDPR and

the ISO27001. A method for modelling further policies will be outlined within this task. The

implementation of policies, which are modelled this way, within the CAS Policy Management

component will be outlined. Moreover, the upload of general policies and rules based on XACML

to the modelling tool shall be enabled.

The implementation of policy modelling is led by FUJITSU and supported by UBITECH and

aligned with related work packages WP3, WP4 and WP6.

CAS User Interface

The PaaSword User Interface shall be adapted to the requirements of the CAS. This task

includes the adaptation of the current UI to the new modules and functionalities of SecureIoT.

Among these features are the selection of the policies to be applied and of the objects and

attributes of the target system.

In the MVP the objects will be added manually by the use cases using the UI. In a later iteration

the automated import of a list of object instances (to be aligned with use cases on CMDB

format) shall be assessed.

The implementation of the user interface is led by UBITECH.

CAS Audit Manager

The CAS audit manager is the component, which will issue the ComplianceAuditRequest to the

PEP. The MVP will audit one policy related to one object instance. In a later stage of the

implementation auditing compliance to a policy per list of object instances will be assessed.

Page |

48




Within the current implementation of the PaaSword tool the four states of ABAC – “Allow”,

“Deny”, “Undefined”, “Not Applicable” – are collapsed to “Allow” and “Deny”. For the CAS

purpose. It is preferred to unbundle all four states as they give additional relevant information.

Thus, it will be checked, how this unbundling may be achieved.

Moreover, the input and output of the ComplianceAuditRequest, i.e. policy, object and result)

shall be connected with the CAS Reporting module by the CAS Audit Manager by an identifier

which shall be returned to the CAS UI.

The implementation of the CAS Audit Manager, being a transversal component, will be

extended from the PaaS Tool supporting the requirements identified previously. The

modification of the internal functionality will be performed by UBITECH and supported by

SiLo, Atos and Fujitsu as necessary linked to the other components they work with.

CAS Reporting Module

The CAS Report Module needs to be linked to the CAS Audit Module as this provides the audit

information. The report shall include information on the rule, object and result. It will be stored

as an XML file in a SecureIoT database. This file may be accessed in the CAS user interface using

the identifier provided by the CAS Audit Module. The XML file may be transformed by an XSLT

transformation provided by the user according to its needs and specifications.

The implementation of the CAS Report Module is led by ATOS.

SecureIoT Handlers

The specific sources, i.e. CMDBs and database schemes according to the specified set of policies

need to be defined. Considering the further iterations of the CAS implementation the

connection with other artefacts of SecureIoT will be assessed.

The implementation of the SecureIoT handlers is led by SiLO

Table 6 illustrates the development timeline for the 1st prototype and its integration into the

use cases.

Page |

49




Table 6 Implementation of 1st Prototype - Timeline

Sprint Month Goals Partners

Sprint #1 M14 • Align with use cases on policies, rules and CMDB

• ABC

FUJITSU XYZ

Sprint #2 M15 • Specification of 1st set policies, rules, data for compliance audit evaluation

• Define CMDB structure with the use cases

• Initial User Interface adaptations (e.g Reporting, Menu restructuring etc.)

• Initial design of the reporting manager (search, select, view, etc.) and integration with CAS user interface

FUJITSU FUJITSU UBITECH ATOS

Sprint #3 M16 • Description of 1st set of rules in XACML available

• Update models based on CMDB structure and use case needs

• Definition of output coming from the assessment (information obtained, type, etc.); integration with SecureIoT data storage

• Exemplary handlers available

FUJITSU UBITECH ATOS SiLO

Sprint #5 M17 • Testing and extension of functionalities

• Handlers available and tested

ATOS SiLO

Sprint #6 M18 • Integration with use cases and 1st evaluations (e.g. Connected Cars)

ATOS

5.2 PaaSword tool system requirements and handling This section provides information on the technical requirements, code availability and installation

of the UBITECH’s PaaSword tool, which will be used in the initial implementation of the SecureIoT

CAS prototype. The tool will be integrated with the other components of the CAS as described in

its architecture and will support the functionalities via an API. So far, the functionalities offered

by the PaaSword tool to be integrated into the CAS are

Page |

50




• Create a policy using a policy modelling tool (the Policy Editor)

o The policy is XACML compliant

• Create a model using a modelling tool (the Model Editor)

• Perform validation of a system using several policies

• Return information of the validation/checking as an initial report

5.2.1 Code and Binaries availability

The Compliance Audit component is offered at the SecureIoT GitLab repository. The repository is

named ComplianceAuditService and is available at:

https://gitlab.atosresearch.eu/secureiot/complianceauditservice. The latest version of the

components is under the “develop” branch.

The repository is organized, as the other services of SecureIoT, following a common

infrastructure in order to facilitate the work in the project:

• core: provides the core modules of the Compliance Audit Service

• utils: provides utilities and documents related to the Compliance Audit Service

5.2.2 System Requirements

We plan to provide the development of the Compliance Audit component using containers for

facilitating its deployment and use and Maven for project management. This is supported as well

for other services of SecureIoT, which facilitates the integration between components and their

exchange of information. We initially plan to make the prototype to run on Windows and Linux,

following with other O.S. and devices after analysing its fulfilment in the next phases of

development.

https://gitlab.atosresearch.eu/secureiot/complianceauditservice

Page |

51




6 Continuous integration (CI), testing (CT) and

deployment (CD) strategy The CAS follows the SecureIoT continuous integration, testing and deployment methodology.

This way, it will facilitate greatly the usage, development and integration of the CAS with other

components of the project (which are shown in previous sections).

SecureIoT provides a specific methodology for development, testing and integration in T5.5

(Continuous integration and configuration of SECaaS services), which aim to assure the high-

quality and industrial readiness of the services at the end of the project, minimize the impact and

difficulties of the integration of the output of SecureIoT with existing systems and promote and

enforce a common and consolidated methodology and approach.

More information about the SecureIoT process and methodology we plan to follow for the

development and testing of the Compliance and Assurance Service can be found in Section 6 of

D5.1 “IoT Risk Assessment and Mitigation as a Service. First version”.

Page |

52




7 Conclusions This deliverable has specified the Compliance Auditing Service functionalities of the SecureIoT

platform. Moreover, it has specified the ways in which the Compliance Auditing Service

components of the project are integrated with other modules of the SecureIoT platform, fully in-

line with the SecureIoT architecture. The specifications include also details about the APIs for

accessing the compliance auditing functionalities.

From a practical perspective, the compliance auditing service of the project provides the means

for assuring compliance and identifying potential incompliances of an IoT system. It also

facilitates the identification and implementation of relevant mitigation actions.

Key to the operation of the Compliance Auditing Service is its proper integration with the policy

management services of the project, given that these services drive the modelling of policies

against which compliance shall be audited. As part of the present demonstrator this is in its early

stages at the level of a proof-of-concept and based on the PaaSword tool of an earlier project,

which we plan to extend to cover the needs and requirements of SecureIoT with new

functionalities and properties. The plan for releasing updated versions of this deliverable

(including updated and enhanced demonstrators) involves the integration of this tool with more

advanced versions of the policy management, data collection, e.g. the CMDBs, of the project. To

this end, SecureIoT has implemented and put in place a continuous integration methodology that

emphasizes frequent integration and delivery of the risk assessment component of the project.

Overall, the present deliverable represents significant progress in the detailed specification of

the Compliance Auditing Services of the project, including relevant functional specifications and

APIs. It is accompanied by an initial demonstrator, which will be however fine-tuned as part of

subsequent versions. The latter will be reflected in deliverables D5.5 and D5.6 of the project,

which will be enhanced and more advanced versions of the present deliverable.

Page |

53




References D2.2 Neises, J.; Walloschke, T..; et al.: “Analysis of Stakeholders’ Requirements”,

SecureIoT H2020-IoT03-2017 - RIA Project, May 2018

D2.3 Walloschke, T.; Neises, J.; et al.: “IoT Security and Privacy Models”, SecureIoT H2020-IoT03-2017 - RIA Project, August 2018

D2.4 Soldatos, J.; Efremidis, S.; et al.: “D2.4: Architecture and Technical Specifications”, SecureIoT H2020-IoT03-2017 - RIA Project, September 2018

D4.6 Neises, J., Walloschke, T.; et al.: “Cross-Platform Security Support – 1st Version”, SecureIoT H2020-IoT03-2017 - RIA Project, November 2018

D5.7 Menesidou, S.; Angouras, G.; Panetelopoulos, S.; Calvo, D.: “IoT Developers Support as a Service. First version”, SecureIoT H2020-IoT03-2017 - RIA Project, December 2018

D6.1 Kyriazakos, S.; et al.: “Detailed Specification of Usage Scenarios and Planning of Validation Activities - First version”; SecureIoT H2020-IoT03-2017 - RIA Project, September 2018

Fowler 18 Fowler, M.: “Microservices”, 2014. (Accessed: 19- Dec- 2018): https://martinfowler.com/articles/microservices.html.

I40 Adolphs, P.; Auer, S.; Bedenbender, H.; Billmann, M.; Hankel, M.; Heidel, R.; Hoffmeister, M.; Huhle, H.; Jochem, M.; Kiele-Dunsche, M.; Koschnick, G.; Koziolek, H.; Linke, L.; Pichler, R.; Schewe, F.; Schneider, K.; Waser, B.: „ Working Paper - Structure of the Administration Shell Continuation of the Development of the Reference Model for the Industrie 4.0 Component”, April 2016, https://www.plattform-i40.de/I40/Redaktion/EN/Downloads/Publikation/structure-of-the-administration-shell.pdf?__blob=publicationFile&v=7

Kruchten 95 Kruchten, P.: “Architectural Blueprints - The “4+1” View Model of Software Architecture”, Paper published in IEEE Software 12, November 1995, pp. 42-50

MKGC 08 http://www.mkgcglobal.com/services-regulatory-compliance.shtml

PaaSword_D1.3 Verginadis, Y.; Patiniotakis, I.; Mentzas, G.: "Policies Enforcement Middleware Mechanisms – Early Release", PaaSword H2020-644814, July 2016

Schmohl08 Schmohl, R., Baumgarten, U., Context-aware Computing: A Survey Preparing a Generalized Approach” (2008), https://mediatum.ub.tum.de/doc/1115382/1115382.pdf

XACML 17 OASIS, "eXtensible Access Control Markup Language (XACML) Version 3.0”, 2017.

https://martinfowler.com/articles/microservices.html

https://www.plattform-i40.de/I40/Redaktion/EN/Downloads/Publikation/structure-of-the-administration-shell.pdf?__blob=publicationFile&v=7



http://www.mkgcglobal.com/services-regulatory-compliance.shtml

https://mediatum.ub.tum.de/doc/1115382/1115382.pdf

Date post:	03-Oct-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

DELIVERABLE - SECUREIoT Project

Documents