La sécurité en mode agile

Sécurité des applications
La sécurité en mode agile

De nombreuses organisations, ou leurs prestataires, ont fait le choix de méthodes agiles. De gré ou de force, les « sprints » et autres « releases » sont des termes qui animent désormais le cycle de vie des projets. Loin de nous l’idée de discuter du bienfondé de ces méthodes. Nous nous sommes simplement demandés comment concilier sécurité et agilité.

Pour beaucoup de nos clients, nous avons travaillé sur l’intégration de la sécurité dans les projets. Cette notion désigne les travaux, méthodes et outils qui permettent de s’assurer que chaque projet intègre la bonne démarche de sécurité. Respect de la PSSI, analyse de risques, implémentation des bonnes mesures de sécurité : l’objectif est de décliner une approche industrialisée et pragmatique pour chaque projet. Les chefs de projet deviennent ainsi le garant de la sécurité au sein de leur projet.

Ces travaux sont basés sur les méthodes projet en place dans les organisations - traditionnellement  un bon vieux cycle en V. Face aux méthodes agiles, il est temps de se remettre en question et de revoir l’approche « Sécurité dans les projets ». En se basant sur quelques-uns des principes issus de Scrum, nous nous sommes essayés à l’exercice de la sécurité en mode agile. Tout cela sera challengé, itéré et amélioré au fil du temps…

 

Pre Release 

La première question est celle du cadre de la démarche sécurité. Faut-il tout glisser dans un sprint ou dans une release ? Cette première question n’est pas anodine. La sécurité à l’échelle d’un projet passe par certaines obligations qui n’ont pas nécessairement de valeur « business » pour le projet. Sécuriser la plateforme de développement ? Anonymiser les données de tests ? Un mal nécessaire mais dont la valeur n’est pas évidente de prime abord pour le chef de projet. Cela n’apportera pas beaucoup à l’instant T, à l’échelle d’une story. Mais à long terme cela peut représenter l’économie de bugs très impactants… On retombe sur un débat bien connu, celui de la valeur de la sécurité !

A cela s’ajoute un peu de répartition de la charge de travail : faut-il tout faire porter sur le sprint 0 ou faut-il lisser davantage ? Nous avons pris le parti d’intégrer dans la pre-release un certain nombre de travaux qui vont profiter à l’ensemble de la release. Ainsi les étapes d’expression de besoin « macro » sont-elles présentes dans la pre-release. Soit on intègre les risques issus d’une analyse existante, soit on initie l’analyse de risque pour identifier les premières exigences de sécurité mais également de conformité. On définit les modalités de pilotage et de gouvernance de la sécurité – ou on les extrait de la PSSI. On initie alors un plan de traitement des risques, que l’on ajoutera au backlog ou que l'on pourrait nommer product security backlog. 

 

Run

C’est alors que les sprints vont s’enchainer. Là encore, un parti pris : celui de lisser les travaux. Les mesures transverses, comme celles de la sécurité des données échangées par les acteurs Projet, sont lissées sur plusieurs sprints. Il s’agira de combiner cela avec les autres pans du projet. Si l’infrastructure cible de la plateforme de production est installée en sprint 3, il faudra par exemple travailler sur les guides de durcissement en sprint 1 ou 2. Comme à l’époque du cycle en V : un peu de sécurité au bon moment et pas trop d’un coup pour ne pas décourager ni surcharger les équipes !

On enchaine alors les sprints, en gardant en tête certaines obligations qui ne sont pas directement utiles aux stories, mais qui seront nécessaires au produit – ou tout simplement obligatoire à des fins de conformité interne ou externe. Ci-dessous quelques propositions de travaux à mener pour les différents sprints.

 

SPRINT 0

  • Sensibilisation de l’équipe Projet
  • Protection des documents Projet et des données de tests
  • Sécurisation de l’architecture de développement
  • Déploiement des outils de tests de sécurité

SPRINT 1

  • Revue d’architecture
  • Durcissement des socles
  • Sécurité de l’hébergement

SPRINT N

  • Intégration de la sécurité dans les ateliers de conception (couvrant a minima : données, flux, transactions, accès)
  • Test unitaire de sécurité / revue de code
  • Correction des codes

Il faudra trouver le bon moment pour faire un test d’intrusion – sur un produit suffisamment avancé – mais aussi pour prendre en compte la correction des faiblesses potentielles. Avant et après, l’agilité est l’occasion de challenger son approche en matière de sécurité applicative : des tests plus réguliers mais plus simples. On introduit alors les tests unitaires de sécurité, les revues de code ou scans de vulnérabilités les plus automatisés possibles. Nous pourrons en reparler mais c’est l’occasion de tirer partie du potentiel des outils « devops ». L’intégration continue permet par exemple de jouer de façon automatique des tests de qualité du code. Et plusieurs des outils de test, comme Sonarqube par exemple, intègrent des fonctionnalités de tests de sécurité.

 

Post Release

L’heure est maintenant à la fête rétro. Pour la post-release, nous avons identifié trois chantiers majeurs. Tout d’abord il faut dérouler un certain nombre de cas de tests, qui semblent plus adaptés à l’échelle d’une release que d’un sprint, comme un test de bascule d’un environnement nominal à un environnement de secours par exemple.

Ensuite il faut travailler la conduite du changement, en sensibilisant ou communiquant vers les utilisateurs. On retombe sur le sujet de la « première connexion ». Comment distribuer les moyens d’accès à de nouveaux utilisateurs si l’application ne bénéficie pas d’un SSO ou d’une fédération d’identité ? Un mot de passe à usage unique, un mot de passe par défaut transmis en clair par mail, le même pour tout le monde ? Cette étape est souvent négligée et donne lieu à des horreurs sur le plan de la sécurité !

Enfin il faut préparer le run. Cela passe désormais par l’intégration du nouveau projet aux dispositifs de pilotage de la sécurité opérationnelle. En gros il s’agira d’intégrer tout cela dans le SOC et les dispositifs d’alerte et de suivi de la sécurité au quotidien.

 

Conclusion 

Les méthodes agiles sont parfois vécues comme une source de difficulté pour la sécurité. La notion d’agilité est parfois un beau prétexte pour aller trop vite et négliger quelques fondamentaux de gestion des risques. Mais la plupart du temps, il faut en faire une opportunité pour remettre en question son approche Sécurité et dépoussiérer le fameux processus d’intégration de la sécurité dans les projets ! La transformation numérique passe aussi par la transformation de la sécurité !

Pour vous aider à voir plus clair, téléchargez le visuel qui récapitule les étapes de la sécurité en mode agile.

 

Benjamin Leroux, Consultant senior en Sécurité des Systèmes d'Informations, Advens