L’évolution du leadership en matière de sécurité au sein de la haute direction

Clarke Rodgers (00:09) :
Chris, merci beaucoup de m’avoir rejoint aujourd’hui.

Chris Rothe (00:11) :
Merci de m’avoir invité.

Clarke Rodgers (00:13) :
Pouvez-vous me parler un peu de vous, de votre parcours et de votre rôle chez Red Canary ?

Chris Rothe (00:17) :
Je suis le directeur technique et le cofondateur de Red Canary. Nous sommes spécialisés dans la réponse aux détections. Avant de créer l’entreprise, je travaillais dans le traitement des données satellitaires, qui vise à « collecter de grandes quantités de données et y appliquer des algorithmes intéressants ». Les informations dégagées sont ensuite présentées à des analystes afin d’éclairer leurs décisions, ce qui est d’ailleurs très similaire à notre activité en matière de cybersécurité.

Clarke Rodgers (00:39) :
Vous travaillez dans le secteur de la cybersécurité depuis un certain temps. Or, nous plaisantons souvent en disant que le CISO était autrefois au sous-sol et qu’il siège maintenant au conseil d’administration. Comment analysez-vous cette évolution ?

Chris Rothe (00:49) :
Le plus important, selon moi, c’est qu’il est passé à un rôle beaucoup moins technique et largement plus politique, ce qui est essentiel pour promouvoir la sécurité au sein de l’organisation et l’intégrer dans la culture. En outre, pour des personnes comme nous qui possèdent des plateformes SaaS, il s’agit également d’un rôle très orienté vers la clientèle, qui consiste à faire en sorte que les clients aient confiance dans la protection de leurs données.  

Clarke Rodgers (01:16) :
Lors de discussions avec des clients dans le cadre de votre rôle, comment présentez-vous la valeur commerciale de la sécurité ?

Chris Rothe (01:21) :
Le risque commercial est en fin de compte une question de risque financier. Il peut avoir différentes formes selon votre secteur d’activité. Si vous travaillez dans le secteur des services financiers, votre réputation est en jeu et vous devez faire en sorte que les gens vous confient leur argent. Que vous travailliez dans le secteur de la fabrication, des soins de santé ou tout autre secteur de ce type, le risque encouru est opérationnel : faire en sorte que vos machines fonctionnent en permanence et que des gens restent en vie dans le secteur des soins de santé.

Pour que ces conversations puissent être vraiment fructueuses, l’enjeu principal est donc d’en arriver à parler d’argent et de réduction du risque par dollar.

Parfois, ce n’est pas ce dont les gens veulent parler. Ils veulent parler des aspects techniques et de la manière dont vous pouvez les aider à réduire le nombre d’incidents de sécurité, entre autres sujets de notre domaine. Et c’est super aussi. En fin de compte, tout tourne à un moment ou à un autre autour de l’argent.

Clarke Rodgers (02:06) :
En interne chez Red Canary, comment améliorez-vous l’efficacité de l’équipe de sécurité et comment faites-vous en sorte qu’un développeur isolé se soucie de la sécurité et y pense au quotidien ?

Chris Rothe (02:22) :
C’est extrêmement important pour nous. En tant qu’entreprise de sécurité, nous sommes en quelque sorte tenus de respecter des normes plus élevées. Il est donc important que tous les membres de l’entreprise se soucient de la sécurité de nos activités et de celles de nos clients. Au fil des ans, nous avons pris certaines mesures pour faire en sorte que cela soit lié au rôle de chaque employé, notamment en intégrant, dans notre cycle de vie de développement de logiciels, des spécialistes de la sécurité de produits qui font partie de chaque équipe Scrum. Ils participent donc à la planification du sprint et en amont. Il ne s’agit pas de faire appel à l’équipe de sécurité au terme d’un projet de conception. Elle doit en faire partie de A à Z et y jouer un rôle central.

L’autre mesure consiste à faire en sorte que les contrôles de sécurité et l’analyse statique, ou toute autre activité similaire, se déroulent dans le giron des développeurs. Elle est intégrée au pipeline du CI/CD. N’y réfléchissez pas par deux fois. Toutes ces tâches doivent avoir lieu avant la fusion du code. Cela permet de s’adapter aux développeurs, ce qui n’est généralement pas le cas.

Clarke Rodgers (03:17) :
Il est généralement assez difficile de trouver des talents en matière de sécurité. Vous devez soit les embaucher, soit les conserver, soit les former. Quelles stratégies avez-vous utilisées chez Red Canary pour développer les compétences et les connaissances de vos professionnels de la sécurité ?

Chris Rothe (03:31) :
Notre objectif est de faire en sorte que les professionnels de la sécurité de notre équipe n’aient pas à se contenter de tâches répétitives et « indifférenciées », pour reprendre un terme d’AWS.

Clarke Rodgers (03:40) :
Bien sûr.

Chris Rothe (03:40) :
Ils ne doivent pas y consacrer plus de 60 % de leur journée. Soixante pour cent représente en quelque sorte le seuil magique à partir duquel ils commencent à s’ennuyer face à la nature répétitive de ce travail. Nous maintenons ce cap grâce aux outils et à l’automatisation mis à leur disposition, à la recherche de modèles répétitifs et à la création (via l’IA, le ML, etc.) d’outils qui prennent en charge les tâches lourdes indifférenciées afin que les professionnels puissent se concentrer sur l’essentiel.

Clarke Rodgers (04:09) :
Vous avez parlé d’outils et d’automatisation. L’IA générative est en vogue ces derniers temps. Qu’en pensez-vous à la fois en tant que professionnel de la sécurité quant à la gestion des risques liés à son utilisation, mais aussi en tant que chef d’entreprise désireux de tirer parti des avantages qu’elle peut vous offrir ? Pourriez-vous nous en dire un mot ?

Chris Rothe (04:31) :
Du point de vue des risques, je pense que nous nous sommes lancés en veillant à disposer des bonnes mesures de protection pour éviter d’utiliser du contenu créé par une IA dont nous ignorons le propriétaire. Nous avons mis en place des barrières de protection à cet effet.

Mais d’une manière générale, nous voulons que chaque membre de l’équipe Red Canary utilise l’IA générative d’une manière adaptée à son rôle. Prenons l’exemple du vendeur qui, suite à une excellente conversation téléphonique avec un client, doit rédiger un e-mail de suivi : nous devons accélérer ce processus et améliorer la qualité de cette communication. En fin de compte, c’est bénéfique pour le client et pour vous, car la tâche vous a pris cinq minutes au lieu d’une heure. Voilà notre approche, qui consiste à faire en sorte que tout le monde puisse utiliser l’IA générative en toute sécurité.

Mais je pense que nous n’en sommes qu’à nos débuts pour ce qui est des dangers et des défis associés à cette technologie ainsi que des types de problèmes juridiques qu’elle suscitera dans les années à venir. Quant à la façon dont nous l’utilisons spécifiquement en matière de sécurité, nous encourageons beaucoup la conception ou l’idée du copilote.

Pendant des années, nous avons en quelque sorte considéré notre plateforme de sécurité comme une machine à tout faire, bien qu’il s’agisse d’une analogie un peu déplacée. L’IA générative nous offre de nouveaux outils intéressants afin d’aller encore plus loin et de déterminer comment rendre ce processus d’analyse plus rapide, plus complet et plus précis pour, à terme, détecter et éliminer les menaces plus vite.

Voilà donc certaines des applications que nous examinons. Le principal défi en matière de sécurité, en fin de compte, est le déficit de ressources humaines. D’où l’importance du travail effectué par AWS pour améliorer progressivement la sécurité de la plateforme et des services. Par ailleurs, il est primordial de tirer parti des ressources assez rares dont nous disposons en termes de professionnels de la sécurité et de ne pas les épuiser à force de labeur. Donnons-leur des outils qui leur permettent de réaliser de grandes choses.

Clarke Rodgers (06:42) :
Dans le même ordre d’idées, vous discutez avec de nombreux clients, dont beaucoup utilisent plusieurs clouds. Quels conseils leur donnez-vous quant à l’aspect sécurité et aux défis potentiels de la sécurisation de plusieurs clouds ?

Chris Rothe (06:58) :
D’une manière générale, nous adhérons au principe d’avoir le même ensemble de contrôles et la même compréhension des données et des accès sur toutes les plateformes (cloud ou sur site) que vous utilisez. Il s’agit d’une sorte de couche de base. Nous devons en quelque sorte simplement savoir qui a accès à quoi et comment déterminer si un problème grave se produit.

Clarke Rodgers (07:21) :
J’imagine que leurs résultats en matière de sécurité devraient être les mêmes en ce qui concerne leurs configurations.

Chris Rothe (07:25) :
Tout à fait. Et si vous ne pouvez pas atteindre ce résultat avec une plateforme cloud en particulier ou une autre, c’est peut-être le moment de la remettre en question et de déterminer si vous devez l’utiliser ou non. Si la sécurité n’est pas à la base ni à la hauteur des exigences pour ce type d’ensemble de contrôles de base, pourquoi fait-elle partie de votre architecture ?

Ces conversations sont difficiles, car les gens investissent beaucoup dans leur stratégie associée au multicloud. Mais je pense qu’au bout du compte, le point de départ consiste à comprendre quels contrôles doivent être mis en place et comment nous détecterons les menaces. Si vous ne pouvez pas répondre à cette préoccupation, vous devez repenser votre architecture ou votre stratégie.

Clarke Rodgers (08:07) :
C’est un excellent point de vue. Chris, merci beaucoup pour le temps que vous m’avez consacré aujourd’hui.

Chris Rothe (08:12) :
Merci de m’avoir invité.