Comment DevSecOps peut rendre votre SMSI basé sur la norme ISO 27001 plus mature

Préface

Commençons par dresser un tableau légèrement exagéré de la sécurité de l'information. Pourquoi ? Parce que c'est une chose étrange. Presque tout le monde la connaît. La plupart des gens y ont déjà été confrontés directement ou indirectement. Ils vous disent à quel point c'est important et à quel point une cyber-attaque serait néfaste. Mais d'un autre côté, les responsables de la sécurité qui tentent de mettre en œuvre des mesures de sécurité doivent souvent faire face à des refus :

• Les "gardiens de la sécurité" bloquent ou ralentissent toujours les projets les plus rentables pour les entreprises.
• Les développeurs et les administrateurs de système ne voient que la charge de travail supplémentaire qui leur est imposée en raison de la sécurité.
• Pour de nombreux utilisateurs finaux, contourner les mesures de sécurité de la manière la plus créative possible semble être une sorte de sport.

Comment la sécurité peut-elle être pratique ?

Nous ne voulons pas être catastrophistes, la situation n'est pas toujours aussi grave que nous venons de la décrire, mais les personnes travaillant dans le domaine de la sécurité de l'information peuvent reconnaître certaines des histoires ci-dessus depuis plus longtemps. Se plaindre n'est pas la raison d'être de cet article ; il explique comment la sécurité pratique peut être mise en œuvre à un stade très précoce du développement logiciel en utilisant DevSecOps.

En même temps, elle est liée aux systèmes de gestion de la sécurité de l'information (SGSI), plus théoriques et axés sur la conformité, que la plupart des entreprises ont mis en place aujourd'hui. Il existe plusieurs idées sur la manière de combiner les deux approches. Nous nous concentrerons sur une idée relativement nouvelle : OWASP DSOMM, le modèle de maturité DevSecOps de l'Open Web Application Security Project.

ISO 27001 : bien connue et largement utilisée

Commençons par l'ISO 27001, la norme de sécurité de l'information sur laquelle se fondent la plupart des SMSI de nos clients. Alors que la norme ISO 27001 définit les exigences générales, la norme associée ISO 27002 fournit une liste détaillée des documents requis et recommandés. Elle mesure les contrôles à partir de sujets organisationnels tels qu'une organisation de la sécurité de l'information bien définie sur les processus (on/offboarding, réponse aux incidents, gestion des fournisseurs), jusqu'à des exigences détaillées telles qu'une politique de mot de passe ou une matrice de rôles et de responsabilités bien définie.

Ce qui est vraiment nécessaire

Les gens se plaignent des exigences et des contrôles de la norme ISO parce qu'elle modifie leur activité quotidienne ; elle est de trop haut niveau. Beaucoup veulent des exigences précises qu'ils peuvent utiliser et mettre en œuvre directement, mais malheureusement, la norme ISO 27001 / 27002 ne fonctionne pas à ce niveau. Il est nécessaire d'établir une correspondance entre le niveau élevé et la mise en œuvre pratique de bas niveau pour les opérations quotidiennes.

C'est pourquoi nous nous concentrons sur une nouvelle idée de correspondance : l'une des exigences énumérées dans la norme ISO 27002 est un "processus documenté de développement du système" (section A.14). C'est là que DevSecOps et le modèle de maturité DevSecOps (DSOMM) de l'OWASP entrent en jeu.

Pourquoi DevSecOps est-il utile à votre organisation ?

DevOps (combinaison du développement de logiciels - "Dev" ; et des opérations informatiques - "Ops") est également bien connu dans l'industrie du développement de logiciels depuis des années. Son objectif est de raccourcir le cycle de vie du développement des systèmes et d'assurer une livraison continue avec une qualité logicielle élevée. Ce type de développement logiciel basé sur DevOps est souvent mis en œuvre dans le cadre d'approches agiles telles que Scrum ou Kanban, car les deux idées visent le même objectif : des cycles de vie courts et une livraison continue.

DevSecOps (DevOps avec sécurité profondément intégrée - "Sec") a été ajouté à DevOps plus tard, lorsque les gens ont réalisé que la mise en œuvre de la sécurité dès les premières phases de développement présentait plusieurs avantages. Les éventuels problèmes de sécurité sont détectés très tôt et il n'est pas nécessaire de les résoudre au cours ou à la fin de la phase de développement. En règle générale, plus vous identifiez un problème de sécurité tard dans le cycle de vie du logiciel, plus il sera coûteux de le résoudre.

Identifier les problèmes de sécurité

Coût relatif de la correction des bogues, en fonction du moment de leur détection

Le fait de s'occuper des bogues de sécurité dès la phase de développement (exigences, architecture, codage, intégration, tests de composants) pourrait permettre d'économiser beaucoup de ressources - temps et budget, ainsi qu'une motivation insuffisante de l'équipe.

Pour en revenir aux premiers obstacles auxquels les responsables de la sécurité doivent faire face, DevSecOps satisferait plusieurs parties :

1. Premièrement, l'aspect commercial
   1. ne reçoit pas (ou moins) de "bloqueurs" tardifs de la part de la sécurité
   2. obtient des coûts moins élevés ainsi que des projets plus respectueux des délais et du budget grâce à la correction précoce des bogues
2. Deuxièmement, les développeurs et les administrateurs de systèmes
   1. avoir à traiter moins de problèmes de sécurité lors des tests et de la mise en œuvre, ce qui pourrait permettre de gagner beaucoup de temps.
   2. s'éduquer automatiquement pour procéder de la même manière et de manière plus sûre dans les projets futurs, car le processus global était plus simple et moins frustrant.

Comme nous venons de le voir, le développement de logiciels selon l'approche DevSecOps présente de nombreux avantages. Le problème est de savoir comment nous pouvons utiliser cette approche plutôt pratique et orientée vers le développement pour alimenter un SGSI basé sur la norme ISO 27001, par exemple :

• comment conserver les secrets,
• comment transférer des paramètres confidentiels, ou
• comment faire l'inventaire des objets en cours d'exécution, etc.

Cette approche ne permet pas de traiter ces sujets à un niveau aussi détaillé. Les données sont nécessaires pour documenter et prouver ce qui est fait pour atteindre les contrôles spécifiques de la norme ISO 27002. Toute personne ayant participé à un audit basé sur la norme ISO 27001 sait à quel point ces informations sont importantes et à quel point la plupart des auditeurs se concentrent sur la déclaration d'applicabilité (SoA). La déclaration d'applicabilité documente exactement les liens entre un contrôle ISO 27002 et la mesure technique ou organisationnelle qu'une entreprise a mise en œuvre pour y répondre.

Les combiner : l'approche DSOMM de l'OWASP

L'équipe de projet de l'OWASP DSOMM a également reconnu ce besoin. Relativement récemment, une correspondance entre les sujets du DSOMM et les contrôles ISO 27002 a été ajoutée. Certains de nos clients travaillant avec DevSecOps utilisent déjà cette correspondance. Le responsable du SMSI peut directement faire correspondre les mesures prises pendant les DevSecOps aux contrôles ISO 27002 correspondants, tels qu'ils sont énumérés dans le plan d'action. La plupart des correspondances DSOMM se réfèrent à A.14 (processus de développement de système documenté) et certaines à des contrôles tels que A.12 (opérations, sauvegardes, surveillance, etc.), de sorte que la couverture est déjà relativement large.

L'utilisation de la nouvelle cartographie DSOMM-ISO27701 pourrait donc servir de pont entre le SMSI de haut niveau et le processus de développement logiciel de bas niveau. Nous recommandons vivement aux propriétaires de produits et de risques des équipes de développement et aux responsables de la sécurité de l'information (CISO) de discuter de ce sujet. C'est un pas de plus vers des logiciels plus matures et plus sûrs. En même temps, c'est aussi un pas de plus vers un SGSI mature.

Conclusion

Vous développez des logiciels dans votre entreprise, que ce soit pour votre propre usage ou pour un produit destiné à d'autres ? Vous intéressez-vous à la sécurité de l'information, non seulement en théorie mais aussi en pratique ? Dans ce cas, vous devriez certainement vous intéresser de plus près à DevSecOps en général, surtout si vos équipes de développement travaillent déjà en mode agile. Chez CISO AG, nous vous aidons à automatiser les tâches de sécurité essentielles et à les mettre en œuvre dans votre flux de travail DevOps.