Skip to main content

TR 03187-Conformance Statement

CIVITAS/CORE conforms to Level 1 of BSI TR-03187, a German security recommendation for Urban Data Platforms. In the context of BSI TR-03187, CIVITAS/CORE implements requirements that pertain to "Entwickler" (Software Developers) and "Lösungsanbieter" (Integrators). Requirements that pertain to "Betreiber" (Operators) are out of scope.

The following sections detail how the pertinent requirements of BSI TR-03187 are fulfilled in CIVITAS/CORE.

Generated from https://gitlab.com/civitas-connect/civitas-core/requirements (labels: requirement-source::tr-03187, tr-level::1) at 2025-12-17T14:05:56.227104+00:00

[TR-03187] AR-1 Geringstmögliche Privilegien​

Implemented through Security Architecture Principles for components developed by CIVITAS/CORE.

3rd Party Components: Todo.

[TR-03187] AR-2 Legacy-Clienttechnologien vermeiden​

For components developed by CIVITAS/CORE, linter checks ensure that no legacy components are present (for details see implementation ticket).

Todo: check 3rd party components.

[TR-03187] AR-3 Nicht verwendete Abhängigkeiten entfernen​

SSDLC policy (Section 6.6) and the Deployment Checklist (section "Production Requirements") mandate a reasonable effort to be made towards minimizing shipped artifacts.

Todo: make reasonable effort to check 3rd party components.

[TR-03187] AR-4 Version Pinning​

Ensured through Deployment Standards for container images (section "Version Management"), Front End Style guide for npm (section "Imports / Exports") and Back End Style guide for Java (section "Imports")

[TR-03187] AR-5 Sitzungs-IDs zufällig und eindeutig​

Level 4 UUIDs mandated through Backend Style Guide (Section "Security").

Todo: check 3rd party components and already implemented code.

[TR-03187] AR-6 Sitzungsablauf nach Inaktivität​

To be implemented

[TR-03187] AR-7 Rollenbasierte Benutzerverwaltung​

Role-based user management is implemented. Users are assigned role "Standard User" on registration. For details, see Authorization Data Model

[TR-03187] AR-8 Replay-Schutz​

User authentication is performed system-wide by OpenID Connect. For this, JWT tokens are used. JWT tokens are signed and have timestamps.

To do: Kafka messages?

[TR-03187] AR-9 Geheimnisse müssen änderbar sein​

As per SSDLC (section 9) and Deployment Standards (Section "Security"), secrets are stored through Kubernetes secrets or other secure means external to the application, in a changable manner.

Exception: Keycloak stores secrets (passwords, signing keys) in database; all of them are changable through regular Keycloak mechanisms.

[TR-03187] AR-10 Geheimnisse von Benutzern dürfen nicht zur Sicherstellung von Vertraulichkeit verwendet werden​

CIVITAS/CORE does not use user supplied secrets to ensure confidentiality toward third parties. The requirement is also part of the Security Architecture Principles.

Todo: check 3rd party components

[TR-03187] AR-11 Kryptografische Verfahren sollen TR-2101-1 entsprechen​

Requirement to use BSI-approved cryptography is part of Backend Code Style Guide and of Deployment Standards.

To do: ensure 3rd party component conformance.

[TR-03187] AR-12 Standardframeworks für sicherheitskritische Funktionen​

Ensured through inclusion in Security Architecture Principles document.

[TR-03187] AR-13 Ganze Zertifikatkette validieren​

On the ingress side, TLS validation is Operator's responsibility. For in-cluster validation, the service mesh is configured to ensure full chain validation (details tbd)

Todo: actually implement this and link to documentation.

[TR-03187] AR-14 Alle vorgesehenen Sicherheitsmechanismen defaultmäßig anschalten​

Ensured through Security Architecture Principles and Deployment Standards.

[TR-03187] AR-15 Verschlüsselte Kommunikation​

Encryption between container instances is implemented through TLS via a service mesh.

Todo: actually implement this and link to documentation.

[TR-03187] AR-17 Integritätsgeschützter Kanal für Deployment​

CIVITAS/CORE is deployed as source code and helm charts through Gitlab and container images through Gitlab container registry. Gitlab enforces TLS, so integrity and authentication are ensured.

TODO: implement signing for containers

[TR-03187] CT-1 Container-Hardening​

Enforced through Deployment Standards (section "Security")

[TR-03187] CT-2 Werkzeuggestützte Prüfung auf Container-Sicherheitslücken​

Trivy scans are used to scan container images. (implementation ticket)

[TR-03187] CT-5 Geheimnisse zur Laufzeit dynamisch bereitstellen​

As per SSDLC (section 9) and Deployment Standards (Section "Security"), secrets are stored through Kubernetes secrets or other secure means external to the application, in a changable manner.

[TR-03187] CT-6 Gehärtete Clusterknoten​

Since CIVITAS/CORE assumes it runs on an existies kubernetes cluster, this requirement is out of scope for CIVITAS/CORE.

[TR-03187] CT-8 Geringstmögliche Privilegien für Container-Images​

Containers do not run as root. This is ensured through Deployment Standards (section "Security").

[TR-03187] CT-9 Transportverschlüsselung & Integrität zwischen Pods​

Encryption between container instances is implemented through TLS via a service mesh.

Todo: actually implement this and link to documentation.

[TR-03187] MS-3 Vermeidung fester Credentials für Managed-Service-Zugriffe​

Not applicable, as any possible managed service access is outside the scope of the application's design.

[TR-03187] AUT-1 Einheitliche Vertrauensniveaus in der Authentifizierung​

Authentication is centralized through Keycloak. For Keycloak, no fallback methods (e.g. password reset through security questions) are defined.

(Implementation ticket)

[TR-03187] AUT-2 Multi-Faktor-Authentisierung​

CIVITAS/CORE uses Keycloak as the identity provider for all components. In the default installation, MFA is enabled.

(Implementation ticket)

[TR-03187] AUT-4 Kryptografisch abgesicherter Zugriff auf Infrastruktur​

As CIVITAS/CORE considers itself an application that runs on infrastructure provided by an operator, this is considered an operator requirement from a CIVITAS/CORE perspective.

For operators that want to apply this requirement to CIVITAS/CORE itself, a cryptographically secured authentication mechanism is available through Keycloak's support of WebAuthN.

(Implementation Ticket)

[TR-03187] AUT-7 Passwortrichtlinien​

CIVITAS/CORE uses Keycloak as the identity provider for all components. By default, a strong password policy is active.

Todo: (Implementation ticket)

[TR-03187] W-4 Restriktive CORS-Policy​

For CIVITAS/CORE components, a restrictive CORS policy applies:

  1. Access-Control-Allow-Origin only allows specific domains, not *.
  2. Access-Control-Allow-Methods only contains actually required methods (e.g. GET, POST).
  3. Access-Control-Allow-Headers is set explicitly, without wildcards.
  4. Access-Control-Allow-Credentials is only set when required.

To do: implement this

To do: check 3rd party components.

[TR-03187] W-5 Web-Server-Verzeichnisauflistung deaktivieren​

CIVITAS/CORE custom components use Spring Boot. Model Atlas uses Jetty; neither are even able to list directories by default.

Todo: check 3rd party components.

[TR-03187] W-6 Nicht benötigte Datei-Metadaten und Sicherungskopien vermeiden​

CIVITAS/CORE custom components use Spring Boot. Model Atlas uses Jetty; neither are even able to serve static files directories without specific provisions.

Todo: check 3rd party components.

[TR-03187] W-8 Kurzlebige JWTs​

CIVITAS/CORE uses Keycloak as the identity provider for all components. In the default installation, SSO Session Idle is set to 60 Minutes and SSO Session Max is set to 10h

(Implementation ticket)

[TR-03187] W-14 Standardzugangsdaten ändern​

Authentication is centralized through Keycloak, so there is only one component holding authentication data. The Keycloak admin password is randomly generated for each installation, so there are no default credentials.

Todo: Check if this is true.

[TR-03187] IoT-1 Zugang allen IoT-Ressourcen standardmäßig verweigern​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-2 Einheitlicher Zugriffskontrollmechanismus​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-3 Authentifizierung und Autorisierung für IoT-Geräte​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-4 Standardzugangsdaten ändern​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-5 Device Onboarding​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-6 Generierung von Netzschlüsseln nach Zufallsprinzip​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE. h Security Architecture Principles

[TR-03187] IoT-7 Erneuerung Netzschlüssel​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-8 Replay-Schutz​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] IoT-9 Eindeutige Identifikation von IoT-Geräten​

Not applicable, as there is no direct traffic from IoT devices to CIVITAS/CORE.

[TR-03187] VPN-1 VPN-Verschlüsselungsverfahren gemäß TR-02101-1​

Not applicable, as VPN is assumed to be handled by the Operator at an infrastructure level.

Document in a suitable "Product Scope" type document.

[TR-03187] VPN-2 Sichere Konfiguration VPN-Gateway​

Not applicable, as VPN is assumed to be handled by the Operator at an infrastructure level.

Document in a suitable "Product Scope" type document.

[TR-03187] L-3 Schutz von Logs vor unbefugtem Zugriff​

Out of scope, as all CIVITAS/CORE components only write logs to stdout without storing them. What happens to the logs afterwards is the Operator's responsibility.

The only exception are Keycloak's logs that are stored in Keycloak's database. That database can only be accessed by the Keycloak service.

Todo: ensure this is actually the case.

[TR-03187] DH-1 Verschlüsselung At-Rest​

Not applicable, as this is considered the responsibility of the operator. CIVITAS/CORE assumes encryption to be handled transparently at a volume level.

[TR-03187] DH-2 Schutz geheimer Schlüssel​

As per SSDLC (section 9) and Deployment Standards (Section "Security"), secrets are stored through Kubernetes secrets or other secure means external to the application.

Exception: Keycloak stores secrets (passwords, signing keys) in database.

[TR-03187] DH-4 Data Governance-Vorgaben etablieren​

CIVITAS/CORE provides a variety of features through which organizations can implement data governance:

  • Fine grained permission management
  • Separation of Data Sources and Data Sets
  • Data Sets, Data Sources and Data Models can have custom metadata tags
  • Data Provience tracking is enabled by making the Data Source a first-class-citizen. Furthermore, Data Sets can be Data Sources aswell, which creates a explicitly trackable graph of data provenance/data lineage *Data Sets have metadata describing the data semantically and organizational based on the DCAT-AP.de 3.0 standard

[TR-03187] ORG-7 Tests nur auf dedizierter Umgebung​

Neither Civitas Connect nor any of the members of the project team provide a production environment. Therefore this requirement is not applicable. All tests are run on dedicated environments with synthetic data. The requirement for synthetic data is part of the Security Architecture Principles.

[TR-03187] ORG-8 Penetrationstests​

Penetration Tests are planned and tracked through Gitlab Epic Penetration Test