Tous ceux qui ont mis en place des projets agiles savent qu'ils vont se heurter au frein de ceux qui n'adoptent pas cette démarche. Ceux qui privilégient une approche d'étude globale avant toute réalisation ont du mal à comprendre ceux qui avancent par itérations successives, validées à chaque sprint par la satisfaction des clients ou des utilisateurs.
Dans ces multiples freins on trouve la sécurité, souvent mise en avant comme incompatible avec l'agilité.
En effet, comment arriver à faire homologuer avant la mise en service la sécurité d'un système qui va être spécifié, construit, testé et mis en production par morceaux ? La démarche de sécurité semble difficilement compatible avec les projets agiles.
À tel point que certains projets agiles ont certainement du avancer en dehors de l'homologation fixée par la sécurité, sous couvert d'expérimentation ou de priorité stratégique, pour tester de nouveaux services et sans mettre en place dès le démarrage une sécurité disproportionnée avec les enjeux du pilote engagé.
Entre deux enjeux majeurs - la transformation numérique et la cybersécurité - l'entreprise doit parfois choisir le plus important des deux pour assurer sa survie : la transformation numérique ! C'est elle qui va permettre de maintenir ses revenus dans cette nouvelle économie incertaine, quitte à faire l'impasse dans un premier temps sur la démarche sécurité, le temps d'assurer l'installation des nouveaux services numériques, et y revenir ensuite une fois les premiers objectifs atteints.
Alors comment réconcilier ces deux démarches sans que l'une ignore l'autre ?
Et bien cet été, c'est l'ANSSI, l'Agence Nationale de Sécurité des Systèmes d'Information créée en 2009, qui en a certainement surpris plus d'un en publiant une note en version bêta sur comment "Intégrer la sécurité numérique en démarche Agile ?".
Cette initiative est saluée par GreenSI via ce billet pour de nombreuses raisons.
Tout d'abord elle démontre comment un organisme de gouvernance, au lieu de se cacher derrière le caractère régalien de sa mission, reconnaît l'évolution amenée par le digital et l'efficacité de l'agilité pour y répondre.
Ainsi, elle fait avancer la réflexion et propose d'y répondre en conservant l'objectif de sécurité à atteindre, mais en ouvrant un autre chemin pour s'y rendre.
Cette démarche conforte tous les RSSI - Responsable de la Sécurité des SI - qui ont déjà choisi de déchausser leurs "bottes régaliennes" pour se mettre au service des métiers. Ces RSSI sont passés du contrôle au conseil et aident les métiers à mettre en oeuvre les nouveaux systèmes souhaités au lieu de simplement en refuser les dossiers de conception quand ils ne respectent pas les attendus, même quand ces attendus sont discutables dans la nouvelle économie.
Ensuite, elle propose aux professionnels de l'informatique de consulter une version de ce document pour appel à commentaires. L'ANSSI propose de confronter sa vision au retour d'expérience pratique de mise en oeuvre dans les projets des entreprises publiques ou privées.
GreenSI trouve cette co-construction ouverte très innovante et complémentaire des travaux qui peuvent se tenir dans les commissions de groupes de DSI comme le Cigref.
Enfin, la démarche proposée est simple et pragmatique. Elle vise à répondre à une contrainte réglementaire d'homologation en contournant l'approche traditionnelle. Pour cela elle s'inspire de l'agilité, en adopte le fonctionnement, et adapte la démarche sécurité pour intégrer ces projets construits de façon itérative avec des cycles "Dev et Ops" qui s'enchaînent. La mécanique de comment intégrer cette démarche dans les sprints et les activités de développement est très bien détaillée. Globalement cela repose sur deux principes.
Le premier principe proposé est celui d'adapter le niveau de sécurité aux enjeux du projet.
Quand un projet se construit de façon itérative, ce niveau de sécurité va monter progressivement, mais surtout commence au bon niveau.
Si votre premier sprint consiste à mettre en production une page blanche avec inscrit dessus "Hello world!" (pour valider la chaîne de construction par exemple), vous imaginez bien que même si un hackeur s'empare de la page, l'impact pour l'entreprise est quasi nul et ce système n'aura pas été connecté au reste du SI.
Dans le paradigme classique de la sécurité, l'affichage de cette page (et donc le test de la chaîne de bout en bout) n'aurait pu se faire qu'une fois l'ensemble du système homologué et le système de sécurité complet des serveurs mis en place... Même si finalement cette réponse sécuritaire porte sur 99% de fonctions encore non développées !
A la clef, le time to market, car pendant que l'on étudie et on imagine des solutions pour des problèmes qui ne sont pas encore posés, les concurrents avancent et les startups innovent.
Le second principe est de traiter les risques de manière rigoureuse et itérative pour tendre vers l'exhaustivité.
C'est l'agilité adaptée à l'identification des risques ; mais en réajustant les objectifs de sécurité à chaque itération et en intégrant les risques induits par les interactions entre composants au fur et à mesure qu'ils sont présents ensemble dans le système. Les fameuses 99% de fonctions non développées qui passent par la page "Hello world!" n'induisent pas leurs contraintes à cette page tant qu'elles ne sont pas développées.
Les premiers retours d'expérience des professionnels de la sécurité sur le site de consultation ouvert par la DINSIC montre une très bonne réception à la fois de la démarche de co-construction de l'ANSSI, et de la nouvelle démarche de sécurité agile. Beaucoup remercient également la publication et la clarté du document d'accompagnement "Outils et bases de connaissance"qui pose les bases de la sécurité numérique.
GreenSI pense même que cette démarche peut renforcer la sécurité finale obtenue par rapport à une approche traditionnelle. Non pas que l'analyse soit plus poussée, mais parce que les femmes et les hommes de ces projets vont tout simplement collaborer et non s'affronter quand l'approche régalienne instaure des hiérarchies de pouvoirs.
- La démarche agile demande un niveau de compréhension de la sécurité par les développeurs et l'équipe projet plus élevé que dans la démarche classique ; donc demande plus de dialogue entre développeurs et l'équipe sécurité.
- De plus comme elle est itérative, à chaque itération ce dialogue va permettre l'amélioration continue, et de revenir à la marge sur les choix du sprint précédent. Les développeurs agiles font déjà cela pour l'architecture logicielle avec le "code refactoring" qui consiste à rendre générique au sprint suivant des parties du code qui avaient été produites au départ pour un seul cas, sans changer les fonctionnalités produites.
Cela n'est pas sans rappeler la démarche DevOps, quand les Développeurs et les Opérations ont commencé à se parler et ne plus se retrancher derrière les dogmes de chacun de ces métiers (comme celui des évolutions du SI globales et par paliers).
L'agilité démontre une fois de plus sa capacité de transformation des organisations. Elle est ici en train de transformer une interface de plus dans le processus collaboratif de construction du logiciel, celle entre la conception et la sécurité, car comme GreenSI aime bien l'écrire, l'agilité c'est dans toutes les directions.
Alors, allez vite contribuer et poster votre commentaire sur le document de l'ANSSI avant le 15 septembre. Dans 5 ans quand l'agilité sera devenue une évidence pour toute monde, vous pourrez dire "j'y ai contribué !".
Ne ratez pas non plus les "Assises de la sécurité 2017" qui auront lieu le mois prochain.
La conférence d'ouverture sera tenue par Guillaume Poupard, le Directeur Général de l'ANSSI qui "pitchait" cette semaine à l'université d'été du MEDEF pour rappeler aux patrons d'entreprises que la sécurité était d'abord leur sujet, avant d'être celui de leur RSSI.
Maintenant c'est au tour de ces RSSI de montrer qu'ils savent répondre aux enjeux d'agilité du business.