Jordan Assouline, formateur et expert en cybersécurité, en est convaincu, la sécurité informatique est indispensable et peut être plus simple à déployer que ce que l’on pense. C’est ce qu’il démontre avec son livre « DevSecOps – Développez et administrez vos services en toute sécurité » sorti aux Editions ENI ces derniers jours. Entretien.

Jordan Assouline : C’est plutôt une philosophie ou une culture qui essaie de casser les silos qui peuvent exister entre les métiers de développeurs, de sécurité et d’opérationnel.

J’entends par ce dernier terme toutes les personnes qui vont pouvoir fournir ou aider à fournir les supports matériels et logiciels sur lequel les développeurs vont pouvoir travailler. Par exemple quand un développeur travaille sur un site web, il va falloir l’héberger sur un serveur. Et ceux qui se chargent de ça, ce sont les opérationnels, les Ops.

Le DevSecOps a donc pour but que ces trois rôles n’en forment plus qu’un dans les organisations. C’est un très court résumé bien sûr, dans le livre cela prend 600 pages  !

JA : Excellente question qui fait aussi débat ^^ Je pense qu’un DevOps qui fait bien son travail et donc va vouloir mettre en place de la sécurité aura potentiellement du mal à atteindre le niveau attendu. Il faut ajouter des choses. On peut comparer avec Linux où il y a un noyau avec des éléments qui gravitent autour : DevOps est le socle et la sécurité vient se greffer par-dessus à chaque étape.

Dans le DevOps, il y a des piliers sur lesquels tout le monde est d’accord, les CALMS pour Culture, Automatisation, Lean, Mesure et Partage. Et dans la culture, il faut intégrer la sécurité, dans le Lean aussi, l’automatisation aussi… La sécurité permet d’exacerber certains aspects qui méritent un traitement plus approfondi.

Quelqu’un qui est DevOps aura du mal à aller au bout de toutes ces démarches car cela demande de la transmission et des connaissances que tout le monde n’a pas. Mais c’est facile à acquérir quand on a envie et c’est ce que j’essaie de démontrer dans le livre. On peut passer de DevOps à DevSecOps sans avoir fait 5 ans d’études en sécurité !

JA : Par exemple. Les pratiques de développement doivent aussi être changées pour qu’elles soient sécurisées. Et le SDLC qui est une méthode particulière de construction du logiciel doit s’imprégner de sécurité, ce que l’on nomme SSDLC.

De la même manière, sans changer fondamentalement les choses, on injecte de la sécurité partout, plus de matière et de contenus.

Cela a créé un débat car, il faut se dire les choses, rajouter ces étapes fait perdre du temps pendant la phase de développement. Mais cela en fait gagner pour les étapes en aval. Et par rebond, c’est une méthode qui fait gagner de l’argent, en évitant les attaques, et fait monter en compétences et responsabilité les équipes. Des bénéfices donc humains, techniques et économiques, ce n’est pas mal, non ?

Le Security Champion ne doit pas être un recrutement externe

JA : Par expérience, deux choses fonctionnent bien.

La première ne va pas plaire à tout le monde mais cela fonctionne : il faut que cela soit du « top down ». Si l’initiative vient des techs et non du top management, en général, cela n’aboutit jamais. Bien sûr, il y a des exceptions.

À l’inverse, quand ces actions ruissellent du top management aux techs, la plupart du temps c’est plus efficace.

La deuxième chose ce sont les actions parmi lesquelles la diffusion de la culture sécurité va être importante. Et pas que pour les techs, pour toute l’entreprise. Cela peut être par des actions basiques comme celles relatives à la gestion des mots de passe ; ou à la mise en œuvre d’une charte informatique dans l’entreprise.

Ensuite, dans l’idéal, il faudrait une personne, le coach DevSecOps, dont le rôle va être d’aider tout le monde, d’être support. Enfin, il faut des outils qui vont pouvoir faciliter l’adoption de la sécurité par tous les intervenants. Il faut donner envie.

La dernière action, fondamentale et peut-être la plus importante, est la mise en place de « Security Champions » au sein des équipes (front, back, bdd, ops, réseau, …), un promoteur du sujet qui va évangéliser ses collègues. Déjà en montrant par l’exemple avec la mise en place d’actions qui vont aider les développeurs et opérationnels. Mais aussi en étant en contact avec les Security Champions des autres équipes. Ce qu’il est important de comprendre, c’est que le Security Champion n’est pas un recrutement externe. C’est un membre de l’équipe que l’on va accompagner, former, faire monter en compétences. Cela limite les freins vis-à-vis de ses collègues.

Avec tout cela, une entreprise lambda, sans beaucoup d’investissements, va pouvoir mettre en place beaucoup d’actions de sécurité efficaces. Je souligne d’ailleurs dans mon livre de nombreuses solutions Open-source pour que cela soit très accessible.

JA : Ce sont deux « caisse-à-outils » des DevOps. Quasi tous doivent les connaître et les utiliser, sans forcément en être un expert. Et la raison, même si là encore ça ne va pas plaire, est qu’ils ont été faits par et pour les développeurs mais beaucoup utilisés par les opérationnels.

L’idée de base fonctionne sauf que pour faire de la conteneurisation, on utilise des serveurs, une infrastructure. Et les développeurs, soit n’ont pas la main sur ces équipements, soit n’y sont pas à l’aise. Il a donc toujours fallu que les opérationnels et les développeurs collaborent efficacement sur ces outils. Kubernetes est arrivé par-dessus pour orchestrer le fonctionnement de tout ça quand il y a beaucoup de conteneurs hébergés sur de multiples serveurs.

Dans le livre, je montre donc comment utiliser Docker et Kubernetes avec ces aspects sécurité grâce à des outils open-ource et gratuits.

JA : Quand vous développez en langage haut niveau, vous utilisez systématiquement des librairies disponibles sur Internet. Et c’est normal, si quelqu’un a déjà fait ce que vous voulez faire et qu’il a mis à disposition son code… GAFAM mises à part (et encore…), tout le monde fait ça.

Sauf que beaucoup d’études ont démontré que ces librairies open-source comportent plein de failles de sécurité. Non pas parce qu’elles ont été mal développées mais parce qu’elles ne sont pas mises à jour, les bénévoles derrière n’ont pas toujours le temps de les laisser up-to-date. Et comme de nouvelles vulnérabilités apparaissent… Je montre dans le livre quelques outils qui permettent de vérifier que les librairies ne sont pas trop faillibles.

DevSecOps : l’outil parfait n’existe pas

JA : Oui, et même le faire repasser régulièrement. Car même une fois le projet déployé de manière sécurisé, de nouvelles vulnérabilités peuvent apparaître. Il faut régulièrement faire des analyses. Cela fait partie du cycle de vie du Logiciel qui doit être réactualisé très souvent.

JA : Il faut voir la chose sous deux angles.

Le nombre d’attaques est surtout plus visible. Avant, c’était le challenge technique qui attirait beaucoup les pirates. Aujourd’hui, ce n’est plus vrai et les groupes d’attaquants peuvent être financés avec des sommes assez importantes ce qui leur permet d’avoir plus d’impact lors des attaques.

Mais l’outil parfait n’existe pas. Et l’outil n’est pas un but en soi, il est là pour apporter du support. Qui plus est, il faut être capable d’en exploiter les fonctions. Comme avec une voiture par exemple, certaines entreprises vont acheter des gros modèles surtout… pour montrer qu’elles ont un gros modèle ! Mais elles n’ont pas forcément le personnel pour l’utiliser et être capable de traiter les informations que ces outils envoient. Et ils en envoient beaucoup, notamment des faux positifs. C’est normal. Ce type d’outil « s’éduque » mais pour faire cela il faut du personnel qualifié. Et ce type de profil n’est pas facile à trouver.

Donc, je ne pense pas que commencer un changement par l’achat d’outils sophistiqués soit la bonne méthode. Il faut d’abord changer la culture puis se pencher sur l’outillage pour accélérer ou supporter ce changement.

JA : Oui. Le DevSecOps n’est pas adapté à toutes les entreprises.

Un des objectifs du DevOps est de se dire que lorsque l’on développe quelque chose, il doit être mis très vite à disposition des utilisateurs finaux. Ce qui veut dire qu’il faut pouvoir déployer souvent de nouvelles versions. Netflix le fait plusieurs milliers de fois par jour par exemple ! DevOps est là pour montrer des pratiques et outillages qui permettent ce rythme tout en restant fonctionnels.

Mais toutes les entreprises n’ont pas besoin de déployer à une fréquence soutenue. D’autant que cela demande une montée en compétences des équipes, de l’outillage, de l’argent, l’acceptation du risque – plus vous déployez, plus le risque est important-…

JA : C’est une volonté de ma part. Je voulais montrer que ce n’est pas si compliqué de mettre en place des outils open-source pour faire des analyses de vulnérabilité par exemple. Mais surtout, je voulais montrer que ce n’est pas si compliqué que cela de les corriger. Sur le Web, on trouve des explications sur comment on utilise un outil et des informations éparpillées partout sur les vulnérabilités qui n’expliquent pas souvent comment les corriger.

En détaillant ainsi, je voulais souligner la démarche : comment on met en place l’outil, comment on analyse les résultats et comment on corrige. C’est tout le cycle de vie. Et on le trouve peu sur Internet car on valorise beaucoup la détection mais peu la correction. Alors que c’est fondamental. C’est l’opposition Red Team vs Blue Team, attaquants contre défenseurs. Même dans l’imaginaire collectif, les attaquants sont toujours plus valorisés.

JA : Ce fut exigeant de ma part. J’ai dû réfléchir pour expliquer et transmettre des choses que je fais naturellement, quotidiennement. Ce n’est pas évident. Cela m’a amené des questions sur mes propres pratiques.

L’autre point qui m’a pris du temps est que j’ai détaillé l’ensemble des étapes. L’idée était qu’un non connaisseur puisse reproduire les actions. Pour comprendre c’est autre chose bien sûr mais cette approche était importante pour moi.

Et puis il faut vérifier que tout est bien correct, pas seulement donner des conseils. J’ai testé beaucoup d’outils, bien plus forcément que ceux que j’ai retenus dans le livre.