Au moment de clore cette série d’articles, il convient de faire un résumé des points abordés et de prendre un peu de hauteur.
Les risques d’attaque sur une usine logicielle sont importants, et les tentatives par Supply Chain Attack sont un des vecteurs de choix.
Le risque est réel, mais la bonne nouvelle est qu’il ne faut rien de très complexe pour s’en prémunir.
Pratiquer un état des lieux
La première chose à faire, collectivement, est de se demander quels sont les niveaux de connaissance sur les risques, de préparation pour y faire face et d’outillage pour s’en prémunir.
- Les acteurs de l’usine logicielle, Dev, PM, PO, DevOps, sont-ils prêts ?
- Y a- t-’il eu une formation sur les risques spécifiques aux usines
- Les acteurs savent-ils précisément quoi faire en cas de risque identifié
- Les rôles et responsabilités de chacun sont- elles claires pour tous
- L’environnement qui héberge l’usine logicielle est- il de qualité production ?
- Processus de maintien en condition opérationnelle
- Processus de maintien en condition de sécurité
- Pratiques autour des backups et restauration des contenus de l’usine
- Résultats des exercices de PRA/PCA
- Quels sont les outils en place ?
- Pour détecter les vulnérabilités
- Pour isoler l’usine d’internet
- Pour avoir un inventaire des dépendances directes et indirectes
Bâtir le plan pour être à l’état de l’art
L’état des lieux doit vous permettre de savoir d’où vous partez et quelles seront les étapes pour arriver à l’état de l’art, et donc de construire votre roadmap.
Voici les jalons importants et certains sont probablement déjà en place chez vous
- L’ensemble des acteurs ont été formés aux risques
- Formation initiale sur les vulnérabilités et vecteurs d’attaques
- Règles sur la sélection des composants externes
- L’usine logicielle suit de solides pratiques de production
- Des backups de chaque service de l’usine
- Des backups restaurés et contrôlés régulièrement
- Définition d’un Plan de Reprise d’Activité (PRA)
- Le PRA est joué régulièrement, idéalement une fois par trimestre, ad minima une fois par an
- Un gestionnaire d’artefacts est en place, en priorité pour les contenus externes
- Les contenus externes ne sont plus consommés en direct mais au travers de proxy.
- L’environnement technique de l’usine logicielle est isolé, notamment d’Internet
- L’usine logicielle est sanctuarisée, les accès vers l’extérieur connus et maîtrisés
- Une isolation des environnements de production évitera les contaminations
- Un inventaire à jour des flux réseaux, entrants et sortants
- Les pipelines de construction incluent des analyses de vulnérabilité
- Toute dépendance risquée est bloquée à la construction
- Les vulnérabilités sont traitées au plus tôt
- Une cartographie des composants embarqués est disponible pour chaque produit
- Nous savons de quoi chaque produit est composé
- Nous pouvons à tout moment savoir quelle version de produit contient quelles vulnérabilités
- Nous pouvons lever des alertes sur des nouvelles vulnérabilités dans des produits en production
- Des analyses de vulnérabilité sont mises en place sur l’ensemble des environnements
- Les vulnérabilités sont détectées dès qu’elles apparaissent
- L’ensemble des environnements notamment en production
Il est possible de faire les choses petit à petit, l’important est d’initier, puis de suivre le processus.
Certaines actions peuvent être faites en parallèle, la vitesse de mise à l’état de l’art dépendra donc des moyens alloués au projet.
Conclusion
Avec des équipes formées et sensibilisées, des processus clairs et connus, et des outils simples, il est possible de protéger efficacement son usine logicielle des contenus dangereux.
Comme tout sujet lié à la sécurité, rien n’est acquis et la vigilance de tous reste la meilleure des protections.
sécurité
sécurité