​We are pleased to announce the release of the final deliverable on the MEDINA certification language: “Deliverable 2.5: Specification of the Cloud Security Certification Language“, final version.

In the course of the project, the partners defined, developed and integrated a set of tools that convert the EUCS security requirements, originally expressed in Natural Language (NL), into a machine-executable language. This process involves two consecutive translations: first from NL to Controlled Natural Language (CNL), and then from CNL to Domain Specific Language (DSL).

The initial translation from NL to CNL allows for the representation of a security requirement as security policies in an intermediate formal language that is still understandable to humans. The translation is via the tool named NL2CNL Translator.

The output of the NL2CNL Translator can be reviewed and modified by an experienced user, via a dedicated tool called CNL Editor.

Once the user is satisfied with the CNL policies, the second translation, known as mapping, takes place. This translation converts the CNL policies into the Medina DSL via the DSL Mapper.

Let’s take a closer look at the functionality of these three tools.

NL2CNL Translator:  it serves two primary purposes. it first selects a set of metrics that can be used to evaluate a specific EUCS security requirement. Once a set of metrics is associated with a requirement, the second objective is to translate those metrics into policies. The metrics are initially expressed in Natural Language (NL), while the translated policies are expressed in Controlled Natural Language (CNL). Not only the translator expresses requirements and metrics into CNL, but also utilizes a Metric Recommender that employs Natural Language Processing (NLP) techniques to automatically associate a set of metrics with a requirement. The association is based on text similarities between the description of the requirement and the descriptions of the available metrics.

CNL Editor: it provides a web interface that allows users to refine policies associated with a specific requirement by the NL2CNL Translator. Specifically, users can visualize the CNL statements and modify some reference values present therein. The CNL Editor employs a vocabulary that includes terms from the MEDINA Catalogue of Controls and Metrics (the repository of EUCS requirements and available metrics) to assist users in selecting target values.

Through the user interface, it is possible to

• View the list CNL policies
• Select and visualize a specific policy
• Delete the selected policy or update the target value therein.

When the user is satisfied with all the policies, she can call the functionality `map’ that invokes the DSL Mapper.

A notable advantage of using the CNL Editor is the ability to modify portions of the policies associated with a requirement. Users have the flexibility to change target values for an obligation or delete policies. This empowers the users responsible for the cloud service, as they can customize default values for target values or choose not to proceed with the assessment of some requirements.

DSL Mapper:  it maps CNL policies into executable policies expressed in Rego Language The Rego language enables the creation of policies that can be utilized to automatically assess some evidence collected by other MEDINA tools. When evaluating Rego policies, three elements are taken into account:

• Input: The request or data being evaluated
• Policy (or rule): The specific policy being applied
• (Optional) External data: Additional information used in the evaluation

The input is examined against the policy to determine if it meets the requirements, and external data may also be considered during the evaluation process.

Within MEDINA, Rego policies are employed in the following manner: Evidence collectors generate evidence that needs to be assessed using the MEDINA metrics. For example, evidence describing an object storage system may require assessment using a metric that specifies the need for backup. This task involves evaluating a request (the evidence describing the storage) against a predefined policy (the metric), sometimes with the utilization of external data (such as the target value and operator defined by the metric). The DSL Mapper’s role is to generate the policy descriptions and descriptions of the external data, while the inputs are provided by the evidence collectors.

As of month 30 of MEDINA, the three components have been fully developed, their proper functioning tested, and integration with the other components of the `Certification Metrics and Languages’ work package has been completed.