Entretiens
Craig Riddell, Global Field CISO chez Wallarm – Série d’entretiens
Craig Riddell, Global Field CISO chez Wallarm, est un cadre supérieur 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é – comprendre comment les API et les systèmes d’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, la dérive des systèmes d’IA et la fraude, avec une attention constante pour combler le fossé 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 plate-forme offre une découverte continue, des tests et une protection en temps réel contre des 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 façon 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 plate-forme répond à une réalité croissante où les API et les systèmes d’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 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 éloigné de la périphérie et s’est déplacé vers les API et les systèmes à propulsion machine ?
Au début de ma carrière, l’accent était mis sur la protection de la limite. Pare-feu, segmentation, 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 façon 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. 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 à propulsion 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 commercial 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 cybernétique comme cassée, en référence à la façon 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 équivaut à sûr. 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 une utilisation abusive de la 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 si souvent entre les frontières organisationnelles au lieu d’être clairement détenu ?
Parce que les systèmes ne correspondent pas à la façon dont les organisations sont structurées.
DevOps détient la livraison. La sécurité détient la politique. Les équipes commerciales détiennent les résultats. Les équipes de données détiennent les modèles. Chaque groupe détient une partie, mais personne ne détient le système dans son comportement 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 par-dessus. 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 inconsistante entre toutes.
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 façon dont les systèmes modernes fonctionnent réellement.
Dans votre expérience, quels sont les équipes qui assument généralement qu’elles détiennent 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 à détenir le risque lié à l’IA d’un point de vue de gouvernance et de conformité. DevOps détient 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 produire. 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 faux.
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 s’agit moins de bloquer une demande unique et plus 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. Ils décomposent les demandes de manière structurale, traitant chaque interaction comme un ensemble de jetons de comportement plutôt que d’essayer de correspondre à des modèles connus comme mauvais.
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 reposez sur 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 l’observabilité significative pour les API et les systèmes d’IA en production ?
L’observabilité significative n’est pas seulement des journaux et des 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 la façon dont les points de terminaison sont utilisés et de la façon dont les interactions évoluent au fil du temps.
Pour les systèmes d’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 dans 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 à propulsion machine ?
Parce que la vitesse et l’échelle ont changé.
Les systèmes prennent 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 d’IA ne sont pas toujours déterministes, ce qui rend les modèles d’approbation préalable moins efficaces.
La surveillance humaine conserve son importance, mais elle doit passer de l’approbation d’actions individuelles à la définition de limites 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 d’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 en direct.
En réalité, les systèmes évoluent. Les API changent. Les modèles d’IA interagissent avec de nouvelles données et flux de travail. Le comportement change avec le 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 détenir 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 de fonctionnement.
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. Découverte continue, application et raffinement impulsé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 de visibilité sur la façon dont les systèmes fonctionnent en production. À partir de là, les équipes peuvent s’aligner sur ce que « bien » signifie, détecter les écarts et réagir.
Le changement est de la propriété cloisonnée à la responsabilité coordonnée, ancrée dans les informations en temps de fonctionnement.
En regardant vers l’avenir, attendez-vous que la responsabilité de la sécurité devienne plus centralisée à nouveau, ou continuera-t-elle à se fragmenter à mesure que les systèmes deviennent plus autonomes ?
La responsabilité restera distribuée parce que cela reflète la façon dont les systèmes sont construits.
Ce qui changera, c’est la façon dont cette responsabilité est coordonnée.
Nous verrons plus de modèles de gouvernance unifiés où les équipes détiennent 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. Ce seront celles qui alignent les parties prenantes sur la façon dont les systèmes se comportent réellement dans le monde réel.
Parce que si personne ne comprend le comportement en temps de fonctionnement, personne ne détient réellement le risque.
Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus devraient visiter Wallarm.
