IT-Grundschutz

Sicherheitskonzept openDesk SaaS

DISCLAIMER:
Dieses Dokument und die dazugehörigen Unterlagen befinden sich derzeit in Bearbeitung und sind noch nicht finalisiert. Konkret sind folgende Aufgaben noch nicht abgeschlossen und werden zur Zeit bearbeitet:

Vervollständigung des Big Pictures und der High Level Architektur von openDesk

Vervollständigung der Strukturanalyse, u.a. Zugriffsklärungen

Vervollständigung der Bedrohungsanalyse inkl. STRIDE-Analyse und Threat-Model

Detaillierung u.a. von Bedrohungen und Schwachstellen, Maßnahmen, Gefährdungen und Risikobehandlung

Vervollständigung der Nutzerbeschreibungen und der Rollenkonzepte

Verifizierung der organisatorischen und technischen Maßnahmen im Rahmen der Risikoanalyse

Nachgelagert eine Aufstellung der Zuordnung von BSI-Bausteinen zu einzelnen Objekten des Informationsverbunds.

Die Themenfelder “Schulung und Weiterbildung der Mitarbeiter”, “Allgemeine Themen des IT-Betriebs”, “Themen der baulichen und physischen Sicherheit”, “Bereitstellung von openDesk in einer Confidential Cloud (Vetrauliche Cloudumgebung)”, “Detaillierte Integrationsleistungen der openDesk SaaS Lösung in ein Kundennetzwerk”, “Kunden-bezogene Penetrationstests und zu testende Konfigurationen” sowie “Lizenz-Themen” werden nicht behandelt.

Dieses Dokument ist nicht als endgültige Quelle heranzuziehen. Bei Bedarf sind weitere Informationen über die entsprechenden Stellen bei der ZenDis anzufragen.

Versionshistorie

Dokumentation der Änderungen und Aktualisierungen des Sicherheitskonzepts.

Datum	Tätigkeit	Bearbeiter	Versionsnummer
10.01.2024	Erstellung des Dokumentes	Christian Wolter	v0.01
21.01.2025	Erstellen des Inhaltsverzeichnisses, Kapitel “Bedrohungsanalyse” begonnen	Christian Wolter	v0.02
13.02.2025	Kapitel “Strukturanalyse” begonnen Kapitel “Risikoanalyse” begonnen Kapitel “Modellierung der Sicherheitsmaßnahmen” begonnen	Christian Wolter	v0.03
24.02.2025	Kapitel “Definition der Schutzbedarfskategorien”, “Anwendung STRIDE”, “Erhebung der IT-Systeme von openDesk”, “Schutzbedarfsfeststellung der Zielobjekte im Informationsverbund”, “Schwachstellen” erstellt	Christian Wolter	v0.1.1
31.03.2025	Kapitel “Risikoanalyse” und “Modellierung der Sicherheitsmaßnahmen” bearbeitet und fortgeführt	Christian Wolter	v0.2
19.05.2025	Diverse Optimierungen des Konzepts für die Lesbarkeit	Dirk Loßack	v0.3

Glossar

Begriff	Definition
Informationsverbund	Ein Informationsverbund ist die Gesamtheit aller vernetzten IT-Systeme, Anwendungen und Kommunikationsverbindungen, einschließlich dedizierter abgrenzbarer Teilbereiche, die wesentliche Aufgaben und Geschäftsprozesse einer Institution unterstützen.

Inhaltsverzeichnis

Sicherheitskonzept openDesk

1. Einleitung

Software-as-a-Service (SaaS) Lösungen sind für den IT-Betrieb sowohl in der öffentlichen Verwaltung als auch in der Privatwirtschaft ein integraler Bestandteil. SaaS Lösungen bieten Flexibilität, Skalierbarkeit, Kosteneffizienz und Kostenkontrolle. Mit der zunehmenden Nutzung von SaaS Lösungen steigt auch die Notwendigkeit, robuste Sicherheitsmaßnahmen zu implementieren. Die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade) der Daten müssen gewährleistet sein. Weiterhin steigt die Bedrohungslage für IT-Systeme und digitale Infrastrukturen, insbesondere im öffentlichen Bereich, kontinuierlich. Cyberangriffe, Datenlecks und andere sicherheitsrelevante Vorfälle nehmen sowohl in Häufigkeit als auch in Komplexität zu. Daher muss jedes IT-System und jedes Informationssystem über ein robustes und umfassendes Sicherheitskonzept verfügen. Dieses Dokument dient als zentrales Sicherheitskonzept für die Bereitstellung von openDesk als SaaS Lösung, welche auf der STACKIT-Plattform betrieben wird. In diesem Dokument wird openDesk immer im Kontext der Bereitstellung als SaaS Lösung betrachtet.

1.1 Umfang und Zielsetzung

openDesk ist ein Open-Source-Entwicklungsprojekt, das vom Bundesministerium des Innern und für Heimat initiiert wurde. Es zielt darauf ab, der öffentlichen Verwaltung eine leistungsstarke Alternative zu proprietären Lösungen im Bereich des digitalen Arbeitsplatzes zu bieten.

Der Browser-basierte Arbeitsplatz von openDesk legt besonderen Wert auf:

Digitale Souveränität: Die Verwendung von Open-Source-Software ermöglicht eine unabhängige und kontrollierte IT-Infrastruktur.
Nutzerfreundlichkeit: Der Arbeitsplatz ist intuitiv und einfach zu bedienen, um die Effizienz der Verwaltung zu steigern.
Zukunftsfähigkeit: Die modulare Architektur ermöglicht die Integration neuer Technologien und die Anpassung an zukünftige Anforderungen.

openDesk unterstützt sowohl alltägliche Geschäfts- und Arbeitsprozesse als auch die virtuelle Zusammenarbeit. Dazu werden marktgängige Open-Source-Komponenten integriert und weiterentwickelt. Die IT-Architektur basiert auf:

Modularität: Die einzelnen Komponenten können unabhängig voneinander entwickelt und aktualisiert werden.
Austauschbarkeit: Die Komponenten können durch andere Open-Source-Lösungen ersetzt werden.
Interoperabilität: Die Komponenten können miteinander kommunizieren und Daten austauschen.

Das Wesen von openDesk besitzt hierzu folgende Merkmale:

Herstellerunabhängigkeit: Die Lösung ist nicht an bestimmte Anbieter gebunden.
Innovationspotenzial: Neue Technologien und Lösungen können mit angemessenem Aufwand integriert werden.
Sicherheit: Die Verwendung von Open-Source-Software ermöglicht eine transparente und sichere IT-Umgebung.
Flexibilität: Die Verwaltung kann den Arbeitsplatz an ihre individuellen Bedürfnisse anpassen.

Das Ziel von openDesk ist es, die Zusammenarbeit zwischen den öffentlichen Verwaltungen zu stärken und einen unabhängigen IT-Betrieb zu ermöglichen. Dies umfasst sowohl die Softwarebereitstellung als auch die Informationsverarbeitung.

Innerhalb von openDesk sind hierfür verschiedene IT-Werkzeuge enthalten, z.B. zur Bearbeitung von Dokumenten, zum Dateiaustausch und zur Kommunikation. Dabei verfolgt openDesk einen vollständigen Open-Source Ansatz. Jeglicher Quellcode wird dafür über die Plattform Open CoDE veröffentlicht und regelmäßig aktualisiert. Die Abbildung “openDesk Generelle Architektur High-Level (Entwurf)” stellt hierzu die generellen openDesk Architektur dar:

Entwurf_Architektur

Dieses Sicherheitskonzept zielt darauf ab, die wesentlichen Sicherheitsanforderungen und -maßnahmen für openDesk zu definieren. Es beschreibt die Strategien und Technologien, die eingesetzt werden, um potenzielle Bedrohungen zu identifizieren, zu verhindern und zu mitigieren. Darüber hinaus werden die Prozesse und Verantwortlichkeiten festgelegt. Sicherheitsvorfälle können effektiv gemanagt werden und erfüllen sowohl die gesetzlichen als auch die regulatorischen Anforderungen. Hierzu wird openDesk immer als ein Gesamtsystem betrachtet, sodass eine gesamtheitliche Betrachtung aller Bestandteile und bestehender Systemabhängigkeiten von openDesk erfolgt. Dies umfasst die Cloud Infrastruktur, die Plattform, als auch die einzelnen Applikationen der Software.

Ein sicherer, stabiler und leistungsfähiger Betrieb von openDesk kann nur bei Einhaltung der hier beschriebenen Maßnahmen und Vorkehrungen gewährleistet werden. Der Betreiber hat die genannten Sicherheitsvorkehrungen zu beachten, das System gemäß diesen Anforderungen zu betreiben und weiterzuentwickeln.

1.2 Adressatenkreis

Primär ist dieses Sicherheitskonzept an die Verantwortlichen von openDesk gerichtet, welche u.a. folgende Zielgruppen umfasst:

Das entscheidungstragende Management für die IT-Sicherheit im Rahmen der Zustandsüberwachung.
Mitarbeiter, welche für die Entwicklung, Implementierung und Wartung der Sicherheitsaktivitäten verantwortlich sind.
Systemingenieure und -architekten, die für den Entwurf, die Implementierung und die Modifizierung verantwortlich sind.
Systemadministratoren, welche für die Aufrechterhaltung des täglichen Betriebs verantwortlich sind.
Abteilungen der jeweiligen Softwareeigentümer der Module von openDesk.
Weitere potenziell interessierte Parteien, wie z.B. interne und externe Prüfer.

1.3 Dokumentenaufbau

Im Rahmen dieses Sicherheitskonzepts werden folgende Themengebiete behandelt:

Strukturanalyse: Eine detaillierte Untersuchung der Systemarchitektur und dessen Komponenten, um potenzielle Schwachstellen zu identifizieren.
Bedrohungsanalyse: Die Identifikation und Bewertung möglicher Sicherheitsbedrohungen.
Risikoanalyse: Eine systematische Bewertung der identifizierten Risiken, um deren potenzielle Auswirkungen und Eintrittswahrscheinlichkeiten zu bestimmen.
Modellierung von Anforderungen: Die Definition und Spezifikation von Sicherheitsanforderungen, die zur Absicherung von openDesk notwendig sind.
Sicherheitsmaßnahmen: Die Implementierung konkreter technischer, organisatorischer und personeller Sicherheitsmaßnahmen der identifizieren Risiken zu mitigieren, sowie die Sicherheitsanforderungen zu erfüllen.

1.4 Angewendete Standards

Für die Gewährleistung eines robusten, zuverlässigen und sicheren Betriebes ist die Einhaltung etablierter Standards essenziell. Diese Standards dienen als Maßstab für die organisatorischen und technischen Anforderungen und bieten Richtlinien und Rahmenbedingungen. Diese unterstützen Sicherheitsrisiken zu erkennen und abzuschwächen. Die unten beschriebenen Standards sind auf nationaler Ebene fester Bestandteil einer jeder IT-Umgebung und zum Teil auch international anerkannt und etabliert. Dazu gehören national der BSI IT-Grundschutz und der BSI C5. International gehört der CIS-Benchmark (für Linux Server und Kubernetes), The Twelve-Factor App (Die Zwölf-Faktor-App), Top Threats to Cloud Computing 2024 (Die größten Bedrohungen für Cloud Computing 2024) und OWASP Top 10 dazu. Jeder dieser Standards befasst sich mit speziellen Sicherheitsaspekten, die von allgemeinen Best Practices bis hin zu spezifischen Richtlinien für bestimmte Technologien oder Branchen reichen. In der Tabelle “Angewendete Standards” sind diese mit einer kurzen Beschreibung aufgeführt.

Standard	Notwendigkeit openDesk SaaS
BSI IT-Grundschutz	Der BSI IT-Grundschutz ist ein auf nationaler Ebene bewährtes Rahmenwerk für IT-Sicherheit. Dieser wird vom Bundesamt für Sicherheit in der Informationstechnik (BSI) erstellt, das als deutsche Behörde für die IT-Sicherheit des Bundes zuständig ist. Der BSI IT-Grundschutz bietet eine systematische und strukturierte Herangehensweise an die IT-Sicherheit, um Risiken zu erkennen und zu minimieren. Das Rahmenwerk unterstützt dabei, die Effizienz von IT-Sicherheitsmaßnahmen durch eine klare Strukturierung und Priorisierung von Maßnahmen zu verbessern. Es ist jedoch an die individuellen Bedürfnisse und Anforderungen einer IT-Umgebung anpassbar, so dass es keine genauen Vorgaben für ihre Umsetzung gibt.
BSI C5	Der BSI C5 (Cloud Computing Compliance Controls Catalogue) ist ein vom BSI entwickelter Kriterienkatalog. Der Kriterienkatalog definiert die Anforderungen an die Informationssicherheit von Cloud-Diensten. Der C5-Katalog dient als Leitfaden für Cloud-Anbieter und -Nutzer, so dass die angebotenen Cloud-Dienste den hohen Sicherheitsstandards entsprechen. Dies umfasst unter anderem Maßnahmen zur Datensicherheit, der Zugriffskontrollen und dem Notfallmanagement. Durch die Einhaltung des C5-Katalogs werden Cloud-Anbieter ihren Kunden gegenüber in die Lage versetzt transparent die getroffenen Sicherheitsmaßnahmen und -kontrollen darzulegen. Außerdem unterstützt der BSI C5 dabei, diese weiteren unternehmerische Anforderungen zu erfüllen und erleichtert damit die Nachweispflicht z.B. gegenüber Aufsichtsbehörden. Risiken werden im Zusammenhang mit der Nutzung von Cloud-Diensten identifiziert und mitigiert.
CIS-Benchmark	Der CIS-Benchmark (Center for Internet Security) ist ein weltweit anerkannter Standard zur Systemhärtung. Diese Benchmarks bestehen aus Best Practices von Sicherheitsexperten und Anbietern von Härtungsspezifikationen. Sie sind für eine Vielzahl von Betriebssystemen, Anwendungen und Netzwerkgeräten verfügbar und enthalten detaillierte Anweisungen zur Konfiguration von Sicherheitseinstellungen. Ziel der Benchmarks ist es, mögliche Schwachstellen zu identifizieren und zu schließen. Ein weiterer Vorteil der CIS-Benchmarks ist ihre regelmäßige Aktualisierung und die Reaktion auf neue Bedrohungen und Schwachstellen. Wenn ein System gemäß CIS gehärtet wurde, werden zahlreiche Testmethoden bereitgestellt.
The Twelve-Factor App	Die Twelve-Factor App (Zwölf-Faktoren-App) ist eine anerkannte Methodik für die Entwicklung sicherer Webanwendungen mit dem Schwerpunkt auf dem Hosting in einem Kubernetes-Cluster. Sie listet mehrere Best Practices für die sichere und zuverlässige Softwareentwicklung und das Hosting auf und ist auf jede Programmiersprache und jede Verwendung von unterstützenden Diensten anwendbar, z.B. Middleware-Dienste, Gateways oder Datenbanken.
Top Threats to Cloud Computing 2024	Die Cloud Security Alliance (CSA), eine Non-Profit-Organisation mit 48.000 Mitgliedern weltweit, veröffentlicht jährlich eine Rangliste der Sicherheitsbedrohungen im Cloud Computing. Diese Rangliste dient Unternehmen und Organisationen sich über die aktuellen und sich entwickelnden Bedrohungen zu informieren und ihnen zu helfen, ihre Sicherheitsstrategien entsprechend anzupassen und zu verbessern. Neben nationaler Betrachtung von Bedrohungen, dient dieser Standard für openDesk als internationaler Vergleich für die Vorbereitung auf Risiken, sowie die Mitigierung dieser.
OWASP Top 10	Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Organisation, die sich der Verbesserung der Sicherheit von Anwendungen, Diensten und Software widmet. Von ihr werden individuelle, auf diverse IT-Bereichen und Softwareentwicklung angepasste Top 10 gepflegt und veröffentlicht.

1.5 Definition Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade)

Die CIA-Triade sind die drei grundlegenden Prinzipien der Informationssicherheit und das allgemeine Schutzziel für jedes IT-System: C für Confidentiality (Vertraulichkeit), I für Integrity (Integrität) und A für Availability (Verfügbarkeit) werden im Folgenden kurz beschrieben und klassifiziert. Auswirkungen beschreibt Faktoren wie z. B. finanzieller Art, Reputation, geistiges Eigentum oder Compliance im Rahmen der eigens gesetzten Schutzziele der Institution.

1.5.1 Vertraulichkeit

Das Kriterium der Vertraulichkeit entspricht der geschäftlichen Notwendigkeit, den Zugang zu Informationen freigeben oder einschränken zu können. Dies bedingt auch die Befähigung Einschränkungen kontrollieren zu können.

Klassifikation Vertraulichkeit	Definition
normal	Informationen, deren Offenlegung keine wesentlichen negativen Auswirkungen auf das Unternehmen oder seine Partner hätte.
hoch	Informationen, deren unbefugte Offenlegung moderate negative Auswirkungen auf das Unternehmen oder seine Partner haben könnte.
sehr hoch	Informationen, deren unbefugte Offenlegung erhebliche negative Auswirkungen auf das Unternehmen oder seine Partner haben könnte.

1.5.2 Integrität

Das Kriterium der Integrität entspricht der geschäftlichen Notwendigkeit, Änderungen an den Informationen zu kontrollieren. Diese Kontrollfunktion erfordert wiederum den Schutz der Richtigkeit und Vollständigkeit dieser Informationen.

Klassifikation Integrität	Definition
normal	Informationen, die von jedem Nutzer, der im Rahmen seiner normalen Geschäftstätigkeit Zugang zu diesen Daten hat, geändert werden können.
hoch	Änderungen an diesen Informationen sind nur im Rahmen eines formalisierten Änderungsprozesses möglich.
sehr hoch	Informationen in diesen Klassifizierungen müssen sicherstellen, dass sie nicht verändert oder manipuliert werden können.

1.5.3 Verfügbarkeit

Das Kriterium der Verfügbarkeit bedingt eine stetige Erreichbarkeit von IT-Systemen, sowie stetig abrufbare Informationen für die befugten Personen.

Klassifikation Verfügbarkeit	Definition
normal	Informationen, deren Beibehaltung wünschenswert ist, deren Verlust jedoch das Tagesgeschäft des Unternehmens nicht gefährden würde.
hoch	Die meisten Informationen oder Systeme unterliegen dieser Einstufung und werden gemäß den üblichen Praktiken behandelt, wie z.B. Spiegelung der Festplatten und Aufnahme in bestehende Pläne zur Aufrechterhaltung des Geschäftsbetriebs.
sehr hoch	Auftrags- und Mandats-bezogene kritische Informationen oder Systeme unterliegen dieser Klassifizierung. Ihr Verlust würde sich stark negativ auf das Geschäft auswirken oder die Arbeit unmöglich machen.

1.6 Definition der Schutzbedarfskategorien

Die Schutzbedarfskategorien helfen den notwendigen Schutz für IT-Systeme und Daten festzulegen und zu priorisieren. Eine Einordnung in Schutzbedarfskategorien unterstützt bei der Bewertung möglicher Auswirkungen von Störungen und Vorfällen, wie z. B. die Datensicherheit, die Datenintegrität, die Verfügbarkeit der Dienste, die Anwendungssicherheit, die Vertraulichkeit etc. im Rahmen der eigens gesetzten Schutzziele der Institution, sowie bei der Ergreifung geeigneter Sicherheitsmaßnahmen.

Im Folgenden sind die Schutzbedarfskategorien und ihre Definitionen sowie Beispiele für jede Kategorie aufgeführt:

Schutzbedarfskategorie	Definition	Beispiele
normal	Beeinträchtigung von IT-Systemen und Daten haben eine geringe Auswirkung	kurzfristiger Ausfall der öffentlichen Website
hoch	Beeinträchtigung von IT-Systemen und Daten haben eine moderate Auswirkung	Ausfall von internem E-Mail-Server
sehr hoch	Beeinträchtigung von IT-Systemen und Daten haben eine fundamentale Auswirkung	Verlust und Verbreitung personenbezogener Daten

1.7 Anwendung STRIDE

STRIDE ist ein Akronym und steht für Spoofing (Nachahmen oder Vortäuschen einer Identität), Tampering (fälschen und manipulieren von Daten), Repudiation (Abstreiten einer Handlung), Information Disclosure (aufdecken, veröffentlichen von Informationen), Denial of Service (erzwungene Nichtverfügbarkeit eines Dienstes) und Elevation Privilege (unzulässige Erweiterung von Rechten). STRIDE wurde 2002 von Microsoft für die Klassifizierung von Angriffsmustern entwickelt. Die folgende Tabelle beschreibt die Bedrohungen und ordnet diese den Kriterien zu, die davor schützen.

Definition der Kriterien:

Authentifizierung ist der Prozess der Überprüfung der Identität eines Benutzers oder Systems, um sicherzustellen, dass die angegebene Identität korrekt ist.
Nichtabstreitbarkeit stellt sicher, dass eine durchgeführte Aktion oder Transaktion nicht im Nachhinein von ihrem Urheber geleugnet werden kann, indem Beweise wie digitale Signaturen verwendet werden.
Autorisierung ist der Prozess der Zuweisung von Rechten und Berechtigungen an einen authentifizierten Benutzer oder ein System, um den Zugriff auf Ressourcen und Dienste zu steuern.
Die Kriterien Integrität, Verfügbarkeit und Vertraulichkeit sind im Kapitel 1.6 definiert.

Kategorie	Beschreibung	Kriterien
Spoofing (Vortäuschung)	Umfasst unberechtigten Zugriff auf und die anschließende Verwendung der Authentifizierungsinformationen eines anderen Benutzers, z.B. Benutzername und Kennwort.	Authentifizierung
Tampering (Manipulation)	Umfasst die böswillige Änderung von Daten. Beispiele sind nicht autorisierte Änderungen von persistenten Daten, z.B. der Daten in einer Datenbank, und die Änderung von Daten bei der Übertragung zwischen zwei Computern über ein offenes Netzwerk wie das Internet.	Integrität
Repudiation (Abstreitung)	Ein Benutzer oder eine Entität streitet die Durchführung eine Tätigkeit ab. Bei unzureichenden Beweisen oder Protokollen kann Repudiation die Nachweisbarkeit und Verantwortlichkeit untergraben. Insbesondere in rechtlichen oder regulatorischen Angelegenheiten ist Repudiation kritisch. Für ein Entgegenwirken können Maßnahmen wie digitale Signaturen, umfassende Protokollierung und Audit-Trails eingesetzt werden. Gerade im Bereich von SaaS-Diensten kann dies unter anderem für kritische Änderungen an Einstellungen in der Anwendung, wie z.B. die Zugriffskontrollen oder Sicherheitskonfigurationen gelten.	Nichtabstreitbarkeit
Information Disclosure (Veröffentlichung von Informationen)	Ein unbefugtes Offenlegen von sensiblen Daten wie persönliche Informationen, Geschäftsgeheimnisse oder vertrauliche Dokumente von unautorisierten Personen gefährden die Vertraulichkeit. Beispielhaft können aufgrund einer Fehlkonfiguration der Zugriffskontrollen nicht autorisierte Benutzer auf Datenbanken zugreifen und sensible Informationen wie Namen, Adressen und Kreditkartendaten einsehen.	Vertraulichkeit
Denial-of-Service (Verweigerung)	Bei DoS-Angriffen (Denial of Service) wird berechtigten Benutzern der Zugriff auf einen Dienst verweigert, indem z.B. ein Webserver vorübergehend nicht verfügbar oder nicht nutzbar gemacht wird. Um die Verfügbarkeit und Zuverlässigkeit aufrecht zu erhalten, muss sich vor DoS-Angriffen geschützt werden.	Verfügbarkeit
Elevation of Privilege (Rechteerweiterung)	Ein nicht autorisierter Benutzer erlangt erweiterte Rechte oder privilegierten Zugriff. Der Benutzer verfügt dann über ausreichende Zugriffsrechte zur Kompromittierung des gesamten Systems. Ein Angreifer nutzt eine Sicherheitslücke, um sich Administratorrechte zu verschaffen. Mit diesen erweiterten Rechten kann der Angreifer auf sensible Daten zugreifen, Sicherheitskonfigurationen ändern und das gesamte System lahmlegen.	Autorisierung

2. Festlegung des Informationsverbunds im Rahmen des Sicherheitskonzeptes für openDesk

Die Festlegung des Informationsverbunds ist ein zentraler Bestandteil des Sicherheitskonzept. Mehrere einzelne containerisierte Anwendungen, die das endgültige Produkt openDesk vervollständigt, liegen der Betrachtung des vorliegenden Sicherheitskonzepts zugrunde, wobei der Fokus auf openDesk als SaaS-Endprodukt liegt. Weitere Betrachtungen unterliegen den jeweiligen Verantwortlichen der einzelnen Komponenten, wie u.a. der physischen Infrastruktur, der virtuellen Infrastruktur usw.

2.1 Informationsdomäne

Dieses Sicherheitskonzept bezieht sich auf die Bereitstellung von openDesk als SaaS-Lösung und umfasst die damit zusammenhängende Informationsdomänen, wie Kundendaten, Anwendungsdaten und Mitarbeiterdaten. Im Informationsverbund werden die Sicherheitsfunktionen sowie die Grundkonfiguration der SaaS-Lösung openDesk als Ganzes betrachtet.

2.2 Abgrenzung

Dieses Sicherheitskonzept stellt die Sicherheitsanforderungen für openDesk als SaaS Lösung dar. Es enthält jedoch keine Anforderungen oder Implementierungen für Themen, die nicht direkt auf die openDesk SaaS Lösung anwendbar sind. Unter anderem betrifft dies folgende Themen:

Schulung und Weiterbildung der Mitarbeiter

Eine Berücksichtigung der Schulung und Weiterbildung von Mitarbeitern findet in diesem Dokument nicht statt. Die Verantwortung für die Qualifizierung der Mitarbeiter liegt beim Betreiber der SaaS-Lösung von OpenDesk, sodass die geforderten Sicherheitsrichtlinien und -bestimmungen verstanden und umgesetzt werden. Darunter fallen z. B. Phishing Simulation oder Cyber Awareness Training.
Allgemeine Themen des IT-Betriebs

Alltägliche Betriebsabläufe und die Verwaltung der IT-Infrastruktur, die Teil der allgemeinen Themen des IT-Betriebs sind, werden nicht betrachtet, wie z. B. die Anwendung des ITIL Frameworks, Operational Excellence oder ähnliches. Diese Aspekte sind unabhängig von der SaaS-Lösung und werden internen IT-Prozesse des Betriebs abgedeckt. Das Dokument konzentriert sich auf die Bereitstellung der SaaS-Lösung und nicht auf die Verwaltung der gesamten IT-Umgebung.
Themen der baulichen und physischen Sicherheit

Bauliche und physische Sicherheitsmaßnahmen, wie Zugangskontrollen, Überwachungstechnologie oder Sicherheitsprotokollierungen, sind nicht Teil des Sicherheitskonzepts. Es wird vorausgesetzt, dass die SaaS-Lösung auf eine konforme Hyperscaler Umgebung betrieben wird.
Bereitstellung von openDesk in einer Confidential Cloud (vertrauliche Cloud-Umgebung)

Die Bereitstellung von openDesk in einer Confidential Cloud wird nicht betrachtet. Die SaaS-Lösung wird zentral auf die vorgegebene Hyperscaler Umgebung bereitgestellt.
Detaillierte Integrationsleistungen der openDesk SaaS Lösung in ein Kundennetzwerk

Die Integration in ein Kundennetzwerk hängt stark von der spezifischen Netzwerkarchitektur und den Sicherheitsanforderungen des Kunden abhängt. Der Kunde ist verantwortlich für die sichere Integration von openDesk in seine bestehende IT-Umgebung, einschließlich der Konfiguration von Firewalls und anderen Sicherheitsvorkehrungen.
Kunden-Bezogene Penetrationstests und zu testende Konfigurationen

Dies erfordert spezifische Tests, Anpassungen und Abstimmungen auf die individuelle IT-Umgebung des Kunden. Es liegt in der Verantwortung des Kunden regelmäßig Penetrationstests durchführen.
Lizenz-Themen

Lizenz-Themen beziehen sich auf die rechtlichen und vertraglichen Aspekte der Nutzung der SaaS-Lösung. Für die Einhaltung der Lizenzbedingungen und die Verwaltung der Lizenzen gilt gemäß der vertraglichen Vereinbarungen zwischen den jeweiligen Parteien und weiteren Dritten.

Dieses Dokument stellt zudem keine detaillierten Konzepte einzelner Systeme oder Anwendungen vor, sondern weist lediglich auf Sicherheitsaspekte hin, die für den zukünftigen Betrieb berücksichtigt werden müssen Diese sind weiteren organisatorischen oder technischen Konzepten untergeordnet, wie z.B. einem Disaster-Recovery-Konzept, einem Netzwerkkonzept, einem Backup-Konzept, einem Betriebshandbuch, einem Staging-Konzept und weiteren Bedarfs-bedingten Konzepten.

3. Strukturanalyse als Basis des Sicherheitskonzeptes für openDesk

Erhebung von Informationen, die für die weitere Vorgehensweise in der Erstellung des Sicherheitskonzeptes benötigt werden. Dabei geht es um die Erfassung folgender Bestandteile:

Anwendungen, Container, IT-Systeme und sicherheitsrelevante IT-Komponenten.

Allzu oft werden Container hierbei mit virtuellen Maschinen verwechselt oder gleichgesetzt und dadurch irreführende Annahmen hinsichtlich Sicherheit und Isolierung gemacht, weshalb an dieser Stelle zuerst eine Einordnung erfolgt.

Virtuelle Maschinen (VM) simulieren quasi ein komplettes Betriebssystem, indem sie einen physischen Server emulieren und damit virtualisiert bereitstellen, sodass Anwendungen darin betrieben werden können. Von außen betrachtet sieht eine virtuelle Maschine so aus und verhält sich auch so wie ein komplett separater, “echter” Server im Netzwerk. Bei einer solchen virtuellen Maschine handelt es sich meist um eine einzige Datei, welche auch den notwendige Festplattenspeicher beinhaltet, um Betriebssystem, Anwendungen und Daten zu speichern.

Bei Containern handelt es sich um leichtgewichtige Alternativen zu virtuellen Maschinen, jedoch mit ein paar Einschränkungen. Container und virtuelle Maschinen haben gemeinsam, dass sie Ressourcen des Host Systems verwenden. Während bei virtuellen Maschinen eine Emulation und Virtualisierung der für den Betrieb notwendigen Hardware stattfindet, ist dies so bei Containern nicht der Fall. Stattdessen nutzen Container direkt die vom Host bereitgestellten Ressourcen wie CPU, Arbeitsspeicher und ggf. Festplattenspeicher. Daher spricht man bei Containern von einer Isolierung auf Prozessebene, nicht von einer Virtualisierung. Daher können Container ohne weitere Maßnahmen kein vergleichbares Schutzniveau wie virtuelle Maschinen bieten.

Virtuelle Maschinen bieten daher designbedingt eine höhere Isolierung und Kapselung von der darunterliegenden Infrastruktur. Sollte ein Angreifer Zugriff auf eine virtuelle Maschine bekommen, so ist er zunächst in dieser “eingesperrt” und hat bei richtiger Konfiguration keinen oder sehr wenigen Zugriff auf die darunterliegende Infrastruktur, also den physischen Server oder das Netzwerk. Hat ein Angreifer dagegen einen ungehärteten Container kompromittiert, hat er meistens tiefgreifenderen Zugriff bzw. kann er sich diesen schneller und leichter verschaffen als bei einer VM.

Als Angriffsvektor formuliert bedeutet das, dass eine virtuelle Maschine gewöhnlich mehr Angriffsfläche bietet als ein ungehärteter Container, aber im Falle einer Kompromittierung die darunterliegende Infrastruktur bei einem Container weniger stark geschützt ist als bei einer virtuellen Maschine.

In vielen Fällen ist die Triebfeder hinter den Bemühungen zur Container-Härtung eine angestrebte Zertifizierung nach branchenüblichen Standards, jedoch sollte jeder auch ohne diese Zielsetzung das vitale Interesse haben, einen sicheren Betrieb gewährleisten zu können. Neben den Maßnahmen zur Absicherung und Härtung der Plattform, auf welcher openDesk betrieben werden soll, stellt der containerisierte Betrieb von openDesk eine zusätzliche Herausforderung dar. Die Härtung von Containern ist dabei nur ein Teil; die Unterstützung des Betriebs der Container durch zusätzliche Sicherungsmaßnahmen wie Richtlinien, die das gewünschte Verhalten der containerisierten Anwendungen erzwingen, trägt einen ebenso wichtigen Teil bei.

Der Container-Härtung kommen daher drei Aufgaben zu, um die maximale Sicherheit von openDesk zu gewährleisten:

Schutz der im Container betriebenen Komponenten von openDesk selbst
Schutz anderer Anwendungen bzw. weiterer Komponenten von openDesk auf der gleichen Plattform
Schutz der zugrundeliegenden Infrastruktur, wodurch weitreichender Zugriff und damit erhöhte Gefahr für alle Anwendungen und Komponenten von openDesk besteht

In allen drei Fällen gilt es, Attacken und Einbrüche abzuwehren, um Ausfälle zu verhindern und Datenkorruption oder -diebstahl zu vermeiden. Hierbei ist es wichtig, die Gesamtheit zu betrachten. Bleibt eine vermeintlich unwichtige Komponente von openDesk ungeschützt, so kann ein Angreifer diese kompromittieren, sich so Zugriff auf die Plattform beschaffen und damit nicht “von außen”, sondern “von innen” weitere Komponenten von openDesk kompromittieren, welche ggf. nur gegen Angriffe “von außen” geschützt waren. Insbesondere in geteilten Umgebungen mit unzureichendem Schutz der Plattform erhöht sich dieses Risiko erheblich.

Im Gegensatz zur Härtung von virtuellen Maschinen gibt es für die Container-Härtung keinen echten Standard, gemäß welchem man zuverlässig festmachen kann, ob ein Container adäquat gehärtet ist. Vielmehr existieren Best-Practices zur Härtung, auf welche im Folgenden eingegangen werden wird.

Im Gegensatz zur Härtung von Servern, virtuellen Maschinen oder Container-Plattformen existieren für Container selbst keine echten Standards, sondern lediglich Best-Practices. Diese zielen auf die sichere und nachhaltige Entwicklung von Software, hier openDesk, als auch auf den sicheren Betrieb und die zuverlässige Wartung ab. Aber auch der Schutz der darunterliegenden Plattform wird durch die Best-Practices indirekt mit betrachtet. Idealerweise werden diese Best-Practices, zusammen mit anderen Regeln für Plattform selbst, nicht nur passiv eingehalten, sondern aktiv erzwungen. Konkret an einem Beispiel, dass Container nicht mit Root-Rechten laufen sollen, bedeutet dies, dass auf der einen Seite die Software so entwickelt werden muss, dass sie diese Rechte nicht benötigt, aber auf der anderen Seite die Plattform die Ausführung der Software dann auch aktiv unterbindet, sollte sie z.B. durch einen Konfigurationsfehler oder aber einen gezielten Angriff mit Root-Rechten versuchen zu laufen.

3.1 Integrierte Anwendungen in openDesk

openDesk ist modular aufgebaut und besteht aus einer Vielzahl von containerbasierten Softwarekomponenten auf Basis von Open-Source Lösungen, welche durch Kubernetes orchestriert werden. Die Funktionalitäten von openDesk beinhalten:

ID	Anwendung	Funktionsmodul	Hersteller
1.	Collabora	Weboffice	Collabora Ltd.
2.	CryptPad	Diagram Editor	XWiki SAS
3.	Element	Textnachrichten-, Audio- und Videokommunikationsdienst (TAV)	Element GmbH
4.	Jitsi Meet	virtuelle Besprechungen	Nordeck IT + Consulting GmbH
5.	Nextcloud	File Management	Nextcloud GmbH
6.	Nubus	Identity- und Accessmanagament (IAM), Application Access Portal	Univention GmbH
7.	OpenProject	Projektmanagement	OpenProject GmbH
8.	OX App Suite	Groupware	Open-Xchange AG
9.	XWiki	Knowledge Management	XWiki SAS

Hieraus ergibt sich die folgende Software High-Level Architektur:

Entwurf_Software High-Level Architektur

1. Collabora - WebOffice (Webbasierte Büroanwendung)

Um Office-Dokumente wie Rich-Text-Dokumente, Tabellenkalkulationen und Präsentationen zu bearbeiten, wird WebOffice als Modul verwendet. Diese Integration ermöglicht es, Dokumente direkt im Browser zu erstellen, zu bearbeiten und gemeinsam zu nutzen.

2. CryptPad - Diagram Editor

Um diagrams.net-Dokumente zu bearbeiten, wird der Diagram Editor genutzt, um Benutzern zu ermöglichen, Diagramme und grafische Darstellungen direkt im Browser zu erstellen, zu bearbeiten und gemeinsam zu nutzen.

3. Element - TAV

Das Modul TAV wird für diverse Kommunikationszwecke eingesetzt, einschließlich Textnachrichten sowie direkter Audio- und Videoanrufe für eine nahtlose und effiziente Interaktion.

4. Jitsi Meet - virtuelle Besprechungen

Das Modul wird für digitale Meetings genutzt, um kollaborativ ortsunabhängig und kosteneffizient miteinander zu arbeiten.

5. Nextcloud - File Management (Dateiverwaltung)

Als eine Plattform für Dateispeicherung und -synchronisation mit leistungsstarken Kollaborationsfunktionen, die über Desktop-, Mobil- und Webschnittstellen zugänglich sind, bietet das File Management die zentrale Verwaltung, den sicheren Austausch und die Synchronisation von Dateien in Echtzeit.

6. Nubus - Identity- und Accessmanagament (IAM, Identitäts- und Zugriffsmanagement), Application Access Portal (Zugriffsportal auf die Anwendungen)

Das Modul IAM stellt Funktionen Zentralisierung und Vereinfachung des Identitätsmanagements in IT-Umgebungen. Folgende Funktionen werden durch das Modul bereitgestellt:

Identity Provider (IdP, Identitätsanbieter): Mit der Open-Source Softwarelösung Keycloak fungiert dieser als zentraler IdP, verwaltet die Authentifizierungstoken für Anwendungen und übernimmt die Benutzerauthentifizierung.
Access Control Layer (Ebene der Zugriffskontrolle): Durch die Nutzung von RBAC wird sichergestellt, dass ein Zugriff auf dedizierte Systeme, Dienste oder APIs nur durch autorisierte Benutzer erfolgen kann.
Integrations-Hub: Dieser synchronisiert Identitäts- und Zugriffsdaten zwischen Anwendungen, um Konsistenz zu gewährleisten.
User Provisioning (Benutzerbereitstellung): Auf Grundlage der organisatorischen Abläufe, erfolgt die Erstellung, Aktualisierung und Deaktivierung von Benutzerkonten in integrierten Systemen automatisiert.
IAM-Administration: Per vereinfachter Version der Univention Management Console (UMC) werden Benutzer-, Gruppen- und Berechtigungsinformationen verwaltet.
Frontend Integration Authentication (Authentifizierungsintegration im Frontend): Über den der Intercom Service / Silent Login ist sichergestellt, dass das Frontend anwendungsübergreifend die API eines anderen Dienstes aufrufen kann, welcher ebenfalls eine Benutzerauthentifizierung benötigt.
Application Access Portal (Portal für den Anwendungszugriff): Für den Zugriff auf einzelnen Anwendungen, ist über bereitgestellte Application Access Portal zu nutzen.

7. OpenProject - Project Management (Projektverwaltung)

Das Project Management bietet eine Vielzahl von Funktionen, darunter agiles Projektmanagement, Issue-Tracking, Zeit- und Kostenmanagement, sowie die Verwaltung von Projektplänen und Meilensteinen.

8. OX App Suite - Groupware

Groupware wird für E-Mail, Kalender, Adressbuch und das persönliche Aufgabenmanagement verwendet und alle wichtigen Kommunikations- und Organisationsfunktionen in einer einzigen Anwendung ab.

9. XWiki - Knowledge Management

Das Knowledge Management bietet eine umfassende Wissensplattform an, um Inhalte innerhalb der Organisation zu erstellen, zu teilen und zu verwalten, so dass wertvolle Informationen leicht zugänglich und zentralisiert sind.

3.2 Erhebung der IT-Systeme von openDesk

Für openDesk als SaaS Produkt arbeiten mehrere IT-Systeme und Komponenten zusammen, um die Bereitstellung des Dienstes zu gewährleisten. Darunter fallen folgende IT-Systeme und Komponenten:

(AS01) Infrastruktur:
Für den Betrieb von OpenDesk als SaaS-Lösung erforderlichen physischen und virtuellen Komponenten. Das umfasst u.a. Server, Netzwerke, virtuelle Maschinen, Speicherlösungen und Firewalls.

(AS02) Backup- und Wiederherstellungssysteme:
Die Backup- und Wiederherstellungssysteme für den Betrieb von OpenDesk als SaaS-Lösung umfassen sowohl Hardware- als auch Software-basierte Lösungen. Durch diese werden regelmäßige Sicherungskopien aller kritischen Daten und Systeme erstellt. Über automatisierte und in definierten Intervallen durchgeführte Backup-Prozesse werden Datenverluste vermieden. Eine zügige Wiederherstellung der Daten durch inkrementelle oder vollständige Backups kann hierbei die Ausfallzeit minimieren.

(AS03) Schnittstellen:
Für den openDesk Betrieb als SaaS-Lösung sind Schnittstellen wie APIs (Application Programming Interfaces) und anderer Integrationspunkte wie Webhooks essenziell zur Verbindung und Kommunikation innerhalb von openDesk selber, sowie mit anderen Systemen und Anwendungen. Durch Standards für den Zugriff auf Funktionen und Daten werden die Integration und Interoperabilität erleichtert.

(AS04) Benutzerzugänge:
Benutzerzugänge den Betrieb von openDesk als SaaS-Lösung umfassen Authentifizierungs- und Autorisierungsmechanismen, wie z.B. Single Sign-On (SSO), Multi-Faktor-Authentifizierung (MFA) und rollenbasierte Zugriffskontrollen (RBAC). Zentral wird ein Identity Provider (IdP) für eine zentrale Benutzerverwaltung und -authentifizierung verwendet. Gemäß “Least-Privilege” Prinzip werden Benutzerrechte und -rollen vergeben.

Als zusätzliche Sicherung wird ein Privileged Access Management (PAM) und Privileged Access Workstations (PAW) eingesetzt. PAM-Lösungen ermöglichen die Überwachung und Verwaltung von privilegierten Konten, während PAWs speziell gesicherte Arbeitsstationen für administrative Aufgaben bereitstellen.

(AS05) Protokolle und Überwachungsdaten:
Protokolle und Überwachungsdaten umfassen u.a. System- und Anwendungsprotokolle, Sicherheitsereignisse, Benutzeraktivitäten und Netzwerkverkehr und dienen z.B. zur Überwachung der Systemleistung und der Erkennung von Sicherheitsvorfällen.

(AS06) Anwendungen:
Die Anwendungen sind die zentralen Softwarelösungen, die das SaaS-Lösung openDesk den Endbenutzern spezifische Funktionen und Dienste bieten. Darunter fallen die einzelnen Module selbst, einschließlich des Codes und der Konfigurationen.

3.3 Netzplanerhebung von openDesk

– TBD –

3.4 Nutzerbeschreibung

– TBD –

Gruppenbezeichnung	Funktion	Rechte	Gruppenmitglieder

– TBD –

3.5 Zusammenfassung der Strukturanalyse

– TBD –

4. Schutzbedarfsfeststellung der Zielobjekte im Informationsverbund

Die für openDesk als SaaS-Lösung erforderliche Schutzbedarfsanalyse dient als Ermittlung des erforderlichen Schutzes für die Geschäftsprozesse, die verarbeiteten Informationen und die eingesetzte Informationstechnik. Basierend auf den Ergebnissen der Schutzbedarfsanalyse wird in den folgenden Kapiteln eine Bedrohungs- und Risikoanalyse durchgeführt. Es werden weder dedizierten Technologien, Konfigurationen (z.B. in Form einer Configuration Management Database (CMDB)) oder ähnliches abgebildet. Detaillierte Informationen sind den einzelnen Betriebsdokumentationen zu entnehmen.

4.1 Schutzbedarfsfeststellung

Im Folgenden werden die Schutzbedarfsfeststellungen aufgelistet. Eine Einordnung erfolgt anhand der in Kapitel 1.5 dargelegten Definitionen.

IT-System	Beschreibung	Vertraulichkeit	Integrität	Verfügbarkeit
(AS01)	Infrastruktur	hoch	hoch	sehr hoch
(AS02)	Backup- und Wiederherstellungssysteme	sehr hoch	hoch	hoch
(AS03)	Schnittstellen	hoch	hoch	hoch
(AS04)	Benutzerzugänge	sehr hoch	hoch	hoch
(AS05)	Protokolle und Überwachungsdaten	hoch	sehr hoch	hoch
(AS06)	Anwendungen	hoch	hoch	sehr hoch

5. Bedrohungsanalyse

Die Bedrohungsanalyse ist ein zentraler Bestandteil eines Sicherheitskonzepts. Dies dient zur Identifizierung von Sicherheitsrisiken und deren Mitigation. Dabei sind potenzielle Bedrohungen wie DDoS-Angriffe, SQL-Injection oder unsichere APIs zu analysieren. Die Bewertung dieser Bedrohungen hinsichtlich ihrer Wahrscheinlichkeit und Auswirkungen ermöglicht es für openDesk als SaaS-Lösung, gezielte Gegenmaßnahmen wie Multi-Faktor-Authentifizierung, Verschlüsselung und regelmäßige Penetrationstests zu entwickeln. Für die Bedrohungsanalyse werden Bedrohungen für das Einsatzszenario “die Bereitstellung von openDesk als SaaS-Lösung, die auf der STACKIT-Plattform bereitgestellt wird und über Kubernetes orchestriert wird” nach dem STRIDE-Modell beschrieben. Es bietet ein systematisches und umfassendes Modell zur Identifizierung und Klassifizierung von Sicherheitsbedrohungen, welche dabei hilft, potenzielle Schwachstellen frühzeitig zu erkennen und geeignete Gegenmaßnahmen zu entwickeln.

5.1 Einführung “Threat Model”

Das Threat Model (Bedrohungsmodell) ist ein systematischer Ansatz zur Identifikation, Bewertung, Priorisierung und der Implementierung von Gegenmaßnahmen. Es dient dazu, potenzielle Schwachstellen und Angriffsvektoren zu erkennen, die die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) von openDesk gefährden könnten. Zum besseren Verständnis der Umgebung gilt folgendes Threat Model in Anlehnung an die STRIDE Methodik.

– TBD –

5.2 Schwachstellen

In diesem Kapitel werden die möglichen Schwachstellen des beschriebenen Informationsverbundes detailliert analysiert. Die Schwachstellen werden in organisatorische und technische Kategorien unterteilt, um eine umfassende und strukturierte Analyse zu gewährleisten. Zu jeder Schwachstelle wurde ein Kürzel verwendet, welches in der Risikoanalyse markiert wird. Für die organisatorischen Schwachstellen wird das Kürzel “OS” verwendet und für die technischen Schwachstellen das Kürzel “TS”. Die Schwachstellen werden hierzu jeweils fortlaufend nummeriert.

5.2.1 Organisatorische Schwachstellen

Folgende potenzielle organisatorische Schwachstellen sind zu betrachten:

(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung:
Fehlende oder mangelnde Definitionen der Projektanforderungen, einschließlich Sicherheits- und Gesetzesanforderungen, sowie die aktive Einbindung von Entwicklungs- und Administrations-teams führen zu Verzögerungen im Notfall, erhöhten Kosten und potenziellen Sicherheitsrisiken.

(OS02) Effektives Risikomanagement und Überprüfungsprozesse:
Ein Mangel an effektivem Risikomanagement und regelmäßigen Prüfungen kann dazu führen, dass potenzielle Bedrohungen und Schwachstellen nicht frühzeitig erkannt und adressiert werden.

(OS03) Umfassende Schulung und Sensibilisierung des Personals:
Ein Mangel an regelmäßigen und umfassenden Schulungen und Informationsveranstaltungen kann dazu führen, dass Mitarbeiter nicht ausreichend über aktuelle Sicherheitsbedrohungen und -protokolle sensibilisiert sind.

(OS04) Unklare Rollen und Verantwortlichkeiten:
Eine unzureichende Definition von Rollen und Berechtigungen verstärkt den Eindruck einer unklaren Verteilung von Verantwortlichkeit und kann zudem zu Verwirrung und Ineffizienz führen.

(OS05) Mangelhafte Durchsetzung der Rollendefinitionen:
Eine fehlende Rollentrennung macht IT-Systeme anfälliger auf Grund der übermäßigen Verteilung privilegierter Rechte. So sollte beispielsweise keiner einzelnen Person Zugriffsrechte auf die gesamte Plattform gewährt werden.

(OS06) Need-to-know-Prinzip nicht angewendet:
Der Zugriff auf Informationen und Daten sind nur Personen oder Gruppen zu ermöglichen, die für ihre Tätigkeit notwendig sind. Wenn das Need-to-know-Prinzip nicht angewendet wird, können sensible Informationen in die falschen Hände geraten, was zu Sicherheitsverletzungen und potenziellen Schäden für das Unternehmen führen kann. Zudem kann die Nichteinhaltung dieses Prinzips die Einhaltung von Datenschutzbestimmungen gefährden und rechtliche Konsequenzen nach sich ziehen.

(OS07) Unzureichende Trennung von Zuständigkeiten:
Eine fehlende oder ungenügende Trennung von Zuständigkeiten begünstigt die Eskalation von Zugriffsrechten. Wenn eine Einzelperson oder Gruppe zu viele Berechtigungen hat, können diese unautorisiert auf kritische Systeme zugreifen. Es können Änderungen vorgenommen, die die Sicherheit und Stabilität des Informationsverbund gefährden. Beispielsweise kann ein Administrator, der sowohl für die Systemkonfiguration als auch für die Sicherheitsüberwachung verantwortlich ist, unbemerkt Änderungen vornehmen.

(OS08) Mangelndes Sicherheitsbewusstsein:
Fehlendes Sicherheitsbewusstsein bei Benutzern birgt Risiken zum Verlust von Daten, Zugängen u.a. Daher sind Maßnahmen zur Minderung dieser Risiken zu ergreifen.

(OS09) Provisionierung von Benutzern:
Unzureichende Kontrollen und Prozesse bei der Provisionierung von Benutzern stellen Sicherheitsrisiken dar. Beispiele hierfür sind:

Vergabe von Nutzerberechtigungen an Benutzern mit unzureichenden oder übermäßigen Zugriffsrechten bedingt Fehlerpotentiale und Sicherheitsrisiken.
Inkonsistenzen und Sicherheitslücken entstehen durch zeitliche und inhaltliche Verzögerungen bei der Synchronisation zwischen IT-Systemkomponenten.
Das Erstellen unabhängiger, asynchroner Kopien von Identitätsdaten erschwert die Verwaltung und Sicherung dieser Daten erschweren kann.
Es besteht die Möglichkeit, dass Anmeldeinformationen während des Bereitstellungsprozesses abgefangen werden können.

(OS10) De-Provisionierung von Benutzern:
Verzögerte oder fehlerhafte De-Provisionierung von Benutzern kann unbefugten Zugriff durch ehemalige Mitarbeiter oder Personen mit veränderten Rollen ermöglichen. Dadurch können vertrauliche Informationen ungeschützt bleiben und potenziell nach außen gelangen. Dies kann wiederum Verstöße gegen gesetzliche und regulatorische Anforderungen zur Folge haben, was rechtliche Konsequenzen und finanzielle Strafen nach sich ziehen kann.

(OS11) Zugriffskontrollen:
Um sicherzustellen, dass nur autorisierte Benutzer und Systeme auf sensible Daten und Systeme zugreifen können, sind strenge Zugriffskontrollen im Informationsverbund erforderlich. Fehlende oder unzureichende Zugriffskontrollen können dazu führen, dass unautorisierte Benutzer oder Systeme Zugang zu sensiblen Daten und Systemen erhalten. Dies kann zu Datenverlust, Datenmissbrauch oder Sicherheitsverletzungen führen.

(OS12) Fehlende oder unzureichende Sicherheitsrichtlinien:
Fehlende oder unzureichende Sicherheitsrichtlinien sowie die ungenügende Kontrolle ihrer Umsetzung begünstigen die Umgehung von Sicherheitsmaßnahmen und den fahrlässigen oder böswilligen Umgang mit sicherheitsrelevanten Informationen. Dies kann zu Datenverlust oder -diebstahl führen. Ein Beispiel ist das Fehlen klarer Richtlinien zur Passwortsicherheit, was zu schwachen Passwörtern und erhöhtem Risiko von Kontoübernahmen führen kann.

(OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien:
Unzureichende Kontrollen der Umsetzung von Sicherheitsrichtlinien bewirkt die nicht ordnungsgemäße Anwendung von Sicherheitsmaßnahmen. Ohne regelmäßige Überprüfungen und Audits bleiben Sicherheitslücken unentdeckt und haben das Potential ausgenutzt zu werden.

(OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen:
Protokolle bzw. Sicherheitsereignisse dokumentieren technische und fachliche Vorgänge auf IT-Systemen. Durch Auswertung dieser Ereignisse kann eine nicht sachgerechte Nutzung erkannt und mitigiert werden. Für eine angemessen Sicherheitsüberwachung sind angemessen Verfahren und Aufbewahrungsregelungen zu etablieren. Fehlen angemessene Verfahren und Aufbewahrungsregelungen für die Sicherheitsüberwachung, kann dies dazu führen, dass sicherheitsrelevante Vorfälle nicht rechtzeitig erkannt und behandelt werden. Dies erhöht das Risiko von unentdeckten Sicherheitslücken und Missbrauch, was die Integrität und Vertraulichkeit der Daten gefährdet.

(OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets:
Eine vollständige Übersicht über alle eingesetzten Assets ist entscheidend. Die mangelnde Transparenz der eingesetzten Assets führt zu mehreren Gefahren: Unbekannte Schwachstellen bleiben unentdeckt, geeignete Sicherheitsmaßnahmen können nicht implementiert werden und eine unzureichende Überwachung macht es schwierig, ungewöhnliche Aktivitäten oder Angriffe zu erkennen. Angreifer suchen gezielt nach ungeschützten Systemen. Ohne Kenntnis über alle genutzten Assets bieten die IT-Systeme ein leichtes Ziel.

(OS16) Fehlende oder unzureichende Klassifizierung der Assets:
Assets können nicht effektiv geschützt werden, wenn die Klassifizierung der Assets fehlt, ungenügend oder unzureichend ist. Dadurch kann der Aufwand des Schutzes von Assets mit einem niedrigen Schutzbedarf zu hoch sein. Es entstehen im Vergleich hohe Kosten und Aufwände. Andersherum kann der Schutzbedarf auch zu niedrig eingeschätzt werden, sodass die Assets nicht ausreichend geschützt werden.

(OS17) Unklarer Besitz von Assets:
Für jedes Asset ist eine dedizierte verantwortliche Person oder Personenkreis zu benennen. Im Falle von Schwachstellen oder von notwendigen Patches (Fehlerbehebungen) und Änderungen haben die Verantwortlichen für die Aktualität der Assets Sorge zu tragen.

(OS18) Ungeeignetes Vorgehens-Modell für die Softwareentwicklung:
Die Auswahl eines ungeeigneten Vorgehens-Modell bei der Software-Entwicklung begünstigt Verzögerungen im Entwicklungsverlauf und im Projekt. Je nach Modell und Umfang des Vorhabens werden relevante Aspekte vernachlässigt oder irrelevante Aspekte übermäßig fokussiert.

(OS19) Unzureichendes Release und Deployment Management:
Ungenau definierte Prozesse der Softwarebereitstellung resultiert in neuen produktiv genutzten Softwareversionen mit kritischen Fehlern.

(OS20) Unzureichendes Configuration und Change-Management:
Insofern das Konfigurations- und Änderungsmanagement nicht klar ausgearbeitet ist, besteht die Möglichkeit von Inkompatibilitäten. Wenn Änderungen ohne angemessene Planung und Koordination durchgeführt werden, kann dies zu Instabilitäten und Systemausfällen führen. Ein Beispiel ist die Einführung eines neuen Software-Updates, welches nicht mit dem aktuellen Betriebssystem oder der eingesetzten Kubernetes Version kompatibel ist.

(OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan:
Im Falle eines Ausfalls oder Notfalls, könnte der Betrieb mangels Business Continuity (Fortführung der Geschäftsprozesse) und Disaster Recovery Plan (Plan zur Wiederherstellung im Katastrophenfall) nicht aufrechterhalten bzw. nur mit großen Ausfallzeiten wiederhergestellt werden. Mit ungetesteten Plänen besteht die Gefahr, dass ein Desaster Recovery unzureichend ausgeführt wird, so dass Datenverluste oder der Betriebsausfall über einen langen Zeitraum nicht verhindert werden können.

(OS22) Planung von Ressourcen:
Eine sorgfältige Planung der Ressourcennutzung ist notwendig, um sicherzustellen, dass alle Systeme und Anwendungen stets über ausreichende Ressourcen verfügen, um ihre Aufgaben zu erfüllen. Dies umfasst die Verwaltung von Rechenleistung, Speicherplatz, Netzwerkbandbreite und anderen Komponenten. Wenn benötigte Ressourcen nicht rechtzeitig bereitgestellt oder skaliert werden, kann dies die Leistung und Verfügbarkeit der Systeme beeinträchtigen.

(OS23) Backup:
Eine umfassende Backup-Strategie ist entscheidend, um SaaS-Produkte vor Datenverlusten durch Cyberangriffe und andere unvorhersehbare Ereignisse zu schützen. Wenn keine geeigneten Maßnahmen zur Sicherung und Wiederherstellung von Daten getroffen werden, ist die Integrität und Verfügbarkeit der Daten gefährdet bis hin zum Totalverlust der Daten.

(OS24) Auswahl und Management von Dienstleistern:
Eine grundlegend gefestigte Auswahl an Dienstleistern und die Verwaltung verstärkt die hohen Sicherheitsstandards und die Integrationsfähigkeit. Eine gute Zusammenarbeit mit den Dienstleistern trägt für die Sicherheit und Hochverfügbarkeit der Systeme bei.

(OS25) Multi-Sourcing-Strategie:
Durch eine durchdachte Multi-Sourcing–Strategie stehen mehrere Dienstleister zur Verfügung stehen, um den Betrieb auch im Falle des Ausfalls eines anderen Dienstleisters aufrechtzuerhalten. Dies erhöht die Flexibilität und Resilienz des Unternehmens und minimiert das Risiko einer Abhängigkeit von einem einzigen Dienstleister.

(OS26) Management von Drittanbieter-Ressourcen:
Die sorgfältige Nutzung und Überwachung von Drittanbieter-Ressourcen, dazu gehören z.B. externer Code oder Open-Source-Bibliotheken ist durch Cybersecurity Supply Chain Risk Management (C-CSRM) zu verwalten, so dass potenzielle Risiken in der Lieferkette zu identifizieren und zu minimieren sind.

(OS27) Vertraulichkeitsvereinbarungen (NDA):
Ein fachgerechter Umgang mit dem Austausch und der Verbreitung von Informationen und Daten durch Dienstleister und Kooperationspartner ist die Grundlage für die Zusammenarbeit. Dies schützt sensible Informationen und gewährleistet die Einhaltung rechtlicher und vertraglicher Verpflichtungen.

(OS28) Kundenmanagement:
Eine gründliche Identifikation und Prüfung von Kunden bzw. Serviceabonnenten schützt sensible Daten und Systeme und trägt zur Sicherheit und Integrität der IT-Infrastruktur bei.

5.2.2 Technische Schwachstellen

Folgende potenzielle technische Schwachstellen sind zu betrachten:

(TS01) Hypervisor-Schwachstellen:
Angriffe auf den Hypervisor sind besonders attraktiv, da der Hypervisor die physischen Ressourcen und die darauf laufenden virtuellen Maschinen (VMs) vollständig kontrolliert. Jede Schwachstelle in dieser Ebene ist daher äußerst kritisch. Die Ausnutzung des Hypervisors bedeutet potenziell die Ausnutzung jeder VM, die auf ihm läuft:

Ein typisches Szenario, das durch die Ausnutzung einer Hypervisor-Schwachstelle ermöglicht wird, ist der sogenannte “Virtual Machine Escape” (Ausbruch aus einer virtuellen Maschine).
Ein weiteres Szenario ist “VM-Hopping” (der Wechsel von einer VM zu einer anderen VM), bei dem ein Angreifer zunächst eine VM mit einer Standardmethode hackt und dann, unter Ausnutzung einer Hypervisor-Schwachstelle, die Kontrolle über andere VMs übernimmt, die auf demselben Hypervisor laufen.

(TS02) Fehlende Netzwerkverschlüsselung:
Um die Vertraulichkeit und Integrität von Daten während der Übertragung zu gewährleisten, ist es entscheidend, dass alle Datenübertragungen ordnungsgemäß verschlüsselt sind. Dies umfasst die Nutzung von sicheren Protokollen wie TLS, SSL und VPNs. Der Schutz von Daten während Übertragung ist besonders wichtig, da sie dann anfällig für Abhör- und Manipulationsangriffe sind. Bei unzureichender oder fehlender Netzwerkverschlüsselung bestehen folgende Gefährdungen:

MITM-Angriffe: Wenn Daten über Netzwerke ohne Verschlüsselung übertragen werden, können sie von Angreifern abgefangen und gelesen werden. Bei einem MITM-Angriff kann der Angreifer den Datenverkehr zwischen zwei Kommunikationspartnern abfangen und möglicherweise manipulieren.
Datenverlust und Datenmanipulation: Unverschlüsselte Datenübertragungen sind anfällig für Abhörangriffe, bei denen sensible Informationen wie Passwörter, Kreditkartendaten und persönliche Daten gestohlen werden können. Angreifer können auch die übertragenen Daten manipulieren, was zu Datenverlust und Sicherheitsverletzungen führen kann.
Datenschutzverletzungen: Fehlende Netzwerkverschlüsselung kann zu erheblichen Datenschutzverletzungen führen, da vertrauliche Informationen während der Übertragung kompromittiert werden können. Dies kann zu finanziellen Verlusten und Reputations-Schäden führen.

(TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers:
Um die Vertraulichkeit und Integrität von Daten während der Verarbeitung zu gewährleisten, ist es entscheidend, dass alle Daten im Arbeitsspeicher (RAM, Random Access Memory) und anderen temporären Speicherorten ordnungsgemäß geschützt sind. Der Arbeitsspeicher ist ein kritischer Bereich, in dem Daten aktiv verarbeitet werden und er kann sensible Informationen wie Passwörter, Verschlüsselungsschlüssel und andere vertrauliche Daten enthalten. Genauso zu betrachten ist der Schutz der Prozessoren (CPU, Central Processing Unit). Sie sind die zentrale Verarbeitungseinheit ist und ebenfalls anfällig für Sicherheitslücken. Folgende Gefährdungen sind möglich:

Memory Dump (Auszug des Arbeitsspeichers): Angreifer können Techniken wie Memory-Dumping verwenden, um den Inhalt des Arbeitsspeichers auszulesen und sensible Informationen zu extrahieren. Dies kann durch physische Zugriffe oder durch Malware (Schadsoftware) geschehen, die den Arbeitsspeicher ausliest.
Datenverlust und Sicherheitsverletzungen: Ohne ausreichenden Schutz können sensible Daten im Arbeitsspeicher von Angreifern extrahiert werden. Dies führt zu Datenverlust und Sicherheitsverletzungen, da vertrauliche Informationen wie Passwörter und Verschlüsselungsschlüssel kompromittiert werden. Es wird gegen das Prinzip der Vertraulichkeit verstoßen.
CPU-Meltdown (Zusammenbruch der CPU): Meltdown ermöglicht den Zugriff auf sensible Daten im Speicher. Diese sind durch die CPU geschützt sein, jedoch werden Schwachstellen in der spekulativen Ausführung von Befehlen ausgeführt, um den Zugriff zu ermöglichen. Dadurch können vertrauliche Informationen wie Passwörter und Verschlüsselungsschlüssel extrahiert werden.

(TS04) Mangelhaftes & unsicheres Ressourcenmanagement:
Eine mangelhafte Trennung (Segregation), also eine nicht ausreichende Isolierung von Ressourcen und Anwendungen, erleichtert den unbefugten Zugriff auf Informationen sowie den Missbrauch von Ressourcen, wie beispielsweise Schwachstellen im Sicherheitsmodell des Hypervisors. Darüber hinaus können fehlerhafte Algorithmen und -prozeduren zum Ressourcenmanagement zu einer unerwarteten Ressourcenerschöpfung führen. Die Folge sind Systemausfälle und Dienstunterbrechungen. Schwachstellen ermöglicht es den Angreifern, die Ressourcenverteilung zu manipulieren, was zu ineffizienter Ressourcennutzung und potenziellen Sicherheitsvorfällen führt.

(TS05) Fehlende Ressourcenisolierung:
Infrastructure-as-a-Service (IaaS), Container-as-a-Service (CaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS) Lösungen basieren häufig auf Architekturen und Umgebungen, bei denen physische Ressourcen von mehreren virtuellen Maschinen und damit mehreren Benutzern gemeinsam genutzt werden. Der Ressourcenverbrauch eines Benutzers kann sich auf den Ressourcenverbrauch eines anderen Benutzers auswirken.

Überbuchung von Ressourcen: Es ist möglich, dass Benutzer mehr Ressourcen verbrauchen als ihnen zugewiesen wurde. Dies kann die Leistung und Verfügbarkeit der Dienste für andere Benutzer beeinträchtigen. Beispielsweise kann ein Benutzer, der eine ressourcenintensive Anwendung ausführt, die CPU, den Speicher oder die Netzwerkbandbreite übermäßig beanspruchen, was zu einer Verlangsamung oder einem Ausfall der Dienste für andere Benutzer führt.
Mangelnde Isolation von Netzwerkressourcen: Durch fehlende Isolation von Netzwerkressourcen besteht die Möglichkeit, dass ein Angreifer den Netzwerkverkehr anderer Benutzer abhört oder manipuliert. Dies kann zu Datenverlusten, Sicherheitsverletzungen und einer Beeinträchtigung der Integrität und Vertraulichkeit der Daten führen.
Seitenkanalangriff (Side channel attack): Durch die Beobachtung von Ressourcenverbrauchsmustern können Angreifer Informationen über andere Benutzer oder deren Anwendungen gewinnen kann. Dies kann z.B. über Angriffe des Cache erfolgen, bei dem ein Angreifer durch die Analyse von Cache-Zugriffsmustern sensible Informationen wie kryptografische Schlüssel extrahieren kann.
Störender-Nachbar-Effekt (“Noisy Neighbor”-Effekt): Der “Noisy Neighbor-Effekt” tritt auf, wenn ein Benutzer durch übermäßigen Ressourcenverbrauch die Leistung und Verfügbarkeit der Dienste für andere Benutzer beeinträchtigt.
Sicherheitsverletzungen durch gemeinsame Nutzung von Ressourcen: Eine gemeinsame Nutzung physischer Ressourcen von mehreren Benutzern kann das Risiko beinhalten, dass ein Angreifer Schwachstellen in der Ressourcenverwaltung ausnutzt, um auf die Daten oder Anwendungen anderer Benutzer zuzugreifen. Ein Beispiel hierfür ist die Ausnutzung von Schwachstellen in der Virtualisierungsschicht.

(TS06) Unsichere Managementinterfaces:
Managementinterfaces sind Schnittstellen, die Administratoren und IT-Personal zur Verwaltung und Konfiguration von IT-Infrastrukturen verwenden. Diese Schnittstellen bieten umfangreiche APIs, mit denen der IT-Dienstleister proprietäre Management-, Bereitstellungs- und Reporting-Schnittstellen entwickelt, die den Benutzern zur Verfügung stehen. Schwachstellen im Sicherheitsmodell dieser Schnittstellen können zu unbefugtem Zugriff auf Benutzerinformationen führen. Beispielsweise können Angreifer durch Schwachstellen in den Managementschnittstellen die Konfigurationsdaten manipulieren, was zu einer Eskalation von Zugriffsrechten führt. Dies ermöglicht es Angreifern, auf höher privilegierte Ressourcen zuzugreifen und diese zu missbrauchen.

Die unsichere oder unzureichende Überwachung von Managementschnittstellen begünstigt die Eskalation von Zugriffsrechten, die fahrlässige oder auch böswillige Manipulation von Konfigurationsdaten, sowie den fahrlässigen oder auch böswilligen Missbrauch von virtuellen oder physischen Ressourcen. Darüber hinaus kann es eine Schwachstelle auf dieser Ebene ebenfalls einem Angreifer ermöglichen, die Assets innerhalb der IT-Infrastruktur zu manipulieren. Dies kann zu Denial-of-Service-Angriffen führen, bei denen laufende virtuelle Maschinen heruntergefahren werden, zu Datenlecks, bei denen Daten kopiert und außerhalb der virtuellen Maschinen übertragen werden, zu Kompromittierungen von Daten, bei denen virtuelle Maschinen durch modifizierte Kopien ersetzt werden, oder zu direkten finanziellen Schäden, indem viele Kopien der virtuellen Maschinen gestartet werden.

Fehlende Kontrollen der IT-Infrastruktur und Cross-Side-Channel-Schwachstellen können ebenfalls erhebliche Risiken für die Sicherheit der Managementinterfaces mit sich bringen. Wenn die Überwachung und Protokollierung der Aktivitäten auf diesen Schnittstellen unzureichend sind, können Angreifer ihre Aktivitäten verschleiern und unentdeckt bleiben. Dies erschwert die rechtzeitige Erkennung und Abwehr von Angriffen. Das Fehlen von Tools zur Durchsetzung von Terms of Service (ToS, Nutzungsbedingungen) oder spezifischer Service Level Agreements (SLA, Dienstleistungs-Güte-Vereinbarung, d.h. ein Rahmenvertrag für wiederkehrende IT-Dienstleistungen) wie Quality of Service (QoS, Qualität und Güte eines Dienstes) oder Distributed Resource Scheduling (DRS, Ressourcenplanung in verteilten Systemen) kann dazu führen, dass ein Benutzer die IT-Infrastruktur übermäßig beansprucht. Dies kann sich negativ auf andere Benutzer auswirken, indem es zu unzureichender Leistung oder gar dem Ausfall des Dienstes oder der Infrastruktur führt.

(TS07) Unsichere Kommunikationskanäle:
Über Kommunikationskanäle erfolgt die Übertragung von Daten zwischen Systemen und Benutzern. Eine unzureichende kryptographische Sicherung von Kommunikationsendpunkten, -kanälen und -protokollen sind Schwachstellen für Angreifern, die es ermöglicht Kommunikationssitzungen abzuhören und zu übernehmen. Unsichere Authentifizierungsmechanismen und die Verwendung selbst-signierter Zertifikate erhöhen das Risiko, dass Angreifer Kommunikationssitzungen übernehmen und sich als legitime Benutzer ausgeben können. Diese Angriffe werden durch unsichere Authentifizierungsmechanismen oder die Akzeptanz selbst-signierter Software-Zertifikate zusätzlich begünstigt.

(TS08) Unsichere Mandantenfähigkeit:
Wenn die Trennung der Daten und Ressourcen zwischen den Mandanten nicht strikt umgesetzt wird, haben Angreifer Zugriff auf die Daten anderer Mandanten. Zudem können unzureichend konfigurierte Mandanten-Umgebungen zu sogenannten “Noisy Neighbor”-Effekten (Störender-Nachbar-Effekt) führen, bei denen die Aktivitäten eines Mandanten die Leistung und Verfügbarkeit der gesamten Umgebung beeinträchtigen.

(TS09) Fernzugriff auf die Managementoberfläche:
Der Fernzugriff auf die Managementoberfläche begünstigt das Ausnutzen von Schwachstellen in Endgeräten, z.B. im Kontext des Internets der Dinge (IoT, Internet of Things) und der IT-Infrastruktur (Einzelkunde oder IT-Anbieter). Solche Schwachstellen können durch schwache Authentifizierungsmechanismen oder unzureichende Verschlüsselung entstehen. Diese Schwachstellen betreffen die Möglichkeit, Daten während der Übertragung abzufangen und zu lesen, beispielsweise durch MITM-Angriffe. Weitere Risiken ergeben sich durch die Akzeptanz von selbstsignierten Zertifikaten.

(TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen:
Eine unzureichende Sicherheit von Kubernetes-Umgebungen mittels mangelhafter Authentifizierung und Autorisierung in der Control Plane birgt Sicherheitsrisiken. Administrierende und toolgestützte Bereitstellungen benötigen administrative Zugänge. Obwohl Mechanismen zur Authentifizierung und Autorisierung, häufig vorhanden sind, sind sie nicht immer standardmäßig aktiviert. Unbefugte, die auf das Netzwerk oder die Nodes (Knoten) zugreifen, können über ungeschützte administrative Zugänge Befehle ausführen, die der Verfügbarkeit, Vertraulichkeit und Integrität der verarbeiteten Daten schaden können.

Ein weiteres Risiko ist der Vertraulichkeitsverlust von Zugangsdaten. Pods benötigen Zugangsdaten (Access Tokens) zur API von Kubernetes. Wenn ein Pod angegriffen wird, können diese Zugangsdaten in unbefugte Hände gelangen. Mit diesen Zugangsdaten können Angreifer authentifiziert mit der Control Plane interagieren und, sofern die Berechtigungen ausreichen, Veränderungen an der Orchestrierung vornehmen.

Ressourcenkonflikte führen dazu, dass einzelne Pods den Node oder die Orchestrierung überlasten können. Die Verfügbarkeit aller anderen Pods auf dem Node oder den Betrieb des Nodes selbst ist dadurch gefährdet.

Die Automatisierung per Continuous Integration / Continuous Deployment Pipelines (CI/CD-Pipelines, d.h. Automatisierungen zur kontinuierlichen Integrierung und kontinuierlichen Auslieferung von Software und Diensten) und die daraus folgende Notwendigkeit, den Werkzeugen privilegierte Zugangsberechtigungen zu erteilen, birgt das Risiko unautorisierter Änderungen am Kubernetes Cluster.

Durch unberechtigte Kommunikation zwischen Pods und Nodes im Cluster, sowie mit externen IT-Systemen, hat ein Angreifer die Möglichkeit, die Control Plane, andere Pods oder die Nodes zu kompromittieren. Pods im Cluster können unerwünscht von außen erreichbar sein, was Angriffe gegen Dienste ermöglicht, die eigentlich nur intern erreichbar sein sollten. Diese Gefährdung wird durch die geringere Aufmerksamkeit verschlimmert, die internen Diensten oft entgegengebracht wird. Eine Verwundbarkeit auf einem nur intern eingesetzten Dienst, der von außen erreichbar ist, gefährdet die gesamten Cluster erheblich.

(TS11) Unzureichende Container-Sicherheit:
Container werden vorrangig auf Basis von vorgefertigten Images erstellt, die selbst erstellt, aber auch aus dem Internet bezogen werden können. Die in den Images enthaltene Software kann verwundbar sein und die aus dem Image gestarteten Container können dadurch angreifbar werden. Zudem können Images absichtlich integrierte Schadsoftware enthalten. Sollte ein Angreifer in der Lage sein, im Container eigenen Code auszuführen, kann er die Isolation des Containers überwinden und auf andere Container, das Host-System oder die Infrastruktur zugreifen (Container-Ausbruch), sofern diese nicht richtig abgesichert sind. Dies kann zum Verlust der Vertraulichkeit, Integrität und Verfügbarkeit aller auf diesem Host ausgeführten Container sowie des Hosts selbst führen, falls der Angreifer dort erhöhte Privilegien erlangen kann.

(TS12) Unzureichende Datenbanksicherheit:
Datenbanken können durch Schadprogramme infiziert werden, die unautorisierten Zugriff ermöglichen, Daten durchsickern lassen oder entfernen und die Verfügbarkeit der Datenbankdienste beeinträchtigen. Überlastungen und Kapazitätsengpässe beeinträchtigen die Nutzung der Datenbank durch autorisierte Benutzer. Sicherheitsanfälligkeiten in der Datenbanksoftware können zu unautorisierten Rechteausweitungen, Datenverlust oder -verfälschung und Leistungsabbau führen. Ungültige Daten oder Befehle, Fehler in Administrationsprozessen oder Sabotage können die Integrität der Daten beeinträchtigen.

(TS13) Unzureichende Sicherheit von Applikationen:
Durch unsichere Programmierung, veraltete Bibliotheken oder unzureichende Eingabevalidierung haben Angreifer die Chance, den unautorisierten Zugriff auf sensible Daten zu erlangen, die Integrität der Applikation zu kompromittieren oder Denial-of-Service-Angriffe durchzuführen. Besonders kritisch sind Schwachstellen wie SQL-Injection, Cross-Site Scripting (XSS, webseitenübergreifendes Scripting) und unsichere Authentifizierungsmechanismen, die es Angreifern ermöglichen, sich als legitime Benutzer auszugeben.

(TS14) Fehlende Input-Validierung:
Angreifer können manipulierte Daten in ein System eingeben, um dessen Funktionalität zu beeinträchtigen oder unbefugten Zugriff zu erlangen, wenn die Input-Validierung unzureichend ist. Typische Angriffe sind:

Buffer Overflow (Pufferüberlauf): Übermäßige Datenmengen führen zu Systemabstürzen und ermöglichen Schadcode-Ausführung.
Canonicalization Attack (Angriff durch Kanonisierung): Manipulation von Dateipfaden gewährt unbefugten Zugriff.
XSS: Bösartige Skripte werden in vertrauenswürdige Webseiten eingebettet.
SQL Injection: Eingabe von SQL-Code, um Datenbanken zu manipulieren oder auszulesen.

(TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen:
Durch eine unzureichend gesicherte Entwicklungsumgebung besteht die Gefahr der Softwaremanipulation, welche schwer zu identifizieren ist. Ohne klare Zugriffsprotokolle werden Änderungen nicht nachvollzogen. Fehlende Versionsverwaltung erschwert die Nachverfolgung von Änderungen und die Wiederherstellung funktionierender Versionen. Unzureichender Schutz des Quellcodes kann zu Beschädigungen und Datenverlust führen, was die Weiterentwicklung der Software behindern kann. Eine neue Version einer Anwendung, die nicht ausreichend getestet ist oder den Freigabeprozess nicht durchlaufen hat, kann durch unzureichendes Management von Berechtigungen der CI/CD-Umgebung dazu führen, dass diese anfälliger für Sicherheitsvorfällen ist.

(TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen):
Unsichere APIs dienen als Einfallstor für Angriffe dienen. Typische Sicherheitslücken sind:

Autorisierung und Authentifizierung:
Schwachstellen in der Autorisierung und Authentifizierung kann ohne die Berechtigungen der Verbindung zu anderen Schnittstellen ausreichend zu überprüfen, dass Angreifer unberechtigten Zugriff auf Daten erhalten. Zudem können Lücken in der Authentifizierungslogik ausgenutzt werden, indem Authentifizierungstokens missbraucht werden. Durch eine unzureichende Trennung zwischen administrativen und betrieblichen Funktionen führt dazu, dass Angreifer privilegierte administrative Rechte erlangen können.
Datenexposition und -verarbeitung:
Die Weitergabe von Sensible Daten ohne vorherige Filterung an Clients können das Risiko ungewollter Datenänderungen erhöhen.
Ressourcenmanagement und Ratenbegrenzung:
Kein Rate Limiting (Begrenzung von Anfragen) ermöglicht z.B. Brute-Force- und DoS-Angriffe (Denial of Service Angriffe), was die Verfügbarkeit beeinträchtigt.
Fehlkonfiguration und Verwaltung:
Unsichere Standardeinstellungen, z.B. bei Cloud-Speichern oder HTTPS-Headern, können z. B. für einen unbefugten Zugriff ausgenutzt werden. Fehlende Dokumentation führt zur versehentlichen Freigabe unsicherer APIs, was das Risiko von Sicherheitslücken erhöht.
Injektion und Angriffsvektoren:
APIs sind anfällig für SQL-Injection-Angriffe, bei denen Angreifer schädlichen Code einschleusen, um Daten zu manipulieren oder zu stehlen.
Überwachung und Protokollierung:
Mangelnde Protokollierung und Überwachung verzögern die Erkennung von Angriffen, was es Angreifern ermöglicht, länger unentdeckt zu bleiben und größeren Schaden anzurichten.

(TS17) Fehlende oder unzureichende Test- und Freigabeverfahren:
Fehlende oder unzureichende Test- und Freigabeverfahren für Änderungen, Updates und Patches führen zu Fehlfunktionen und externen Angriffen. Ohne gründliche Tests und eine kontrollierte Freigabe können Änderungen unbeabsichtigte Nebenwirkungen haben, die die Stabilität und Sicherheit des Informationsverbundes beeinträchtigen. Beispielsweise kann ein nicht ausreichend getestetes Update zu einem Systemabsturz oder einer Sicherheitslücke führen. Infolgedessen könnten schützenswerte Informationen offengelegt, manipuliert oder zerstört werden.

(TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses:
Eine fehlende oder unzureichende Qualitätssicherung während der Software-Entwicklung kann zu Verzögerungen oder sogar zum Scheitern des Projekts führen. Ohne gründliche Überprüfung der Sicherheit der entwickelten Software können Schwachstellen in der finalen Version verbleiben.

(TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA):
Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) fördern Risiken wie unbefugtem Zugriff, Datenverlust und anderen Sicherheitsvorfällen. IAA-Mechanismen sind wesentliche Sicherheitsprozesse zur Sicherstellung des Zugriffs von autorisierten Benutzern und Systemen auf dedizierte Daten und Ressourcen. Diese Mechanismen sind entscheidend, um die Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Ressourcen zu gewährleisten.

Schwache Passwörter, fehlende Multi-Faktor-Authentifizierung (MFA), unzureichende Passwort-Management-Richtlinien, unsichere Speicherung von Anmeldeinformationen, fehlende oder unzureichende Zugriffskontrollen sowie Schwachstellen in Authentifizierungsprotokollen sind typische Schwachstellen unsicherer IAA-Mechanismen. Ohne zusätzliche Authentifizierungsfaktoren wie SMS-Codes oder biometrische Daten und nur die Verwendung von Passwörtern, besonders die schwach sind und/oder wieder verwendet werden, erleichtert es Angreifern, Zugriff auf die Systeme zu erhalten. Unzureichende Passwort-Management-Richtlinien, wie das Fehlen von Richtlinien zur regelmäßigen Änderung von Passwörtern oder zur Vermeidung der Wiederverwendung von Passwörtern, erhöhen das Risiko. Angreifer greifen bei einem Datenleck auf Anmeldeinformationen zu, wenn die Speicherung von Passwörtern in Klartext oder die Verwendung unsicherer Hashing-Algorithmen erfolgt. Ohne Role-based Access Control (RBAC, rollenbasierte Zugriffskontrollen) oder regelmäßige Überprüfung der Zugriffsrechte haben Benutzer unbefugten Zugriff auf Informationen, Daten und Ressourcen. Die Verwendung unsicherer oder veralteter Authentifizierungsprotokolle beherbergen Risiko von Angriffen wie Replay-Angriffen (Angriff durch erneutes Einspielen bzw. Abspielen von zuvor aufgezeichneten Authentifizierungs- oder Autorisierungs-Daten) oder Man-in-the-Middle-Angriffen bzw. Machine-in-the-Middle-Angriffen (MITM, Angriff durch einen Mittelsmann in der Übertragungskette zwischen Kommunikationspartnern).

Die möglichen Folgen unsicherer IAA-Mechanismen sind vielfältig. Angreifer können sich Zugang zu sensiblen Daten und Ressourcen verschaffen, was zu Datenverlust, Datenmanipulation oder Datenlecks führen kann. Sie können ihre Zugriffsrechte erhöhen und auf höher privilegierte Ressourcen zugreifen, was zu schwerwiegenderen Sicherheitsvorfällen führen kann. Unsichere IAA-Mechanismen können es Angreifern ermöglichen, ihre Aktivitäten zu verschleiern und unentdeckt zu bleiben. Zudem können sie die Fähigkeit zur Überwachung und Erkennung von sicherheitsrelevanten Ereignissen beeinträchtigen, was die Reaktionszeit auf Sicherheitsvorfälle verlängert.

(TS20) Unsichere Biometrische Verfahren:
Unsichere biometrische Verfahren werden oft als primäre Authentifizierungsmethode verwendet. Wenn biometrische Systeme nicht ausreichend gesichert sind, können Angreifer diese Systeme überlisten und unbefugten Zugriff erlangen. Beispielsweise können gefälschte Fingerabdrücke verwendet werden, um biometrische Systeme zu täuschen. Typische Sicherheitslücken und Risiken umfassen:

Gefälschte biometrische Merkmale: Angreifer können gefälschte Fingerabdrücke oder Gesichtsbilder verwenden, um Authentifizierungssysteme zu überlisten.
Deepfakes (d.h. täuschend echte, gründliche Fälschung): Durch den Einsatz von künstlicher Intelligenz können Personen durch eine technische Täuschung realitätsnah kopiert werden können.
Speicherung biometrischer Daten: Wenn biometrische Daten in der Cloud oder auf unsicheren Servern gespeichert werden, besteht die Gefahr, dass diese Daten im Rahmen eines Datenlecks offengelegt werden.
Missbrauch durch Dritte: Hinterlegte biometrische Merkmale anderer Personen auf einem Gerät können das Risiko erhöhen, dass Unbefugte das System überlisten.

(TS21) Automatisierte Überwachungstools:
Das Fehlen oder eine unzureichende Aggregation und Korrelation von Systemaktivitäten in einem zentralen Informationssicherheitsmonitor wird die rechtzeitige Entdeckung und Abwehr des Missbrauchs von Ressourcen oder externer Angriffe behindert. Ohne ein effektives Sicherheitssystem können sicherheitsrelevante Ereignisse unbemerkt bleiben, was die Reaktionszeit auf Sicherheitsvorfälle verlängert und die Wahrscheinlichkeit von Datenverlust und Systemkompromittierungen erhöht.

Darüber hinaus behindern unzureichende forensische Mittel und Fähigkeiten die Entdeckung und Abwehr externer Angriffe. Forensische Fähigkeiten sind entscheidend, um nach einem Sicherheitsvorfall Beweise zu sammeln und zu analysieren. Wenn die forensischen Mittel und Fähigkeiten unzureichend sind, haben es Angreifer leichter ihre Spuren zu verwischen und somit unentdeckt zu bleiben. Dies erschwert die Identifizierung der Angreifer und die Wiederherstellung der betroffenen Systeme und Daten.

(TS22) Unzureichende Schwachstellen-Tests:
Mit unzureichende Schwachstellen-Tests können potenzielle Sicherheitslücken in der Konfiguration und Administration von der Cloud-Plattform hin zur SaaS-Anwendung möglicherweise nicht identifiziert und behandelt werden. Regelmäßige und umfassende Schwachstellen-Tests sind durchzuführen, bevor sie von Angreifern ausgenutzt werden können. Ohne diese Tests besteht ein erhöhtes Risiko, dass unsichere Netzwerkarchitekturen oder unzureichende Segmentierungen unentdeckt bleiben. Dies ermöglicht Angreifern unbefugten Zugriff auf Systeme und Daten zu erlangen. Auch besteht das Risiko, dass Angreifer sich lateral innerhalb des Netzwerks bewegen und auf weitere Ressourcen zugreifen können. Angreifer können unentdeckt bleiben und ihre Aktivitäten fortsetzen. Datenverlust, finanziellen Schäden und Reputationsverlust sind die Folgen. Möglicherweise werden dadurch Compliance-Anforderungen nicht erfüllt werden, so dass zusätzlich mit rechtlichen Konsequenzen und Strafen gerechnet werden könnte.

(TS23) Fehlende Implementierung einer Web Application Firewall (WAF):
Eine WAF ist entscheidend, um Webanwendungen vor einer Vielzahl von Web-basierten Angriffen zu schützen, darunter SQL-Injection, Cross-Site Scripting (XSS, Webseitenübergreifendes Scripting) und andere Bedrohungen. Ohne eine angemessene WAF sind Webanwendungen anfällig für diese Angriffe, was zu Datenverlust, Datenmanipulation und unautorisiertem Zugriff auf sensible Informationen führen kann. SQL-Injection-Angriffe ermöglichen es Angreifern, schädlichen SQL-Code in eine Abfrage einzufügen, um auf Datenbanken zuzugreifen oder diese zu manipulieren. XSS ermöglicht es Angreifern, schädlichen Code in Webseiten einzubetten, der dann von anderen Benutzern ausgeführt wird. Beide Angriffsarten können schwerwiegende Folgen haben, einschließlich des Verlusts vertraulicher Daten und der Kompromittierung von Benutzerkonten.

(TS24) Zertifikatslaufzeiten:
Wenn Zertifikate ablaufen oder veraltet sind, führt das zu Ausfallzeiten, da verschlüsselte Verbindungen nicht mehr als sicher erkannt werden. Zudem erhöht sich das Risiko von MITM-Angriffen und Schlüsseldiebstahl, da Angreifer veraltete oder kompromittierte Zertifikate ausnutzen können.

(TS25) Fehlende Sicherung der Datenträger:
Um die Integrität und Vertraulichkeit von Daten im Ruhezustand zu gewährleisten, ist es entscheidend, dass alle gespeicherten Daten ordnungsgemäß gesichert und verschlüsselt sind. Dies umfasst die Verschlüsselung von Festplatten, Datenbanken und Backup-Medien usw. Besonders Datenträgern sind bei unzureichender Sicherung leicht zugänglich:

Unbefugter Zugriff: Ohne ausreichende Verschlüsselung können unbefugte Personen, die Zugang zu den Datenträgern erhalten, sensible Daten auslesen und manipulieren.
Datenverlust und Sicherheitsverletzungen: Sensible Informationen können kompromittiert werden, was zu finanziellen Verlusten und Reputationsschäden führen kann.

(TS26) Unzureichende Wartung:
Regelmäßige Wartungsmaßnahmen, wie das regelmäßige Einspielen von Sicherheitsupdates oder -patches, sind entscheidend, um Systeme und Anwendungen sicher und funktionsfähig zu halten. Wenn Sicherheitsupdates und -patches nicht zeitnah eingespielt werden, bleiben Schwachstellen in der Software unentdeckt und nicht behoben.

5.3. Zusammenfassung der Bedrohungsanalyse

Für die Risikoanalyse werden die bekannten Bedrohungen aufgegriffen und die hierauf zutreffenden Risiken im Hinblick auf ihr Schadenspotential und die Eintrittswahrscheinlichkeit bewertet.

– TBD –

Die wesentlichen Bedrohungen umfassen die Kompromittierung von administrativen und Fachbenutzerschnittstellen, dem ungeregelten Umgang mit Benutzerzugängen und Berechtigungen als auch dem Verlust von Daten durch Remote-Benutzer. Art und Umfang des Risikos ist anhand der Risikoanalyse zu ermitteln.

6. Risikoanalyse

Die hier dargestellte Risikoanalyse zielt darauf ab, potenzielle Sicherheitsrisiken und Schwachstellen zu identifizieren, zu bewerten und geeignete Maßnahmen zur Risiko-Mitigierung einzusetzen. Die Risikobewertung erfolgt in Anlehnung an den BSI-Standard 200-3. Dabei werden sowohl die Eintrittswahrscheinlichkeit als auch die mögliche Schadensauswirkung von identifizierten Risiken berücksichtigt, welche auf den zuvor dargestellten technischen und organisatorischen Schwachstellen basieren. Zur Risiko-Mitigierung werden sowohl technische als auch organisatorische Maßnahmen erfasst, siehe dazu Kapitel 7.

6.1. Erstellung einer Gefährdungsübersicht

In diesem Kapitel werden mögliche Gefährdungen mit dem Kürzel “GE” aufgelistet.

(GE01) Vendor-Lock-In
Die fehlende Verfügbarkeit von Standarddatenformaten oder Serviceschnittstellen beeinträchtigt die Daten- und Serviceportabilität. Dies kann zu erheblichen Problemen führen, wenn ein Anbieterwechsel oder eine Migration aus der internen IT-Umgebung erforderlich wird.

(GE02) Unzureichende Kenntnis über Regelungen
Das bloße Festlegen von Regelungen stellt nicht sicher, dass diese auch eingehalten werden und einen reibungslosen Betrieb sicherstellen. Alle Mitarbeitenden, insbesondere die Leitenden, müssen die geltenden Regelungen kennen. Schäden, die durch Unkenntnis dieser Regelungen entstehen, dürfen nicht durch eigene Aussagen über Unwissenheit entschuldigt werden.

(GE03) Ausfall der Dienstverfügbarkeit
Ein Ausfall der Dienstverfügbarkeit kann durch verschiedene Ursachen wie Hardwarefehler, Softwarefehler, Netzwerkprobleme oder menschliches Versagen verursacht werden. Solche Ausfälle können zu erheblichen Betriebsunterbrechungen führen.

(GE04) Beendigung oder Ausfall von IT-Diensten
Wenn der IT-Anbieter aus dem Geschäft ausscheidet oder seine Dienste einstellt, kann dies dramatische Auswirkungen auf die Benutzerseite haben. Dies kann zu einem plötzlichen Verlust des Zugriffs auf wichtige Dienste und Daten führen. Die Folgen sind möglicherweise unter anderem erhebliche Betriebsunterbrechungen und finanzielle Verluste.

(GE05) Akquisition von IT-Anbietern
Die Übernahme eines IT-Anbieters könnte die Wahrscheinlichkeit eines strategischen Wandels erhöhen. Unverbindliche Vereinbarungen könnten gefährden sein, wie beispielsweise Softwareschnittstellen, Sicherheitsinvestitionen und außervertragliche Sicherheitskontrollen.

(GE06) Compliance-Kontrollverlust
Die Auslagerung IT-Bestandteile auf externe IT-Services kann sich auf die eigenen erworbenen Zertifizierungen und die von Dritten, sowie auf die gesetzlichen Anforderungen auswirken.

(GE07) Beeinflussung der geschäftlichen Reputation durch Aktivitäten andere Nutzende
Die Nutzung gemeinsamer virtueller Ressourcen und virtueller Infrastrukturen kann zu einer Beeinträchtigung der Dienste führen. Besonders bei böswilligen Aktivitäten bei einem einzigen Konsumenten.

(GE08) Unbeeinflussbare Änderungen in der Lieferkette
Wenn ein IT-Betrieb spezialisierte Aufgaben an externe Dienstleister auslagert, kann das Sicherheitsniveau des gesamten Systems von der Sicherheit dieser Drittanbieter abhängen. Jede Schwachstelle bei einem externen Partner kann die Sicherheit des IT-Betriebs gefährden.

(GE09) Ineffizientes Management der virtuellen Ressourcen
Ineffizientes Ressourcenmanagement kann zu erheblichen Problemen führen. Eine Unterbereitstellung von Ressourcen kann die Leistung und Verfügbarkeit der Dienste beeinträchtigen, während eine Überbereitstellung die Wirtschaftlichkeit und Reputation beeinträchtigen kann.

(GE10) Versagen der Mandantenfähigkeit
Die Nutzung gemeinsamer virtueller Rechen-, Speicher- und Netzwerkkapazitäten in einer mandantenfähigen Umgebung bedeutet, dass mehrere Benutzer dieselben Ressourcen teilen. Wenn die Mechanismen zur Trennung dieser Ressourcen versagen, kann dies die Verfügbarkeit und Vertraulichkeit der Daten jedes einzelnen Benutzers direkt beeinträchtigen.

(GE11) Missbrauch von Rollen und Rechten
Bei Ausführung bösartiger Aktivitäten ausführt kann sich dies auf sämtliche Daten, Dienste und die Reputation des Unternehmens auswirken.

(GE12) Datenabgriff während der Übermittlung
In einer verteilten Architektur erfolgt der Datentransfer zwischen verschiedenen IT-Komponenten, besonders wenn externe IT-Infrastrukturen genutzt werden. Es besteht die Gefahr, dass Daten während der Übertragung abgefangen und kompromittiert werden.

(GE13) Datenabgriff bis hin zum Verlust beim Hoch-/Herunterladen innerhalb der IT-Infrastruktur
Bei einem Datentransfer zwischen IT-Anbieter und Benutzer zwischen verschiedenen IT-Komponenten besteht die Gefahr, dass Daten während der Übertragung abgefangen und kompromittiert werden.

(GE14) Distributed denial of service (DDoS)
Erreichbare Schnittstellen zum Internet macht die Umgebung anfällig für Denial-of-Service-Angriffe.

(GE15) Verlust von Schlüsseln zur Verschlüsselung
Unbefugtes Erlangen von geheimen Schlüsseln (wie SSL) oder Passwörtern durch Dritte, sowie die Gefahr des Verlusts oder der Beschädigung dieser Schlüssel, was ihre Funktion zur sicheren Authentifizierung und digitalen Signatur beeinträchtigen kann.

(GE16) Anforderungsdifferenzen an die IT-Umgebung und die der Benutzer
Das Versagen von Benutzer, ihre Umgebungen ordnungsgemäß zu schützen, kann eine Schwachstelle für die IT-Plattform darstellen, wenn der IT-Anbieter nicht die notwendigen Schritte zur Isolierung unternommen hat. Dazu zählt auch eine unklare Definition der Anforderungen.

(GE17) Datenschutzrisiken
Als Datenschutzverantwortlicher kann eine Überprüfung der Datenverarbeitungsprozesse des IT-Anbieters herausfordernd sein. Neben Gefahr von Datensicherheitsverletzungen, besteht die Gefahr die Meldepflicht zu verletzen.

(GE18) Lizenzrisiken
Lizenz und dessen Bedingungen können in einer IT-Umgebung unbrauchbar werden.

(GE19) Unbefugte Berechtigungsausweitung
Fehlkonfigurationen von Rollen und Zugriffsrechten, fehlende Software-Updates oder unbekannte Schwachstellen können dazu führen, dass Benutzerrechte ungewollt ausgeweitet werden.

(GE20) Angriffe durch Social Engineering
Durch Social Engineering können Angreifer sensible Zugangsdaten wie Benutzernamen und Passwörter erlangen. Typische Angriffsstrategien beinhalten das Täuschen von Opfern, indem sie sich als vertrauenswürdige IT-Mitarbeiter oder Vorgesetzte ausgeben, um vertrauliche Informationen zu sammeln.

(GE21) Gefährdung und Verlust von Log-Daten
Ohne vollständige und unverfälschte Log-Daten wird es schwierig, Sicherheitsvorfälle zu identifizieren, zu analysieren und darauf zu reagieren. Dies kann die Fähigkeit zur Aufrechterhaltung der Systemintegrität und zur Durchführung von Audits erheblich einschränken.

(GE22) Verlust oder Gefährdung von Sicherheitsprotokollen
Sicherheitsprotokolle sind unter anderem für die forensische Untersuchung von Sicherheitsvorfällen unerlässlich. Der Verlust oder die Kompromittierung dieser Protokolle könnte die Fähigkeit zur effektiven Untersuchung und Reaktion auf Sicherheitsvorfälle erheblich behindern.

(GE23) Verlust oder Diebstahl von Backups
Gestohlene oder verlorene Backups können zu einem vollständigen Datenverlust führen, insbesondere wenn die Daten nicht verschlüsselt sind. Angreifer könnten erpressen und sensible Informationen kompromittieren.

6.2. Risikobewertung

Das in diesem Sicherheitskonzept angewendete Verfahren zur Bewertung der Risiken lehnt sich an den BSI-Standard 200-3 an und umfasst demnach bei der Bewertung zum einen die Eintrittswahrscheinlichkeit und zum anderen die mögliche Schadensauswirkung.

Die X-Achse spiegelt die Eintrittshäufigkeit wider, welche in vier Häufigkeiten kategorisiert ist. Diese Kategorien bieten eine Grundlage zur Bewertung der Eintrittswahrscheinlichkeit eines Risikos.

Selten: Das Risiko tritt sehr unwahrscheinlich und selten auf.
Mittel: Das Risiko ist möglich und kann gelegentlich auftreten.
Häufig: Das Risiko ist wahrscheinlich und tritt häufig auf.
Sehr häufig: Das Risiko ist sehr wahrscheinlich und tritt sehr häufig auf.

Die Y-Achse ist auch in vier Kategorien unterteilt, die die Auswirkungen des Risikos einordnen.

Vernachlässigbar: Die Schadensauswirkungen sind so gering, dass sie vernachlässigt werden können.
Begrenzt: Die Auswirkungen des Schadens sind begrenzt und kontrollierbar.
Beträchtlich: Die Auswirkungen des Schadens können umfangreich sein.
Existenzbedrohend: Die Auswirkungen des Schadens können existenziell bedrohlich und essenziell sein.

Die Risikoeinstufung ist das Ergebnis aus der Kategorie der Eintrittshäufigkeit und Auswirkungen. Die Risikokategorien helfen, die Bedrohungsgrade und die Wirksamkeit der vorgesehenen Sicherheitsmaßnahmen zu bewerten. Folgende Risikoeinstufungen sind bestimmt:

gering: In der Praxis werden geringe Risiken akzeptiert und weiter beobachtet. Die bisher realisierten oder im Sicherheitskonzept vorgesehenen Maßnahmen ermöglichen einen angemessenen Schutz.
mittel: Eventuell bieten die implementierten oder im Sicherheitskonzept vorgesehenen Maßnahmen nicht genügend Schutz.
hoch: Keinen hinreichenden Schutz gegen die jeweilige Bedrohung bieten die umgesetzten oder im Sicherheitskonzept geplanten Sicherheitsmaßnahmen.
sehr hoch: Keinen ausreichenden Schutz vor der jeweiligen Gefährdung bieten die bereits umgesetzten oder zumindest im Sicherheitskonzept vorgesehenen Sicherheitsmaßnahmen.

Für die Analyse gelten folgende Bewertungskriterien:

Eintrittshäufigkeit / Auswirkungen	selten	mittel	häufig	sehr häufig
vernachlässigbar	gering	gering	gering	gering
begrenzt	gering	mittel	mittel	hoch
beträchtlich	mittel	mittel	hoch	sehr hoch
existenzbedrohend	hoch	hoch	sehr hoch	sehr hoch

6.3. Behandlung der Risiken

Die Behandlung der Risiken umfasst die systematische Identifikation und Bewertung potenzieller Bedrohungen sowie die Entwicklung geeigneter Gegenmaßnahmen. Dabei fließen sowohl organisatorische als auch technische Maßnahmen mit ein. Eine detaillierte Auflistung der Maßnahmen zur Risikobehandlung werden in Kapitel 7 aufgelistet.

(GE01) Vendor-Lock-In

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS27) Vertraulichkeitsvereinbarungen (NDA)
Betroffene Assets	(AS01) Infrastruktur (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.03) Asset Management (OM03.05) Open-Source (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (TM01.01) Ressourcen Management
Restrisiko	gering
Begründung	Die IT-Architektur basiert auf Modularität, Austauschbarkeit und Interoperabilität.

(GE02) Unzureichende Kenntnis über Regelungen

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	begrenzt
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS17) Unklarer Besitz von Assets (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen
Betroffene Assets	(AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM05.01) Ticketsystem (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM08.01) Hintergrundüberprüfung (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM03.03) Common Vulnerabilities und Exposures (CVE) (TM04.06) Whitelisting (TM11.02) Sichere Konfiguration (Container) (TM11.03) Durchsetzung von Richtlinien (Container)
Restrisiko	gering
Begründung	Fortlaufende Schulungen und die Verfügbarkeit einer aktuellen und zugänglichen Dokumentation der Regelungen und Richtlinien sind zu gewährleisten, so dass alle Mitarbeiter über die notwendigen Kenntnisse verfügen.

(GE03) Ausfall der Dienstverfügbarkeit:

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	beträchtlich
Schwachstellen	(OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS16) Fehlende oder unzureichende Klassifizierung der Assets (OS19) Unzureichendes Release und Deployment Management (OS20) Unzureichendes Configuration und Changemanagement (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS22) Planung von Ressourcen (OS23) Backup (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS08) Unsichere Mandantenfähigkeit (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS26) Unzureichende Wartung
Betroffene Assets	(AS01) Infrastruktur (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM02.01) Integration in BCM/ITSCM (OM02.02) Prüfung Business Continuity Prozesse (OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM12.01): Staging Umgebung (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.03) Erkennung von Schwachstellen (OM15.01) Bestimmung der Akzeptanzniveaus (OM15.03) Informationen zu Sicherheitsproblemen (OM16.05) Wirkungsanalyse Service-Ausfall (OM17.04): Portabilität von Diensten gewährleisten (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.01) Ressourcen Management (TM01.02) Patch Management (TM03.01) Härtung (TM03.02) Härtung (Kubernetes) (TM04.01) Zentrales Logging und Monitoring (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM07.01) Hochverfügbarkeit (TM07.02) Kubernetes Resilienz (TM08.01) Generelle Netzwerksicherheit (TM11.01) Härtung der Anwendungscontainer (Container) (TM11.02) Sichere Konfiguration (Container) (TM11.04) Host-basierte Angriffserkennung (Container) (TM11.05) Vorsorge für Untersuchungen (Container) (TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container) (TM12.02) Durchsetzung von Richtlinien (Kubernetes) (TM12.03) Kubernetes Nodes (TM12.04) Automatisierung und Versionskontrolle
Restrisiko	gering
Begründung	Hochverfügbarkeitslösungen und kontinuierliche Überwachung der Systeme gewährleisten eine schnelle Wiederherstellung der Dienstverfügbarkeit im Falle eines Ausfalls.

(GE04) Beendigung oder Ausfall von IT-Diensten

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS23) Backup (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS02) Backup- und Wiederherstellungssysteme (AS04) Benutzerzugänge
Gesamtrisiko	hoch
Maßnahmen	(OM02.01) Integration in BCM/ITSCM (OM03.03) Asset Management (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.04) Service Level Agreements mit Dienstleister (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (TM04.06) Whitelisting (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM09.01) Tests von Backup und Wiederherstellung (TM11.05) Vorsorge für Untersuchungen (Container)
Begründung	Geordnete Prozesse bei Beendigung von Diensten, sowie die Portabilität, Flexibilität und Backup-Funktionalitäten stellen den Betrieb auch bei beendeten oder ausgefallenen IT-Dienste wieder.
Restrisiko	gering

(GE05) Akquisition von IT-Anbietern

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS21) Mangelnder und ungetesteter Business Continuity und Disaster Recovery Plan (OS23) Backup (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS01) Infrastruktur (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.04) Service Level Agreements mit Dienstleister (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM17.05) Migration von Anwendungen (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM07.03) Replikation von Daten (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Definierte Service Level Agreements, geordnete Prozesse bei Änderungen von Diensten, sowie die Portabilität, Flexibilität und Backup-Funktionalitäten sichern den Betrieb auch bei geänderten Umständen beim IT-Anbieter.

(GE06) Compliance-Kontrollverlust

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	begrenzt
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS06) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren
Betroffene Assets	(AS01) Infrastruktur (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (TM04.06) Whitelisting (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM11.01) Outsourcing (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.03) Schulung des Betriebs und der Administration (OM15.04) Verstoß gegen Sicherheitsrichtlinien (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Die Gefahr des Kontrollverlustes über die eigene Compliance wird eingedämmt, indem einerseits organisatorische Absicherungen vereinbart sind. Andererseits sorgen technische Maßnahmen dafür nur bestimmte Bereiche angesteuert werden können und zudem eine Protokollierung von Zugriffen erfolgt.

(GE07) Beeinflussung der geschäftlichen Reputation durch Aktivitäten anderer Nutzende

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	beträchtlich
Schwachstellen	(OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (TS08) Unsichere Mandantenfähigkeit (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren
Betroffene Assets	(AS01) Infrastruktur (AS04) Benutzerzugänge (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.02) Vergabe von Zugriffsrechten (OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM10.01) Passwortsicherheit (OM13.03) Schulung des Betriebs und der Administration (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM01.01) Ressourcen Management (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM11.03) Durchsetzung von Richtlinien (Container) (TM11.08) Weitergehende Isolation und Kapselung (Container)
Begründung	Durch die Sicherstellung der technischen und organisatorischen Ressourcen-, und Kapazitätsplanung, Zugriffsverwaltung und der Benutzerzugriffe ist ein Risiko dahingehend mitigiert.
Restrisiko	gering

(GE08) Unbeeinflussbare Änderungen in der Lieferkette

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	begrenzt
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS24) Auswahl und Management von Dienstleistern (OS25) Multisourcing-Strategie (OS26) Management von Drittanbieter-Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement
Betroffene Assets	(AS01) Infrastruktur (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM09.02) Aktivitätenerfassung abstimmen (OM09.04) Speicherung und Zugriff auf Identitäten (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.03) Schulung des Betriebs und der Administration (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM18.01) Image-Provenance (Container) (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM08.05) Dienst- und Anwendungstrennung
Restrisiko	gering
Begründung	Um unkontrollierbare Änderungen in der Lieferkette zu minimieren, wurden sowohl organisatorische als auch technische Maßnahmen vorgenommen. Die getroffenen organisatorische Maßnahmen bieten Absicherung auf nicht-technischer Ebene, während technische Vorkehrungen sicherstellen, dass nur bestimmte Bereiche zugänglich sind und alle Zugriffe protokolliert werden.

(GE09) Ineffizientes Management der virtuellen Ressourcen

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	begrenzt
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS18) Ungeeignetes Vorgehensmodell für die Softwareentwicklung (OS22) Planung von Ressourcen (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.01) Ressourcenplanung (OM03.02) Kapazitätsplanung (OM03.03) Asset Management (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.09) Benutzerdokumentation (OM09.02) Aktivitätenerfassung abstimmen (OM13.01) Änderungsdokumentation (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM17.01) Bereitstellung von Diensten (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.01) Ressourcen Management (TM01.03) Quotas, Request & Limits (Kubernetes) (TM04.01) Zentrales Logging und Monitoring (TM11.02) Sichere Konfiguration (Container)
Begründung	Durch die Sicherstellung der dedizierten Planung von virtuellen Ressourcen anhand des dokumentierten IT-Betriebs, sowie die technische Umsetzung der Dokumentation inkl. dedizierter Verantwortlichkeiten, sind virtuelle Ressourcen effizient gemanaged.
Restrisiko	gering

(GE10) Versagen der Mandantenfähigkeit

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS15) Fehlende, unvollständige oder ungenaue Bestandsaufnahme der Assets (OS17) Unklarer Besitz von Assets (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS08) Unsichere Mandantenfähigkeit
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme* (AS04) Benutzerzugänge (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM14.03) Erkennung von Schwachstellen (OM15.06) Statuskommunikation (OM17.01) Bereitstellung von Diensten (OM17.02) Änderung und Aktualisierung von Diensten (OM17.03) Dienstdokumentation (TM01.01) Ressourcen Management (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM11.03) Durchsetzung von Richtlinien (Container) (TM11.08) Weitergehende Isolation und Kapselung (Container)
Begründung	Das Versagen der Mandantenfähigkeit wir durch die Gestaltung von openDesk als SaaS-Lösung mitigiert.
Restrisiko	gering

(GE11) Missbrauch von Rollen und Rechten

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS17) Unklarer Besitz von Assets (OS28) Kundenmanagement (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS08) Unsichere Mandantenfähigkeit (TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme* (AS04) Benutzerzugänge (AS06) Anwendungen
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.01) Hintergrundüberprüfung (OM08.02) Vergabe von Zugriffsrechten (OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM09.03) Speicherung und Löschung von Benutzerdaten (OM09.04) Speicherung und Zugriff auf Identitäten (OM10.01) Passwortsicherheit (OM11.02) Autorisierung von Dienstleistern (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM01.01) Ressourcen Management (TM03.01) Härtung (TM04.04) Löschung von Protokolldaten (TM04.06) Whitelisting (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM06.02) Secret Verwaltung (TM06.03) Kubernetes Secret Management (TM11.02) Sichere Konfiguration (Container) (TM11.06) Unveränderlichkeit (Container) (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM12.02) Durchsetzung von Richtlinien (Kubernetes) (TM12.04) Automatisierung und Versionskontrolle (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Eine umfassende Rollen- und Rechtestruktur, sowohl auf organisatorischer als auch auf technischer, lässt den Missbrauch von Rollen und Rechten auf ein geringes Risiko eindämmen.
Restrisiko	gering

(GE12) Datenabgriff während der Übermittlung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (OS20) Unzureichendes Configuration und Changemanagement (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS09) Fernzugriff auf die Managementoberfläche (TS10) Unzureichende Sicherheit von Kubernetes-Umgebungen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS14) Fehlende Input-Validierung (TS15) Unzureichend gesicherter Einsatz von Entwicklungsumgebungen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten (AS06) Anwendungen
Gesamtrisiko	sehr hoch
Maßnahmen	(OM01.01) Einhaltung Sicherheitskonzept (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.02) Patch Management (TM03.01) Härtung (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM08.05) Dienst- und Anwendungstrennung (TM09.02) Verschlüsselung Backup (TM10.01) Regelmäßige Penetrationstests (TM10.02) Isolierung bei APT-Vorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme (TM12.01) Container Plattform (Kubernetes) (TM12.05) Lebenszyklus eines Pods (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Dedizierte getroffene organisatorische und technische Maßnahmen auf IaaS, PaaS und SaaS-Layer mitigieren das Risiko des Datenabgriffs während der Übermittlung.
Restrisiko	gering

(GE13) Datenabgriff bis hin zum Verlust beim Hoch-/Herunterladen innerhalb der IT-Infrastruktur

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten
Gesamtrisiko	sehr hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.02) Schwachstellenmanagement (OM14.03) Erkennung von Schwachstellen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.02) Patch Management (TM03.01) Härtung (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.03) Logging, Monitoring & Auditing (Kubernetes) (TM04.06) Whitelisting (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM09.02) Verschlüsselung Backup (TM10.01) Regelmäßige Penetrationstests (TM10.02) Isolierung bei APT-Vorfällen
Begründung	Der Informationsverbund wird auf einer ISO 27001 zertifizierten und C5 Testat-2 konformen Hyperscaler Umgebung betrieben.
Restrisiko	gering

(GE14) Distributed denial of service (DDoS)

Kategorie	Wert
Eintrittswahrscheinlichkeit	sehr häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (TS05) Fehlende Ressourcenisolierung (TS13) Unzureichende Sicherheit von Applikationen (TS16) Unsichere Application Programming Interfaces (API, Programmierschnittstellen) (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS22) Unzureichende Schwachstellentests (TS23) Fehlende Implementierung einer Web Application Firewall (WAF) (TS26) Unzureichende Wartung
Betroffene Assets	(AS03) Schnittstellen (AS06) Anwendungen
Gesamtrisiko	sehr hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.03) Erkennung von Schwachstellen (OM15.01) Bestimmung der Akzeptanzniveaus (OM15.02) Risikobewertungen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.07) Forensische Untersuchungen (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM18.02) Regelmäßige Updates (Container) (OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container) (OM18.04) Überwachung und kontinuierliche Sicherheitsscans (Container) (TM01.03) Quotas, Request & Limits (Kubernetes) (TM03.03) Common Vulnerabilities und Exposures (CVE) (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung (TM10.02) Isolierung bei APT-Vorfällen (TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container) (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Eine skalierfähige Plattform, sowie die Überwachung der Umgebung bis hin zu sicheren Webanwendung lassen das Risiko abschwächen.
Restrisiko	gering

(GE15) Verlust von Schlüsseln zur Verschlüsselung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.02) Risikobewertungen (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.06) Statuskommunikation (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM06.02) Secret Verwaltung* (TM06.03) Kubernetes Secret Management (TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes) (TM08.01) Generelle Netzwerksicherheit (TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster (TM08.03) Netzwerk Segmentierung (TM09.02) Verschlüsselung Backup (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme (TM12.06) Trennung und Sicherheit von Pods und Containern (TM13.01) Datenbanksysteme
Begründung	Durch die dedizierte Segmentierung der verschiedenen Layern, sowie u.a. die Verwaltung des Secrets für dedizierte Bereiche lassen das Risiko abschwächen. Weitere Maßnahmen wie Änderungen von Schlüsseln oder Neuinstallationen der Systeme lassen selbst bei einem Vorfall schnelle Reaktionen zu.
Restrisiko	gering

(GE16) Anforderungsdifferenzen an die IT-Umgebung und die der Benutzer

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS28) Kundenmanagement (TS04) Mangelhaftes & unsicheres Ressourcenmanagement (TS05) Fehlende Ressourcenisolierung (TS07) Unsichere Kommunikationskanäle (TS08) Unsichere Mandantenfähigkeit (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.03) Asset Management (OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM04.01) Bestimmung von Nutzungsbedingungen (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.05) Segregation von Tätigkeiten (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM18.01) Image-Provenance (Container) (TM01.01) Ressourcen Management (TM02.01) Charakteristiken der IaaS- und PaaS-Services (TM05.01) Mandantentrennung und Multi-Mandantenfähigkeit (TM05.03) Benutzerauthentifizierung (TM07.01) Hochverfügbarkeit
Begründung	Die Sicherung der Umgebung erfolgt nach technischen Vorgaben. Etwaige Änderungen von Anforderungen werden valide geprüft. Auch die Umsetzung der Anforderungen, um die Sicherheit der Umgebung nicht zu gefährden.
Restrisiko	gering

(GE17) Datenschutzrisiken

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS11) Unzureichende Container-Sicherheit (TS12) Unzureichende Datenbanksicherheit (TS13) Unzureichende Sicherheit von Applikationen (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS04) Benutzerzugänge (AS05) Protokolle und Überwachungsdaten (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM09.03) Speicherung und Löschung von Benutzerdaten (OM09.04) Speicherung und Zugriff auf Identitäten (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.03) Informationen zu Sicherheitsproblemen (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.06) Statuskommunikation (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (OM16.03) Audit-Tools (OM16.04) Audit-Protokolle (OM18.01) Image-Provenance (Container) (TM04.01) Zentrales Logging und Monitoring (TM04.04) Löschung von Protokolldaten (TM05.04) Protokollierung der Zugriffe (TM06.01) Verwendung von Benutzerdaten (TM13.01) Datenbanksysteme (TM13.02) Sicherheitsanforderungen an Webanwendungen
Begründung	Das Risiko des Verstoßes gegen den Datenschutz werden durch eine Vielzahl organisatorischer und technischer Maßnahmen mitigiert, u.a. durch die Protokollierungen von Zugriffen, Sicherungen von Datenbanken und Webanwendungen selber.
Restrisiko	gering

(GE18) Lizenzrisiken

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	existenzbedrohend
Schwachstellen	(OS01) Fehlende oder mangelnde Definitionen der Projektanforderungen und Nutzerbeteiligung (OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS04) Unklare Rollen und Verantwortlichkeiten (OS05) Mangelhafte Durchsetzung der Rollendefinitionen (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein
Betroffene Assets	(AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM03.05) Open-Source (OM15.06) Statuskommunikation (OM17.03) Dienstdokumentation (OM17.04) Portabilität von Diensten gewährleisten (OM17.05) Migration von Anwendungen
Begründung	openDesk ist ein Open-Source-Entwicklungsprojekt, welches portabel in andere Umgebungen integriert werden kann. Selbst bei möglichen Risiken von Lizenzverstößen, ist eine Migration ungestört möglich.
Restrisiko	gering

(GE19) Unbefugte Berechtigungsausweitung

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	beträchtlich
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (TS06) Unsichere Managementinterfaces (TS07) Unsichere Kommunikationskanäle (TS09) Fernzugriff auf die Managementoberfläche (TS17) Fehlende oder unzureichende Test- und Freigabeverfahren (TS18) Fehlende oder unzureichende Qualitätssicherung des Entwicklungsprozesses (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools (TS22) Unzureichende Schwachstellentests (TS26) Unzureichende Wartung
Betroffene Assets	(AS01) Infrastruktur (AS02) Backup- und Wiederherstellungssysteme (AS04) Benutzerzugänge (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM07.05) Segregation von Tätigkeiten (OM07.06) Provisionierung von Benutzern (OM07.07) De-Provisionierung von Benutzern * (OM07.08) Kontenverwaltung (OM07.09) Benutzerdokumentation (OM07.10) Benutzertrennung (OM08.02) Vergabe von Zugriffsrechten (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen* (OM09.02) Aktivitätenerfassung abstimmen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen* (OM14.02) Schwachstellenmanagement (OM14.04) Vorfallmanagement (OM15.04) Verstoß gegen Sicherheitsrichtlinien (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.01) Log-Dateien Überprüfung (OM16.02) Protokollierungsprozess (TM01.02) Patch Management (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM04.05) Ausführliche Protokollierung zur Sicherung der Archive (TM04.06) Whitelisting (TM05.02) Authentifizierung & Autorisierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM05.05) User, Rollen und Rechte (Kubernetes) (TM05.06) Automations-User und personalisierte User (Kubernetes) (TM11.02) Sichere Konfiguration (Container) (TM11.06) Unveränderlichkeit (Container)
Begründung	Eine strikte organisatorische Trennung und eine technische Trennung von Benutzerzugriffen, lassen dedizierte Nutzerzugriffe steuern und eine Ausweitung eindämmen.
Restrisiko	gering

(GE20) Angriffe durch Social Engineering

Kategorie	Wert
Eintrittswahrscheinlichkeit	häufig
Auswirkung	existenzbedrohend
Schwachstellen	(OS02) Effektives Risikomanagement und Überprüfungsprozesse (OS03) Umfassende Schulung und Sensibilisierung des Personals (OS27) Need-to-know-Prinzip nicht angewendet (OS07) Unzureichende Trennung von Zuständigkeiten (OS08) Mangelndes Sicherheitsbewusstsein (OS09) Provisionierung von Benutzern (OS10) De-Provisionierung von Benutzern (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS27) Vertraulichkeitsvereinbarungen (NDA) (OS28) Kundenmanagement (TS09) Fernzugriff auf die Managementoberfläche (TS19) Unsichere Identifikations-, Authentifizierungs- und Autorisierungsmechanismen (IAA) (TS20) Unsichere Biometrische Verfahren (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS04) Benutzerzugänge
Gesamtrisiko	sehr hoch
Maßnahmen	(OM07.01) Rollen- und Berechtigungskonzept (OM07.02) Dokumentation von Rollen und Verantwortlichkeiten (OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM08.01) Hintergrundüberprüfung (OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen (OM09.02) Aktivitätenerfassung abstimmen (OM10.01) Passwortsicherheit (OM11.02) Autorisierung von Dienstleistern (OM11.03) Einhaltungen von vertraglichen Vereinbarungen (OM11.05) Beendigung von Dienstleistungsverhältnissen (OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung (OM13.03) Schulung des Betriebs und der Administration (OM14.01) Kommunikation von Sicherheitsmaßnahmen (OM14.04) Vorfallmanagement (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM15.07) Forensische Untersuchungen (OM16.02) Protokollierungsprozess (TM04.01) Zentrales Logging und Monitoring (TM04.02) Auswertung der Ereignisprotokollierung (TM05.03) Benutzerauthentifizierung (TM05.04) Protokollierung der Zugriffe (TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen (TM10.04) Sicherheitsbedingte Neuinstallation der Systeme
Begründung	Die Unterteilung der Zugriffe auf technischer Ebene, aber auch die Verteilung der Verantwortung in der Organisation, schmälern das Risiko des Social Engineerings.
Restrisiko	gering

(GE21) Gefährdung und Verlust von Log-Daten

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS12) Unzureichende Datenbanksicherheit (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS05) Protokolle und Überwachungsdaten
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.01) Log-Dateien Überprüfung (OM16.03) Audit-Tools (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung
Begründung	Dedizierte, Verschlüsselte Zugriffe mitigieren das Risiko der Gefährdung von Log-Daten. Selbst bei Verlust sind die Daten kurzfristig wiederherzustellen.
Restrisiko	gering

(GE22) Verlust oder Gefährdung von Sicherheitsprotokollen

Kategorie	Wert
Eintrittswahrscheinlichkeit	mittel
Auswirkung	beträchtlich
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS13) Unzureichende Kontrolle der Umsetzung von Sicherheitsrichtlinien (OS14) Fehlende Richtlinien oder unzureichende Verfahren für die Sammlung und Aufbewahrung von Protokollen (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS12) Unzureichende Datenbanksicherheit (TS21) Automatisierte Überwachungstools (TS25) Fehlende Sicherung der Datenträger
Betroffene Assets	(AS02) Backup- und Wiederherstellungssysteme (AS03) Schnittstellen (AS05) Protokolle und Überwachungsdaten
Gesamtrisiko	mittel
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (OM16.02) Protokollierungsprozess (OM16.04) Audit-Protokolle (TM04.02) Auswertung der Ereignisprotokollierung (TM04.04) Löschung von Protokolldaten (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung
Begründung	Dedizierte, Verschlüsselte Zugriffe mitigieren das Risiko der Gefährdung von Sicherheitsprotokollen. Selbst bei Verlust sind die Daten kurzfristig wiederherzustellen.
Restrisiko	gering

(GE23) Verlust oder Diebstahl von Backups

Kategorie	Wert
Eintrittswahrscheinlichkeit	selten
Auswirkung	existenzbedrohend
Schwachstellen	(OS03) Umfassende Schulung und Sensibilisierung des Personals (OS08) Mangelndes Sicherheitsbewusstsein (OS11) Zugriffskontrollen (OS12) Fehlende oder unzureichende Sicherheitsrichtlinien (OS23) Backup (TS01) Hypervisor-Schwachstellen (TS02) Fehlende Netzwerkverschlüsselung (TS03) Fehlende Verschlüsselung der Prozessoren & des Arbeitsspeichers (TS05) Fehlende Ressourcenisolierung (TS21) Automatisierte Überwachungstools
Betroffene Assets	(AS05) Protokolle und Überwachungsdaten (AS06) Anwendungen
Gesamtrisiko	hoch
Maßnahmen	(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten (OM06.01) Datensicherung (OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung (OM06.03) Sicherung von Produktionsdaten (OM06.04) Physisch getrennte Backup-Speichermedien (OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen (OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups (OM06.07) Absicherung der Wiederherstellbarkeit von Backups (OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne (OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung (OM15.05) Alarmierung sicherheitsrelevanter Ereignisse (TM04.05) Ausführliche Protokollierung zur Sicherung der Archive (TM05.04) Protokollierung der Zugriffe (TM06.02) Secret Verwaltung (TM09.02) Verschlüsselung Backup (TM09.03) Kubernetes Backup
Begründung	Widerstandsfähige Wiederherstellungspläne mitigieren das Risiko des Verlustes oder des Diebstahls von Backup. Das ausgearbeitete Backup Konzept stellt einen gesicherten Zugriff auf die verschlüsselten Backup dar.
Restrisiko	gering

6.4. Zusammenfassung der Risikoanalyse

–TBD–

7. Modellierung der Sicherheitsmaßnahmen

Dieses Kapitel beschreibt die Modellierung der Sicherheitsmaßnahmen für openDesk als SaaS-Lösung. Dabei erfolgt die Identifikation geeigneter Sicherheitsanforderungen und die Umsetzung entsprechender Maßnahmen für den Informationsverbund durch die Auswahl passender Bausteine aus dem IT-Grundschutz-Kompendium, siehe hierzu die separate Datei “20250307_InitialerArbeitsstand_openDesk_Checklisten_IT-Grundschutz_v0.01.pdf” [TBD].

7.1. Organisatorische Sicherheitsmaßnahmen

In diesem Kapitel werden die organisatorischen Maßnahmen beschrieben, welches für openDesk als SaaS definiert, umgesetzt und gepflegt werden. Hinweis: Hier genannte Tools sind keine Empfehlungen, sondern stellen lediglich vergleichbare Produkte dar.

(OM01.01) Einhaltung Sicherheitskonzept:
Die Umsetzung und der Betrieb der openDesk als SaaS-Lösung entspricht vollständig dem definierten Sicherheitskonzept, welches auf Basis der Anforderungen durch den BSI IT-Grundschutz angefertigt wurde. Dies wird regelmäßig, aber mindestens jährlich, überprüft und der Prüfungsbericht wird zentral auf Open Code abgelegt.

(OM02.01) Integration in BCM/ITSCM:
Die openDesk als SaaS ist in die Prozesse und Planungen des Business Continuity Management (BCM) und IT Service Continuity Management (ITSCM) integriert. Unter Berücksichtigung der verschiedenen Systeme, Dienste und Anwendungen, welche in der Umgebung eingesetzt werden. Es werden in der gesamten Umgebung Redundanzen und Cluster-Technologien benutzt. Des Weiteren besteht eine Unabhängigkeit hinsichtlich des Cloud Service Providers (CSP) und weiteren Technologie-Vendoren. So ist ein direkter Umzug der Umgebung auf einen anderen Hyperscaler jederzeit möglich, was dazu führt, dass die Umgebung zeitnah wiederhergestellt werden kann.

(OM02.02) Prüfung Business Continuity Prozesse:
Es werden regelmäßige, mindestens jährliche, technische Prüfung der Business Continuity Prozesse durchgeführt. Die Testergebnisse werden dokumentiert und analysiert, um nachhaltig kontinuierliche Verbesserungen und Anpassungen vornehmen zu können.

(OM03.01) Ressourcenplanung:
Die Ressourcen für openDesk als SaaS-Lösung sind ausreichend dimensioniert, passend ausgewählt und individuell anpassbar. Hierfür erfolgt in regelmäßigen Abständen, aber mindestens monatlich, eine Überprüfung der Ressourcen und der erwartete Ressourcenbedarf und -wachstum.

(OM03.02) Kapazitätsplanung:
Die Verfügbarkeit, Qualität und ausreichende Kapazität von openDesk als SaaS sind geplant, vorbereitet und gemessen, um die erforderliche Verfügbarkeit zu erbringen. Zudem werden regelmäßige Prognosen über den künftigen Kapazitätsbedarf erstellt, um das Risiko einer Systemüberlastung zu verringern. Hierzu ist ein entsprechendes, angemessenes und End-to-End Monitoring etabliert, welches über vordefinierte Tresholds verfügt.

(OM03.03) Asset Management:
Alle bereitgestellten Systeme und Dienste werden vollständig im Asset Management erfasst. Hierfür wird ein zentrales Tool verwendet. Die Vollständigkeit und Genauigkeit der Liste wird regelmäßig, aber mindestens monatlich, überprüft. Notwendige Änderungen müssen direkt durchgeführt werden und intern kommuniziert werden.

(OM03.04) Einsatz zertifizierter Umgebungen, Plattformen und Diensten:
Die openDesk als SaaS verwendet und nutzt ausschließlich zertifizierte oder testierte Infrastrukturen und Plattformen, welche gemäß des BSI IT-Grundschutz, Cloud Computing Compliance Criteria Catalogue (C5) und weiteren gängigen oder äquivalenten Standards geprüft und/oder konform sind.

(OM03.05) Open-Source:
openDesk setzt vollständig auf Open-Source Komponenten. Dies führt zu einer großen Transparenz über alle Bestandteile und die Architektur von openDesk. Da der Quellcode von Open-Source Software offen zugänglich ist, kann dieser durch jeden überprüft und auditiert werden. Dies sorgt dafür, dass Sicherheitsprobleme schneller erkannt, offen kommuniziert und Verbesserungen und Fehlerbehebungen schnell und transparent umgesetzt werden können. Durch den Einsatz offener Standards wird zudem ein Vendor Lock-In vermieden, da einzelne Komponenten der Lösung austauschbar sind, ggf. durch sogenannte “Drop-In-Replacements”, d.h. dass eine Softwarekomponente 1:1 durch eine andere ersetzt werden kann, da z.B. die API-Schnittstelle exakt identisch ist.

(OM04.01) Bestimmung von Nutzungsbedingungen:
Nutzungsbedingungen für openDesk als SaaS sind definiert und den Benutzern frei zugänglich. Nur Benutzer, welche diese Bedingungen akzeptieren, erhalten einen Zugriff auf die Umgebung.

(OM05.01) Ticketsystem:
Zur Dokumentation, Priorisierung und effizientes Zeitmanagement von Vorfällen und Rückfragen ist ein Ticketsystem etabliert. Zudem werden Best Practices wie ITIL (Information Technology Infrastructure Library) angewendet, um die Servicequalität einzuhalten und Reaktionszeiten zu optimieren.

(OM06.01) Datensicherung:
Zur Sicherstellung der Datensicherung von der openDesk-Umgebung und dessen Dienste ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft. Alle relevanten Daten werden regelmäßig gesichert und können im Falle eines Datenverlusts wiederhergestellt werden.

Um die Datenwiederherstellung sicherzustellen und Ausfallzeiten im Falle eines Datenverlusts zu minimieren, enthält das Dokument feste Vorgaben zu der Backup-Methode, den ausführenden Intervallen und festen Termine der Wiederherstellungstest.

Hierzu liegt ein gesamtheitliches Backup-Konzept vor, welches alle Bestandteile von openDesk als SaaS betrachtet.

(OM06.02) Zuverlässigkeit von Backups durch regelmäßige Prüfung:
Die Zuverlässigkeit der Backups wird durch regelmäßige Prüfungen der Backup-Funktionalität, z. B. in einer gleichwertigen Testumgebung, sichergestellt. Die Prüfungen werden dokumentiert und analysiert. Im Nachgang werden mögliche Schwachstellen identifiziert und behoben.

(OM06.03) Sicherung von Produktionsdaten:
Die Sicherung von Produktionsdaten werden entsprechend den festgelegten Backup Prozessen durchgeführt. Eine Replizierung von gesicherten Produktionsdaten auf einen anderen Backup-Speicher ist nicht gestattet und Bedarf einer separaten Freigabe. Produktionsdaten dürfen nicht in nicht-produktiven Umgebungen verwendet oder eingespielt werden.

(OM06.04) Physisch getrennte Backup-Speichermedien:
Damit das Risiko zur gleichzeitigen Gefährdung von System- und Backup-Daten mitigiert werden kann, sind die Backup-Speichermedien vom CSP physisch getrennt von den zentralen Komponenten platziert. Die Backup-Speichermedien werden hierzu zudem an einem separaten Standort aufbewahrt. Zusätzlich schützt die Nutzung mehrerer physisch getrennter Backup-Standorte zur weiteren Risikominimierung.

(OM06.05) Backup unter Berücksichtigung geeigneter Sicherheitsmaßnahmen:
Backups und die zugehörige Umgebung sind durch umfassende Sicherheitsmaßnahmen wie Sicherung der Zugriffe durch Benutzer und einem adäquatem Rechte- und Rollenkonzept gesichert. Es ist eine Mandantenfähigkeit des Backup-Sicherungstools und des Backup-Speichers sichergestellt.

(OM06.06) Datenverschlüsselung als Schutzmaßnahme für Backups:
Die Sicherheit und Vertraulichkeit der Daten wird durch die Verschlüsselung sämtlicher Daten-Backups gewährleistet. Diese Maßnahme dient der Risikominderung und ist unabhängig von der physischen Sicherheit der Backups. Die Verschlüsselung erfolgt nach aktuellen Sicherheitsstandards des BSI und wird regelmäßig, mindestens jährlich, überprüft und aktualisiert.

(OM06.07) Absicherung der Wiederherstellbarkeit von Backups:
Backups werden in einem standardisierten Format gesichert, so dass die Daten zuverlässig wiederhergestellt werden können und keine Abhängigkeiten zu einem Datensicherungssoftware Vendoren besteht. Die Überprüfung der Backup-Daten erfolgt sowohl auf physischer als auch auf logischer Ebene. Die Sicherungen erfolgen nach festgelegten Verfahren, die regelmäßige Tests der Wiederherstellbarkeit beinhalten, um die Integrität und Funktionalität der Daten zu gewährleisten. Durchgeführte Tests werden dokumentiert und analysiert, um die Wiederherstellungsprozesse stetig zu verbessern.

(OM06.08) Widerstandsfähigkeit durch strukturierte Wiederherstellungspläne:
Für die Wiederherstellung von openDesk werden strikt definierten Wiederanlauf- und Notfallpläne befolgt. Diese beinhalten die Wiederherstellung von Backups, um die Anwendung auf den Zustand vor dem Vorfall zurückzusetzen und die Betriebsfähigkeit sowie die Datenintegrität zu gewährleisten. Die Wiederherstellungspläne sind definiert und dokumentiert, um im Ernstfall eine schnelle und effiziente Wiederherstellung zu ermöglichen. Die Pläne werden regelmäßig getestet und aktualisiert, sodass sie den aktuellen Anforderungen und Best Practices entsprechen.

(OM07.01) Rollen- und Berechtigungskonzept:
Gemäß Least-Privilege-Prinzip sind jegliche Rollen und deren Berechtigungen auf minimal notwendige Rechte von Benutzenden und Administratoren beschränkt. Hierzu werden nur Rechte vergeben, welche zum Erfüllen der entsprechenden Aufgaben notwendig sind.

(OM07.02) Dokumentation von Rollen und Verantwortlichkeiten:
Rollen und Verantwortlichkeiten von Dienstleistern, Mitarbeitenden und sonstigen Dritten, die Administratoren sind, werden in Bezug auf Informationsbestände und Sicherheit dokumentiert und an einer zentralen Stelle abgelegt.

(OM07.03) Bewusstsein für Rollen und Verantwortlichkeiten:
Jegliche mitwirkende Dienstleister, Mitarbeitende und sonstigen Dritte, die Administratoren sind, müssen über ihre Rollen und Verantwortlichkeiten bewusst sein und unterrichtet werden. Dies führt zu einer Gewährleistung von sicheren und geschützten Arbeitsumgebung und zum Erhalt des Bewusstseins und der Einhaltung der bestehenden Richtlinien und Verfahren, sowie der geltenden gesetzlichen und regulatorischen Compliance-Verpflichtungen.

(OM07.04) Richtlinien zur Identitäts-, Berechtigungs- und Zugriffsverwaltung:
Es sind Richtlinien und Verfahren für den Benutzerzugriff festgelegt und unterstützende Geschäftsprozesse und technische Maßnahmen umgesetzt. Diese stellen sicher, dass alle internen Benutzer, Dienstleister und Kunden mit Zugriff auf Systeme, Dienste und Daten über eine angemessene Verwaltung von Identitäten, Berechtigungen und Zugriffen verfügen. Folgende Richtlinien, Verfahren, Prozesse und Maßnahmen stellen dies sicher:

Verfahren, Rollen und Verantwortlichkeiten für die Provisionierung und De-Provisionierung von Benutzerkonten und dessen Berechtigungen. Dies erfolgt nach dem Least-Privilege-Prinzip.
Segmentierung von Sitzungen und Daten in mandantenfähigen Architekturen durch Dritte (z.B. Dienstleister).
Identity Trust Verifikation sowie die Interoperabilität von Service-to-Service-Anwendungen (APIs) und Informationsverarbeitungssystemen, wie z.B. Single Sign-On (SSO) und Föderation.
Von der Erstellung bis zum Widerruf das Account Credential Lifecycle Management
Wiederverwendung von Zugangsdaten und/oder Identitätsspeichern oder die Minimierung derer.
Regeln für Authentifizierung, Autorisierung und Abrechnung (AAA) für den Zugriff auf Daten und Sitzungen, einschließlich u.a. Verschlüsselung und multi-Faktor-Authentifizierung
Berechtigungen und Unterstützungsfunktionen zur Kontrolle der Authentifizierungs-, Autorisierungs- und Abrechnungsregeln (AAA) durch Dienstleister für den Zugriff auf Daten und Sitzungen.
Erfüllung der anwendbaren gesetzlichen und regulatorischen Compliance-Vorgaben.

(OM07.05) Segregation von Tätigkeiten:
Richtlinien und Verfahren für den Benutzerzugriff sind festgelegt. Diese implizieren Geschäftsprozesse und technische Maßnahmen zur Begrenzung des Benutzerzugriffs, gemäß der festgelegten Aufgabenverteilung, um Geschäftsrisiken im Zusammenhang mit Interessenkonflikten zwischen Benutzenden und ihrer Rollen zu mitigieren.

(OM07.06) Provisionierung von Benutzern:
Die Provisionierung von Benutzern sind durch standardisierte Prozesse definiert. Benutzerkonten werden bei Beginn des Arbeitsverhältnisses ordnungsgemäß erstellt und mit den entsprechenden Berechtigungen versehen. Ein Onboarding-Prozess für neue Benutzer ist für eine sicherheitstechnische einwandfreie Ausführung der geforderten Tätigkeiten etabliert.

(OM07.07) De-Provisionierung von Benutzern:
Die De-Provisionierung von Benutzern ist durch standardisierte Prozesse definiert. Benutzerkonten sind bei Beendigung des Arbeitsverhältnisses oder bei einem Tätigkeits- bzw. Rollenwechsel umgehend und ordnungsgemäß deaktiviert und werden gemäß den Anforderungen auch entfernt.

(OM07.08) Kontenverwaltung:
Persönliche Konten werden über einen zentralen Identity Provider verwaltet. Nicht personenbezogene Konten, wie z.B. “root”, werden mittels Privileged Access Management (PAM) auf persönliche Konten abgebildet.

(OM07.09) Benutzerdokumentation:
Es wird eine Dokumentation über autorisierte Benutzer und dessen Rechte geführt, welche regelmäßig, aber mindestens monatlich, überprüft wird.

(OM07.10) Benutzertrennung:
Zur effizienten Trennung von Benutzern ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

(OM08.01) Hintergrundüberprüfung:
Mitarbeitende, Dienstleister und weitere Dritte unterliegen einer Hintergrundüberprüfung. Diese entspricht den lokalen Gesetzen, Vorschriften, Ethikrichtlinien und vertraglichen Beschränkungen. Entsprechend der Überprüfung muss eine verhältnismäßige Einordnung zur erforderlichen Datenklassifikation, den Geschäftsanforderungen und dem akzeptablen Risiko erfolgen.

(OM08.02) Vergabe von Zugriffsrechten:
Zur Vergabe von Zugriffsrechten ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

(OM08.03) Standardisierter Abstimmungsprozess von Zugriffsrechten:
Zur Abstimmung von Zugriffsrechten ist ein Standardabstimmungsprozess definiert, dokumentiert, genehmigt und wird regelmäßig, aber mindestens monatlich, überprüft.

(OM09.01) Beendigung und Änderung von Beschäftigungsverhältnissen:
Die Zuweisung, Kommunikation und die Fortführung der bestehenden Dokumentation von Rollen und Verantwortlichkeiten bei der Beendigung oder Änderung von Arbeitsverhältnissen ist elementar und zu gewährleisten. Hierzu ist ein entsprechender Joiner - Mover - Leaver Prozess etabliert.

(OM09.02) Aktivitätenerfassung abstimmen:
Alle Maßnahmen und Prozesse zur Erfassung der Aktivitäten von Personen erfolgen in Abstimmung gemäß der internen Unternehmensrichtlinien. Hierdurch kann nachvollzogen werden, welche Änderungen am System vorgenommen wurden. Die Aktivitätenerfassung erfolgt gemäß der Datenschutzbestimmung.

(OM09.03) Speicherung und Löschung von Benutzerdaten:
Zur Speicherung und sicheren Löschung von Benutzerdaten ist ein Prozess definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft.

(OM09.04) Speicherung und Zugriff auf Identitäten:
Richtlinien und Verfahren werden für die Regelung der Speicherung und des Zugriffs auf Benutzeridentitäten definiert. Der Zugriff ist ausschließlich auf Benutzer zu beschränken, die ausdrücklich als geschäftlich erforderlich definiert sind. Methoden wie rollenbasierte Zugriffskontrolle (RBAC), dem Least-Privilege-Prinzip, regelmäßige Überprüfung der Zugriffsrechte und die Implementierung von Multi-Faktor-Authentifizierung (MFA) werden eingesetzt.

(OM10.01) Passwortsicherheit:
Bei der Verwendung von Passwörtern, werden nach den internen Sicherheitsrichtlinien erstellt und gesichert. Diese sind nach den geltenden Standards erstellt, z.B. BSI IT Grundschutz oder Center for Internet Security (CIS). Es dürfen keine Anmeldedaten oder Passwörter in Klartext gespeichert oder weitergegeben werden. Jeder Benutzer verwendet hierzu eine Passwort-Manager-Software (z.B. Keepass) zur Verwaltung aller Informationen ihrer Accounts.

(OM11.01) Outsourcing:
Outsourcing erfolgt durch einen definierten und überwachten Prozess. Hierbei wird sichergestellt, dass alle externen Dienstleister und ähnliche Parteien gemäß dem BSI den festgelegten Sicherheitsrichtlinien und -anforderungen entsprechen. Der Prozess wird für jeden externen Dienstleister und ähnliche Parteien dokumentiert und zentral abgelegt.

(OM11.02) Autorisierung von Dienstleistern:
Dienstleister und ähnlichen Partner müssen autorisiert sein. Erst danach erhalten diese, gemäß der Verhältnismäßigkeit, Zugriff zu benötigten Informationen.

(OM11.03) Einhaltungen von vertraglichen Vereinbarungen:
Drittanbieter sind verpflichtet, die Einhaltung der in den Verträgen festgelegten Vereinbarungen zu Informationssicherheit, Vertraulichkeit, Service-Definitionen und Lieferstufen bei Bedarf nachzuweisen. Berichte, Aufzeichnungen und Dienstleistungen von Drittanbietern müssen regelmäßig, aber mindestens einmal jährlich, überprüft werden.

(OM11.04) Service Level Agreements mit Dienstleister:
Service Level Agreements (SLAs) sind mit jedem Dienstleister anhand unternehmensinterner Richtlinien unter Berücksichtigung bestehender Prozesse und Anforderungen zu definieren und auszuarbeiten.

(OM11.05) Beendigung von Dienstleistungsverhältnissen:
Die Beendigung von Dienstleistungsverhältnissen mit Kunden, Dienstleistern und ähnlichen Parteien sind durch einen standardisierten Prozess definiert, dokumentiert, genehmigt und werden regelmäßig, aber mindestens jährlich, überprüft. Umgebungen, Zugriffsrechte werden gemäß Vereinbarungen entzogen. Eine Übertragung der vertraulichen gespeicherten Daten sind abzustimmen oder vorher individuell zu sichern.

(OM12.01) Staging Umgebung: Die openDesk als SaaS Lösung wird mindestens in Produktion und Nicht-Produktion getrennt (2-stufiges Staging). Dies erfordert mindestens zwei separate und autarke openDesk als SaaS Umgebungen.

(OM13.01) Änderungsdokumentation: Dokumentationen von Änderungen von Umgebung und dessen Komponenten sind definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens monatlich, überprüft. Patches, Updates und Upgrades werden gemäß eines Staging Prozesses (mindestens zweistufig) getestet, überprüft und dokumentiert.

(OM13.02) Regelmäßige Dokumenten und Richtlinien Überprüfung:
Dokumentationen, Handbücher und Richtlinien werden regelmäßig, aber mindestens jährlich, überprüft, um die kontinuierliche Sicherheit der openDesk als SaaS zu gewährleisten.

(OM13.03) Schulung des Betriebs und der Administration:
Für den sicheren Betrieb und die Administration der Umgebung und der Systeme erhalten alle Mitarbeitenden eine entsprechend auf die Aufgabe zugeschnittene Schulung. Die Schulung enthält alle relevanten Themen, die den sicheren Betrieb und die Administration der Umgebung gewährleisten. Dies muss u.a. eine Sicherheitsunterweisung umfassen, sowie der Umgang mit der Umgebung, seiner Systeme sowie die Technologie dahinter und aufzeigen der notwendigen Dokumentationen und Handbücher.

(OM14.01) Kommunikation von Sicherheitsmaßnahmen:
Die Kommunikation von Sicherheitsmaßnahmen ist regelmäßig und systematisch. Alle Mitarbeitende, Dienstleister und weitere Dritte werden über aktuelle Sicherheitsrichtlinien und -verfahren informiert. Dies umfasst Schulungen, regelmäßige Updates und die Bereitstellung von leicht zugänglichen Informationsressourcen.

(OM14.02) Schwachstellenmanagement:
Richtlinien und Verfahren für die Erkennung von Schwachstellen sind definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens jährlich, überprüft.

(OM14.03) Erkennung von Schwachstellen:
Für eine frühzeitige Erkennung von Schwachstellen sind technische Maßnahmen und unterstützende Prozesse mit dem Schwachstellenmanagement auszuarbeiten. Hierbei sind zudem false-positive Fälle zu berücksichtigen, da auch diese die Verfügbarkeit und Sicherheit der Umgebung und ihre Dienste verringert.

(OM14.04) Vorfallmanagement:
Nach der Identifizierung eines Sicherheitsvorfalls müssen die zuständigen Mitarbeitenden die Ursache analysieren und betroffene System isolieren. Es sind passende Maßnahmen zur Behebung auszuwählen und diese gemäß den internen Richtlinien des Unternehmens zu genehmigen. Dabei ist es essenziell bereits während der Analyse einen Schwerpunkt zwischen Eindämmung des Schadens oder einer detaillierten Ursachenforschung und Untersuchung zu setzen. Ein standardisierter Prozess zur Nachbereitung ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft. Dieser Prozess beinhaltet hierbei entsprechende Rollen und auch Kommunikationswege und -reihenfolgen.

(OM15.01) Bestimmung der Akzeptanzniveaus:
Jegliche Risiken sind auf ein vertretbares Niveau begrenzt. Die auf Risikokriterien basierenden Akzeptanzniveaus sind festgelegt und dokumentiert. Hierzu stimmen diese mit den angemessenen Lösungszeiträumen und der Zustimmung der Interessengruppen überein.

(OM15.02) Risikobewertungen:
Risikobewertungen im Zusammenhang mit den Anforderungen an die Datenverwaltung sind wie folgt durchzuführen:

Eine Sensibilisierung für den Speicherort von sensiblen Daten und ihren Übertragungsweg.
Die Komponenten, Datenbanken, Container und Kubernetes-Infrastrukturen.
Gewährleistung der Einhaltung von definierten Aufbewahrungsfristen und Entsorgungsvorschriften am Ende der Nutzungsdauer.
Klassifizierung von Daten und Schutzmaßnahmen gegen unbefugte Nutzung, unbefugten Zugriff, Datenverlust, Datenzerstörung und Datenverfälschung. Die Durchführung und/oder Prüfung der Risikobewertung hat mindestens einmal pro Jahr zu erfolgen.

(OM15.03) Informationen zu Sicherheitsproblemen:
Informationen zu Sicherheitsproblemen werden im Rahmen der etablierten Prozesse entsprechend den Vorgaben, z.B. des BSI und ENISA, eingeholt und überprüft.

(OM15.04) Verstoß gegen Sicherheitsrichtlinien:
Eine formelle Disziplinar- oder Sanktionsrichtlinie für Mitarbeitende, die gegen Sicherheitsrichtlinien und -verfahren verstoßen, ist implementiert. Mitarbeitende werden im Vorfeld über die möglichen Konsequenzen eines Verstoßes informiert. Die Richtlinien legen die Disziplinarmaßnahmen eindeutig fest und werden den Mitarbeitenden bekannt gemacht, z.B. im OnBoarding Prozess.

(OM15.05) Alarmierung sicherheitsrelevanter Ereignisse:
Ein Prozess zur Alarmierung bei sicherheitsrelevanten Ereignissen in der Umgebung, sowie derer Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft. Im Falle eines sicherheitsrelevanten Ereignisses werden alle betroffenen internen Mitarbeitenden und externen Dritten sofort benachrichtigt. Es ist gemäß den internen Unternehmensrichtlinien zu prüfen, ob ähnliche Parteien wie Datenschutzbeauftragte, Rechtsabteilung usw. mit einzubeziehen sind. Ein Einhalten der Meldepflichten gegenüber Behörden und ähnlichen Parteien ist essenziell.

(OM15.06) Statuskommunikation:
Alle Administratoren, Benutzende und weitere Drittparteien sind über Störungen, Notfälle, Krisen, geplante Updates und den allgemeinen Status der IaaS- und PaaS-Services regelmäßig zu informieren. Hierzu ist ein Kommunikationsplan inkl. der technischen Umsetzung definiert, dokumentiert und wird regelmäßig überprüft.

(OM15.07) Forensische Untersuchungen:
Forensische Verfahren, einschließlich der Beweismittelkette (Chain of Custody), müssen strikt eingehalten werden, um nach einem Vorfall Beweise zu sammeln, die den Anforderungen der jeweiligen Gerichtsbarkeit entsprechen. Betroffene Benutzer und externe Partner sollen die Möglichkeit erhalten, an diesen Untersuchungen teilzunehmen, soweit dies gesetzlich zulässig ist.

(OM16.01) Log-Dateien Überprüfung:
Ein Prozess zur Prüfung aller Log-Dateien der Umgebung, sowie derer Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig automatisiert überprüft.

(OM16.02) Protokollierungsprozess:
Ein Prozess der Protokollierung und der Analyse der Umgebung, sowie derer Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens monatlich, überprüft.

(OM16.03) Audit-Tools:
Zugriffe und die Nutzung von Audit-Tools müssen segmentiert und eingeschränkt werden. Dies soll den Missbrauch von Protokolldaten vermeiden.

(OM16.04) Audit-Protokolle:
Audit-Protokolle müssen unter höheren Sicherheitsstandards geschützt, aufbewahrt und verwaltet werden und haben die gesetzlichen und regulatorischen Compliance-Verpflichtungen einzuhalten. Die Audit-Protokolle haben einer dedizierten Verantwortung von Benutzern zu stehen. Außerdem müssen diese bei einer forensischen Untersuchung unterstützen. Deshalb sind u.a. Kennzahlen wie Performance, Kapazitätsplanung und False-Positive Analysen festzuhalten.

(OM16.05) Wirkungsanalyse Service-Ausfall:
Die Wirkungsanalyse muss für alle Komponenten, Dienste und weitere Services durchgeführt werden. Dadurch sind frühzeitig Risiken erkennbar, um mögliche Wirkungen zu minieren und Reputationsschäden einzudämmen.

(OM17.01) Bereitstellung von Diensten:
Die Bereitstellung von Diensten in der Umgebung sind für die Provisionierung und De-Provisionierung klar definiert, dokumentiert, genehmigt und werden regelmäßig, mindestens jährlich, überprüft.

(OM17.02) Änderung und Aktualisierung von Diensten:
Ein Prozess für die Änderung oder Aktualisierung aller Dienste ist definiert, dokumentiert, genehmigt und wird regelmäßig überprüft. Eine Verwaltung der Umgebung und dessen Dienste durch Managementsysteme muss nach dem 4-Augen-Prinzip erfolgen.

(OM17.03) Dienstdokumentation:
Die Dokumentation der bereitgestellten Dienste in der Umgebung ist gemäß den Anforderungen, die Automatisierungsplanung, die Eingabevalidierung, die Authentifizierung und Verschlüsselung, die Rollen und Rechte, die Überwachung und Protokollierung sowie die Sicherheitseinstellungen erstellt.

(OM17.04) Portabilität von Diensten gewährleisten:
Ein Prozess für die Übertragbarkeit von Diensten und Daten auf eine andere Umgebung ist definiert, dokumentiert, genehmigt und wird regelmäßig, mindestens jährlich, überprüft.

(OM17.05) Migration von Anwendungen:
Migrationen von Anwendungen müssen werden vorab einer Bewertung unterzogen. Migrationen müssen adäquat vorbereitet und geplant werden. Geltende Sicherheitsmaßnahmen werden in die Migrationsstrategie integriert, um Daten und Systeme zu schützen. Relevante Stakeholder werden frühzeitig eingebunden, um die die Migration reibungslos zu gewährleisten.

(OM18.01) Image-Provenance (Container):
Ein Aspekt zum sicheren Betrieb ist die Image-Provenance. Sie umfasst die Verwendung als auch die Verteilung sicherer Container-Images aus vertrauenswürdigen Quellen, wie es auch durch BSI IT-Grundschutz SYS.1.6.A6 und BSI IT-Grundschutz SYS.1.6.A12 gefordert ist. Konkret bedeutet dies, dass bei der Erstellung der Container und der Helm-Charts zur Bereitstellung von openDesk nicht blind öffentlichen Container-Images und Helm-Charts vertraut wurde, sondern dass diese entweder selbst erstellt worden sind oder ausführlich geprüft wurden, um sicherzustellen, dass nur das wirklich Notwendigste enthalten ist. Gerade mit Bezug auf die Verwendung von Containern, egal ob zur Nutzung als Basis-Container oder zur Umsetzung gewisser Fähigkeiten, sei darauf hingewiesen, dass auch minimale Container-Images aus nicht-vertrauenswürdigen Quellen stammen können und somit ein Sicherheitsrisiko darstellen.

Bei der Erstellung von openDesk wurden nur Container-Images und Softwarekomponenten aus als vertrauenswürdig klassifizierten Quellen verwendet oder eigenständig implementiert. Die Bereitstellung für den produktiven Betrieb geschieht im Rahmen von SaaS über eine Plattform-interne Container-Registry als vertrauenswürdige Quelle. Mit Blick auf die Implementierung selbst wurden anerkannte Standards zur Implementierung sicherer Software umgesetzt. Alle Schritte und Prozesse sind entsprechend dokumentiert.

Die Container-Images von openDesk sind mit entsprechenden Metadaten versehen, um die Funktion und die Historie des Container-Images bei Bedarf nachvollziehen zu können. Darüber hinaus gewährleisten digitale Signaturen, dass die Container-Images unverändert, die im Kubernetes-Cluster der Plattform zum Betrieb von openDesk als SaaS verwendet werden, unverändert sind und dem “Auslieferungszustand” von openDesk in der jeweiligen Version entsprechen. Nur Container, die eine valide Signatur aufweisen, werden zum Betrieb von openDesk als SaaS verwendet. Dadurch kann sichergestellt werden, dass zwischen Bereitstellung der Container und Nutzung der Container kein Angreifer schadhaften Code einschleusen kann.

Wie durch BSI IT-Grundschutz SYS.1.6.A13 gefordert, durchlaufen alle Container-Images und damit openDesk als Software für den produktiven Betrieb einen Test- und Freigabeprozess gemäß des Bausteins BSI IT-Grundschutz OPS.1.1.6. Nur Container, welche diesen Prozess erfolgreich durchlaufen haben, erhalten eine entsprechende Signatur, sodass diese als Nachweis für die durchgeführte Qualitätskontrolle dient.

(OM18.02) Regelmäßige Updates (Container):
Veraltete Software kann Sicherheitslücken enthalten, die es einem Angreifer ermöglichen, die Software zu kompromittieren, Daten zu stehlen oder zu manipulieren, oder im “besten” Fall lediglich die Verfügbarkeit der Anwendung zu stören. Daher ist die regelmäßige Aktualisierung unerlässlich. Für den Fall der Nutzung von openDesk als SaaS bedeutet dies ganz konkret, dass der Hersteller von openDesk regelmäßig, aber im Notfall auch außerordentliche Aktualisierungen von openDesk bereitstellt. Für den Betrieb in einer Container-Plattform bedeutet dies, dass aktualisierte Container der Komponenten von openDesk erzeugt und bereitgestellt werden. Hierbei werden zwei Ebene betrachtet, welche auf dem aktuellen Stand gehalten werden müssen: zum einen openDesk selbst, d.h. die Pakete und Abhängigkeiten, welche zur Erstellung der jeweiligen openDesk Komponente selbst notwendig sind, aber auch das Basis-Betriebssystems des Containers, d.h. das Basis-Image, auf welchem die openDesk Komponenten aufsetzten. Um hier den Überblick zu behalten, wird zu jedem Container mit jedem neuen Release eine sogenannte Software Bill of Materials (SBOM) erzeugt. BSI IT-Grundschutz SYS.1.6.A14 sieht hierzu ein Konzept für das Patch- und Änderungsmanagement gemäß BSI IT-Grundschutz OPS.1.1.3 vor, welches erstellt worden ist und welches genau beschreibt, wann und wie die Updates der Container-Images der Komponenten von openDesk ausgerollt werden. Aber auch die Container-Umgebung selbst muss regelmäßig überprüft und aktualisiert werden. Dies liegt jedoch in der Verantwortung des Hyperscalers der Container-Umgebung.

(OM18.03) Überwachung und kontinuierliche Sicherheitsscans (Container):
Gemäß der Redewendung “Vertrauen ist gut, Kontrolle ist besser” werden umfassende Überwachungs- und Auditierungssysteme auf Plattformebene durch den Hyperscaler genutzt, um die Komponenten von openDesk während des Betriebs hinsichtlich Verfügbarkeit und Performanz, aber auch mit Blick auf ungewöhnliche Aktivitäten, Engpässe und auch der Einhaltung der Richtlinien und der Härtungsmaßnahmen hinsichtlich Industriestandards zu überwachen. Die regelmäßige Prüfung auf Schadsoftware sowie bekannte Schwachstellen oder Hintertüren gehört selbstverständlich dazu. Alle Schritte wurden vollständig dokumentiert und auditierbar aufbereitet. Regelmäßige Sicherheitsscans und Schwachstellenprüfungen, sowohl auf Quellcode als auch auf Container-Ebene, werden vollständig automatisiert durchgeführt und die Ergebnisse überwacht, ausgewertet und die notwendigen Anpassungen abgeleitet und umgesetzt. Dies umfasst eine Überprüfung auf bekannte Schwachstellen, sogenannte CVE-Scans, also auch die Überprüfung des Quellcodes mittels statischer Code-Analyse sowie die dynamische Code-Analyse bis hin zu Penetrationstests von openDesk.

(OM18.04) Sichere Entwicklung und sichere Deployments (Container):
Nicht nur während des Betriebs, sondern auch bei der Entwicklung der openDesk-Komponenten und der Erstellung der Container ist auf die Einhaltung der Richtlinien zur Härtung, der Überprüfung hinsichtlich Schwachstellen und der Absicherung der Software Supply Chain geachtet worden. Das bedeutet, dass unter anderem die openDesk Komponenten ohne erweiterte Rechte auskommen, dass sie nicht erst vor der Auslieferung, sondern regelmäßig auf Schwachstellen überprüft werden und dass die Abhängigkeiten zu anderen Paketen und Bibliotheken sorgfältig ausgewählt worden sind, um eine robuste Entwicklungsbasis zu schaffen. Aber auch die Manifeste und Helm Charts für das Deployment der openDesk Komponenten kann Schwachstellen enthalten. Meist handelt es sich hier um die unbeabsichtigte Preisgabe von sensitiven Informationen (z.B. hart-kodierte Zugangsdaten, statt wie durch BSI IT-Grundschutz SYS.1.6.A8 gefordert ein externes Schlüsselmanagement-System und/oder Kubernetes Secrets einzusetzen, um diese Informationen besonders geschützt und außerhalb des Container Images zu speichern und zu verwalten sowie nur berechtigten Personen Zugriff zu erlauben). Aber auch der Betrieb von openDesk an sich kann beeinträchtigt werden, wenn z.B. durch fehlende Healthchecks der Zustand der Container zur Laufzeit nicht überprüft werden kann und somit die regulierenden und korrigierenden Mechanismen von Kubernetes nicht zum Einsatz kommen (können), um die Aufrechterhaltung des Betriebs zu unterstützen.

Bei der Entwicklung und dem Betrieb einer Software wird nach höchsten Sicherheitsmaßnahmen gearbeitet und die eingesetzte Software auf das Wesentliche reduziert. Die Kompilierung der Software erfolgt entweder außerhalb des eigentlichen Erstellungsprozesses der Container oder die Container werden via Multi-Stage-Build erstellt, d.h. in einem oder mehreren Schritten werden in Containern die Artefakte, also die Komponenten von openDesk, kompiliert und dann als letzten Schritt in den finalen, minimalen Container kopiert. Dadurch sind nur die wirklich notwendigen Artefakte und keine zusätzliche und unnötige Software im finalen Container enthalten, sondern nur die eigentliche openDesk Komponente und der zur Laufzeit benötigte Abhängigkeiten.

Ohne angemessene Sicherheitsmaßnahmen können Schwachstellen im Quellcode selbst oder in der Konfiguration der Container ausgenutzt werden, die zu Datenverlust, Ausfallzeiten oder Sicherheitsverletzungen führen. Ungehärtete Container oder openDesk selbst stellen dann ein leichtes Angriffsziel dar. Damit Sicherheit nicht erst zuletzt während der Entwicklung betrachtet und “nachgerüstet” wird, sondern von Beginn an essenzieller Bestandteil der Entwicklung ist, werden in einem kontinuierlichen DevSecOps-Prozess alle Bestandteile von openDesk automatisiert gegen die Policies und Best-Practices geprüft und gehärtet, um potenzielle Angriffsvektoren zu minimieren. Folgende Maßnahmen sind im Rahmen von openDesk für eine zuverlässige und strukturierte Entwicklung inkl. Tests umgesetzt worden:

Die Basis-Images werden mindestens monatlich aktualisiert, sodass die aktuellen Sicherheitsupdates eingespielt werden.
Es wird auf die Verwendung des Tags latest verzichtet, sondern mit konkreten Tags, also Versionen der Container Images gearbeitet, da latest veränderlich ist und damit keine stabile Basis gewährleistet werden kann. Ein Image, was gestern erzeugt wurde und den Tag latest bekam, kann heute ein ganz anderes Image sein, aber trotzdem latest heißen. Dadurch ist im Nachhinein völlig unklar, was genau alles im Image mit dem Tag latest enthalten war und was nicht.
Überprüfung der Deployment-Manifeste, der Helm Charts und der Dockerfiles auf problematische Konfigurationen und, sofern die Prüfung fehlerhafte Konfigurationen zu Tage fördert, Abbruch des Erstellungsprozesses der openDesk Komponente. Eine fehlerhafte Konfiguration kann trotz fehlerfreien Quellcodes neue, bisher unbekannte Angriffsvektoren ermöglichen. Gemäß BSI IT-Grundschutz SYS.1.6.A8 beinhalten diese Überprüfungen, ob eventuell Zugangsdaten oder andere sensitiven und vertrauenswürdigen Informationen wie “Passwörter jeglicher Accounts, API-Keys für von der Anwendung genutzte Dienste, Schlüssel für symmetrische Verschlüsselungen sowie private Schlüssel bei Public-Key-Authentisierung” in den Container Images, dem Quellcode oder den Manifesten und Helm Charts enthalten sind.
Erstellung einer Software Bill of Material (SBOM) zur Sicherstellung der Supply Chain, zur Lizenzprüfung der verwendeten Abhängigkeiten und als Vorstufe zur Prüfung auf bekannte Schwachstellen (CVEs).
Durchführung der CVE-Prüfung und, sofern diese zu viele oder zu schwere Abhängigkeiten aufweist, Abbruch des Erstellungsprozesses der openDesk Komponente.
Durchführung der statischen Code-Analyse und, sofern diese Prüfung Auffälligkeiten oder Schwächen aufweist, Abbruch des Erstellungsprozesses der openDesk Komponente.
Durchführung der Härtungsmaßnahmen vor den fachlichen Test, damit diese nicht gegen eine nachträglich veränderte Basis und Konfiguration durchgeführt werden.
Durchführung der fachlichen Tests und sogenannter Unit-Test (keine QA-Tests) zur Überprüfung, ob sich die openDesk Komponente nach allen Härtungsmaßnahmen noch immer gemäß den Spezifikationen verhält.
Durchführung von Penetrationstests inkl. Dokumentierung der Ergebnisse
Sofern alle Überprüfungen erfolgreich bestanden werden, werden das entsprechende Container Image als auch die für das Deployment notwendigen Manifeste oder Helm Charts automatisiert signiert und in der vertrauenswürdigen Container Registry für die Produktivumgebung freigegeben.

7.2. Technische Sicherheitsmaßnahmen

In diesem Kapitel werden die technischen Maßnahmen (TM) beschrieben, welche durch openDesk als SaaS Lösung bereitgestellt und implementiert sind. Hinweis: Hier genannte Tools sind keine Empfehlungen, sondern stellen lediglich vergleichbare Produkte dar.

(TM01.01) Ressourcen Management:
Das Ressourcenmanagement erfolgt durch eine Kombination aus automatisierten und manuellen Prozessen. Hierzu werden Methoden wie die kontinuierliche Überwachung und Analyse der Ressourcennutzung genutzt, um Engpässe frühzeitig zu erkennen und zu beheben. Prinzipien wie die Least Privilege Policy werden angewendet, um sicherzustellen, dass nur autorisierte Benutzer Zugriff auf kritische Ressourcen haben. Zudem werden regelmäßige Audits durchgeführt, um die Einhaltung der Sicherheitsrichtlinien zu überprüfen und potenzielle Schwachstellen zu identifizieren. Die Nutzung von Cloud-basierten Lösungen ermöglicht eine flexible Skalierung der Ressourcen, um den aktuellen Anforderungen gerecht zu werden.

(TM01.02) Patch Management:
Der technische Prozess zur zeitnahen Installation von sicherheitsrelevanten Patches und Updates für alle Komponenten und Dienste wird nach den internen Unternehmensrichtlinien unverzüglich eingeleitet. Dies umfasst infrastrukturell auch Firewalls, Netzwerkkomponenten, Serverbetriebssysteme und Plattform-Softwaremodule. Update-Freigaben müssen genehmigt werden und sind nur aus sicheren Quellen zu verwenden.

Die Umgebung und die zugehörigen Services werden gesamtheitlich in das bestehende Patch-Management integriert, sodass alle Komponenten regelmäßig aktualisiert und sicherheitsrelevante Patches zeitnah installiert werden.

Alle Softwarepakete und Containerdateien dürfen ausschließlich aus geprüften sicheren und vertrauenswürdigen Quellen installiert werden. Eine entsprechende Freigabe der Quelle wird dazu zentral dokumentiert und den beteiligten Personen bereitgestellt. Alle Installationen werden außerdem regelmäßig auf ihre Herkunft und Integrität überprüft.

(TM01.03) Quotas, Request & Limits (Kubernetes):
Quotas, Requests und Limits werden für alle Dienste und Workloads in den Kubernetes-Clustern festgelegt. Diese Maßnahmen setzen klare Grenzen für die Nutzung von CPU und Speicher. Es unterstützt die Cluster und deren Workloads effizient zu verwalten und bei Problemen neu zu starten. Quotas werden zudem für eine kontrollierte Ressourcennutzung pro Namespace festgelegt.

(TM02.01) Charakteristiken der IaaS- und PaaS-Services:
Die Umgebung IaaS- und PaaS-Services weisen folgende Charakteristiken auf:

Die Bereitstellung von Ressourcen wie Rechenleistung, Speicher und Netzwerken erfolgt automatisiert und mit minimaler Interaktion. Alle genutzten Systeme und Services können hierfür über eine API angesteuert werden. Zudem erfolgt die Verwendung von Self-Service-Portalen, um Abhängigkeiten zum CSP so gering wie möglich zu halten.
Services müssen über Standardschnittstellen wie HTTPS verfügbar sein und von verschiedenen Clients genutzt werden können.
Die Bereitstellung von Diensten und Anwendung hat hochgradig automatisiert zu erfolgen.

(TM03.01) Härtung:
Eingesetzten Betriebssysteme, Container und Plattformen sind mindestens nachdem internationalen Standard des CIS-Benchmarks Level 1 oder einem vergleichbaren Standard gehärtet. Dies gilt für alle Systeme, welche innerhalb von openDesk betrieben werden, als auch für Systeme, welche für die Bereitstellung von openDesk genutzt werden. u.a. betrifft dies Compute Nodes, Kubernetes Cluster, Third-Party Supporting Dienste, wie OpenCode, ArgoCD und HashiCorp Vault.

(TM03.02) Härtung (Kubernetes):
Die Control Plane Nodes, die die Managementkomponenten des Clusters wie API-Server, Controller Manager, Scheduler und ETCD hosten, müssen mindestens gemäß den BSI-Standards gehärtet werden, optimalerweise nach internationalen Standards wie CIS. Dies umfasst die Implementierung dedizierter Nutzerzugriffe, wie beispielsweise ein dedizierter Nutzer für ETCD und ein root Benutzer für die verbleibenden Komponenten, um sicherzustellen, dass Änderungen am Cluster nur auf Knotenebene vorgenommen werden können.

Die Worker Nodes sind unerwünschten Konfigurationsänderungen zu schützen. Dies kann beispielsweise durch die Vergabe dedizierter Berechtigungen und die Änderung der Eigentümerschaft der jeweiligen Konfigurations- und Zertifikatsdateien erfolgen, sodass nur der root-Benutzer diese ändern kann.

Um die Kubelet-Komponente in Kubernetes zu härten, muss sie vor Man-in-the-Middle-Angriffen, kompromittierten oder veralteten Zertifikaten und Fehlkonfigurationen geschützt werden. Der betriebene Kubelet ist vor unbefugtem und anonymem Zugriff sowie unbefugten Änderungen über seine API geschützt. Kommunikationskanäle und Schnittstellen werden eingeschränkt, Zertifikatsabläufe verhindert und kryptografische Verschlüsselungen eingesetzt.

Die Kommunikation muss zu anderen Cluster-Komponenten mittels TLS-Verschlüsselung gesichert werden, um Man-in-the-Middle-Angriffe zu verhindern und eine abhörsichere Kommunikation zu gewährleisten. Anonymer, unautorisierter und unsicherer Zugriff muss deaktiviert werden. Role-Based Access Control (RBAC) muss aktiviert sein, um den Zugriff auf den Cluster zu beschränken und zu sichern.

Es müssen Kommunikationskanäle und Schnittstellen eingeschränkt sowie TLS-Verschlüsselung implementiert sein. Es muss eine Trennung der Service Benutzer auf Controller-Ebene implementiert und eine regelmäßige Zertifikatsrotation durchgeführt werden.

Der Scheduler muss sicherstellen, dass neu erstellte Workloads auf die zweckdienlichsten Nodes verteilt werden. Es müssen Kommunikationskanäle und Schnittstellen eingeschränkt werden, um unbefugten, anonymen und unkontrollierten Zugriff zu verhindern.

Es ist eine dediziert Zertifizierungsstelle (CA) für ETCD (verteilter Key-Value-Store) zu verwenden. TLS muss genutzt werden und die Nutzung von Zertifikaten, die von dieser CA ausgestellt wurden, erzwungen werden. Die gespeicherten Daten sind zu verschlüsseln.

(TM03.03) Common Vulnerabilities und Exposures (CVE):
Es werden regelmäßig alle Systeme und Services auf bekannte CVE-Schwachstellen geprüft und gegebenenfalls werden geeignete Maßnahmen ergriffen, um diese Schwachstellen zu beseitigen. Darüber hinaus werden Kunden proaktiv über die gefundene Schwachstelle und deren Behebung informiert. Entsprechende Schwachstellen-Scanner sind in der CI/CD Pipeline integriert, z.B. über das Tool trivy, um eine automatisierte Überprüfung zu gewährleisten.

Sicherheitspatches für CVEs mit einem Score von 8 und größer werden direkt in die produktive Umgebung eingespielt, um das Risiko von Sicherheitsvorfällen zu minimieren. Sicherheitspatches für CVEs unter 8 werden zuerst in den entsprechenden Test-Stage eingespielt und dort gemäß des definierten Patch Management verprobt.

(TM04.01) Zentrales Logging und Monitoring:
Alle Systeme und Services der openDesk als SaaS Umgebung sind an das zentrale Logging & Monitoring der Umgebung angebunden, um ein End-to-End Monitoring gewährleisten zu können. Sollte ein System oder Service nicht an das zentrale Logging & Monitoring angebunden sein, dann ist dieses umgehend aus dem Informationsverbund zu entfernen.

(TM04.02) Auswertung der Ereignisprotokollierung:
Automatisierte Überwachungstools, wie z.B. ein Security Information and Event Management (SIEM) System, IDS und IPS-Komponenten, werden zur regelmäßigen Überprüfung der Logging und Monitoring-Dateien der Dienste und Systeme eingesetzt, um sicherheitsrelevante Ereignisse frühzeitig zu erkennen. Angepasste Kenngrößen werden entsprechend der Anforderung eingesetzt. Sicherheitsrelevante Ereignisse werden anonym protokolliert und überprüft. Die verantwortlichen Personen werden benachrichtigt, um potenzielle Bedrohungen frühzeitig zu erkennen und zu verhindern.

(TM04.03) Logging, Monitoring & Auditing (Kubernetes):
Alle Cluster, Cluster-Dienste und openDesk selbst werden an das zentrale Monitoring- und Logging-System angebunden. Das Audit Logging innerhalb von Kubernetes ist aktiviert. Außerdem müssen regelmäßige Audits von openDesk, des Clusters und der Cluster-Dienste durch Schwachstellen- und Policy-Scanner, wie z.B. Trivy, durchgeführt werden, um die Workload und den Cluster hinsichtlich der Einhaltung der Vorgaben durch den BSI IT-Grundschutz zu überwachen (u.a. Compliance mit CIS Kubernetes Benchmark) und transparent zu machen und im zentralen Monitoring und Logging zugänglich zu machen.

(TM04.04) Löschung von Protokolldaten:
Es wird sichergestellt, dass Administratoren, die Protokollierungsfunktionen ausführen, nicht berechtigt sind, die aufgezeichneten Daten zu ändern oder zu löschen, um die Authentizität und Zuverlässigkeit der Protokollierung zu gewährleisten. Hierfür ist ein rollenbasiertes Zugriffskontrollkonzept implementiert, welches bei dem der Zugriff auf die aufgezeichneten Daten separat gesteuert werden kann.

(TM04.05) Ausführliche Protokollierung zur Sicherung der Archive:
Eine ausführliche Protokollierung der Zugriffe auf elektronische Archive ist zu implementieren. Unter anderem sind mindestens Parameter wie Datum, Uhrzeit, Benutzer, Client, ausgeführte Aktionen und Fehlermeldungen zu erfassen.

(TM04.06) Whitelisting:
Gemäß Whitelisting werden Infrastruktur, Services und Dienste durch sogenannte Sicherheitsgruppen und klar definierte Sicherheitsrichtlinien geschützt. Das konfigurierte Whitelisting ist regelmäßig zu überprüfen und in den entsprechenden Betriebshandbüchern zu dokumentieren und zu aktualisieren.

(TM05.01) Mandanten-Trennung und Multi-Mandantenfähigkeit:
Verwendete und eingesetzte Systeme, Plattformen und Dienste verfügen über eine Multi-Mandantenfähigkeit. Datenzugriffe erfolgen nur durch die jeweilige Komponente, welche auch einen Zugriff auf diese benötigt.

Die technische Separierung von Kunden, welchen denselben Kubernetes Cluster nutzen, erfolgt über die Verwendung von Namespaces. Die Funktionalitäten des Namespaces stellen hierbei sicher, dass die Ressourcen jedes Kunden logisch isoliert und dass keine unbefugten Zugriffe zwischen den Kundenumgebungen erfolgen kann. Hierfür werden unter anderem StorageClasses mit namespace-spezifischen Attributen genutzt, um jede Anwendung und/oder jeden Dienst logisch voneinander zu trennen.

Falls eine Separierung der Kunden nicht über Namespaces erfolgen kann oder darf, wird hierfür ein separater Kubernetes Cluster bereitgestellt. Dies führt auch dazu, dass alle Third-Parties Dienste separat bereitgestellt werden, um Abhängigkeiten zwischen verschieden Kubernetes-Clustern zu vermeiden.

(TM05.02) Authentifizierung & Autorisierung:
Sämtliche Services verfügen über einen Autorisierungs- und Authentifizierungsmechanismus, wobei die Authentifizierung immer am zentralen Verzeichnisdienst erfolgt und die Autorisierung immer direkt im jeweiligen System. Hierzu verfügt jeder Dienst zusätzlich über gängige Authentifizierung- und Authentifizierungsfunktionalitäten, wie beispielsweise Multi-Faktor-Authentifizierung (MFA), Single Sign On (SSO) und die Nutzung von rollenbasierten Zugriffskontrollen (RBAC). Dadurch erfolgt die Umsetzung einer feingranularen Rechtestruktur. Zusätzlich ist der direkte Zugriff auf den Cluster auf die Administratoren und das Automatisierungs- und CI/CD-System beschränkt. Hierzu wird durchgehend das “Least-Privilege” Prinzip angewendet. Änderungen an den RBAC-Regeln dürfen nur durch den verantwortlichen Kubernetes-Betrieb vorgenommen werden.

Für den Zugriff auf die Kubernetes Cluster sind granulare Zugriffskontrollen implementiert, um den Zugriff basierend auf Benutzerrollen zu steuern. Die Umsetzung dieser erfolgt am definierten Rollen- und Rechtekonzept.

(TM05.03) Benutzerauthentifizierung:
Die Umgebung, Dienste und Anwendungen müssen eine grundlegende Benutzerauthentifizierung (1-Faktor) implementiert haben, während privilegierte Benutzer eine 2-Faktoren-Authentifizierung (MFA) erfordern. Es sind nur Benutzer gemäß “Least-privilege principle” zu erstellen, die für den Betrieb und die Verwaltung erforderlich sind. Der Zugriff auf die Umgebungen muss ausschließlich über das SSH-Protokoll erfolgen, wobei personalisierte, passwortgeschützte SSH-Schlüssel für jeden Benutzer verwendet werden, um eine eindeutige Zuordnung und zusätzliche Sicherheit zu gewährleisten. Es ist zu empfehlen, dass der Zugriff auf eine PAW (Privileged Access Workstations) über ein Privileged Access Management (PAM) erfolgt. Die Benutzer sind zentral im Identitätsmanagementsystem zu verwalten.

Der Zugriff auf Protokolldateien soll dem “need to know”-Prinzip folgen und ein rollenbasiertes Zugriffskontrollkonzept (RBAC) implementiert werden.

(TM05.04) Protokollierung der Zugriffe:
Alle Zugriffs- und Änderungsaktivitäten werden über die Audit-Logs protokolliert. Administrative Zugriffe auf kritische Systeme sind zudem visuell aufzuzeichnen und verschlüsselt zu sichern.

(TM05.05) User, Rollen und Rechte (Kubernetes):
Die definierten Rollen, Rechte und die User werden nur dediziert im Cluster verwendet. Zudem werden keine Berechtigungen auf Knotenebene erhalten oder sogar außerhalb des Clusters genutzt.

(TM05.06) Automations-User und personalisierte User (Kubernetes):
Plattform-Administratoren erhalten einen Service User zur Administration der Umgebung, welcher die Möglichkeit besitzt mit dem Cluster zu kommunizieren. Dieser User ist nicht für tägliche Operationen zu verwenden und bedarf immer einer 4-Augen Überprüfung oder Freigabe. Die Anmeldeinformationen ist auf ein Minimum an vertrauenswürdigen Administratoren zu beschränken.

Zur Nutzung von Tools zur Verwaltung des Quellcodes (OpenCode) sowie die Nutzung einer CI/CD-Pipeline (z.B. Tekton o.ä.) benötigt einen nicht-menschlichen Service User zur Automatisierung administrativ-ähnliche Zugriffsrechte gemäß Least-Privilege Prinzip auf die Cluster.

Menschliche Benutzer müssen sich mit personalisierten Anmeldeinformationen authentifizieren. Dies ermöglicht die Prüfung von Interaktionen mit Clustern oder Konfigurationsänderungen. Ein Zugriff durch anonymisiert User, nicht authentifizierter oder nachgeahmter Zugriff auf die Cluster ist strikt untersagt. Ein interner Identity Provider (z.B. Keycloak) muss verwendet werden, um menschliche Benutzer zu verwalten und ihnen individuelle, Cluster-interne Servicekonten zuzuweisen, die an spezifische Rollen gebunden sind.

(TM06.01) Verwendung von Benutzerdaten:
Alle Benutzerdaten werden anonymisiert oder pseudonymisiert, bevor diese in der nicht-produktiven Umgebungen verwendet werden. Die Verwendung von Benutzerdaten im produktionsfreien Umfeld entspricht strikt den Anforderungen des Datenschutzes.

Es sind Sicherheitsmaßnahmen implementiert, wie die Verschlüsselung von Daten sowohl im Ruhezustand (Encryption at Rest) als auch während der Übertragung (Encryption in Transit), als auch die Implementierung dedizierter Zugriffe, damit Benutzerdaten ausreichend geschützt sind.

(TM06.02) Secret Verwaltung:
Für die Speicherung von Secrets, wie z.B. Zugangsdaten und Zertifikaten, wird ein Secret Manager eingesetzt. Die Richtlinien und Verfahren für die kryptografische Schlüsselverwaltung entsprechend den zentralen Vorgaben des BSI und es werden ausschließlich kryptografische Methoden genutzt, welche als sicher gelten und gemäß den geltenden Standards zugelassen und empfohlen sind. Darunter fällt die “Technischen Richtlinien (TR) - Kryptografische Verfahren: Empfehlungen und Schlüssellängen” des BSI, welche auf den NIST Spezifikationen basiert. Diese Spezifikationen werden regelmäßig, mindestens jährlich, überprüft. Die eingesetzten kryptografischen Methoden und die damit verbundenen Prozesse sind in den Konzepten des verwendeten Systems zu dokumentieren.

Für die zentrale Verwaltung von autorisierten Benutzern mit Zugriff auf Anwendungen und Dienste muss einen Security Token Service Provider, z.B. Keycloak, verwendet werden.

(TM06.03) Kubernetes Secret Management:
Secrets im Bereich Kubernetes werden als Dateien und nicht als Umgebungsvariablen konsumiert, soweit möglich. Zudem müssen Secrets vor dem Commit in das Versionskontrollsystem mit SOPS (Secrets OPerationS) verschlüsselt und die Verschlüsselung von ETCD aktiviert werden.

(TM07.01) Hochverfügbarkeit:
Jegliche Systeme und Services, welche für die Bereitstellung und den Betrieb von openDesk als SaaS genutzt werden, werden hochverfügbar bereitgestellt. Dies erfolgt präferiert durch die Nutzung von Active-Active Funktionalitäten. Bei der Verwendung von Active-Passiv Funktionalitäten ist zu gewährleisten, dass eine minimale Ausfallzeit während des Failover Prozesses erfolgt. Zudem erfolgt jeder Failover Prozess automatisiert und Bedarf keiner manuellen Eingriffe.

(TM07.02) Kubernetes Resilienz:
Der Kubernetes Cluster, wie er durch den Hyperscaler als PaaS bereitgestellt wird, wird hochverfügbar und redundant betrieben. Hierfür werden für jeden Kubernetes Cluster mindestens 3 Control und ETCD Nodes betrieben und mindestens 2 Worker Node pro Cluster. Jegliche Cluster-Dienste verwenden zudem geeignete Readiness- und Liveness-Probes, sodass die jeweiligen Dienste bei einem Ausfall automatisch neu starten. Diese Konfiguration stellt sicher, dass der Ausfall einer Maschine die Gesamtfunktionalität und Leistung des Clusters nicht beeinträchtigt.

(TM07.03) Replikation von Daten:
Jede StorageClass wird mit mindestens einem Replikationsfaktor von drei verwendet. Diese sind analog über mindestens drei verschiedene Nodes des jeweiligen Clusters zu verteilen. Durch Vorgaben von Aversionen (Anti-Affinity-Rule) wird verhindert, dass alle Replikate auf demselben Node gespeichert werden.

(TM07.04) Cluster: Data-at-Rest Verschlüsselung (Kubernetes):
Die Verschlüsselung Data-at-Rest erfolgt auf mehreren Ebenen. Die Dateisysteme der zugrunde liegenden Knoten, die Cluster-Datenbank (ETCD) und dynamisch bereitgestellten Volumes durch Block-Storage-System für Kubernetes wie Longhorn usw., die den Pods der Dienste und Workloads zugeordnet sind, werden verschlüsselt. Dies erfolgt Namespace übergreifend.

(TM08.01) Generelle Netzwerksicherheit:
Die Netzwerksicherheit und die Sicherheit bei der Datenübertragung werden durch umfassende Verschlüsselungsmaßnahmen gewährleistet. Für die interne und externe Kommunikation kommen ausschließlich sichere und durch das BSI geprüfte Übertragungsprotokolle wie SSH und TLS (Transport Layer Security) ab Version 1.3 zum Einsatz. Dies stellt sicher, dass alle Informationen, insbesondere sensible Daten, verschlüsselt werden, um die Datensicherheit zu erhöhen und vor unbefugtem Zugriff und Abhörversuchen zu schützen.

Zusätzlich werden Backend-Systeme und Anwendungen durch verschlüsselte Verbindungen wie TLS und VPNs (Virtual Private Networks) gesichert. Anwendungen innerhalb der Plattform verfügen durchgehend über sichere Kommunikationsprotokolle wie SSL/TLS und sind nur über diese zugänglich.

(TM08.02) Verschlüsselung des Kubernetes Netzwerks innerhalb der Cluster:
In jedem Kubernetes-Clustern wird ein Service-Mesh, z.B. umgesetzt durch Linkerd, Istio oder Consul, implementiert, um mutual TLS (mTLS) für alle Kommunikationen innerhalb der Cluster zu ermöglichen und abhörsichere Kommunikation zu gewährleisten. Hierzu ist jedes Service-Mesh mit dem internen Cluster-Dienst namens cert-manager verbunden, der als zentrale Stelle für die Konfiguration, Ausstellung und Widerruf von Zertifikaten fungiert. Der cert-manager arbeitet zusammen mit dem trust-manager, der zur Verwaltung von Zertifizierungsstellen in den Clustern verwendet wird, und automatisiert effektiv die administrative Interaktion in Bezug auf die allgemeine Zertifikatsverwaltung sowie die spezifische Handhabung von mTLS-Verbindungen, Ingress-Routen usw.

(TM08.03) Netzwerk Segmentierung:
Die gesamte Umgebung verfügt über entsprechende Netzwerk Segmentierungen, sodass für verschiedene Aufgaben auch verschiedene Netzwerke genutzt werden. Eine stateful Firewall wird verwendet, um die gesamte Kommunikation zwischen diesen Segmenten zu kontrollieren, zu überwachen und freizugeben. Dies stellt sicher, dass nur autorisierter und notwendiger Datenverkehr zugelassen wird, was die Sicherheit und Integrität des gesamten Netzwerks erhöht.

Zusätzlich werden die Kubernetes Control Planes mehrerer Cluster mit individuellen Managementnetzwerken verbunden. Der Zugriff auf die Dienste und Workloads erfolgt dafür über eigene, dedizierte Netzwerke. Hierfür werden spezifische Netzwerke für dediziert Aufgaben verwendet.

(TM08.04) Netzwerk: Dokumentation, Betrieb und Sicherstellung:
Die gesamte Umgebung verfügt über eine umfassende Dokumentation für die gesamte Netzwerkumgebung. Diese Dokumentation enthält eine detaillierte Netzwerktopologie, Konfigurationen und Verbindungen innerhalb der Umgebung, um Klarheit über die Netzwerkstruktur zu gewährleisten und eine effiziente Verwaltung und Sicherheitsüberwachung zu ermöglichen. Zur Absicherung des öffentlichen Der Betrieb des gesamten Netzwerkes erfolgt vollständig automatisiert und zentralisiert. Jegliche Netzwerkkonfigurationen werden in dem zentralen Versionskontrollsystem hinterlegt. Internetverkehrs muss die Infrastruktur durch ein Application Layer Gateway (ALG) geschützt werden.

Für die openDesk als SaaS Lösung wird Infrastructure as a Service (IaaS) des Hyperscalers genutzt. Dieser Dienst des Hyperscalers unterliegt den Sicherheitsanforderungen der openDesk als SaaS Lösung und wird regelmäßig, mindestens jährlich, hinsichtlich der Einhaltung der Vorgaben geprüft.

(TM08.05) Dienst- und Anwendungstrennung:
Für die Dienste- und Anwendungstrennung, sowie für die Mikrosegmentierung, werden Network Policies konfiguriert, sodass eine strikte Trennung der Netzwerke zwischen den Namespaces eingehalten wird. Diese Policies enthalten eine “deny all”-Regel, welche jegliche externe und inter-namespace Kommunikation verbietet und dadurch eine Isolation der Workloads und Dienste bis auf Pod-Ebene erfolgt. Nur die unbedingt erforderlichen Kommunikationswege dürfen mittels einer “Allow List” zugelassen werden (White Listing). Jegliche Änderungen an den Network Policies dürfen ausschließlich von den dedizierten verantwortlichen Administratoren vorgenommen werden.

(TM09.01) Tests von Backup und Wiederherstellung:
Es werden regelmäßige, mindestens jährliche, Tests von Backup und Wiederherstellungsprozessen durchgeführt, dokumentiert und auf Angemessenheit geprüft. Dies geschieht sowohl für einzelne Dienste als auch für die gesamte Umgebung. Diese Prüfung wird hierfür in einer zur Produktionsumgebung äquivalenten Umgebung geprüft.

(TM09.02) Verschlüsselung Backup:
Alle Backups werden verschlüsselt auf den Backup System abgelegt, wobei das entsprechende Verschlüsselungsprotokoll mindestens dem aktuellen BSI-Standard entspricht. Dies wird regelmäßig, mindestens jährlich, geprüft.

(TM09.03) Kubernetes Backup:
Backups der persistenten Volumes werden regelmäßig und automatisiert auf einer S3-kompatible Speicherlösung gesichert. Die Konfigurationsoptionen der Kubernetes-Cluster und der installierten Addons werden im internen Versionskontrollsystem gespeichert und durch dieses gesichert. Zusätzlich werden ETCD-Snapshots regelmäßig gesichert und wiederhergestellt. Die Backup- und Wiederherstellungsfunktionen von den jeweiligen Services sind anhand des zentralen Backup Konzeptes auszugestalten. Alle genannten Backup-Quellen werden regelmäßig und automatisch gemäß einem geeigneten Backup-Schema gesichert.

(TM10.01) Regelmäßige Penetrationstests:
Die Umgebung und die Dienste werden regelmäßig, mindestens jährlich, durch Penetrationstests überprüft. Hierfür werden sowohl automatisierte als auch manuelle Penetrationstests durchgeführt, um potenzielle Schwachstellen zu identifizieren und um diese anschließend beheben zu können.

(TM10.02) Isolierung bei APT-Vorfällen:
Im Falle eines APT-Vorfalls (Advanced Persistent Threat) sind die betroffenen Netzwerkabschnitte sofort und vollständig zu isolieren, um die Ausbreitung der Bedrohung zu stoppen. Dies umfasst insbesondere die Trennung vom externen und öffentlichen Netzwerk, um den restlichen Teil des Netzwerks zu schützen.

(TM10.03) Unverzügliche Passwortänderung nach Sicherheitsvorfällen:
Nach einem Sicherheitsvorfall müssen alle Zugangsdaten unverzüglich geändert werden.

(TM10.04) Sicherheitsbedingte Neuinstallation der Systeme:
Die von einem Sicherheitsvorfall betroffenen Systeme müssen einer umfassenden Neuinstallation unterzogen werden. Um wiederkehrende Sicherheitsverletzungen und kontinuierlichen Datenverlust zu verhindern, sind diese Maßnahmen für den kontinuierlichen, sicheren Betrieb essenziell. Zudem müssen Backups vorab in einer Sandbox Umgebung ausreichend geprüft und freigegeben werden, bevor diese wieder in den produktiven Betrieb hinzugefügt werden können.

(TM11.01) Härtung der Anwendungscontainer (Container):
Zur Härtung von Containern ist die Minimierung der Angriffsfläche zwingend erforderlich, um Kompromittierung, Datenverluste oder Datenmanipulationen zu vermeiden. Durch die Minimierung der Angriffsfläche wird die Hürde, die ein Angreifer nehmen muss, hoch gesetzt, sodass ein erfolgreicher Angriff unwahrscheinlicher wird. Die Angriffsfläche setzt sich aus mehreren internen und externen Faktoren auf verschiedenen Ebenen zusammen. Im Vergleich zu einer virtuellen Maschine können Container eine wesentlich geringere Angriffsfläche haben, indem man folgende Regeln beachtet:

Nur ein Dienst pro Container: In jedem Container von openDesk wird stets nur ein Dienst von openDesk bereitgestellt. Dies ist so auch gemäß BSI IT-Grundschutz SYS.1.6.A11 gefordert. Ein Dienst kann im Kontext von openDesk eine Software wie Nextcloud, eine Datenbank wie PostgreSQL oder auch nur ein Teil eines größeren Verbundes sein, z.B. Software, die aus Microservices besteht. Wenngleich es technisch möglich wäre, mehrere Dienste mit einem Container abzubilden, ist hierauf verzichtet worden, um die Prozessisolierung (ein Container stellt auf Betriebssystemebene einen Prozess dar) zu gewährleisten. Außerdem begünstigt die Ein-Prozess-pro-Container-Politik die Umsetzung der nachfolgenden Maßnahme: minimale Basis-Images.
Verwendung minimaler Basis-Images und Entfernung unnötiger Komponenten: Die Idee hinter dieser Best-Practice ist denkbar einfach. Große Basis-Images, wie z.B. ein vollwertiges Ubuntu oder Debian, etc. enthalten eine Vielzahl an vorinstallierten Software-Komponenten, Pakete und Bibliotheken, welche für den Betrieb der eigentlichen openDesk-Software-Komponente nicht benötigt werden. Jede Software, ob aktiv genutzt oder nicht, kann Sicherheitslücken und generell einen möglichen Angriffsvektor bieten. Daher gilt: je weniger in einem Container steckt, desto besser. Daher basieren die Container von openDesk auf sogenannten minimalen Basis-Images, d.h. Images, welche nur die minimal notwendigen Pakete und Bibliotheken enthalten, damit die entsprechende openDesk-Komponente lauffähig ist. Des Weiteren wurde bei der Erstellung der Container darauf geachtet, dass keine Pakete, Bibliotheken oder andere Komponenten, die nur zum Kompilieren, aber nicht zur Laufzeit benötigt werden, im finalen Container der openDesk-Komponente enthalten sind. Durch beide Maßnahmen werden die Container-Images die auszuführende Anwendung reduziert und somit die Angriffsfläche signifikant verkleinert.
Anstreben von Distroless-Container: Klassische Container enthalten stets Abhängigkeiten, Pakete und Bibliotheken einer konkreten Linux-Distribution, z.B. Ubuntu oder Debian, etc. Die maximale Reduzierung auf das wesentliche besteht darin, all diese Betriebssystem-spezifischen “Altlasten” loszuwerden und so die Angriffsfläche noch weiter zu reduzieren, indem wirklich nur die Bibliotheken und Pakete im Container vorhanden sind, die zur Laufzeit des Prozesses der openDesk-Komponente erforderlich sind und alle anderen Abhängigkeiten an ein (im Container bereitgestelltes, klassisches) Betriebssystem entfallen. Daher auch der Name “Distroless”, also ein Container “ohne Distribution”. Hier zeigt sich auch der Hauptunterschied zwischen Containern und virtuellen Maschinen: virtuelle Maschinen müssen immer auf einem Betriebssystem basieren, Container müssen dies nicht. openDesk basiert aktuell jedoch noch nicht auf Distroless-Containern.

(TM11.02) Sichere Konfiguration (Container):
Container können auf zwei Arten konfiguriert werden: zum Zeitpunkt ihrer Erstellung oder beim Deployment durch sogenannte Configmaps oder Umgebungsvariablen. In beiden Fällen können fehlerhafte Konfigurationen dazu führen, dass die in Containern betriebene Software, hier openDesk, kompromittiert wird und dass Daten manipuliert oder gelöscht werden. Die Durchsetzung der folgenden Maßnahmen ist mindestens durch organisatorische Maßnahmen auf Seiten des Hyperscalers der Container-Plattform, idealerweise aber automatisiert durch ein Policy-System ebenfalls durch den Hyperscaler technisch umgesetzt.

Ausführung von Containern ohne Privilegien: Wie gemäß BSI IT-Grundschutz SYS.1.6.A17 gefordert, benötigen die Komponenten von openDesk keine erweiterten Rechte, im folgenden Root-Rechte genannt. Ausgestattet mit solchen Rechten und Privilegien kann ein Container auch auf dem darunterliegenden Host Root-Rechte erlangen, was einem Angreifer im Falle einer Kompromittierung einen umfassenden Zugriff auf die Systeme auch außerhalb des Containers ermöglicht, z.B. Nachinstallation von Software, Einschleusen von Schadcode oder Deaktivierung von Sicherheitsmechanismen - nicht nur im Container, sondern auch direkt auf dem Host-System. Um dies ausschließen zu können, verzichten alle Container von openDesk, sofern nicht zwingend erforderlich, auf den Einsatz des Root Users (Nutzer-ID 0) innerhalb der Container. Auf der Container-Ebene, also auf Ebene der durch den Hyperscaler bereitgestellten PaaS-Plattform, ist durch eben diesen sicherzustellen, dass die verwendeten Non-Root User, also die Nutzer mit einer ID größer als 0, nicht auf Nutzer auf dem Host abgebildet werden, welche erweiterte Rechte erlangen könnten. Ausnahmen, für welche der Einsatz von Root-Rechten oder die sogenannten Privilege Escalation, auch Rechteausweitung genannt, unumgänglich ist, sind angemessen dokumentiert. Hierbei ist auch darauf geachtet worden, dass erweiterte Rechte nicht pauschal vergeben worden sind, sondern gemäß der innerhalb von Kubernetes zur Verfügung stehenden Mitteln beim Deployment von openDesk die jeweils erforderlichen Privilegien auf das absolute Minimum begrenzt wurden. Ebenfalls auf der Ebene der Container-Plattform ist sicherzustellen, dass die Container-Runtime als auch die instanziierten Container von einem System-Account des darunterliegenden Betriebssystems ausgeführt werden, welcher nicht direkt über erweiterte Rechte verfügt und dem es auch nicht möglich ist, erweiterte Rechte indirekt über sogenannte Rechteausweitung zu erhalten. Auch ist durch den Hyperscaler sicherzustellen, dass die Container-Runtime z.B. durch die Verwendung der Virtualisierungs-Erweiterungen von CPUs gekapselt werden. Die vom Hyperscaler durchgeführten Maßnahmen sind dokumentiert und attestiert.
Zugriffe auf das Host-System: Gemäß BSI IT-Grundschutz SYS.1.6.A18 und BSI IT-Grundschutz SYS.1.6.A19 sind die Zugriffe auf das Host-System zu begrenzen. Dies umfasst neben den Nutzern innerhalb des Containers, welche über keine Root-Rechte verfügen dürfen, auch direkte Zugriff auf Dateien und Ordner außerhalb des jeweiligen Containers auf dem Host-System. Alle im Kontext von openDesk verwendeten Container verzichten auf den direkten Zugriff auf die darunterliegenden Host-Systeme. Sofern aus betrieblichen Gründen doch Zugriffe oder Berechtigungen notwendig sein sollten, sind die hierfür notwendigen System-Accounts dem darunterliegenden Host bekannt und entsprechend aussagekräftig dokumentiert. Persistenter Massenspeicher, auf welche die Komponenten von openDesk zur Sicherung von Daten angewiesen sind, wird von einem persistenten Speichersystem bezogen, d.h. die einzelnen Anwendungen haben keinen direkten Zugriff auf den Massenspeicher des Host-Systems oder auf befindlichen Verzeichnissen auf dem Host-System selbst. Entsprechende Berechtigungen bzw. Zugriffsbeschränkungen sind auf dem persistenten Speichersystem durch den Hyperscaler gesetzt. Die vom Hyperscaler durchgeführten Maßnahmen sind dokumentiert und attestiert.
Isolation der einzelnen Komponenten von openDesk: Beim Deployment von openDesk sind die durch die Container-Plattform gegebenen Isolationsmechanismen genutzt worden, d.h. einzelne Komponenten von openDesk sind in logischen Einheiten gruppiert und prozess-seitig über sogenannte Namespaces sowie netzwerk-seitig über sogenannte Network Policies (vergleichbar mit einer software-basierten Firewall) separiert worden. Zugriffe von einem Namespace auf den anderen sind nicht pauschal möglich, sondern nur vorab fest definierte Zugriffe über fest definierte Ports und fest definierte Services sind möglich. Die Anzahl der freigegebenen Ports ist auf das Minimum reduziert worden. Darüber hinaus gehende Netzwerkzugriffe wurden beim Deployment verboten.
Beschränkung der nutzbaren Ressourcen pro Container bzw. openDesk Komponenten: Im Kontext von Kubernetes, der zugrundeliegenden Container-Plattform der SaaS-Variante von openDesk, wurden wie durch BSI IT-Grundschutz SYS.1.6.A15 gefordert die den Containern zur Verfügung stehenden Ressourcen reserviert, aber auch eingeschränkt. Besonders letzteres ist zwar gemäß aktueller Best-Practices mindestens umstritten, jedoch überwiegen die mit dieser Vorgabe einhergehenden Vorteile. Auf der einen Seite kann man argumentieren, dass die nach oben unbeschränkte Ressourcennutzung innerhalb eines Namespaces, welcher trotzdem mit einer Quota und damit einer oberen Grenze für CPU, Arbeitsspeicher, Massenspeicher, etc. für alle in ihm befindlichen Komponenten versehen ist, mehr Spielraum bei der Ressourcennutzung und damit eine tendenziell bessere Ressourcenauslastung bietet. Dagegen spricht jedoch, dass ohne Limitierung einzelne Container einer Anwendungskomponente im Fehler- oder Angriffsfall zu viele Ressourcen beanspruchen können, was zur Einschränkung der Verfügbarkeit oder gar dem Ausfall der entsprechenden Komponenten führt. Die Limitierung sorgt dafür, dass Kubernetes regulierend eingreifen kann und automatisch den Neustart der betroffenen Komponente auslösen kann. Ebenfalls wurde die untere Ressourcengrenze für alle Anwendungen festgelegt, sodass für jede Anwendung die minimal notwendigen Ressourcen definiert und reserviert sind, um einen reibungslosen Betrieb zu gewährleisten. Untere und obere Ressourcengrenze, im Kubernetes-Kontext auch Requests und Limits genannt, sorgen darüber hinaus dafür, dass Kubernetes die einzelnen Container optimal auf die zur Verfügung stehenden Knoten des Clusters verteilen kann, was die Plattform-Stabilität an sich als auch die Hochverfügbarkeit der Anwendungen selbst erhöht.
Absicherung der administrativen Zugänge und Absicherung der Konfiguration: Gemäß BSI IT-Grundschutz SYS.1.6.A16 enthalten die Container der openDesk Anwendungen keine Werkzeuge für administrative Fernzugriff bzw. generell keine Fernwartungszugänge. Jegliche administrativen Zugriffe erfolgen stets über direkt oder indirekt über die Container-Runtime durch den Hyperscaler. Vorgenommene Änderungen werden nachvollziehbar dokumentiert und in einem Versionskontrollsystem gemäß BSI IT-Grundschutz SYS.1.6.A20 versioniert abgelegt.

(TM11.03) Durchsetzung von Richtlinien (Container):
Im Abschnitt der Best-Practices sind viele Maßnahmen genannt, welche laut BSI IT-Grundschutz umgesetzt werden sollen oder müssen, jedoch wird nie explizit gefordert, dass Technik eingesetzt wird, um die Umsetzung der Maßnahmen und der Richtlinien zu erzwingen, z.B. mit Hilfe eines Policy Systems wie Open Policy Agent (OPA) oder Kyverno und ggf. auch in Kombination mit Bordmitteln der Plattform, hier Kubernetes. Genau hier setzt der Baustein BSI IT-Grundschutz SYS.1.6.A21 an. Er fordert nicht nur, dass mit Hilfe erweiterter Sicherheitsrichtlinien die Berechtigungen von Containern weiter eingeschränkt werden, sondern auch, dass es Systeme, idealerweise ein zentrales System gibt, was all diese Einschränkungen und Maßnahmen erzwingt, d.h. ein Deployment, welches nicht erlaubte Berechtigungen verlangt, wird abgelehnt und dessen Start aktiv verhindert. Die genannten Policy Systeme verfügen darüber hinaus über ein integriertes Monitoring, welches an ein zentrales Monitoring angeschlossen ist, sodass Verstöße gegen die Richtlinien oder auch regulierende Eingriffe des jeweiligen Policy Systems dokumentiert und transparent gemeldet werden.

Konkret werden durch das BSI die folgenden drei Einschränkungen gefordert; eine beispielhafte Möglichkeit der Durchsetzung sei hier mit angegeben:

eingehende und ausgehende Netzverbindungen: NetworkPolicies in Kombination mit Kyverno oder OPA zur dynamischen Überwachung, ob die Policies gesetzt sind und damit sie bei Bedarf automatisch neu gesetzt werden. Hinweis: Die korrekte Einstellung der NetworkPolicy, d.h. dass sie auch wirklich den Netzwerk-Verkehr blockt, den sie blocken soll, kann so nicht überprüft werden. Hierfür sind andere Systeme und Maßnahmen (z.B. Einsatz von Sonden und deren Monitoring) erforderlich.
Dateisystem-Zugriffe: Durch sogenannte “Validating Policies” und “Mutating Policies” (beides im Fall von Kyverno, für OPA heißen sie vergleichbar) können Deployments, also im Fall von Kubernetes die Beschreibungen, wie eine Anwendung ausgerollt und betrieben wird, überprüft werden, ob sie den Richtlinien entsprechen (“validating”) und sofern diese Prüfung fehlschlägt, ein Deployment abgelehnt werden bzw. auch aktiv geändert werden (“mutating”) und damit von einem nicht-konformen Deployment intransparent und in Hintergrund in ein konformes Deployment überführt werden.
Kernel-Anfragen (Syscalls): analog zu “Dateisystem-Zugriffe”.

Darüber hinaus sind noch weitere, sehr granulare Einschränkungen der Berechtigungen auf möglich. Die folgende Liste stellt eine nicht abschließende Sammlung an Maßnahmen dar, welche über die Forderungen des BSI hinaus gehen:

Intern arbeitet Kubernetes Namens- und Label-basiert, d.h. Zusammenhänge und Verknüpfungen z.B. von Containern zu darunterliegenden Knoten, werden über entsprechende Label sichergestellt. Daher ist es nur dem Hyperscaler der Kubernetes Plattform gestattet, die Label der darunterliegenden Knoten zu ändern, damit Container einzelner Kunden sauber und isoliert auf dedizierten Knoten betrieben werden können. Darüber hinaus wird grundsätzlich erzwungen, dass Deployments über Labels verfügen.
Der Hyperscaler stellt darüber hinaus durch eine entsprechend erzwungene Policy sicher, dass nur Container aus vertrauenswürdigen Quellen (Registries) eingesetzt werden können, dass diese über eine valide Signatur verfügen müssen, und dass der Zugriff auf die vertrauenswürdigen Registries immer authentifiziert und niemals anonym geschehen darf. Alle Container werden regelmäßig auf bekannte Schwachstellen überprüft, zu alte Container oder welche mit einer zu hohen oder zu gravierenden Anzahl an bekannten Schwachstellen können erst gar nicht mehr ausgeführt und betrieben werden. Zur Umsetzung dieser Maßnahmen und um darüber hinaus auch das Einschmuggeln von Containern mit Schadcode an den bekannten und vertrauenswürdigen Registries vorbei zu unterbinden, wird mit Hilfe einer sogenannten ImagePullPolicy sichergestellt, dass Container Images immer und ausnahmslos gegen die bekannten Registries geprüft werden bzw. stets neu bei Abweichungen aus diesen bezogen werden.
Die mögliche Interaktion von Containern mit der darunterliegenden Infrastruktur wird weitgehend unterbunden, d.h. Zugriffe auf die Container Runtime, jeglicher Zugriff auf das Dateisystem der darunterliegenden Server oder virtuellen Maschinen (egal ob “echte” Ordner wie / oder “unechte” Ordner wie /proc), die Nutzung von als unsicher eingestuften Volumes zur Datenspeicherung, Änderungen an Kernel-Parametern als auch die direkte Nutzung und die Freigabe von Ports sind verboten und die Einhaltung dieser Regeln wird erzwungen.
Darüber hinaus werden auch aktiv die Zugriffe auf Ressourcen, die durch den Kubernetes Cluster selbst bereitgestellt werden, eingeschränkt, wie z.B. die Nutzung des default Namespace zum Betrieb von openDesk oder die standardmäßig aktivierte Bereitstellung der Credentials zur Kommunikation mit dem Kubernetes Cluster selbst sind technisch mittel Policy unterbunden worden. Durch den zwingenden Einsatz sogenannter Quotas auf Ressourcen wie CPU, Arbeitsspeicher, Massenspeicher, etc. werden im Cluster verfügbare Ressourcen fest zugeordnet und beschränkt, was die Systemstabilität im Allgemeinen erhöht.
Die Nutzung von SELinux oder AppArmor wird erzwungen und das eingesetzte Profil fixiert. Eine Policy erzwingt die Verwendung eingeschränkter Nutzer (Non-Root), die Verwendung des Root-Nutzers oder privilegierter Container an sich wird policy-seitig unterbunden ebenso wie jegliche nachträgliche Rechteausweitungen (privilege escalation). Sogenannte Kernel Capabilities, mit deren Hilfe auch eingeschränkte Nutzer vorab mit administrativen Rechten ausgestattet werden können, werden durch eine entsprechende Policy aktiv unterdrückt. Sogenannte Network Policies stellen sicher, dass einzelnen Komponenten von openDesk oder einzelne Kunden netzwerk-seitig isoliert werden und dass die Kommunikation der Komponenten untereinander als auch “nach außen” nur über wohldefinierte Schnittstellen stattfinden kann und auf das notwendige Minimum reduziert ist.

Der Hyperscaler der Plattform stellt sicher, dass Policy Systeme eingesetzt und mindestens gemäß der genannten Maßnahmen eingerichtet sind und überwacht werden. Ausnahmen von all den geschilderten Maßnahmen sind ausführlich dokumentiert, im Einzelfall geprüft und nur begründbar erlaubt.

(TM11.04) Hostbasierte Angriffserkennung (Container):
Zur weiteren Absicherung vor eventuellen Angriffen auf oder gar den Ausbrüchen aus einem Container sind durch den Hyperscaler der Container-Plattform geeignete Maßnahmen ergriffen worden, um auf Ebene der Hosts das Verhalten der Container zu überwachen. Wie in BSI IT-Grundschutz SYS.1.6.A24 gefordert, sind diese sogenannten Security-Agenten an das zentrale Monitoring und Logging angeschlossen, um Abweichungen vom Normalverhalten erkennen zu können. Diese Meldungen werden über den zentralen Prozess des Hyperscalers zur Behandlung von Sicherheitsvorfällen angemessen behandelt. Durch den Hyperscaler werden folgende Bereiche überwacht:

Netzverbindungen
erstellte Prozesse
Dateisystem-Zugriffe
Kernel-Anfragen (Syscalls)

Der Hyperscaler stellt sicher, dass die notwendigen Security-Agenten installiert, konfiguriert und gewartet werden, dass sie korrekt an das zentrale Monitoring angeschlossen sind und dass der Prozess zum Umgang mit Vorfällen umgesetzt und etabliert ist und dass bei Vorfällen angemessen kommuniziert wird.

(TM11.05) Vorsorge für Untersuchungen (Container):
Der Hyperscaler der Container-Plattform stellt gemäß BSI IT-Grundschutz SYS.1.6.A22 sicher, dass in regelmäßigen Abständen von einem Monat vollständige Backups der Container erstellt sowie gegen Datenverlust gesichert und idealerweise verschlüsselt abgelegt werden, damit diese im Bedarfsfall für eine spätere Untersuchung verfügbar sind. Da im Fall von Kubernetes Teile der Konfigurationen von Containern in Configmaps und Secrets ausgelagert oder im Rahmen der Deployment-Manifeste oder Helm Charts anderweitig (aber unter Versionskontrolle) vorgenommen werden, werden auch hiervon in gleichem Turnus vollständige Sicherungen durchzuführen und wie zuvor gesichert abgelegt.

(TM11.06) Unveränderlichkeit (Container):
Beim Deployment von openDesk werden gemäß BSI IT-Grundschutz SYS.1.6.A23 die Dateisysteme innerhalb des Containers als “read-only”, also ohne Schreibrechte und damit nur lesbar für den Container selbst eingebunden. Lediglich die persistenten Datenspeicher, welche über das verteilte Speicherbackend zur Verfügung stehen, sind als schreibbare Speicherorte verfügbar.

(TM11.07) Hochverfügbarkeit von containerisierten Anwendungen (Container):
Gemäß BSI IT-Grundschutz SYS.1.6.A25 werden alle Komponenten von openDesk auf Kubernetes-Ebene hochverfügbar bereitgestellt, indem mittels Replikation und Load-Balancern mehrere Instanzen der jeweiligen Komponente zur Verfügung stehen und dadurch, dass die Replikas auf mehrere Zonen verteilt werden, auch beim Ausfall ganzer Abschnitte die Verfügbarkeit von openDesk nicht gefährdet wird.

(TM11.08) Weitergehende Isolation und Kapselung (Container):
Gemäß BSI IT-Grundschutz SYS.1.6.A26 können einzelne Kunden der openDesk SaaS-Version eine dedizierte Zuordnung der eigenen SaaS-Instanz auf einzelnen Hosts fest zuzuordnen. Ein dedizierter Betrieb der Container mit Hypervisoren oder gar der festen Zuordnung eines einzelnen Containers zu einem einzelnen Container-Host ist nicht vorgesehen.

(TM12.01): Container Plattform (Kubernetes)
Für die openDesk als SaaS Lösung wird die Kubernetes Platform as a Service (PaaS) Lösung des Hyperscalers genutzt. Dieser Dienst des Hyperscalers unterliegt den Sicherheitsanforderungen der openDesk als SaaS Lösung und wird regelmäßig, mindestens jährlich, hinsichtlich der Einhaltung der nachfolgenden Vorgaben geprüft.

(TM12.02) Durchsetzung von Richtlinien (Kubernetes):
Da erforderliche Richtlinien standardmäßig von Kubernetes, wie den Pod Security Admission Controller, nicht durchgesetzt werden können, wird für das Umsetzen des Policy-Managements ein Tool, z.B. Kyverno, in den jeweiligen Clustern verwendet.

(TM12.03) Kubernetes Nodes:
Alle Cluster-Dienste werden im sogenannten Management-Cluster, einem dedizierten Kubernetes-Cluster, ausgeführt. Alle Workload-Komponenten werden in einem separaten Cluster, den Workload-Clustern, betrieben. Es sind dedizierte Kubernetes Nodes für verschiedene Zwecke zu erstellen: Control Plane Nodes, ETCD Nodes und Worker Nodes. Die Nodes werden durch entsprechende Firewall-Regeln voneinander isoliert.

(TM12.04) Automatisierung und Versionskontrolle:
Einrichtungs- und Wartungsaufgaben sind automatisiert durchzuführen. Hierfür werden vordefinierte Pipelines verwendet, um mit den Clustern zu interagieren. Das Automatisierungssystem muss dazu Zugriff auf ein Versionskontrollsystem haben, in dem alle Konfigurationen der Kubernetes-Cluster, der Cluster-Dienste und der Workloads gespeichert sind, und git-basierte Workflows für Authentifizierung, Autorisierung, Genehmigung und Wartung vollständig unterstützen.

(TM12.05) Lebenszyklus eines Pods:
Für die Initialisierung von Pods werden Init-Container verwendet, um den Start des Hauptcontainers vorzubereiten. Die Init-Container laufen nacheinander und stellen sicher, dass der Hauptcontainer erst gestartet wird, wenn alle Init-Container erfolgreich abgeschlossen sind. Zusätzlich werden Sidecars eingesetzt, um bestimmte Aufgaben wie mTLS durch Proxies zu realisieren und die Trennung von Aufgaben zu unterstützen.

Um sicherzustellen, dass nur autorisierte Container gestartet werden, werden die Images zudem nur aus einer internen Container-Registry bezogen.

(TM12.06) Trennung und Sicherheit von Pods und Containern:
Gemäß “Least-privilege Prinzip” werden Pods und Container mit einem minimalen Satz an Berechtigungen für Benutzende betrieben. Privilegierte Benutzer auf Containern und solche mit root Rechten sind auf das Mindestmaß zu reduzieren. Nur bei ausgewählte Cluster-Dienste dürfen Benutzende mit erweiterten Rechten ausgestattet werden, wenn dies unbedingt erforderlich ist. Alle Workload Container müssen unprivilegiert betrieben werden. Auszuschließen ist eine Rechteausweitung. Die Richtlinien müssen durch die Verwendung von SecurityContext, schreibgeschützten Dateisystemen und der Deaktivierung von Host-Namespace-Sharing durchgesetzt werden. Alle diese Maßnahmen müssen allen Clustern mittels Policy-Management-Tool implementiert werden.

(TM13.01) Datenbanksysteme:
Zugriffe auf Datenbanken sind strenger Richtlinien und Kontrollen unterlegen, wie z.B. über rollenbasierte Zugriffskontrollen (RBAC). Nur autorisierte Benutzer können auf Datenbanken und die Inhalte der Datenbanken zugreifen. Alle Zugriffe und Zugriffsversuche werden protokolliert. Anomalien sind zu prüfen, zu analysieren und entsprechend geeigneten Maßnahmen zu ergreifen. Für den Erhalt der Integrität von Datenbanken müssen regelmäßige Integritätsprüfungen und Validierungen der Daten durchgeführt werden und technische Maßnahmen implementiert werden, wie Transaktionsprotokollierung.

Zudem sind System und Dienst interne Datenbanken, welche für die Bereitstellung von openDesk als SaaS, nicht an das Netzwerk angebunden und somit von äußerlichem Zugriff geschützt. Diese Datenbänke werden nicht von Kunden benutzt und sind somit auch nicht für diese zugänglich.

(TM13.02) Sicherheitsanforderungen an Webanwendungen:
Für eine ausreichende Sicherung von Webservices sind alle eingehenden und ausgehenden Daten auf Richtigkeit, Vollständigkeit und Authentizität zu überprüfen. Webanwendungen müssen den aktuellen Sicherheitsanforderungen, wie bspw. OWASP Top Ten, entsprechen, regelmäßige Sicherheitsüberprüfungen unterzogen und Penetrationstests ausgesetzt werden. Für die Konfiguration von Webanwendungen muss die Implementierung von Sicherheitsheadern und regelmäßigen Sicherheitsüberprüfungen erfolgen. Dazu gehört auch die Deaktivierung nicht verwendeter HTTP-Methoden. Sie sind so zu konfigurieren, dass sie keine sicherheitsrelevanten Informationen preisgeben. Dazu gehört u.a. die Maskierung von Fehlermeldungen, die keine sensiblen Daten enthalten dürfen, sowie die Implementierung von Sicherheitsheadern und Verschlüsselungstechniken. Zugangskontrollmaßnahmen in Form von Authentifizierungs- und Autorisierungsmechanismen wie bspw. OAuth müssen implementiert sein, sowie das Least-Privilege Prinzips durchgesetzt werden. Mit Implementierung von Maßnahmen wie Rate Limiting oder Traffic Filtering müssen Webanwendungen durch Denial-of-Service (DoS)-Angriffe gesichert werden.

8. IT-Grundschutzcheck für den modellierten Informationsverbund

Ermittlung des Status des bestehenden und nach IT-Grundschutz modellierten Informationsverbundes in Bezug auf den Umsetzungsgrad der Sicherheitsanforderungen des IT-Grundschutz-Kompendiums.

Der Soll-Ist-Vergleich wird im Dokument [TBD] dargestellt. Das Sicherheitskonzept openDesk als SaaS gilt nur als vollständig, wenn auch diese Datei vorliegend ist.

Abkürzungsverzeichnis

Abkürzung	Bedeutung
ABAP	Advanced Business Application Programming
ACL	Access Control Lists
ACME	Automatic Certificate Management Environment
AD	Active Directory
AES	Advanced Encryption Standard
AI	Artificial Intelligence
AIDE	Advanced Intrusion Detection Environment
ALG	Application-Level Gateway
API	Application Programming Interface
APT	Advanced Persistent Threat
ASLR	Address Space Layout Randomization
BACS	Building Automation and Control Systems
BIOS	Basic Input/Output System
BSI	Bundesamt für Sicherheit in der Informationstechnologie
C-CSRM	Cybersecurity Supply Chain Risk Management
CA	Certificate Authority
CARP	Common Address Redundancy Protocol
CI/CD	Continuous Integration / Continuous Deployment
CIA	Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit)
CIS	Center for Internet Security
CISA	Cybersecurity and Infrastructure Security Agency
CNI	Container Network Interface
CORS	Cross-Origin Resource Sharing
CPU	Central Processing Unit
CSA	Cloud Security Alliance
CTR	Cybersecurity Technical Report
CUPS	Computer Printing System
CVE	Common Vulnerabilities and Exposures, ein Programm zur Identifizierung, Definition und Katalogisierung von Schwachstellen
CVSS	Common Vulnerability Scoring System
DCCP	Datagram Congestion Control Protocol
DDoS	Distributed Denial of Service
DGUV	Deutsche Gesetzliche Unfallversicherung
DHCP	Dynamic Host Control Protocol
DMA	Direct Memory Access
DNS	Domain Name Server
DoS	Denial-of-Service
DRS	Distributed Resource Scheduling
E2EE	Ende-zu-Ende-Verschlüsselung
ERP	Enterprise Resource Planning
EU	Europäische Union
FDE	Full Disk Encryption, Festplattenverschlüsselung
FTP	File Transfer Protocol
GDM	Gnome Display Manager
GID	Group ID, die Identifikationsnummer einer Gruppe
GNOME	Graphical User Desktop Environment for Linux
GNU	GNU ist ein rekursives Akronym für “GNU’s Not Unix!”
GPG	GNU Privacy Guard
GPS	Global Positioning System,
HCI	Hyper-converged Infrastruktur
HIDS	Host-based Intrusion Detection System
HMACSHA512	Hash-based Message Authentication Code Secure Hash Algorithm 512
HSM	Hardware Security Module
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
IAM	Identity and Access Management
ICMP	Internet Control Message Protocol
ICS	Industrial Control System
IdP	Identity Provider
IDPS	Intrusion Detection and Prevention System
IDS	Intrusion Detection Systems
iLO	Integrated Lights-Out, ein System zur Administrierung und Fernwartung von Servern
IMAC	Install (Installieren), Move (Verschieben), Add (Hinzufügen), Change (Ändern)
IMAP	Internet Message Access Protocol
IO	Input/Output, Eingabe/Ausgabe
IoT	Internet of Things, Internet der Dinge
IP	Internetprotokoll
IPC	Inter-Process Communication, Inter-Prozess-Kommunikation
IPS	Intrusion Prevention System,
ISMS	Information Security Management System, Informationssicherheitsmanagementsystem
IT	Informationstechnologie
KMS	Key Management System
KVM	Kernel-basierte Virtuelle Maschine
LACP	Link Aggregation Control Protocol
LAN	Local Area Network, lokales Netzwerk
LB	Load Balancer
LDAP	Lightweight Directory Access Protocol
LTS	Long Term Support, Langzeitsupport
LUKS	Linux Unified Key Setup
LUN	Logical Unit Number
MaaS	Metal as a Service,
MAC	Mandatory Access Control
MDM	Mobile Device Management
MFA	Multi-Faktor Authentifizierung
mTLS	Mutual TLS, siehe auch TLS
NAT	Network Address Translation
NFS	Network File System
NGFW	Next-Generation Firewall
NIS2	Direktive (EU) 2022/2555 des Europäischen Parlaments und des Europäischen Rats vom 14.12.2022 zur Steigerung der Cybersicherheit in der Europäischen Union als Erweiterung der Regularie (EU) No 910/2014 und der Direktive (EU) 2018/1972, welche Direktive (EU) 2016/1148 ersetzt
NIS Server	Network Information Service Server
NIST	Nationales Institut für Standards and Technologien
NTP	Network Time Protocol
NW	Netzwerk
OAuth	Open Authorization
OoB	Out-of-Band
OS	Operation System, Betriebssystem
OSS	Open Source Software
OWASP	Open Worldwide Application Security Project
PAM	Privileged Access Management
PAW	Privileged Access Workstation
PBKDF2	Password-based Key Derivation Function Version 2
PCI	Peripheral Component Interconnect
PGP	Pretty Good Privacy
PKI	Public Key Infrastructure
PLC	Programmable Logic Controller
POP3	Post Office Protocol Version 3
PXE	Pre-Boot Execution Environment
QoS	Quality of Service
RAID	Redundant Array of Independent Disks
RAM	Random Access Memory
RBAC	Role-based Access Control, rollenbasierte Zugriffskontrolle
RDBMS	Relational Database Management System
RDS	Relational Database Service
RPC	Remote Procedure Call
RSH	Remote Shell
S3	Simple Storage Service, ein Protokoll für Objektspeicher
SaaS	Software as a Service
SAML	Security Assertion Markup Language
SAN	Storage Area Network
SBOM	Software Bill of Material
SCTP	Stream Control Transmission Protocol
SDN	Software-defined Network, Software-definiertes Netzwerk
SDS	Software-defined Storage, Software-definierter Speicher
SGID	Sticky GID, siehe auch GID
SHA	Secure Hash Algorithm
SIEM	Security Information and Event Management
SLA	Service Level Agreement
SNMP	Simple Network Management Protocol
SOPS	Secrets Operations
SQL	Structured Query Language
SSD	Solid State Disk
SSH	Secure Shell, ein Protokoll zur Netzwerkverbindung über unsichere Verbindungen
SSL	Secure Sockets Layer
STRIDE	Spoofing, Tampering, Repudiation (Verleugnung), Information disclosure, Denial of service, Elevation of privilege
SUID	Sticky UID, siehe auch UID
TBM	Technical Building Management
TCP	Transmission Control Protocol
TCP SYN Cookies	TCP SYN Cookie ist eine Technik, um sogenannten SYN Flood Attacken, einer Art von Denial-of-Service Angriffen zu widerstehen
TIPC	Transparent Inter-Process Communication
TLS	Transport Layer Security
TOR	Top-Of-Rack
ToS	Terms of Service
TPM	Trusted Platform Module
UDP	User Datagram Protocol
UEFI	Unified Extensible Firmware Interface
UID	User ID, die Identifikationsnummer eines Benutzers
UPS	Uninterruptible Power Supply, unterbrechungsfreie Stromversorgung
USB	Universal Serial Bus
VIP	Virtual IP, virtuelle IP, siehe auch IP
VM	Virtuelle Maschine
VNC	Virtual Network Computing
VoIP	Voice over IP, siehe auch IP
VPC	Virtual Port Channel
VPN	Virtuelles Privates Netzwerk
VSA	Verschlusssachenanweisung
VS-NfD	Verschlusssache - nur für den Dienstgebrauch
WAF	Web Application Firewall
WLAN	Wireless Local Area Network, Funknetzwerk
XDCMP	X Display Manager Control Protocol