La tragédie de la sécurité meurt sur le creuset du DevOps

La sécurité n'est plus ce qu'elle était. Ou peut-être qu'elle a toujours été ainsi et qu'elle semble seulement différente en raison de l'érosion lente de mon idéalisme de jeunesse.

La sécurité se divise en deux. D'un côté, nous nous efforçons de protéger nos organisations. Arrêter les acteurs malveillants, protéger les données et les actifs, et défendre les utilisateurs contre les menaces et même contre leurs propres erreurs. De l'autre côté se trouve la conformité. Veiller à ce que l'organisation respecte les normes réglementaires, contractuelles et autres. Sur ces deux voies, nous gérons des risques : les risques de violation et d'interruption de service, ou les risques d'amendes réglementaires.

La tragédie de la sécurité est le reflet de la tragédie des biens communs. Selon Wikipédia :

L'essentiel de la conformité en matière de sécurité est conçu pour réduire le risque de sécurité. Du moins sur le papier. Mais au fil du temps, nous avons vu norme après norme, réglementation après réglementation, dissocier le risque de la conformité. La nature même des normes de conformité empêche les organisations d'adapter les mesures de sécurité à leurs risques propres. Je ne dis pas que c'est toujours le cas, mais c'est largement vrai, en particulier à mesure que l'on monte en échelle vers de grandes organisations. Rien ne prouve qu'exiger une réinitialisation des mots de passe tous les 90 jours pour des utilisateurs disposant de la MFA ou d'autres restrictions conditionnelles aujourd'hui courantes améliore la sécurité. La personne qui a inventé les exigences de complexité des mots de passe le regrette littéralement et affirme qu'elles ne fonctionnent pas. Il n'existe ni preuve ni fondement scientifique solide justifiant d'exiger le chiffrement non natif de tous les volumes de stockage chez un fournisseur cloud.

La sécurité est une ressource partagée et limitée. Nous ne disposons que d'un budget donné, d'un nombre donné de professionnels de la sécurité, et d'un temps limité que le personnel hors sécurité peut consacrer à la sécurité au détriment de ses autres objectifs. Plus nous tirons vers la conformité, moins il reste de cette réserve pour la sécurité. Moins la conformité s'aligne sur la sécurité, moins les efforts réduisent les risques de sécurité.

Voilà la tragédie de la sécurité. Nous avons dissocié le risque de la conformité, faisant du défaut de conformité le risque lui-même. Plus les risques réels sont dissociés de la conformité, plus le régime de conformité est rigide, moins il y a de ressources de sécurité disponibles pour la défense, et moins les autres équipes soutiennent les efforts de sécurité.

Un excellent exemple est ressorti d'une conversation avec Chris Farris. Pour le paraphraser :

Les développeurs se soucient bel et bien de la sécurité. C'est la conformité qui les irrite. Aidez-les à sécuriser leur application et ils vous soutiendront. Dites-leur d'accepter une interruption de 4 heures un week-end pour reconstruire leur base de données avec du chiffrement parce qu'un obsédé de la conformité l'exige, et vous ne faites que les exaspérer.

Je ne dis pas que toute la conformité se résume à des règles stupides, mais certaines règles de conformité le sont, et la mauvaise application de bonnes règles dissociées des risques l'est encore davantage.

Le DevOps devient le creuset de l'avenir de la sécurité, car dans le monde du cloud et du DevOps, chaque équipe applicative devient responsable de l'ensemble de la pile, y compris d'une grande partie de la sécurité. De nouveaux serveurs, réseaux et pare-feu ne sont qu'à un git commit et quelques appels d'API. Cela fait aussi peser une charge plus lourde sur ces équipes, qui doivent gérer leur propre sécurité et leur propre conformité. Nous conservons une sécurité centralisée et des ressources de sécurité partagées, mais lorsqu'il s'agit de la pointe de la lance, nous dépendons bien davantage des équipes DevOps. Nous ne pouvons pas créer une grande DMZ pour le cloud. Les frontières entre réseaux internes et externes ne peuvent plus être rangées dans des zones standardisées. De nombreuses applications bâties sur des services cloud natifs n'ont même plus de réseau et reposent sur des règles IAM et des politiques de ressources écrites en JSON, déployées par les équipes applicatives via l'infrastructure as code.

Ainsi, bon nombre de mes récents projets de conformité axés sur le cloud et le DevOps consistent d'abord à faire de la bonne sécurité, puis à trouver comment rédiger un rapport qui donne l'impression de respecter la lettre de la conformité alors que ce n'est pas le cas, même lorsque le résultat est plus sûr.

Il existe deux solutions possibles.

La première consiste à réviser les normes de sécurité pour qu'elles s'adaptent mieux au cloud et au DevOps et à réduire le nombre de règles stupides ou inapplicables. Ce travail est en partie engagé, mais j'en suis venu à penser qu'il exige un changement générationnel que nous n'avons pas le temps d'attendre. N'abandonnons pas, mais n'attendons pas non plus.

L'autre consiste à recourir à l'automatisation pour retirer aux individus une part aussi grande que possible de la charge de sécurité et de conformité, tout en leur laissant la liberté et le contrôle nécessaires pour construire vite. Je ne suggère pas que la réserve globale de sécurité se réduise, mais que nous utilisions l'automatisation et d'autres technologies pour diminuer l'obligation individuelle de consacrer du temps aux choses les moins utiles.

Tout est question de temps et de concentration de ressources limitées. Et au fond, qu'est-ce qui a le plus de valeur : un bon test d'intrusion ou un audit de conformité ? Regardez maintenant combien vous dépensez en tests d'intrusion et combien vous payez pour un audit.