Dans l'article précédent, nous avons beaucoup parlé de la sécurité des systèmes ERP. Maintenant, nous voulons parler des moyens de les protéger.
La protection des systèmes ERP est un défi. Un bon projet complet peut prendre des années à être achevé, en particulier lorsqu'il s'agit de grands paysages. Cependant, cela vaut la peine d'investir. Voici quelques étapes de base qui vous aideront à concevoir en toute sécurité votre implémentation SAP lorsque vous êtes au stade de la planification. Vous pouvez également appliquer cette méthodologie pour protéger vos systèmes contre les attaques les plus courantes.
1. Protégez-vous contre les attaques externes, désactivez les services non sécurisés
Toute application plus ou moins complexe possède une grande fonctionnalité qui est nécessaire en général, mais inutile dans des cas particuliers. Presque toutes ces fonctionnalités dans un système ERP typique sont activées par défaut.
Comme d'habitude, l'installation de SAP comprend environ 1 500 services Web différents, qui sont disponibles à distance au nom de tout utilisateur enregistré, si le service est activé par défaut. Par ailleurs, une quarantaine de services sont accessibles même aux utilisateurs anonymes. Certains documents de recherche ont souligné 13 services essentiels. Comme mentionné ci-dessus, ceux-ci ne sont que des services de base.
Nous vous recommandons d'appliquer les recommandations de la directive mentionnée ci-dessus dès que possible - désactivez tous les services accessibles aux utilisateurs anonymes, analysez lesquels des services installés sont nécessaires et limitez en outre l'accès en mettant en œuvre des contrôles d'autorisation.
L'architecture du système SAP doit inclure un proxy Web (SAP Web Dispatcher) qui restreindra l'accès à tous les services inutiles de l'extérieur et autorisera l'accès uniquement aux services nécessaires.
Le répartiteur Web SAP se situe entre Internet et votre système SAP. Il s'agit du point d'entrée pour les demandes HTTP dans votre système, qui consiste en un ou plusieurs serveurs d'applications SAP NetWeaver. SAP Web Dispatcher contribue donc à la sécurité et équilibre la charge de votre système SAP.
Vous trouverez des informations supplémentaires sur SAP Web Dispatcher ici .
2. Appliquer les principes SoD
Les solutions SAP offrent diverses opportunités fonctionnelles, qui sont mises en œuvre via des programmes, des transactions et des rapports. L'accès à ces objets doit être strictement réglementé en fonction des valeurs d'autorisation définissant les utilisateurs, les méthodes et les objets autorisés pour l'accès. L'accès à des actions critiques (par exemple, les droits d'accès pour modifier des transactions ou pour lire des tables) permet aux utilisateurs d'effectuer des attaques sur les systèmes SAP, d'élever leurs privilèges ou de voler des données critiques.
La séparation des tâches (SoD) est une méthode de sécurité pour prévenir les conflits d'intérêts, c'est-à-dire pour éviter deux autres droits d'accès qui - accordés ensemble - peuvent entraîner un risque d'actions frauduleuses (par exemple, un droit de créer et d'approuver un ordre de paiement).
La première étape consiste à minimiser le nombre d'utilisateurs avec le profil SAP_ALL ou ceux ayant accès aux transactions critiques telles que SE16, SM59 et SE38. À l'étape suivante, appliquez les contrôles SoD, au moins ceux mentionnés dans les directives ISACA .
3. Séparez le développement du test et recherchez les vulnérabilités
Pour vous protéger des développeurs malveillants, commencez par séparer la conception entre le développement de test et l'infrastructure de production, puis contrôlez toutes les demandes de transport du développement à la production. Cela semble facile; cependant, la question est de savoir ce qui doit être contrôlé exactement. Pour architecturer en toute sécurité la séparation entre le développement de test et les systèmes de production, vous devez vous assurer qu'il n'y a pas de connexion avec les informations d'identification stockées des systèmes à haute priorité (systèmes de production) aux systèmes à faible priorité (systèmes de développement). Ces connexions sont uniquement autorisées à stocker la configuration de connectivité technique et à authentifier l'utilisateur pour chaque accès.
Comme vous le savez peut-être, OWASP (Open Web-application security Project, axé sur l'amélioration de la sensibilisation à la sécurité des applications Web) fournit sa liste des 10 principales vulnérabilités les plus dangereuses affectant les applications Web. Lorsque nous traitons avec des applications d'entreprise, il n'est pas si facile de comprendre quels problèmes nous devons vérifier. Heureusement, il existe EAS-SEC (eas-sec.org) - une organisation à but non lucratif visant à accroître la sensibilisation dans l'espace de sécurité des applications d'entreprise. EAS-SEC se compose de projets distincts et l'un d'eux couvre la sécurité du code. Il s'agit du guide de développement d'applications Enterprise Application Systems ou EASAD. Ce guide décrit 9 catégories générales de problèmes de code source pour les langues professionnelles.
Catégories:
- Injections (Code, SQL, OS)
- Appels critiques (vers DB, vers OS)
- Contrôles de contrôle d'accès manquants ou incorrects (authentification manquante, erreurs)
- Traversée de répertoire (écriture, lecture, SMBRelay)
- Modification du contenu affiché (XSS, CSRF)
- Portes dérobées (informations d'identification codées en dur)
- Canaux secrets (sockets ouverts, appels HTTP, SSRF)
- Divulgation d'informations (utilisateurs codés en dur, mots de passe)
- Instructions obsolètes (READ TABLE, méthodes du noyau)
Ces catégories sont universelles et identiques pour la majorité des applications métier telles que SAP, Oracle, Microsoft Dynamics et Infor et leurs langages personnalisés.
Un processus de développement sécurisé doit inclure au moins la vérification des vulnérabilités du code de ces neuf catégories.
4. Connexions sécurisées
Comme chaque système est connecté à d'autres, il est essentiel de comprendre quel système peut être attaqué, comment SAP est connecté avec d'autres applications d'entreprise, comment un attaquant peut augmenter ses privilèges et quel actif vous devez protéger au début. Nous devons analyser quel système est le plus important et commencer à résoudre les problèmes sur ce système particulier.
Tout d'abord, nous devons attribuer la gravité de chaque actif. Analysez ensuite les connexions entre les actifs, qu'ils soient sécurisés ou non, et enfin hiérarchisez les actifs en fonction de leur impact global sur la sécurité globale du paysage. Par exemple, vous disposez d'un actif à faible risque, par exemple, un système de test sans données critiques. Ce système a une connexion avec le système de production, et ce système de production, à son tour, a une connexion avec l'infrastructure ICS. Compte tenu de toutes les connexions, ce système de test peut avoir un impact important sur tous les paysages et nous devons nous soucier de sa sécurité.
En plus des mécanismes d'un serveur d'applications, les serveurs peuvent souvent être connectés à un certain nombre d'autres mécanismes. Par exemple, les solutions SAP peuvent être installées sur des serveurs Windows, qui font partie d'un domaine unique et s'exécutent avec les privilèges d'un compte commun. Dans ce cas, accéder à un serveur signifie presque toujours accéder à tous les autres serveurs, quelle que soit la façon dont ils sont correctement protégés au niveau de l'application. Cela est également possible lorsque des liens ou des connexions sécurisées sont implémentés via un SGBD . Les SGBD stockent souvent des références à d'autres bases de données avec des données d'authentification prédéfinies, ce qui rend les autres SGBD accessibles. En outre, la portée de ces mécanismes comprend toutes les autres méthodes possibles pour pénétrer le système voisin, que les auditeurs utilisent généralement dans les tests de pénétration, c'est-à-dire une tentative de connexion à un système voisin avec le même mot de passe ou des mots de passe similaires à la fois au niveau du système d'exploitation, du SGBD et des applications. , ainsi que toutes sortes de recherches de mots de passe en texte brut dans le système de fichiers; mise à jour, intégration, scripts de sauvegarde, etc. Toutes ces options doivent être vérifiées pour éliminer tout risque de pénétration avec un maillon faible à tous les systèmes.
Un autre risque de connexions non sécurisées est la fuite de données. Les systèmes SAP doivent chiffrer les données lors de leur transfert. Il est clair que le trafic HTTP doit être sécurisé par SSL, mais la majeure partie du trafic est transférée à l'aide des protocoles propriétaires de SAP qui sont non sécurisés par défaut tels que RFC (Protocol to connect SAP systems), DIAG (Protocol to connect SAP client with SAP Server) et le protocole Message Server. Malheureusement, il n'existe aucun moyen de sécuriser le trafic de Message Server; par conséquent, le simple fait de placer ce service sous le pare-feu sera la seule option. Comme pour les protocoles DIAG et RFC, le chiffrement peut être implémenté via SNC.
SNC sans connexion unique est disponible pour tous les clients SAP NetWeaver pour l'interface graphique SAP utilisant le chiffrement client SNC et pour toutes les communications RFC entre les serveurs SAP. Les capacités de connexion unique de base sont disponibles dans les environnements où les serveurs SAP et les clients SAP GUI exécutent Microsoft.
Résumé
La sécurité ERP est une tâche complexe. Cependant, le simple fait de suivre ces 4 étapes de haut niveau peut améliorer considérablement le niveau de sécurité de votre système ERP. Ce n'est qu'après avoir implémenté l'architecture en toute sécurité qu'il est logique de prendre des mesures supplémentaires telles que la gestion des vulnérabilités et la réponse aux incidents.