Our mission
Future of compute - green, open, efficient

Blog.

Minimum requirements for the use of cloud offerings by the public sector - Version 2

Written by Marius Feldmann (Cloud&Heat), Peter Ganten (Chairman of the OSB Alliance, Univention), Bernhard Hecker, Stephan Ileander (initially Stefan Herold; STACKIT), Timo Levi (Deputy Chairman of the OSB Alliance, T-Systems International), Kai Martius (secunet), Rainer Sträter (IONOS)
Cloud&Heat | OSBA | Position Paper "Minimum Requirements for the Use of Cloud Offerings by the Public Sector - Version 2".

The publication of the document "Minimum requirements for the use of cloud offerings by the public sector" in autumn 2022 has generated a broad, positive response. We were approached by many institutions, received much applause and many ideas for further specification. We summarise these here in the present version 2.

The federal, state and local governments are facing massive and urgent tasks in the area of digitalisation. To solve them, the public sector is increasingly relying on the use of cloud offerings. However, there are particular requirements for the administration in terms of the
protection of data as well as to sustainably ensure the operational and design capability of digital infrastructures. Open source software is particularly well suited to meet these requirements.

Protection of data, services and infrastructure

The state must effectively protect citizens' personal data as well as its own confidential information from unauthorised access. To do this, it must maintain control at all times over who may access which data, when and under what circumstances.
In addition, economic dependencies and the danger of resulting political constraints must be avoided so that the state is also resilient in cases of crisis or disaster and can ensure the continuous availability of elementary state functions. To this end, the operational capability of important digital infrastructures and services must be guaranteed, functionally controlled and adapted to new needs independently of the interests of states or companies that cannot be influenced or are difficult to influence. The capabilities to control data flows and to use and shape information technology together form the basis of the state's digital sovereignty.

Create and strengthen digital sovereignty

Even without the use of cloud computing, critical dependencies already exist today, for example in workplace productivity functions, which have created significant challenges in the area of digital sovereignty. In 2019, for example, these were outlined in the final report of the study commissioned by the Federal Ministry of the Interior, for Construction and Home Affairs. PwC study "Strategic market analysis to reduce dependencies on individual software providers". presented in detail.

In addition, cloud computing poses the risk of far-reaching dependencies, for example because cloud operators can independently define and change the rules for access to data or for the expansion of their own offerings by third parties. The use of third-party infrastructures also reduces the possibility of controlling data flows. The use of cloud computing therefore makes it
It is imperative to assess such potential dangers and to deal with them consciously so as not to be unexpectedly confronted later with dependencies that are economically, technologically or even politically expensive to pay for. Not least for this reason, a significant strengthening of Germany's digital sovereignty became an important component of the 2021 Coalition agreement of the current federal government as well as the leitmotif of the 2022 Digital strategy for Germany.

In the area of tension between the great benefits of cloud computing on the one hand and the danger of considerable dependencies with potentially dramatic consequences on the other, the state and the administration must now find a way that allows the potential of cloud computing to be used as well as possible and at the same time takes into account the requirements of digital sovereignty, i.e. the ability to control, resilience, and the ability to act and shape. An important instrument for this is the definition of minimum requirements, i.e. the minimum characteristics of cloud services that must be complied with, which ensure the state's ability to control and shape at all times.

"Digital sovereignty" is currently a widely discussed field in the political arena in terms of definitions and guidelines. The political goal is undisputed. In most cases, conditions are defined that are intended to avoid the onset of "dependencies". In the Paper "Strategy for Strengthening Digital Sovereignty for IT in Public Administration three requirement categories are listed (autonomy, self-determination and security), which were defined in a corresponding key points paper of the IT Planning Council.

However, the proposed regulations are, like this "state" is to be achieved is very often limited to legal and procedural aspects. Cloud providers can, for example, give assurances through declarations and contracts, compliance with which is difficult or impossible to verify. Or they grant verifiability (source code inspection) to individual parties only under strict secrecy.

However, whether the goal of "non-independence" is actually achieved depends to a large extent on characteristics of the technology used. Security in terms of independence is a result of Trustworthiness, and independence / self-determination of one of Openness (in the sense of availability and designability of technology, resilience and adaptability).

The minimum requirements derived from this must apply regardless of the size of the provider, and should accordingly not exclude any provider per se. The point is rather that the minimum requirements for securing digital sovereignty are publicly accessible and in principle can be checked by anyone. Incidentally, they are already being applied today by a wide range of German and
European cloud and software providers.

The OSB Alliance also shares the view of the Federal Government and the IT Planning Council, as stated in various papers and resolutions, that these properties in total and the strengthening of digital sovereignty can only be achieved through the use of open source software. The OSB Alliance therefore recommends that the criteria formulated here - mutatis mutandis - be incorporated into normative requirements, e.g. in the context of the
German administrative cloud strategy, the security requirements of the BSI and procurement requirements.

Safety requirements

Security plays a central role in cloud computing and requires, among other things, uncompromising compliance with minimum standards. Recognised and established security certifications of the BSI (C5) and in future of the EU (EUCS) are a minimum requirement for the operator of a cloud offering. However, they do not go far enough in terms of verifiable technical security. Instead, the security requirements formulated here should define concrete technical prerequisites for the software stack used that lead to the achievement of true sovereignty and independence. Exclusively contractual constructs or only limited availability of source code and construction details of the software do not lead to permanent independence of the cloud offering.

The criteria are intended to ensure protection against control or unauthorised access to sensitive data by third parties - also and especially by state actors - but above all to create resilience and security through independence from individual software providers. To this end, it must also be possible, among other things, for an independent, unannounced audit of compliance with security criteria to take place at any time. Furthermore, at least the following requirements must be implemented by cloud providers:

  • Cloud solutions consist of complex combinations of different software components, which must be fully documented with so-called "Software Bill of Materials" (SBOM) and made completely transparent for user organisations. It must be possible at any time to determine from the SBOM which software components in which versions the operator is currently using and whether, if applicable, updates to correct known security problems are available and these have already been integrated into the cloud offering.
  • Typically, developers and DevOps personnel work together internationally in a complex manner in the operation and further development of cloud services. On the part of the provider, it may not be possible to exclude the possibility of employees influencing the source code of the cloud and installing malware or backdoors due to the influence of foreign jurisdictions (e.g. on the basis of the US CLOUD Act) or through undue influence. It must therefore be possible to exclude the possibility of malware being installed or existing without the knowledge of the customers, for example through the possibility of source code analyses.
  • Without an insight into the source code of the software components with which a cloud service is realised, which is possible at any time, the service in question cannot be considered secure. The necessary possibility of independent verification may not be carried out unilaterally by the provider or by third parties on its behalf, but must be feasible for customers themselves at any time. Therefore, an open source solution is to be preferred for all components of the cloud.
  • The source code used must not deviate from the source code made available for testing. The equality of the versions used shall be certified, for example, by means of a checksum comparison.
  • Critical parts of the cloud solution such as user management, certificate management and issuance as well as key management are to be additionally protected by means of verifiable architectural security measures, such as those described as confidential computing.
    to hedge.
Resilience and resilience

A central aspect of resilience is operational sovereignty, i.e. the ability to operate IT infrastructure independently of third parties, to keep it secure and to adapt it to current requirements.

  • If employees who are not exclusively subject to local legislation are used for the operation, there is a risk that they may be obliged, on the basis of laws such as the US CLOUD Act, to allow third parties access to data on the instructions of the respective governments or legal systems or to jeopardise the operation of the entire infrastructure. Therefore, only employees who are exclusively subject to local legislation may be employed.
  • The software used to operate cloud services must not contain any functions which, once activated, enable access to data or endanger the operation of the infrastructure (so-called "kill switches"). The verification of such functions is practically impossible without access to the source code, which is therefore mandatory.
  • It must be ensured that software updates, in particular those to correct safety-related problems, can be made available even if this no longer corresponds to the will of the original manufacturer or of the state in whose territory the software is produced.
    legal system in which the manufacturer concerned is located.
  • Finally, adaptations to newer requirements or interfaces must also be possible independently of the original manufacturer. This is best ensured by using open source code.
  • The complexity of the entire software stack requires the development of and adherence to standards or standardised interfaces, which at best are oriented towards globally established open industry standards.
  • It must be possible to operate applications independently of the infrastructure and to ensure continued operation without major adjustments to the application even when the underlying infrastructure is changed. Therefore, the use of a universal abstraction layer between applications and infrastructure is recommended. The OSB Alliance will soon present a concept for this.
Legal requirements

When procuring cloud services by the public administration, the following legal and contractual characteristics of the respective offers must be ensured in particular:

  • All processed data (such as user data, log files, billing data, etc.) must be made available to users by the cloud provider at any time directly and/or within the framework of a certified "takeout" procedure. Go to
    Traceability, certification and any other assessment in the area of data protection and data security also requires that the software and its specific code are open source and auditable.
  • The cloud provider must ensure that the entire data storage and the technology of its processing is portable and usable with open-source software stacks on other IaaS platforms. This can be achieved, for example, through open source standards for file formats and open source software.
    representation of the algorithmic processing must be implemented. It must be technically and organisationally possible to make data processing transportable between data spaces of any provider at any time. Data spaces in this sense are based on open source
    software and the ability to run on any IaaS platform.
  • The technical and organisational measures (so-called TOMs) implemented by a cloud provider or a subcontractor must - in addition to the classic protection goals for general data and information security (including confidentiality, availability and integrity of data, as they are also named in Art. 32 GDPR) - also contain measures regarding source openness and transportability. Contracts with a cloud provider should only be concluded if source openness and transportability of the data within secured data rooms is ensured and the cloud provider provides contractual assurances in this regard.
    makes.
  • All data "at rest" or "in flight" must be encrypted at any time in a traceable manner (with open-source algorithms) and certifiable with regard to the criteria of security and portability. At the same time, it must be ensured that secure paths are used via algorithmic precautions.
    data in anonymised form or anonymously converted for evaluations, etc. Because at no time should data that is subject to special compliance requirements (such as the DSGVO) be processed in insecure contexts. The technical
    The realisation and implementation of the encryption and pseudonymisation technologies used must be verifiable and auditable.
  • Providers must be obliged to respect the rights of citizens with regard to the handling of personal data and to implement ways to fulfil data subjects' rights (such as access, deletion, right to rectification, right to erasure) in a comprehensible manner with regard to processing, implementation and storage location. To this end, open standards and open source software must be made mandatory. 
Recommendations for action for politics and administration:

Planned action by politics and administration at federal, state and municipal level is particularly important for creating and securing digital sovereignty. We make the following recommendations in this regard:

  • Clear responsibilities for describing and defining binding minimum requirements for cloud solutions must be designated at the various levels of government. The assumption of this task by the IT Planning Council as a joint instrument of the federal government and the Länder should be evaluated.
  • Minimum requirements are to be set in a multi-stage process that is transparent and iterative for the business community.
  • The requirements at national level must be closely coordinated with the European level. In this context, work towards a common procurement framework in Europe that takes into account the recommendations listed here to safeguard digital sovereignty in Europe.
  • Binding minimum requirements must be integrated as an important basis in procurement processes. In addition to the binding requirements (mandatory conditions), supplementary optional conditions should be included in the evaluation.
  • As part of the definition of the minimum requirements, a metric for measuring the criticality of cloud services should be developed. Dedicated mandatory requirements for the operator as well as the technological basis of the service should be linked to different levels of criticality to be defined. If the criticality of the services is high, all formulated requirements - such as operation in Germany by personnel with German citizenship using exclusively open source software - should be fulfilled.
  • Within the framework of procurement processes, long-term economic efficiency considerations must be carried out, which also take into account costs for the decommissioning of cloud services and the replacement of providers ("exit costs"). To reduce the costs of replacing a provider, offers where alternative providers can take over the operation of a cloud service should always be preferred.
  • When selecting cloud services, it is important to ensure that these offerings exclusively use and offer open interfaces for which there are open source reference implementations.
  • In the case of individual software development commissioned by the state, the corresponding results should always be published under an open source licence. If standard services are purchased, open source solutions should always be preferred to proprietary solutions.
  • The funding strategies of the Federal Government and the Länder for research and development activities must take into account the requirements for ensuring digital sovereignty with a special focus on open source solutions. In this way, research and development activities leading to later product developments are to be geared to meeting the minimum requirements.
    be prepared consistently from the beginning.

Authors:

  • Marius Feldmann, Cloud&Heat Technologies
  • Peter Ganten, Chairman of the OSB Alliance, Univention
  • Bernhard Hecker
  • Stephan Ileander (initial Stefan Herold), STACKIT
  • Timo Levi, Deputy Chairman OSB Alliance, T-Systems International
  • Kai Martius, secunet
  • Rainer Sträter, IONOS

More blog posts