Security Champions - Pourquoi ? Pour qui ?

0:12 Bonjour à tous et ravi de vous retrouver aujourd'hui, de vous rencontrer, de vous retrouver pour certains. Je suis ravi de vous partager ce workshop avec vous. On va parler des Security Champions aujourd'hui. Je m'appelle Gérald Cression et je suis ravi de vous rencontrer. Alors, quelques mots à propos du programme. On va commencer par des éléments de contexte. Revoir quelques fondamentaux que vous connaissez certainement, qui sont les raisons pour lesquelles c'est important d'augmenter notre empreinte de sécurité dans nos organisations, avec les différentes, les récentes évolutions qui ont pu arriver. Et puis on va se demander comment on peut faire pour augmenter cette empreinte de sécurité. Et bien évidemment, la solution que je vous propose, c'est les Security Champion Program. Donc on va voir ensemble d'abord qu'est-ce que c'est, comment on peut le définir, et puis surtout, très très opérationnellement, on va voir comment ça marche, comment on peut monter un programme, qui on doit recruter, comment on peut animer, comment on doit récompenser, qu'est-ce qu'on doit leur enseigner. Voilà, plein de clés opérationnelles. J'espère que vous ressortirez de là avec des outils qui vous permettront véritablement, pourquoi pas, de mettre ça en place dans vos organisations.

1:19 Je l'ai appelé« Pourquoi, pour qui? » ce workshop. J'aurais dû l'appeler« Pourquoi, comment? » en fait, parce que c'est pour tous et qu'on va être vraiment très, très, très, très opérationnel. Et en fin de session, je vous remercie. Je vous donnerai quelques liens vers des ressources complémentaires qui pourront vous aider à poursuivre la réflexion si ça vous aide. Avec quelques mots à propos de moi et surtout à propos de nous. Je m'appelle Gérald Christian, comme je vous le disais, et je fais partie de l'équipe Developer Relations et Communauté chez SNIC. Alors certains d'entre vous me diront, mais qu'est-ce que c'est que SNIC? On n'est pas encore très très connu. SNIC, c'est une plateforme à destination des développeurs et des équipes sécurité, qui est là pour sécuriser l'ensemble de vos applications. Sur l'ensemble de leurs étages. Donc ça démarre par votre code maison, votre code source. Toutes vos librairies tiers, toutes vos dépendances sur lesquelles vous vous appuyez. Puis tout à l'heure, j'utiliserai l'image de l'iceberg. On verra un peu visuellement que ça représente quand même beaucoup. Vos images Docker, évidemment. Et puis pour finir, la couche infra, aussi bien sur la partie config, terraform, files, que...

2:23 Déploiement cloud. SNIC c'est une solution qui a vraiment été pensée pour les développeurs dans le sens où on est dans la philosophie shift left appliquée à la sécu quoi donc on met la sécurité dans les mains des développeurs et on fait en sorte que dans leur quotidien ça s'intègre facilement dans leur workflow, dans leur environnement de travail concrètement ils peuvent avoir des plugins sur leur VS Code en fait pour directement lorsqu'ils codent voir des failles, il y a des webbooks sur leur repo git ils peuvent le mettre en pipeline voilà parce que c'est utilisable en CI, voilà. Puis c'est aussi accessible avec une web UI relativement simple et visuelle avec des dashboards, etc. Voilà. On va tout de suite enchaîner sur les fameux éléments de contexte dont je parlais tout à l'heure et voir pourquoi il faut augmenter notre empreinte sécurité. Alors, on le sait, il y a eu beaucoup d'évolutions dans notre domaine récemment. Une qui n'est pas si récente que ça, mais qui a eu un gros impact, c'est le cloud native. Le cloud native a vraiment changé la donne, en fait, dans le sens où le cloud native associé à la philosophie DevOps, qui décloisonne les fonctions entre Dev et Ops, finalement,

3:31 l'impact que ça a, c'est que les développeurs ont beaucoup moins de dépendance à d'autres équipes dans l'organisation. Je pense notamment aux équipes Ops et aux équipes Sécu, en fait. Avant, les développeurs s'occupaient essentiellement de leur code source et puis éventuellement des librairies tierces sur lesquelles ils s'appuyaient. Et puis le reste du stack, c'était géré par des équipes IT ou des équipes plateforme. Et puis quand on avait besoin de quelque chose, on ouvrait un ticket, il y avait quelqu'un qui allait ouvrir un port, reconfigurer un réseau, etc. Bon, évidemment, tout ça a volé en éclats. Aujourd'hui, on déploie à vitesse grand V plusieurs fois par jour, on déploie en continu. La plupart des interactions, c'est managé par des API. Nos cloud providers nous proposent des centaines de services pour configurer du réseau, scheduler des containers, j'en passe et bien d'autres. Donc en fait, de facto, le paysage d'intérêt... des développeurs, c'est élargi.

4:32 Alors tout ça, ça dépend évidemment beaucoup du niveau de maturité des différentes organisations, mais de façon générale, on peut s'accorder à dire que le paysage des développeurs n'est plus du tout le même qu'avant, et ils interagissent sur bien plus d'aspects qu'avant. Et la vitesse à laquelle ils vont aussi. Et tout ça, ça nous oblige évidemment à repenser la façon dont on doit gérer nos risques et notre approche sécurité. Alors on ajoute à ça évidemment une tendance... Une lame de fond, une tendance révolutionnaire. On voit bien qu'il y a de plus en plus de développeurs qui aujourd'hui utilisent l'intelligence artificielle pour générer du code. Et c'est normal, c'est génial. On gagne du temps, on gagne en réactivité, ça peut corriger plus vite certaines erreurs. Donc c'est vraiment très intéressant en fait. Mais bien évidemment, tout ça ajoute au contexte de complexité et puis au risque de sécurité. Je ne rentre pas dans le détail là-dedans, mais on a pas mal de workshops et de vidéos sur lesquels on parle vraiment de l'impact de l'AI dans la sécurité.

5:35 Et c'est vrai que c'est un sujet infini, en fait. Un petit ratio pour finir, on le sait, il n'y a pas assez d'équipes de sécurité. On parle d'un ratio de 1% en moyenne. C'est-à-dire que concrètement, sur une équipe de 100 devs, en général, on a 10 profils OPS et une personne véritablement dédiée sécurité. Ça veut dire quoi? Ça veut dire que finalement, la sécurité, elle est en sous-effectif, elle est en sous-nombre, elle est complètement impossible pour elle, c'est impossible pour elle de suivre tout ce qui se passe. Et quand on est en telle infériorité numérique, on ne peut que se limiter à faire des vérifications de conformité, de compliance. C'est hyper frustrant. En plus, tout le monde déteste la sécurité, donc c'est chiant. Non mais parlons vrai quoi. Donc ça ne marche pas en fait. Et donc il faut se caler les équipes de sécurité. Si on n'intègre pas la sécurité avec des automatisations et directement dans le workflow des développeurs au quotidien, En fait, c'est impossible de suivre. Donc, on passe dans une ère qu'on appelle l'ère du DevSecOps.

6:35 On connaît tous le DevOps. Le DevSecOps, c'est l'extension naturelle du DevOps au paysage de la sécurité. Donc, cette fameuse philosophie chiffre-lève dont je parlais tout à l'heure. Et la question, c'est comment on donne les moyens aux développeurs, finalement, de contribuer à la prise en charge de la sécurité? Et là, évidemment, la réponse, la révélation, c'est les Security Champion Program. Alors, finalement, qu'est-ce que c'est un programme de Security Champion? Si on cherche une définition officielle, voilà ce qu'on peut trouver. C'est un mécanisme de communication efficace pour partager de la connaissance et collaborer entre des équipes dev et des équipes sécurité. Donc on brise les silos, comme dans Dev et Ops. Maintenant, si on se le dit un peu plus en français courant, et pour ceux d'entre vous qui sont peut-être des responsables sécurité dans l'organisation, les Security Champions, ce sont vos relais de communication. C'est eux qui, au quotidien, dans les équipes, vont rappeler les consignes, vont rappeler les bonnes pratiques, les policies, etc. C'est vos yeux et vos oreilles.

7:37 C'est eux qui vont vous faire remonter l'information quand, à un moment donné, il y a un nouveau projet qui se lance et que ce serait peut-être intéressant d'aller participer à une réunion pour regarder les schémas d'archi, etc. C'est vos avocats, c'est votre voix, c'est eux qui, dans les réunions de dev, vont lever la main en disant« Vous êtes sûr que vous voulez le faire comme ça? » Peut-être pas une très bonne idée. Leur job n'est pas de devenir des responsables. en tant que telle, mais ce sont des portes-drapeaux, des relais de communication. C'est une véritable collaboration qu'on a avec eux, en partenariat avec les équipes sécurité. Alors on va regarder tout de suite comment on construit et on anime un programme de Security Champion. Juste quelques mots pour rendre hommage à une personne qui s'appelle Tania Jankak, vous connaissez peut-être. Elle anime une communauté qui s'appelle We Hack Purple, elle est basée au Canada, elle fait du training de sécurité. Et je me suis pas mal inspiré de ses travaux en fait pour construire ce talk. Donc voilà, je voulais juste le mentionner par probité et puis parce qu'elle est super. Donc je vous engage aussi à la découvrir.

8:39 Allez, on commence par des prérequis. Je vais y aller un peu au pas de charge parce que j'ai pas mal de contenu à délivrer. Il y a deux prérequis essentiels quand on construit un programme de Security Champion. Le premier, c'est de demander leur avis aux développeurs, évidemment. Si on veut qu'ils soient impliqués, si on veut qu'ils adhèrent au programme, il faut tout de suite les impliquer dès le départ. Donc, demandez-leur de quoi ils ont besoin. Demandez-leur, mais qu'est-ce qui te gêne au quotidien? Comment est-ce que je peux t'aider à faire ton boulot de la façon la plus sécurisée possible? Comment est-ce que je peux t'aider? Il faut vraiment voir ce programme comme une façon de leur apporter de la valeur, en fait, sous l'angle de vue du développeur. On peut aussi leur rappeler que le but du jeu, au bout du bout, c'est aussi de leur amener un peu plus d'autonomie et un peu plus de vélocité. Donc ça, ça leur... Parle concrètement donc. Essayons de prioriser aussi nos actions en fonction de leurs besoins. C'est vraiment un prérequis essentiel. Le second prérequis, c'est qu'un programme de Security Champion, il faut que ce soit officiel et reconnu dans l'organisation.

9:43 Parce que ça va leur prendre du temps, en fait, à vos Security Champions de s'occuper de ça. Ça ne va pas leur prendre tout leur temps, mais une partie de leur temps. Et donc, il est hors de question que ça impacte, en fait, leurs objectifs perso. Où, voilà, évidemment, ils vont être capables de délivrer un peu moins parce que c'est du temps qui passe ailleurs. Il faut que tout le monde soit... au clair là-dessus dans l'entreprise. Il faut que le management soit au clair et qu'il soit OK avec ça, qu'il adhère au projet, qu'il lui apporte du support, voire même qu'il le sponsorise. C'est-à-dire qu'en fonction des organisations, si vous avez des CISO, des VP sécurité, des VP engineering, même des CTO, il faut que vraiment ces gens-là soient à bord avec vous quand vous construisez ces programmes-là, et voire même que l'un d'entre eux soit sponsor officiel, entre guillemets, en interne du projet. Pour le middle management, c'est pareil, les chefs d'équipe. Ils ont leurs coéquipiers qui vont passer un peu plus de temps à faire ça. Donc eux aussi, il faut qu'ils soient totalement en support de ça et que ça ne pose de problème à personne. C'est vraiment un prérequis essentiel. Alors on a nos prérequis, on va se poser la question de comment recruter en fait nos security champions.

10:48 Et là il y a une règle d'or, on les recrute, on recrute des volontaires, on ne les nomme pas. Si vous les nommez, si vous dites tiens, toi tu vas être security champion, ça ne marche pas. C'est une corvée, ils ne vont pas faire le job, ils vont mal le faire. On recrute véritablement des volontaires, des gens qui ont envie. Et donc pour ça, il faut attirer les bonnes personnes. C'est qui les bonnes personnes finalement? On peut se poser la question. Les bonnes personnes, c'est ceux qui s'intéressent au sujet, c'est ceux qui posent des questions, c'est ceux qui fixent des bugs, c'est ceux qui font des formations à côté, c'est ceux qui achètent des livres, c'est ceux qui en parlent, c'est les gens qui sont véritablement intéressés par le sujet. Et bien évidemment, il faut que ce soit des développeurs. C'est-à-dire que vraiment, le but du jeu, c'est de faire de la... avec les développeurs. Donc prenons nos champions dans les équipes de dev. Alors comment on les attire ces volontaires? Il faut créer des opportunités, il faut créer des opportunités de rencontre et là il faut être un peu créatif. Il y a plein de manières de le faire, il y a des manières ludiques, on peut organiser des catch de flag par exemple avec eux, ça c'est plutôt sympa.

11:50 Tout le monde sait ce que c'est un catch de flag? Un catch de flag, c'est un espèce de challenge où tu passes d'énigme en énigme. En général, ce sont des énigmes sécurité que tu dois résoudre, qui sont plus ou moins complexes. Et puis à chaque fois que tu résous une énigme, tu gagnes des points. Il y a un leaderboard, celui qui en arrive au plus ou le plus vite gagne plus de points. Et à la fin, il y a en général quelques cadeaux, des choses comme ça. Donc c'est plutôt sympa, c'est une manière très ludique de mettre la sécurité dans les mains des développeurs, sans grosse prise de tête en fait. Donc on peut organiser des catch de flag, c'est plutôt sympa, il y en a plein en ligne, vous n'êtes pas obligé de créer les énigmes de sécurité vous-même, c'est une bonne manière d'attirer les bonnes volontés. On peut organiser des jeûnés thématiques aussi, comme des lunch and learn, vous prenez un sujet sécurité, vous dites tiens aujourd'hui on va parler sécure, c'est quoi du cross-site scripting, boum. Et on commande des pizzas et on amène les développeurs et puis pendant un déj, le temps d'un déj, on expose, on fait un petit meet-up interne. Et là, on voit qui vient, qui pose des questions, qui s'intéresse.

12:52 Tout ça, c'est vos futurs champions. On peut aussi... Moi, j'ai vu des gens qui mettaient dans leur signature mail... dans leur status lac, je cherche des security champions. On diffuse la parole, on diffuse le mot, soyez créatifs, à la guerre comme à la guerre, tous les moyens sont bons. Et puis après, en tant qu'équipe sécurité, on peut aussi changer un petit peu notre narratif, être un petit peu moins directif, peut-être un petit peu plus orienté service pour donner envie. C'est vrai qu'on a souvent tendance à dire, si tu ne fais pas ça, ça ne passe pas en prod. Et c'est vrai qu'en fait, c'est important. Mais on peut aussi essayer d'être un peu plus ouvert, de dire, tiens, comment est-ce que je peux t'aider? Répondre à des questions, donner envie d'adhérer au sujet, d'adhérer au projet et prendre du temps pour les développeurs. Bien. Alors maintenant qu'on a nos volontaires, on va se demander comment on démarre. Et c'est vrai que c'est une question qu'on se pose souvent en fait, par où commencer.

13:56 Alors je l'ai dit tout à l'heure, l'important c'est d'impliquer les développeurs dès le départ. Il y a un super outil pour faire ça, c'est les scorecards. Vous faites des scorecards en entreprise et en fait ce sont des auto-évaluations où ça va vous permettre de voir un peu où ils en sont sur les processus, les bonnes pratiques, les tests qui sont mis en place, etc. D'équipe en équipe. On s'apercevra que d'une équipe à l'autre, les niveaux de maturité ne sont pas les mêmes. Et c'est normal, ça s'appelle la nature humaine. Mais ces scorecards, ça permet de lancer une... En plus de cette espèce d'audit, ça permet de lancer une bonne dynamique d'introspection et de prise de conscience chez les développeurs. Donc c'est une bonne chose. Alors dans la scorecard, on met toute une liste de questions sur les process, les tests, les bonnes pratiques qui sont en place. C'est bien que les développeurs, ce soit eux qui lient de ce sujet aussi, qu'ils se l'approprient. Ça ne veut pas dire qu'on ne s'en occupe pas. On se met d'accord avec eux pour définir la liste de questions, être sûr que ce soit eux qui l'ont fait.

15:00 soit bien complet, et puis surtout on fait en sorte que les scorecards soient toutes les mêmes d'équipe en équipe. Parce que ça va nous resservir derrière quand on va mesurer les progrès. Et pour mesurer des progrès, il faut qu'on soit capable de comparer des choux avec des choux, ou des pommes avec des pommes. Donc il faut de l'homogénéité. Et puis c'est bien aussi d'avoir une image d'où on se trouve au niveau de sa code base, évidemment, quand on démarre ce genre de programme. Alors vous avez plein d'outils qui vont vous permettre de le faire. Je vais vous parler de SNIC, évidemment. Mais en trois mots, en fait, si vous importez vos projets, après quelques secondes ou quelques minutes de scan, vous allez assez rapidement avoir une liste de vulnérabilités qui va apparaître. Et ça va vous donner un nombre absolu de failles. Alors, bon, ça c'est un indicateur, mais ce n'est peut-être pas le plus intéressant. Ce qui est intéressant, c'est combien il y en a qui sont critiques, combien il y en a qui sont critiques et à maturité d'exploitation. Et là, effectivement, celle-ci, c'est peut-être vos priorités. Est-ce que c'est plutôt, il n'y a plus un mapping, est-ce que c'est plutôt sur mon code, est-ce que c'est plutôt sur ma couche infra, est-ce que c'est plutôt dans mes images Docker, est-ce que c'est plutôt sur mes dépendances open source, voilà.

16:00 Donc, quand on a ce mapping et nos scorecards sur nos équipes, en fait, on a une baseline qui nous permet de démarrer le programme en sachant d'où on part. Et puis, dans le futur, on pourra se reposer un petit peu sur la mesure des progressions. Alors, No Security Champions, c'est un groupe, c'est un groupe de gens, c'est une équipe en fait. Donc on peut se demander comment générer de l'adhésion et de l'engagement dans le groupe. J'ai résumé ça en trois mots, rencontrer, impliquer, inviter. J'aurais pu dire s'inviter aussi, parce que... Invitez-vous aux réunions des devs si vous faites partie des équipes sécurité. Allez-y, allez les voir. Dites, tiens, j'ai entendu parler qu'il y avait cette réunion. Est-ce que je peux venir? Je vais peut-être avoir des idées à vous proposer. Je vais peut-être avoir des sujets. Et puis, invitez évidemment les devs dans vos réunions sécurité aussi. C'est important, communication dans les deux sens. Impliquez-les, invitez-les. Si vous avez un programme en place, créez des occasions de rencontre récurrentes et ancrées dans le marbre. On se rencontre au moins une fois par mois. On passe au moins une heure ensemble une fois par mois où on se parle. Ça peut être dans la vraie vie, ça peut être sur Zoom en fonction de comment vous êtes distribué.

17:04 Mais voilà, un meeting mensuel récurrent, c'est essentiel. On peut prendre le sujet sécu et le décortiquer à ce moment-là, faire un petit exposé. On peut aussi préparer des questions, un petit peu comme un stand-up. T'en es où? Qu'est-ce qui te bloque? Comment est-ce que je peux t'aider? C'est quoi le prochain projet? On essaye vraiment de maintenir une communication la plus fluide possible avec eux et de façon hyper régulière. On peut créer des mailing lists aussi et partager des informations. Petite newsletter mensuelle, ça ne fait pas de mal, un truc sympa. Vous pouvez partager des informations à propos de l'écosystème. Vous pouvez décortiquer des sujets de l'actualité. Tiens, Log4J, comment ça s'est passé? Qui est-ce qui s'en est sorti? Qui est-ce qui ne s'en est pas sorti? Partager l'information petit à petit et rendre les de plus en plus experts dans leur sujet. Et puis évidemment... Quand il y a des incidents de sécurité, votre champion, vous les impliquez sur les incidents. Ils vont vous aider à enquêter, ils vont vous aider à trouver des informations, à comprendre ce qui s'est passé. rentrer dans le détail, c'est eux qui ont l'information de toute façon. Donc autant aller la puiser à la source, ils sont vraiment là pour ça.

18:06 Faites-leur voir tout en avance, tout. Les nouveaux outils, les nouvelles policies, les nouvelles guidelines. Avant que ça sorte en avant-première, vous leur en parlez, vous leur montrez, vous leur faites des démos et vous leur demandez du feedback évidemment. Et vous le prenez en compte. C'est des gens qui sont intelligents, ils travaillent pour vous. Profitez-en et partagez ça avec eux. Et puis après, le reste, évidemment, c'est du team building. Donc, on fait des trucs fun ensemble, on fait des catch de flag, on va à des meet-up ensemble. Idéalement, on va avoir des conférences ensemble, même si on peut. On va à FOSDEM ensemble, c'est cool. Si vous faites partie de communautés de sécurité, invitez-les dans ces communautés. Faites des intros, présentez-les, faites en sorte qu'ils soient bien accueillis, ainsi de suite. Le but du jeu, c'est vraiment de créer un esprit d'équipe. Alors, on l'a dit tout à l'heure, l'éducation c'est la clé, l'éducation des développeurs. Mais évidemment, trop d'éducation, c'est compliqué, ne leur faites pas perdre leur temps. Ça ne sert à rien d'en faire des experts de l'encryptage s'ils n'en font pas beaucoup au quotidien.

19:11 On essaye de se contenir à leur stack, à leur langage, à ce qu'ils font. Pardon. S'ils font du Java, faites du thread modeling en Java, c'est déjà super. Thread modeling, ça parle à tout le monde. Le threat modeling, c'est une technique qui consiste à prendre soit du code, soit un schéma d'architecture, notamment, et de regarder du point de vue d'un attaqueur, en fait, et de regarder quels sont les vecteurs d'attaque, comment est-ce que je peux rentrer, et surtout d'arriver à scorer aussi les impacts, en fait. Et puis après, on regarde comment est-ce qu'on peut minimiser les vecteurs d'attaque et minimiser les conséquences, en fait, des différentes attaques. Et c'est des super trainings, en fait, parce que ça permet vraiment de changer son angle de vue en tant que dev et de comprendre ce qui peut se passer derrière le... Derrière le code. Il faut qu'ils aient aussi, donner leur des attentes et des rôles clairs. En tant que champion, je veux que tu sois capable de faire ça et ça. Je veux que tu sois capable de relire du code et de voir s'il y a des failles. Je veux que tu sois capable, en tant qu'incident, d'appliquer tel et tel protocole.

20:12 Il faut qu'en gros, leur feuille de route soit claire aussi, de votre côté. Si vous faites des sessions de code review, invitez-les. Si vous revoyez des PR, si vous revoyez du code régulièrement, invitez-les. Et puis vous mettez tous autour de l'écran et vous regardez ensemble et vous leur montrez. Vous voyez ce bout de code ou ce truc-là? Voilà, ça, ce n'est pas super et voilà comment on pourrait le fixer. Voilà comment on pourrait le faire mieux. C'est aussi comme ça qu'on va leur apprendre des choses et qu'on va petit à petit leur apporter de plus en plus d'expertise pour qu'ils deviennent autonomes et qu'ils soient capables de le faire. Faites du coaching, du coaching en groupe et du coaching en one-on-one. Il y a un gros rôle de mentoring en fait, quand on crée ces programmes. Alors, ça peut passer par des office hours. Une fois par mois, on a un zoom ouvert, ou bien la porte de son bureau est ouverte, et puis qui veut passe et on discute. On se pose des questions, on n'a pas de potes. Parfois, on n'a pas de sujet véritablement, mais on boit un café. Voilà, ça crée du lien aussi. Les office hours, c'est super. Faites des one-on-one aussi, mensuellement, avec chacun des champions.

21:14 Et puis là, c'est plus du mentoring individuel. Donc, ça peut être bien de mettre en place avec eux des plans d'action pour les aider à prioriser certaines choses, pour les aider à mettre en place des objectifs et voir comment on les atteint. Cette dimension de mentoring, elle est importante. Et puis après, dans la formation, il y a quelques indispensables. Savoir écrire et relire du code pour qu'il soit sécurisé, c'est un indispensable. Donc si les champions ne savent pas le faire, ce n'est pas grave. On fait des labs, on fait des trainings, on leur apprend. On fait du straight modeling notamment. On écrit ensemble des schémas d'architecture. On prend un whiteboard, on dit ce front-end parle à cette API, cette API appelle cette database, cette API appelle telle app serverless, blablabla. On fait des schémas et ensemble on regarde où est-ce qu'il faudrait qu'on mette des checks sécurité. Voilà, on essaye d'illustrer ça. Les codes revus ensemble, j'en ai parlé. Voilà, on est à peu près dans les indispensables. Et puis évidemment, tout ça, ça se rafraîchit régulièrement. On fait en sorte que cette connaissance, elle soit toujours immédiatement mobilisable en cas de besoin.

22:16 Donc ça veut dire qu'au moins une fois par an, on revoit les choses régulièrement. Les policies et les standards, ça fait partie des indispensables aussi. Et bien souvent, c'est méconnu. Et si c'est méconnu, ce n'est pas appliqué. Donc on ne leur balance pas un PDF de 20 pages en disant« tiens, vas-y, apprends ça par cœur et tu dois l'appliquer», ça ne marche pas. Mais on peut faire pareil, des déjeuners thématiques, le faire de façon un peu collaborative. Pendant un déjeuner, on prend un sujet, on le décortique ensemble. Et le but du jeu, c'est qu'à la fin du déjeuner, tout le monde soit au courant et comprenne comment ça marche et comment ils peuvent l'appliquer. Et puis, s'il y a des policies qui sont manquantes, on les crée ensemble. Tiens, on se met à faire du serverless, c'est quoi les bonnes pratiques du serverless? Allez, on les crée ensemble en équipe et puis comme ça, on est sûr que tout le monde est d'accord et que ce sera... pris en compte. Et puis s'ils ne sont pas compliant, s'ils ne sont pas conformes avec vos standards, ce n'est pas grave. Les sessions de mentoring, c'est fait pour ça. On place des plans d'action et on regarde comment progressivement on peut devenir de plus en plus conforme aux attentes. Dernier point de training, les outils.

23:18 Évidemment, si on a des outils, il faut que nos champions sachent les utiliser. Alors, comment installer tout ça, c'est facile, mais comment on configure? Comment on interprète les résultats? Tiens, j'ai eu un scan de sécurité qui m'a détecté 10 000 failles. Qu'est-ce que je fais? Je me suscite tout de suite ou j'attends un peu? Non. Comment j'interprète les résultats? Comment je priorise? Ainsi de suite. Tout ça, ça fait partie des indispensables. Une bonne manière de le faire, c'est de faire des hackathons avec eux. On fait des hackathons sur les outils. Voilà, c'est fun, c'est ludique, on gamifie un peu l'approche. Et puis à la fin du hackathon, vos champions, ils savent utiliser les choses. Ok, j'enchaîne, je suis désolé, c'est un peu au pas de course. Comment on mesure le succès? Ça, c'est une vraie question, en fait, parce que ce n'est pas forcément évident. Alors, je vous renvoie un peu au slide de tout à l'heure sur la baseline, finalement. L'important, c'est de mesurer les progressions. Donc, on peut refaire des scorecards et puis les comparer. On peut les faire tous les six mois, tous les ans, et on regarde, on compare un petit peu, d'une période à l'autre, les progressions des différentes équipes. On peut aussi mettre en place des systèmes de ceinture.

24:20 Vous connaissez tous, ceinture blanche, ceinture jaune, ceinture noire, blablabla, en fonction des niveaux d'expertise, et regarder comment on progresse par rapport à ça. D'ailleurs, à ce sujet, c'est mal. de se dire aussi que sur les projets les plus critiques dans notre solution, ce n'est pas bête d'avoir au moins une ceinture noire par équipe sur ces projets-là. Ça peut faire partie des indispensables, en fait. Et donc, si ce n'est pas le cas, c'est pareil. Ça fait partie des objectifs qu'on va pouvoir mesurer et dont on va pouvoir mesurer la progression. Voilà, on peut mesurer combien on a de... Ceinture noire au total, combien on a de progression. On peut aussi mesurer combien on a de membres dans le programme. Est-ce que ça a progressé? Est-ce que ça a régressé ? Combien de temps il reste? Il ne reste que deux mois et après ils s'en vont? Pas bon ça. Il faut retravailler, il faut revoir comment on anime, ainsi de suite. Il y a plein de vecteurs, de possibilités pour mesurer les progrès, mais moi je vous engage véritablement à mesurer les progressions. On pourrait tenter de mesurer le nombre de failles fixées, pré-prod, post-prod. Tout ça, ça dépend un peu du contexte de ce qu'on est en train de créer.

25:24 Et je ne suis pas sûr que ce soit un indicateur hyper pertinent. Ça dépend un peu de chacun. Donc chacun trouve sa vérité aussi. Voilà, la reconnaissance évidemment c'est important. Alors il y a la reconnaissance, à noter que la reconnaissance et la récompense ce sont deux choses différentes. Et puis il y a des gens qui fonctionnent par reconnaissance et d'autres qui fonctionnent par récompense. Donc on aura aussi un point sur la récompense après, c'est pas tout à fait pareil. La reconnaissance, ça commence par faire en sorte que nos champions, leur rôle, soit clairement connu et reconnu dans l'entreprise. Que tout le monde sache clairement quelle est leur mission et que tout le monde la comprenne et l'accepte. Alors vous pouvez leur donner des goodies sympas aussi, ça peut être des fonds Zoom un peu rigolos, ça peut être des certificats internes, des badges. Il y a une boîte qui s'appelle Lollopin qui est super, qui fait des badges, je n'ai pas d'action, mais moi j'aime bien. C'est des badges que vous pouvez attribuer, révoquer, c'est même des badges qui peuvent s'upgrader en fait, pour devenir un peu comme des Pokémon. En fait, c'est super, voilà, je trouve ça vraiment sympa.

26:29 Votre champion quand il faut. Il faut un truc bien, envoyer un message à leur manager. Appeler leur manager, dire« putain, c'est génial ce qu'elle a fait, elle nous a vraiment aidé». Puis évidemment, vous leur mettez un message aussi pour leur dire merci. Quand ils font leur revue annuelle, c'est pareil. Vous leur mettez une note dans la revue annuelle, vous mettez une ligne ou deux, vous dites« cette année Sonia nous a vraiment aidé parce qu'elle a eu tel tel et tel impact» et puis voilà, vous faites en sorte de la rapporter ce support-là et ce merci-là. Et puis c'est bien de faire en sorte qu'il y ait régulièrement des mentions spéciales du top management aussi. À un moment donné, quand le CEO dit« Merci, les Security Champions, votre contribution est vraiment importante et on est heureux de vous avoir», ça fait du bien à tout le monde. Donc un peu de lobbying de ce côté pour qu'à un moment donné, ce programme soit aussi mis en valeur. Et puis voilà, je parlais du système de ceinture tout à l'heure, on peut gamifier un peu ça, en tout cas fêter les progressions. Tiens, Gérald, il est passé de ceinture blanche à ceinture jaune, c'est génial, on fait la fête, allez. On achète des 4 quarts, on achète du jus d'orange, on fait un goûter, on marque le coup, bref.

27:34 On est une équipe et on s'encourage les uns les autres. Alors, la récompense, évidemment, c'est important aussi. Il y a quelques carottes aussi à mettre en place. Si, comme moi, vous pensez que le temps, c'est une des denrées les plus rares, accordez-leur du temps, au-delà de la sécurité, aidez-les dès que vous pouvez, dès que vous voyez qu'ils sont coincés sur un truc, mettez-les en relation avec des gens dans l'entreprise, à l'extérieur de l'entreprise, si vous avez du réseau, apportez-leur du support. Il faut que ces gens-là... se disent j'ai ce support, j'ai cette attention, j'ai ce temps qui m'est donné parce que je me suis investi dans ce programme. Il faut qu'ils ressentent bien ça comme un... Un perk, un bénéfice. Puis après, vous leur faites des petits cadeaux sécu, des bouquins, des YubiKey, idéalement, vous leur payez des trainings, c'est génial, ou des certifs, c'est génial, si vous avez des budgets, c'est vraiment magnifique. Si vous avez un petit budget aussi pour des hoodies et des t-shirts avec une tête de mort marquée Security Champion et leur nom, Ils vont kiffer, c'est sûr. Donc allez-y, ne vous retenez pas. Voilà, les certificats en Sion, ainsi de suite, ça fait partie des essentiels.

28:38 Et puis, une des récompenses, ça peut être aussi des délégations d'autonomie. C'est-à-dire que dire à un moment donné, telle ou telle équipe, elle n'a pas besoin de passer par... Des checks qui étaient un peu basiques parce qu'on sait qu'il y a une ceinture noire à l'intérieur, ça fait plaisir à tout le monde, y compris à l'équipe, et tout le monde dans l'équipe comprend pourquoi ils ont un Security Champion qui s'investit autant dans le programme. Donc c'est bien aussi de récompenser l'équipe. Voilà. Dernier point, et j'en ai fini. La continuité, c'est essentiel. Je l'ai dit tout à l'heure, quand on a un meeting une fois par mois avec nos champions, on le maintient. Il n'y a pas d'exception, il n'y a pas d'urgence, il n'y a pas de rien du tout. C'est ancré dans le marbre et ça tourne. D'ailleurs, les meetings sont schedulés automatiquement tous les 26 du mois parce que comme ça, on ne les oublie pas et c'est dans l'agenda de tout le monde. Un programme comme ça, c'est comme un vélo. ça se casse la gueule. Donc on est ensemble, on en parle, on se parle tout le temps. On est vraiment une équipe. Exceptionnellement, si vraiment, là c'est Noël et puis il n'y aura personne, on met un petit message en disant ok, on ne se voit pas là, mais on se voit en janvier.

29:42 Et en janvier, on va parler de ça. Et puis vous leur mettez un petit même sécurité sympa pour maintenir un peu le côté sympa et équipe. Mais vraiment, surcommuniquer, c'est mieux que sous-communiquer. Et la régularité, c'est essentiel. Voilà, j'en ai fini, je vous mets quelques... lien ici vers des ressources intéressantes qui me semblent bien pour continuer la réflexion. Il y a un livre sympa qui s'appelle Alice and Bob Learn Application Security, qui est typiquement un bon goodie un peu rigolo, c'est Ernest Janka qui l'a écrit, dont je vous parlais tout à l'heure. Nous on a un playbook, alors des blog posts en ligne, on en a des tonnes, mais on a un playbook sur les Security Champion Program qui peut être intéressant à regarder. Je vous engage à joindre des communautés aussi en ligne. Il y a We Act Purple dont je vous parlais tout à l'heure qui est une super communauté. Il y a la communauté DevSecCon qui est une communauté animée par SNIC mais qui est... Neutre au sens commercial, c'est une communauté véritablement. Il y a 7000 membres sur Discord qui se posent des questions, il y a des experts qui répondent, c'est vraiment très très vivant.

30:49 Il y a une section de notre site, alors là vraiment, shameless plug, ça s'appelle learn-snick.io, mais c'est super parce que c'est des petits ateliers de formation en fait, où vous allez prendre différents thèmes de sécurité, et sur chacun des thèmes en fait vous avez une leçon, des petits exercices, et puis vous avez une espèce de niveau que vous passez en fait, et vous passez d'une leçon à l'autre. Et ça passe par plein de trucs essentiels. Vous avez tous les OWASP Top 10, OWASP Top 10, j'arrive pas à le dire, qui sont décortiqués. Vous avez plein de trucs vraiment intéressants. Moi, je vous engage à envoyer ça à votre champion pour qu'il aille s'auto-former là-dessus. Pour finir, on a aussi pas mal de contenu sur l'ethical hacking. Alors je le mentionne parce qu'à chaque fois qu'on fait des workshops là-dessus, les développeurs adorent. Apprenez-leur à être des hackers. Ils kiffent, ils adorent. Vous leur apprenez à véritablement hacker des trucs en fait. Et donc du coup, d'abord ça les intéresse et puis ils montent véritablement en expertise.

31:51 Donc le white hacking, c'est vraiment quelque chose qui est plutôt sympa. Et puis pour finir, il y a un site web qui s'appelle Security Zins, qui fait plein de petits slides comme ça, que moi je trouve génial, parce que ça vous permet de vulgariser de la connaissance sur plein de sujets sécurité plutôt essentiels. J'en ai fini. Je ne sais pas si vous avez éventuellement des questions. Sinon, on est juste en face, donc passez nous voir, on sera ravis de vous recevoir.