Im vorherigen Artikel haben wir viel über die Sicherheit von ERP-Systemen erzählt. Jetzt wollen wir über Möglichkeiten sprechen, sie zu schützen.
Der Schutz von ERP-Systemen ist eine Herausforderung. Es kann Jahre dauern, bis ein gutes umfassendes Projekt abgeschlossen ist, insbesondere bei großen Landschaften. Investitionen lohnen sich jedoch. Im Folgenden finden Sie einige grundlegende Schritte, mit denen Sie Ihre SAP-Implementierung in der Planungsphase sicher gestalten können. Sie können diese Methode auch anwenden, um Ihre Systeme vor den häufigsten Angriffen zu schützen.
1. Schützen Sie sich vor externen Angriffen und deaktivieren Sie unsichere Dienste
Jede mehr oder weniger komplexe Anwendung verfügt über eine große Funktionalität, die im Allgemeinen benötigt wird, in bestimmten Fällen jedoch nicht erforderlich ist. Fast alle diese Funktionen in einem typischen ERP-System sind standardmäßig aktiviert.
Wie üblich umfasst die SAP-Installation ungefähr 1500 verschiedene Webdienste, die für jeden registrierten Benutzer remote verfügbar sind, wenn der Dienst standardmäßig aktiviert ist. Außerdem sind etwa 40 Dienste auch anonymen Benutzern zugänglich. Einige Forschungsarbeiten wiesen auf 13 kritische Dienste hin. Wie oben erwähnt, handelt es sich hierbei nur um Basisdienste.
Wir empfehlen, dass Sie Empfehlungen aus der oben genannten Richtlinie so bald wie möglich anwenden. Deaktivieren Sie alle Dienste, auf die anonyme Benutzer zugreifen können, analysieren Sie, welche der installierten Dienste erforderlich sind, und beschränken Sie den Zugriff zusätzlich, indem Sie Berechtigungsprüfungen durchführen.
Die Architektur des SAP-Systems sollte einen webbasierten Proxy (SAP Web Dispatcher) enthalten, der den Zugriff auf alle unnötigen Dienste von außen einschränkt und nur den Zugriff auf die erforderlichen Dienste ermöglicht.
Der SAP Web Dispatcher liegt zwischen dem Internet und Ihrem SAP-System. Dies ist der Einstiegspunkt für HTTP-Anforderungen in Ihr System, das aus einem oder mehreren SAP NetWeaver-Anwendungsservern besteht. Der SAP Web Dispatcher trägt somit zur Sicherheit bei und gleicht die Last in Ihrem SAP-System aus.
Weitere Informationen zu SAP Web Dispatcher finden Sie hier .
2. Wenden Sie die SoD-Prinzipien an
SAP-Lösungen bieten verschiedene funktionale Möglichkeiten, die durch Programme, Transaktionen und Berichte implementiert werden. Der Zugriff auf diese Objekte sollte streng reguliert werden, basierend auf den Berechtigungswerten, die Benutzer, Methoden und Objekte definieren, die für den Zugriff zugelassen sind. Durch den Zugriff auf wichtige Aktionen (z. B. Zugriffsrechte zum Ändern von Transaktionen oder zum Lesen von Tabellen) können Benutzer Angriffe auf SAP-Systeme ausführen, ihre Berechtigungen eskalieren oder kritische Daten stehlen.
Die Aufgabentrennung (SoD) ist eine Sicherheitsmethode, um Interessenkonflikte zu vermeiden, d. H. Um zwei oder mehr Zugriffsrechte zu vermeiden, die - wenn sie zusammen gewährt werden - das Risiko betrügerischer Handlungen bergen können (z. B. ein Recht zur Schaffung und Genehmigung einen Zahlungsauftrag).
Der erste Schritt besteht darin, die Anzahl der Benutzer mit SAP_ALL-Profil oder Benutzern mit Zugriff auf kritische Transaktionen wie SE16, SM59 und SE38 zu minimieren. Wenden Sie als nächsten Schritt SoD-Kontrollen an, zumindest die in den ISACA- Richtlinien genannten.
3. Trennen Sie die Entwicklung vom Test und suchen Sie nach Schwachstellen
Um sich vor böswilligen Entwicklern zu schützen, müssen Sie zunächst die Trennung zwischen Testentwicklung und Produktionsinfrastruktur entwerfen und dann alle Transportanforderungen von der Entwicklung bis zur Produktion steuern. Es scheint einfach zu sein; Es geht jedoch darum, was genau kontrolliert werden sollte. Um die Trennung zwischen Testentwicklungs- und Produktionssystemen sicher zu gestalten, sollten Sie sicherstellen, dass keine Verbindungen mit gespeicherten Anmeldeinformationen von Systemen mit hoher Priorität (Produktionssysteme) zu Systemen mit niedriger Priorität (Entwicklungssysteme) bestehen. Diese Verbindungen dürfen nur die Konfiguration der technischen Konnektivität speichern und den Benutzer für jeden Zugriff authentifizieren.
Wie Sie vielleicht wissen, bietet OWASP (Open Web Application Security Project, das sich auf die Verbesserung des Bewusstseins für die Sicherheit von Webanwendungen konzentriert) die Top-10-Liste der gefährlichsten Sicherheitslücken, die Webanwendungen betreffen. Wenn wir uns mit Unternehmensanwendungen befassen, ist es nicht so einfach zu verstehen, welche Probleme wir überprüfen müssen. Glücklicherweise gibt es EAS-SEC (eas-sec.org) - eine gemeinnützige Organisation, die darauf abzielt, das Bewusstsein für die Sicherheit von Unternehmensanwendungen zu stärken. EAS-SEC besteht aus separaten Projekten, von denen eines die Codesicherheit abdeckt. Es wird als EASAD (Enterprise Application Systems Application Development Guide) bezeichnet. In diesem Handbuch werden 9 allgemeine Kategorien von Quellcodeproblemen für Geschäftssprachen beschrieben.
Kategorien:
- Injektionen (Code, SQL, OS)
- Kritische Aufrufe (an DB, an OS)
- Fehlende oder schlechte Zugriffskontrollprüfungen (fehlende Authentifizierung, Fehler)
- Verzeichnisdurchquerung (Schreiben, Lesen, SMBRelay)
- Änderung des angezeigten Inhalts (XSS, CSRF)
- Hintertüren (fest codierte Anmeldeinformationen)
- Verdeckte Kanäle (offene Sockets, HTTP-Anrufe, SSRFs)
- Offenlegung von Informationen (fest codierte Benutzer, Passwörter)
- Veraltete Anweisungen (READ TABLE, Kernel-Methoden)
Diese Kategorien sind universell und für die meisten Geschäftsanwendungen wie SAP, Oracle, Microsoft Dynamics und Infor sowie deren benutzerdefinierte Sprachen gleich.
Ein sicherer Entwicklungsprozess sollte mindestens die Überprüfung auf Code-Schwachstellen dieser neun Kategorien umfassen.
4. Sichere Verbindungen
Da jedes System mit anderen verbunden ist, ist es wichtig zu verstehen, welches System angegriffen werden kann, wie SAP mit anderen Unternehmensanwendungen verbunden ist, wie ein Angreifer Berechtigungen eskalieren kann und welches Asset Sie zunächst schützen sollten. Wir sollten analysieren, welches System das wichtigste ist, und Probleme auf diesem bestimmten System lösen.
Zunächst müssen wir jedem Asset den Schweregrad zuweisen. Analysieren Sie anschließend die Verbindungen zwischen Assets, unabhängig davon, ob sie sicher sind oder nicht, und priorisieren Sie die Assets nach ihren allgemeinen Auswirkungen auf die gesamte Landschaftssicherheit. Sie haben beispielsweise ein Asset mit geringem Risiko, beispielsweise ein Testsystem ohne kritische Daten. Dieses System hat eine Verbindung mit dem Produktionssystem, und dieses Produktionssystem hat wiederum eine Verbindung mit der ICS-Infrastruktur. Unter Berücksichtigung aller Verbindungen kann dieses Testsystem einen großen Einfluss auf die gesamte Landschaft haben, und wir sollten uns um seine Sicherheit kümmern.
Zusätzlich zu den Mechanismen eines Anwendungsservers können Server häufig mit einer Reihe anderer Mechanismen verbunden sein. Beispielsweise können SAP-Lösungen auf Windows-Servern installiert werden, die Teil einer einzelnen Domäne sind und mit den Berechtigungen eines gemeinsamen Kontos ausgeführt werden. In diesem Fall bedeutet der Zugriff auf einen Server fast immer den Zugriff auf alle anderen Server, unabhängig davon, wie gut sie auf Anwendungsebene geschützt sind. Es ist auch möglich, wenn Links oder vertrauenswürdige Verbindungen über DBMS implementiert werden. DBMS speichert häufig Verweise auf andere Datenbanken mit vordefinierten Authentifizierungsdaten, wodurch andere DBMS zugänglich werden. Darüber hinaus umfasst der Umfang solcher Mechanismen alle anderen möglichen Methoden zum Eindringen in das Nachbarsystem, die Auditoren normalerweise bei Penetrationstests verwenden, dh den Versuch, sich bei einem Nachbarsystem mit denselben oder ähnlichen Kennwörtern sowohl auf Betriebssystem-, DBMS- als auch auf Anwendungsebene anzumelden sowie alle Arten der Suche nach Passwörtern im Klartext im Dateisystem; Update, Integration, Backup-Skripte usw. Alle diese Optionen sollten überprüft werden, um das Risiko eines Eindringens mit einer schwachen Verbindung zu allen Systemen auszuschließen.
Ein weiteres Risiko für unsichere Verbindungen ist ein Datenverlust. SAP-Systeme sollten Daten während der Übertragung verschlüsseln. Es ist klar, dass der HTTP-Verkehr durch SSL gesichert werden sollte, aber der größte Teil des Verkehrs wird mit den standardmäßig unsicheren proprietären Protokollen von SAP übertragen, z. B. RFC (Protokoll zum Verbinden von SAP-Systemen), DIAG (Protokoll zum Verbinden des SAP-Clients mit SAP Server). und Message Server-Protokoll. Leider gibt es keine Möglichkeit, den Message Server-Verkehr zu sichern. Daher ist es die einzige Option, diesen Dienst einfach unter die Firewall zu stellen. Bei DIAG- und RFC-Protokollen kann die Verschlüsselung über SNC implementiert werden.
SNC ohne Single Sign-On-Funktion steht allen SAP NetWeaver-Kunden für SAP GUI mit SNC-Client-Verschlüsselung und für die gesamte RFC-Kommunikation zwischen SAP-Servern zur Verfügung. Grundlegende Single Sign-On-Funktionen sind in Umgebungen verfügbar, in denen SAP-Server und SAP-GUI-Clients Microsoft ausführen.
Zusammenfassung
Die ERP-Sicherheit ist eine komplexe Aufgabe. Wenn Sie jedoch nur diese vier allgemeinen Schritte ausführen, kann sich das Sicherheitsniveau Ihres ERP-Systems erheblich verbessern. Erst nach sicherer Implementierung der Architektur ist es sinnvoll, weitere Schritte wie das Schwachstellenmanagement und die Reaktion auf Vorfälle durchzuführen.