Projets

DevSecOps : des RSSI témoignent

Benoît Fuzeau, RSSI de la Casden : « Il est important que les développeurs et le RSSI puissent se parler. »

A l'occasion de la quatrième conférence Devops Rex, le 17 octobre 2019 à Paris, le RSSI de la Casden et la RSSI adjointe de JCDecaux ont partagé leur expérience autour de la démarche DevSecOps.

PublicitéL'approche DevOps, qui vise à rapprocher les mondes du développement et de la production, fait de plus en plus d'adeptes. Selon IDC, un projet applicatif sur cinq s'inspire de cette démarche dans les entreprises françaises en 2018, une part qui devrait continuer d'augmenter pour atteindre 35 à 40% des projets en 2021. Signe de cette adoption croissante, le succès grandissant de la conférence Devops REX, qui a accueilli cette année plus de 20 intervenants sur 17 sessions. Durant l'événement, DevSecOps était à l'honneur. Cette évolution de DevOps, qui intègre les équipes de sécurité dans les projets, a fait l'objet d'une série de témoignages. Parmi ceux-ci, deux interventions de RSSI, venus expliquer la valeur apportée par cette démarche.

Aider la sécurité à revenir au coeur des projets

Benoît Fuzeau est le RSSI de la Casden Banque Populaire, la banque coopérative de la fonction publique. Il a découvert DevSecOps à l'occasion d'un projet inscrit sur la feuille de route numérique de l'entreprise, l'import de pièces justificatives en ligne. « Pour moi, ce projet a été un déclic. La sécurité a l'habitude d'effectuer des analyses de risques sur quatre grandes dimensions : la disponibilité, l'intégrité, la confidentialité et la notion de preuve. En prenant ces sujets en amont, nous avons pu identifier certains enjeux très tôt et aider l'équipe de développement à trouver des solutions », raconte le RSSI. Pour réduire par exemple le risque d'interruption de service lié à l'import simultané d'un trop grand nombre de documents, il a suffi de prévoir une limite sur la quantité de pièces pouvant être transmises en même temps. De la même façon, quelques lignes de code ont permis de vérifier de façon simple l'intégrité des documents PDF envoyés. Auparavant, les collaborateurs chargés de la sécurité étaient fréquemment sollicités en fin de projet, ce qui se traduisait souvent par des compromis et des ajouts de dernière minute, compliqués à maintenir et complexes à déployer. « DevSecOps permet aux femmes et aux hommes de la sécurité de revenir dans les équipes projets et de se faire entendre », souligne le RSSI. « C'est aussi un moyen de réunir les équipes IT et de parler le même langage. » Benoît Fuzeau tient au passage à dénoncer un cliché qui a la vie dure « Ce n'est pas vrai que la sécurité dit toujours non : pour nous aussi, la priorité c'est le métier. »

La sécurité peut également apporter de bonnes pratiques aux développeurs. En se familiarisant avec la plateforme de gestion de code GitHub, souvent utilisée pour partager des projets avec la communauté, le RSSI a par exemple constaté que certains contributeurs laissaient des données clients apparentes dans leur code. Un hacker éthique lui a également montré qu'il était facile pour des pirates de se servir du code publié pour dissimuler des programmes malveillants, en exploitant les techniques d'obfuscation de code, des risques auxquels les équipes de développement ne sont pas forcément sensibilisées. « De notre côté, nous pouvons nous aussi profiter de l'expertise des développeurs, pour nous aider par exemple à intégrer différents outils de sécurité à l'aide d'APIs », conclut Benoît Fuzeau.

PublicitéAdopter la « security by design »

Peu de temps après, Joy-Alexandra Denis, RSSI adjointe chez JCDecaux, groupe spécialisé dans la publicité urbaine, est venue raconter le voyage de leur DSI vers DevSecOps. Tout a commencé en 2018, lors d'un atelier sur DevOps. Dès le départ, cette initiative obtient un fort soutien du management. L'entreprise décide d'axer sa démarche DevOps autour de cinq objectifs : des applications qui se réparent toutes seules, des tests automatisés, des responsables de produits (products owners) capables de livrer en toute autonomie, des équipes techniques (feature teams) capables de gérer les incidents en dehors des heures ouvrées et enfin la capacité à créer des infrastructures sans avoir besoin d'ouvrir des tickets. « Dès la mise en place de DevOps, nous avons observé une diminution drastique du nombre d'incidents en production », relate la RSSI adjointe. Lors du premier atelier DevOps de 2019, les 5 membres du département sécurité rejoignent la démarche. « Nous envisagions de créer une core team, afin de promouvoir la culture DevOps, de tester de nouveaux outils et procédures... Au moment de décider qui devait intégrer cette équipe, la sécurité a spontanément été citée », témoigne Joy-Alexandra Denis.

Joy-Alexandra Denis, RSSI adjointe, JCDecaux :« Nous sommes passés d'un rôle de validateur à un rôle de conseil. »

Rapidement, la sécurité identifie une première action de sensibilisation à mener, ciblée sur les product owners. « Ces derniers font le lien entre les métiers et les équipes techniques. Ils sont au coeur de la démarche DevSecOps. » L'enjeu était notamment de montrer l'intérêt d'intégrer la sécurité dès le début des projets, plutôt que de faire appel à elle deux jours avant la date prévue pour la livraison. « Nous sommes passés d'un rôle de validateur à un rôle de conseil, dans lequel nous aidons les équipes à choisir la solution la mieux adaptée. » De cette façon, la feuille de route des projets intègre des jalons centrés sur la sécurité : analyse de risques au démarrage, recommandations en phase de design, et enfin vérifications avant la livraison.

Afin d'aider les équipes de développement à adopter les principes de « security by design », le département de sécurité a établi 11 règles d'or. Celles-ci permettent de formaliser des bonnes pratiques de base, comme l'usage de l'authentification forte, du protocole HTTPS, les règles pour écrire du code sécurisé ou encore les tests de sécurité... « Nous avons également beaucoup misé sur la communication. Quand les tests de sécurité ne sont pas bons, nous faisons une restitution précise à l'équipe, associée si nécessaire à une démonstration. Nous envoyons également un mail groupé quand l'application est validée, pour que tout le monde, y compris la production, soit au courant que la sécurité a vu l'application », souligne la RSSI adjointe. Des petits détails, mais qui mis bout à bout représentent un gain de temps pour tout le monde.

Inclure la sécurité dans le processus d'intégration continue

Aujourd'hui, l'objectif est d'intégrer la sécurité dans les pratiques quotidiennes, en s'appuyant sur l'automatisation. Pour cela, JCDecaux a choisi de désigner dans les équipes DevOps des champions de la sécurité, sensibilisés aux règles d'or précédemment décrites. Ces champions sont les interlocuteurs privilégiés du département sécurité : ils relayent les actions, tiennent l'équipe de sécurité informée des nouveaux projets et testent les nouveaux outils. Parmi les solutions déjà mises en place figure sonarqube, une solution d'analyse statique de code Open Source, qui permet d'identifier des bugs et des failles de sécurité en lisant le code. L'outil a été personnalisé avec les équipes de développement, afin de s'adapter à leurs besoins : le nombre de règles a été ramené à une centaine, avec trois profils de qualité. Ces derniers permettent de définir des seuils précis, que les applications doivent respecter pour obtenir le feu vert de la sécurité.

Ensuite, sonarqube a été intégré dans le processus de livraison. « Nous lançons l'analyse depuis Jenkins, au moment du merge », explique Joy-Alexandra Denis. Le code est ensuite testé avec le profil correspondant : si des problèmes sont détectés, la sécurité accompagne l'équipe de développement. « Récemment, nous avons divisé le nombre de vulnérabilités par deux en une réunion », illustre Joy-Alexandra Denis. En conclusion, la RSSI adjointe a souligné l'importance du reporting, qui permet de traduire de manière concrète les bénéfices de la démarche DevSecOps. « Nous avons par exemple un tableau de bord qui recense les vulnérabilités les plus fréquemment rencontrées. Celui-ci nous permet d'identifier soit des faux positifs, qui nécessitent de revoir les règles, soit des sujets sur lesquels les développeurs ont besoin d'être davantage formés ou sensibilisés. »