Comment GitLab a créé un framework de contrôle de sécurité de A à Z

L'équipe Security Compliance de GitLab a constaté que les frameworks de contrôle de sécurité existants ne permettaient pas la personnalisation nécessaire pour s'adapter à l'environnement multi-produits et cloud-native. Elle a donc décidé de créer son propre framework.

Découvrez ce que nous avons appris et pourquoi créer son propre framework de contrôle de sécurité personnalisé pourrait convenir à votre programme de conformité.

Un parcours jalonné de frameworks

Lorsque j'ai rejoint l'équipe Security Compliance de GitLab en novembre 2022, nous utilisions le Secure Controls Framework pour gérer les contrôles de nos certifications externes et nos besoins de conformité interne. Mais à mesure que nos exigences augmentaient, nous avons réalisé que nous avions besoin d'une solution plus complète.

Avec l'autorisation Federal Risk and Authorization Management Program (FedRAMP) dans notre roadmap, nous avons choisi d'adopter la norme NIST SP 800-53. Celle-ci comprend plus de 1 000 contrôles, mais son exhaustivité n'est pas entièrement adaptée à l'environnement de GitLab.

Nous n'avions pas besoin d'implémenter chaque contrôle NIST, mais uniquement ceux applicables à nos exigences spécifiques. Nous nous sommes concentrés sur la qualité des contrôles plutôt que la quantité. Implémenter des contrôles inutiles n'améliore pas la sécurité ; en réalité, un nombre excessif de contrôles peut fragiliser la sécurité d'un environnement, car les individus trouvent des moyens de contourner des contrôles trop restrictifs ou non pertinents.

Certains contrôles ne possédaient pas la granularité nécessaire à nos besoins. Par exemple, le contrôle AC-2 « Account Management » de la norme NIST couvre la création et le provisionnement des comptes, la modification et la désactivation des comptes, la suppression et la résiliation des comptes, la gestion des comptes partagés et de groupe, ainsi que la surveillance et la revue des comptes.

En pratique, il s'agit d'au moins six contrôles distincts avec des propriétaires, des procédures de test et des risques différents. Pour des certifications comme SOC 2, chaque activité est testée comme un contrôle séparé, car les exigences en matière de preuves et les contextes opérationnels diffèrent. Le contrôle AC-2 global de la norme NIST ne correspondait pas à la façon dont nous gérions réellement nos contrôles, ni à la façon dont les auditeurs nous évaluaient, et nous avions besoin de contrôles suffisamment granulaires pour refléter notre environnement opérationnel.

Nous nous retrouvions à personnaliser, ajouter et adapter constamment les contrôles NIST à notre environnement. À un moment donné, nous avons réalisé que nous n'utilisions plus vraiment la norme NIST SP 800-53 : nous étions en train de construire notre propre framework. Nous avons décidé qu'un framework de contrôle personnalisé, adapté à l'environnement de GitLab, permettrait de mieux répondre à notre offre multi-produits et aux besoins de conformité spécifiques de chaque produit.

Création du GitLab Control Framework

En cinq étapes méthodiques, nous avons construit notre propre framework de contrôles communs : le GitLab Control Framework (GCF).

1. Analyser nos besoins

Nous avons examiné nos contrôles existants et mis en correspondance chaque exigence de nos certifications externes déjà obtenues, les certifications figurant dans notre roadmap et notre programme de conformité interne :

Certifications externes :

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

Besoins de conformité interne :

• Contrôles pour les systèmes critiques non inclus dans la portée des certifications externes
• Contrôles pour les systèmes ayant accès à des données sensibles

Cette première étape nous a permis d'établir la base de référence : quels contrôles doivent exister pour satisfaire nos obligations de conformité.

2. S'inspirer des frameworks du secteur

Ensuite, nous avons comparé nos exigences aux frameworks reconnus dans le secteur :

• NIST SP 800-53
• NIST Cybersecurity Framework (CSF)
• Secure Controls Framework (SCF)
• Common Controls Framework (CCF) d'Adobe et de Cisco

Étant donné que nous avions déjà adopté des frameworks par le passé, nous souhaitions nous inspirer de leur structure et nous assurer de ne pas négliger des domaines, des contrôles ou des bonnes pratiques de sécurité essentiels.

3. Créer des domaines de contrôle personnalisés

À la suite de cette analyse, nous avons créé 18 domaines de contrôle personnalisés adaptés à l'environnement de GitLab :

Chaque domaine regroupe des contrôles similaires en familles logiques, alignées sur la façon dont le programme de sécurité de GitLab est réellement organisé et opéré. Cette structure offre une approche méthodique pour ajouter, mettre à jour ou supprimer des contrôles à mesure que nos besoins évoluent.

4. Ajouter du contexte et des données

Une fois nos domaines définis, nous avons fait face à deux défis majeurs : comment appliquer des contrôles pour plusieurs produits sans dupliquer le framework, et comment capturer un contexte de mise en œuvre pertinent pour réellement exploiter et auditer à grande échelle.

Mise à l'échelle pour plusieurs produits

GitLab propose plusieurs produits : GitLab.com (SaaS multilocataire sur Google Cloud Platform GCP), GitLab Dedicated (SaaS monolocataire sur AWS) et GitLab Dedicated pour le secteur public (offre FedRAMP monolocataire de GitLab sur AWS). Chaque offre possède une infrastructure, un périmètre de conformité et des exigences d'audit différents. Nous devions prendre en charge des audits spécifiques à chaque produit sans créer des frameworks entièrement séparés.

Nous avons conçu une hiérarchie de contrôles où les contrôles de niveau 1 forment la base du framework et définissent ce qui doit être implémenté au niveau organisationnel. Les contrôles de niveau 2 représentent la mise en œuvre et contiennent les détails spécifiques des produits et la façon dont chaque exigence est réellement satisfaite.

%%{init: { "fontFamily": "GitLab Sans" }}%%

graph TD
accTitle: Hiérarchie des contrôles
accDescr: Les exigences de niveau 1 se déclinent en implémentations de niveau 2.

L1["Niveau 1 : framework<br/>Ce qui doit être implémenté"];
L2A["Niveau 2 : GitLab.com<br/>Façon d'implémenter"];
L2B["Niveau 2 : GitLab Dedicated<br/>Façon d'implémenter"];
L2C["Niveau 2 : GitLab Dedicated sect. publ.<br/>Façon d'implémenter"];
L2D["Niveau 2 : entité<br/>(hérité par tous)"];

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

Cette séparation nous permet de maintenir un seul framework avec des implémentations spécifiques à chaque produit, plutôt que de gérer des frameworks dupliqués pour chaque offre. Les contrôles d'entité s'appliquent à l'ensemble de l'organisation et sont hérités par GitLab.com, GitLab Dedicated et GitLab Dedicated pour le secteur public.

Ajout de contexte aux contrôles

Les frameworks de contrôle traditionnels ne suivent qu'un minimum d'informations : un identifiant de contrôle, une description et un propriétaire. Le GCF adopte une approche différente et sa force réside dans les métadonnées exhaustives que nous associons à chaque contrôle. Au-delà de la simple description du contrôle ou de la déclaration de mise en œuvre, nous suivons les éléments suivants :

• Le propriétaire du contrôle : qui est responsable du contrôle et de son risque ?
• L'environnement : s'applique-t-il à l'ensemble de l'organisation (entité, hérité par toutes les offres produits), à GitLab.com ou à GitLab Dedicated ?
• Les actifs : quels systèmes spécifiques ce contrôle couvre-t-il ?
• La fréquence : à quelle fréquence le contrôle est-il exécuté ou testé ?
• La nature : est-il manuel, semi-automatisé ou entièrement automatisé ?
• La classification : est-il destiné à des certifications externes ou à la gestion des risques internes ?
• Les détails des tests : comment l'évaluons-nous ? Quelles preuves collectons-nous ?

Ce contexte transforme le GCF d'une simple liste de contrôles en un inventaire de contrôles opérationnel.

Grâce à cette structure, nous pouvons répondre à des questions telles que :

• Quels contrôles s'appliquent à GitLab.com pour notre audit SOC 2 par rapport à GitLab Dedicated ? → Filtrer par environnement : GitLab.com
• Quels contrôles l'équipe Infrastructure possède-t-elle ? → Filtrer par propriétaire
• Quels contrôles pouvons-nous automatiser ? → Filtrer par nature : manuel

5. Itérer, faire maturer et mettre à l'échelle

Le GCF n'est pas statique et a été conçu pour évoluer avec notre activité et notre environnement de conformité.

Obtention de nouvelles certifications

Grâce au contexte opérationnel intégré au GCF, nous pouvons rapidement déterminer le périmètre et les lacunes lors de l'obtention de nouvelles certifications (ISMAP, IRAP, C5, etc.) :

1. Déterminer le périmètre : quel produit en a besoin (GitLab.com, GitLab Dedicated, ou les deux) ?
2. Cartographier les exigences : les contrôles existants couvrent-ils déjà les exigences de la nouvelle certification ?
3. Identifier les lacunes : quels nouveaux contrôles doivent être créés ?
4. Mettre à jour les correspondances : relier les contrôles existants aux exigences de la nouvelle certification.

Adaptation aux nouvelles réglementations

Lorsque de nouvelles réglementations émergent ou que des exigences existantes changent :

• Examiner les contrôles existants : un contrôle existant couvre-t-il déjà la nouvelle exigence ?
• Mettre à jour ou créer : soit mettre à jour le contrôle existant, soit créer un nouveau contrôle.
• Appliquer le plus strict : lorsque plusieurs certifications ont des exigences similaires, nous implémentons la version la plus stricte conformément à l'approche qui vise à sécuriser une fois pour se conformer à de nombreuses exigences.
• Établir les correspondances entre certifications : relier le contrôle à toutes les exigences de certification pertinentes.

Gestion du cycle de vie des contrôles

Le framework s'adapte à divers changements :

• Évolution des exigences : lorsque des certifications mettent à jour leurs exigences, nous examinons les contrôles impactés et mettons à jour les descriptions ou les correspondances.
• Contrôles obsolètes : si une exigence est supprimée ou si un contrôle n'est plus nécessaire, nous le marquons comme obsolète et le retirons de notre calendrier de surveillance.
• Identification de nouveaux risques : les évaluations des risques peuvent révéler des lacunes nécessitant de nouveaux contrôles internes.

La force des contrôles communs : contrôle unique, exigences multiples

Un contrôle de sécurité unique qui permet de se conformer à de nombreuses exigences n'est pas qu'un simple principe : il s'agit d'un processus avec des avantages concrets sur la façon dont nous préparons les audits, accompagnons les propriétaires de contrôles et obtenons de nouvelles certifications. Découvrez les résultats en pratique, en termes de qualité et de chiffres.

Résultats concernant la qualité

Depuis la mise en œuvre du GCF, nous avons constaté des améliorations significatives dans notre gestion de la conformité :

Approche d'audit intégrée

Le GCF nous permet de maintenir un seul framework avec des contrôles associés aux exigences de plusieurs certifications, au lieu de gérer des ensembles de contrôles séparés pour chaque audit. Un seul contrôle peut satisfaire simultanément aux exigences SOC 2, ISO 27001 et PCI DSS.

Préparation des audits plus rapide

Grâce au GCF, nous maintenons une seule liste de demandes consolidée au lieu de listes séparées pour chaque audit. Étant donné que les contrôles ont été définis avec un contexte spécifique, nos listes de demandes indiquent « liste des utilisateurs Okta » au lieu d'une mention générique « liste des utilisateurs en production », ce qui élimine toute ambiguïté et interprétation. Nous ne collectons pas de preuves « N/A » et ne laissons pas aux auditeurs le soin d'interpréter ce que « production » signifie dans notre environnement. Tout est déjà adapté à nos systèmes réels.

Réduction de la charge pour les parties prenantes

Cette intégration réduit directement la charge de travail de nos parties prenantes. Les propriétaires de contrôles n'ont besoin de fournir des éléments qu'une seule fois au lieu de répondre à des demandes séparées des auditeurs SOC 2, ISO et PCI. Lorsque nous collectons des preuves pour les contrôles d'accès, celles-ci conviennent simultanément aux exigences SOC 2, ISO 27001 et PCI DSS. Un seul contrôle, un seul test et une seule preuve sont nécessaires pour satisfaire à de multiples certifications et exigences.

Analyses des lacunes plus efficaces

Lors de l'obtention de nouvelles certifications ou du lancement de nouvelles fonctionnalités, le contexte opérationnel permet une analyse des lacunes plus efficace. Nous pouvons déterminer quels contrôles existent déjà, ce qui manque et quelle mise en œuvre est nécessaire.

Résultats quantifiables

Efficacité des contrôles :

• Réduction de 58 % des contrôles SOC (de 200 à 84) pour GitLab.com et de 55 % (de 181 à 82) pour GitLab Dedicated
• Un seul framework prend désormais en charge plus de 8 certifications

Efficacité des audits :

• Consolidation de 4 listes de demandes d'audit en 1 seule, réduisant les demandes de 44 % (de 415 à 231)
• Taux d'acceptation des preuves de 95 % avant le début des travaux de terrain pour les audits PCI récents

Échelle du framework :

• Plus de 220 contrôles actifs répartis sur 18 domaines personnalisés
• Correspondances avec plus de 1 300 exigences de certification
• Prise en charge de plusieurs offres produits

Perspectives

Le GCF continue d'évoluer à mesure que nous ajoutons des contrôles de sécurité et d'IA, obtenons de nouvelles certifications et affinons notre approche.

Pour les professionnels de la conformité des contrôles de sécurité : n'hésitez pas à créer votre propre framework si les normes du secteur ne vous conviennent pas. L'investissement initial est largement rentabilisé en termes d'évolutivité, d'efficacité et de contrôles véritablement adaptés à votre environnement. Parfois, le meilleur framework est celui que vous concevez vous-même.

Si cet article vous a été utile, consultez notre documentation complète du GitLab Control Framework, où nous détaillons notre méthodologie pour ce framework, nos domaines de contrôle et nos structures de champs.