Le DevOps, symbolisé par le logo infini, comprend les activités permettant aux développeurs et administrateurs de collaborer de manière constante et itérative sur les développements, les tests, l’intégration en continu et la surveillance des applications. Ces modes d’organisation et d’outillage ont profondément bouleversé les pratiques des équipes de développement de production. Ces évolutions ne sont pas sans impact sur la sécurité.
Le DevOps, nouveau casse-tête des RSSI ? Pas du tout ! Pour s’en sortir, il suffit d’intégrer la sécurité au cœur du DevOps, et mettre en place une démarche DevSecOps.
Quels objectifs atteindre dans une démarche DevSecOps ?
L’objectif d’une démarche DevSecOps est au final d’aboutir le plus efficacement possible à un niveau de sécurité des applications adapté aux risques. Différents principes concourent à atteindre cet objectif en un minimum d’efforts :
Itératif
Selon les principes agiles, il est préférable d’échouer rapidement pour corriger rapidement. Par exemple une conception imparfaite est parfois plus efficace qu’une phase de spécification trop longue. Il faut donc évaluer le bénéfice de la conception par rapport au délai qu’il fait peser sur le projet. C’est ce qui conduit aussi à adopter une démarche itérative pour réévaluer régulièrement l’orientation du projet. En sécurité, cela pourrait se décliner par la planification de plusieurs itérations PDCA (Plan, Do, Check, Act). Ainsi des phases d’étude, d’audit ou de gouvernance peuvent s’entremêler tout au long du projet. Par exemple : réévaluation des menaces en phase de déploiement, scans de code récurrents dès le début des développements, plusieurs versions du dossier d’architecture en cours de projet ou réaliser des contrôles de conformités sur les composants techniques dès les phases de tests, etc.
Automatisé
Puisqu’on cherche à augmenter la fréquence des contrôles sécurité pour « itérer » dans le projet et sans augmenter la charge de travail associée, il faut outiller les contrôles pour rendre autonome l’équipe projet. Cela passe nécessairement par des indicateurs de suivi du projet ou des preuves de ces contrôles. Par exemple : participation à un comité d’architecture, rapport de scan, principes d’architecture conformes, modèles de configuration, spécifications « Access Management » et « API Management »… sont autant d’indicateurs du projet et sont souvent mesurables sans recourir systématiquement à l’équipe sécurité.
Il est également possible d’autoriser certains niveaux d’ouverture du service applicatif en fonction des résultats de ces contrôles de sécurité. Par exemple : ouverture en interne uniquement, livraison pour tests, restreint à une population pilote ou pour une durée limitée et sous réserve d’application d’un plan d’action.
En résumé, outiller et automatiser les contrôles permet :
- De rendre autonomes les équipes et ne plus les ralentir
- D’anticiper les actions des équipes
- D’augmenter la fréquence des contrôles pour une charge de travail équivalente ou inférieure et ainsi éviter des écarts importants entre deux contrôles de sécurité
Collaboratif
Pour que les contrôles de sécurité soient applicables il faut également identifier les différents fournisseurs du projet et leur niveau de responsabilité. Il faudra aussi pour cela déterminer par exemple si l’architecture est en partie on totalement « on premise » ou multi cloud. Il faut également établir avec les exploitants des équipements de sécurité et d’infrastructure (Access Management, APIM Management, Plateforme d’Intégration Continue, etc…) les besoins pour anticiper leur bonne utilisation.
Enfin, une organisation avec des responsabilités organisées et documentées aux différents niveaux ci-dessous permet de conserver la fluidité apportée par le DevOps :
- Responsabilité produit
- Responsabilité de l’architecture de développement
- Responsabilité du développement d’un composant
- Responsabilité des opérations
- Responsabilité de la qualité et des tests
Nos conseils pour mettre en place une démarche DevSecOps
Pour initier une démarche DevSecOps, il faut d’abord bien sûr comprendre les pratiques SecOps actuelles et essayer de répondre à quelques questions d’organisation :
- Comment évaluer les risques et suivre l’application des mesures dans un projet en évolution constante ?
- Quels outils et indicateurs partager pour rendre autonome l’équipe projet ?
- Comment automatiser les contrôles pour permettre à l’équipe projet d’anticiper ses plans d’action ?
En fonction de cette analyse des risques, des processus ainsi que des outils de sécurité déjà en place ou identifiés, il convient de prioriser les indicateurs à surveiller, les outils qui seront capables de les produire et les personnes qui seront responsables de suivre ces indicateurs. On peut alors les mettre en place et itérer une première fois en l’état et pratiquer l’amélioration continue. Pour pérenniser l’utilisation des outils de sécurité et les indicateurs qu’ils produisent, il faut ensuite définir les responsabilités autour de ces outils.
Un grand nombre d’outils est désormais disponible pour faciliter la mise en place du DevSecOps, notamment pour s’intégrer dans les outils « historiques » du DevOps mais aussi pour apporter de solutions nouvelles comme l’Attack Surface Management.
« Le train du DevOps est déjà bien en marche dans les entreprises, et les équipes sécurité doivent le rattraper, parfois à marche forcée ! Le DevSecOps propose des solutions simples et intégrées aux pratiques DevOps. Cerise sur le gâteau ? L’automatisation des contrôles de sécurité, propre au DevSecOps, est une réelle opportunité pour faire face à la pénurie d’experts sur le marché de la cybersécurité. Tout un écosystème de technologie (repositories, scanner, orchestrateurs, etc) est en train d’émerger. Il faut maintenant orchestrer leur utilisation pour une sécurité optimale et améliorée en continu. »
