Certification Process and Framework Architecture

According to [1], a certification process receives as input the Target of Certification (ToC), describing the system under certification, the security property p to be certified, and all the evaluation activities to be carried out on the ToC, and returns as

output a certificate including the evidence describing the evaluation activities. The certification process is composed of two consecutive phases, each one described in machine-readable document.

• Certification methodology specification: the certification authority defines a set of mandatory evaluation activities to be executed on a generic class of ToC to certify a given property. It is defined as a declarative model called Certification Model (CM) Template – CMT – and is signed by the certification authority. It represents the basis for establishing a chain of trust grounded on the correctness of the methodology defined by the certification authority.

• Certification process specification: the CUMULUS-accredited lab together with the service provider instantiates the methodology described in a CMT on a specific ToC to evaluate the corresponding property. It is defined as a procedural model called Certification Model (CM) Instance – CMI, without direct involvement of the certification authority. It can be directly executed by the CUMULUS certification framework.

Certification models are complex documents specifying all activities of a cer-tification process. For the sake of simplicity, in this chapter, we consider simpli-fied CMs defined as the models driving the collection of generic evidence (see Sect.8.2.1).

8.2.1 CM Instance and CM Template

CM Template and CM Instance are machine-readable documents associated with a pair.p; ToC/ and both represent the execution flows (i.e., a path in the CM) of a ToC as the concatenation of mechanisms deployed at different layers of the cloud stack.

Although they share a similar structure, they have some fundamental differences.

CMT defines generic execution flows as a sequence of vertices with abstract function calls and mechanism annotations, while CMI defines real execution flows that refer to a concrete ToC, with real function calls and mechanisms. Also, the trust in CMT is given by the trust in the signature of the certification authority, while the trust in CMI inherits from a correct instantiation of the corresponding CMT [2].

Practically, CMT and CMI are defined as direct acyclic graphs, where each vertex refers to a mechanism type and models its execution, and each edge is annotated with the function call to the mechanism represented by the vertex. We note that each function call annotating an edge triggers a state transition and corresponding mech-anism execution. Each vertex also includes (i) the description of the mechmech-anism (i.e., the minimum required mechanism in CMT and the implemented mechanism in CMI), (ii) its deployment layer (i.e., service, platform, or infrastructure layer), (iii) a set of events affecting its execution, and (iv) activities to be executed to evaluate its correct behavior.

The correct instantiation of a CMT in a CMI is verified according to a consistency check function composed of three steps: CM Instance Reduction, Graph Matching,

Fig. 8.1 Conceptual framework

and Annotation Matching. CM Instance Reduction includes all preparatory activities needed to compare CMT and CMI. Graph Matching checks whether CMI graph is a proper instantiation of the CMT graph, meaning that the two graphs are isomorphic, that is, they have the same vertices and edges, and corresponding vertices have the same type. Annotation Matching traverses CMI and CMT graphs using breadth-first search and, for each pair of vertices, verifies whether: (i) the implemented mechanism in CMI is at least as strong as the required mechanism in CMT, (ii) information associated with each pair of corresponding vertices in CMI and CMT must be such that the cloud layer is the same, and the events and the activities in the CMT are a subset of the events and the activities in the CMI. More details on the consistency check function can be found in [1]. We say that CMI is consistent with CMT (denoted CMIFCMT) according to the above three steps.

8.2.2 Certification Process

Figure 8.1 shows the conceptual framework of our certification process, as an extension of the one in [2]. The certification of the ToC for a given security property starts upon the definition of a CM Instance that is generated as a specialization of a given CM Template and continuously verified against it using the Consistency Check (see Sect.8.2.1). The evidence is continuously collected and analyzed by executing the CM Instance, to verify support (dashed arrow in Fig.8.1) for the property to be certified. The evidence, in fact, could be insufficient to prove a given security property and thus to award the corresponding certificate. The continuous check of consistency between CMI and CMT and incremental evidence collection introduce two loops in the framework, which are at the basis of the advanced certification models in Sect.8.4and the trust model in Sect.8.5.

Fig. 8.2 Certification process

Based on this conceptual framework, we define the certification process in Fig.8.2 that works as follows. First of all, independently from the certification of any specific systems, certification authorities define their CM templates for different pairs.p; ToC/. Then, a service provider aiming to implement a certified cloud-based system selects a specific CMT, implements the system, and defines the CMI according to the selected CMT and implemented system. The CUMULUS-accredited lab then evaluates the consistency between CMI and CMT (CMI F CMT) and, if consistent, executes CMI and collects the evidence using the functionalities offered by the CUMULUS framework (see Sect.8.2.3). Finally, the certification authority adopting the CUMULUS framework evaluates the evidence collected and, if sufficient, releases a certificate C.

8.2.3 Architecture

Figure 8.3 shows an integrated view of the CUMULUS framework architecture [3] and its multi-layer certification assurance [4]. The architecture consists of internal components processing CUMULUS certification models, remote compo-nents residing on cloud platforms with services and applications part of the target of certification, and APIs and dashboard GUI offering retrieval and management functionality to various types of actors interacting with the framework.

Topmost part of Fig.8.3shows the different actors interacting with the frame-work. Certification authorities and accredited labs access framework’s functionality for management of certification models (storage, retrieval, update, deletion) and execution of certification processes for given CMIs. Cloud service providers access framework’s functionality for retrieval of certificates and CMIs issued for providers’

services. The third category of actors are cloud service and application developers.

This category of users interact with the framework due to their needs of consuming cloud services and resources within their applications, subject of development, in

Fig. 8.3 CUMULUS certification framework architecture

order to obtain required security assurance about the security aspects and properties of those cloud resources. The central certification artifacts for this last category of actors are the certificates issued by the framework. In that direction, the CUMULUS framework provides an engineering process and toolkit for cloud application developers to facilitate certification-aware engineering of cloud applications [5]. A set of APIs and dashboard GUI are provided to enable access to the retrieval and management functionality of the framework for the different types of actors.

The central part of Fig.8.3 shows the CUMULUS framework architecture.

The main component of the framework in charge of execution of all certification processes is the Certification Manager. The CUMULUS framework triggers the execution of type-specific certification processes by submitting a CMI for execution through the framework management APIs or through the Dashboard. The frame-work calls the Certification Manager to handle the execution of the given CMI. The Certification Manager has three main sub-components – Monitoring Manager, Test Manager, and TC Manager. Each of these type-specific managers is responsible

for the execution of the corresponding type-specific CMIs and for handling all related certification processes and sessions. In this way, the Certification Manager main role is to dispatch all certification requests coming from the framework actors to the corresponding type-specific certification managers and return the results of certification process executions back to the framework actors (e.g., through the dashboard).

Each type-specific certification manager implements (i) all necessary certifi-cation mechanisms and underlying certificertifi-cation processes and their execution, for the corresponding type-specific certification, and (ii) all interactions with the corresponding type-specific Evidence Collector. The evidence collector is a remote framework component residing on the cloud platform deploying the target of certification and is responsible for gathering type-specific evidence on the target of certification and its environment and reporting those to the corresponding type-specific certification manager. Three Evidence Collectors have been developed [6]:

(i) Event Captor, gathering evidence for monitoring-based certification by capturing events on the ToC and its environment; (ii) Test Agent (TA), gathering evidence for test-based certification by executing test cases on the ToC and its environment;

and (iii) TC Module, gathering evidence for TC-based certification by measuring integrity of ToC’s software and its environment/platform using a Trusted Platform Module (TPM) [7].

The bottom part of Fig.8.3 shows how CMIs relate to the different layers of the cloud computing model (SaaS/PaaS/IaaS) and provide multi-layer certification-based security assurance [4]. Depending on the ToC, its perimeter and the security property to be certified, hybrid and/or multi-layer certification models might be specified, which require the presence of different type-specific Evidence Collectors on the same or different layers of the cloud computing model to gather sufficient evidence and ensure the security property holds for the ToC. It might be also the case where a CMI requires type-specific certification on lower levels of cloud computing model in order to ensure the security property holds for the ToC.