SAPotage - Cible : la production


De nombreux responsables pensent d'abord à la protection des systèmes de commande lorsqu'ils évoquent la sécurité informatique dans la production et se sentent en sécurité si leurs systèmes SCADA ne sont pas connectés à Internet.
Au plus tard lorsque ces systèmes sont connectés à un Intranet, la prétendue sécurité n'est plus de mise. Mais la production ne se limite pas à la commande d'une chaîne de montage.
Chaque processus de fabrication repose sur l'initiation de processus commerciaux par des personnes autorisées. Pour ce faire, les données de production sont de plus en plus souvent récupérées au niveau des installations de commande et transmises aux systèmes SAP.
Dans l'idéal, un tableau de bord alimenté par des données en temps réel met à la disposition de tous les décideurs, où qu'ils se trouvent, les informations nécessaires à la gestion des processus commerciaux tels que l'approvisionnement en matériaux et la planification de la production.
Ainsi, les responsables des départements dirigent la logistique de production en commandant de nouveaux matériaux, en organisant la sous-traitance de la fabrication et en établissant la facture. Le contrôle de la qualité fait également partie intégrante d'un processus de fabrication géré par SAP.
Scénarios de risque
Grâce à cette imbrication directe des processus de production et des processus commerciaux, les pirates disposent d'un vaste champ d'action pour attaquer les modules et les applications ERP ou SCM.
Des utilisateurs malveillants peuvent tout d'abord obtenir des informations centrales sur le savoir-faire en matière de production et les processus d'une entreprise. Les solutions de planification de la production basées sur SAP ainsi que les modules ERP et SCM deviennent ainsi des cibles intéressantes pour l'espionnage industriel.
Deuxièmement, les utilisateurs malveillants et les propriétaires non autorisés d'un compte d'utilisateur SAP ont de vastes possibilités d'activités frauduleuses.
Une fois que l'on a obtenu l'accès à une instance SAP via la couche transactionnelle - c'est-à-dire au niveau de SAP-NetWeaver ou de Hana -, il est possible de contourner les concepts de sécurité SAP classiques au niveau de l'application, comme la ségrégation des droits, grâce à des procédures simples.
Par conséquent, les applications ne sont pas non plus protégées. Une SoD prévoit par exemple dans le cas normal qu'un utilisateur d'un département de production puisse passer une commande de matériel, mais que la facturation ne puisse être effectuée que par le contrôle de gestion.
Un utilisateur qui crée son propre compte avec des droits d'utilisation étendus, qui détourne un compte privilégié SAP All Account à ses propres fins ou qui se crée un nouveau compte, se débarrasse de ces restrictions SoD.
Il passe une commande fictive, écrit une facture fictive à un homme de paille et ordonne le virement sur son compte. Les petites sommes d'argent qui circulent régulièrement peuvent passer inaperçues, d'autant plus que sa propre production se poursuit sans être affectée.
De nombreux RSSI ne peuvent souvent même pas avoir une vue d'ensemble de ces risques de sécurité quotidiens par manque de ressources.
Troisièmement, le sabotage des environnements SAP met en danger la production. Des fournisseurs malveillants arrêteront les commandes de matériel nécessaires, manipuleront peut-être les données de production, par exemple pour le calcul du prix de revient du matériel. Au niveau des transactions SAP, ils peuvent paralyser l'ensemble du système SAP par un shut-down.
Sans planification de la production, il n'y a alors plus de production possible. Dans la pratique, cela peut être plus rare. Un système SAP qui fonctionne et qui sert de plate-forme à des activités frauduleuses est généralement plus lucratif.
Procédures
La connexion croissante des processus commerciaux liés à la production à Internet via des solutions basées sur SAP et l'intégration de partenaires externes aggravent la situation en matière de risques.
La transmission mobile de données ou la connexion de fournisseurs par exemple via le cloud et les systèmes de contrôle augmentent la surface d'attaque. Les applications mobiles faisant partie de la plateforme mobile SAP peuvent devenir des portes d'entrée sur les instances ERP SAP en raison d'un accès non justifié.
Les pirates recherchent de manière ciblée de nouvelles possibilités d'accès. Un spear phishing classique visant des responsables de production pour enregistrer la saisie de mots de passe au moyen d'enregistreurs de frappe menace bien sûr aussi l'utilisateur SAP et n'est qu'un début.
Les pirates externes malveillants utilisent des moteurs de recherche tels que Shodan pour trouver les instances SAP qu'ils recherchent. Les collaborateurs internes ont bien sûr encore plus de facilité à accéder aux systèmes SAP.
En exploitant une vulnérabilité de type HTTP-Verb-Tampering, les pirates peuvent créer des utilisateurs de backdoor dans le module de gestion des utilisateurs SAP J2EE. Ils peuvent ainsi accéder aux portails SAP et aux plateformes d'intégration de processus, ainsi qu'aux systèmes internes qui y sont liés.
Les attaques contre les bases de données se font par le biais de vulnérabilités des protocoles SAP propriétaires : les droits d'utilisateur détournés ou usurpés permettent d'exploiter les failles de la passerelle RFC SAP au niveau des transactions SAP.
Le pirate a accès à toutes les informations stockées dans la base de données SAP et peut les lire. Pour ce faire, les pirates externes font souvent un détour par des environnements souvent non productifs et donc souvent insuffisamment protégés :
Par exemple, les environnements de test sont souvent oubliés après la mise en place du système de production correspondant - et avec eux les comptes techniques qui s'y appliquent, souvent dotés uniquement de mots de passe par défaut.
Un pirate peut facilement les utiliser comme tremplin pour attaquer les systèmes de production. Ces méthodes d'attaque fréquemment observées permettent ensuite de modifier et de manipuler de nombreuses informations importantes pour la production.
Par exemple, les tables SAP LFA1 (Vendor Master Data), KNA1 (Customer Master Data), EKKO et EKPO ou encore AUFK pour les ordres d'achat et KALC pour le calcul de la quantité des articles de production.
Niveau de protection de la couche transactionnelle
La protection des processus de production basés sur SAP commence dès les bases de tout environnement SAP - au niveau de la couche transactionnelle. La ségrégation des responsabilités, les mesures GRC et les applications de sécurité spéciales au niveau des applications, ainsi que l'assistance à grande échelle fournie par l'éditeur de logiciels SAP, sont des outils importants pour créer plus de sécurité.
Mais ils ne peuvent pas se suffire à eux-mêmes. Ils n'éliminent pas les risques au niveau Hana ou NetWeaver dus à l'apparition de failles de sécurité, à des correctifs logiciels non appliqués, à une communication incontrôlée via des interfaces permettant de transférer des données erronées ou à un accès non protégé aux services d'administration.
Une protection complète de la couche transactionnelle peut éliminer efficacement bon nombre de ces risques et fournit la base de la sécurité des modules et applications ERP ou SCM.
Une évaluation automatisée de toutes les instances SAP - y compris des environnements de test et de développement - fait l'inventaire des failles de sécurité existantes et met en évidence les risques potentiels.
De tels messages tiennent également compte du contexte des informations d'infrastructure fournies par l'évaluation automatique. Ils enregistrent également les modifications du système qui rendent éventuellement une organisation vulnérable. Cela permet de déterminer les chances de succès d'une attaque.
Les analyses correspondantes décrivent en détail la probabilité et l'impact des menaces. Les administrateurs peuvent utiliser des instructions détaillées pour combler les failles en fonction de leur priorité.
Surveillance et comportement des utilisateurs
Les solutions avancées surveillent également en permanence l'état des menaces et recherchent des modèles d'attaque pour exploiter de nouvelles vulnérabilités.
Ils signalent les nouvelles attaques effectivement menées contre les vulnérabilités existantes et analysent les méthodes d'attaque correspondantes en temps réel. Les mécanismes de défense sont déclenchés automatiquement et peuvent être mis en œuvre par les responsables.
Les services informatiques empêchent ainsi l'exploitation des failles de sécurité, même si aucun patch régulier n'a encore été publié et mis en œuvre. Ce gain de vitesse est crucial.
En effet, dans les environnements SAP, en raison de la complexité des systèmes, il s'écoule en moyenne jusqu'à 18 mois entre le jour où une attaque se produit pour la première fois et la mise en œuvre effective d'un correctif pertinent.
Pour se défendre contre les abus, la fraude et l'espionnage, il est également important de reconnaître les comportements inhabituels des utilisateurs, qui peuvent être l'indice d'activités malveillantes de la part de collaborateurs.
Les responsables de la sécurité ont la possibilité de réagir le plus rapidement possible aux menaces et peuvent encaisser immédiatement les droits d'utilisation utilisés pour modifier les droits des utilisateurs ou pour accéder aux données de production.
Une stratégie de sécurité SAP réussie est construite sur plusieurs niveaux et repose sur plusieurs outils, dont des pare-feux et des solutions SIEM.
Il est également important que ces solutions n'agissent pas comme des solutions isolées, mais puissent échanger des données pertinentes via des interfaces de programmation (API) définies.
Créer des bases sûres
Seul celui qui protège la couche transactionnelle peut protéger efficacement ses applications de production et ses modules ERP dans SAP. En effet, si un pirate informatique parvient à accéder à n'importe quel point de départ dans l'environnement système SAP, tous les composants SAP liés à la production lui seront ouverts. La sécurité ERP et SCM a également besoin d'un sol solide sous ses pieds.