Cloud security and network file storage safety 3D illustration concept. Information upload to server for encrypted and password protected database hosting. Access to safe backup tech with web key.

Towards Automated Cloud Security Certification

Obtaining a cloud security certification requires a lot of preparation time, which mainly involves manual processes that are prone to error. In other words, several employees cannot perform their usual duties during an audit preparation. Our Clouditor tool aims to improve this process by making audit preparations more systematic and automatable. This makes it possible to continuously monitor cloud services and check their compliance with a cloud security catalog such as BSI C5[1], EUCS[2], or the CCM[3].

Why certify your cloud service in the first place?

The trend of companies using the cloud is not new – but still growing. Even small and medium-sized businesses are increasingly considering using the cloud, mainly for cost reasons[4].

The question arises why a company would want to have its cloud service certified anyway. We have identified the following three main reasons:

  1. Customer trust: A company can build trust with its customers by demonstrating that it adheres to common standards in the field, e.g., by featuring the respective certification labels on its website.
  2. Contractual duties: A common reason for certification today is that a contractor insists that its partner be compliant with a certain certification catalog.
  3. Regulatory intervention: National or supranational (e.g., the EU) legislation requiring companies in certain domains to comply with respective standards. We will take a closer look at the European certification ecosystem in the following section.

Standardization in the EU

We are shifting to a new way of doing security certification in the EU. Currently, the situation is a patchwork among European nations. Each nation has its own standardizations for certain domains. In Germany, for example, there is the Cloud Computing Compliance Criteria Catalogue (C5) addressing the cloud domain or the Medizinproduktegesetz (MPG)[5] addressing medical devices.

While the latter has already been officially replaced by the new European-wide MDR (Medical Devices Regulation)[6], the C5 is still the standard for cloud computing in Germany. This is likely to change. There is a new European candidate in the pipeline, the European Cybersecurity Certification Scheme for Cloud Services (EUCS).

There are two main drivers bringing the EUCS into play: The EU Cybersecurity Act[7] and the EU Cyber Resilience Act[8].

The Cybersecurity Act went into effect in 2019 and sets up a uniform framework for security certifications. Based on Article 48, the European Union Agency for Cybersecurity (ENISA)[9] proposes a candidate scheme, the EUCS. This is a security catalog for cloud services. In fact, one of its main references is the C5. As in the medical field, the goal is to replace national standards with the EUCS.

However, it is not mandatory to become certified – at least not yet. In the EU, the CE label on (physical) products indicates that these “meet EU safety, health, and environmental protection requirements.”  Under the proposal for the EU Cyber Resilience Act (CRA), efforts are being made in the EU to apply this approach analogously to digital products as of 2025. The definition of such products is that they have at least some “digital elements.” Thus, they can be software-only or hardware products. These labels are intended to build trust, strengthen security in EU products, and provide more transparency to EU citizens. The objectives in the proposal, including showing compliance with a security framework and being transparent to customers, are already a good indicator that cybersecurity certifications are part of the bigger picture. In addition, the proposal aims to interact with other EU regulations, e.g., the EU Cybersecurity Act. And as we have just learned, this act proposes the EUCS in turn.

The certification process today (overview)

Let us look at the procedure of becoming certified. For demonstration purposes, we will use a running example. A global company, HyperIoT, operates an industrial IoT cloud service. To ensure the resilience and availability of services in different countries, they utilize various public cloud providers, including Microsoft Azure and Amazon Web Services (AWS). These providers offer a multitude of resources, such as virtual machines (VMs), storages, networks, and functions, with each provider having tens of thousands of these resources.

There are many logistics companies that are convinced of the service’s benefits for improving their productivity in asset tracking and fleet management. However, their policies require HyperIoT to be compliant with EUCS, e.g., to be sure they process data in a secure way. A certification process could take place as follows:

Since the certification includes information security aspects, the person in charge is HyperIoT’s chief information security officer (CISO).

To obtain the certification, an audit has to be conducted. In order to ensure a successful audit and manage the extensive documentation involved, it is advisable to seek third-party expertise. To assist in gathering the necessary information, evidence, and documents for the audit, as well as ensuring the accurate completion of paperwork, HyperIoT hires consultants.

Since the CISO cannot handle this alone, more employees are involved for support. The CISO, consultant, and other involved employees are in constant communication and meet on a regular basis to discuss further actions and what has to be improved.

When all necessary evidence has been gathered and the documents are ready, it is time to conduct the actual audit. For this purpose, an auditor visits the company and checks the collected information, e.g., policy documents and a sample of resource configurations.

Can the audit process be automated?

Typically, the audit preparation and the audit itself do not involve much automation. In fact, a common way to organize the audit preparation is to collect evidence in large Excel spreadsheets. While many certification requirements make it difficult to introduce automated evidence collection and assessment, more recent standards, such as the upcoming EUCS, even specifically require the automated monitoring of some technical requirements. We firmly believe that incorporating automation is crucial:

  • Audit preparation is an error-prone task. There are many employees involved, so the human factor is involved as well. Collecting a large amount of evidence and entering it into Excel spreadsheets is a task that is sure to lead to errors made by humans.
  • It comes with high costs. As seen in the image above, the audit preparation takes about 3 to 5 months, in which the employees involved must look for and provide evidence. Thus, the company spends a lot of money on document acquisition since employees must work on these tasks instead of doing their regular work.
  • It is not future-ready for upcoming EU regulations. The biggest downside of this manual approach has already been mentioned, namely the regulatory situation with CRA. In the current version of EUCS, some requirements demand the continuous monitoring of cloud resources. The fact that certifications granted in the EU will play an important role in the CRA is generally agreed upon among experts in the industry. Even if the CRA did not include the EUCS, this scheme will likely replace national certification catalogs; this means that German companies that are compliant with the C5 today will most likely seek to be compliant with the EUCS “tomorrow.” Returning to the subject, the requirement of “continuous monitoring” of a company’s assets would make an audit preparation in the classic sense, a one-time manual preparation, simply impossible.
  • “Sleep factor” of the CISO (as we call it). A non-negligible fact we identified in our projects and when talking to CISOs is that they want to have a holistic view of their current (multi-)cloud setup at any time. Manually collecting documents for an audit that takes place every two years is not helpful in a world of fast changing cloud systems. Automated processes allow CISOs to sleep well since they know the company is audit-ready at any time.

Automation is thus not only practical for improving the security posture and saving costs; it will likely also be required in the future. And that is where the Clouditor comes into play. However, the entire certification process cannot be automated. For example, as of today, the actual audit still has to be performed by a verified auditor. We cannot eliminate the complete preparation process either, since there is always evidence that cannot be obtained automatically. Consider “physical” security, for example. However, even for these cases, we have a (not fully automated) solution in mind; more about that later.

Our solution: The Clouditor

We are building the Clouditor to automate audit preparation as much as possible. CISOs should be able to take advantage of continuous monitoring to avoid high personnel costs and human error. And, of course, to assure that the system’s compliance is audit-ready at any time.

As described above, we cannot retrieve all kinds of evidence automatically. However, for technical evidence that can be retrieved automatically, the Clouditor is the right solution. In the following, we briefly describe the architecture and functionality of our tool, accompanied by our running example.

The Clouditor follows a microservices architecture. In the following picture, you can see a simplified view of the Clouditor, in which each oval box represents a microservice:

Using the APIs of the respective cloud systems or of instantiations of the container orchestration platform Kubernetes[10] (top of the picture), the Clouditor checks the configurations of the resources deployed in these systems. This task is performed by a system-specific discoverer. The collected information (configurations) is then stored as evidence. This evidence has a unified format that is based on an ontology for describing cloud resources; see also the work of Banse et al.[11]. This abstraction allows rules to be defined for it without knowing the specific details of the cloud systems (since each cloud, of course, has its own way of defining its resources). Thus, for a new cloud connection (e.g., to the Google Cloud[12]), we would build a new discoverer that uses the respective API, converts the information into the ontology-based evidence format, and send it to the assessment component. In our example, HyperIoT uses hundreds of VMs, distributed across AWS and Azure. Both of our cloud discoverers, namely AWS Discoverer and Azure Discoverer, retrieve the configurations for each VM in the respective cloud and transform it into our evidence format, which is then forwarded. An example of such evidence can be seen in the following:


“id”: “83f0ef13-1341-4704-89f3-c314a1b56079”,

“name”: “Location Tracker”,

“type”: “VirtualMachine”,

“resource”: {

“automaticUpdates”: {

“enabled”: true


“malwareProtection”: {

“enabled”: true



The assessment component then evaluates the incoming evidence according to a set of rules. As of today, standards are written in natural language. Therefore, “metrics” are used in the domain of cloud certifications. Here, metrics are technical rules extracted from the requirements of the respective catalogs that measure the properties of a cloud resource (the evidence). You can see it as a machine-readable representation of a requirement, where one requirement is bundled in one or more metrics. These metrics adhere to the format of the ontology, making it consistent with the retrieved evidence sent by the discovery components. There is a movement to try to use a more machine-readable approach, see OSCAL[13], but we are not there yet. Consequently, one of our main tasks is to define such metrics using a catalog in natural language. As an example, here is a simple rule measuring if automatic updates are enabled (written in the policy language Rego[14]):

compliant if input.automaticUpdates.enabled == true

Now you can see how the ontology prescribes the way an AutomaticUpdate feature has to be set by the discoverer (creating the evidence) so that the assessment can apply the metric to it (using dot notation).

The results of the rules applied to the evidence are the assessment results, and these are sent to the orchestrator. The orchestrator is the heart of the Clouditor, because it is the interface to the outside world, internally controls the components, and stores the necessary information (metrics, assessment results, and catalogs) in a database.

For data protection reasons, the assessment forwards the evidence to the evidence store. The idea of separating the evidence store from the orchestrator arose when we thought about how the Clouditor could be offered. In the case of a cloud-hosted or a software-as-a-service solution, Clouditor users could deploy the evidence store on premises to keep the evidence in their hands.

Finally, we want the user to be able to inspect the evidence, assessment results, etc. in one unified view. Therefore, it is possible to see the whole state of the system on the dashboard. In case of non-compliance, you can follow the path to evidence that is misconfigured and make corrections accordingly. There is also the command line interface (CLI), which you can use to interact with the Clouditor on the terminal instead of a GUI. Since we want to support the whole certification process in the future, we are also conducting research on the automation of certificate maintenance in the context of the project MEDINA[15].  Hence, we have already prepared the storage and view of certificates as well.

The future Clouditor: Next steps

We are currently working on improving Clouditor’s support for the certification process:

  • Support of more (cloud) systems, e.g., the Google Cloud and Office 365 Security Data
  • Support of more catalogs, e.g., addressing domain-specific regulations such as the Medical Devices Regulation (the legal framework for medical devices within the EU)
  • A result document indicating which requirements are already fulfilled and which are not. This document then can be inspected by the auditor conducting the audit.
  • The possibility to evaluate requirements not covered by the Clouditor itself – either manually via UI (with evidence, of course) or via external tools, e.g., business processes via provided APIs.

The last step would enable the Clouditor to take as much work as possible from users, leaving them as little manual work as possible.


Doing certifications can be time-consuming and error-prone. We are building a solution to improve the audit preparation by adding automation. Today, almost the whole company certification process is still done manually, i.e., many employees are involved.

Compare the process of today (see picture above) with the process using Clouditor:

With our solution, you can automatically check the configurations in cloud systems or systems using Kubernetes. You can see which resources are deployed and what their compliance status is according to the chosen catalog. There will still be some tasks that can only be performed manually (top right corner). However, with Clouditor, the number of these manually performed tasks decreases significantly, and we relieve employees of tasks that can be done automatically. We also plan to integrate external tools to increase the coverage of cloud catalogs even more.

Note that an audit has to be carried out frequently (e.g., yearly), which always consumes a lot of time when everything is done manually. As you can see, using the Clouditor can save a lot of time and resources as well as reduce human errors and, hopefully, lets the CISO sleep well.

If you want to learn more details, either visit our GitHub page[16] to browse our freely accessible open-source repository or simply contact us. You are also very welcome to contact us if you have any suggestions for improvements.

Nico Haas

After completing his Master’s degree in Computer Science at the University of Stuttgart, Nico Haas joined the Service and Application Security department at Fraunhofer AISEC in 2021. His primary work involves research and development in the area of cloud security, with a specific focus on Continuous Cloud Security Monitoring and Certification.

Most Popular

Never want to miss a post?

Please submit your e-mail address to be notified about new blog posts.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.
Bitte füllen Sie das Pflichtfeld aus.

* Mandatory

* Mandatory

By filling out the form you accept our privacy policy.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other Articles

Headerbild zum Blogartikel "Neue Studie zu Laser-basiertem Fehlerangriff auf XMSS" im Cybersecurityblog des Fraunhofer AISEC

Fraunhofer AISEC commissioned by the German Federal Office for Information Security (BSI): new study of laser-based fault attacks on XMSS

To ensure the security of embedded systems, the integrity and authenticity of the software must be verified, for example through signatures. However, targeted hardware attacks enable malware to be used to take over the system. What risks are modern cryptographic implementations exposed to? What countermeasures need to be taken? To answer these questions, Fraunhofer AISEC was commissioned by the German Federal Office for Information Security (BSI) to carry out a study of laser-based fault attacks on XMSS. The focus is on a hash-based, quantum-secure scheme for creating and verifying signatures based on the Winternitz One-Time-Signature (WOTS) scheme.

Read More »

Anomaly Detection with Quantum Machine Learning – Identifying Cybersecurity Issues in Datasets

Since the release of ChatGPT, the popularity of Machine Learning (ML) has grown immensely. Besides Natural Language Processing (NLP) anomaly detection is an important branch of data analysis whose goal is to identify observations or events that deviate from the rest of the data. At Fraunhofer AISEC, cybersecurity experts explore Quantum Machine Learning methods for anomaly detection. One approach is based on the classification of quantum matter while a second method uses a type of Quantum Support Vector Machine with a kernel that is calculated on a quantum computer. This blog post explains the fundamentals of anomaly detection and shows the two approaches being pursued by the Quantum Security Technologies group at Fraunhofer AISEC.

Read More »

Towards Automated Cloud Security Certification

Obtaining a cloud security certification requires a lot of preparation time, which mainly involves manual processes that are prone to error. In other words, several employees cannot perform their usual duties during an audit preparation. Our Clouditor tool aims to improve this process by making audit preparations more systematic and automatable. This makes it possible to continuously monitor cloud services and check their compliance with a cloud security catalog such as BSI C5[1], EUCS[2], or the CCM[3].

Read More »

gallia – An Extendable Pentesting Framework

gallia is an extendable pentesting framework with the focus on the automotive domain, developed by Fraunhofer AISEC under the Apache 2.0 license. The scope of the toolchain is conducting penetration tests from a single ECU up to whole cars. Currently, the main focus lies on the UDS interface but is not limited to it. Acting as a generic interface, the logging functionality implements reproducible tests and enables post-processing tasks.
The following blog post introduces gallia’s architecture, its plugin interface, and its intended use case. The post covers the interaction between its components and shows how gallia can be extended for other use cases.

Read More »