Recadrer la sécurité en tant qu'avantage stratégique

Clarke : (00:05)
Merritt, merci beaucoup de vous être jointe à nous aujourd'hui.

Merritt : (00:08)
Merci de m'avoir invitée.

Clarke : (00:09)
Pourriez-vous me parler un peu de votre parcours ? Qu'est-ce qui vous a amenée chez AWS et à ce que vous faites dans votre fonction actuelle ?

Merritt : (00:15)
Oui. Je travaille chez AWS depuis presque quatre ans. Je viens de l'administration américaine où je m'occupais de la sécurité pour le compte des Américains. J'y ai travaillé dans les trois agences. Je suis venue à la sécurité car j'avais l'impression que nous devions faire face à de grandes thématiques, mais que nous n'avions pas de véritables moyens d'en tenir compte. J'ai donc obtenu un diplôme de droit, en partie parce que je savais que ce serait l'un de nos enjeux. Et j'ai aussi le sentiment que ces questions en arrière-plan seront plus importantes que de déterminer cette menace à ce moment précis, ou cet acteur, etc. Et par conséquent, j'ai fini par travailler dans ce que je considère comme des domaines peu attirants de la sécurité. C'est-à-dire ce qui se trouve au niveau de l'infrastructure, mais qui compte beaucoup en coulisses. Je pense que c'est ce qui m'a vraiment poussée à atterrir ici.

Clarke : (01:08)
C'est passionnant. Pouvez-vous m'en dire un peu plus sur le bureau du responsable de la sécurité informatique et sur son rôle dans l'ensemble des processus AWS ?

Merritt : (01:17)
Oui. J'occupe donc la fonction de principale du bureau du responsable de la sécurité informatique. Le bureau du responsable de la sécurité informatique (CISO, Chief Information Security Officer) d'AWS ressemble beaucoup à celui de n’importe quelle autre entreprise. Steve Schmidt, mon patron, s'occupe non seulement de la sécurité interne quant à la manière dont AWS se protège, mais aussi de la façon dont nous assurons la sécurité de tout ce que nous proposons en tant qu'entreprise. Il s'agit là d'un ensemble de livrables intéressants à prendre en compte, car vous réfléchissez à la manière de mettre en place des garde-corps et de permettre à vos employés d'avoir un minimum de friction et d'être eux-mêmes des équipes de développement. Et puis vous essayez aussi de faire en sorte que vos équipes de développement fassent la chose la plus sûre, de la manière la plus simple et la plus sécurisée. C'est donc là que mon rôle me permet d'avoir une certaine empathie et une certaine crédibilité lorsque je m'adresse aux clients, car environ la moitié de mon travail consiste à essayer d'améliorer notre sécurité chez AWS et l'autre moitié à parler aux clients. Il s'agit parfois d'une prise de parole en public, mais le plus souvent, il s'agit de conversations entre CISO, de discussions avec des groupes de sécurité et de la recherche de moyens de renforcer la maturité de leur entreprise. Bien souvent, la sécurité est l'un de ces facteurs clés qui leur permettront d'avancer à un rythme plus soutenu, plus rapide et plus mature. Toutefois, je pense que le revers de la médaille est que la sécurité peut souvent être perçue comme un obstacle. Et je pense que ce n'est pas pertinent. Non seulement parce que les équipes de sécurité doivent évoluer et ne plus dire non, mais aussi parce que de nos jours, surtout dans le cloud, comme vous le savez, dès que vous commencez à développer quoi que ce soit, vous articulez votre identité et vos autorisations, mais aussi votre mode de construction par rapport au reste de votre architecture et au reste de l'internet. Dès lors, il y a des propriétés de la sécurité inhérentes à tout ce que vous créez. Cela signifie que nous devons intégrer la sécurité dans nos conversations et expliquer à nos clients notre façon de procéder.

Clarke : (03:23)
D'accord. Ainsi, dans vos conversations avec les CISO des clients, j'imagine que cela peut déborder sur vos autres responsabilités, car j'imagine qu'un CISO pourrait dire : « J'aime le produit X ou Y, mais j'aimerais qu'il fasse ceci ». Cela fait partie de la pile de sécurité dont vous êtes également responsable. De quelle manière au cours d'une conversation de ce type une demande d'un client peut-elle être transmise aux équipes chargées des produits des services de sécurité pour être mise en œuvre dans une fonctionnalité ?

Merritt : (03:51)
Comme vous le savez, les équipes de service créent, mettent en œuvre et déploient en permanence de nouvelles fonctionnalités. Il n'est donc pas vraiment compliqué de suivre ce qu'elles ont décidé ou pu investir dans l'offre. Il s'agit plutôt de savoir comment nous résolvons le problème et si nous ne le résolvons pas comme il se doit, je pense que c'est une conversation que je ramène chez nous et sur laquelle je travaille. Toutefois, une grande partie de mon travail consiste à comprendre d'une part ce que le client demande vraiment et d’autre part comment l'aider à atteindre le stade de maturité supérieur ou comment l'amener à un meilleur stade. Et l'autre partie, c'est comment on fait ? Je pense qu'une grande partie de la valeur ajoutée que les clients attendent vraiment d'une conversation avec moi se résume à « Comment votre équipe concilie-t-elle cela ? ». Bien que je ne croie pas aux jeux à somme nulle, je pense qu'il est utile de faire preuve d'une véritable empathie. 

Clarke : (04:51)
Bien dit. Donc quand les clients demandent, « Comment AWS fait X ? ». Quelles sont les questions les plus courantes du genre « Comment AWS fait…» ? Du point de vue de la sécurité, est-ce ces types de questions que vous recevez des clients ?

Merritt : (05:07)
L'innovation est de loin la plus importante. « Comment vos équipes de développement innovent-elles et comment votre équipe de sécurité entretient-elle une relation avec vos équipes de développement qui ne soit pas conflictuelle ? ». Je suis convaincue que c'est un aspect vraiment remarquable de notre activité car, si l'on peut dire ce que l'on veut du rythme d'innovation que nous poursuivons sans relâche, cela signifie parfois que nous sortons des versions à une cadence très rapide, ou que les gens ont du mal à comprendre l'intérêt des nouvelles choses. Mais en fin de compte, ce que nous faisons, de par la nature de certains de ces mécanismes, est comparable à une équipe de deux pizzas, qui a une résonance sécuritaire, vous voyez ? Ainsi, dans le cadre d'une équipe de deux pizzas, qui signifie que vous êtes cloisonnés intentionnellement en quelque sorte, pour prendre rapidement une décision métier, vous avez une certaine prise de décision métier concernant la sécurité. Ainsi, seule une petite poignée de personnes saura comment les composants fonctionnent en arrière-plan. Cela concerne les éléments de sécurité de notre mode de fonctionnement. Ce dont nous parlons vraiment, c'est la manière dont nous avons intégré la sécurité dans les produits que nous proposons. Il ne s'agit donc pas tant de s'identifier à eux en tant qu'équipe de sécurité chargée de réformer cet appareil. Il s'agit en fait pour eux de dire : « Comment avez-vous transformé votre entreprise en une entreprise qui vit et respire la sécurité dans le cadre du livrable que vous vendez ? ».

Clarke : (06:38)
C'est très clair. Ainsi, lorsque je m'entretiens avec des clients, l'une des choses qu'ils ont tendance à soulever, et j'imagine que vous êtes également confrontée à la même question, c'est « Je comprends la valeur de DevSecOps. Je comprends l'intérêt de consacrer des ressources à la sécurité technique et opérationnelle et à tous les autres composants de la sécurité. Mais comment puis-je réellement créer une organisation de sécurité de classe mondiale à la manière d'AWS ? »

Merritt : (07:05)
Voilà. Je pense que cette question peut revêtir de nombreuses formes, n'est-ce pas ? Cela pourrait être : « Je ne sais pas si nous avons déjà exercé notre plan de réponse aux incidents » ou « Je ne sais pas si nous avons un plan de réponse aux incidents ». Et encore une fois, je pense qu'une grande partie de tout cela concerne les contrôles qui s'appliquent au cycle de vie de vos ressources. J'allais faire référence à l'infrastructure, mais c'est quelque chose que vous créez à travers ce processus, non ? Depuis vos contrôles de protection, de détection et de remédiation. Et bien évidemment, l'un des éléments auquel nous revenons toujours est l'automatisation. Ainsi, par exemple, dans notre équipe de sécurité AWS, nous ne fermons jamais un dossier d'incident avant d'avoir mis au point une solution, dans la mesure du possible. Ainsi, l'automatisation n'est que de simples paroles jusqu'à ce que vous la mettiez en œuvre de manière observable. Mais en fin de compte, ce que nous recherchons actuellement, ce sont des moyens de véritablement mettre les opérations à l'échelle. Et grâce à ces contrôles de protection, de détection et de remédiation, notre service de surveillance 24 heures sur 24 est une personne qui surveille toutes les automatisations. Il y a donc une grande liberté qui découle de l'adoption de cette nouvelle génération de centre d'opérations de sécurité. Ne vous méprenez pas, je sais que c'est pour une sorte de ville sur la colline, mais à bien des égards, il faut bien commencer quelque part. Vous obtiendrez des résultats. Nous avons donc constitué une équipe de sécurité en résolvant de grands problèmes, mais aussi de petits. Il faut bien commencer quelque part, non ? Engagez des personnes qui aiment l'automatisation, engagez une équipe de sécurité diversifiée qui pense différemment, qui résout les problèmes avec un code différent, avec une automatisation différente, et ensuite, il faut aussi obtenir l'adhésion de votre direction. C'est extrêmement important pour ce processus où nous parlons vraiment de l'investissement de l'entreprise, ou plutôt de l'entité, car le secteur public fonctionne à peu près de la même manière en termes d’investissement dans le processus de sécurité. Et encore une fois, cela doit être mis en œuvre par le biais de moyens et de comportements spécifiques. Alors quand les gens viennent me voir pour me demander « Comment mettre en place une équipe de sécurité de classe mondiale ? ». Ou « Comment créer une culture de l'innovation ? ». Voilà ce que vous faites de manière répétée. Il y a des choses auxquelles nous pouvons nous identifier et sur lesquelles nous pouvons nous appuyer. Par exemple, dans ce DevSecOps, nous intégrons un ingénieur en sécurité dans les équipes dans une certaine proportion, actuellement d'un huitième, mais qui pourrait être… Cela peut varier à la hausse ou à la baisse, puis on évalue si le chiffre est adéquat. Nous revenons sur la cause de l'erreur chaque fois que quelque chose se produit alors qu'elle n'aurait pas dû arriver ou que les choses ne se déroulent pas exactement comme prévu. Et d'ailleurs, les VP doivent participer à ces réunions sur une cause de l'erreur. On n'y envoie pas un jeune ingénieur pour assumer la responsabilité. Nos véritables objectifs sont le fait de disposer de ce type d'écosystème de responsabilité, non pas pour les individus qui en font les frais, mais pour l'organisation, mais aussi la croissance de la courbe d'apprentissage au fil du temps. Et c'est quelque chose qui, selon moi, n'arrive pas par hasard. Vous devez mettre ces mécanismes en place.

Clarke : (10:22)
Et je suppose que l'astuce consiste à développer ce mécanisme qui renforce le comportement que vous recherchez.

Merritt : (10:28)
C'est tout à fait ça. Par exemple, si vous choisissez de rendre les autorisations de vos employés très ouvertes, ce que nous faisons chez Amazon, ce qui, soit dit en passant, est une décision métier délibérée, vous devrez alors avoir une journalisation et un suivi très fins de ce qui se passe, du moins c'est ce que nous avons choisi d'avoir. Ensuite, vous devez disposer de seuils et de remontées irréprochables qui se déroulent selon un calendrier, et encore une fois cela signifie que vos dirigeants doivent s'investir, car ils doivent savoir qu'ils vont répondre au téléphone pour assurer la sécurité. 100 % des cadres diront qu'ils se soucient de la sécurité, mais ce qui compte c'est le fait de savoir qu'ils devront se battre pour cela et qu'ils devront comprendre qu'ils seront appelés à le faire. Et cela signifie également que l'équipe de sécurité aura un certain rôle tissé dans l'entreprise elle-même.

Clarke : (11:26)
D'accord. Vous avez mentionné les investissements un peu plus tôt dans votre réponse, n'est-ce pas ? Un grand nombre de CISO de nos clients et de nos cadres supérieurs viennent nous voir et nous disent : « Nous devons investir dans nos capacités ». Du point de vue de la sécurité, AWS a été très clair au fil des ans sur le concept des cinq éléments fondamentaux de la référence de sécurité minimale. Il s'agit de l'identité, des contrôles de détection, de la sécurité de l'infrastructure, de la protection des données et de la réponse aux incidents. Ainsi, lorsqu'un CISO d'un client annonce : « Je dispose d'un budget limité, et d'un personnel limité, mais je dois respecter ces cinq fondamentaux. Où dois-je commencer mes investissements, où est le meilleur rapport qualité-prix pour ces cinq points ? »

Merritt : (12:09)
Bon nombre de CISO me demandent : « Dois-je commencer avec une charge de travail ou une centaine ? ». Vous voyez ? Et je pense que la réponse est de commencer quelque part et de donner du sens. Commencez par un nombre illimité de charges de travail, mais faites-les ouvertement. Faites-les comme ceux qui se trouvent sous un microscope de sécurité, parce que je crois que vous en tirerez les gains de sécurité qui ont réellement un différentiateur métier pour votre entreprise ou votre entité du point de vue de la plate-forme. Je vais juste revenir en arrière, et ça va sembler dérisoire, mais rappelons-nous ce qu'est le cloud. Il y a 20 ans, on s'intéressait à ces cinq fondamentaux en vérifiant simplement si des serveurs malveillants se trouvaient sous les bureaux. On ne fait plus ça, du moins pas si vous êtes dans le cloud. Et l'une des raisons pour lesquelles nous savons qu'il s'agit d'un gain de sécurité est qu'AWS assume la responsabilité de ces couches inférieures de la pile. Tirer parti du cloud pour assurer la sécurité à l'échelle du cloud est l'une des urgences que les clients n'exploitent vraiment pas. S'ils ne disposent que d'un budget limité, c'est une raison de plus pour qu'ils arrivent à ce stade où ils peuvent tirer parti de cette échelle. Cela dit, si je devais choisir, je dirais que l'identité est vraiment complexe. Je n'ai pas encore rencontré un client qui me dise : « J'adore mon fournisseur d'identité. Et je pense que nous nous en sortons très bien. »

Clarke : (13:40)
Donc des investissements dans l'identité, si vous êtes à court d'argent ?

Merritt : (13:45)
Je pense que si vous êtes à court d'argent, vous devriez discuter avec l'entreprise de ses objectifs, puis de la raison pour laquelle la sécurité est un facteur de différenciation. Et je ne parle pas seulement de la sécurité autour de ce que vous produisez, mais de celle qui fait partie intégrante de votre produit. Donc, si vous êtes un détaillant, si vous êtes une société pétrolière et gazière, etc. Qu'il s'agisse de l'automobile, de l'industrie pharmaceutique, des médias et des divertissements, des fusions et des acquisitions, une partie de ce dont les gens se soucient aujourd'hui, à juste titre, c'est de la sécurité des activités. Il ne s'agit donc pas seulement des personnes qui proposent des produits de sécurité et qui disent « Est-ce que vous gérez nos données en interne dans vos fonctions de RH ? ». Il s'agit en fait de savoir comment vous assurez la sécurité en tant que partie intégrante de votre produit. Et je pense qu'il n'y a aucun moyen de contourner cela. Cela doit être lié à la manière dont vous créez votre entreprise et des objectifs que vous atteignez. Et pour en revenir à votre point, le budget que vous visez doit en tenir compte. Aussi, je ne pense pas que nous devions encore considérer la sécurité comme un centre de coûts. J'en ai vraiment assez de ça, car il s'agit en fait d'un accélérateur de l'activité et d'un moteur de l'activité, et que personne ne veut faire quoi que ce soit si ce n'est pas sécurisé, personne ne veut acheter quoi que ce soit si ce n'est pas sécurisé, et personne ne veut interagir avec l'entreprise ou avec un gouvernement si ce n'est pas sécurisé. Et donc franchement, c'est un non-sens si vous n'y êtes pas. Je sais que la cible est mouvante, parce que c'est un processus sur lequel nous travaillons, mais vous devez vous battre avec les meilleurs d'entre nous.

Clarke : (15:24)
Donc, dans l'optique où la sécurité est un accélérateur de l'activité, comment un CISO et une organisation qui considère l'organisation du CISO comme un centre de coûts peuvent-ils faire passer ce message au conseil d'administration ou aux autres décideurs de leur organisation ?

Merritt : (15:42)
Il y a plusieurs éléments, n'est-ce pas ? L'un deux est la transformation générale qui se produit au sein des entreprises lorsqu'elles choisissent de se développer. En réalité, je pense que les entreprises en général sont beaucoup trop obnubilées par le coût qu'implique le changement. Et au lieu de cela, elles n'examinent pas le coût qu'engendre un statu quo. Vous savez, à ce stade, vous devriez vous demander ce qu'il vous en coûte de rester là où vous êtes et ce que vous payez maintenant pour ne pas avoir fait bouger les choses et ne pas avoir fait les choses que vous savez nécessaires. Et franchement, je comprends qu'il faudra un peu d'audace ou d'énergie positive pour y arriver, mais cela commencera à porter ses fruits presque immédiatement. Par ailleurs, cela deviendra également l'un des moyens grâce auxquels votre organisation pourra réellement se développer en tant qu'entreprise. Et au fond, je pense que tout retard à cet égard n'est qu'une perte de temps. Et par la même occasion, pour répondre à votre question, je pense que les gens qui considèrent cela comme un centre de coûts font partie du passé. 

Clarke : (16:53)
Voilà. Je pense que vous avez soulevé un point important, à savoir que le risque de ne pas faire quelque chose est aussi imprudent que certains autres risques que les entreprises examinent.

Merritt : (17:01)
Je ne dirais pas aussi imprudent, mais souvent plus cher. Et quand vous vous adressez au conseil d'administration, c'est l'une des choses auxquelles il faut penser. Selon moi, lorsque les gens parlent des métriques de sécurité, ils les ont souvent transformées en jeux. Ils disent : « Nous avons dit que la semaine dernière, nous avons observé 100 signaux d'alerte, tandis que cette semaine, il n'y en a que 70. » Et c'est comme si ces signaux n'étaient ni ici ni là. Bien entendu, ces chiffres sont artificiels. Je viens de les inventer. Mais le fait est que vos métriques de sécurité doivent permettre de savoir si vous vous améliorez ou non au fil du temps. Et si ce n'est pas le cas, c’est qu’elles ne sont pas pertinentes. Parce que qui êtes-vous vraiment en train de transformer en jeu ? C'est à vous d'être dans la mêlée.

Clarke : (17:50)
Les rançongiciels sont actuellement un thème important. Ils sont une grande préoccupation pour les clients. Je sais que vous avez une certaine expertise dans ce domaine. Quels conseils pouvez-vous donner aux organisations de sécurité de vos clients quant à ce qu'elles doivent faire pour se préparer à affronter un rançongiciel ?

Merritt : (18:07)
Oui. Il est évident que ce thème a été très médiatisé ces derniers temps. Bien que les rançongiciels ne soient pas nouveaux. Cela remonte au moins à 1989. Il y a eu une conférence où un mauvais acteur distribuait des lecteurs de disques étiquetés « AIDS », parce qu'il s'agissait d'une conférence sur la santé. Ensuite, on l'a appelé « rançongiciel AIDS», car lorsque vous l'insériez dans votre lecteur de disque, il chiffrait vos fichiers et vous demandait d'envoyer un chèque de 89 USD à une boîte postale au Panama. Donc je suppose que le rançongiciel lui-même n'est pas nouveau en théorie, mais il l'est dans la pratique, en raison de l'avènement des cryptomonnaies et de la possibilité de monétiser le fait qu'ils ont pénétré dans votre réseau.

Clarke : (18:58)
Et le rançongiciel est un service, n'est-ce pas ?

Merritt : (19:01)
Oui. Et sa marchandisation est certainement un facteur. Et puis, franchement, le fait que les régimes de confidentialité des données ont rendu très coûteux pour les entreprises le fait d'avoir été victimes d'une violation. Il y avait une forme de rançongiciel où ils verrouillent réellement vos données et une autre où ils appliquent la technologie xFill. Et même si vous possédez des sauvegardes, ils menacent de révéler qu'ils ont obtenu l'accès. Cela pourrait en soi être considéré comme une violation, surtout si vous traitez des données réglementées, comme nous le faisons tous. Je pense donc que le contexte dans lequel cela se produit est pertinent ici. Mais selon moi, pour répondre à votre question, il n'y a pas de solution miracle pour les rançongiciels. Les rançongiciels exigent que vous mettiez de l'ordre chez vous. Il s'agit donc tout simplement de minimiser la probabilité que l'on accède à vos systèmes. Donc des choses comme l'identité et les correctifs, le moindre privilège et la segmentation. Et puis aussi disposer de ces sauvegardes inaltérables. Donc des choses comme AWS Backup ou Cloud and Door qui vous permettent d'avoir un point de sauvegarde frais dans le temps, ou une capacité de restauration de la sauvegarde. 

Clarke : (20:23)
Aussi, pour rester dans le domaine des sujets brûlants pour les clients, citons également le concept de confiance zéro. Alors, que signifie la confiance zéro pour vous, comment l'expliquer aux clients et comment AWS peut-il les aider à atteindre la confiance zéro si, en fait, c'est quelque chose qu'ils doivent faire ?

Merritt : (20:42)
Oui, voyons ça. Je pense que la confiance zéro peut être un cadre conceptuel utile pour envisager vos contrôles de sécurité. Vous voyez ? Je pense… Avant toute chose, demandez à n'importe qui ce que signifie la confiance zéro et vous obtiendrez une définition différente. Selon moi, la confiance zéro n'implique pas que cette tasse de café n'est pas connectée à Internet, mais qu'il faut réduire, peut-être jusqu'à zéro, le niveau de confiance que nous devons accorder à un acteur du réseau en fonction de la position qu'il y occupe. Donc en gros, qu'il s'agisse de logiciels ou d'humains, nous devrions réduire notre dépendance à l'égard de cette idée de périmètre traditionnel. Mais bien entendu, le périmètre est mort, vive le périmètre, non ? Et je pense que dans le cloud, et franchement chez AWS, notre approche ne consiste pas à faire un choix binaire entre les contrôles traditionnels centrés sur le périmètre comme un VPN ou un VPC et les contrôles fins centrés sur l'identité qui fonctionnent à l'intérieur de ceux-ci comme les groupes de sécurité, Naples, etc. Mais bien au contraire, il s'agit de faire en sorte que ces éléments fonctionnent les uns avec les autres, qu'ils se complètent et qu'ils soient conscients les uns des autres. Un exemple serait donc une stratégie de point de terminaison d'un VPC, où il y a à la fois le périmètre et les autorisations affinées. Ces éléments sont conscients de se compléter les uns les autres et sont capables de raisonner grâce à certains de nos outils qui sont inhérents au cloud, parce que nous faisons de l'infrastructure en tant que code. Vous pouvez faire de la sécurité en tant que code. Ainsi, par exemple, l'analyseur ou l'inspecteur d'accès peut déterminer l'accessibilité du réseau sans envoyer de paquet sur le réseau. Donc l'idée est que vous devriez coupler ces types de défense en profondeur, je suppose, mais cela semble dépassé. C'est comme dire: « Mettez le verrou à la porte et à la fenêtre. » Non, ils servent des objectifs différents. Et en réalité, ils font également partie de la même logique que celle que nous utilisons lorsque nous raisonnons autour de la sécurité.

Clarke : (22:57)
Merci Merritt de nous avoir accordé votre temps aujourd'hui. Une dernière réflexion ?

Merritt : (22:59)
Vous savez, je pense que souvent, les gens viennent me voir avec ce qu'ils pensent être des questions profondes et techniques du CISO. En fait, ce qu'ils demandent vraiment, c'est : « Comment faire pour que mon organisation ait l'élan et les moyens de faire changer les choses ? ». Et je pense que cela se résume à l'investissement, tant au sens littéral que métaphorique, que consent une entité pour que la sécurité devienne une priorité. Ainsi, lorsque nous affirmons que la sécurité est un « job zéro », un prérequis absolu, ou tout autre aphorisme que nous utilisons, nous ne souhaitons pas en faire une devise. Nous voulons que cela fasse partie intégrante de la culture de toutes nos actions. L'un des moyens d'y parvenir est de faire en sorte que Steve Schmidt dépende directement du PDG et que la sécurité ne soit jamais surclassée ou surpassée par d'autres intérêts métier. Je pense que dans le cas des personnes qui espèrent imiter une partie de la hiérarchisation que nous avons été en mesure de montrer, la façon de faire est tout simplement de le faire. Et le moyen d'y parvenir est de commencer. Et la façon de commencer est de faire en sorte que votre entreprise s'aligne sur ces objectifs. Et l'un des autres moyens d'y parvenir, ou l'un des moyens de permettre à votre organisation de s'en rapprocher, est de mettre en place cette équipe de classe mondiale. Il est évident que les talents sont difficiles à dénicher pour l'instant. Et je souhaite que nous embauchions des personnes qui pensent différemment, qui ont une apparence différente et qui codent différemment, parce que c'est véritablement la chose à faire pour le secteur et pour l'ensemble de l'écosystème. Vous savez, la sécurité a de nombreux points de contact avec les communautés vulnérables, avec les façons dont nous interagissons avec la technologie, dont nous résolvons les problèmes et rendons les entreprises et les entités plus fortes. Si ce n'est pas ici, alors où ? Je dirais donc qu'il s'agit d'un appel à l'action pour nous tous : faites en sorte que votre lieu de travail soit inclusif et que vos entités soient plus fortes.

Clarke : (25:02)
Merritt. Merci beaucoup pour votre éclairage et de nous avoir accordé du temps aujourd'hui.