SAP, Oracle, Siemens : vos systèmes critiques sont la vraie cible — et votre patch management ne suffit pas

Chaque mois, je vois les mêmes entreprises dépenser des fortunes en EDR de nouvelle génération, en SIEM en cloud et en formations phishing — pendant que leur SAP tourne sur un kernel ABAP non patché depuis huit mois et que leurs automates de production répondent encore au mot de passe "admin/admin". Ce n'est pas de la négligence. C'est une incompréhension systémique de la surface d'attaque réelle. Et les attaquants, eux, l'ont très bien compris.

Le paradoxe du RSSI bien équipé

Il y a un paradoxe au coeur de la cybersécurité des grandes organisations : plus elles investissent dans des outils de détection sophistiqués, plus elles ont tendance à négliger la gestion des vulnérabilités sur leurs systèmes les plus critiques. Ce n'est pas une intuition — c'est une observation terrain que je fais régulièrement dans mes missions d'audit.

Le mécanisme est simple à comprendre. Les équipes sécurité dépensent leur énergie à déployer et opérer des outils complexes — SIEM, SOAR, EDR, XDR, threat intelligence, red team interne. Ces outils ont une valeur réelle. Mais ils monopolisent les ressources humaines et créent une illusion de couverture : on voit des dashboards remplis d'alertes et de métriques, on répond à des incidents, on fait du threat hunting. Et pendant ce temps, la vulnérabilité CVSS 10.0 dans SAP Commerce Cloud publiée hier reste non patchée parce que "l'équipe Basis est surchargée" et que "la fenêtre de maintenance est dans six semaines".

Selon les données d'Onapsis publiées en 2025, le délai médian de déploiement des patches SAP dans les grandes entreprises est de 97 jours après publication. Pour les patches critiques (CVSS >= 9.0), il tombe à 62 jours — ce qui est toujours considérable quand on sait que des PoC fonctionnels pour les vulnérabilités SAP bien documentées émergent en 24 à 72 heures après la publication des Security Notes. Le gap entre la publication d'un patch et son déploiement effectif est une fenêtre d'attaque cadeau pour les attaquants.

Les systèmes OT industriels sont encore pire. Une étude de Claroty de 2025 indique que 35% des dispositifs OT critiques dans les environnements industriels européens ont des vulnérabilités connues depuis plus de 12 mois sans patch appliqué — souvent parce que le patch nécessite un arrêt de production, ou parce que le fournisseur n'a pas qualifié le patch pour la version du firmware en place. Le résultat est prévisible : des automates Siemens, Rockwell ou Schneider qui tournent avec des credentials par défaut et des firmwares obsolètes, accessibles depuis des réseaux de moins en moins isolés.

SAP : la bombe à retardement dans vos SI d'entreprise

Parlons concret. Le 11 août 2026, SAP a publié une faille CVE-2026-58231 avec un CVSS de 10.0 — le score maximum possible — dans SAP Commerce Cloud. Un attaquant non authentifié peut bypasser l'intégralité de l'authentification via le composant Data Hub Adapter. Résultat : accès complet aux données clients, commandes, informations de paiement. Pour tout opérateur e-commerce sur SAP Commerce Cloud, c'est une catastrophe potentielle dont la fenêtre d'exploitation s'ouvre dans les heures suivant la publication de la Security Note.

La même journée, deux failles CVSS 9.9 et 9.1 dans SAP Manufacturing Integration and Intelligence (MII) permettent l'injection de commandes arbitraires sur le serveur hôte. Ce serveur est, dans la plupart des déploiements industriels, directement connecté aux réseaux OT de production. On parle d'une vulnérabilité dans un logiciel SAP qui peut conduire à l'arrêt de lignes de production ou à la manipulation d'équipements physiques.

Ce n'est pas exceptionnel. En 2025, des chercheurs d'Onapsis ont documenté au moins 12 campagnes d'exploitation active de vulnérabilités SAP dans des environnements de production — dont plusieurs impliquant des acteurs liés à des États. Le groupe FIN13, spécialisé dans le ciblage des systèmes SAP mexicains et latino-américains, a démontré que l'expertise SAP offensive existe et qu'elle est monétisée. La CISA et le BSI allemand ont publié un avis conjoint en 2022 sur l'exploitation APT de vulnérabilités SAP : ce n'est plus théorique.

Le problème structurel avec le patch management SAP, c'est la complexité opérationnelle. Un Security Patch Day SAP typique publie 20 à 35 Security Notes. Chacune nécessite une analyse d'impact par l'équipe Basis, un test en environnement de recette, une coordination avec les équipes métier, une fenêtre de maintenance. Dans une grande entreprise avec des centaines de systèmes SAP (ERP central, satellites CRM, SCM, MII, portails Fiori, BW...), déployer un patch critique en moins de 72 heures relève de l'exploit organisationnel. Personne n'a le temps. Alors on priorise, on reporte, et les failles CVSS 10 attendent leur tour.

La solution n'est pas d'avoir plus de temps — c'est de changer le modèle. Les organisations qui s'en sortent le mieux ont trois pratiques en commun : un inventaire SAP précis et à jour (quels composants, quelles versions, quelle exposition réseau), une équipe Basis avec un SLA patch défini contractuellement pour les critiques (72h de patch ou de mesure compensatoire), et un WAF applicatif SAP (comme ceux de Onapsis ou de SAP elles-même) capable de bloquer des tentatives d'exploitation connues pendant la fenêtre de patch.

Oracle PeopleSoft et ShinyHunters : quand la dette technique devient une catastrophe

L'exemple le plus frappant de l'année pour illustrer les conséquences d'un ERP sous-patché : l'exploitation de CVE-2026-35273 dans Oracle PeopleSoft par le groupe ShinyHunters. Entre le 27 mai et le 9 juin 2026, ce groupe a exploité une faille de désérialisation non authentifiée (CVSS 9.8) dans le endpoint /PSEMHUB/hub de PeopleTools pour compromettre plus de 100 organisations à travers 300 instances PeopleSoft.

Le point crucial : Oracle n'a publié son advisory qu'un jour après que ShinyHunters a commencé à mettre en vente les données volées. Les attaquants avaient donc exploité la vulnérabilité comme un zéro-day pendant plusieurs jours, sans que les organisations victimes aient eu la moindre chance de patcher. Le secteur de l'enseignement supérieur — qui représente une large portion des déploiements PeopleSoft (gestion des étudiants, finances universitaires) — a été particulièrement touché.

Mais voilà ce qui est encore plus instructif que l'attaque elle-même : les analyses post-incident ont montré que même pour les organisations qui avaient accès au patch depuis sa publication, le délai de déploiement moyen était de plusieurs semaines. Les universités américaines victimes avaient souvent des installations PeopleSoft vieilles de 5 à 10 ans, avec des personnalisations importantes qui rendaient le patch complexe à appliquer sans risquer de casser des fonctionnalités métier critiques. C'est le dilemme classique de la dette technique ERP : plus le système est personnalisé et vieux, plus il est difficile à patcher, et plus il est potentiellement vulnérable.

Le secteur universitaire n'est pas une exception — c'est un miroir de ce qui se passe dans les ETI industrielles françaises avec leurs instances SAP ou Oracle E-Business Suite vieilles de 10-15 ans. Les mêmes contraintes s'appliquent : personnalisations massives, équipes techniques réduites, contrainte budgétaire forte, dépendance à un partenaire intégrateur pour les opérations de patch. Le résultat est identique : des systèmes critiques structurellement sous-patchés.

L'OT : quand le pivot devient physique

L'incident de la centrale CHP polonaise révélé à DEF CON 34 le 9 août 2026 marque un tournant dans la documentation des attaques OT. Pour la première fois, on dispose d'une chaîne d'attaque complète et documentée utilisant un APN cellulaire privé partagé comme pivot entre deux organisations et entre leurs réseaux IT et OT respectifs.

Concrètement : les attaquants compromettent un parc éolien voisin, découvrent que ce parc partage le même APN privé (canal cellulaire dédié) que la centrale CHP cible, pivotent via cet APN vers le réseau OT de la centrale, trouvent un PLC Siemens avec les credentials par défaut encore actifs, et le mettent en mode STOP. Turbine arrêtée. Traitement de l'eau coupé. 50 000 habitants sans chaleur — brièvement, heureusement.

Ce cas illustre trois problèmes structurels des réseaux OT modernes :

Premier problème — la confiance implicite accordée aux APN privés. Un APN privé est perçu comme un réseau de confiance parce qu'il est "dédié" et "sécurisé" par l'opérateur télécom. En réalité, si plusieurs entités partagent le même APN, chacune est potentiellement accessible depuis le réseau des autres. La plupart des équipes OT ignorent qui d'autre partage leur APN — c'est une information que l'opérateur DSO gère souvent sans la communiquer explicitement à ses clients.

Deuxième problème — les credentials par défaut sur les automates. C'est un classique documenté depuis les années 2010, accentué par Stuxnet, régulièrement rappelé dans les guidelines IEC 62443 et ANSSI. En 2026, des PLCs Siemens accessibles depuis des réseaux non cloisonnés tournent encore avec "admin/admin". Pas parce que les responsables OT sont incompétents — mais parce que changer un credential sur un automate en production nécessite une intervention planifiée, une procédure validée, un test, et souvent un arrêt de production. L'organisation préfère prendre le risque plutôt que d'interrompre la production.

Troisième problème — l'absence de surveillance des flux réseau OT. La centrale polonaise disposait d'un Fortinet en périmètre. Mais ce Fortinet ne couvrait pas les flux entrants via l'APN. Sans surveillance des flux réseau sur les interfaces cellulaires, le mouvement latéral de l'attaquant était invisible. Un déploiement Zeek ou un outil de surveillance réseau industriel (comme Claroty ou Dragos) sur les interfaces APN/OT aurait probablement détecté le scan et la connexion anormaux avant la mise en STOP du PLC.

Les cinq blocages structurels — et comment les lever

Après des dizaines de missions dans des environnements IT/OT hybrides, j'ai identifié cinq blocages qui expliquent pourquoi les organisations maintiennent des systèmes critiques sous-patchés malgré les alertes répétées. Les voici, avec ma lecture terrain de chaque situation :

1. La complexité opérationnelle du patch sur les systèmes critiques. Un patch SAP n'est pas un Windows Update. Il nécessite une analyse d'impact, un test sur un système dédié, une coordination métier et une fenêtre de maintenance. Pour un parc SAP de 50 composants, maintenir un cycle de patch en moins de 30 jours sur les critiques exige des ressources dédiées que la plupart des organisations n'ont pas. Solution : définir contractuellement des SLA de patch par criticité, externaliser si nécessaire la veille et l'analyse d'impact, et automatiser les déploiements dans les environnements de test via des pipelines CI/CD SAP.

2. La dette technique des ERP anciens. Les systèmes SAP ECC 6.0 ou Oracle EBS déployés il y a 10-15 ans avec des centaines de développements spécifiques (Z-programs, BADIs personnalisées) sont quasi-impossibles à patcher rapidement sans risque de régression. Le patch lui-même peut casser des fonctionnalités métier non documentées. Solution : traiter la dette technique comme une dette financière — la provisionner, la planifier, et l'amortir progressivement. Une migration vers S/4HANA ou une refonte des personnalisations est souvent moins chère sur 5 ans que le coût d'un incident.

3. Le cloisonnement organisationnel IT/OT. Les équipes sécurité IT n'ont pas autorité sur les systèmes OT, gérés par les équipes de production ou maintenance industrielle. Les RSSI ne voient pas les inventaires d'automates. Les équipes OT ne reçoivent pas les bulletins de vulnérabilités. Cette séparation organisationnelle est la règle, pas l'exception. Solution : créer un rôle de référent sécurité OT rattaché fonctionnellement au RSSI, et imposer un inventaire OT partagé mis à jour trimestriellement.

4. L'invisibilité des surfaces d'attaque secondaires. Personne ne surveille les APN privés. Personne ne sait exactement qui d'autre partage le même APN. Les interfaces de management des PLCs ne sont pas dans les CMDB. Les flux réseau OT ne sont pas collectés dans le SIEM. Ce que vous ne voyez pas, vous ne pouvez pas le protéger. Solution : tout inventorier, y compris les vecteurs non-IT — APN, liaisons série, protocoles industriels, interfaces de management des équipements OT.

5. La tolérance au risque implicite. Le management connaît les vulnérabilités. Il a vu les rapports d'audit. Il a signé les plans d'action. Mais quand vient le moment d'arrêter une ligne de production pour patcher un automate, la décision est différée. Il y a une tolérance au risque implicite qui s'est installée — "ça fait 10 ans qu'on tourne comme ça, il ne s'est rien passé". L'incident polonais, l'attaque ShinyHunters, les failles SAP CVSS 10 — ces événements servent à remettre en question cette tolérance. Mon travail de consultant, c'est souvent de traduire le risque technique en impact business concret pour que le management comprenne ce qu'il accepte réellement quand il diffère un patch.

Ce que les organisations qui s'en sortent font différemment

Je travaille aussi avec des organisations qui ont réussi à sortir du cercle vicieux du sous-patching. Voici les pratiques communes que j'observe chez elles :

Un inventaire vivant, pas un tableur statique. Les organisations matures maintiennent un inventaire automatisé de leurs systèmes IT et OT, mis à jour en continu via des agents légers ou de la découverte réseau passive. Ils savent à tout moment quelle version de firmware tourne sur quel PLC, quelle version de PeopleTools est déployée sur quelle instance. Sans cet inventaire, la priorisation des patches est aveugle.

Des SLA de patch contractualisés, pas seulement des bonnes intentions. Les patches CVSS >= 9.0 sont traités sous 72 heures — soit patch déployé, soit mesure compensatoire (coupure d'accès réseau, activation d'une règle WAF) documentée et validée. Ce SLA est formalisé dans la politique de sécurité et est suivi au niveau de la direction lors des comités de sécurité mensuels.

Des mesures compensatoires documentées pour chaque système non patchable. Pour les systèmes où le patch est techniquement impossible à court terme (OT ancien, ERP fortement personnalisé), une fiche de risque documentée avec des compensations est maintenue : isolation réseau renforcée, surveillance accrue, segmentation additionnelle. Ces fiches sont revues tous les trimestres.

Un red team OT au moins une fois par an. Les organisations sérieuses font tester leur résilience OT par des équipes offensives spécialisées. Ces exercices révèlent invariablement des surfaces d'attaque ignorées — credentials par défaut, protocoles non sécurisés, APN mal configurés — que les audits de conformité ne trouvent pas.

Conclusion

L'actualité cybersécurité du 11-12 août 2026 donne une illustration parfaite de la surface d'attaque réelle des organisations modernes : une faille CVSS 10.0 dans SAP Commerce Cloud, deux failles CVSS 9.9/9.1 dans le middleware industriel SAP MII, et la révélation d'une attaque OT sophistiquée via APN privé contre une centrale énergétique. Ces trois sujets n'ont rien d'anecdotique — ils représentent les vecteurs d'attaque que les groupes APT et ransomware ciblent activement parce qu'ils savent que ces systèmes restent sous-protégés.

La bonne nouvelle, c'est que les solutions existent. Inventaire précis, SLA de patch contractualisés, mesures compensatoires documentées, surveillance des vecteurs non-IT, red team OT annuel. Ce n'est pas de la magie — c'est de l'organisation et de la priorité. Mais ça demande que la direction comprenne ce qu'elle risque réellement quand elle diffère un patch critique. Et pour ça, nous, les praticiens, nous devons faire notre travail de traduction du risque technique en impact business. C'est ce que je fais à chaque mission. Et c'est souvent là que tout se joue.