Sommaire
Maintenant qu’est posé le postulat qu’une usine logicielle est une cible de choix, voyons quelles lignes de défense mettre en place pour se protéger.
Dès qu’on parle de sécurité, avant même les outils et les processus, c’est l’humain qui reste la première des protections.
C’est l’humain qui évitera d’introduire du risque, détectera des comportements inattendus ou des signaux faibles et mettra en place les mesures de protection à tous les étages de l’usine logicielle, de la conception jusqu’au déploiement, en passant par toutes les étapes de construction.
Sachant que 80% des cybermenaces ont une origine humaine, on comprend qu’une des clés de la protection reposera sur les acteurs de l’usine logicielle, qu’ils soient utilisateurs ou administrateurs.
Des acteurs formés
Pour tout ce qui touche à la sécurité, la sensibilisation aux risques ainsi qu’une formation continue des acteurs reste un élément fondamental.
Un plan de formation typique serait :
- Expliquer ce que sont les attaques sur la chaîne d'approvisionnement
- Comment elles se produisent
- Les risques pour l’entreprise et ses clients
- En donner une perspective suivant le contexte technique en place
- Les langages de développement
- La stratégie d’utilisation de composants tiers (ex: OpenSource)
- L’outillage en place dans les chaînes de CI et CD
- Détailler les mécanismes de protection mis en place (ou à venir) sur les chaînes CI/CD
- Sas de sécurité (Security Gate)
- Analyses de vulnérabilités directes
- Analyses de vulnérabilités tierces via le jeu des dépendances transitives
- Former sur les réponses à apporter sur les alertes de sécurité
- Analyse des failles remontées
- Distinguer risque potentiel de risque applicable
- Savoir requalifier l’applicabilité d’un risque lorsque le contexte change
- Donner les clés de sélection de composants tiers
- Licences
- Sources Editeurs
- Sources Communautaires
- Analyse de la dynamique et de l’écosystème des projets Open Source
Une telle formation doit être dispensée aux nouveaux arrivants et sera accompagnée de sessions de rafraîchissement sur les nouveaux risques et outils mis en place pour s’en prémunir.
La sécurité est un effort constant et pour ce faire, on pourra solliciter des profils de type DevSecOps qui outre la mise en place d’outils, feront une acculturation dans les équipes.
Et toujours garder à l’esprit que la sécurité reste le sujet de tous, tous doivent être acteurs de la prévention.
Des acteurs identifiés
Savoir qui fait quoi
On doit pouvoir à tout moment répondre à ces questions :
- Qui a accès aux services de l’usine logicielle ?
- A quels services un utilisateur a accès ?
- Quand est arrivé un utilisateur ?
- Quand est parti un utilisateur ?
- Quelles sont les attributions et droits d’un utilisateur sur les services ?
- Quels sont les clés et tokens d’accès d’un utilisateur aux services ?
- A quel moment un utilisateur a vu l’ensemble de ses accès invalidés ?
- Comment révoquer l’ensemble des clés et tokens d’un utilisateur ?
Ce sont des questions qui deviennent critiques dès lors qu’on est face à un risque potentiel.
- En cas de perte ou de vol du poste de travail d’un utilisateur
- Si on a des doutes sur des opérations faites depuis un poste de travail
- On cherche à savoir ce qu’a pu faire un collaborateur
Il convient donc de s’assurer que l’ensemble des acteurs de l’usine logicielle soient identifiés, par exemple dans un annuaire d’entreprise et que leurs accès, directs ou indirects, via clés/tokens, puissent être bloqués à tout moment et ce sur l’ensemble des services de l’usine logicielle.
Bien gérer les départs
Il faudra porter une attention particulière sur les départs avec une inactivation des comptes, clés et tokens très rapide pour que rien ni personne ne les utilise à la place du partant. Cela permettra notamment de détecter des traitements effectués avec des accès d’utilisateurs révoqués ou des activités de type shadow IT.
Retenir une stratégie SSO d’entreprise dans l’usine logicielle permettra de simplifier les procédures de départ et le décommissionnement des comptes, une charge de moins pour l’équipe chargée de l’usine.
Garantir l'authenticité des opérations
Il est fortement recommandé d’utiliser des mécaniques de signature qui permettent de garantir l'authenticité et l'intégrité des opérations.
C’est typiquement ce que l’on va trouver sur des gestionnaires de sources comme GitHub ou GitLab avec en plus des mécanismes qui rendent obligatoires ces signatures.
Confiance et contrôle
L’usine logicielle est une zone qui suit certaines règles, simples :
- Il y a des administrateurs de l’usine logicielle, une équipe CI/CD typiquement.
- Il y a des utilisateurs de l’usine logicielle, l’ensemble des acteurs.
- L’accès à l’infrastructure sous-jacente est réservé aux administrateurs.
- La configuration des chaînes CI/CD est auditable et soumise à approbation.
- Des contrôles de qualité et sécurité sont mis en place sur la chaîne de production.
La sécurité de votre production logicielle passe par un environnement de production qui soit sous contrôle strict et pour cela la chaîne de fabrication doit être parfaitement sûre.
Cela passe par un contrôle des personnes ayant accès à l’infrastructure. Elles doivent être identifiées, en nombre restreint et leurs actions connues et auditables. C’est une demande qu’on trouve dans les conformités ISO 27001 par exemple avec notamment l’utilisation de comptes nominatifs.
On garantit ainsi à un auditeur, que les personnes pouvant intervenir sur l’infrastructure sont connues, leur nombre restreint et qu’on a mis en place une traçabilité sur les opérations.
Dans des contextes plus contraints, par exemple SecNumCloud, il sera peut être même obligatoire de réduire les accès à l’infrastructure à certains profils de l’équipe, par exemple des SRE internes.
Rôles et responsabilités sur l’usine logicielle
Les rôles et responsabilités (ownership) des différents acteurs sur l’usine logicielle doivent être clairs, communiqués et compris de tous.
Chacun doit pouvoir à répondre à 3 questions simples :
- Quels sont mes clients ?
- Quels sont mes fournisseurs ?
- Où commence et où s’arrête ma zone de responsabilité ?
Exemples de questions qui doivent avoir des réponses claires, avec un zoom particulier sur les maintenance en condition opérationnelle (MCO) et condition de sécurité (MCS)
- Qui s’occupe du MCO/MCS de l’infrastructure hébergeant l’usine logicielle ?
- Qui s’occupe du MCO/MCS des services de l’usine logicielle ?
- Qui surveille les vulnérabilités de logiciels tiers ?
- Qui corrige les vulnérabilités de logiciels tiers ?
- Qui définit les règles de qualité et de sécurité des chaînes CI/CD ?
- Qui implémente et maintient les règles de qualité et de sécurité des chaînes CI/CD ?
Dans le découpage MCO/MCS, sur une usine logicielle, on pourra avoir plusieurs acteurs différents, qui seront en charge des différentes couches, infrastructures, services et applicatifs, DevOps, SRE, Ingénieur CI, qui vont devoir se répartir les tâches.
Dès lors que chacun connaît ses missions, on réduit les risques de frictions aux interfaces, on sait précisément qui apportera les réponses et on peut construire les équipes en conséquence.
Rôles et responsabilités sur les projets
L’attribution de droits étendus à beaucoup d’acteurs peut simplifier ou accélérer au démarrage, mais n’est malheureusement guère soutenable sur la durée car on perd en visibilité.
On risque de tomber dans le travers connu de la dilution de responsabilité, “quand trop de personnes sont responsables, plus personne ne l’est”.
Il existe une organisation des rôles dans les usines logicielles qui permettent d’organiser finement l’activité.
Owner, Maintainer, Developer, Reporter, Guest sont des rôles qu’on trouve dans les gestionnaires de sources comme GitLab.
Chez Github, on trouve une structure plus légère, qui va de simple lecteur à administrateur, mais l’idée reste la même.
Avec chaque rôle sont associés des droits qui donnent des responsabilités plus ou moins grandes sur le projet.
Ceci permet implicitement de détecter instantanément qui est chargé de quoi et qui peut faire quoi et pourra vous prémunir du cas suivant :
- On a détecté une faille de sécurité sur un projet ;
- Le projet a 20 owners et 30 maintainers ;
- Il y a donc 50 personnes à contacter ;
- Et le risque que 49 personnes pensent que la 50eme traite la demande ;
- On perd du temps à trouver la personne qui pourra résoudre le problème.
Une organisation fine des rôles va permettre de gagner en lisibilité et en réactivité, ce qui est capital lors de la réponse à incident de sécurité.
Conclusion
La protection de l’usine logicielle commence par des acteurs formés aux risques, enjeux et aux outils mis en place pour détecter et alerter sur des vulnérabilités.
Les acteurs doivent aussi être identifiés et leurs contributions certifiées.
Une distribution claire des rôles et responsabilités permet de s’assurer que l’ensemble du périmètre est couvert et on peut ainsi très rapidement savoir qui mobiliser pour répondre à un risque identifié.
