The core focus of MEDINA project is on continuous monitoring of compliance with a new European cyber security certification standard EUCS. Risk assessment is used in the MEDINA project to support the decision making about the detected non-conformities. Risk-based approach helps to avoid a simple check list approach to this problem, and allows evaluating of non-conformities from the cloud service provider (CSP) perspective by taking into account the cyber security needs of this specific provider.

One of the main problems of risk assessment is that it requires significant amount of time, effort and knowledge to conduct such analysis. Naturally, this approach does not fit well into the overall MEDINA goal, i.e., to perform monitor compliance continuously. That is why we use Self-Assessment Tool for Risk Analysis (SATRA), which aims to collect only the basic information about the considered cloud service, like which EUCS requirements have been implemented and how sensitive the possessed resources are for the CSP.

It worth underlying again that risk assessment in Medina is primarily used to support the decision making regarding the detected non-conformities, i.e., to evaluate how important the detected deviations are for the CSP. This support is provided in two parts of the Medina process:

• the static risk assessment is to be performed before obtaining a certificate and can be used to evaluate the readiness of the CSP for the certification procedure; and
• the dynamic risk assessment is performed after every “cycle” of evidence collection during the continuous monitoring and helps to estimate whether the current state of cyber security of the cloud is good enough to maintain the certificate (and that any existing non-conformities cause only minor deviation from the full compliance).

It worth mentioning that these two modes of applying risk assessment are different also in other aspects. For example, the static risk assessment is performed by a user (e.g., compliance manager) who manually inserts data (through a guided procedure) using SATRA’s GUI. There is also a possibility to use the dedicated API to do the same analysis if a custom-made tool (e.g., a dashboard) is developed by the CSP and is able to communicate with SATRA. In contrast, the dynamic application of the risk assessment procedure is performed automatically: a MEDINA’s component responsible for aggregation of evidences (Continuous Certificate Evaluation (CCE)) provides this information through SATRA’s GUI, the risk is re-computed using this input, and the result is sent to the decision-making component (Certificate Life-Cycle Manager (LCM) for the final decision about the certificate state.

Furthermore, the static risk assessment relies heavily on a human operator who provides data for analysis. Naturally, this type of input could be incorrect because of lack of knowledge or deliberately “improved” data. Yet, it is important to underline that our static risk assessment tool is an instrument for self-assessment, and the user itself will suffer from his own mistakes or forging. On the other hand, the dynamic risk assessment relies on the measured (objective) data, which are provided to SATRA as an input by various monitoring tools through CCE. Yet, the values regarding the sensitivity levels are still to be provided by a human operator before the monitoring starts. It is worth noting that it is the dynamic risk assessment that is mostly contributing to the decision making of the MEDINA platform, and the static risk assessment is just a support for preparation for certification.

Static Risk Assessment

Our risk assessment approach follows the general risk assessment process and first, identifies and estimates the key risk components: vulnerabilities, assets, and threats. Vulnerabilities are seen as a lack of security requirements requested by EUCS standard. This information is collected through filling in a questionnaire which contains all EUCS requirements and ask the human operator to let the tool know whether these requirements are fulfilled.

Figure 1: Questionnaire

The second risk component which is to be provided by a human operator is the information about assets, i.e., a list of available cloud resources and their confidentiality, integrity and availability sensitivity levels (so called CIA triad). These levels are then to be translated in an expected monetary loss which will be further used for computation and evaluation.

Figure 2: Asset information collection for static risk assessment

The last key component, threats, is built in the tool, i.e., all threats are assessed and those that are not relevant for the CSP are to be easily ruled out since their level will be too low.

The risk computation itself is performed automatically according to our computational model. The results are twofold: first, we provide the risk value for the organization as a value between 0 and 100. In the same way risk values are reported for every single threat considered by the tool. Second, and that is more important for the MEDINA’s goal, we estimate the gap between the current and the best (full compliance) risk level. This value is to be compared with a threshold to decide whether the non-conformity is major (strongly require additional effort in security the cloud) or minor (could be neglected as insignificant) for certification.

More info: D2.5: Specification of the Cloud Security Certification Language – v3

Dynamic Risk Assessment

The dynamic risk assessment is performed through API and its results are not displayed to the operator directly (only as a part of the aggregated reports provided by other MEDINA components, e.g., LCM). The only direct interaction with a human operator is done in the beginning of the process, when the information about assets and their sensitivity levels is requested. Note, that in this case it is required to add sensitivity values for all possible resource types. This is required since the dynamic risk assessment procedure does not know a priori evidence for which resource will be sent to RAOF. Moreover, the dynamic nature of cloud may require new resources to be added or removed on the fly, i.e., during the monitoring phase. So, the risk computation tool must be ready for any possible input. Naturally, it is not required to set all value, if only a few resources are important for the CSP; not important resources may simply have “1” as the lowest cost value and will have almost no effect on the risk computation and evaluation. Yet, we also provide an opportunity to add specific resources, e.g., a database which contains very sensitive data, in contrast to any other database, which contain secondary information. In that case, an ID of the specific resource must be provided, to let the computation engine to treat this resource separately (i.e., with different sensitivity values).

Figure 3: Asset information collection for dynamic risk assessment

As it was mentioned above, the information about fulfilment of requirements is provided to SATRA from an evidence managing MEDINA component (i.e., CCE). The provided information says which requirement for which resource have been monitored and what is the status for this requirement according to the gathered evidence.

The way of gathering information about fulfilled requirements per resource opens the possibility to measure risk for each resource separately. In short, during the dynamic risk assessment it is possible to perform the analysis per resource, making sure that more sensitive resources (i.e., with higher CIA values) have higher protection. In the end, risk values per resource are aggregated to get the final estimation for the whole cloud service. Finally, the computed risk value is compared with the full compliance case and a decision about the degree of non-conformity (major or minor) is made by comparing the distance with the established threshold.

The risk evaluation result is provided to the decision making engine (i.e., LCM), which decides if the current state of practices should lead to certification revocation or the certification can be maintained. The value of the evaluation is stored by this component to support the made decision, and can be used either by the CSP and/or for an auditor to react on the current certification status.

More info: D4.5: Methodology and tools for risk-based assessment and security control reconfiguration – v2