Wie GitLab ein eigenes Security-Control-Framework gebaut hat

GitLabs Security-Compliance-Team stellte fest, dass die vorhandenen Security-Control-Frameworks sich nicht so weit anpassen ließen, dass sie zur Multi-Produkt- und Cloud-native-Umgebung der Plattform gepasst hätten.

Also haben wir ein eigenes gebaut.

Hier steht, was wir dabei gelernt haben und warum ein eigenes Security-Control-Framework auch für das eigene Compliance-Programm der richtige Schritt sein kann.

Der Weg durch die Frameworks

Als ich im November 2022 zum Security-Compliance-Team von GitLab kam, verwalteten wir unsere Controls über das Secure Controls Framework, sowohl für externe Zertifizierungen als auch für interne Compliance-Anforderungen. Mit wachsenden Anforderungen zeigte sich jedoch, dass wir etwas Umfassenderes brauchten.

Da die FedRAMP-Autorisierung auf unserer Roadmap stand, entschieden wir uns als Nächstes für NIST SP 800-53. NIST SP 800-53 umfasst mehr als 1.000 Controls, doch diese Vollständigkeit passt nicht ideal zur Umgebung von GitLab.

Wir mussten nicht jedes NIST-Control umsetzen, sondern nur die, die für unsere konkreten Anforderungen gelten. Unser Fokus lag auf der Qualität der Controls, nicht auf ihrer Zahl. Unnötige Controls verbessern die Sicherheit nicht. Im Gegenteil: Zu viele können eine Umgebung unsicherer machen, weil Menschen Wege finden, übermäßig restriktive oder irrelevante Controls zu umgehen.

Manchen Controls fehlte außerdem die nötige Granularität. Das NIST-Control AC-2 "Account Management" etwa deckt Kontoerstellung und Provisionierung ab, Kontoänderung und Deaktivierung, Kontoentfernung und Beendigung, die Verwaltung geteilter Konten und Gruppenkonten sowie Kontoüberwachung und -prüfungen.

In der Praxis sind das mindestens sechs eigenständige Controls mit unterschiedlichen Verantwortlichen, Prüfverfahren und Risiken. Bei Attestierungen wie SOC 2 wird jede dieser Tätigkeiten als eigenes Control geprüft, weil sie unterschiedliche Nachweisanforderungen und operative Kontexte haben. Das allumfassende AC-2 von NIST bildete weder ab, wie wir Controls tatsächlich betreiben, noch wie Auditoren uns tatsächlich bewerten. Wir brauchten Controls, die granular genug sind, um unsere operative Umgebung abzubilden.

So kam es, dass wir NIST-Controls ständig anpassten, ergänzten und umbauten. Irgendwann wurde uns klar: Wir nutzten NIST SP 800-53 gar nicht mehr, wir bauten unser eigenes Framework darauf auf. Wir entschieden, dass ein eigenes, auf die Umgebung von GitLab zugeschnittenes Control-Framework unserem Multi-Produkt-Angebot und den jeweiligen Compliance-Anforderungen jedes Produkts am besten gerecht wird.

Das GitLab Control Framework aufbauen

In fünf methodischen Schritten haben wir unser eigenes Common-Controls-Framework aufgebaut: das GitLab Control Framework (GCF).

1. Analysieren, was wir brauchen

Wir haben unsere bestehenden Controls durchgesehen und jede Anforderung erfasst, die sich aus bereits gehaltenen Zertifizierungen, aus Zertifizierungen auf unserer Roadmap und aus unserem internen Compliance-Programm ergibt:

Externe Zertifizierungen:

• SOC 2 Type II
• ISO 27001, ISO 27017, ISO 27018, ISO 42001
• PCI DSS
• TISAX
• Cyber Essentials
• FedRAMP

Interne Compliance-Anforderungen:

• Controls für unternehmenskritische Systeme, die nicht im Geltungsbereich externer Zertifizierungen liegen
• Controls für Systeme mit Zugriff auf sensible Daten

Damit stand die Ausgangsbasis: welche Controls existieren müssen, um unsere Compliance-Pflichten zu erfüllen.

2. Von etablierten Frameworks lernen

Anschließend haben wir unsere Anforderungen mit anerkannten Frameworks abgeglichen:

• NIST SP 800-53
• NIST Cybersecurity Framework (CSF)
• Secure Controls Framework (SCF)
• Common Controls Framework (CCF) von Adobe und Cisco

Da wir in der Vergangenheit bereits Frameworks eingeführt hatten, wollten wir aus deren Struktur lernen und sicherstellen, dass uns keine wichtigen Sicherheitsdomänen, Controls oder bewährten Vorgehensweisen entgehen.

3. Eigene Control-Domänen schaffen

Aus dieser Analyse heraus haben wir 18 eigene Control-Domänen entwickelt, zugeschnitten auf die Umgebung von GitLab:

Jede Domäne fasst verwandte Controls zu logischen Familien zusammen, die sich daran orientieren, wie das Security-Programm von GitLab tatsächlich organisiert ist und betrieben wird. Diese Struktur gibt uns ein methodisches Vorgehen an die Hand, um Controls zu ergänzen, zu aktualisieren oder zu entfernen, wenn sich unsere Anforderungen ändern.

4. Kontext und Daten ergänzen

Mit den definierten Domänen standen zwei zentrale Fragen an: wie sich Controls über mehrere Produkte hinweg abbilden lassen, ohne das Framework zu duplizieren, und wie sich aussagekräftiger Umsetzungskontext erfassen lässt, um im großen Maßstab tatsächlich betreiben und auditieren zu können.

Über mehrere Produkte hinweg skalieren

GitLab bietet mehrere Produktvarianten an: GitLab.com (mandantenfähiges SaaS auf GCP), GitLab Dedicated (Single-Tenant-SaaS auf AWS) und GitLab Dedicated for Government (GitLabs Single-Tenant-FedRAMP-Angebot auf AWS). Jede Variante hat eigene Infrastruktur, eigene Compliance-Geltungsbereiche und eigene Audit-Anforderungen. Wir mussten produktspezifische Audits unterstützen, ohne dafür jeweils komplett eigene Frameworks anzulegen.

Wir haben eine Control-Hierarchie entworfen, in der Level-1-Controls das Framework bilden und festlegen, was auf Organisationsebene umgesetzt sein muss. Level-2-Controls sind die Umsetzung und halten produktspezifisch fest, wie die jeweilige Anforderung tatsächlich erfüllt wird.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
  accTitle: Control-Hierarchie
  accDescr: Level-1-Anforderungen laufen auf Level-2-Umsetzungen herunter.

  L1["Level 1: Framework<br/>Was umgesetzt sein muss"];
  L2A["Level 2: GitLab.com<br/>Wie es umgesetzt ist"];
  L2B["Level 2: Dedicated<br/>Wie es umgesetzt ist"];
  L2C["Level 2: Dedicated for Gov<br/>Wie es umgesetzt ist"];
  L2D["Level 2: Entity<br/>(von allen geerbt)"];

  L1-->L2A;
  L1-->L2B;
  L1-->L2C;
  L1-->L2D;

Diese Trennung erlaubt es uns, ein einziges Framework mit produktspezifischen Umsetzungen zu pflegen, statt für jede Variante ein eigenes Framework zu verwalten. Entity-Controls gelten organisationsweit und werden von GitLab.com, GitLab Dedicated und GitLab Dedicated for Government geerbt.

Controls mit Kontext anreichern

Klassische Control-Frameworks führen nur wenige Informationen mit: eine Control-ID, eine Beschreibung und eine verantwortliche Person. Das GCF geht einen anderen Weg, und seine eigentliche Stärke sind die umfangreichen Metadaten, die wir zu jedem Control führen. Über die Control-Beschreibung oder das Implementation Statement hinaus erfassen wir:

• Control-Verantwortung: Wer trägt die Verantwortung für das Control und sein Risiko?
• Umgebung: Gilt es organisationsweit (Entity, von allen Produktvarianten geerbt), für GitLab.com oder für Dedicated?
• Assets: Welche konkreten Systeme deckt dieses Control ab?
• Häufigkeit: Wie oft wird das Control durchgeführt oder geprüft?
• Art: Manuell, teilautomatisiert oder vollautomatisiert?
• Klassifizierung: Dient es externen Zertifizierungen oder dem internen Risikomanagement?
• Prüfdetails: Wie bewerten wir es? Welche Nachweise sammeln wir?

Dieser Kontext macht aus dem GCF mehr als eine einfache Control-Liste: ein operationalisiertes Control-Inventar.

Mit dieser Struktur lassen sich Fragen wie diese beantworten:

• Welche Controls gelten für unser SOC-2-Audit für GitLab.com und welche für GitLab Dedicated? → Nach Umgebung filtern: GitLab.com
• Welche Controls verantwortet das Infrastructure-Team? → Nach Verantwortung filtern
• Welche Controls lassen sich automatisieren? → Nach Art filtern: manuell

5. Iterieren, reifen lassen und skalieren

Das GCF ist nicht statisch, sondern darauf angelegt, sich mit unserem Geschäft und der Compliance-Landschaft weiterzuentwickeln.

Neue Zertifizierungen angehen

Weil der Kontext im GCF operationalisiert ist, lassen sich Geltungsbereich und Lücken bei neuen Zertifizierungen (ISMAP, IRAP, C5 und weitere) rasch bestimmen:

• Geltungsbereich bestimmen: Welches Produkt hat den geschäftlichen Bedarf (GitLab.com, GitLab Dedicated oder beide)?
• Anforderungen zuordnen: Decken bestehende Controls die neuen Zertifizierungsanforderungen bereits ab?
• Lücken erkennen: Welche neuen Controls müssen entstehen?
• Zuordnungen aktualisieren: Bestehende Controls mit den neuen Zertifizierungsanforderungen verknüpfen.

Auf neue Regulierung reagieren

Wenn neue Regulierung entsteht oder sich bestehende Anforderungen ändern:

• Bestehende Controls prüfen: Deckt ein vorhandenes Control die neue Anforderung bereits ab?
• Aktualisieren oder neu anlegen: Entweder den Wortlaut eines bestehenden Controls anpassen oder ein neues Control anlegen.
• Die strengste Fassung anwenden: Wenn mehrere Zertifizierungen ähnliche Anforderungen stellen, setzen wir die strengste um. Einmal absichern, vielfach erfüllen.
• Über Zertifizierungen hinweg zuordnen: Das Control mit allen einschlägigen Zertifizierungsanforderungen verknüpfen.

Den Control-Lebenszyklus steuern

Das Framework passt sich verschiedenen Veränderungen an:

• Geänderte Anforderungen: Aktualisieren Zertifizierungen ihre Anforderungen, prüfen wir die betroffenen Controls und passen Beschreibungen oder Zuordnungen an.
• Abgekündigte Controls: Entfällt eine Anforderung oder wird ein Control nicht mehr gebraucht, markieren wir es als deprecated und nehmen es aus dem Monitoring-Plan.
• Neu erkannte Risiken: Risikobewertungen können Lücken aufzeigen, die neue interne Controls erfordern.

Die Stärke gemeinsamer Controls: ein Control, mehrere Anforderungen

Einmal absichern und vielfach erfüllen ist nicht bloß ein Prinzip. Es bringt handfeste Vorteile dabei, wie wir Audits vorbereiten, Control-Verantwortliche unterstützen und neue Zertifizierungen angehen. So sieht das in der Praxis aus, qualitativ wie in Zahlen.

Qualitative Ergebnisse

Seit der Einführung des GCF haben sich unsere Compliance-Abläufe deutlich verbessert:

Integrierter Audit-Ansatz

Mit dem GCF pflegen wir ein Framework, dessen Controls mehreren Zertifizierungsanforderungen zugeordnet sind, statt für jedes Audit eigene Control-Sets zu verwalten. Ein einziges Control kann Anforderungen aus SOC 2, ISO 27001 und PCI DSS gleichzeitig erfüllen.

Schnellere Audit-Vorbereitung

Über das GCF pflegen wir eine konsolidierte Anfrageliste statt getrennter Listen je Audit. Weil wir Controls mit konkretem Kontext definiert haben, steht in unseren Anfragelisten "Okta-Nutzerliste" statt eines generischen "Produktions-Nutzerlisten". Das nimmt Mehrdeutigkeit und Auslegungsspielraum heraus. Wir sammeln keine "N/A"-Nachweise und überlassen es nicht den Auditoren, zu deuten, was "Produktion" in unserer Umgebung bedeutet. Alles ist bereits auf unsere tatsächlichen Systeme zugeschnitten.

Weniger Aufwand für Beteiligte

Diese Integration entlastet unmittelbar alle Beteiligten. Control-Verantwortliche liefern Nachweise einmal, statt auf getrennte Anfragen von SOC-2-, ISO- und PCI-Auditoren zu antworten. Wenn wir Nachweise für Zugriffskontrollen sammeln, erfüllen diese die Anforderungen von SOC 2, ISO 27001 und PCI DSS gleichzeitig. Ein Control, eine Prüfung, ein Nachweis, und mehrere Zertifizierungen und Anforderungen sind erfüllt.

Effizientere Gap-Analysen

Bei neuen Zertifizierungen oder neuen Funktionen ermöglicht der operationalisierte Kontext eine gezieltere Gap-Analyse. Wir können bestimmen, welche Controls bereits existieren, was fehlt und welche Umsetzung nötig ist.

Quantifizierbare Ergebnisse

Control-Effizienz:

• SOC-Controls um 58 % reduziert (200 Controls → 84) für GitLab.com und um 55 % (181 → 82) für GitLab Dedicated
• Ein Framework trägt inzwischen 8+ Zertifizierungen

Audit-Effizienz:

• 4 Audit-Anfragelisten zu einer konsolidiert, Anfragen um 44 % reduziert (415 → 231)
• 95 % Evidence-Acceptance-Rate vor dem Fieldwork bei den jüngsten PCI-Audits

Umfang des Frameworks:

• 220+ aktive Controls über 18 eigene Domänen
• Zugeordnet zu 1.300+ Zertifizierungsanforderungen
• Trägt mehrere Produktvarianten

Wie es weitergeht

Das GCF entwickelt sich weiter, während wir Security- und KI-Controls ergänzen, neue Zertifizierungen angehen und unser Vorgehen schärfen.

Für Fachleute in der Security-Compliance: Keine Scheu davor, ein eigenes Framework zu bauen, wenn die Industriestandards nicht passen. Der anfängliche Aufwand zahlt sich in Skalierbarkeit, Effizienz und Controls aus, die für die eigene Umgebung tatsächlich Sinn ergeben. Manchmal ist das beste Framework das selbst entworfene.

Wer tiefer einsteigen möchte, findet in unserer Dokumentation zum GitLab Control Framework die Methodik, die Control-Domänen und die Feldstruktur im Detail.