Une plateforme IoT est une cible attractive. Elle détient les identifiants de milliers d’appareils, elle peut envoyer des commandes à des équipements, et elle sert souvent de nombreux clients à la fois. Un pare-feu réseau placé devant elle arrête certaines attaques, mais beaucoup de celles qui sont dangereuses ressemblent à des requêtes ordinaires : une connexion valide depuis un lieu inhabituel, une clé d’API utilisée d’une nouvelle manière, un utilisateur qui lit bien plus d’enregistrements que d’habitude. Les détecter demande une couche qui comprend l’application elle-même.
Cet article explique le fonctionnement du pare-feu IA intégré à Hermetry, ainsi que les choix de conception qui le sous-tendent.
Ce qu’il surveille
Le pare-feu observe la plateforme, et pas seulement le réseau. Il travaille avec plus de 1 000 types de signaux de sécurité : tentatives de connexion, vérifications de permissions, utilisation des clés d’API, schémas de requêtes, modifications des appareils et des règles, et bien d’autres. Plus de 1 200 types d’actions de la plateforme sont audités, de sorte que le pare-feu peut voir qui a fait quoi, sur quel tenant et quand.
Trois couches de détection
Règles et détecteurs
Certaines attaques ont des signatures claires : trop de connexions échouées, requêtes qui sondent des faiblesses connues, rafale soudaine d’exports. Les règles et les détecteurs dédiés les repèrent rapidement et de façon prévisible. Ils sont faciles à lire et faciles à tester.
Un modèle comportemental
D’autres attaques ne se révèlent que par un changement de comportement. Un utilisateur qui consulte habituellement quelques tableaux de bord liste soudain tous les appareils d’un tenant. Une clé d’API qui n’a appelé qu’un seul point de terminaison pendant des mois commence à en appeler dix. Un modèle comportemental apprend à quoi ressemble la normalité et signale ce qui s’en écarte.
Un modèle de classification des attaques
Un second modèle, indépendant, examine l’activité suspecte et estime à quel type d’attaque elle ressemble. Connaître la classe aide à choisir la bonne réponse : une tentative de credential stuffing appelle une action différente d’un scraping de données.
Les deux modèles sont volontairement indépendants. Aucun n’agit seul. Le constat d’un modèle ne déclenche une action qu’une fois validé, afin qu’une erreur isolée ne bloque pas un utilisateur légitime.
Les leurres détectent ce que les détecteurs manquent
Certains des signaux les plus fiables proviennent de pièges. La plateforme contient :
- des clés d’API leurres qu’aucun client légitime n’utilise jamais ;
- des enregistrements canari qu’aucun écran normal ne lit jamais ;
- des routes piège qu’aucune partie de l’interface n’appelle jamais.
Toucher à l’un d’eux est un signe fort que quelqu’un explore la plateforme avec un accès volé ou un outil automatisé. Les leurres produisent très peu de fausses alertes, car les utilisateurs légitimes n’ont aucune raison de les atteindre.
Observer, suggérer, agir
Les équipes de sécurité doivent faire confiance à un système avant de le laisser agir. Le pare-feu propose donc trois modes.
- Observer : il enregistre ce qu’il aurait fait, sans rien faire. Utilisez ce mode pour apprendre comment il se comporte sur votre trafic.
- Suggérer : il propose des actions qu’une personne doit approuver.
- Agir : il exécute lui-même des actions validées, comme ralentir ou bloquer une source, et les enregistre.
Jamais seul sur les appareils industriels
Une règle ne change pas selon le mode. Le pare-feu n’agit jamais de sa propre initiative sur les appareils industriels. Couper un contrôleur de pompe ou une passerelle à cause d’un schéma suspect pourrait causer plus de dégâts que l’attaque qu’il cherche à arrêter. Pour les appareils industriels, le pare-feu se contente de suggérer, et une personne décide.
Chaque décision est expliquée
Un blocage que personne ne peut expliquer érode vite la confiance. Chaque décision du pare-feu s’accompagne d’une explication : les signaux observés, la règle, le détecteur ou le modèle qui les a levés, la manière dont le constat a été validé et l’action qui a suivi. Les administrateurs peuvent ainsi revoir les décisions, corriger les erreurs et régler le système en toute confiance.
Son articulation avec le reste de la plateforme
Le pare-feu n’est qu’une couche parmi d’autres. Les données des tenants sont séparées dans la base de données grâce à la sécurité au niveau des lignes (row-level security), de sorte que même une attaque réussie sur un compte ne peut pas lire les lignes d’un autre tenant. Les rôles limitent ce que chaque utilisateur peut faire. Les identifiants des appareils sont délivrés par appareil, avec des certificats lorsque les appareils en ont besoin. Le pare-feu surveille l’ensemble.
Ce qu’il faut demander à toute plateforme
- Surveille-t-elle le comportement applicatif, et pas seulement le trafic réseau ?
- Peut-on la faire fonctionner d’abord en mode observation ?
- Explique-t-elle ses décisions ?
- Existe-t-il une règle stricte interdisant toute action automatique sur les équipements industriels ?
- Les actions sont-elles auditées, et peut-on consulter le journal d’audit ?
En savoir plus sur notre page sécurité et sur la page du pare-feu IA.