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.
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 :
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.
On doit pouvoir à tout moment répondre à ces questions :
Ce sont des questions qui deviennent critiques dès lors qu’on est face à un risque potentiel.
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.
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.
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.
L’usine logicielle est une zone qui suit certaines règles, simples :
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.
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 :
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)
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.
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 :
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é.
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é.