Face à une attaque, la plupart des outils de sécurité SAP se contentent de prévenir un humain et d’attendre qu’il réagisse. Pour Jean-François Scardigli, Head of France and Iberia chez SecurityBridge, le réseau et le web ont réglé ce problème depuis longtemps — et c’est ce virage que la sécurité SAP doit prendre à son tour.
SAP, ERP (Enterprise Resource Planning) utilisé par la majorité des grandes organisations, pilote souvent la finance, la logistique, les RH et la production. En sécurité réseau, l’approche fondée sur la seule alerte a montré ses limites face à des attaquants capables d’agir en quelques secondes.
Une leçon déjà apprise en sécurité réseau et web
Les premiers outils de sécurité réseau étaient des IDS (Intrusion Detection System), qui se contentaient de signaler une intrusion déjà en cours. Le secteur a répondu avec les IPS (Intrusion Prevention System), capables de bloquer un paquet avant qu’il n’arrive. La même évolution s’est produite pour les applications web : un WAF (pare-feu applicatif) filtre le trafic à l’entrée d’un site, tandis que son successeur, le RASP (Runtime Application Self-Protection), s’exécute dans l’application et peut interrompre une opération dangereuse en cours. Dans les deux cas, le changement a été le même : on est passé de l’observation à l’action.
Une sécurité SAP encore cantonnée à l’alerte
Pour l’auteur, la plupart des outils dédiés à SAP fonctionnent encore comme des IDS : ils détectent un appel RFC (Remote Function Call) suspect, puis transmettent l’information à un analyste SOC ou à un administrateur Basis. Il cite l’exemple d’une vulnérabilité de SAP NetWeaver Visual Composer exploitée activement en 2025, avant même la diffusion large du correctif, et inscrite par l’agence américaine CISA à son catalogue des vulnérabilités connues comme exploitées quelques jours seulement après sa publication.
Un modèle à quatre couches pour la défense SAP
Jean-François Scardigli propose d’organiser la sécurité SAP en quatre couches reliées par une gouvernance commune : les personnes (équipes formées, responsabilités claires) ; un blocage déterministe et assisté par IA au moment précis où une action dangereuse est tentée — l’équivalent d’un RASP pour SAP, et la couche qui manquerait le plus souvent aujourd’hui ; le durcissement, via la configuration et le patching ; et enfin une surveillance continue nourrissant le SOC.
Selon lui, c’est la deuxième couche qui change la donne : sans elle, les trois autres décrivent une opération de détection compétente mais réactive. « La détection indique ce qui s’est produit, seul le blocage empêche que cela se produise », résume-t-il. Il rappelle que la sécurité réseau n’a jamais retiré l’IDS quand l’IPS est arrivé, ni le WAF quand le RASP s’est imposé — elle a ajouté une couche capable d’agir. À la sécurité SAP, selon lui, de faire de même : un système SAP compromis touche rarement un seul service, la finance, la logistique et les RH encaissant souvent le choc ensemble, en quelques secondes.
Tribune de Jean-François Scardigli, Head of France and Iberia chez SecurityBridge.