Les Devops et l’Agilité : les pires ennemis de la Sécurité…ou pas ! (2/2)

Nous l’évoquions dans un précédent article (les devops et l’agilité pires ennemis de la sécurité ou pas 1/2), Devops et agilité ne font pas forcément bon ménage avec la sécurité. Cependant, loin d’être une fatalité, cette opposition permet au métier de la sécurité d’évoluer avec le temps.

À l’image de l’essor de l’IT et de l’internet que le monde a connu vers la fin des années 90 et le début des années 2000, les métiers de la Sécurité font face aujourd’hui à des opportunités, mais aussi à des challenges de taille pour esquisser les traits d’une Nouvelle Sécurité agile et efficiente.

La prérogative essentielle de ce changement est de suivre la cadence à laquelle évoluent les besoins digitaux gouvernés par les méthodologies agiles.

Pour être plus précis, contrairement à l’approche historique où la Sécurité est une couche supplémentaire que l’on superpose à l’infrastructure technique et aux différentes procédures métiers, il s’agit désormais de s’inscrire de manière durable et efficace dans les cycles agiles des projets. C’est ici où le concept de Secure by Design prend tout son sens.

Pour être efficace et ciblée, la Sécurité ne peut plus se permettre de rester « la cinquième roue du carrosse » des projets techniques en se limitant à un ensemble de composantes fonctionnant de manière décorrélée, voire antagonique aux fonctionnalités métiers.

Les fonctionnalités, les architectures applicatives et les configurations de firewalls, waf, sondes, filtrage… doivent être pensées, conçues et mise en oeuvre non pas comme « composantes standards », mais en tant que moyens techniques adaptés à l’usage métier avec comme finalité la limitation de la surface d’attaque.

Adopter une approche “Secure by Design” consiste ainsi à intégrer les besoins et les outils sécurité dès les premières phases de définition des cahiers des charges des besoins et fonctionnalités. En particulier une évaluation une gestion des risques sécurité doivent être mises en place.

Concrètement, tous les Backlogs Scrum doivent impérativement permettre de vérifier les aspects sécurité qui y sont associés et y apporter les réponses techniques et procédurales. Cela doit se décliner de manière claire en termes d’actions et de plannings de livraison.

L’enjeu de cette approche est d’assurer l’efficacité et la réactivité requises par les cycles agiles courts. Pour ce faire, l’outillage technique de la sécurité, mais aussi la contribution des référents sur ce domaine doivent probablement être repensés et renforcés.

Dans le cadre collaboratif de DevOps, la sécurité est une responsabilité partagée, intégrée de bout en bout. Cet état d’esprit est si important qu’il a conduit certains à inventer le terme « DevSecOps » pour souligner la nécessité d’intégrer une base de sécurité dans les initiatives DevOps.

Sur le plan technique, à l’image de l’évolution, et (n’ayons pas peur de le dire) la révolution qui a bouleversé le monde de l’infra avec l’avènement de la virtualisation, du cloud et de la containérisation, les technologies de la sécurité devront faire preuve de plus de flexibilité et de capacité d’exécution via deux leviers principaux.

Interfaçage et interopérabilité :

Pour être agile, la Sécurité doit s’affranchir des contraintes d’infrastructure (qu’elle soit on-prem, cloud ou hybride…), mais aussi des technologies propriétaires qui peuvent devenir des freins aux changements et aux évolutions.

Plus que jamais, les technologies sécurité doivent s’inscrire dans une approche d’ouverture en s’orientant le plus possible vers du software-based, typiquement en exposant ses fonctionnalités via des API et des protocoles normalisés.

Automatisation :

L’intervention de l’humain devrait être réduite au minimum car c’est souvent le maillon qui introduit des délais supplémentaires de traitement, voire des risques d’erreur.

Ainsi, il faut généraliser l’usage des frameworks de développement sécurisé, des règles automatiques, des mécanismes de déploiement et de contrôles automatisés ainsi que les alertes et la visibilité (traçabilité) associées.

Naturellement, pour rester efficaces, les frameworks sécurité doivent être périodiquement mis à jour selon des processus préalablement établis. En somme, la sécurité doit devenir proactive en suivant les pratiques CI/CD tout en couvrant toutes les couches de l’OSI.

Le renouveau technologique de la Sécurité semble ainsi bien amorcé. Cependant, la Sécurité reste, « dans son ADN », un domaine assez rigide, ne serait-ce que par rapport aux normes qui le régissent (ISO 27001 par exemple). Ceux-ci sont souvent en décalage par rapport à l’aspect technologique qui a évolué à une cadence bien plus rapide.

Le nouveau vrai challenge de la sécurité sera peut-être celui d’une évolution de ses normes.

iDNA vous conseille et vous accompagne dans la conception et la mise en place de vos projets sécurité.