The main objective of MEDINA is to provide a tool for CSPs (Cloud Service Providers) that allows them the achievement of a continuous auditing and certification of Cloud Services aligned to the EU Cybersecurity Act, all this in an automated and almost real time manner. This post describes the architecture of the software framework behind the tool, the parts in which the MEDINA tool is divided, and related issues to operate and deliver it.

Overview

In a previous post we provided a high-level technical overview of the MEDINA framework based  in the functionality of each component by outlining the evaluation workflow. In this article we will focus more into the whole picture. To start, there is not a good architecture description without a diagram, so here’s ours:

Building blocks of the MEDINA framework.

The architectural framework proposed by MEDINA can be abstracted in the eight building blocks shown in the figure. Each block corresponds to a well differentiated functionality of the tool, that will be developed and further refined in the upcoming months, and finally instantiated in the two use cases of MEDINA project.

The building blocks

The first building block relates to the set of catalogues being required by the different roles and personas interacting with MEDINA, and comprise the elements of a control’s framework like EUCS. We call it catalogue of controls and security schemes. It also includes things like Technical and Organizational Measures (TOMs), reference implementations, and equivalencies among controls in different schemes.

The second block implements the Natural Language Processing (NLP) techniques proposed by MEDINA to guarantee that new requirements from EUCS -or other secutity schemas- are related to the metrics in the catalogue. This block leverages a novel ontology to guarantee that requirements written in natural language are automatically associated to CSP-specific resources. Our goal is to automatize the current (manual) process performed by compliance managers and auditors to interpret, map, implement, and assess requirements in their organizations.

The risk assessment functionalities provided by MEDINA, both static and dynamic, form the third building block of the architecture. Those functionalities take as input the MEDINA catalogue of controls and security schemes and, based on the CSP’s risk appetite and assessment results, can control the certification lifecycle (see building block 4).

The fourth building block in our framework comprises the components that manage the lifecycle of the certification, which depends on the rules established by the corresponding scheme (EUCS in the case of MEDINA). National Certification Bodies (NCB), or even pan-European entities like ENISA, can benefit from by becoming public registers of issued certificates. Our goal is to provide fully automated lifecycle management, which depends on dynamic risk assessment techniques and the automation of the security assessment processes implemented by MEDINA.

A state of practice challenge for providing automation of auditing/certification relates to the processing of organizational measures, where related documentation of the CSP (e.g. security concepts, operation manuals) is assessed for conformance with the certification scheme’s requirements. Building block five in MEDINA’s framework implements both a repository for those organizational evidences, and the NLP-based techniques for their processing.

Complementary to this functionality in MEDINA, is building block seven, which provides the assessment of technical measures by integrating a variety of tools (Clouditor, Wazuh, Codyze and others) including native CSP functionalities. This block is heading to the multi-layer assessment of the target-of-certification cloud service i.e. the related IaaS, PaaS and SaaS stack.

All gathered assessment results, either from organizational (block 5) or technical measures (block 7), are holistically stored and processed by the components shown in building block 6. An orchestrator, in charge of managing the collected evidences and assessment results, and a DLT-enabled evidence manager, that guarantees tamper proof storage of evidences, are core components of this building block.

Finally, building block 8 provides a MEDINA user interface to facilitate human interaction with the rest of components. Take for example a corporate compliance manager who visualizes the near real-time status of issued EUCS certificates, or an external CAB reviewing the evidence used for a certification process.

Operating environment and deployment models

During the development, the MEDINA framework is available on a test-bed environment that serves to test and verify all the functionalities. The Test Bed environment is setup with a three nodes Kubernetes cluster with two different, independent and isolated virtual environments: development and test. All the micro-services are containerized and communicate each other with RESTful APIs over HTTPS secure protocol. The micro-services cluster are packaged in Docker images and stored on a private Docker registry running on Artifactory.

Kubernetes cluster installation with RKE

The final deployment model will depend on both the business model finally defined and on the requirements of the certification stakeholders. From the technical point of view, most of the MEDINA components can be offered as Web Tools (SaaS) accessible through a browser, or as containerized tools. * This second option, where the web applications are installed locally, is mandatory for the KR4-Evidence Management Tool).

• Repository of metrics and measures (KR1)
• Risk based selection of controls (KR2)
• Certification language (KR3)
• Continuous evidence management tool (KR4) (* only containerized)
• Cloud certificate Evaluator (KR5)
• Auditor Tool (KR6).