Craig Riddell, Global Field CISO chez Wallarm – Série d’entretiens

Craig Riddell, Global Field CISO chez Wallarm, est un dirigeant expérimenté en cybersécurité qui se concentre sur l’aide aux entreprises à gérer les risques croissants liés aux API et aux systèmes alimentés par l’IA. Dans son rôle actuel, il travaille en étroite collaboration avec les CISO, les CIO et les dirigeants de l’ingénierie pour traduire les modèles d’attaque et les scénarios d’abus du monde réel en stratégies de sécurité actionnables, avec un fort accent sur l’observabilité – la compréhension de la manière dont les API et les systèmes alimentés par l’IA se comportent en production à travers les utilisateurs, les applications et les intégrations. Sa carrière s’étend sur des rôles de direction dans la gestion des identités et des accès, l’architecture de confiance zéro et la sécurité d’entreprise dans des organisations telles que Netwrix, Kron et HP, où il a piloté des transformations IAM à grande échelle et modernisé les cadres de sécurité. L’expertise de Riddell est centrée sur les menaces émergentes telles que les attaques de logique métier, les abus d’API, le dérive des systèmes alimentés par l’IA et la fraude, avec une focalisation constante sur le pontage de l’écart entre la stratégie de sécurité de haut niveau et l’exécution opérationnelle.

Wallarm est une entreprise de cybersécurité spécialisée dans la protection des API, des applications et des systèmes alimentés par l’IA dans les environnements cloud modernes. Sa plateforme offre une découverte continue, des tests et une protection en temps réel contre les menaces telles que les abus d’API, les attaques de logique métier et les exploits automatisés, tout en offrant une visibilité approfondie sur la manière dont les systèmes se comportent à travers des infrastructures complexes. Conçue pour les architectures multi-cloud et cloud-native, Wallarm s’intègre dans les flux de travail DevOps et de sécurité existants, permettant aux organisations de détecter et de bloquer les attaques à mesure qu’elles se produisent plutôt que après coup. En combinant l’inventaire d’API, la détection de menaces alimentée par l’IA et les capacités de réponse automatisée, la plateforme répond à une réalité croissante où les API et les systèmes alimentés par l’IA sont devenus la principale surface d’attaque pour les entreprises numériques modernes.

Vous avez commencé votre carrière en travaillant directement avec les systèmes et les infrastructures et vous êtes ensuite passé à des rôles de direction axés sur la sécurité des identités, des accès, des API et de l’IA. Quels sont les principaux changements qui vous ont amené à conclure que le véritable risque s’est déplacé de la périphérie vers les API et les systèmes alimentés par la machine ?

Au début de ma carrière, l’accent était mis sur la protection de la périphérie. Les pare-feu, la segmentation, le durcissement des infrastructures. Ce modèle fonctionnait lorsque les systèmes étaient plus statiques et que les limites de confiance étaient plus faciles à définir.

Ce qui a changé, c’est la manière dont les applications sont construites et dont les systèmes interagissent. Les API sont devenues le tissu conjonctif de tout, et l’IA a accéléré cela encore plus. Maintenant, les systèmes prennent des décisions, appellent d’autres systèmes et exécutent des actions à une échelle et à une vitesse qui n’impliquent pas les humains dans la boucle.

À ce stade, la périphérie devient moins pertinente. Le véritable risque se déplace vers l’endroit où les décisions sont prises et où les actions sont exécutées, à l’intérieur des API et des flux de travail alimentés par la machine.

Si vous n’avez pas de visibilité et de contrôle là-bas, vous faites confiance à un comportement que vous ne pouvez pas pleinement voir. C’est là que le risque métier apparaît, allant de l’exposition financière aux résultats involontaires et à la perturbation opérationnelle.

Vous avez décrit la poignée de main numérique comme cassée, en référence à la manière dont les systèmes établissent la confiance et échangent des actions à travers des chaînes de plus en plus complexes d’API et de processus automatisés. À quoi ressemble cette rupture dans un environnement d’entreprise réel aujourd’hui ?

Dans la plupart des environnements, les systèmes se font confiance sur la base de l’identité et de l’authentification. Un jeton est valide, une demande est bien formée et l’interaction est autorisée.

Le problème est que cela suppose que valable signifie sécurisé. Ce n’est plus vrai.

Nous authentifions l’identité, mais nous ne validons pas l’intention. Nous vérifions l’accès, mais pas le comportement à travers la chaîne.

Un service peut être autorisé à appeler un autre service, ce qui déclenche des actions en aval à travers plusieurs API. Chaque étape semble légitime en isolation, mais à travers la chaîne complète, vous commencez à voir un comportement non intentionnel ou un abus de logique.

Dans les environnements alimentés par l’IA, cela est amplifié. Les agents peuvent enchaîner des actions et exécuter des flux de travail sans examen humain.

La poignée de main se produit toujours, mais personne ne demande si le comportement a du sens dans le contexte. La confiance est établie, mais pas continuellement validée.

Pourquoi le risque lié à l’IA et aux API tombe-t-il souvent entre les frontières organisationnelles au lieu d’être clairement possédé ?

Parce que les systèmes ne correspondent pas à la manière dont les organisations sont structurées.

DevOps possède la livraison. La sécurité possède la politique. Les équipes commerciales possèdent les résultats. Les équipes de données possèdent les modèles. Chaque groupe possède une partie, mais personne ne possède le système tel qu’il se comporte en production.

Les API exécutent la logique métier à travers les systèmes. L’IA introduit une prise de décision non déterministe au-dessus de cela. Ensemble, ils traversent toutes les frontières.

Ils sont construits par une équipe, sécurisés par une autre et consommés par une troisième, avec une surveillance incohérente à travers toutes ces équipes.

Les lacunes que cela crée ne sont pas des défaillances d’équipes. Ce sont des défaillances du modèle opérationnel pour refléter la manière dont les systèmes modernes fonctionnent réellement.

Dans votre expérience, quels sont les équipes qui supposent généralement qu’elles possèdent le risque lié à l’IA, et où se trouvent les plus grands angles morts entre la sécurité, DevOps et les unités commerciales ?

Les équipes de sécurité ont tendance à posséder le risque lié à l’IA d’un point de vue de gouvernance et de conformité. DevOps possède le déploiement et la fiabilité. Les unités commerciales se concentrent sur les résultats.

Les angles morts apparaissent entre ces domaines.

La sécurité définit ce qui devrait se passer. DevOps s’assure que le système fonctionne. L’entreprise se concentre sur les résultats. Mais très peu d’équipes regardent régulièrement ce que le système fait réellement en temps réel.

C’est là que le risque vit, surtout lorsque le comportement est techniquement valable mais contextuellement incorrect.

De nombreuses attaques modernes apparaissent comme un comportement valable et authentifié plutôt que comme des intrusions évidentes. Comment les organisations devraient-elles repenser la détection dans cette nouvelle réalité ?

Nous devons aller au-delà de l’identification des « mauvaises » demandes.

Dans de nombreux cas, la demande est valable. Les informations d’identification sont légitimes. L’appel d’API est attendu. Ce qui n’est pas attendu, c’est la séquence d’actions, le volume ou le résultat.

La détection doit devenir comportementale et contextuelle. Il ne s’agit plus de bloquer une seule demande, mais de comprendre comment les systèmes interagissent au fil du temps.

Les approches qui tiennent réellement à l’échelle vont au-delà de la correspondance de modèles. Elles décomposent les demandes de manière structurale, en traitant chaque interaction comme un ensemble de jetons de comportement plutôt que d’essayer de correspondre à des modèles connus.

Cela permet de comprendre comment le comportement évolue et où il se dévie, même lorsque tout semble valable en surface.

Si vous vous fiez à des règles statiques ou à des signatures, vous manquerez la plupart de ce qui compte.

Vous avez souligné l’importance de l’observabilité dans le comportement du monde réel. À quoi ressemble une observabilité significative pour les API et les systèmes alimentés par l’IA en production ?

L’observabilité significative ne consiste pas seulement en journaux et en métriques. C’est comprendre le comportement dans le contexte.

Pour les API, cela signifie une visibilité complète de la demande et de la réponse, de l’utilisation des points de terminaison et de l’évolution des interactions au fil du temps.

Pour les systèmes alimentés par l’IA, cela signifie comprendre les entrées, les décisions et les actions résultantes.

Le plus important, c’est de relier ces éléments à travers les systèmes dans des flux de travail complets, et non des événements isolés.

Sans cela, vous opérez sur des hypothèses concernant le comportement du système au lieu de la réalité.

Pourquoi les modèles de révision et d’approbation humaine traditionnels deviennent-ils moins efficaces dans les environnements alimentés par la machine ?

Parce que la vitesse et l’échelle ont changé.

Les systèmes font des milliers ou des millions d’appels par minute, et les attaques ou les comportements non intentionnels peuvent se dérouler en minutes ou en secondes. Vous ne pouvez pas réalistiquement mettre un humain dans la boucle pour chaque décision sans casser les performances.

Les systèmes alimentés par l’IA ne sont pas toujours déterministes, ce qui rend les modèles d’approbation préalable moins efficaces.

La surveillance humaine a toujours de l’importance, mais elle doit passer de l’approbation d’actions individuelles à la définition de garde-fous et à la surveillance des résultats.

Quels sont les écarts opérationnels les plus courants que vous voyez lorsque les entreprises tentent de sécuriser les systèmes alimentés par l’IA en utilisant des cadres de sécurité hérités ?

La plus grande lacune est la dépendance excessive à l’égard des contrôles de conception.

Les organisations se concentrent sur la sécurisation des modèles, l’examen du code et la définition des politiques avant le déploiement. C’est important, mais cela suppose que les systèmes se comporteront comme prévu une fois qu’ils sont en direct.

En réalité, les systèmes évoluent. Les API changent. Les modèles alimentés par l’IA interagissent avec de nouvelles données et flux de travail. Le comportement change au fil du temps.

Sans validation continue du comportement en production, les organisations sont effectivement aveugles après le déploiement.

À quoi ressemble un modèle opérationnel pratique lorsque plusieurs parties prenantes partagent la responsabilité du risque lié à l’IA et aux API ?

Cela commence par reconnaître qu’aucune équipe ne peut posséder cela de bout en bout.

Un modèle pratique définit une responsabilité partagée, ancrée autour d’une source de vérité commune : le comportement en temps réel.

La sécurité définit le risque et la politique. L’ingénierie construit et exploite les systèmes. L’entreprise définit les résultats acceptables.

Les équipes qui prennent les devants opèrent dans une boucle fermée. La découverte continue, l’application et l’affinement sont pilotés par ce que les systèmes font réellement en production, et non par ce qui a été supposé au moment de la conception.

Toutes les parties prenantes ont besoin d’une visibilité sur la manière dont les systèmes fonctionnent en production. À partir de là, les équipes peuvent s’aligner sur ce que « bien » signifie, détecter les déviations et réagir.

Le changement est de la propriété cloisonnée à la responsabilité coordonnée, ancrée dans l’aperçu en temps réel.

En regardant vers l’avenir, pensez-vous que la responsabilité de la sécurité deviendra plus centralisée à nouveau, ou continuera-t-elle à se fragmenter à mesure que les systèmes deviennent plus autonomes ?

La responsabilité restera distribuée car cela reflète la manière dont les systèmes sont construits.

Ce qui changera, c’est la manière dont cette responsabilité est coordonnée.

Nous verrons plus de modèles de gouvernance unifiés où les équipes possèdent leurs domaines mais opèrent avec une visibilité et un contexte partagés.

Les organisations qui réussiront ne seront pas celles qui essaient de centraliser tout, mais celles qui alignent les parties prenantes sur la manière dont les systèmes se comportent réellement dans le monde réel.

Parce que si personne ne comprend le comportement en temps réel, personne ne possède réellement le risque.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Wallarm.