The goal of the MEDINA project is to design and develop a security framework for automated evaluation of cloud service compliance with security standards. This post aims to provide a high-level technical overview of the MEDINA framework’s contents and introduces the functionality of MEDINA by outlining the workflow of each component and how cloud service providers (CSPs) and their auditors can use MEDINA for evaluation of their services.

Let’s browse through the MEDINA components, roughly following the flow of data starting at the standard’s specification through gathering and processing of the evidence, and finally arriving to the decision about the validity of the certificate according to the specified standard.

Understanding the standard

The structure and contents of the certification scheme are stored in the MEDINA Catalogue of controls and security schemes. This component acts as a database storing all the required information about the controls and requirements of various certification schemes (although MEDINA primarily focuses on the EUCS), as well as metrics that define how compliance can be (automatically) monitored. It makes this data available for review both to human users and, via an API, to all other MEDINA components.

Closely connected to the specification of standards is a set of natural-language processing (NLP) components that analyse the requirements described in the specification of standards in natural language (NL) and using them to derive metrics and machine-readable rules for assessing evidence according to these metrics. The NL2CNL Translator is used to select from existing set of metrics those that best match the individual requirements of the standard.  Natural language is thus translated into an intermediary controlled natural language (CNL), describing the mapping of metrics to requirements. This mapping can be manually refined by experts using the CNL Editor. Another related component, the DSL Mapper, converts the CNL into rules in a domain-specific language (DSL).

Collecting and assessing evidence

The mentioned DSL rules are understood and used by the security assessment components to evaluate the measurements performed by the evidence collection tools and produce assessment results expressing compliance (or incompliance) of a specific monitored resource (e.g. a virtual machine, a software service, a database…) with a particular metric. MEDINA provides a generic security assessment component integrated with Clouditor as well as support for externally provided assessment tools if they follow the specifications of the corresponding MEDINA APIs.

As mentioned, measurements are performed by various evidence gathering tools. These tools detect the state of particular cybersecurity aspects in the environment where the evaluated cloud service is running.

MEDINA integrates the following evidence gathering tools:

• Clouditor, an evidence gathering tool that connects to the API of the CSP’s IaaS cloud provider and evaluates metrics related to the configuration of cloud infrastructure and services, e.g. whether data backups of virtual drives are enabled, whether databases meet the required encryption standards, etc.
• Wazuh, an intrusion detection system with agents installed on the monitored VMs provides measurements related to monitoring of the anti-malware software operations and alerting in case of errors or intrusions.
• Vulnerability Assessment Tool (VAT) that can automatically trigger vulnerability scans towards the cloud service infrastructure to find vulnerabilities in the software or configuration of servers. It also provides a vulnerability management and alerting platform.
• Codyze, an evidence gathering tool specialized in detecting software vulnerabilities through static analysis of source code and software dependencies.
• MEDINA is also developing a special component for gathering of organisational evidence. The organisational evidence component analyses documents that include organisational policies of the CSP and helps to provide evidence for compliance with organisational requirements of certification.

As the evidence is processed by the security assessment component, its output (assessment results) is sent to the Orchestrator, which stores it in a permanent database and forwards it to other components for further processing, as well as to the Evidence Trustworthiness Management tool which stores a copy of the evidence in a blockchain to ensure the integrity and authenticity of the gathered data.

Final processing and certificate state evaluation

In the next stage of the MEDINA workflow, three additional components take care of the final evaluation of the certificate status: Continuous Certification Evaluation (CCE), Risk Assessment and Optimisation Framework (RAOF), and Automated Lifecycle Manager. CCE receives assessment results and continuously generates an evaluation tree indicating the level of compliance with the standard’s requirements, controls, and control groups. When an incompliance is detected, information about it is sent to RAOF, where risk analysis determines its impact on the overall security level of the observed system. Based on the results of CCE and RAOF, as well as previous evaluations, the Lifecycle Manager finally decides whether the observed cloud service is eligible for the certification or not.

To assist auditors or internal compliance managers, the review of collected measurements, evidence and detailed compliance status is supported by the MEDINA Integrated UI, which binds the interfaces of all necessary MEDINA components into a single point of user interaction. Alternatively, communication via APIs is enabled in all parts of the MEDINA framework for easier integration with custom data collection and processing or UI solutions.

For more details on each component keep following the blog or check the MEDINA deliverables.