À 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é.

Cet article Les Devops et l’Agilité : les pires ennemis de la Sécurité…ou pas ! (2/2) est apparu en premier sur iDNA.

L’Output de ces travaux se concrétise sur le plan opérationnel par un ensemble de procédures, best practices, kits de durcissements…mis en œuvre par l’entreprise. Celle-ci s’appuie alors sur ses fournisseurs et intégrateurs IT mais aussi sur des solutions techniques ad hoc (appelées alors Solutions de Sécurité). Ces mesures techniques (mais aussi organisationnelles) ont pour vocation de réduire les risques auxquels l’entreprise est exposée.

Ces dispositifs sont alors orchestrés par des mécanismes et des processus de supervision, de reporting et de gestion d’incidents dont le but est de contrôler l’efficience des mesures mis en œuvre et éventuellement les ajuster selon les résultats qu’elles auront réalisés. C’est ce qui est communément appelé cycle PDCA (Plan, Do, Check, Act), ou encore roue de Deming.

Cet article Les Devops et l’Agilité…les pires ennemis de la Sécurité…ou pas ! (1/2) est apparu en premier sur iDNA.