Remettre en question le statu quo

00:05 Richard Bird — citation d'ouverture

« Plus nous distribuons, plus nous décentralisons, plus nous fragmentons. Plus nous optons pour des solutions telles que l'absence de code ou le low-code, plus nous optons pour le mode sans serveur ; nous créons simplement un environnement distribué qui est un environnement riche en cibles pour les acteurs malveillants, et un environnement incroyablement difficile à gérer du point de vue de la sécurité. »

00:28 Raghu Nandakumara

Bienvenue sur The Segment, un podcast sur le leadership de Zero Trust. Je suis votre hôte, Raghu Nandakumara, responsable des solutions industrielles chez Illumio, la société de segmentation Zero Trust. Aujourd'hui, je suis rejoint par Richard Bird, directeur de la sécurité chez Traceable, un leader de la sécurité des API. Avec des décennies d'expérience en cybersécurité et en informatique dans le monde des entreprises et des startups. Richard est chercheur principal au Zero Trust Institute de théorie cybernétique et membre exécutif de Cyber Edboard. Il est connu dans le monde entier pour ses tatouages, ses nœuds papillon et ses connaissances d'expert en matière de sécurité des API, de Zero Trust et d'identité numérique. Aujourd'hui, Richard se joint à nous pour discuter de la manière de devenir un technologue non traditionnel qui aborde la question de la dissonance cognitive dans le domaine de la cybersécurité et de l'intersection entre Zero Trust et la sécurité des API. Nous avons donc eu le plaisir [d'avoir] le parrain de Zero Trust sur ce podcast. Nous avons eu le Dr Zero Trust lui-même. Nous avons eu toute une collection d'autres sommités de la cybersécurité et de la technologie. Mais c'est absolument la première fois qu'une rock star apparaît sur notre podcast. Sur ce, j'ai le grand plaisir d'accueillir l'invité d'aujourd'hui, Richard Bird, directeur de la sécurité chez Traceable AI. Richard, merci de vous joindre à nous.

02:01 Richard Bird

Je suis très enthousiaste à l'idée de cette conversation. Merci de m'avoir invitée.

02:04 Raghu Nandakumara

Tu ne peux pas être plus excité que moi, Richard. Je regardais votre profil LinkedIn et j'ai remarqué que nous avons des parcours professionnels au moins très similaires. Nous avons tous deux passé 15 à 20 ans dans le secteur des services financiers avant de passer au « pays des fournisseurs ». À ce stade, toutes les comparaisons s'arrêtent. Je suis heureuse de dire qu'il existe un parallèle avant d'entrer dans le vif du sujet : un peu de contexte sur vous-même et sur ce qui vous a amené à ce que vous faites aujourd'hui.

02:31 Richard Bird

Eh bien, je pense que ce qui m'a amené ici, c'est mon association avec certains des personnages louches que vous avez mentionnés, tous des amis à moi. Et lorsque nous parlons de Chase Cunningham et John Kindervag, les histoires que nous partagerons au cours de cette discussion tournent vraiment autour de la façon dont nous nous sommes continuellement portés volontaires pour participer à des trajectoires de carrière particulières ou contrôler des domaines d'expertise et d'expérience. Et cela s'est traduit par une belle opportunité de synergie d'être ensemble sur un certain nombre de chaînes différentes, ou de me faire dire volontairement par l'un ou l'autre que je dois les rejoindre. Donc, je suis juste en bonne compagnie, je suppose que c'est pour cela que je suis ici. Mais tu sais, c'est devenu... ma biographie est un peu usée après quelques années à dire les mêmes choses encore et encore. Mais oui, j'ai occupé des postes en entreprise pendant 20, presque 25 ans. Au cours de ces 25 années, environ 16 ou 17 d'entre eux travaillaient dans les services bancaires et financiers, le traitement des paiements, les débuts de la bulle Internet, les paiements de personne à personne et ce genre de choses, et ont été élus par des amis et des collègues pour s'occuper de la sécurité de l'information dès les débuts de la sécurité centralisée de l'information en tant que service au sein de JPMorgan Chase en particulier. Je dis aux gens que j'ai passé ensemble 11 années à Chase, soit 137 ans de ma vie que je ne retrouverai jamais. Vous vieillissez définitivement en tant que banquier canin. Mais j'ai aussi vu beaucoup de choses très tôt, de nombreuses choses qui revêtent aujourd'hui une importance croissante pour les organisations et les entreprises d'aujourd'hui, à savoir des problèmes auxquels une organisation comme Chase était confrontée il y a dix ans ou plus. Mais aussi qu'une organisation comme Chase disposait des ressources financières et de l'expertise nécessaires à l'époque. Donc, j'aime toujours dire aux gens que je ne suis pas un expert. J'ai juste subi de nombreux coups et j'ai accumulé des bleus et des cicatrices avant que beaucoup d'autres personnes ne le fassent lors de la sécurité. Et je suis généralement plus favorable à ce que je publie pour ce qu'il ne faut pas faire que pour ce qui est des bonnes pratiques, car j'ai souvent mal fait les choses au cours de ma carrière et j'ai quand même réussi à survivre et à avoir l'occasion de discuter avec vous aujourd'hui.

04:51 Raghu Nandakumara

Je suis juste en train de rire et de sourire tellement en vous entendant dire cela parce que cela correspond parfaitement à ma propre expérience. Nous sommes confrontés à un si grand nombre de ces défis, souvent quelques années avant que le reste des organisations et d'autres secteurs ne soient confrontés aux mêmes défis. Et essentiellement, le fait d'avoir les cicatrices nécessaires pour être en quelque sorte capable de rejoindre l'autre camp et de dire : « Oui, c'est ainsi que vous devriez résoudre le problème » ou « C'est ce que j'ai appris, et voici comment vous pourriez le faire mieux ». Absolument associé à cela. Avant d'aller plus loin, je suis très heureuse de vous parler du travail que vous faites chez Traceable. Mais j'ai bien aimé lire votre article sur LinkedIn à propos de Joe Strummer et de l'influence de la musique sur votre carrière. J'aimerais que vous partagiez cela avec le public avant d'aller plus loin sur la façon dont votre intérêt pour la musique, votre passion pour la musique ont réellement influencé votre façon de penser et de communiquer les idées clés et les 10 principaux défis actuels.

05:57 Richard Bird

Eh bien, je suis vraiment contente que vous l'ayez publiée, car cela va me donner l'occasion de parler sans vergogne de quelque chose sur lequel je travaille. Mais c'est aussi l'occasion de partager. Il y a très peu de choses dont je suis vraiment fière dans ma carrière. La seule chose dont je suis vraiment fière, et je ne me contente pas d'être une technologue non traditionnelle. Je ne suis pas issu du MIS ou de la CEI, et je ne dis pas que dans le domaine de la technologie, il y a quelque chose de mal à cela. Mais je venais d'une toute autre voie. Je viens d'une majeure en sciences politiques avec une spécialisation en théorie des relations internationales et d'une mineure en japonais. Et j'étais chef de projet de construction. Après avoir quitté l'armée, il se trouve que c'était juste à une époque où la gestion de projet était une compétence extrêmement critique en matière de technologie, et quelqu'un a vu en moi quelque chose que je ne voyais pas moi-même. Et ils m'ont engagé. Et cette personne est toujours un mentor près de 30 ans plus tard. Je partage cette expérience parce que ce sont les pierres angulaires qui me permettent d'être une conférencière passionnée, une présentatrice passionnée ou une chercheuse passionnée sur des questions d'actualité dans la société, qu'elles soient techniques ou autres. C'est cette notion, cette notion artistique des muses. Ce qui vous inspire est différent de ce qui vous passionne. Ce qui vous inspire et, pour moi, mes sources d'inspiration sont étroitement liées aux arts. Il se trouve que la musique est l'une d'entre elles. Et comme la pièce que j'ai écrite semble toucher un peu le cœur et l'âme de beaucoup de gens. Vous savez, j'ai grandi au tout début de la musique punk rock. Je n'ai pas honte de dire que cela m'a probablement inspiré une pensée plutôt contraire, cyniques, voire anti-establishment, quand j'étais enfant, et elle est toujours là. Je l'ai enterré il y a plus de 20 ans dans le monde de l'entreprise, où vous n'êtes pas autorisé à dire des choses en public, vous n'êtes pas autorisé à partager vos pensées. Vous devez obtenir 17 approbations différentes pour participer à un podcast, et encore moins pour parler en public. Et j'ai gardé un cap là-dessus pendant un quart de siècle. Et cet article m'est venu quand quelqu'un m'a demandé : « Comment se fait-il que vous ayez trouvé autant d'analogies ou de métaphores farfelues ? » ou « Toute cette approche narrative que vous adoptez pour aborder les choses ». J'ai dit : « Eh bien, c'est deux choses. Tout d'abord, j'ai grandi en tant que fils de capitaine de bateau de pêche, alors j'ai obtenu un doctorat en narration. » Et la deuxième, c'est que tous ces éléments de mon passé et de mon expérience, le fait d'avoir grandi en écoutant de la musique, d'entendre des paroliers et des musiciens incroyables aborder avec leurs mots les problèmes de la société, sont devenus une source d'inspiration naturelle et une pierre de touche de motivation pour moi personnellement. » Lorsque je prends la parole en public, l'un de mes objectifs est de créer un véritable lien émotionnel avec les gens. Et c'est compliqué parce que vous n'êtes pas connecté à une seule émotion. Tout comme la musique, vous ne vous connectez pas à une seule émotion. Quelqu'un peut être heureux d'entendre une chanson, mais la joie et la danse sont deux composantes différentes de cette expérience, pas une seule. Et j'ai dit « plug » éhonté. Comme je joue telle ou telle personnalité, je parle et ce type de rôle depuis cinq ou six ans, je me suis rendu compte que ce que j'ai vécu et ce que je pense être enseignable. Je vais le maudire, mais j'en suis à la dernière édition d'un livre intitulé Célèbre avec 12 personnes. Le sous-titre est un guide de carrière expliquant comment devenir un expert de renommée internationale dans un domaine qui intéresse tout le monde. Et l'idée de ce livre est qu'au cours de mon voyage au cours des cinq ou six dernières années, j'ai rencontré un très grand nombre de personnes microcélèbres. Et la plupart de ces micro-célébrités sont comme moi. Ils sont inspirés par des sujets qui sont loin de notre carrière et de notre expérience de travail. Et ces micro-célébrités ne travaillent pas uniquement dans le domaine de la sécurité. Je me suis assise à côté d'un type dans un avion, nous avons commencé à discuter et il a dit : « Oui, eh bien, je suis coordinateur de cascades. » Je suis descendu de l'avion et j'ai découvert qu'il le coordinateur des cascades. C'est lui qui enseigne à tous les autres cascadeurs et cascadeurs d'Hollywood. Il a des milliers de personnes qui le suivent. Et je pensais ne jamais avoir entendu parler de lui auparavant et je n'entendrai probablement plus jamais parler de lui. Mais quelle dynamique intéressante pour quelqu'un d'être capable d'avoir un tel impact sur la vie des gens. Et c'est vraiment de là que vient toute cette énergie pour écrire cet article de Joe Strummer. Par exemple, que pouvons-nous faire si nous ne sommes pas des rock stars et des musiciens ? Que pouvons-nous faire pour susciter le même enthousiasme, la même motivation et la même passion et être même une muse pour les autres dans notre propre domaine d'expertise ? Et c'est vraiment comme ça que tout est arrivé.

11:12 Raghu Nandakumara

J'adore ça. Merci beaucoup pour ce partage. Et une humble demande de ma part : lorsque ce livre sera publié, j'espère qu'il s'agira d'un véritable format de livre physique, et pas simplement d'un livre électronique. J'adorerais une copie signée de votre part.

11:27 Richard Bird

C'est le plan. Je suis assez vieux pour continuer à aimer le papier.

11:12 Raghu Nandakumara

Ma femme plaisante avec moi en disant que si j'achète des livres, c'est juste pour remplir notre étagère. Et je réponds : « Oui, absolument, sans vergogne, c'est pour la toile de fond quand je suis au téléphone. » Mais l'argument que vous avez soulevé en matière de narration, et je trouve vraiment cette inspiration pour raconter des histoires, dans le rôle que je joue aujourd'hui, et je suis sûr que vous trouvez dans votre rôle, c'est qu'il est très important de relier, en quelque sorte, je suppose, la valeur technique des produits que nos entreprises fabriquent, le lien réel entre l'essence de l'acheteur et le résultat qu'il essaie d'obtenir. Il ne s'agit pas de technologie ; il ne s'agit pas de la façon dont vous vous y prenez et faites les choses. Il s'agit de la façon dont je vais t'aider. Pourquoi est-ce important pour toi ? Et je pense que la narration est très importante, vous trouvez cela ?

12 h 15 Richard Bird

Eh bien, non seulement je trouve que je pense cela en cours d'écriture, ce qui n'est pas naturel pour moi. L'écriture de longs formats n'est pas naturelle pour moi. Au cours du processus d'écriture, j'ai dû vraiment comprendre pourquoi, en matière de sécurité en particulier, nous avons du mal à communiquer les uns avec les autres. Nous avons du mal à communiquer en ce qui concerne, voici le problème commercial que je dois vous aider à résoudre. En tant que fournisseur de solutions techniques, nous avons du mal, en tant que technologues, à faire face à cette exigence commerciale. Et les technologues ne comprennent pas. Et je pense que ce que j'ai réalisé, c'est que lorsque nous parlons des personnes présentes sur le marché, nous essayons de montrer une voie pour résoudre les problèmes de manière vraiment universelle à ces acheteurs, qui opèrent à la couche abstraite. C'est une abstraction. Ils reconnaissent qu'il y a un problème ; ils reconnaissent qu'ils voient une sorte de violation ou de piratage dans les actualités. Mais en assimilant cela à tous les différents leviers et adversaires au sein d'une organisation qui doivent être actionnés, poussés, tordus ou ajustés pour empêcher que cette mauvaise chose ne se produise. C'est extrêmement difficile. Et ensuite, lorsque nous en revenons aux ingénieurs, aux ingénieurs de solutions et aux architectes de sécurité. Nous vivons tous dans le monde des spécifications. Nous parlons tous de ces leviers, nous parlons tous de ces commutateurs, et nous parlons de... Et nous avons un énorme écart de dissonance cognitive. C'est ce qui arrive. Et je pense que la narration est l'un des principaux éléments, l'un des principaux outils qui permettent de combler cette lacune. Cela crée la possibilité d'une couche de traduction universelle entre ces parties et ces différentes entités. Parce qu'en fin de compte, nous faisons tous la même chose pour essayer de résoudre ces problèmes. Et quand nous nous demandons pourquoi allons-nous si lentement pour y arriver ? Je pense que cela tient en grande partie à ceci : une fracture importante dans la communication et la compréhension. C'est-à-dire que je travaille sur la couche d'abstraction, je travaille sur la couche de spécification. Et il n'y a rien qui puisse tout relier. Et je pense que la narration en est un élément essentiel.

14:38 11:12 Raghu Nandakumara

Vous utilisez donc le terme dissonance cognitive, et en fait, vous n'allez pas le croire, mais j'ai fait des recherches à ce sujet et j'ai écouté certains des autres articles que vous avez publié, et je vous cite, vous avez dit : « dissonance cognitive, il y a un énorme fossé entre le fait que je sais que j'ai un problème et je fais quelque chose pour y remédier ». Alors, essayons maintenant d'en arriver à ce niveau. Vous l'avez constaté dans votre expérience, et j'ai constaté dans mes expériences que vous faites une évaluation. Disons qu'il s'agit d'un exercice en équipe rouge. Vous identifiez vos zones de vulnérabilité et vous dites : « Oh, oui, je sais que je suis vulnérable là-bas. Je comprends que je dois faire quelque chose à ce sujet. » Six mois plus tard, 12 mois plus tard, répétez l'exercice, les mêmes vulnérabilités existent. Je dois faire quelque chose à ce sujet : répéter, répéter, répéter. Pourquoi cet écart ? Pourquoi cette incapacité à franchir le pas et à résoudre les problèmes qui doivent être résolus ?

15:35 Richard Bird

Oui, il y a quelques composants. La première est que l'écart représente l'écart entre les connaissances et la menace, ou entre les connaissances et les risques ou entre les connaissances et l'expérience. J'avais dit que j'étais dans l'armée. Nous avions un sergent instructeur alors que je fréquentais l'une de nos écoles. Et une jeune troupe est arrivée et se tenait devant eux pour se plaindre d'une situation que nous vivions au cours d'un exercice en particulier. Et le sergent instructeur l'a regardé et a dit : « Je t'entends, mais je ne peux pas vraiment te sentir. » Et j'ai trouvé ça génial. Je l'utilise depuis des années. Il a dit : « J'enregistre votre problème. Cependant, je ne peux ni ne veux y faire quoi que ce soit. Et je pense qu'il y en a beaucoup dans le monde de l'entreprise parce qu'il est facile de lancer des pierres. Je pense que c'est l'un des avantages que j'ai, c'est que mes pierres sont lancées un peu moins fort parce que je suis passée de ce côté du mur. Je suis d'avis que vous avez tellement de priorités concurrentes. Vous avez tellement de plateformes en feu ; vous avez tellement de problèmes. J'ai eu des programmes entiers qui ont déraillé pour essayer de réduire les risques, de manière tangible, dans un domaine sur lequel nous travaillions depuis quelques années, parce que certains cadres ont appelé et ont dit : « Hé, je suis allé à une conférence, j'ai entendu cela, vous devez vous y mettre maintenant ». Il y a tout simplement énormément de distractions dans le monde de l'entreprise. Donc, il ne suffit pas de savoir quelque chose. Et je pense que nous ne cessons de prouver que le fait de savoir quelque chose n'entraîne pas de changements de comportement. En ce qui concerne l'atténuation des risques associés à un objet, c'est quelque chose que nous devons réinvestir dans les transactions risquées. Au fil des ans, les acteurs de la gestion des risques ont eu du mal à créer des formules qui soient réellement adaptées aux coûts et aux conséquences des risques. Pour les classifications des risques, je cite toujours le livre de Nassim Qualy, Le cygne noir, chaque fois que je parle de risque, c'est un livre tellement révélateur sur le « pourquoi ». Pour répondre à votre question, nous ne pouvons pas faire de progrès car nous agissons en permanence en tant que dirigeants et praticiens avec la conviction que ces risques à long terme ne se produiront pas. Et comme vous le savez, Qualys explique dans son livre que l'histoire prouve que ces événements à long terme se produisent beaucoup plus fréquemment que ce à quoi on pourrait s'attendre. Cela nous ramène à cette dissonance cognitive. Si je pense qu'un risque existe si loin que je n'ai pas à m'en inquiéter. Je suis sûr que, tout comme votre parcours, vous l'avez entendu à maintes reprises : « Oui, je suppose que c'est vraiment un gros problème. Mais je ne travaille pas dans le secteur bancaire, donc cela ne m'inquiète pas vraiment. » Vous savez, comment cela s'est-il passé pour tout le monde à propos des rançongiciels ? C'est vrai. Vous savez, on s'attend à ce qu'il existe un gradient de types d'attaques qui représente l'ampleur de la complexité et de la maturité. Et cela vient d'être abordé lors d'une conversation hier, quelqu'un m'a demandé, il m'a répondu : « Eh bien, si quelqu'un attaque une Chase, une Bank of America ou une ville de cette façon, parce qu'une très grande entreprise et une organisation vraiment compliquée, les petites ou moyennes entreprises n'ont pas à s'inquiéter de la même attaque. Et je me suis dit : « Mon garçon, tu viens de réussir. Je veux dire, il y aura beaucoup de cynisme à ce sujet, comme si tu venais de réussir. Vous savez, les gens dimensionnent leurs programmes de sécurité en fonction des risques qu'ils pensent être liés à leur domaine ou à leur secteur d'activité. En attendant, les mauvais acteurs n'y pensent pas comme ça. Si les méchants s'en vont, où que je puisse entrer, par exemple, si je dois utiliser une attaque sophistiquée, cool. Je vais utiliser une attaque peu sophistiquée. Cool. Si j'ai accès à tes données. C'est tout ce qui compte vraiment. Et je pense que c'est vraiment toute la confusion liée à la complexité de ce marché. Cela permet à cette roue de dissonance cognitive de tourner et de tourner d'année en année en termes de performances de sécurité.

19h50 Raghu Nandakumara

Comment pouvons-nous changer cela ?

19:53 Richard Bird

Il y a la réponse du praticien adulte, et puis il y a la réponse cyniques.

19:58 Raghu Nandakumara

Je veux les deux.

20:02 Richard Bird

Eh bien, je vais commencer par la réponse cyniques. Et cela reflète une conversation que je venais d'avoir avec un mentor l'autre jour ; le mentor m'a dit : « Peut-être devrions-nous simplement conseiller de commencer à conseiller les méchants. Parce qu'ils écoutent, mais pas nos collègues, nos amis et nos compagnons de pratique. » Et je pense que c'est une déclaration sévère, mais je ne pense pas que ce soit totalement injuste. Et je pense que la réponse cyniques à cette question est que pendant longtemps, en tant que praticiens, nous devons tous attendre que la plus grande violation se produise et que les gens changent enfin. Cela n'a pas marché. Et cela soulève la question suivante : et si nous assistons à une réaction en chaîne ? Un événement catastrophique ? Et si le réseau d'infrastructures d'un pays venait à tomber en panne ? Et si nous assistons à une panne massive de l'ensemble du réseau d'un hôpital ? Nous avons été témoins de cas isolés de fermetures de blocs opératoires et de salles d'urgence. J'ai toujours été convaincu que ce qui change vraiment la donne, c'est lorsqu'il y a une forme ou une autre de nombreuses victimes associées à l'action d'un mauvais acteur dans le monde numérique. Et quand je l'ai dit il y a quelques années, les gens pensaient que j'étais la chose la plus sombre que je pouvais dire, et maintenant je dis que les gens disent : « Oui, je comprends ». Comme si ça pouvait arriver. Donc, je pense qu'une certaine partie de ce problème se reflète dans cette dissonance cognitive dont nous parlons, c'est-à-dire que nous n'avons toujours pas vu quelque chose d'assez grand et de grave pour enfin réveiller les gens. Maintenant, la réponse professionnelle à cette question est que là où nous commençons vraiment à faire des progrès, c'est lorsque nous commençons à constater un changement significatif. C'est l'un des comportements les plus bizarres que j'ai vus dans le domaine de la sécurité. Beaucoup de professionnels de la sécurité s'énervent quand je dis cela, mais je crois fermement que la sécurité est la seule discipline du monde de l'entreprise où nous refusons de tirer les leçons de l'histoire, des données et des preuves. Nous avons clairement des preuves devant nous. Je vais donc donner un exemple très précis. Après 25 à 30 ans d'histoire, nous avons des preuves claires : lorsqu'un acteur malveillant pénètre dans votre système, la toute première chose qu'il fait est d'accéder à votre Active Directory. Et en accédant à Active Directory, ils recherchent des fonctionnalités et des identités obsolètes, désuètes, désactivées, mais non supprimées. Ils s'emparent de tous ces droits et accèdent à des subventions et à des autorisations, ils font de mauvaises choses. Et comme tout se trouvait sur votre AD, vos systèmes internes de sécurité ne rattrapent pas leur retard car ils semblent devoir être là. Maintenant, c'est une tendance dont tous les responsables de la sécurité savent qu'ils sont réels ; ils savent que c'est étayé par des preuves. Et ils savent que c'est la voie principale pour les mauvais acteurs. Pourtant, vous pouvez entrer dans huit ou neuf entreprises sur dix aujourd'hui et leur demander : « Quand avez-vous nettoyé votre annonce pour la dernière fois ? » Qu'il s'agisse d'Azure ou d'une solution sur site, vous entendrez des grillons. Vous entendrez quelqu'un dire : « Eh bien, vous savez quoi, cela a été financé l'année dernière et l'année précédente, mais c'est passé en dessous du résultat net, et nous n'y sommes pas parvenus. » Et je pense que, universellement, nous le savons, c'est l'une des surfaces d'attaque les plus capitalisables de toutes les entreprises. Et pourtant, nous restons tous assis et nous nous disons : « Oui, j'ai été retiré du financement, et nous n'allons pas travailler là-dessus cette année ». C'est ce que je dis quand je dis que nous refusons constamment. Et cela revient à beaucoup de questions autrefois, comme si vous aviez juste besoin de bien connaître les bases. Personnellement, je ne pense pas que ce soit une déclaration utile. Cela revient à la sécurité fondamentale. Utilisez-vous correctement la sécurité fondamentale ? Et vous savez, ce n'est pas pour amener le témoin ici, mais c'est ce qui m'a finalement amené à Zero Trust, après avoir longtemps résisté à Zero Trust. Parce que je pense que nous allons aborder certains aspects de Zero Trust ici, qui remontent aux tout débuts de l'informatique et qui sont fondamentaux. Et je pense que même si beaucoup de gens pensent que Zero Trust l'est, passons à l'avenir ; en réalité, certains aspects de Zero Trust sont plus ou moins liés à, revenons aux principes du passé qui, nous le savons, ont fonctionné et qui sont extrêmement utiles dans l'environnement actuel, mais que nous avons oubliés et je pense que c'est là que nous commençons à constater des améliorations lorsque nous revenons en arrière et que nous retrouvons nos racines. Et deuxièmement, lorsque nous commençons à prêter attention aux données clairement publiées et aux données clairement divulguées, nous ne cessons de nous dire que c'est notre point faible.

24h40 Raghu Nandakumara

Juste en écoutant tout cela et toutes sortes de choses que nous aurions pu approfondir et qui, je suppose, seraient là toute la journée et toute la soirée, tant que mon temps le permet, mais je ne suis pas sûre que le vôtre le fasse. Donc, juste deux choses. L'une des choses que vous avez évoquées, c'est que ce besoin de prise de conscience est probablement dû à cet événement véritablement catastrophique déclenché par une cyberattaque. Et je pense que nous sommes en quelque sorte sur le point de prendre conscience de cette réalité. Je veux dire, tout le monde cite Colonial Pipeline comme un exemple possible de cela. Et puis des changements qui ont ensuite entraîné, en termes de réglementation des exigences au niveau gouvernemental ou spécifique à l'industrie, en termes de manière à améliorer la posture de cybersécurité, à la fois des organisations individuelles, mais aussi de manière collective. Ensuite, vous avez parlé de Zero Trust comme d'une sorte de retour vers le futur en termes de manière réaliste pour ce qui est de la manière dont nous pouvons améliorer la posture de sécurité. Et comme vous l'avez expliqué, Zero Trust ne concerne pas nécessairement ce type de stratégie de cybersécurité tournée vers l'avenir. Mais en fait, revenons à ce qui a toujours été au cœur de la cybersécurité. En arrière, en quelque sorte au début des temps. Où l'avons-nous oublié ? Et pourquoi l'avons-nous oublié ?

26:01 Richard Bird

Eh bien, les raisons pour lesquelles c'est oublié sont intéressantes parce que nous les voyons tous les jours. Le monde de l'espace numérique est devenu de moins en moins sûr à mesure que nous sommes passés d'une décentralisation monolithique à une économie distribuée puis hautement décentralisée. Plus l'architecture informatique est fragmentée, distribuée et décentralisée, plus les failles de sécurité et les exploits s'aggravent, car vous n'avez plus la commande et le contrôle dont vous disposiez auparavant. Maintenant que je ne dis pas ça pour me débarrasser de ma pelouse, les enfants, c'est le bon genre de déclaration. Ce que je veux dire, c'est que c'est le mécanicien qui a provoqué l'explosion, ce qui a eu de graves conséquences sur le plan de la sécurité. Et c'est quelque chose qui va très clairement empirer. Et cela s'explique par le fait que nous sommes dans cette phase technologique où nous atteignons les capacités actuelles ultimes en matière de virtualisation, à savoir HTTP, HTTPS, couche 7 d'application à application. Je me souviens qu'il y a quelques années, une très grande banque avec laquelle je travaillais en Europe m'a dit que son objectif dans cinq ans était de lancer toutes ses applications sur l'Internet public. Et j'ai répondu : « Vous êtes fous les gars. » J'ai répondu : « C'est fou. » Et pourtant, c'est ce monde. C'était un cas où j'étais myope. Je me suis dit : « Ce n'est pas possible, nous n'y arriverons jamais. » Et puis la réalité est que c'est le monde dans lequel nous vivons. Mais aujourd'hui, de plus en plus d'actifs que vous utilisez pour générer de la valeur afin de gérer et de distribuer des transactions ne vous appartiennent pas. Et plus ce n'est pas votre affaire, plus nous augmentons les risques liés à la chaîne d'approvisionnement : tous les acteurs de cette chaîne font des choses sans jamais discuter entre eux, sans jamais se parler des contrôles de sécurité des uns et des autres. Quelque part en bas de la chaîne, il y a un type qui a extrait quelques lignes de code dans un dépôt public quelque part, et le code est déjà compromis. Et tu n'as plus aucun contrôle là-dessus. Donc, c'était le conducteur. Plus nous distribuons, plus nous décentralisons, plus nous fragmentons, plus nous empruntons des voies telles que l'absence de code, le low-code, et plus nous optons pour le mode sans serveur, plus nous créons simplement un environnement distribué qui est un environnement riche en cibles pour les acteurs malveillants, et un environnement incroyablement difficile à gérer du point de vue de la sécurité. C'est donc certainement le facteur causal. Et, comme je l'ai dit, je ne veux pas que quelqu'un m'envoie de mauvais grammes ; il y a encore ce gars anti-Cloud. L'informatique distribuée existe depuis longtemps. Ne pensez pas que, parce qu'AWS et Google ont réussi à garer certaines machines virtuelles équipées d'équilibreurs de charge dans leur propre centre de données, ceux d'entre nous qui ont les cheveux gris ne savent pas à quoi ressemblent la décentralisation et la distribution. Mais oui, je pense que l'élément fondateur de Zero Trust va évidemment changer la donne pour moi, car j'ai dit que j'étais une résistance à Zero Trust au début parce que je suis un vieux gars de l'identité, d'habitude, ce qui signifie que Zero Trust ressemble à de la friction. C'est la friction qui vous fait virer. Mais je me suis complètement trompée car derrière ces frictions se trouve cette réalité et nous remontons aux débuts de l'informatique, selon laquelle le moteur de ces mauvaises choses dans ces environnements hautement distribués est l'existence, l'intention, la conception, l'ingénierie, l'existence autorisée d'une confiance implicite et persistante dans tout. Et cette existence d'une confiance appliquée et persistante est ce que les mauvais acteurs adorent. Cet exemple AD, j'ai un ancien compte AD avec des droits de Dieu que personne n'a jamais retiré du répertoire, ce qui est impliqué dans une confiance persistante illustrée. Et j'ai choisi, soit en l'ignorant, soit en l'ignorant délibérément, de ne pas y remédier. J'autorise un portail pour que de mauvaises choses se produisent. Tout cela est basé sur la confiance. Et c'était vraiment le genre de changement pour moi. Donc, je pense que vous savez, la voie d'amélioration, même avec la distribution massive de plates-formes et d'infrastructures informatiques, consiste à réduire considérablement dans le but d'éliminer la confiance implicite et persistante dans la plus grande partie possible du patrimoine numérique, le plus rapidement possible.

31:11 Raghu Nandakumara

Pour ceux qui ne regardent pas cette vidéo et qui la consultent par audio, je suis sur le point de perdre la tête parce que je viens de passer les deux dernières minutes à hocher vigoureusement la tête à chaque mot prononcé par Richard. Je pense que c'est l'une des approches les plus succinctes mais les plus directes et les plus descriptives pour analyser les raisons pour lesquelles Zero Trust est nécessaire et la racine du problème que nous essayons de résoudre. Alors, Richard, j'apprécie ça.

31:45 Richard Bird

Eh bien, il m'a fallu beaucoup de temps pour le comprendre. Et je ne suis pas le seul à faire ce bruit. L'un des problèmes du surnom Zero Trust est que nous n'arrivons pas à trouver la véritable racine de la confiance dont nous parlons. J'ai toujours pensé que nous aurions dû appeler le modèle « votre beau-frère douteux, qui est peut-être toxicomane et qui veut toujours emprunter le cadre de sécurité de vos outils ». Parce que tout le monde sait de quoi on parle. C'est un membre de la famille que vous ne leur donnez pas chez vous et le code de votre ouvre-porte de garage. Et nous en avons beaucoup ; nous avons beaucoup de ces beaux-frères sommaires dans nos systèmes aujourd'hui. Et cela revient à la partie narrative, à savoir que j'étais réactive, émotionnellement réactive au terme Zero Trust au départ. Et cela m'a fait me tromper terriblement sur mes propres suppositions. Et moi John [Kindervag] ai partagé l'histoire, je la partage tout le temps. Je me souviens que lorsque j'ai rencontré John pour la première fois en personne, nous étions en train de dîner. Et j'ai dit : « Mec, je ne croyais pas ce que tu vendais. » Et il a commencé à me parler, et la seule chose qu'il a dite, qui a tout mis en lumière pour moi, c'est qu'il a dit : « Je pense que les données devraient avoir une identité ». Et j'ai répondu : « Waouh, freine, mec. » C'est comme Star Trek, et nous sommes toujours dans Fred Flintstone. Dès que John a commencé à l'articuler d'une manière — il est également un excellent conteur d'histoires — lorsqu'il a commencé à l'articuler d'une manière qui n'était pas un livre blanc, ce n'est pas une autre spécification technique qui m'a ouvert les yeux. Et comme je l'ai dit, j'admets pleinement que j'étais un abruti en ce qui concerne la notion de Zero Trust, car je veux revenir à la base. Au cours de ma vie, j'ai fait beaucoup de choses en matière de sécurité des ordinateurs centraux pour l'identité. Et j'ai travaillé avec d'incroyables pionniers du secteur bancaire ou des opérations sur mainframe. Et j'ai eu cette révélation à un moment donné alors que je travaillais sur un programme vraiment énorme chez Chase. Zero Trust m'avait déjà été expliqué par ces responsables des opérations sur les ordinateurs centraux. Parce que Zero Trust, le contrôle d'accès depuis ses débuts jusqu'à ce que nous commencions réellement à brancher d'autres appareils virtuels pour accéder aux données de base du mainframe a toujours été un Zero Trust. Et je me suis dit : « Waouh, cela revient à ce que je voulais dire. Ces principes fonctionnaient, certes, d'un système centralisé pour un grand système centralisé, mais ces principes fonctionnaient dans cet environnement. Et nous ne pouvons pas faire valoir si bien que ce n'est pas comme le cloud. Parce que, comme je tiens à le rappeler aux gens, environ 90 % de toutes les opérations informatiques effectuées chaque nuit se produisent lorsqu'un levier géant de dessin animé est actionné et que des ordinateurs centraux fonctionnent. Pourtant, environ 90 % des charges de travail alors que tout le monde passe au cloud pourraient continuer à dominer la planète grâce à Internet, le cloud après 30 ans de cloud commercial. Nous ne pouvons pas utiliser cette rationalisation de la complexité du cloud lorsqu'il s'agit de la complexité du mainframe et de l'énorme monde monolithique qui l'est tout autant. Mais je pense que nous invoquons ces excuses pour des raisons de commodité. Parce que tout se résume à : je veux que mon widget soit diffusé plus rapidement, je veux que mon produit soit produit plus rapidement. Je veux, je veux, je veux, je veux, je veux, et ces « je veux » viennent rarement avec ; j'aimerais aussi que ce soit sûr. Vous savez, ce sont ces facteurs qui compliquent vraiment la sécurisation de ces objets.

35:27 Raghu Nandakumara

Oui, absolument. Lorsque vous décrivez la nécessité d'un Zero Trust, essentiellement le problème qui s'est accumulé, vous avez parlé, essentiellement, de cette accumulation d'un trop grand nombre d'accès implicites, du fait que nous pensons que cela rend nos rôles plus faciles et plus productifs. Dès que nous entendons le terme Zero Trust, ou, en d'autres termes, la suppression de la plus grande confiance implicite possible, de sorte qu'il y ait beaucoup moins d'accès gratuit que tout type d'attaquant peut exploiter. Je pense que c'est le problème. Et je pense que vous avez décrit comme cela le problème qu'il faut tant de temps à de nombreuses organisations pour surmonter. Parce qu'ils le pensent déjà, oh mon dieu. Allez-vous supprimer cet accès, vous allez le casser ? Et ensuite, comment puis-je être productif ? Et je pense que quand les gens y pensent, et en fait, je pense qu'à l'avenir, si vous y réfléchissez, de ce point de vue, sera-t-il plus facile d'énumérer toutes les mauvaises choses que vous voulez empêcher de se produire ? Bien, et est-ce que c'est une liste finie ? Ou est-ce plus facile de simplement définir des choses très spécifiques ? Tu as vraiment besoin de quelque chose à faire ? Et juste gérer ça ? Lequel de ces deux est le plus facile quand on y pense ?

36:49 Richard Bird

Je pense que nous pensons qu'il faut insister sur la question des personnes les plus défavorisées, et pas seulement dans Zero Trust. Je veux dire, au moins le privilège est une composante fonctionnelle des environnements à haut risque depuis longtemps. Je pense que nous serions proches de la déclaration la moins privilégiée sans jamais revenir à ce que je pense que vous repoussez vraiment les limites, à savoir, que diriez-vous de la moins fonctionnelle ? Par exemple, pourquoi à partir d'un processus de flux transactionnel ? Et bon sang, tu parles d'un terrier à lapins dans lequel on pourrait tomber, et pourquoi est-ce si facile pour les mauvais acteurs ? Vous savez, une fois qu'ils ont obtenu une forme d'entrée, une authentification par points, de faux identifiants, des informations d'identification piratées, peu importe le cas. Comment se fait-il qu'ils puissent prendre un seul appel d'autorisation et utiliser et réutiliser cet appel d'autorisation pour accéder à des tonnes d'autres données auxquelles notre appel d'autorisation n'a jamais été destiné ? Et fonctionne comme prévu ? L'idée que je vais créer des contrôles de couche d'autorisation bien trop privilégiés. Non pas d'un point de vue identitaire mais d'un point de vue fonctionnel. Par exemple, pourquoi diable ai-je besoin de pouvoir autoriser l'accès à une application qui n'a absolument rien à voir avec l'expérience de ce client ? Ou cette expérience de techniciens ? Nous le faisons tout le temps. Et je pense que cette propagation, cette énumération des mauvaises choses par rapport à la fonctionnalité est devenue une équation tellement difficile. Parce que pour revenir à votre point de référence, comme lorsque j'ai commencé à travailler dans le domaine de la sécurité des identités, le principal problème était de lutter contre les appels d'authentification propriétaires émanant de développeurs d'applications. Et on aurait cru que c'était la fin du monde. C'était comme si non, non, non, j'avais reçu mon appel d'authentification ; c'est mon application. Va-t'en, laisse-moi tranquille. Et nous répondons : « Oui, mais vous n'avez pas besoin d'un appel d'authentification authentifié pour chaque application ». Nous pouvons fédérer et standardiser l'authentification unique, et d'ailleurs, cela devient beaucoup plus sécurisé. D'ailleurs, c'est un service ; vous n'avez plus à gérer ces frais généraux et tout ce genre de problèmes, à gérer vos propres journaux de contrôle d'accès et à tout ce genre de choses. Ce combat était une guerre sainte. Comme si c'était horrible. Et si c'était horrible, c'est parce qu'il y a environ 15 ans, ou 20 ans auparavant, nous avions consulté nos développeurs d'applications et nous leur avions dit : « Hé, va créer une application ». Et ils l'ont fait. Et ils ont créé une application. Ils ont répondu : « Eh bien, nous avons besoin d'un flux d'authentification pour ce truc. » Aucune directive, aucune sécurisation ou aucune sécurité de l'information n'a été mise en panne dans le cadre de ce plan. Vous savez, pour en revenir à la fonctionnalité, devinez quoi ? Il s'agit d'un autre exemple de sécurité. Nous n'avons tout simplement aucun respect pour les preuves, les données de l'histoire. Qu'avons-nous fait avec l'autorisation ? Eh bien, nous avons dit que les développeurs d'applications partaient à la conquête. Que faisons-nous des API ? Ce n'est qu'un widget. Allez-y et utilisez-le. À quel point cela pourrait-il être grave ? En ce moment, il est assis ici et les gens disent : « Je ne sais pas combien d'appels d'autorisation ; je ne sais jamais combien d'API je possède ». Je ne sais pas Et il n'y a pas de moment dans l'histoire de la sécurité où la réponse signifie que de bonnes choses vont se produire du point de vue de la sécurité. Nous avons donc laissé cette propagation massive. De toute évidence, nous parlons beaucoup de l'étalement des API traçables. Mais il y a l'autorisation, l'étalement, les fonctionnalités, l'étalement, tout cela, et nous ne sommes même pas près d'appliquer l'idée du moins quoi que ce soit à aucune de ces choses. Et plus nous vivons dans un monde où l'on attend un accès massif et maximal à tout moment, que nous l'utilisions ou non, plus ces problèmes vont continuer à s'accélérer de façon exponentielle.

40:47 Raghu Nandakumara

Parlons donc de la sécurité des API et du travail que vous accomplissez pour obtenir Traceable. Donc, la première question, je parcourais mes documents de référence Zero Trust préférés cette semaine ; il s'agit du modèle de maturité CISA Zero Trust et du NIST 800 207. Et je les ai parcourues en recherchant spécifiquement la section où ils parleront de Zero Trust et de la sécurité des API. Et le choc, l'horreur, zéro référence, racine carrée de zéro. Qu'est-ce que Zero Trust a à voir avec la sécurité des API ? Commençons par là.

41:29 Richard Bird

Eh bien, vous savez que la réponse la plus courte est que j'étais assis sur scène avec John Kindervag à Miami. Nous faisions partie d'un panel de discussion en groupe et il fait signe de la main à l'écran. Et il répond : « Lorsque nous aurons réussi à appliquer Zero Trust », « toutes les règles de sécurité passeront à la septième couche ». Et je me suis dit que tout le sang avait été évacué de mon corps. Mais j'ai écarté John. J'ai demandé, John, sais-tu à quel point la sécurité d'Internet et du Web est mauvaise ? C'est l'état du Nirvana dont nous devons commencer à parler. Et il se trouve que cela coïncidait avec le moment où j'ai rejoint Traceable. L'un des principaux facteurs qui m'ont poussé à rejoindre Traceable est que j'étais frustrée par les progrès et les innovations réalisés dans le domaine des solutions d'identité. Et je parlais beaucoup de l'exemple que j'ai donné tout à l'heure à propos de l'autorisation, du contrôle des réclamations et de la sécurité. Et il n'y a pas de solution pour cela. Même à ce jour, il y a quelques personnes qui font des expériences, qui ont réalisé des projets scientifiques qui étaient du genre à suivre. Sauf que ce que j'ai réalisé, c'est que l'authentification des autorisations est le carburant de l'autorisation de l'API, c'est tout ce qui compte pour les API du moteur. Et puis, je me suis dit : « Eh bien, si vous pouvez sécuriser les API, vous pouvez maintenant commencer à sécuriser le plan d'autorisation, entre autres choses ». Et l'une des choses que je trouve fascinantes, c'est ce que vous avez découvert. Nous vivons dans un monde qui traite toujours de manière universelle, qui traite toujours les API comme s'il s'agissait d'une sorte de widget. Ils ne le sont pas ; il s'agit simplement d'un appel d'application, l'appel au magasin de données d'application représente simplement un microservice. Genre, à quel point ça pourrait empirer ? Eh bien, nous sommes en train de le découvrir. Nous sommes certainement en train de découvrir à quel point cela pourrait être grave, car les API représentent une micro-encapsulation de la version ultime de la virtualisation. Ils font quelque chose. Et si vous êtes un futuriste incroyablement intelligent, et que vous regardez l'histoire, vous vous dites : « Oh, attendez une minute, nous avons déjà vu ce schéma ». Nous avons vu à quoi ressemblait le monde lorsqu'aucun de nos ingénieurs ne connaissait le nombre de règles de pare-feu que nous avions. Nous voyons à quoi ressemble notre monde, alors qu'aucun des responsables de nos centres d'opérations ne connaissait le nombre de machines virtuelles que nous possédions, n'est-ce pas, ni le nombre de domaines autoprotégés protégés que nous possédions par rapport à ceux qui ne l'étaient pas. Et donc, avec l'essor des API, nous n'avions que six, sept ou huit ans d'énergie pour créer des API qui ont explosé. La proposition de rentabilité de toutes sortes d'objets, de magasins de données bloqués, d'actifs et de services, et elle a été excellente. Mais tout cela s'est fait sans aucune sécurité. Et maintenant, quand on regarde les choses que nous voyons, je peux simplement continuer pendant des heures là-dessus, par exemple, l'une des choses que je considère comme un CISO fonctionnel, je suis le CISO de notre entreprise, en plus d'être une voix tournée vers le marché sur tous ces sujets. Je suis témoin d'attaques chaque semaine ; maintenant, cela m'étonne. Et je me demande : où est-ce que ça va si nous n'assurons pas la sécurité ? L'avantage des API et de leur association à Zero Trust est qu'elles fonctionnent sur la base d'une confiance implicite et persistante. C'est là que tout commence à se mettre en place. Si j'examine tous les principaux modèles à cinq piliers de Zero Trust, si je regarde les principes de Zero Trust, je me rends compte que ce que John a dit est tout à fait exact. Si j'applique Zero Trust efficacement à tous les autres composants de ma sécurité et de ma technologie, qu'il s'agisse de piles ou de couches, ou quel que soit le nom que vous voulez leur donner. Mais je n'ai rien fait pour sécuriser les API ; j'ai simplement sous-optimisé chaque travail et chaque investissement que j'ai réalisés, car des acteurs malveillants peuvent utiliser les API des API pour servir de proxy à tous les autres types d'attaques. À tous les autres niveaux de la pile de sécurité. Je peux utiliser les API pour publier votre application ; je peux utiliser les API pour créer un compte frauduleusement, prendre le contrôle, s'inscrire, je peux utiliser des API pour extraire la charge utile des données. J'ai vu des situations où des téraoctets de données ont été perdus. Et les méchants ne sont jamais entrés dans les systèmes de base de cette entreprise, entièrement pilotés par API. Et c'est le message que j'ai transmis. Pour revenir à ce que vous disiez à propos de la SP 800 207, ainsi que d'un certain nombre d'autres exigences réglementaires et de conformité, l'absence du terme spécifique API est problématique et difficile, et cela ne durera pas très longtemps. Le NIST a fait des déclarations très claires selon lesquelles il prévoyait de donner des directives spécifiques concernant les API. La FTC, la SEC, l'OCC et les secteurs bancaires travaillent tous sur ces références ou ont déjà supprimé les références spécifiques aux API. Pour ceux qui en douteraient, si vous êtes extrêmement ringard et que vous n'avez rien d'autre à faire, consultez le document de conformité aux risques du modèle du Bureau du contrôleur des devises. Et dans ce document de conformité, il est spécifiquement indiqué : « Si vous utilisez des API tierces pour intégrer des informations dans les modèles d'évaluation de votre entreprise, vous devez en tenir compte, vous assurer qu'elles sont sécurisées et prouver qu'il en est ainsi ». Cela ne signifie pas que nous ignorerons les API pour le reste de notre vie d'adulte. Un régulateur va intervenir, ses autres régulateurs vont intervenir, il va y avoir une vague de demandes de contrôle, et le NIST va répondre à cette norme ISO, mais l'ISO ne peut pas se permettre de ne pas y répondre avec des éléments tels que 222, qui est une spécification qui va supprimer Swift. Et pour ceux qui, encore une fois, ne connaissent pas cet aspect bancaire, Swift ne gère que toutes les transactions commerciales internationales qui ont lieu entre les grands pays et les banques d'investissement, les organisations commerciales qui négocient au-delà des frontières internationales. Et vous savez, l'ISO est déjà consciente du fait que les API sont à l'origine de tout ce trafic. Nous sommes donc à l'aube d'un monde extrêmement différent en ce qui concerne la reconnaissance des API dans l'état actuel. Ma première idée est que vous faites tout le reste correctement dans Zero Trust, vous n'avez pas la sécurité des API correctement, vous n'avez pas Zero Trust. Je suis désolée de vous annoncer cette mauvaise nouvelle, mais elle gagne définitivement du terrain sur le marché.

48:18 Raghu Nandakumara

Tout d'abord, ce que j'aimerais vous demander, et nous y reviendrons dans une seconde, c'est à quoi ressemble Zero Trust pour la sécurité des API ? Mais avant d'en arriver là, j'aimerais savoir que [at] Traceable, vous avez publié, je dirais, l'année dernière, ce que je crois être le premier état de la recherche sur la sécurité des API en collaboration avec le Ponemon Institute. De votre point de vue, quel est le principal point à retenir de ce rapport ? Par exemple, s'il y avait une chose que les responsables de la sécurité des dirigeants devaient en retenir, c'est quoi ?

48:53 Richard Bird

Oui, mets-toi la tête dans le sable. Je ne sais pas Je ne sais pas si je pourrais être plus sensible. Mais je veux dire, c'est vrai. Ce sont les pourcentages, les chiffres et les réponses qui sont ressortis de ce rapport avec Larry Ponemon qui étaient époustouflants pour moi, troublants pour moi. C'est une preuve mathématique de ce dont nous avons parlé plus tôt, à savoir que je sais que j'ai un problème, je ne fais rien pour y remédier. Il y a deux ans, les gens disaient que je n'ai aucun problème de sécurité d'API. J'ai bien rigolé et j'ai trouvé une passerelle. Ce n'était pas une dissonance cognitive. C'était de l'ignorance délibérée. Nous sommes maintenant dans cette phase de dissonance cognitive où il est très rare que je parle à quelqu'un sur le marché et qu'il me dise : « Oui, ne t'inquiète pas pour les API. Je l'ai maîtrisé. » Cependant, la grande majorité des personnes qui me donnent cette reconnaissance disent également : « Oui, mais nous y réfléchissons toujours », « Nous ne faisons rien pour y remédier » ou « Nous ne savons pas quoi faire ». Cela changera évidemment au cours des 12 à 18 prochains mois, qu'il s'agisse d'exigences réglementaires, de nouvelles violations ou quoi que ce soit d'autre. Mais c'est certainement là où nous en sommes aujourd'hui. Et les chiffres relatifs à cet état de sécurité des API, qui se confirment incroyablement, environ 64 % des personnes interrogées ont déclaré : « Oui, j'ai certainement été victime d'une violation ou d'un exploit lié à l'API avec succès ». Et parmi ces 64 %, 75 % ont essentiellement dit : « Et cela s'est produit trois fois au moins ». Je suis très mauvais en maths, donc je ne sais pas 74 %, plus de 75 % des 64 % proviennent d'une population totale de 1 800 entreprises. Mais c'est un chiffre important et, plus important encore, c'est un monde très décentralisé, distribué et incroyablement surconnecté.

50:40 Raghu Nandakumara

Je ne suis pas sûr que vous puissiez voir mon écran, car la statistique que vous avez citée « 60 % d'expérience et de violation liée à l'API et 75 % en ont connu au moins trois » est littéralement celle que je regarde en ce moment. Cela m'amène à la question suivante : Zero Trust et sécurité des API. Lorsque vous appliquez les principes du Zero Trust à la sécurité des API, qu'est-ce que cela signifie ?

51:04 Richard Bird

Permettez-moi d'abord de dire ce que beaucoup de gens pensent à tort que cela signifie. Eh bien, beaucoup de gens pensent à tort que cela signifie que vous devez chiffrer les API. J'ai besoin d'une forme d'authentification, de cryptage et d'une forme de cryptage d'autorisation. Et la raison pour laquelle ils disent que c'est une supposition erronée est, encore une fois, regardons 30 ans d'histoire. Comment s'est déroulé le contrôle de l'authentification et des autorisations pour nous jusqu'à présent ? Il est tout aussi facile de falsifier et/ou de voler des informations d'authentification pour une API, voire plus facilement, que pour un compte et une identité donnés. L'une des toutes premières choses que je me souviens avoir dites à nos cofondateurs lorsque je me suis joint à nous, lorsqu'ils m'ont demandé quelle était ma perception de la sécurité des API, j'ai répondu : « Je l'ai déjà vu ». Et ils disent : « Que verrais-tu ? » Et j'ai dit : « Eh bien, je ne peux pas nommer l'entreprise, une très grande banque était assise dans le centre de commande avec un certain nombre de membres de différentes agences de police et de renseignement, parce qu'un certain pays mal acteur s'était introduit dans nos systèmes. Et ce qu'ils ont découvert, c'est que les clés SSH étaient destinées à une application, à un serveur d'applications, à un appareil, à des communications. Mais si vous vous en emparez, que vous les utilisez comme des êtres humains et que vous les utilisez pour effectuer du trafic latéral est-ouest, vous pouvez infliger d'énormes dégâts à une très grande banque. » C'est bon Et le détournement de clés SSH, bien qu'il ne soit pas exactement comparable à la sécurité des API, se fait sur une base transactionnelle, une comparaison très solide, c'est-à-dire que je peux tirer parti d'une API pour entrer, j'utilise une API pour faire des choses. Et si la seule chose qui m'empêche de le faire, c'est le cryptage de l'authentification sur un JSON ou un JOT, sur l'autorisation, j'adore ça en tant que méchant. Tout d'abord, le chiffrement ne suffira pas à vous aider, ce qui signifie que lorsque le chiffrement n'est plus une solution infaillible, vous devez vous concentrer sur la surveillance continue et la collecte de renseignements sur les menaces concernant le comportement d'une API. Google a récemment publié des recherches sur une API exploitable. Et Google a en fait déclaré : « Eh bien, cette API fonctionne comme prévu ». Et ma réponse a été la suivante : un marteau à griffes est conçu pour la plupart du temps qu'il est utilisé, à enfoncer des clous et à arracher des clous sur des planches. Mais la seule fois où il a été utilisé comme arme du crime, il est également très efficace. Il n'a pas été conçu pour être une arme du crime. Aucun gars qui était assis là à fabriquer son premier marteau à griffes ne dit : « Eh bien, je veux enfoncer des clous, et je pense que nous pouvons nous en servir pour tuer quelqu'un ». Et c'est la nature des API. Les API sont conçues pour faire quelque chose. Mais les API peuvent être utilisées pour faire bien d'autres choses, y compris de nombreuses mauvaises choses. Et si vous ne reconnaissez pas ce principe, Zero Trust n'est pas possible dans votre environnement. Parce que vous allez concevoir des API trop privilégiées plutôt que fiables qui circulent dans votre environnement. Et d'ailleurs, vous ne pouvez rien faire d'autre pour vous protéger d'eux parce qu'ils ont l'air de faire ce qu'ils sont censés faire. Beaucoup de personnes dans le monde de la technologie veulent plus de viande sur les os ; je comprends. Ils veulent passer aux spécifications de conception et d'ingénierie et me montrer comment procéder, et je ne suis pas en désaccord avec le fait que c'est nécessaire, et il y en a beaucoup. Mais le vrai problème, c'est que nous ne sommes pas parvenus à un accord fondamental au plus haut niveau selon lequel il s'agit d'un problème. Je peux vous expliquer comment sécuriser vos API tout au long de la journée. Si tu n'es pas prêt à le faire, peu importe. S'il n'est pas opérationnel, il n'existe pas. Et je pense qu'une grande partie de la discussion d'aujourd'hui vise une fois de plus à convaincre les gens qu'ils n'ont pas simplement un problème. Mais ce problème est existentiel. Ce problème va avoir des conséquences catastrophiques. Et si vous voulez dire que je ne fais que vendre de la peur, de l'incertitude et du doute, et que vous n'y avez pas prêté attention la dernière fois que j'ai vérifié, nous devrions tous avoir peur. Si vous regardez les résultats des défaillances de sécurité aujourd'hui, nous devrions tous avoir peur. Et cela doit être ce qui nous pousse à être plus curieux intellectuellement. Et aussi, pour mettre en œuvre des stratégies de sécurité telles que Zero Trust, je vais en quelque sorte boucler le tout. Comme quand les gens se disputent avec moi à propos de Zero Trust. C'est trop et c'est très compliqué, quel que soit l'argument. Ma réponse est toujours la même : « Comment fonctionne la confiance implicite et persistante pour vous ? » C'est vrai, car à moins d'avoir une alternative au statu quo, ne me dites pas à quel point Zero Trust est difficile, car vous ne saurez même pas à quoi cela ressemble avant de vous lancer dans cette aventure. Sinon, tu ne fais que théoriser. Et je sais sur quoi vous travaillez, quelle est votre hypothèse de base maintenant que vous travaillez ; cela ne fonctionne pas.

56:07 Raghu Nandakumara

Je pense que c'est juste pour résumer ce que vous avez dit à propos du type de sécurité des API, et c'est un peu comme cette division entre ce pour quoi elle est conçue et ce que vous pouvez faire réellement grâce à elle. Cela vous ramène à un parallèle que John Kindervag cite souvent à propos des règles de pare-feu. De mauvaises choses se produisent dans les limites autorisées, car c'est ce que les attaquants exploitent. Avant de terminer, à quoi ressemble l'avenir du Zero Trust et de la sécurité des API de votre point de vue ?

56:52 Richard Bird

Eh bien, je pense à l'avenir, et il y a un argument selon lequel je suis trop optimiste quant à ce que je suis prêt à partager. Mais j'y crois fermement, c'est-à-dire que je crois qu'il existe un potentiel d'avenir avec Zero Trust, c'est-à-dire l'état utopique selon lequel si vous pouviez appliquer Zero Trust au plus grand pourcentage de votre patrimoine numérique, à chaque couche, quelle que soit votre architecture hybride, ou si vous êtes toujours sur site, peu importe. Vous pouvez appliquer ces principes Zero Trust à chaque élément du composant. Et vous placez tout dans la couche virtuelle ultime, l'espace de la couche 7. Je pense que nous pouvons réellement réussir et la sécurisation de la couche 7, qui concerne la sécurité des API, jouera un rôle très important à cet égard. Je pense que le contrôle d'identité avancé de prochaine génération aura un rôle important à jouer à cet égard. Je pense qu'il y a d'autres éléments qui seront mis en évidence pour la septième couche. Mais si nous arrivions à un état où ces principaux composants étaient entièrement verrouillés dans un cadre Zero Trust, nous pourrions consacrer toutes nos ressources et nous concentrer pleinement sur cette couche sept. Je pense donc que nous sommes dans une situation où nous sommes sur un pied d'égalité avec les acteurs malveillants qu'un simple reportage sur un autre groupe de serveurs verrouillés à cause d'un ransomware.

58h30 Raghu Nandakumara

J'adore ça. Et je pense que c'est ce que tu as dit. Aujourd'hui, les attaquants par rançongiciels n'ont même pas besoin d'être aussi performants pour réussir. Alors, faisons-les travailler beaucoup plus dur. Donc, s'ils veulent réussir, ils ont intérêt à être très, très bons.

58:49 Ricard Bird

Un autre sujet qui sera abordé un autre jour, mais qui revêt une grande importance : examinons les modèles physiques et la sécurité, puis examinons-les dans le numérique. Par exemple, les gens peuvent argumenter autant qu'ils veulent, mais si vous compliquez la tâche des acteurs malveillants, vous améliorez la sécurité et vous réduisez les risques. Oui, si vous n'êtes pas d'accord là-dessus, demandez-moi combien de palais de justice vous avez visités ne sont pas équipés de grandes barrières en ciment, de pylônes et de toutes sortes d'autres dispositifs de sécurité physiques qui les bloquent actuellement. C'est parce que nous avons retenu la leçon que nous devons ralentir les gens avant qu'ils ne fassent de mauvaises choses dans ce bâtiment. Nous devons appliquer les mêmes types de modèles. Et j'aime beaucoup la façon dont tu l'as formulé. Rendez les choses plus difficiles pour les méchants. Conduisez-les dans des espaces où vous aurez alors une chance de les affronter du point de vue de la sécurité, mais ne leur donnez pas le terrain facile. Et je pense que c'est ce que fait Zero Trust. Je pense que Zero Trust élimine le terrain facile.

59:42 Raghu Nandakumara

J'adore ça. J'allais vous demander de partager votre analogie préférée avec Zero Trust, mais je pense que c'est une déclaration tellement puissante pour terminer. Je dois te dire merci beaucoup, Richard. Cela a été un réel plaisir de discuter avec vous, et je pense que le temps que nous avons passé à converser n'est presque pas suffisant. Merci donc encore, Richard Berg, directeur de la sécurité chez Traceable AI. J'encourage tout le monde à consulter le rapport sur l'état de la sécurité des API qui est disponible sur le site web Traceable AI et à approfondir l'état de la sécurité des API et la manière dont Zero Trust et l'application de Zero Trust peuvent contribuer à l'améliorer. Richard, merci.

1:00:25 Richard Bird

Merci, ça vous a vraiment plu.

1:00:27 Raghu Nandakumara

Merci d'avoir écouté l'épisode de cette semaine. Nous reviendrons avec notre prochain épisode dans deux semaines. En attendant, pour plus de ressources sur Zero Trust, rendez-vous sur notre site Web, www.illumio.com et retrouvez-nous sur LinkedIn et X en utilisant les liens figurant dans nos notes d'émission. C'est tout pour aujourd'hui. Je suis votre hôte Raghu Nandakumara et nous vous en recontacterons bientôt.

‍