Toward security quantification of serverless computing

Ni, Kan; Mondal, Subrota Kumar; Kabir, H M Dipu; Tan, Tian; Dai, Hong-Ning

doi:10.1186/s13677-024-00703-y

Research
Open access
Published: 17 September 2024

Toward security quantification of serverless computing

Kan Ni¹^na1,
Subrota Kumar Mondal¹^na1,
H M Dipu Kabir^2,3,
Tian Tan¹ &
…
Hong-Ning Dai⁴

Journal of Cloud Computing volume 13, Article number: 140 (2024) Cite this article

380 Accesses
Metrics details

Abstract

Serverless computing is one of the recent compelling paradigms in cloud computing. Serverless computing can quickly run user applications and services regardless of the underlying server architecture. Despite the availability of several commercial and open-source serverless platforms, there are still some open issues and challenges to address. One of the key concerns in serverless computing platforms is security. Therefore, in this paper, we present a multi-layer abstract model of serverless computing for an security investigation. We conduct a quantitative analysis of security risks for each layer. We observe that the Attack Tree and Attack-Defense Tree methodologies are viable approaches in this regard. Consequently, we make use of the Attack Tree and the Attack-Defense Tree to quantify the security risks and countermeasures of serverless computing. We also propose a novel measure called the Relative Risk Matrix (RRM) to quantify the probability of attack success. Stakeholders including application developers, researchers, and cloud providers can potentially apply these findings and implications to better understand and further enhance the security of serverless computing.

Introduction

The serverless computing paradigm has received a lot of attention since its birth. Both the rise of the 5G and 6G era and the popularity of various edge devices make the industry and academia pay more and more attention to this new computing paradigm [1]. Serverless computing has gained popularity through the concept of Function-as-a-Service (FaaS), which requires a smaller domain to manage traditional Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). Enthusiastically, it allows developers to focus on the core security logic of the application, regardless of virtual machine (VM) or cloud server infrastructure. The advantages of cloud computing include the ease of sharing resources, autoscaling strategy, and on-demand use [2]. Serverless computing has taken cloud computing one step further by breaking down the units from resources into functions and containers, thereby allowing developers to focus only on the implementation of the specific function or service rather than the complexity of operations and maintenance for underlying servers and infrastructures. Serverless computing is favored by the industrial community and researchers because of its low latency, cost-effectiveness, pay-as-you-go, and autoscaling strategy, consequently offering huge benefits for some cloud computing services [3]. Before serverless computing, automatic scaling of cloud services was used to automatically configure the VM to reserve resources, but customers would still pay for that capacity even if it remains idle. By contrast, cloud service providers pay for idle resources in serverless computing. Customers who use the resources provided by serverless computing can pay according to the workload actually generated. In several mature commercial serverless computing platforms [4], customers can easily migrate their business from traditional cloud servers to serverless computing. Through serverless computing platforms, cloud service providers can better control resource utilization and improve infrastructure utilization. The ease of use of serverless computing is another incentive for users to migrate services. Amazon Web Services (AWS) [5], Google Cloud Platform (GCP) [6], and Microsoft Azure are aggressively expanding their serverless computing platforms and achieving high-profit growth [7]. The community also has several open-source frameworks such as OpenFaaS [7,8,9], Kubeless [7], Knative [10], and many other. Serverless computing has recently been increasingly used in many areas, including video processing, machine learning, data processing, website requests, IoT scenarios, and various stateless APIs [1]. Although serverless computing is concise on the user-end, there are still many challenges in the design, implementation, and deployment of the serverless architecture. Serverless computing platforms are still in their juvenile stage. According to our literature search, there are some challenges that have not been well studied. One of the most important challenges is security.

In this paper, we focus on the security aspects of serverless computing. It is about the security quantification toward the enhancement. Security is perhaps the greatest deterrent that prevents serverless computing from being widely adopted. Many business organizations and research institutes are quite vigilant in migrating their information assets to third-party service providers. Conventional IT infrastructures hold information assets in their private data centers or servers. Running, saving, and backing up data and applications are organized locally in the administrative domain [11]. Traditional organizations are often reluctant to use cloud services as infrastructure. The security measures for external organizations are often transparent. In addition, the presence of a large number of individual users has prompted transparency in security measures. Users may be trusted by cloud service providers, but distrust exists between different users. These reasons cause customers to distrust and conflict with cloud service providers’ assets. Serverless computing exacerbates this trend. When users have only heard of the concept initially, they will not get too interested in or dependent on serverless computing. With the development of the serverless computing ecosystem, more and more people begin to pay attention to the security of serverless computing.

The rise of serverless computing provides an opportunity to construct a novel security quantification method to reveal the degree of risk that exists in serverless computing. We propose a quantification method combining Attack-Defense Tree, Risk Matrix and Probability of Success to demonstrate the risks of serverless computing. In essence, we explore the following specific areas in quantifying serverless security:

Understand and analyze the underlying architecture, principles, and applications of container technologies, such as Docker and Kubernetes towards the development and deployment of serverless computing.
Study and comprehend the architecture, principles, effectiveness, and workflow of serverless computing, identify challenges and related issues toward the security enhancement.
Survey and analyze the prominent and standard security quantification mechanisms (for quantifying security attributes, measures, or metrics) such as Attack Tree and Attack Defense Tree.
Propose a novel quantitative measure to logically compute the probability of risk (an attack) or countermeasure.
Carry out the risk analysis of serverless computing while dividing it into its constituent layers. In fine, we analyze how the quantification can help direct the end-to-end security enhancement of serverless computing.

The rest of this paper is organized as follows. “Related work” section briefly reviews the related works dedicated to serverless security quantification using Attack Tree and Attack Defense Tree. “Serverless computing and OpenFaaS” section presents the architecture, principles, effectiveness, workflow of serverless computing, and the deployment of serverless applications using OpenFaaS (one of the most popular serverless frameworks) [12]. “Security quantification mechanism” section presents our proposed novel security quantification mechanism to carry out the security analysis. “Security quantification of serverless computing” section presents the security quantification of Serverless Computing. Note that the serverless architecture is divided into its constituent layers and thorough quantification is carried out for better analysis. “Conclusion and future works” section concludes this paper with discussion of future research works.

Related work

In this section, we present a literature review delving with security quantification of serverless computing, as following:

Security quantification methodology

We find that the commonly used methodologies for analyzing security risks, threats, vulnerabilities, attacks are Attack Tree, Threat Model, Risk Tree, and others. We briefly demonstrate their principles and evaluation metrics, as follows:

Attack Tree

An Attack Tree is a conceptual diagram used to model possible attack scenarios or threats in a system. It uses graphical, mathematical, and structured decision-tree symbols to model possible attacks. Besides, it also systematically classifies the ways that a system can be attacked. Notably, its complimentary Attack-Defense Tree helps us model defenses against these attacks.

Threat model

Similar to Attack Tree, Threat model^{Footnote 1} analyzes potential threats, vulnerabilities, or the absence of potential countermeasures.

Risk tree

Risk Tree^{Footnote 2} is a methodology, which is used for risk management. Notably, it is developed on the top of Attack Tree approach. Using Risk Tree, we can precisely capture and prioritize the risks of a system and its applications.

Risk matrix

Risk matrix [13] is a tool used to quantitatively assess and prioritize project risk. In the risk matrix table, risks are classified into different levels, such as high, medium, and low. Risk matrix has become one of the widely used quantitative risk assessment techniques [14]. The two main disadvantages of a risk matrix are its poor resolution [15], which may not accurately differentiate and compare distinct risks, and its ambiguous inputs and outputs, which necessitate subjective interpretation and could lead to disparate assessments of the same risk.

Discussion

We observe that the aforementioned methodologies perform similar analysis concerned with security risks, threats, vulnerabilities, attacks, and so on. Among these we choose Attack Tree, since it is well-established compared with other methodologies (as discussed in the later part of this section). Also, our objective is to do quantitative and qualitative analysis concerned with security. To this end, we look for the readily available tools. Respectively, we find a couple of open-source and commercial tools available for Attack Tree as stated later part of this section.

Therefore, we do our quantification toward security area by leveraging Attack Tree (ATree) and Attack-Defense Tree (ADTree). In this section, we review the relevant works to understand the foundations of Attack Tree and Attack-Defense Tree. Besides, the modeling tools and frameworks of Attack Tree and Attack-Defense Tree are analyzed. In addition to the analysis of these fundamental options, we analyze how communities use these tools in terms of security quantification. According to the above analysis, we quantify the security, on which serverless computing focuses.

Foundations of Attack Tree and Attack-Defense Tree

Mauw et al. [16], offers a formal definition of the concepts of Attack Tree that is an effective and intuitive aid to threat analysis. The formal interpretation helps to learn and manipulate Attack Tree precisely. Besides, the denotational semantics based on attack suites, attribution, and projection in attack trees are formally defined.

Mauw et al. [17, 18] give formal definitions of Attack-Defense Tree. As an enhanced version of Attack Tree, Attack-Defense Tree can handle more complex security challenges and scenarios. They utilize Attack-Defense Tree to create effective defenses, and calculate the probability of attack success after defense through some of its attributes which is evaluated in ADTree.

Ingoldsby, Terrance R [19] analyzes threats based on Attack Tree. The author demonstrates the Attack Trees bring greater rigor and objectivity in analyzing the hostile risk. This work gives the origin, use conditions, analysis methods, and calculation of Attack Tree. Besides, it explains how to step in risk analysis. Risk analysis using attack tree model more clearly expresses expert knowledge and reasoning. Analysts can better express their understanding of security issues in a unified and mature model, which promotes discussion among security experts. We know how to model the threat correctly and concisely, which helps us construct attack scenarios against the entire system using attack tree and Attack-Defense Tree methods.

Hansen et al. [20] introduce ADTLANG, a programming language technique for better reasoning of ADTrees. In particular, the authors come up with a set of approaches and augmentations in extending the basic Boolean logic of ADTrees with behavioral properties and quantities. Notably, the authors facilitate the the use of ADTrees introducing a domain specific language and coming up with a tool. This tool/approach is the ADTLANG accompanying with IDE. It facilitates the reuse, collaborative tree construction, and modularity. It also helps separate the quantitative/behavioral elements and logical attributes. The authors evaluate the effectiveness of their tool implementing a reactive Break The Glass policy and achieves comparable results. This research work affirms the significance and importance of ADTree.

Broccia et al. [21] assess the acceptance and understandability of ADTrees notations in analysing security constraints. In particular, the authors assert that while the quality of the notations has been predominantly measured quantitatively, its simplicity, clarity, and comprehensibility (in short, understandability) have not been reviewed, even though they are essential for its success. For this, in evaluating the acceptance and understandability of ADT notations, the authors perform an experiment with 25 human subjects. The experimental analysis prove that ADT notations are well accepted and have a very high level of understandability.

Modeling tools for Attack Tree and Attack-Defense Tree

In the early stage of our research, we first conduct a thorough survey and comparison of the Attack Tree modeling tools available in the market. We then divide them into two types according to commercial or open-source tools as follows:

Commercial Tools: SecurlTree from Amenaza Technologies , AttackTree+ from Isograph and RiskTree from 2T Security.
Open Source Tools: Ent [22], SeaMonster [23] and ADTool [24, 25].

From these two categories, we exclude commercial tools because we have to pay for them. In our study, we will choose the most suitable tool from open source tools through analysis and comparison, and finally we choose ADTool.

Table 1 Open-source Attack Tree modeling tools comparison

Full size table

In Table 1, we show the comparison of three open-source modeling tools to visually illustrate the technical and functional differences among them. After completing the comparison, we chose ADTool as our attack tree modeling tool. ADTool is ahead of other tools in terms of activity and feature support. Notably, ADTool^{Footnote 3} was developed at the University of Luxembourg. It allows users to perform quantitative analysis based on Attack Tree and Attack-Defense Tree. It has 13 built-in property fields, which fully support the quantitative analysis related functions we need. The biggest difference between the other two tools is that ADTool is designed and developed for Attack-Defense Tree, not just Attack Tree, which meets our research objectives.

Use cases of Attack Tree and Attack-Defense Tree

We observe that the protocols and standards used in control systems have little regard for security. To this, we study the use-cases of Attack Tree and Attack-Defense Tree in analyzing security requirements and constraints of various service providers, applications, and systems. We find that Byres et al. [26] use the attack tree to evaluate the possible vulnerability risk of MODBUS protocol stack in SCADA system. By defining several basic categories of risk and environmental assumptions, the authors brainstorm eleven attacker targets and identify security vulnerabilities inherent in the specification and typical deployments of SCADA systems. According to the attack tree, the vulnerability of the system can be analyzed and the related equipment can be tested. The main benefits of using attack trees are that they focus on evaluable targets and can define specific tests, rather than merely considering theoretical vulnerabilities in terms of devices, networks, and protocol implementations without practical testing. We also get guidance on how to quantify risk concretely.

MyProxy system proposed by Saini et al. [27] is a security subsystem in Globus grid computing toolkit, which is used to store user proxy credentials. The authors use the concept of Attack Tree to evaluate its security and calculates the attack cost and damage cost for each attack scenario. Using this system as an example, the authors demonstrate the feasibility of using Attack Tree modeling in enterprise risk management, rather than the complex traditional trust modeling ideas of academia, to quickly understand risk modeling. The authors determine the priority of security vulnerability risk by constructing the qualitative analysis of Attack Tree, which inspires us to conduct the qualitative analysis of serverless computing.

Notably, we also analyze the use cases of ATree and ADTree in e-Voting. To ensure secure access to any Internet application or system, especially for binding Government elections, every vote must be counted. The public, process, equipment, software, strategy, law, and other factors jointly affect the election system and constitute a complex network environment. Pardue et al. [28] build a threat tree for this system. They identified three threats to voting systems: voting equipment attacks, voting process attacks, and insider threats. Although there are overlapping parts among these threats, they are distinguished by different contexts, threat sources, and threat trigger conditions. They treat these three threats as three branches of the threat tree. The sub-threats are defined in a similar way to outline title hierarchy. They also use the OR and AND operators to represent the relationship between the threat nodes. Although their analysis is mainly about threat trees, the principle is similar to attack trees, thereby enlightening us on some strategies of how to attack serverless computing systems. From their risk assessment techniques, we learn how to classify risks into different categories.

Kordy et al. [29] present a method to evaluate probabilistic measurement of offensive and defensive scenarios involving correlative actions using Bayesian networks combined with ADTree method. This approach provides a practical way to perform accurate probabilistic evaluation of security scenarios modeled using attack trees or ADTrees by removing the assumption of independence. However, the application of this method relies on professionals and may require structurally complex models, which makes models difficult to understand and verify, and also makes calculations slow. In our scenario, we use the cumulative distribution function of the standard normal distribution to calculate the probabilities of various risks, saving a lot of time and resources.

Fraile et al. [30] use Attack-Defense Tree to analyze automated teller machines (ATM) threats. ATM security is critical and requires a sophisticated understanding of the threat. The authors introduce the application of Attack-Defense Tree in computer system and creates multi-stage attack scenarios to analyze ATM security. While they do not explain the attack and defense in detail, they do have a good taxonomy of possible ATM risks. We learned how to systematically build an Attack-Defense Tree and the strengths and weaknesses of the analysis. This is a good case study and the best practice for beginners.

Notably, we also analyze the applications of Attack Trees in the field of software and protocols. We find that the quantification of risk assessment is very important in every field of computing, especially for cloud computing, which can directly represent the results of the model. Attack Trees can help us make sound and effective risk assessments. Tanimoto et al. [31, 32] analyze the risk management of security problems in cloud computing. In recent years, the research on cloud computing by cloud service providers and academia mainly focuses on the server side rather than the security side. The authors conducted a comprehensive study and investigation on the security of cloud computing from the perspective of users. Specifically, user-side risk factors could be extracted by risk breakdown structure (RBS) method. According to the result of this method, the author puts forward specific countermeasures and suggestions. Tanimoto et al., in their first study conduct a qualitative assessment of these risks [31]. In their second study, [32], they filled in the quantitative part of the risk assessment. They put forward the risk quantification matrix, using their risk formula to calculate the risk value of each risk factor and its countermeasures to simplify the quantification. The matrix contains three factors, including Asset, Threat and Vulnerability. The final risk value can be obtained by multiplying these three factors. We learn the quantitative method of risk assessment and made more scientific refinement. They do not use attack defense trees to visualize risks and measures while we believe that attack defense is more intuitive in vision than simple table form in their study, and can also reflect the corresponding relationship between different attacks and countermeasures, as well as the hierarchical relationship between different attacks. Li et al. [33] present an offensive and defensive behavior tree model based on the Border Gateway protocol (BGP) attack tree. Their proposition is like that Defense tree model is not easy scalable. On the other hand, based on our study, we find that we can easily scale Attack-Defense tree model. In their study, the authors introduce Game theory into the attack tree model which is intended to demonstrate specific network attack and defensive scenarios. With this, the authors propose an algorithm for the calculation of the target attack success rate and finally its attack probability. This study is in line with ours, however, in our study we come with deriving probability scores of each individual attack and its countermeasures with Attack-Defense tree.

Wang et al. [34] talks about Cybersecurity risk assessment and protection on industrial control systems since it is important for effective response to network attacks. The authors introduce cybersecurity risk assessment method which is applied to airport automatic fuel supply control system. Notably, the method is based on fuzzy theory of Attack-Defense Tree model and probability cybersecurity risk assessment technology. The authors claim that the results are objective and reasonable while they reduce the subjective impact as the assessment is susceptible to subjective and objective effects.

Bryans et al. [35] work on Attack Defense Trees with sequential conjunction in Cyber-Physical Systems (CPS). Their methodology for generating these trees involves using a CPS model and predefined attack and defense templates. The manual process of constructing attack and defense trees is very time-consuming and prone to errors. Therefore, they automatically generate sequentially-connected attack-defense trees to facilitate the analysis of CPS network security. Differentiating our study from theirs, we incorporate probability with Attack Defense Trees. This enhancement dives even deeper into recognizing and comprehending potential system vulnerabilities.

Meng et al. [36] takes help of ADTree to analyze system architectures toward synthesizing optimal cost defense mechanism using MaxSMT [37]. Their goal is to defend all possible attacks/risks with minimal cost. While evaluation, they perform the experiment on a delivery drone system model and it achieves comparable results. Notably, we can also perform cost analysis with ADTree and it can also helps estimate minimum cost toward defending all the possible attacks in a system. As stated earlier, in this paper, we limit our analysis to success probability of attack. Notably, the analysis of minimum cost of attack and minimum cost of defense while mitigating all the attacks is our future study. In future, we plan to perform a comparative study between the study of Meng et al. [36] and ours.

In summary, we explore a set of research works related to threat and attack modeling, which enables us to better analyze the vulnerabilities and risks of serverless computing and conduct reasonable and objective risk assessment, helping us to conduct a scientific security quantification.

Serverless computing and OpenFaaS

We know that serverless computing is emerged with a myriad of features and functions for cloud users while the optimizing the quality of service (QoS), service level agreements (SLAs), cost, resources, time, and many more. However, we find that that we may encounter a couple of issues while working with the public commercial serverless offerings. They require the functions to be written or deployed in a certain way, resulting in vendor lock-in. On the other hand, the open source FaaS frameworks allow us to run serverless computing on private infrastructure, thereby avoiding any form of vendor lock-in. As stated earlier, some of the popular ones are OpenFaaS, Knative, Kubeless, and so on. Among these, OpenFaaS is the most flexible, most popular, and most commonly used [12].

OpenFaaS and its workflow

OpenFaaS is versatile enough to be deployed on private infrastructure, support multiple container runtimes based on K8s, or deploy with its own engine faasd. As one of the most popular platforms, OpenFaaS is getting a lot of attention from the community and its ecosystem is becoming more mature. OpenFaaS makes it easy for developers to deploy functions and microservices regardless of the underlying infrastructure and servers. Package code and binaries into Docker images and deploy them to OpenFaaS for autoscaling and metrics monitoring. OpenFaaS supports most container choreography platforms, such as K8s, OpenShift, and Docker Swarm (Deprecated). The core of OpenFaaS consists of two parts: API gateway and Watchdog. The former is responsible for routing function of the API, autosacling, and providing various metrics of the function. The latter is responsible for starting and monitoring OpenFaaS functions, and the watchdog can turn any binary into a function, similar to a simple initialization process. Watchdog also provides high throughput and reuses expensive resources such as database connections or machine learning models. Gateway metrics can be picked up and visualized by Prometheus^{Footnote 4} [38,39,40] or Grafana Dashboard^{Footnote 5}[41]. AlertManager^{Footnote 6} accesses requests per second metrics from Prometheus and decides the time of firing an alert to the API Gateway. The gateway scales when it receives an alert. Figure 1 is the workflow of OpenFaaS which shows the whole running process of the system.

OpenFaaS cluster

We deploy OpenFaaS to K8s, so we have built a K8s cluster with kind^{Footnote 7} and deployed OpenFaaS on top of it. kind is a tool to run local Kubernetes using Docker container. Notably, the configuration of our system is, as shown in the Table 2.

Table 2 System configuration

Full size table

In the cluster, we first install faas-cli, it is a very useful command line tool, through which we can quickly perform different operations on the function, we can view all supported commands through faas-cli help including new, deploy, build, and so on. Next we need to install K8s and Docker to support the running of virtual nodes. We use Arkade for quick installation of OpenFaaS. We have 2 namespaces - openfaas and openfaas-fn, The first contains all the basic components of OpenFaaS, and the second contains all the functions and function containers.

Security quantification mechanism

Novel quantification measure for security analysis

In order to quantify the security of serverless computing, our main goal is to find an intuitional measure to do it. We have used attack defense trees to model some of the risks of serverless computing and have visualized them with ADTool. An important question is how to assign an appropriate probability value to each risk. We applied the risk matrix to each risk in attack tree to get the risk probabilitiy values. Then, We propose a new quantitative measure to express the probability of risk. In our quantification of security analysis, we combine Risk Matrix, Standard Normal Distribution, and cumulative distribution function to propose a new quantitative measure called Relative Risk Matrix evaluating the probability of risk effectively and efficiently. Our measure is mainly concerned with probability estimation in risks. Among all the attribute domains of Attack-Defense Tree method, we chose the Probability of success domain to support our security quantification analysis. The proposed measure can be described step by step:

1
Compute the matrix value by multiplying the evaluation factor values.
2
Standardize these matrix values to conform to a standard normal distribution.
3
Use the Cumulative Distribution Function(CDF) to generate probabilities from these standardized values.

Notably, it is the process of the formulation of Relative Risk Matrix (RRM) & Relative Risk Mitigation Matrix (RRMM).

Relative risk matrix & relative risk mitigation matrix

In this section, we demonstrate the formulation of Relative Risk Matrix and Relative Risk Mitigation Matrix.

Relative risk matrix for attack

There are three important factors in the relative risk matrix: Vulnerability Severity, Consequence Impact, and Exploitability.

Vulnerability Severity is how critically a vulnerability can affect a system if exploited. This might include considerations such as the potential disruption to the system, the scope of the damage, and the level of access it can provide to an attacker. It is a measure of the potential harm a vulnerability can cause without considering if an exploitation for it exists.
Consequence Impact is often related to what could happen to a system post-exploitation. This mainly concerns the aftermath and potential damage should a vulnerability be successfully exploited. It takes into account factors like data loss, system downtime, reputational damage, etc.
Exploitability is an indication of how simple it is to exploit a given vulnerability. This involves things like whether an exploit is publicly available or known, the level of sophistication needed to exploit the vulnerability, or whether special conditions are required for an attack to be successful.

Notably, although those three factors seem to be closely related due to their involvement in risk assessment, they are different aspects of the overall picture. Each one provides distinct information: the potential severity of a vulnerability, the impact post-exploitation, and the likelihood of successful exploitation. A comprehensive understanding of a system’s security can be obtained by considering all three factors.

Vulnerability Severity and Consequence Impact are often correlated. A high Vulnerability Severity may result in a high Consequence Impact, which can be exemplified by a critical software bug that, once exploited, can bring down the entire system and cause extensive data loss and downtime. However, there can also be many cases where these two factors do not correlate. For example, a system might comprise an exploit with high Vulnerability Severity score because its exploitation would disrupt the system’s operation significantly. However, if that system only contains non-sensitive data, an exploit would not result in serious data loss, which means the Consequence Impact score would be low. On the other hand, a system handling extremely sensitive data could have a high Consequence Impact owing to the seriousness of any data breach. However, if exploiting the vulnerability requires very specific conditions that are difficult for attackers to meet, the Vulnerability Severity could be lower. Hence, although Vulnerability Severity and Consequence Impact are often linked, they do not always correlate. It is vital to consider both when assessing the overall severity of vulnerability and potential impact of consequence.

We have designed a scoring system from 1 to 4 for each risk factor. A score of 1 implies a low probability of this factor leading to the risk, or a minor impact if the risk is triggered by this factor. A score of 2 indicates a below-average likelihood or impact. A score of 3 means this factor has a higher-than-average probability to lead to the risk, or it may cause an above-average impact. Lastly, a score of 4 suggests that this factor has a high probability to cause the risk, and the potential risk could be substantial. This scoring system provides a clear basis for judgements when assessing the contribution of each factor to the risk, thus allowing wiser risk management decisions.

$$\begin{aligned} \textrm{RRM Value}= \text {Vulnerability {Severity}} \times \text {Consequence Impact} \times \text {Exploitability} \end{aligned}$$

(1)

Below we give a range of values for each factor, shown in Table 3. A simple example of Relative Risk Matrix is shown in Table 4.

Vulnerability Severity: Low(1), Medium(2), High(3), Extreme(4)
Consequence Impact: Low(1), Medium(2), High(3), Extreme(4)
Exploitability: Low(1), Medium(2), High(3), Extreme(4)

Table 3 Risk assessment table

Full size table

Table 4 Relative risk matrix value example

Full size table

Let us describe the process of calculating probabilities in detail using a sample Table 4 as an example.

1
Evaluate factor values and compute matrix values. In Table 4, for the risk of “Data modification”, we assess its Vulnerability Severity as medium with a value of 2. Its Consequence Impact is High, with a value of 3. It has an Exploitability of Medium with a value of 2. The product of these factors results in a risk matrix value of 12. Similarly, for the risk of “Privilege Escalation”, we conducted a corresponding evaluation and obtained a risk matrix value of 18.
2
Calculate standard values for matix values. Standardize the matrix values are standardized to conform to a standard distribution. Calculate mean $\mu$ by the formula $\mu = \frac{(12+18)}{2}= 15$, and calculate standard deviation $\sigma$ by the formula $\sigma =\sqrt{\frac{18}{2}}=\sqrt{9}=3$. Utilizing the provided mean and standard deviation, we can compute the standard value with: $SV = (X - \mu ) / \sigma$. Consequently, the standard Value for “Data Modification” is $-1$, indicating its risk matrix value is one standard deviation below the average. The standard Value for “Privilege Escalation” is 1, indicating it is one standard deviation above the mean. These computations let us understand these values’ positioning within the distribution in respect to the mean value.
3
Use the cumulative distribution function to describe the probability distribution of these standardized values [42]. The CDF uses the integral of the probability density function to calculate the probability that a random variable will take on a value less than or equal to a specified value. Applying this function to our standardized values allows us to generate a new set of values that represent the probabilities of each potential risk. For standard value $-1$, the probability is approximately 0.16. This probability can be interpreted as there being a 16% chance that a random variable will take on a value equal to or less than the risk matrix value for “Data Modification”. For standard value 1, the probability is approximately 0.84. This means there is an 84% chance that a random variable will take on a value equal to or less than the risk matrix value for “Privilege Escalation”.

Relative risk mitigation matrix for countermeasure

There are three important factors in the relative risk mitigation matrix: Mitigation Degree, Feasibility, and Implementation Simplicity.

Mitigation Degree assesses how much a certain strategy will reduce the risk. For example, if a security vulnerability can be totally eliminated by applying a certain patch, then this strategy’s mitigation degree is very high.
Feasibility evaluates the viability of actually applying a mitigation strategy. For example, we might have a highly effective strategy, but if it requires an investment in equipment that our organization can not afford, or expertise we do not have, then its feasibility is low.
Implementation Simplicity measures the ease or difficulty in implementing the mitigation strategy. For example, a strategy might require a simple configuration change that can be done in minutes (high simplicity), or it may require significant application code rewrites that could take weeks or months (low simplicity).

$$\begin{aligned} \textrm{RRMM Value}= \text {Mitigation Degree} \times \text {Feasibility} \times \text {Implementation Simplicity} \end{aligned}$$

(2)

Below we give a range of values for each factor.

Mitigation Degree: Low(1), Medium(2), High(3), Extreme(4)
Feasibility: Low(1), Medium(2), High(3), Extreme(4)
Implementation Simplicity: Low(1), Medium(2), High(3), Extreme(4)

A simple example of Relative Risk Mitigation Matrix is shown in Table 5.

Table 5 Relative risk mitigation matrix value example

Full size table

In essence, we propose a new security quantification measure which can be used in serverless computing security analysis combining with risk matrix, standard normal distribution, and cumulative distribution function. This metric assesses the probability of the risks meticulously. We take serverless computing as an example to verify the effectiveness of our measure. In the following sections, we conduct a security quantification for serverless computing. Leveraging a RRM that we developed, we assess potential probabilities associated with various risk events. This information is then modeled and analyzed using Attack Trees and Attack Defense Trees methodology. This novel integration of relative risk matrix and attack modelling techniques provides an enhanced understanding of the security landscape in serverless computing environments, a necessary step towards mitigating potential threats.

Security quantification of serverless computing

Layers of serverless computing

In the “Serverless computing and OpenFaaS” section, we describe the architecture of Serverless Computing. From the architecture, we can divide Serverless Computing into the following layers and conduct quantitative analysis on each layer separately. After performing individual quantitative analyses, they are added together to form a holistic analysis. Below are the defined layers of Serverless Computing:

1
Cloud Layer
2
Container Infrastructure Layer
3
Serverless Layer
4
Access Layer

The following parts describe the security quantification of each layer in Serverless Computing.

Security quantification of cloud layer

More than a decade ago, the concept of cloud computing emerged and continued to grow [43]. The flourish of cloud computing migrates away the innovation and deployment of user software and computing activity from on-premises to the cloud. Cloud computing is the delivery of computing services over the Internet while computers on the Internet can communicate with many servers at the same time and some of them may be exchanging information with each other. Serverless Computing is built on the high degree of maturity of cloud computing and still use servers to compute [44].

The security challenges that Serverless Computing faces first come from the Cloud Layer. Cloud computing presents plenty of security issues and challenges. The security problems relate to the cloud model architecture, multi-tenancy, elasticity, and layer dependency stack [45]. In this section, we quantify the security problems in Cloud layer of Serverless Computing with the attack-defense tree method.

Attack scenario one: Attack Tree modeling and quantification

Attack Tree modeling

We model potential threats in serverless computing by using attack tree. We find three perspectives in cloud computing would have threats and there is a great deal of attack to be put into effect. The typical attack tree diagram is shown in Figs. 2 and 3 while we pick a few options with a high probability of attack. This figure categorizes attack types explicitly and indicates different aspects of our analysis. Attack of CSP side focus on the risks that may occur in CSP while their platform, infrastructure, application, or storage services might have some vulnerabilities. Attack of cloud user side produces the risks in cloud user while users do not secure their credentials and secrets properly. Other attacks are related to emergencies which are not caused by CSP or cloud users.

Cloud service provider side has different ways to attack. When serverless computing provides service in the cloud computing world, CSP side will not ensure its data security, integrity, and consistency. There are some vulnerabilities which allow malicious codes to attack a CSP [46]. Three cloud service models (SaaS, PaaS, and IaaS) used by CSPs store customers’ data in their data centers. All these data can be accessed by CSP, internal employees, and external hackers. CSP have full control over data that can be sold to obtain huge economic benefits. Internal employees may have permission to these data, know how to access data without authentication or develop an exploitable application programming interface. External hackers exploit vulnerabilities with a great deal of cybersecurity attack techniques, such as backdoor, session hijacking, network eavesdropping, and many more. Those threats in CSP side could cause data modification and destruction, data leakage and risky application programming interface. Data leakage over the cloud has become one of the greatest risks [47]. Many CSPs have reported that they lost a lot of customer interest, such as Alibaba Cloud, AWS, IBM, and many others. Application programming interface can be compromised and data can be stolen via this way. Some sensitive interfaces should be authorized and encrypted carefully.

Cloud user side is another compromised part in cloud computing. While users have complete control over their data to decide who has the permission to read or change data and which part of data is available, there are some requirements for cloud users. User access management is a big issue while leaving this operation to the users. Users often do not have very specialized security knowledge and operation knowledge about access management. Mostly, they are not aware of the importance of permission control while their credentials and secrets are obtained by abnormal user. Consequently, the data is compromised. External hackers obtain user credentials easily if users are not aware of security precautions. Bypassing authentication is more unconventional, but also common. Hackers use their tools to execute penetration testing. For example, SQL Injection is a code injection technique used to attack applications to spoof identity without authentication.

Figure 2 shows that some attacks come from natural factors outside of the cloud. Cloud computing services still store data and applications in cloud data centers. Each data center may contains tens of thousands of computers and other auxiliary facilities [48]. While data center faces supplier extensive outage, man-made sabotage and natural disaster, cloud service provider suffers very serious financial losses. These risks cause attacks to cloud layer such as environmental adverse impact, physical destruction, and network faults. The outage causes a large-scale downtime. Even, internal employees or externals could enter the data center and wreak havoc. Moreover, natural disasters such as earthquake and tornado are very common in the some parts of the world.

Quantification with Attack Tree

Now, we use a good metric to quantify the probabilities of risk with Attack Tree in the risks analysis. We find that there is Probability of success in attribute domain in Attack Tree. The success probability of attack equals to the probabilities of risk in our context because the success means the presence of the risk instead of the elimination of the risk. Therefore, we can draw Attack Tree with this attribute domain to quantify the risk.

In our quantitative analysis, we choose the relative risk matrix of attacks of our evaluation method. From Eq. (1), we have three factor and multiply them to get the final matrix value. We normalize these matrix values with standard normal distribution to get the standard value (Y) for each matrix value (X). We calculate the mean value and the standard deviation value of them. We decide the probability of each risk by the standard value and expert consensus. All values are showed in Table 6.

Mean: $\mu = \frac{(12+12.42+11.25+13.5+12.96+3+4+6.75)}{8}= 9.48$
Standard Deviation: $\sigma =\sqrt{\frac{125.84}{8}}=\sqrt{15.73}=3.97$

Table 6 Relative risk matrix value for Attack Tree of cloud layer of serverless computing

Full size table

After getting the matrix value from relative risk matrix, we determine the probability of success of each node in the attack tree based on matrix value, security disclosure degree, professional advice and historical issues of those attacks. It is acceptable that the probability is affected by some subjective factors because risk analysis is conducted by an expert in corresponding area. In our analysis, multiple risk types are examined within the ATree model. Adopting a comparatively objective scoring system, the probabilities of these risks were investigated via search engines and professional databases like MITRE [49]. For instance, the risk category of Data modification & destruction received an evaluation score of 2 for Vulnerability Severity, 3 for Consequence Impact, and 2 for Exploitability. Therefore, the total score would be calculated as $matrix\_value = 2\times 2\times 3 = 12$. All other risks listed in Table 6 are scored using the same criteria. These risk values are then normalized and the probability of each value is calculated through the CDF. We present the Attack Tree of the serverless cloud layer in Fig. 3 with attacking probabilities. Each node is an OR relationship, which means that a successful attack on any node is feasible. We see that the success probability of attack is 99.99$\%$.

Attack scenario one: Attack-Defense Tree modeling and quantification

Attack-Defense Tree modeling

After using attack tree to point out some security risks in the Cloud layer of Serverless Computing, we also find some countermeasures to eliminate or mitigate these risks. Thus, we model an attack-defense tree for it as shown in Fig. 4. We give each attack a defense to prevent or mitigate it. More defenses can be given for an attack, but in order to simplify the quantitative model, we will only propose a most effective defense for demonstration.

While we give each attack a defense, we will describe each defense in detail.

Regarding attacks at the cloud service provider side, data backup is a good countermeasure to cope with the exception when data is modified or destructed. CSP prepares an efficient backup solution and fast recovery when they find that their data go wrong. Many well-known CSPs have complete data backup plans. National Institute of Standards and Technology(NIST) suggests backup plans should be reviewed periodically (at least annually) [50]. In 2018, a Tencent Cloud user called “qian yan shu kong” found the file system metadata was corrupted due to firmware bugs in the disk. Based on its own assessment, the user filed a claim of up to RMB 11,016,000 (About 1.6 million US Dollar) against Tencent Cloud for the failure [51]. To provide consistent, stable and secure services, a cloud data backup plan is necessary and fundamental. Data leakage is a common threat while CSPs fail to secure access rights or compromise data transfer interface [50]. Data leakage might also happen in incomplete data deletion and isolation failure [52]. One effective countermeasure is that CSPs could restrict access to protect from data leakage. CSPs have services and applications which are developed quickly and iteratively expose to interface vulnerabilities. We propose adequate technical specification and testing to reduce and mitigate the possibility of occurrence in risky application programming interface.

In attack of cloud user side, user credentials and secrets are highly confidential. When user credentials and secrets are obtained by third party organizations, they will have access to everything the user owns. Multi-factor authentication mitigates the issue of the leakage of user credentials and secrets. This authentication method allows a granted user to access with two or more factors. It effectively dealt with the partial disclosure of confidential user information. Another attack is bypassing authentication. Bypassing authentication means an attack gains access to a service or application having the same permission as authenticated users. Continuous monitoring can get more context in the user authentication process and avoid being confused by some of the user’s persistent credentials. Continuous monitoring also combines perfectly with multi-factor authentication that allows context in each step of authentication is available.

For other attacks in cloud layer attack, we suggest having a stable environment to protect against the threat of environmental adverse impact. When suffering from physical destruction, first countermeasure is high availability for data centers. The second countermeasure is to strengthen access control for data center anti-damage quality and assurance personnel so that only trusted people can obtain access and take adequate follow-up measures. The last attack is network fault which can be caused by natural disaster, network hardware fault and Internet Service Provider’s fault. The most effective and efficient countermeasure for this attack is to have a completed and updated network backup plan.

Quantification with Attack-Defense Tree

We conduct a quantification with attack defense tree. Similar to the analysis of attack tree, we adopt the same attribute domain and relative risk mitigation matrix to quantify it. After assigning the factors’ value (mitigation degree, feasibility, implementation simplicity) based on our perspective and cognition, we get the mean value $\mu$ and the standard deviation $\sigma$. Table 7 shows the whole calculation process of each defense.

Mean:$\mu = \frac{(24+18.75+18+9+18+27+36+24)}{8} = 21.84$
Standard Deviation:$\sigma =\sqrt{\frac{440.37}{8}}=\sqrt{55}=7.42$

The score of RRMM factors in Table 7 is evaluated comprehensively through sources such as search engines and MITRE D3FEND Knowledge Graph [53]. After the computation of Table 7, we figure out the probability of each defense and assign each defense the probability value in ADTool to generate Fig. 5. When the success probability of each defense node is assigned, the success probability of their corresponding attack node will be reduced according to the corresponding computation. After applying our defense strategy, we can see that the final attack probability on cloud layer attack nodes has decreased from nearly 100% to 98% now. We observed an improvement by applying a single defense against each type of attack. If we apply more defensive techniques, then we will be able to achieve more protection. The quantification of cloud layer attack demonstrates effective protection with reasonable defensive countermeasures.

Table 7 Relative risk mitigation matrix value for attack defense tree of cloud layer of serverless computing

Full size table

Security quantification of container infrastructure layer

Container technology and container orchestration are popular concept in cloud computing. The prosperous of container ecosystem accelerated the development of container technology in the last decade. Docker is the most prevalent representative of container technology. As a lightweight alternative to virtual machines, container is small, fast, and low overhead to provide the resources that microservices needed [54]. However, container is more vulnerable than virtual machines. On the other hand, Kubernetes is the fastest-growing project and the most famous container orchestration framework which is mature in production in arranging containerized applications. As a rapidly evolving and iterative cloud native project, Kubernetes Infrastructure security has a high priority in community and industry. In container infrastructure layer of serverless computing, we analyze the security risks from container side and Kubernetes side while these two sides are the fundamental of FaaS. In attack scenario two, we construct attack tree and attack defense tree for container infrastructure layer of serverless computing. Notably, MITRE ATT&CK framework is a good knowledge base in cyber attacks which coverage for Windows and Linux [55]. Some attacks in our attack tree are highly referenced to this excellent framework and the article which modeled the threat matrix for Kubernetes in Microsoft Security [56].

Attack scenario two: Attack Tree modeling and quantification