Continuous Automated Monitoring

The Continuous Automated Monitoring (CAM) component is a core service within the GAIA-X federation service. Its main goal is to provide transparency to the users of GAIA-X about the compliance of the individual services, offered in the GAIA-X catalog. The basis for this compliance are certain requirements and rules that GAIA-X itself has imposed on its system, i.e. requirements coming from the field of security, such as encryption, data privacy or interoperability. Often, existing standards such as the BSI C5 or EUCS are used as a point of reference. The purpose of the CAM service is to automatically gather evidence that hint to a fulfil of those requirements by a certain GAIA-X service as a whole or by a concrete instantiation of a particular service by a user. This is especially necessary if the offered services are dealing with sensitive data and thus need to have a higher assurance level, i.e., compared to the assurance level “high” in the EU Cybersecurity Certification.

This is achieved by automatically interacting with the service-under-test using standardised protocols and interfaces to retrieve technical evidence. For example, to check for the fulfillment of requirements regarding transport encryption, the CAM service might interact with the service using the TLS protocol and gather technical evidence regarding the used TLS version ans well as employed cipher suites. This evidence is then later compared, i.e. evaluated, against a set of common best practices also referred to in the compliance catalogs. In the example, best practices from the BSI state that at least TLS version 1.2 should be used.

The Figure shows an overview of the envisioned overall architecture of the CAM and its components, according to the ArchiMate standard. In the following, each major component is described briefly.

GX CAM Requirements Manager (GX-CAM-RM): The main purpose of this component is to manage requirements and to interface with external services, to initiate the continuous monitoring process. Therefore, the CX-CAM-RM needs to hold a set of possible controls that are suitable for monitoring as well as a mapping to the technical Collection Module (see below), that implements a metric for the particular control.

GX CAM Collection Module Manager (GX-CAM-CMM): This component can be seen as a collection of different Collection Modules. Each collection module is responsible to collect technical evidence for the fulfilment of a control according to a specific metric. We differentiate between different classes of collection modules. Also new modules can be registered. Within the first iteration of this specification, a minimum set of four classes is specified:

  • Public Registry Collection Module, which gathers additional security and certification related information from public registries (including the GAIA-X federated services catalog), e.g., additional security certification a service already holds.
  • Communication Security Collection Module, which uses test-based [cite] approaches to assess the communication security of critical parts of the GAIA-X service, e.g., by measuring the quality of a TLS connection.
  • Authentication Security Collection Module, which may use test or monitoring-based approaches to assess the quality of employed authentication and authorization techniques by the cloud service. Possible metrics could include correct implementation of state-of-the-art protocols, such as OAuth/OpenID, which also would fulfill requirements with regards to interoperability.
  • Workload Configuration Collection Module, which lastly gathers security and privacy related configuration information about a particular instantiation of a GAIA-X service. Whereas the first three modules gather information that applies to the services as a whole, the last module depends on the actual instantiation of the service for a particular user of the GAIA-X ecosystem. It uses test-based approaches and available standards APIs offered by the cloud provider, such as OpenStack or Kubernetes

All collection modules in common produce technical evidence, which is then transferred to the evaluation interface of the GX CAM Evaluation Manager. 

GX CAM Evaluation Manager (GX-CAM-EM): After collecting the technical evidence by the GX-CAM-CMM, the evidence needs to be evaluated to which degree it demonstrates the fulfilment of a control or requirement. For example, the technical evidence might conclude that TLS version 1.0 is used. However, a control or requirement would state that only state-of-the-art TLS versions, i.e., > 1.2, should be in use. In this case, the evaluation would fail and an evaluation result representing this would be generated. This result can then be queried, either by the dashboard or other interested and authorized parties.

GX CAM Dashboard: This component is used to visualize the evaluation results using a modern web application.

Note, that there is no central persistence layer demonstrated in this approach. This is intentional, since each component of the service can be distributed and should work independently. Thus, it is within the scope of each component to address the necessary persistence. Specific components, such as the collection modules may even choose not to persist information at all.

Specification document