Secure Cloud-Edge Deployments, with Trust

by   Antonio Brogi, et al.
University of Pisa

Assessing the security level of IoT applications to be deployed to heterogeneous Cloud-Edge infrastructures operated by different providers is a non-trivial task. In this article, we propose a methodology that permits to express security requirements for IoT applications, as well as infrastructure security capabilities, in a simple and declarative manner, and to automatically get a probabilistic and explainable assessment of the security level of the possible application deployments. The methodology also considers the impact of trust relations among different stakeholders using or managing Cloud-Edge infrastructures. A lifelike example is used to showcase the prototyped implementation of the methodology.



There are no comments yet.



Green Application Placement in the Cloud-IoT Continuum

Green software engineering aims at reducing the environmental impact due...

Hardware-Enforced Integrity and Provenance for Distributed Code Deployments

Deployed microservices must adhere to a multitude of application-level s...

Pilot-Edge: Distributed Resource Management Along the Edge-to-Cloud Continuum

Many science and industry IoT applications necessitate data processing a...

Reproducible Performance Optimization of Complex Applications on the Edge-to-Cloud Continuum

In more and more application areas, we are witnessing the emergence of c...

A Brain-Inspired Trust Management Model to Assure Security in a Cloud based IoT Framework for Neuroscience Applications

Rapid popularity of Internet of Things (IoT) and cloud computing permits...

An Interposer-Based Root of Trust: Seize the Opportunity for Secure System-Level Integration of Untrusted Chiplets

Leveraging 2.5D interposer technology, we advocate the integration of un...

Performance Analysis of Zero-Trust multi-cloud

Zero Trust security model permits to secure cloud native applications wh...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Enforcing Quality-of-Service (QoS) requirements in the deployment of modern Internet-of-Things (IoT) software systems is a non-trivial – yet necessary – task to accomplish. Indeed, such systems are often developed in large, highly distributed, multi-service architectures, which are to be deployed to complex, heterogeneous and highly distributed infrastructures, spanning the Cloud-IoT continuum. Cloud-Edge computing cloudedgecomputing extends Cloud computing towards the edge of the Internet to better support latency-sensitive and bandwidth-hungry IoT applications by mapping each of their service functionalities (e.g., device management, telemetry ingestion, processing and storage, status and notification, multi-level analytics and data visualisation familiar2015iot) wherever it is best-placed to suitably meet all the application (hardware, software and QoS) requirements book; bonsai.

Various works (e.g., 004; 101; 024; 011; 012; summersoc) have tackled the problem of determining “optimal” placements (and management) of application services, mainly taking into account resource usage, deployment costs, network QoS (i.e., latency, response time, bandwidth), and energy consumption. Considering these aspects all together is of primary importance in Cloud-Edge scenarios, where many life-critical (e.g., e-health, autonomous vehicles) or mission-critical (e.g., drone packet deliveries, smart farming) application verticals can significantly suffer from degradation due to bad resource allocation or insufficient Internet connectivity. Analogously, their management might aim at reducing operational costs, due to power consumption or to resource leasing, so to increase their profits.

However, to the best of our knowledge no approach has been proposed that accounts for the security requirements of the application to be deployed and matches them to the security capabilities available at different infrastructure nodes. Security of information systems is an intrinsically complex problem, which requires reasoning about a system model by analysing its security properties and their effectiveness against potential attacks, and accounting for trust relations among all different involved stakeholders (e.g., infrastructure and application operators). In addition, any methodology for optimal service placement that accounts for security, should in principle enable decision-makers to understand why a certain deployment can be considered the optimal one, i.e. the provided recommendations should be explainable

. Explainable artificial intelligence (XAI) techniques are getting more attention from the security community since they can provide a concise explanation (

proof) of the query results vigano2018explainable. In the case of determining secure and trustworthy deployments of an application, for instance, XAI aims at answering questions like: Why is this deployment more secure than this other? Why and how are they secure?

As an extension to the Cloud, Cloud-Edge will share with it many security threats, while including its new peculiar ones. On the one hand, Cloud-Edge will increase the number of security enforcement points by allowing local processing of private data closer to the IoT sources. On the other hand, new infrastructures will have to face brand new threats for what concerns the physical vulnerability of devices. Indeed, application deployments to Cloud-Edge infrastructures will include accessible (Edge or IoT) devices that may be easily hacked, stolen or broken by malicious users ni2017securing; ambrosin2016sana. Last but not least, as Cloud-Edge application deployments will likely span various service providers - some of which may be not (fully) trustworthy - trust must be considered when deciding where to place application services. In Cloud-Edge scenarios, where part of the application could be deployed to opportunistic infrastructures (e.g., crowd-computing, ad-hoc networks garcia), trust models

are needed to estimate trust levels towards unknown providers, aggregating the opinions that trusted providers declare about the unknown ones.

All these considered, the move of utility computing towards the edge of the network – and in continuity with existing Clouds – calls for new quantitative and explainable methodologies that permit to assess the security level of distributed multi-service IoT applications. Such methodologies should take into account application requirements, security countermeasures featured by the Cloud-Edge infrastructure, and trust relations in place among different stakeholders that manage or use Cloud-Edge infrastructures.

In this article, we propose a first step towards probabilistic reasoning methodologies. Our proposal, SecFog, is based on a simple on a simple declarative approach. It helps application operators in Cloud-Edge scenarios in determining the most secure application deployments by reducing manual tuning and by considering specific application requirements, infrastructure capabilities and trust. The methodology has been prototyped in the ProbLog2 language problog07 and, as we will show, the prototype can be used together with existing approaches that solve the problem of mapping IoT application services to Cloud-Edge infrastructures according to requirements other than security and trust.

The rest of this article is organised as follows. After briefly introducing the ProbLog2 language (Section 2), needed to understand the proposed solution, we detail the SecFog methodology and its implementation, while showing how it can be used on simple examples (Section 3). Afterwards, we describe a larger lifelike example of secure application deployment and illustrate how the SecFog prototype can be used along with other existing tools for application placement in Cloud-Edge scenarios (Section 4). Finally, after discussing related work (Section 5), we draw some conclusions and point to some directions for future work (Section 6).

2 Background: The Problog2 Language

Being SecFog

 a declarative methodology based on probabilistic reasoning about declared infrastructure capabilities and security requirements, it was natural to prototype it by relying on probabilistic logic programming. To implement both the model and the matching strategy we used a language called

ProbLog2 problog15. ProbLog2 is a Python package that permits writing logic programs that encode complex interactions between sets of heterogeneous components, capturing the inherent uncertainties that are present in real-life situations.


 programs are logic programs in which some of the facts are annotated with (their) probabilities.

ProbLog2 facts, such as [fontsize=] p::f. represent a statement f which is true with probability p222A fact declared simply as f. is assumed to be true with probability 1.. ProbLog2 rules, like [fontsize=] r :- c1, … , cn. represent a property r inferred when c1 cn holds. Variable terms start with upper-case letters, constant terms with lower-case letters. Semicolon ; can be used to express OR conditions, i.e., r :- c1; ... ; cn. corresponds to c1 cn.

Each program defines a probability distribution over logic programs where a fact

p::f. is considered true with probability p and false with probability . The ProbLog2 engine problog07 determines the success probability of a query q as the probability that q has a proof, given the distribution over logic programs. The engine also permits to automatically obtain the graphical representation of the AND-OR tree associated with the ground program that it used to answer a given query. This explains how the results are obtained. Finally, the ProbLog2 engine can be used in explanation mode to get, for each query, the list of all mutually exclusive proofs that lead to infer it.

3 Methodology and Implementation

3.1 Overview

Figure 1 offers an overview of the SecFog ingredients that will be thoroughly described in this section. First of all, SecFog considers two roles for its users:

  • infrastructure operators, in charge of managing targeted Cloud-Edge nodes, and providing a description of the provisioned infrastructure capabilities to their users, and

  • application operators, in charge of designing and managing application deployments by specifying their requirements (e.g., hardware, software, QoS), by monitoring deployment performance, and by re-distributing or re-configuring application services when needed.

Figure 1: Bird’s-eye view of SecFog.

Cloud-Edge stakeholders333Naturally, one stakeholder can play more than one role at a time and there can be more stakeholders playing the same role arcangeli. For instance, an infrastructure operator can provide IoT, Edge, or Cloud infrastructures to its customers, whilst managing applications and services over the very same infrastructure, or an application operator can act as an infrastructure provider when sharing her home router as an Edge capability for application deployment. might want to look for secure deployments of their applications and require explanations about such security assessment.

As per the SecFog input, infrastructure operators must provide a Node Descriptor (ND) for each of their managed nodes, declaring all the available security capabilities (relying on the same common vocabulary of application operators) and their estimated effectiveness against attacks. These constitute the description of all Security Capabilities in the Cloud-Edge system.

On the other hand, application operators must provide a description of their Application and specify the Security Requirements of each application service (SR), in terms of the common vocabulary or, possibly, by means of a custom set of Security Policies declared over that vocabulary. The application operator can also possibly specify a complete or partial application deployment in case she wants to assess the security level of deployments under such constraints.

Finally, each stakeholder – infrastructure or application operator – can declare a trust degree towards any other stakeholder, as a set of opinions. Such weighted relations contribute to a Trust Network that is input to SecFog.

The SecFog prototype, given all Security Requirements, Security Capabilities and a Trust Network, features:

  1. a Generate & Test Strategy to determine secure deployments by matching application requirements to infrastructure security capabilities (also considering their effectiveness against attacks), and

  2. a Trust Model that is capable of completing the Trust Network, exploiting transitivity of trust chains and relying on the opinions declared by all stakeholders.

The output of SecFog is a Security Assessment of all eligible deployments determined through the exploration of the search space. For each candidate deployment, the prototype obtains its security level by multiplying the effectiveness of all exploited security capabilities, suitably weighted by trust degrees towards the operator providing them. Last but not least, each output comes with a proof that explains in a graphical, human-readable format how such result was obtained.

In the next paragraphs, we detail each of the ingredients we mentioned and, for each, we give the implementation444The ProbLog2 code of SecFog prototype and of the examples of Section 3 and 4 is publicly available at as well as concrete, executable examples within our ProbLog2 prototype.

3.2 Security in Cloud-Edge Computing

In Cloud-Edge computing infrastructures, end-to-end security must cover everything between the Cloud and the IoT. Naturally, the security requirements of multi-service applications will highly vary depending on business cases, target markets and vertical use cases as well as on the functionality offered by different components. For instance, a database storing video footage from domestic CCTV will probably require more security countermeasures to be active with respect to a database collecting outdoor temperature data from a city or neighbourhood. The OpenFog Consortium openfog highlighted the need for new Cloud-Edge computing platforms to guarantee privacy, anonymity, integrity, trust, attestation, verification and measurement. Whilst security control frameworks exist for Cloud computing scenarios (e.g., the EU Cloud SLA Standardisation Guidelines cloudslaguidelines or the ISO/IEC 19086), to the best of our knowledge, no standard exists yet that defines security objectives for Cloud-Edge application deployments. Based on recent surveys about security aspects in the novel Cloud-Edge landscapes (i.e., mezni2018security, mukherjee2017security, ni2017securing), we devised a simple example of taxonomy555The example taxonomy can be changed or extended so to include new security categories and third-level security capabilities as soon as normative security frameworks will get established in Cloud-Edge scenarios. (Figure 2) of security capabilities that can be offered by Cloud and Edge nodes and therefore used for reasoning on the security levels of given IoT application deployments.







Access Logs


Host IDS

Process Isolation

Permission Model

Resource Usage Monitoring

Restore Points

User Data Isolation



IoT Data Encryption

Node Isolation Mechanims

Network IDS

Public Key Cryptography

Wireless Security


Encrypted Storage

Obfuscated Storage

Access Control

Anti-tampering Capabilities

Figure 2: An example of taxonomy of security capabilities in Cloud-Edge.

Security capabilities that are common with the Cloud might assume renewed importance in Cloud-Edge scenarios, due to the limited resources of the devices installed closer to the edge of the Internet. For instance, guaranteeing physical integrity of and user data isolation at an access point with Edge capabilities might be very difficult. Similarly, the possibility to encrypt or obfuscate data at Edge nodes, along with encrypted IoT communication and physical anti-tampering machinery, will be key to protect those application deployments that need data privacy assurance.

In what follows, when describing the SecFog methodology, we will assume that all involved parties (viz., application and infrastructure operators) share the vocabulary of the example taxonomy666Factually, different operators can employ different vocabularies and then exploit mediation mediation mechanisms, capable of translating one into another. in Figure 2.

3.3 Security Capabilities: the Infrastructure

The Infrastructure can be simply described by infrastructure operators as a set of facts declaring a node and its security capabilities, weighted by the probability that each capability can resist against malicious attacks. Such probability represents a measure of the effectiveness of the considered security countermeasure. Figure 3 lists the vocabulary of ProbLog2 facts that can be used to describe node capabilities in terms of the taxonomy of Figure 2.

[fontsize=, xleftmargin=-1.8cm] access_logs(N). authentication(N). host_ids(N). process_isolation(N). permission_model(N). resource_monitoring(N). restore_points(N). user_data_isolation(N).

certificates(N). iot_data_encryption(N). firewall(N). node_isolation_mechanism(N). network_ids(N). public_key_cryptography(N). wireless_security(N). [fontsize=, xleftmargin=-1.5cm] backup(N). encrypted_storage(N). obfuscated_storage(N).

access_control(N). anti_tampering(N).


Figure 3: Example Cloud-Edge security capabilities in ProbLog2.

Example. A cloud node identified as cloud1 and managed by a certain infrastructure operator cloudOp1 can be specified in SecFog as: [fontsize=] node(cloud1, cloudOp1). In case it features some form of firewall that is guaranteed to resist an attack (e.g., network traffic flood, packet fragmentation) with a likelihood of , the previous line can be simply followed by: [fontsize=] 0.9999::firewall(cloud1). Similarly, an edge node edge3 managed by an operator appOp42 and featuring a broken wireless security system like WEP and an encrypted storage considered effective, is declared as: [fontsize=] node(edge3, appOp42). 0.01::wireless_security(edge3). 0.99::encrypted_storage(edge3). Overall, this type of fact declarations can be used to specify the Node Descriptors by infrastructure operators, as sketched in Figure 1.

3.4 Security Requirements: the Application

As aforementioned, SecFog enables application operators to specify an application along with the services that compose it. Based on the same common vocabulary of Figure 3.2, application operators can then define (non-trivial) custom Security Policies that can be used to declare the Security Requirements of each service composing the application. Custom security policies can be either existing ones, inferred from the presence of certain node capabilities, or they can be autonomously specified/enriched by the application operators, depending on business-related considerations.

Example. First, an application for smartfarming consisting of three services s1, s2 and s3 can be easily specified as: [fontsize=] app(smartfarming, [s1, s2, s3]). Then, the application operator can decide that a node offering backup capabilities together with encrypted_storage or obfuscated_storage can be considered a secureStorage provider. The custom security policy described above can be specified as: [fontsize=] secureStorage(N) :- backup(N), (encrypted_storage(N); obfuscated_storage(N)). A different stakeholder might also require the availability of certificates at the node featuring secure storage and re-define the policy as: [fontsize=] secureStorage(N) :- backup(N), certificate(N), (encrypted_storage(N); obfuscated_storage(N)). The Security Requirements for service s2 of smartfarming, which needs both secureStorage (as previously declared) and resource_monitoring capabilities can then be defined as: [fontsize=] securityRequirements(s2, N) :- secureStorage(N), resource_monitoring(N). Overall, this permits to application operators to quickly and simply specify all the Security Requirements of their software systems by exploiting combinations of custom Security Policies and basic security capabilities.

3.5 Generate & Test Strategy

The ProbLog2 listing in Figure 4 defines the declarative Generate and Test strategy of SecFog. This strategy exploits a knowledge base of facts and rules that defines a Cloud-Edge infrastructure and its Security Capabilities along with an application and its Security Requirements, declared as we have seen in the previous section. It is worth noting that SecFog strategy can be used both (a) to determine (or complete) secure application deployments, assessing their security level, and (b) to assess the security level guaranteed by complete input deployments, which may be already used by the application operators. In both cases (a) and (b), the quantitative security assessment considers the available security capabilities and their declared effectiveness against attacks.

The rule for secFog(OpA, A, D) takes as input an application operator OpA, the application A she is in charge of deploying and a (possibly empty, or partial) deployment D of such application. First, it checks that A has been declared as an application app(A, L) (line 2), then it evaluates the predicate deployment(OpA, L, D) (line 3). Recursively, for each component C in the list of the application components, it checks whether it (can be) has been deployed to a node N (line 7) that can satisfy the security requirements declared by the application operator for C, i.e. whether securityRequirements(C,N) holds (line 8).

[fontsize=] secFog(OpA, A, D) :- (1) app(A, L), (2) deployment(OpA, L, D). (3) (4) deployment(_,[],[]). (5) deployment(OpA,[C—Cs],[d(C,N,OpN)—D]) :- (6) node(N,OpN), (7) securityRequirements(C,N), (8) deployment(OpA,Cs,D). (9)

Figure 4: The Generate & Test strategy of SecFog.

Example. Considering a single-service application, managing the weather data of a municipality, and an infrastructure composed of two (one Cloud and one Edge) nodes declared as follows: [fontsize=] app(weatherApp, [weatherMonitor]). securityRequirements(weatherMonitor, N) :- (anti_tampering(N); access_control(N)), (wireless_security(N); iot_data_encryption(N)).

node(cloud, cloudOp). 0.99::anti_tampering(cloud). 0.99::access_control(cloud). 0.99::iot_data_encryption(cloud).

node(edge, edgeOp). 0.8::anti_tampering(edge). 0.9::wireless_security(edge). 0.9::iot_data_encryption(edge). Running the query [fontsize=] query(secFog(appOp,weatherApp,D)). outputs the resulting secure deployments for the weatherApp, along with a value in the range that represents their assessed security level (based on the declared effectiveness of infrastructure capabilities that are exploited by each possible deployment): [fontsize=] secFog(appOp,weatherApp,[d(weatherMonitor,cloud,cloudOp)]): 0.989901 secFog(appOp,weatherApp,[d(weatherMonitor,edge,edgeOp)]): 0.792 The result, highlighting the deployment to the Cloud as the most secure solution, can be explained by looking at Figure 5, which graphically depicts the AND-OR trees of the two ground programs that lead to the output results. Such graphical explanations can be obtained automatically, by using ProbLog2 in ground mode777 Note that the ProbLog2 engine performs an AND-OR graph search over the ground program to determine the query results. For instance, the value associated with securityRequirements(weatherMonitor,cloud) is obtained as:


As for the AND-OR graph of the ground program, also this proof can be obtained automatically, by using ProbLog2 in explain mode888

Figure 5: Graphical ground program of the weatherApp example.

3.6 Trust Model

The pervasive and highly distributed nature of new Cloud-Edge deployments imposes to deal not only with the effectiveness of the adopted security capabilities but also with the trust degrees towards various, potentially unknown, infrastructure operators. In this section, we show how it is possible to extend the prototype SecFog described up to now so to include a simple, yet powerful, trust model.

We model direct trust relations between two stakeholders and as the probability that can trust , based on an aggregate of all previous interactions they had. The proposed trust model combines such direct trust opinions from different stakeholders and completes the (possibly partial) trust network input to SecFog with missing indirect trust relations. Specifically, our model considers trust relations as transitive and explores network paths while aggregating the opinions (as declared by application and infrastructure operators).

Opinions along paths are combined via multiplication, opinions across paths are combined via addition. Intuitively, this causes opinions to deteriorate along paths and, when multiple opinions are available, to improve, by weighting more those paths that are more trustworthy trust06.

Figure 6 lists the ProbLog2 rules we used to define our model which is a (probabilistic) transitive closure of the trust network input to SecFog. Reasonably, we assume that each stakeholder fully trust herself (line 1). Then, stakeholder A trusts B either directly (lines 3–4), or through a third party C that directly or indirectly trusts B (lines 5–7).

[fontsize=] trusts(X,X). (1) (2) trusts2(A,B) :- (3) trusts(A,B). (4) trusts2(A,B) :- (5) trusts(A,C), (6) trusts2(C,B). (7)

Figure 6: Trust model of SecFog.

Figure 7 shows how to include the trust model in the Generate and Test strategy of Figure 4, by simply adding the condition trusts2(OpA, OpN).

[fontsize=] deployment(_,[],[]). (1) deployment(OpA,[C—Cs],[d(C,N,OpN)—D]) :- (2) node(N,OpN), (3) securityRequirements(C,N), (4) trusts2(OpA, OpN), (5) deployment(OpA,Cs,D). (6)

Figure 7: The deployment/3 predicate with trust.

We first show an example of the trust model alone, then we apply it to the example of Section 3.5 to illustrate its usage within SecFog.

Example. Consider the trust network of Figure 8 and suppose to be interested in the (indirect) trust relation between srcOp and dstOp.

Figure 8: A trust network.

It can be simply computed with the SecFog trust model in ProbLog2 as: [fontsize=] 0.9::trusts(srcOp, aOp). 0.2::trusts(srcOp, bOp).

0.1::trusts(aOp, dstOp).

0.8::trusts(bOp, dstOp).

query(trusts2(srcOp, dstOp)). which returns [fontsize=] trusts2(srcOp,dstOp): 0.2356 as a result. Also in the case of the trust model, it is possible to obtain the ground program which explains how the final result was computed (Figure 9).

Figure 9: Graphical ground program of the trusts2 example.

From this simple example, it is clear that, in the proposed trust model, the contribution of trust relations deteriorates along paths and that all possible paths give their contribution to the output result. Indeed, the final result corresponds to the likelihood that it is possible to establish a trust path from srcOp to dstOp over the considered trust network.

Example. We now retake the example of Section 3.5 and we solve it again by also considering the trust network of Figure 10.

Figure 10: Example trust network among Cloud-Edge operators.

The network is defined by the direct trust relations, which are declared by the different operators as: [fontsize=] .9::trusts(appOp, edgeOp). .9::trusts(appOp, ispOp).

.7::trusts(edgeOp, cloudOp1). .8::trusts(edgeOp, cloudOp2).

.8::trusts(cloudOp1, cloudOp2).

.2::trusts(cloudOp2, cloudOp).

.8::trusts(ispOp, cloudOp). .6::trusts(ispOp, edgeOp). The same query of the previous example now leads to a different result: [fontsize=] secFog(appOp,weatherApp,[d(weatherMonitor,cloud,cloudOp)]): 0.76017935 secFog(appOp,weatherApp,[d(weatherMonitor,edge,edgeOp)]): 0.755568 When accounting for trust, both security levels decrease and the Cloud deployment does not outperform much the Edge deployment, as it was when considering only the effectiveness of security capabilities ( against ). Indeed, both the assessed security levels settle around . In situations like this one, the application operator might make her choice also considering other estimated non-functional parameters (e.g., cost, response time, resource usage).

In the next section, we exploit SecFog to analyse a lifelike example of IoT application deployment to Cloud-Edge infrastructure. We also make use of our FogTorch prototype ccisbrogiforti to select deployments that also meet hardware and software requirements of the example application.

4 Motivating Example

4.1 Infrastructure

Figure 11 shows the Cloud-Edge infrastructure – two Cloud data centres, three Edge nodes – to which a smart building application is to be deployed. For each node, the available security capabilities and their effectiveness against attacks999In Figure 11, when the effectiveness against attacks of a capability is not indicated we assume it is considered to be by the corresponding infrastructure provider.(as declared by the infrastructure operator) are listed in terms of the taxonomy of Figure 3.

Figure 11: Cloud-Edge infrastructure security capabilities.

Relying on such information, node descriptors can be easily expressed by each infrastructure operator through listing ground facts, as discussed in Section 3.3. For instance, edge1 directly operated by the application operator appOp is described as [fontsize=] node(edge1,appOp). 0.9::authentication(edge1). resource_monitoring(edge1). iot_data_encryption(edge1). 0.95::firewall(edge1). public_key_cryptography(edge1). 0.95::wireless_security(edge1). obfuscated_storage(edge1). All the Node Descriptors assembled following this template form the description of the security capabilities available in the infrastructure.

4.2 Application

We retake the application example of ccisbrogiforti and we extend it with security requirements. Consider a simple multi-service IoT application (Figure 12) that manages fire alarm, heating and A/C systems, interior lighting, and security cameras of a smart building. The application consists of three microservices:

  • IoTController, interacting with the connected cyber-physical systems,

  • DataStorage

    , storing all sensed information for future use and employing machine learning techniques to update sense-act rules at the

    IoTController so to optimise heating and lighting management based on previous experience and/or on people behaviour, and

  • Dashboard, aggregating and visualising collected data and videos, as well as allowing users to interact with the system.

Figure 12: Multi-service IoT application.

Each microservice represents an independently deployable component of the application microservices and has its own security requirements.

Particularly, application operators defined the following security requirements:

  • IoTController requires physical_security guarantees (i.e., access_control anti_tampering) so to avoid that temporarily stored data can be physically stolen from the deployment node,

  • DataStorage requires secure_storage (viz., backup (obfuscated_storage encrypted_storage)), the availability of access_logs, a network_ids in place to prevent distributed Denial of Service (dDoS) attacks, and

  • Dashboard requires a host_ids installed at the deployment node (e.g., an antivirus software) along with a resource_monitoring to prevent interactions with malicious software and to detect anomalous component behaviour.

Furthermore, the application requires guaranteed end-to-end encryption among all services (viz., all deployment nodes should feature public_key_cryptography) and that deployment nodes should feature an authentication mechanism.

The described application and security policies translate one-to-one to the following SecFog clauses, as discussed in Section 3.4: [fontsize=] app(smartbuilding, [iot_controller, data_storage, dashboard]).

securityRequirements(iot_controller, N) :- physical_security(N), public_key_cryptography(N), authentication(N).

securityRequirements(data_storage, N) :- secure_storage(N), access_logs(N), network_ids(N), public_key_cryptography(N), authentication(N).

securityRequirements(dashboard, N) :- host_ids(N), resource_monitoring(N), public_key_cryptography(N), authentication(N).

physical_security(N) :- anti_tampering(N); access_control(N).

secure_storage(N) :- backup(N), (encrypted_storage(N); obfuscated_storage(N)).

4.3 Trust Network

Finally, as discussed in Section 3.6, we consider the trust network of Figure 13, which can be defined as: [fontsize=] 0.9::trusts(appOp, edgeOp). 0.8::trusts(appOp, cloudOp2).

0.9::trusts(edgeOp, cloudOp2). 0.7::trusts(edgeOp, cloudOp1).

0.1::trusts(cloudOp1, cloudOp2).

0.8::trusts(cloudOp2, edgeOp). 0.5::trusts(cloudOp2, cloudOp1).

Figure 13: Trust network of the smartbuilding example.

Accounting for trust propagation, such network results in the following value of trust of appOp towards infrastructure providers: [fontsize=] trusts2(appOp,appOp): 1 trusts2(appOp,cloudOp1): 0.8247 trusts2(appOp,cloudOp2): 0.96326 trusts2(appOp,edgeOp): 0.964

4.4 Security Assessment

As discussed in Section 3.5, SecFog prototype can be used to find all deployments that satisfy the security requirements of the example application to the given infrastructure, by simply issuing the query:

[fontsize=] query(secFog(appOp, smartbuilding, D)).

As shown in Table 1, relying on ProbLog2 out-of-the-box algorithms, SecFog prototype returns answers to the query along with a value in that represents the aggregate security level of the inferred facts, i.e. the probability that a deployment can be considered secure according to both to the declared reliability of the infrastructure capabilities and to the trust degree of the application operator towards each exploited infrastructure operator.

Dep. ID IoTController DataStorage Dashboard Security
1 Cloud 1 Cloud 1 Cloud 1 0.82
2 Cloud 1 Cloud 1 Cloud 2 0.81
3 Cloud 1 Cloud 1 Edge 3 0.78
4 Cloud 1 Edge 3 Cloud 1 0.77
5 Cloud 1 Edge 3 Cloud 2 0.75
6 Cloud 1 Edge 3 Edge 3 0.75
7 Cloud 2 Cloud 1 Cloud 1 0.81
8 Cloud 2 Cloud 1 Cloud 2 0.81
9 Cloud 2 Cloud 1 Edge 3 0.77
10 Cloud 2 Edge 3 Cloud 1 0.75
11 Cloud 2 Edge 3 Cloud 2 0.89
12 Cloud 2 Edge 3 Edge 3 0.87
13 Edge 2 Cloud 1 Cloud 1 0.66
14 Edge 2 Cloud 1 Cloud 2 0.65
15 Edge 2 Cloud 1 Edge 3 0.63
16 Edge 2 Edge 3 Cloud 1 0.62
17 Edge 2 Edge 3 Cloud 2 0.72
18 Edge 2 Edge 3 Edge 3 0.72
19 Edge 3 Cloud 1 Cloud 1 0.80
20 Edge 3 Cloud 1 Cloud 2 0.78
21 Edge 3 Cloud 1 Edge 3 0.78
22 Edge 3 Edge 3 Cloud 1 0.77
23 Edge 3 Edge 3 Cloud 2 0.89
24 Edge 3 Edge 3 Edge 3 0.89
Table 1: Eligible deployments of the example application.

If the application operator is only considering security as a parameter to lead her search, she would try to maximise the obtained metric and, most probably, select one among 11, 12, 23, 24. However, security might need to be considered along with other parameters so to find a suitable trade-off among them.

In this regards, it is interesting to see how SecFog prototype can be used in synergy with other tools that perform multi-service application placement in Cloud-Edge scenarios. For instance, our FogTorch prototype book finds eligible deployments that guarantee software, hardware and network QoS requirements. For each deployment, it outputs the QoS-assurance (i.e., the likelihood it will meet network QoS requirements), an aggregate measure of Edge resource consumption, and an estimate of its monthly operational cost. It then employs a simple multi-objective optimisation to rank the deployments and to decide which are the better candidates.

For the smartbuilding example we are analysing, among the deployments of Table 1, FogTorch suggests only 13, 16 and 22 ccisbrogiforti. Naturally, with the aim of maximising security whilst considering all other requirements, the application operator would likely choose 22.

5 Related Work

Among the studies focussing on the placement of multi-service applications to Cloud nodes, very few approaches considered security aspects when determining eligible application deployments, mainly focussing on improving performance, resource usage and deployment cost kaur2017taxonomy; mezni2018security, or on identifying potential data integrity violations based on pre-defined risk patterns zoltan. Other existing research considered security mainly when treating the deployment of business processes to (federated) multi-Clouds (e.g., nacer2016obfuscating; goettelmann2014security; wen2017cost). Similar to our work, Luna et al. luna were among the first to propose a quantitative reasoning methodology to rank single Cloud providers based on their security SLAs, and with respect to a specific set of (user-weighted) security requirements. Recently, swarm intelligence techniques mezni2018security have been exploited to determine eligible deployments of composite Cloud applications, considering a risk assessment score based on node vulnerabilities. However, none of these works embedded a trust model to consider the trust relations and the opinions of the involved stakeholders when determining secure deployments.

Cloud-Edge computing introduces new challenges, mainly due to its pervasive geo-distribution and heterogeneity, need for QoS-awareness, dynamicity and support to interactions with the IoT, that were not thoroughly studied in previous works addressing the problem of application deployment to the Cloud icfecreview; recentreview. Among the first proposals investigating these new lines, 004 proposed a Cloud-Edge search algorithm as a first way to determine an eligible deployment of (multi-component) DAG applications to tree-like infrastructures. Their placement algorithm attempts the placement of services Edge-to-Cloud by considering hardware capacity only. An open-source simulator – iFogSim – has been released to test the proposed policy against Cloud-only deployments. Building on top of iFogSim, 021 refines tries to guarantee the application service delivery deadlines and to optimise computational resource exploitation. Also 032 used iFogSim to implement an algorithm for optimal online placement of application components, with respect to load balancing. Recently, exploiting iFogSim, 101 proposed a distributed search strategy to find the best service placement in Cloud-Edge infrastructures, which minimises the distance between the clients and the most requested services, based on request rates and available free resources. In our previous work, we also proposed a model and algorithms to determine eligible deployments of IoT applications to Fog infrastructures 011 based on hardware, software and network QoS requirements. Our prototype – FogTorch – implements those algorithms and permits to estimate the QoS-assurance, the resource consumption in the Fog layer 012 and the monthly deployment cost closer18 of the output eligible deployments. 062; 027

proposed (linearithmic) heuristic algorithms that attempt deployments prioritising placement of applications to devices that feature with less free resources.

From an alternative viewpoint, 001

gave a Mixed-Integer Non-Linear Programming (MINLP) formulation of the problem of placing application services so to satisfy end-to-end delay constraints. The problem is then solved by linearisation into a Mixed-Integer Linear Programming (MILP), showing potential improvements in latency, energy consumption and costs for routing and storage that the Cloud-Edge interplay might bring. Also

024 adopted an ILP formulation of the problem of allocating computation to Cloud and Edge nodes so to optimise time deadlines on application execution. A simple linear model for Cloud costs is also taken into account. Similar solutions were proposed, attempting to optimise various metrics such as access latency, resource usage, energy consumption or data migrations cost 034; 017; 095; 061; 002; 019. 107 described instead a fuzzy QoE extension of iFogSim – based on an ILP modelling of users expectation – which achieved improvements in network conditions and service QoS. Regrettably, none of the discussed ILP/MILP approaches came with the code to run the experiments. Conversely, 030 proposed a software platform to support optimal application placement in Cloud-Edge landscapes. Envisioning resource, bandwidth and response time constraints, they compare a Cloud-only, an Edge-only or a Cloud-to-Edge deployment policy. Additionally, the authors of 038 released an open-source extension of Apache Storm that performs service placement while improving the end-to-end application latency and the availability of deployed applications. Dynamic programming (e.g., 006

), genetic algorithms (e.g.,


) and deep learning (e.g.,

008) were exploited promisingly in some recent works. Overall, to the best of our knowledge, none of the previous work in the field of application placement included the possibility to look for secure deployments in Cloud-Edge scenarios, based on application requirements and infrastructure capabilities.

When it comes to trust models and trust management trustmanagementardagna, other works such as bistarelli2010semiring; bistarelli2008weighted employ (weighted) logic programming and consider networks of trust (and their closures) with values in the range to express trust relations. Also li2002design relies on logic programming to define a trust framework for role-based access policies. As in SecFog, such relations describe the belief of one stakeholder to trust another, based of the interactions they previously had. In line with other trust models ziegler2005propagation; twigg2003attack; trust06, we aggregate multiple trust paths, so consider as many opinions as possible when computing the final result. In the context of ad-hoc networks, much work was done to devise certification based trust models and protocols to spread trust opinions at runtime omar2012certification. Recently, certification-based schemes were proposed also for the Cloud scenario as in the works by Anisetti et al. anisetti2014certification; anisetti2017semi. However, none of the reviewed approaches combined the modelling of trust networks with a quantitative assessment on the effectiveness of the adopted security capabilities against attacks, as in SecFog. Overall, none of the approaches we reviewed proposed quantitative assessment methodologies of the security level of Cloud-Edge application deployments, capable of accounting for the effectiveness of the exploited security capabilities against attacks as well as for a trust model.

6 Concluding Remarks

In this paper, we proposed a declarative methodology, SecFog, which can be used to quantitatively assess the security level of multi-service application deployments to Cloud-Edge infrastructures. With a prototype implementation in ProbLog2, we have shown how SecFog helps application operators in determining secure deployments based on specific application requirements, available infrastructure capabilities, and considering trust degrees in different Edge and Cloud providers.

To the best of our knowledge, SecFog constitutes a first well-founded, efficient and explainable effort towards such direction. The well-foundedness and efficiency of SecFog are guaranteed by the state-of-the-art resolution algorithms implemented within the ProbLog2 engine. The possibility of explaining the obtained security assessment also derives from ProbLog2 functionalities that allow the users to obtain graphical ground programs and proofs for the results of their queries. The SecFog prototype can be fruitfully used with other tools for application deployment so to identify suitable trade-offs among the estimated security level and other deployment performance indicators (e.g., QoS-assurance, resource usage, monthly cost, energy consumption), as we have shown with our prototype FogTorch.

As our immediate future work, we plan to:

  • prototype a GUI to provide a user-friendly view of the recommended deployment(s), by suitably highlighting how the application security requirements are satisfied,

  • extend such GUI with a visual explanation of the reasons why a give deployment is not recommended by SecFog, and

  • engineer and integrate SecFog with FogTorch and show their applicability to actual use cases.

We also intend to:

  • enhance SecFog by embedding a more expressive and customisable trust model that can take into account confidence level towards the declared opinions, by combining it with existing strategies that have been used to quantify trust degrees (e.g., Bayesian or Dempster–Shafer theories as in weimanet) based on direct experience, possibly considering also the mobility of Edge nodes and IoT devices, and

  • enrich the current application model of SecFog so to be able to analyse the security of (probabilistic) information flows among the constituent services, by also defining pre-defined patterns (along the lines of tsankov2018security).

Acknowledgment This work has been partly supported by the project “DECLWARE: Declarative methodologies of application design and deployment” (PRA_2018_66) funded by the University of Pisa, Italy.