SAP-Systeme schützen
Werbung
Wissen aus erster Hand. Leseprobe Die Security-Experten Holger Stumm und Daniel Berlin vermitteln Ihnen in dieser Leseprobe, wie Sie die Sicherheit Ihrer SAP-Systeme auf jeder Netzwerk-Ebene herstellen. Sie erhalten einen Überblick über die wichtigen Begriffe und Architekturgrundlagen und lernen die im SAP-Umfeld stark genutzten Netzwerkprotokolle kennen. Außerdem wissen Sie nach der Lektüre, wie Sie Ihre Netzwerke und Komponenten härten können. Dazu enthält diese Leseprobe das Inhaltsverzeichnis und das gesamte Stichwortverzeichnis des Buchs. Kapitel 4: »Netzwerksicherheit herstellen« Inhaltsverzeichnis Index Die Autoren Leseprobe weiterempfehlen Holger Stumm, Daniel Berlin SAP-Systeme schützen 426 Seiten, gebunden, Februar 2016 69,90 Euro, ISBN 978-3-8362-3851-9 www.sap-press.de/3907 Kapitel 4 »Das Internet? Gibt’s den Unsinn immer noch?« Homer J. Simpson 4 Netzwerksicherheit herstellen In diesem Kapitel betrachten wir die Sicherheit der Netzwerke im SAP-Umfeld. Diese entsprechen den Netzwerken, die für die gesamten Unternehmensbereiche zum Einsatz kommen, denn in der Regel gibt es keine abweichende Netzwerkarchitektur für die SAP-Lösungen. Nach einer Einführung in die wichtigsten Begriffe und Architekturgrundlagen werfen wir einen Blick auf die Netzwerkprotokolle, die im SAP-Umfeld stark genutzt werden. Wir geben Ihnen Hinweise, wie Sie diese Netzwerke und Komponenten härten können. Abschließend geben wir noch einen Ausblick, wie die Zukunft der Netzwerke in Gestalt der Software Defined Networks aussehen wird. 4.1 Netzwerk, Switches, Router und Firewalls In diesem Abschnitt erklären wir Ihnen zunächst wichtige Begriffe im Zusammenhang mit den Netzwerken anhand des ISO/OSI-Referenzmodells. 4.1.1 Das ISO/OSI-Referenzmodell Um die Elemente, die in Unternehmen ein komplettes SAP-Netz bilden, besser zu verstehen, ist es oft hilfreich, diese in einen normierten Zusammenhang zu stellen. Bei allen Diskussionen um das Wie, Wo und Was in einem Unternehmensnetzwerk hat es sich als hilfreich erwiesen, hier auf das Netzwerkmodell der Standardisierungsgremien ISO bzw. OSI zurückzugreifen, Diese haben die gesamte Netzwerkkommunikation in einzelne Ebenen isoliert und den Ebenen jeweils einen definierten Funktionsumfang zugewiesen. So kann man auch in komplexen Netzwerken den Verkehr jeweils in diese 101 4 Netzwerksicherheit herstellen Netzwerk, Switches, Router und Firewalls funktionalen Ebenen (Layer) unterteilen und die Diskussion gezielt auf einzelne Segmente führen. Denn auch die Funktionen von Ethernet-Adaptern, Clients, Switches, Routern und Firewall lassen sich hervorragend semantisch und syntaktisch im Rahmen dieser Norm beziehungsweise dieses Modells erklären. Ohne es hier im Detail vorzustellen (das würde den Rahmen dieses Buches sprengen) werden wir in den Kapiteln über SAP-Netzwerke immer wieder auf das ISO/OSI-Referenzmodell zurückgreifen. Deshalb wollen wir die wichtigsten Funktionsmerkmale kurz erläutern und in den SAP-Netzwerkkontext stellen Netzwerkreferenzmodell In dem ISO/OSI-Referenzmodell wird beschrieben, wie ein Datenpaket von einer Anwendung selbst (die nicht im OSI-Referenzmodell beschrieben wird) über die Anwendungsschnittstelle (Ebene 7) bis hinunter auf die Bit-Ebene (Ebene 1) und dann letztlich auf das Übertragungsmedium (z. B. Kupferkabel) kommt. Abbildung 4.1 zeigt die verschiedenen Ebenen im Überblick. Wie die Anwendung ist auch das potenzielle Kupferkabel nicht in ISO definiert, wohl aber die Methode, wie das Bit auf das Medium kommt. (7) Anwendungsschicht (Application Layer) (6) Darstellungsschicht (Presentation Layer) (5) Sitzungsschicht (Session Layer) (4) Transportschicht (Network Layer) (3) Vermittlungsschicht (Network Layer) (2) Sicherungsschicht (Data Link Layer) (1) Bit-Übertragungsschicht (Physical Layer) ISO/OSI-Modell Abbildung 4.1 Das Sieben-Schichten-Modell nach ISO/OSI 102 4.1 Ebene 1: Netzwerkebene (Physical Layer) Für die Betrachtung der Netzwerke sind vor allem die Ebenen 1 (BitEbene, physische Ebene) bis 4 (Transportschicht) relevant. Diese bilden die Elemente ab, die als akademische Norm das abbilden, was man in Unternehmen und in der IT gemeinhin als Netzwerke versteht. Die erste Ebene ist die der bitweisen Übertragung, der Netzwerktopologie und der Infrastruktur (im englischen Original auch als Physical Layer bezeichnet). Die dabei verwendeten Verfahren bezeichnet man als übertragungstechnische Verfahren. Geräte und Netzkomponenten, die der Bit-Übertragungsschicht zugeordnet werden, sind z. B. die Antenne und der Verstärker, Stecker und Buchse für das Netzwerkkabel, der Repeater, der Hub oder der Switch. Hier gibt es keine technische Verknüpfung zu spezifischen SAP-Protokollen. Die physikalische Ebene der Übertragung Ebene 2: Sicherungsschicht (Data Link Layer) Die zweite Ebene, die auf Deutsch etwas unbeholfen mit Sicherungsschicht übersetzt ist, wird im Englischen als Data Link Layer funktional deutlicher bezeichnet. In der Nomenklatur ist schon zu erkennen, dass es darum geht, die Verbindung und Sicherstellung der fehlerfreien Datenübertragung zwischen zwei Netzwerkpunkten zu gewährleisten. Nach der amerikanischen Normungsbehörde IEEE ist Ebene 2 in zwei Unterebenen (sub layers) unterteilt: LLC (Logical Link Control, Ebene 2b) und MAC (Media Access Control, Ebene 2a). Die Hardware, die dieser Schicht zugeordnet ist, sind Bridges, Switches und Multiport-Bridges. Das Ethernet-Protokoll beschreibt sowohl Ebene 1 als auch Ebene 2, wobei auf dieser als Zugriffskontrolle CSMA/CD zum Einsatz kommt. Letztlich sind in Ebene 2 die Elemente definiert, die für ein Netzwerk das definieren, was man gemeinhin als »Topologie« bezeichnet. Im Bereich des Ethernets sind es vor allem die Idee der Leitungen aus Ebene 1, in die sich die Netzwerkeinheiten einklinken und über die sie sich an das Netzwerk anschließen. Diese Leitungen können so miteinander kommunizieren und sich gegenseitig auf bestehende Kollisionen und Störungen hin überprüfen (CSMA/CD). So verbundene Leitungen bilden einen Strang, an dem die einzelnen Netzwerkelemente (Taps) hängen. Auch hier gibt es noch keine Verbindung zu einem SAP-Protokoll, in der SAP-Netzwerkarchitektur ist dies eine Ebene, die den Herstellern vorbehalten ist. 103 Die Verbindung der physischen Kommunikation 4 Netzwerksicherheit herstellen Ein Netzwerk bilden Daten transportieren Netzwerk, Switches, Router und Firewalls Ebene 3: Vermittlungsschicht (Network Layer) Ebene 5: Sitzungsschicht (Session Layer) Die Ebene 3 ist die Vermittlungsschicht, der Network Layer. Es ist die Schicht, die im Router adressiert ist. Hier erfolgt das Handling der Adressen, die Identifikation der Weiterleitung zu anderen Netzwerksegmenten etc. Das »IP« im Interchange Protocol von TCP/IP findet hier statt. Die zugehörige Hardware auf dieser Schicht sind Router und Layer-3-Switches. Auf der Ebene 5 (Sitzungsschicht oder Session Layer) wird die Prozess-Kommunikation definiert. Dies ist nicht nur die technische Kommunikation, die auf den Schichten 1–3 stattfindet, sondern definiert den Session Context, den Zusammenhang und die Abfolge der Kommunikation. Auch hier gibt es noch keine direkte Verknüpfung mit einem SAPProtokoll, da hier noch die klassische Netzwerkadressierung, Wegsuche und Transportfindung (Routing) stattfinden. Der Unix Remote Procedure Call (RPC) und somit auch das SAP-Derivat Remote Function Call (RFC) sind hier zu finden. SAP hat eine Abfolge definiert und die Ebene 5 definiert die Synchronisationsund Wiederaufsetzpunkte hierzu. Ebene 4: Transportschicht (Transport Layer) Ebene 6: Darstellungsschicht (Presentation Layer) Die Ebene 4 ist die Anwendungsebene, auf der die SAP-Protokolle aufsetzen. Sie wird als Transportschicht bezeichnet (engl. Transport Layer; auch Ende-zu-Ende-Kontrolle oder Transport-Kontrolle), die den »Payload« (Nutzdaten) weiterleitet. Aufgabe der Transportschicht ist die Segmentierung des Datenstroms. Sie stellt auch für die höheren Ebenen eine definierte Schnittstelle dar, auf die diese einheitlich zugreifen können. Die Darstellungsschicht (Presentation Layer; setzt die systemabhängige Darstellung der Daten in eine unabhängige Form um und ermöglicht somit den syntaktisch korrekten Datenaustausch zwischen unterschiedlichen Systemen. Das heißt, dass hier die Funktionen des SAP GUI durch das DIAG-Protokoll umgesetzt werden. Ein Datensegment ist dabei eine Dateneinheit (Data Unit) die zur Datenkapselung auf der vierten Schicht (Transportschicht) verwendet wird. Es besteht aus Protokoll-Elementen, die Schicht-4-Steuerungsinformationen enthalten. Als Adressierung wird dem Datensegment eine Schicht-4-Adresse vergeben, also ein Port. Das Datensegment selbst wird in der Schicht 3 in ein Datenpaket gekapselt. Hier setzen die Netzwerkprotokolle der SAP auf. Um von verschiedenen Plattformen unabhängig zu sein, hat SAP für alle Netzwerkverbindungen die Zwischenschicht Network Interface (NI) entwickelt. Diese wird von SAProutern und allen SAP-Programmen, sowie von den Software Development Kits für CPI-C und Remote Function Call (RFC) genutzt. Somit setzt auch das DIAG-Protokoll von SAP auf die Transportschichten auf. Aus Sicht des Angreifers sind dies die Schichten, die bei einer Attacke adressiert werden. Dies sind vor allem die Protokolle selbst sowie der Router-Verkehr. 104 Ebenso findet hier nominell die SNC-Verschlüsselung statt, da SNC ja letztlich die Anwendungsdaten verschlüsselt, aber natürlich nicht die darunter liegenden Schichten des Protokolls. Die Darstellungsschicht gewährleistet, dass Daten, die von der Anwendungsschicht eines Systems gesendet werden, von der Anwendungsschicht eines anderen Systems gelesen werden können. Session-Kontext und RPC/RFC DIAG und SNC Ebene 7: Anwendungsschicht (Application Layer) Die Ebene 7 ist die technische Schnittstelle des Netzwerks zur Anwendungsebene und wird oft von Programmierern als Application Programming Interface (API) wahrgenommen. Es handelt sich um die Schnittstelle des Anwendungsprogramms. Ebene 7 beschreibt also nicht die Anwendung selbst, sondern definiert die Art und Weise, wie Programme mit den Netzwerkkomponenten kommunizieren können. In aktuellen Programmiersprachen wird eine solche Schnittstelle in der Regel als API bezeichnet. In der SAP-Welt stellt etwa das Protokoll Dynamic Information and Action Gateway (DIAG) die Schnittstelle zu Ebene 7 des Modells dar. 105 4.1 SAP-GUISchnittstelle 4 Netzwerksicherheit herstellen Gesamtsicht auf das ISO/OSI-Modell Wichtig ist es aus sicherheitstechnischer Sicht, das Netzwerk als Abfolge von Funktionen wahrzunehmen: Es gibt das Netzwerk selbst mit seinen technischen Elementen wie Repeatern etc. und es gibt den Zugang zu den Netzwerken wie Netzwerkadapter und Switches. Dann folgen die »intelligenten« Funktionen des Netzwerks wie Router und darüber liegen die session-bezogenen Layer wie RFC-Protokoll, RFC-Gateway und die Anwendungsschnittstellen. Verschlüsselung ist eine Form des Darstellungsschicht, das SAP GUI eine Form des Presentation Layers. Netzwerk, Switches, Router und Firewalls Voraussetzung für die Nutzung aller Verschlüsselungsfunktionen, aber auch aller weitergehenden Funktionen im Bereich Sicherheitszertifikate und digitaler Signierung ist die Installation der SAP Cryptographic Library. Dies ist ein Produkt, das Kunden auch für SNCVerbindungen zwischen Systemkomponenten zur Verfügung steht. Weitere Informationen über Verschlüsselung im SAP-Bereich, dem SNC-Protokoll und der Implementierung dieser Technolgien erhalten Sie im SAP Help Portal unter der Rubrik SAP Cryptographic Library. 4.1.3 4.1.2 Verschlüsselung der Netzwerkverbindungen mit SNC Mit den Secure Network Communications, den SNC-Verbindungen, hat SAP eine eigene Verschlüsselungsebene geschaffen. In den letzten Jahren wird speziell die Verschlüsselung von Verbindungen zwischen kommunizierenden Komponenten in SAP-Landschaften bei Audits immer wieder gefordert. Bei vielen Kunden war sie bisher noch nicht im Einsatz. Verschlüsselung mit SNC Im Standardfall, z. B. bei einer Kommunikation zwischen einem Benutzer mit SAP GUI und dem SAP NetWeaver Application Server erfolgt die Kommunikation unverschlüsselt im Klartext bzw. zwar komprimiert, aber trotzdem ungesichert. Das bedeutet, dass bei einem Mitschnitt der Verbindung, einem Sniff, die Daten (inkl. Passwort und weiteren Anmeldedaten) unverschlüsselt zu sehen sind. Abhilfe schafft hier eine auf kryptografischen Grundlagen vorgenommene Verschlüsselung. SAP hat hierfür das SNC-Protokoll geschaffen. SNC sichert die Datenkommunikationspfade zwischen verschiedenen Client- und Serverkomponenten des SAP-Systems. Es gibt bekannte kryptografische Algorithmen, die von den unterstützten Sicherheitsprodukten implementiert wurden; mit SNC können Sie diese Algorithmen auf Ihre Daten im Netzwerkverkehr anwenden, um die Sicherheit zu erhöhen. Die gesamte Kommunikation zwischen zwei mit SNC geschützten Komponenten wird gesichert (z. B. zwischen dem SAP GUI und dem Anwendungsserver). Sie können so zusätzliche Sicherheitsfunktionen von Drittanbietern verwenden (z. B. Smartcards). 106 Firewall in der SAP-Umgebung (ISO/OSI) Eine klassische Firewall, die immer wieder als zentrales Element in jedem Sicherheitskonzept aufgeführt ist, ist keiner Ebene des ISO/ OSI-Modells direkt zugeordnet. Sie ist eher komplementär zur Architektur von Netzwerk und Anwendungskommunikation. Eine Firewall ist eine Software, die sich in das Netzwerk einklinkt und dieses von dem Rechnernetz (Topologie), das sich jeweils vor der Firewall befindet, segregiert damit jedes angeschlossene Netzwerksegment eine eigene Sicherheitsebene, eine Policy bilden kann. So werden logische Ebenen gebildet, sogenannte Tiers, die voneinander getrennt sind. Die Firewall stellt dabei beim Übergang von einem Netzwerksegment zu einem anderen die Einhaltung des in der Firewall hinterlegten Regelwerks sicher. Ein klassisches Beispiel sind die Regeln, welcher Client auf Systeme hinter der Firewall zugreifen darf. Wichtig ist, dass Sie die verschiedenen Richtungen der Kommunikation einzeln betrachten. So überprüft die Firewall z. B., ob ein SAP GUI von einem bestimmten Rechner auf ein SAP-System zugreifen darf, stellt aber auch sicher, das umgekehrt der Server nicht beliebige Verbindungen öffnen kann, sondern dem Client nur auf der gerade geöffneten Leitung antwortet. Dies sind die grundlegenden Anwendungen der Firewall, die man den Ebenen 1 bis 4 des ISO/OSI-Modells zuordnen kann. Darüber hinaus beschränken sich moderne Firewalls nicht nur auf die physikalische Kontrolle von Verbindungen, sondern erweitern die Funktionen um die intelligente Analyse des Datenverkehrs. Sie setzen dann auf den Ebenen 4 bis 7 des ISO/OSI-Modells auf und beziehen damit auch Komponenten aus der Anwendungskontrolle mit in die Sicherheitsbetrachtung ein. 107 Firewall und SAP-Systeme 4.1 4 Netzwerksicherheit herstellen Paketfilter Content-Filter Die einfache Filterung von Datenpaketen anhand der Netzwerkadressen ist die Grundfunktion aller Firewalls (in einem TCP/IP-Netz ist damit die Filterung des Ports und der IP-Adresse des Quell- und Zielsystems gemeint). Filterung bezeichnet hier sowohl das positive als auch das negative Routing, also den Zugang (Access) oder die Ablehnung (Deny) einer Route. Dieser Inhaltsfilter ist eine Form des Proxyfilters, der die Nutzdaten einer Verbindung auswertet und z. B. dafür gedacht ist, auf beliebigen Inhalt der Kommunikation zu filtern. Stateful Inspection Diese zustandsgesteuerte Filterung ist eine erweiterte Form der Paketfilterung. Damit gelingt es, den Zugriff auf eine etablierte Verbindung genauer zu beschränken und so das interne Netz besser vor ungewollten Zugriffen von außen zu schützen. Bei dieser Betrachtung eines Paketes bzw. einer Kommunikation wird auch der Kommunikationszustand (Ebene 5 ISO/OSI, der Session Layer) mit berücksichtigt. Firewall und Kontext Hier wird kontrolliert, ob eine etablierte Verbindung auch keine Seitenkommunikation aufbaut, um etwa aus einer Session auf eine andere zu verzweigen. In SAP-Systemen kann solch eine Stateful Inspection sich z. B. als Verbindungsabbruch manifestieren, wenn Inhalte (z. B. Content Header) sich während der Kommunikation von Client zu Server verändern. SAP Web Services können in diese Kategorie fallen. Proxyfilter Ein Proxyfilter stellt stellvertretend für den anfragenden Client die Verbindung mit dem Zielsystem her und leitet die Antwort des Zielsystems an den ursprünglichen Client weiter. Da er die Kommunikation selbst führt, kann er sie nicht nur einsehen, sondern auch beliebig beeinflussen. Während in großen Netzen die Proxy-Funktion oft von dedizierten Servern übernommen wird, kann dies in Einzelsituationen auch von spezialisierten Firewalls übernommen werden. SAP Web Dispatcher SAP-Landschaft analysieren Der SAP Web Dispatcher übernimmt einige dieser Funktionen, wenn im SAP-Bereich Webanwendungen angesprochen werden. Eine Sonderform ist der Reverse Proxy, dessen Aufgaben im SAP-Bereich von dem inzwischen bei den meisten Kunden in Vergessenheit geratenen SAP Business Connector übernommen werden konnten. 108 Auch diese Funktionen können nicht nur von einer Firewall übernommen werden, sondern auch von einem SAP Web Dispatcher. Gerade bei SAP-NetWeaver-AS-Java-Servern wird diese Funktion benutzt, um gewisse bekannte und gefährliche Kommandos von außen aus dem Verkehr heraus zu filtern. Auch das Sperren von unerwünschten Webseiten anhand von Schlüsselwörtern und Ähnliches fallen darunter. Auch können in Bezug auf SAP-Traffic mit Firewalls der neuesten Generation verhaltenstechnische und semantische Analysen des Datenstroms ausgeführt werden, wie z. B.: Darf ein HR-Nutzer CRM-Daten herunterladen? Solche Fälle können dann erkannt und geblockt werden. 4.2 SAP-Landschaft analysieren Wenn die Sicherheitsbedürfnisse einer SAP-Landschaft betrachtet werden, ist es wichtig, sich über die grundlegenden Komponenten zu verständigen. In den 1980er Jahren, als es im SAP-Umfeld noch kein umfängliches Internet gab (von den Anfängen als DARPA-Netzwerk der amerikanischen Verteidigungsministerien einmal abgesehen), waren auch das Ethernet und die damit verbundenen Protokolle nicht wie im heutigen Ausmaß vorhanden. Die SAP-Ingenieure mussten sich Teile ihres Netzwerkprotokolls selbst realisieren und haben deshalb eigene Teilkomponenten erstellt. Diese Elemente, die sich auch oft nicht eindeutig im ISO/OSI-Modell wiederfinden, sollen hier als Grundlage für die Sicherheitsbetrachtungen aufgezählt werden. Die Implementierung der Netzwerkkomponenten der 3-Tier-SAPArchitektur auf einem TCP/IP Stack war geprägt von den Anforderungen der Portierung der Kommunikation der alten IBM-Welt mit ihren Terminals. Viele Artefakte im SAP-GUI-Protokoll resultieren daraus. Deshalb müssen die Angriffe auf diese Protokolle auch sehr SAP-spezifisch sein. Hier versagen oft die standardisierten Netzwerk-Hacker- 109 SAP Web Dispatcher als Content Filter 4.2 4 Netzwerksicherheit herstellen Werkzeuge der Internet-Ära und müssen durch Programmierer mit profunden SAP-Protokoll-Kenntnissen selbst erschaffen werden. Das ist mit Sicherheit eines der Hauptgründe, warum es in der Vergangenheit wenig ausgewiesene Hacker für die SAP-Netzwerke gibt. Das hat sich aber gerade in den letzten Jahren stark geändert. Multi-TierArchitektur im SAP-Umfeld Schon im Bereich der Mainframe-Kommunikation war es immer das Credo der SAP-Entwickler, sich nie auf spezifische Hardwareprotokolle einzulassen. Deshalb wurde zur Integration der Siemens BS/2000- und IBM/370-Architektur die jeweilige Ebene immer abstrahiert angesprochen. Diese Weitsicht zahlte sich aus, als man mit SAP R/3 in die Unix-Welt migrierte. Die eigene abstrakte Architektur passte hervorragend zu den Client-Server-Strukturen. Und mit den drei Komponenten Präsentationsebene (SAP GUI), Anwendungsserver (SAP NetWeaver AS ABAP und RFC) und Datenbankabstraktion hatte man die notwendigen Elemente für die herstellerunabhängigen Implementierungen beisammen. Auf diese drei Ebenen gehen wir im Folgenden genauer ein. 4.2.1 Tier 1: SAP-GUI-Client Der Hauptzugang zu SAP-Systemen basiert in allen Systemen auf dem SAP GUI. Dieser Zugang basiert auf einem Rich-Client-Konzept, das ein proprietäres Netzwerkprotokoll verwendet. Das Konzept, das das SAP GUI verwirklicht, kommt ursprünglich aus der TerminalSteuerung; dort wurden pro Bildwechsel 24 × 80 Zeichen übermittelt und der Server (damals: Mainframe) leitete daraus die notwendigen nächsten Schritte (basierend auf den Benutzereingaben) ab. Auf dieser Basis wurde in SAP R/3 dann eine client-/server-basierte Dialogsteuerung entwickelt. Durch die damals schon praktizierte Herstellerunabhängigkeit der verwendeten Protokolle war die SAP-Dialogsteuerung in allen Netzwerkvarianten ablauffähig. Das Protokoll, das in der alten Welt benutzt wurde, war die SNAArchitektur der 3270-Terminals. Für die Unix-Welt von SAP R/3 wurde die Dialogsteuerung auf dem TCP-IP-Stack realisiert beziehungsweise wurde die DIAG-Struktur der übermittelten Pakete darauf angelegt. Deshalb liegt die Zuordnung des DIAG-Protokolls auch auf Ebene 6 des ISO/OSI-Modells (des Presentation Layers) und nicht auf Ebene 3 oder 4 (Network bzw. Transport Layer). 110 SAP-Landschaft analysieren Aus Sicht eines Angreifers ist das SAP GUI sehr interessant. Zum einen bietet die auf dem Client liegende SAPINI-Datei einen hohen Informationswert, denn dort sind SAP-Systeme mit Adressen und Zielrouten hinterlegt. Zum anderen kann man sicher sein, das die Strecke vom Client zum SAP-System für diesen Desktop freigeschaltet ist. SAP GUI Hack zur Übernahme der IP-Adresse Wenn man Zugang zu einer Workstation oder einem Desktop hat, auf dem SAP GUI installiert ist, möchte man von hier aus mit seinen eigenen Hacker-Werkzeugen wie Nmap oder Metasploit weiter arbeiten. Da aber selbst einfach geschützte Arbeitsplätze in Unternehmen es nicht erlauben, Software zu verändern oder installieren, muss man hier einen Trick verwenden. Ich benutze dafür oft meinen Laptop mit einer Kali-Linux-Distribution. Hiermit versuche ich, die MAC-Adresse des PCs oder Laptops, den ich übernehmen will, zu ermitteln. Das geht meistens in der DOSKommandozeile mit dem Windows-Befehl ipconfig /all. Dieser zeigt mir für den Ethernet-Adapter die MAC-Adresse an. Diese gebe ich dann in Kali-Linux ein (»MAC Spoofing«). Dann stecke ich den Netzwerkstecker vom Desktop in den Laptop um. Ich bin jetzt zwar mit meiner neuen Maschine nicht angemeldet, habe aber auf der Netzwerkebene vollen Zugriff auf die Infrastruktur. Viele werden sagen, dass dies ein simpler Hack ist, aber trotzdem gehört er zum Standard-Repertoire und verdient es, hier erwähnt zu werden. Eine klassische Gegenmaßnahme liegt im Betrieb des Netzwerks. In vielen Unternehmen wird bei dem für die Sicherheit zuständigen Netzwerkadministrator eine Warnung ausgelöst, wenn an Arbeitsplätzen Netzwerkkabel ausgesteckt und wieder eingesteckt werden. Darüber können solche Versuche identifiziert werden. Bei sicherheitsbewussten Unternehmen wird dann auch gleich jener berühmte breitschultrige Herr im schlecht sitzenden dunklen Anzug (mit der Beule in der Brusttasche) losgeschickt, um nachzusehen, was dort passiert. 4.2.2 Tier 1: Zugang aus dem Internet und Übergang ins Intranet Dieses Netzwerksegment ist der Übergang vom Benutzer im anonymen Internet zum authentifizierten Intranet-Benutzer und kennzeichnet auch die Grenze zum Unternehmensnetzwerk. Traditionell nennt man eine solche Zone auch Demilitarisierte Zone (DMZ), abhängig von der jeweiligen Architektur. Wichtig ist, das hier, meist durch eine Firewall geschützt, der Prozess oder der Benutzer sich in 111 SAP-GUI-Hack 4.2 4 Netzwerksicherheit herstellen SAP-Landschaft analysieren irgendeiner Form anmelden muss, sei es durch ein Ticket, einen VPN-Zugang oder ein simples Log-in. Aus Sicht eines SAP-Netzwerks ist Tier 1 eine weit außen liegende Grenze, denn in klassischen Unternehmensnetzwerken liegen die Anwendersysteme im Tier 2 und erst die SAP-Systeme selbst in Tier 3. Das DIAGProtokoll SAP-GUI-Netzwerkverkehr dekodieren Für die Kommunikation zwischen SAP GUI und dem Anwendungsserver wurde das Dynamic Information and Action Gateway Protocol (kurz DIAG) entwickelt. Es ist ein proprietäres Protokoll, dessen Spezifikation nicht veröffentlicht wurde – einige Details sind jedoch inzwischen bekannt geworden. DIAG übertragt binäre Daten, die im Standard komprimiert sind, es findet jedoch ohne die zusätzliche Verschlüsselung per SNC keine Absicherung des Datenverkehrs gegen Sniffing statt. Die Art der Datenkompression ist inzwischen bekannt und es existieren bereits Add-ons für bekannte Netzwerkdiagnose-Tools, wie z. B. Wireshark, die den DIAG-Datenverkehr dekomprimieren und so die Rohdaten lesbar machen. Ein Angreifer, der die Workstation kompromittiert hat, auf der das SAP GUI läuft, kann sogar die Kompression einfach ausschalten; der Benutzer merkt dies zwar, da ein Pop-up-Fenster im SAP GUI ihn warnt – ein findiger Angreifer könnte dies allerdings umgehen (ein Ansatz hierzu ist den Autoren bekannt). Zudem ist fraglich, ob es sich für einen Hacker lohnt, den zusätzlichen Aufwand der Dekompression des Datenverkehrs zu vermeiden, wo dies doch recht einfach möglich ist. Dazu muss einfach die WindowsUmgebungsvariable TDW_NOCOMPRESS auf den Wert 1 gesetzt werden. Ob dies auf einem mutmaßlich gehackten Windows-Rechner der Fall ist, können Sie einfach über die erweiterten Systemeinstellungen prüfen: Abbildung 4.2 Umgebungsvariable zur Deaktivierung der DIAG-Kompression Trotzdem kennt damit ein Angreifer noch nicht die Protokollinterna und ist nicht in der Lage, eine SAP-GUI-Sitzung vollständig in verständliche Kommandos und Antworten zu übersetzen. Um an Benutzername/Passwort-Kombinationen zu gelangen oder kritische Daten zu extrahieren, ist dies jedoch auch nicht unbedingt notwendig! Ist dem Angreifer der Benutzername bekannt, so findet er das Passwort im Klartext in direkter »Nähe«. In Abbildung 4.3 ist ein Mitschnitt des Netzwerkverkehrs eines SAP-GUI-Log-ins als Benutzer ddic zu sehen. Das Passwort abcd1234 ist nur einige Bytes nach dem Benutzernamen sichtbar (siehe Markierungen auf der rechten Seite). 1. Öffnen Sie die Systemsteuerung über das Startmenü. 2. Klicken Sie auf System und dann auf Erweiterte Systemeinstellungen. 3. Im Pop-up-Fenster wählen Sie den Reiter Erweitert und klicken dann auf Umgebungsvariablen. 4. Sollte die Variable gesetzt sein, erhalten Sie folgendes Bild (siehe Abbildung 4.2): Abbildung 4.3 Benutzername und Passwort im Klartext 112 113 Analyse eines NetzwerkMitschnitts 4.2 4 Netzwerksicherheit herstellen Das DIAG-Protokoll ist also im Standard – komprimiert oder nicht – ungeschützt! Ein Angreifer kann ohne tiefgreifendes, technisches Wissen Log-in-Daten Ihrer Benutzer aus mitgeschnittenem Netzwerkverkehr extrahieren. Doch es gibt Abhilfe. Sie können auch ohne eine Sign-on-Infrastruktur in SAP NetWeaver den Netzwerkverkehr zwischen SAP GUI bzw. dem BEx Analyzer und dem AS ABAP verschlüsseln. SNC Client Encryption SAP-Landschaft analysieren (1) SAP GUI starten (4) Benutzer gibt 1. Der Anwender meldet sich an einer Windows-Domäne an und startet eine SAP-GUI-Verbindung zu einem AS-ABAP-System, das SNC Client Encryption verwendet. 2. Die SNC-Client-Encryption-Komponente fordert ein Service-Ticket vom Microsoft Active Directory Server an. 3. Der Microsoft Active Directory Server gibt das Ticket an die SNCClient-Encryption-Komponente zurück. 4. Der Benutzer wird vom SAP GUI zur Eingabe seiner Log-in-Daten aufgefordert. 5. Alle Kommunikation mit dem AS-ABAP-System findet nun verschlüsselt statt. Das genaue Vorgehen zur Einrichtung von SNC Client Encryption kann je nach Release-Stand der beteiligten Systeme variieren – bitte rufen Sie daher immer die zur Version ihres AS-ABAP-Systems gehörige SAP-Dokumentation auf; dort gibt es ein eigenes Kapitel »SNC Client Encryption für Kennwortanmeldung verwenden«, in dem auch weiterführende Hinweise verlinkt sind. 114 (5) Sichere Kommunikation Benutzerkennung und Passwort ein Mithilfe von SNC Client Encryption können Sie die Kommunikation zwischen dem Client und einem AS ABAP per Secure Network Communications (SNC) verschlüsseln und die Daten vor neugierigen Blicken und Manipulationen absichern. Da der komplette Verkehr geschützt ist, können Hacker weder Log-in-Daten mitzulesen, noch geschäftliche Vorgänge ausspionieren oder in sie eingreifen. Als einzige technische, nicht in jedem Falle bereits vorhandene Voraussetzung ist ein Microsoft Active Directory Server zu nennen. Eine verschlüsselte SAP-GUI-Sitzung, wie sie in Abbildung 4.4 zu sehen ist, läuft dann folgendermaßen ab: Geschäftsprozess (2) Anfrage SAP Business Suite SAP S/4 HANA (3) Sicherheitstoken Microsoft Active Directory Abbildung 4.4 Ablauf einer SAP-GUI-Sitzung mit Client Encryption (Quelle: SAP) 4.2.3 Tier 2: Übergang von Intranet zur SAP-Tier Der Übergang von Tier 1 (der DMZ) nach Tier 2 funktioniert in der Regel wieder durch eine Firewall, die das DMZ-Intranet gegen das interne Netzwerk, manchmal auch Campusnetzwerk genannt, abgrenzt. In Tier 2 liegen oft die Mitarbeiter-Systeme, auf denen dann auch der SAP Rich Client (SAP GUI) läuft. Aber auch externe Programme und nicht unternehmenskritische Anwendungen können hier laufen. Aus dieser Ebene 2 werden dann die Verbindungen zu den SAP-Systemen im inneren Tier 3 aufgebaut. Remote Function Call (RFC) ist ein proprietäres SAP-Protokoll. Der RFC-Gateway ist die funktionale Verbindung der Endpunkte der Kommunikation mit einer äußeren Komponente. Es gibt in einem Standard-SAP-System zehntausende solche Funktionsaufrufe, von denen in der Regel nur ein kleiner Teil wirklich von außen aufgerufen wird. In vielen Fällen sprechen SAP-Server mit anderen SAP-Servern auf der Basis von ABAP-Anwendungen miteinander und benutzen das RFC-Protokoll zwischen AS-ABAP-Stacks. Ein System, der RFC Client, initiiert die Kommunikation und der Server nimmt diese Kommunikation auf. Abbildung 4.5 zeigt einen Überblick dieser unterschiedlichen Verbindungen. 115 RFC-Protokoll 4.2 4 Netzwerksicherheit herstellen Virtuelle Netzwerke und Software-Defined Networks 4.2.4 SAP NetWeaver Application Server ABAP, RFC-Server SAP NetWeaver Application Server ABAP, RFC-Client Programm ABAP-Laufzeitumgebung RFC-Destination RFC-Funktionsmodul RFC-Gateway Programm registrierter externer RFC-Server RFC-Funktionsmodul RFC-Funktionsmodul RFC-Funktionsmodul externer RFC-Client Programm gestarteter RFC-Server RFC-Destination RFC-Funktionsmodul Abbildung 4.5 Überblick über das RFC-Protokoll (Quelle: SAP) Aber auch externe Anwendungssysteme können diese Kommunikation initiieren. Es gibt Implementierungen der SAP-Kommunikationsbibliothek als SAP-Konnektoren in Java und als .NET-Implementierung für Microsoft-Umgebungen. RFC-Verbindungen und Verschlüsselung RFC-Verbindungen können sich auch der Verschlüsselungsfunktionen der SNC-Bibliotheken bedienen, ähnlich wie es das SAP GUI und das DIAG-Protokoll auch machen (siehe Abbildung 4.6). Diese Kommunikation wird dann in den entsprechenden Basis-Transaktionen STRUST, SM59 und RZ11 konfiguriert. Für die Clients gibt es ebenfalls entsprechende Bibliotheken, die alle auf der SAP Cryptolib basieren und diese implementieren. Tier 3: Die SAP-Systeme Bis zur Einführung von SAP HANA hatte SAP zu Datenbanken eine ähnliche Haltung wie zu den Netzwerken. SAP wollte weitestgehend unabhängig von Datenbanken sein und implementierte nur eine Schnittstelle zu den Datenbanken hin und nannte diese Open SQL. Es war letztlich eine klassische Implementierung einer Datenbankschnittstelle, wie man sie auch im Bereich ODBC kennt, einem Protokoll, das letztlich von und zu Datenbanken redet. Dieses Protokoll heißt DBCON und ist in der gleichnamigen Tabelle implementiert. Auf dieser Schnittstelle werden ausführbare SQLBefehle gesendet und das SAP-System (in der Regel der laufende ABAP-Serverdienst) erhält die Antwort in Form von einer mehr oder weniger komplexen Tabelle als Datenbereich zurück. Dieses Result Set ist die rohe Datenbasis, die das ABAP-Programm weiter bearbeitet. Die Kommunikation zwischen SAP-System und Datenbank wurde bis vor ein paar Jahren kaum als Sicherheitsproblem gesehen. Man betrachtete die Server als sicher (da diese ja bereits in den Netzwerksegmenten standen, die durch eine oder mehrere Firewalls geschützt waren). Zudem waren die Datenbankserver von einem ehemaligen Marktführer wie Oracle ja auch noch einmal besonders geschützt. SAP allerdings kommunizierte in der Regel über Verbindungen vom Anwendungs- zum Datenbankserver, die keinen oder nur sehr rudimentären Schutz auf den Verbindungen hatte. Bis vor einigen Jahren (und in vielen Systemen heute noch existierenden Produktivversionen) war die Oracle-Verbindung komplett ungeschützt. Ein Angreifer konnte (und kann) auch heute noch diese passwortlose Verbindung jederzeit übernehmen. Firmennetzwerk SNC (empfohlen) ABAP DB SNC (optional) DB WAN Firewall ABAP Anderes Servernetzwerk Firewall SAP GUI, RFC Clients Servernetzwerk Firewall Endanwendernetzwerk ABAP-Programmiersprache SNC (empfohlen) Abbildung 4.6 RFC mit SNC-Verschlüsselung (Quelle: SAP) 116 DB 4.3 Virtuelle Netzwerke und Software-Defined Networks Der Begriff der Software-Defined Networks (SDN) ist schon seit vielen Jahren im Umlauf, aber seinen Weg aus dem Elfenbeinturm der Wissenschaft in die Welt der industriell genutzten Netzwerke begann 2008. So wie die In-Memory-Datenbanktechnologie SAP HANA aus Stanford-Forschungen heraus entstand, wurde auch das SoftwareDefined Networking hier weiterentwickelt. 117 ODBC und DBCON 4.3 4 Netzwerksicherheit herstellen Stanford und Open Network Foundation Da die Stanford-Universität in Palo Alto liegt, also im Herzen des Silicon Valley und in direkter Nähe zu Google, Facebook, SAP und Oracle, wurde die Idee entsprechend gut aufgenommen. Aus dem zuerst einmal in akademischen Kreisen bekannten Modell wurde 2001 die Open Networking Foundation gegründet, die das Modell als Open-Source-Modell weiter benutzt. Die Hauptidee ist es, nur noch die Layer 1 und 2 (und eventuell 3) von entsprechenden Switches vornehmen zu lassen und die Switches direkt mit einem rein auf Software basierenden Controller kommunizieren lassen, der die anderen Funktionen (Ebene 3 bis 7) eines Netzwerks implementiert in reiner Software übernimmt. Bisher lag ja die überwiegende Funktion in dedizierter Hardware, von Netzwerkadaptern über Switches und Router bis hin zu den entsprechenden Adaptern in den Zielservern. Nun sollte dies alles von einer eigenen (Software-)Appliance vorgenommen werden. Nur die Switches bleiben bestehen Switches mit mehreren Dutzend Anschlüssen gibt es heute als sogenannte »Commodity«, also als Massen-Billigware vor allem aus China. Dort werden die Switches mit integrierten Schaltungen hergestellt, so dass ein 48-Port-Switch für ein paar hundert Euro zu bekommen ist. Dieser Switch brauchte nur ein Interface nach der Norm der in Stanford initiierten Open Network Foundation, und man kann den Rest des Netzwerks über entsprechende Frameworks abbilden. Der Ansatz mit den billigen Switches und Softwareframeworks sollte neue Möglichkeiten bringen. Netzwerke sollten direkt programmierbar werden und zentral durch einen reinen softwarebasierten Ansatz zu managen sein. Damit sollten Sie den Netzwerkverkehr optimal organisieren, lenken und verwalten können. Dadurch wären auch Anforderungen aus neuen Diensten wie Videostreams, cloud-basierenden Diensten oder die Separierung von Kundenetzen in großen Datacentern direkt möglich. Separierung von Kontrollfluss und Datenfluss Der Datenfluss in einem Netzwerk wird in eine Control Plane aufgesplittet, in der das ganze Routing stattfindet. Hier wird ein NetzwerkRequest von und nach einem Ziel geleitet. Auf der Data Plane läuft der assoziierte Datenverkehr. Sieht man sich heute einen beliebigen Backbone eines großen Providers an, so sind dort 30–50 % der Auslastung auf Streaming Video Services wie YouTube und Amazon zurückzuführen. Die immer größere Menge an Video-Konferenzen 118 Virtuelle Netzwerke und Software-Defined Networks kommt hinzu. Solch ein Verkehr würde davon profitieren, wenn er separat als Stream und nicht paketorientiert weitergeleitet wird. Gerade große Datacenter haben begonnen, in ihren Rechenzentren SDN-Netzwerke zu schaffen und produktiv einzusetzen. Zwar gibt es noch keine Standards, aber die Möglichkeiten, die sich die Betreiber hier selbst schaffen, sind den Aufwand nach eigenem Bekunden wert. Gerade in den Bereichen Kundensegmentierung (Multi-Tenant) und content-basiertem Routing (Streaming, Packeting) sind die Vorteile sehr hoch. Auch der Bereich Security wächst deutlich. Wo es protokollunabhängige Ebenen gibt, die nur für die Kontrolle zuständig sind und wo es Datenebenen gibt, die die kompletten Datenströme steuern, ist es möglich, ganz neue Sicherheitskontrollen einzubauen. Die SecurityInformation- und Event-Management-Systeme (SIEM, siehe Abschnitt 1.2.7, »Bestimmung der technischen Auswirkungen eines Angriffs«) mit ihren Datenmustern lassen sich hier in Echtzeit auf die Datenströme anwenden. So können auch kontrolltechnisch komplett neue Anwendungen entstehen. Die neue Architektur der Software Defined Networks wird die Implementierung von Netzwerken in den Datacentern grundlegend verändern. Und mit der Architektur wird auch die Sicherheit in Netzwerken komplett neu definiert. In jeder der neuen Komponenten dieser Architektur steckt auch ein starker Sicherheitsaspekt, der nicht mehr an eine Protokoll-Implementierung wie bei ISO/OSI gekoppelt ist, sondern sich ausschließlich über Software und deren Schnittstellen definiert. Dieser Ansatz hat heute schon neue Sicherheitssysteme erzeugt, die in den noch wenigen proprietären Implementierungen in ausgewählten Datacentern zu sehen ist. Die flächendeckende Einführung und Adaptierung dieser Technologie wird aber in den nächsten Jahren zu einer radikalen Änderung auch in der Sicherheit der Netzwerke führen. In Abbildung 4.7 wird solch eine Architektur gezeigt. Die grundlegende Idee ist es, dass eine Control Plane die eigentlichen Datenströme kontrolliert und bewegt. Die Control Plane hat ein Northbound Interface, das die Anwendungen kontrolliert, die auf diese Control Plane einwirken. 119 Control Plane 4.3 4 Virtuelle Netzwerke und Software-Defined Networks SDN-Anwendung SDN-Anwendung SDN-Anwendung SDNAnwendungslogik SDNAnwendungslogik SDNAnwendungslogik NBI-Treiber NBI-Treiber NBI-Treiber Service Level Agreement Northbound Interface NBI SDN Controller Instrumentierung NBI Agent Statistik SDN Kontrolllogik Events Anforderungen Sicherheit: IPS, IDS, SIEM Policy-Konfiguration Performance-Monitoring CDPI-Treiber Datenschicht SDN-Steuerungsschichtschnittstelle Netzwerkelement Netzwerkelement SDN-Datenpfad SDN-Datenpfad Setup der CDPI Agent CDPI Agent Elemente Weiterleitungsmodul/ Verarbeitung Weiterleitungsmodul/ Verarbeitung Abbildung 4.7 SDN-Architektur: Überblick der Open Networking Foundation Application Plane CDPI Data Plane Die Anwendungen selbst bestimmen das Verhalten des Netzwerks und haben die Intelligenz und die Attribute zur Steuerung. Die Ausführung dieser Logik wird dann aber der Control Plane übergeben. Die klassischen Funktionen wie Session Handling, intelligentes Routing und Datenanalyse sind in den Anwendungen und nicht mehr Funktionen des Netzwerks. Ebenso verhält es sich mit dem Control to Data Plane Interface (CDPI). Das CDPI übergibt die Steuerungen (von der Control Plane an die Data Plane) an die Schicht, die die Daten enthält und die Destinationen, von denen und an die die Daten bewegt werden sollen. Somit sind Netzwerksteuerung, Netzwerklogik und Daten vollkommen entkoppelt. Dadurch ist eine wesentlich höhere Flexibilität möglich als in herkömmlichen Netzwerkmodellen nach ISO/OSI. Die Segmentierung und Paketorientierung der Netzwerke sowie die Fokussierung auf Endpunkt-Kommunikation fällt hier komplett weg. Aus Sicht der Endpunkte entsteht durch die Control Plane, die Daten von A nach B bewegt, ein Datenpfad. Hier können auch große Daten- 120 4.3 mengen wie Videostreams bewegt werden, ohne diese stark zu segmentieren, oder es können Datenmengen gezielt geroutet werden, wie es in einem Multimandanten-Rechenzentrum nötig ist. Verwaltung & Administration Steuerungsschicht Anwendungsschicht Netzwerksicherheit herstellen Letztlich muss das SDN in letzter Konsequenz wieder Switches bedienen, die die Umsetzung auf die »letzte Meile«, die Netzwerktopologie der ISO/OSI-Ebenen 1 und 2 bringt. In großen Datacentern werden diese SDN-Segmente aber auch direkt gekoppelt, gerade bei hohen Datenmengen. Die neue Generation von Netzwerken jenseits der 10-Gbit-Datenmengen, die Backbone-Netze mit 100 Gbit, benötigen neue Methoden, solch hohe Datenmengen zu bewegen. 4.3.1 Forwarding Engine Die Idee einer neuen offenen Netzwerkarchitektur Die offene SDN-Architektur erregte natürlich das Missfallen aller Hersteller, die bisher teure Appliances verkauft haben. Dies betrifft alle Switch-Hersteller wie IBM und andere, aber vor allem die großen Netzwerkausrüster wie Cisco, CheckPoint Juniper und viele andere. Natürlich sahen sie eine Vision von billigen Switch-Appliances aus China und offener, kostenloser Software als nicht zielführend an. Aber auch die Hersteller konnten nicht ignorieren, das herkömmliche Netzwerkarchitekturen an ihre Leistungsgrenzen kommen, und konnten die vom großen Data-Center-Markt schon antizipierte Architektur nicht mehr zurücknehmen. So umarmte man, was man nicht mehr bekämpfen konnte und wurde Mitglied in der Open Networking Foundation, um fortan die Entwicklung so zu lenken, dass kommerzielle Interessen und Portierungen weiterhin berücksichtigt werden. Es gibt mittlerweile SDNLösungen von allen großen Anbietern, die aber eher eine proprietäre Tendenz haben. Die SDN-Frameworks im Umfeld der Standford-Initiative sind langsam verblichen, vor allem, weil keines der Frameworks so hochskalierbar und belastbar ist, wie es vor allem von großen Datacenter gefordert wird. Die Datacenter wiederum haben, als größte Kunden der Netzwerkausrüster, funktionierende eigene Implementierungen, die sie aber gerne gegen kommerzielle Implementierungen austauschen würden, um nicht weiterhin selbst entwickeln zu müssen. Open Network Foundation SDN ist weiterhin im Fluss: Große Kunden und Datacenter können und werden unter dem Innovationsdruck hier weiter entwickeln. Man erwartet in den nächsten fünf Jahren auch den flächendecken- SDN im Datacenter heute 121 4 Netzwerksicherheit herstellen den Durchbruch dieser Technologien. Dann wird SDN das Networking, wie wir es heute kennen, komplett verwandelt haben. 4.3.2 Sicherheit im Software-Defined Network SDN bietet komplett neue Ansatzmöglichkeiten, Sicherheit im Rechenzentrum zu implementieren. Ist es bisher softwaretechnisch ein mühseliges Unterfangen, die Pakete der ISO/OSI-Ebenen 1 bis 4 zu sammeln, auszuwerten und in einen Kontext wie SAP zu stellen, fällt all dies weg. Bei Netzwerkgeschwindigkeiten von 10 bis 100 Gbit/s würden auch herkömmliche Ansätze nicht mehr funktionieren. Im Zusammenspiel von Application Plane, Control Plane und Data Plane lassen sich Datenströme gezielt analysieren. Es muss nicht künstlich ein Kontext hergestellt werden (was den Echtzeit-Ansatz nicht realisierbar macht), sondern der Datenfluss kann ebenso wie ein Stream betrachtet und analysiert werden. Mustererkennung und Reaktion auf die Muster kann direkt in der Application Plane implementiert werden. Durch die Einwirkung der Control Plane auf die Data Plane kann dann direkt eine Aktion (wie z. B. der Abbruch) ausgeführt werden und es muss nicht umständlich eine weitere Network Appliance angesteuert werden. Angriffe auf SDN Aber auch das Hacking auf diese Infrastrukturen wird sich in demselben Maße entwickeln und als Sicherheitsberater werden wir uns dann damit beschäftigen, wo die Angriffsvektoren auf die Data und Control Planes entstehen und wie man diese bekämpft. Zukunft von SDN SDN wird heute schon von großen Datacentern als proprietäre Lösung eingesetzt und hat das Potenzial bewiesen, das es in einem solchen Umfeld haben kann. Es wird noch einige Jahre dauern, bis diese Technologie in den klassischen IT der Unternehmen ankommt, vermutlich mit dem nächsten Generationenwechsel der Appliances wie Firewalls, Load Balancern und Switches. Und diese Technologie steckt auch schon in allen virtualisierten Netzwerkumgebungen wie NSX von VMware, die bereits zeigen, wie Security auf einem solchen Layer funktioniert. 122 Auf einen Blick 1 Risiko- und Bedrohungsanalyse für SAP-Systeme ........ 25 2 Eine Sicherheitsstrategie entwickeln ........................... 53 3 SAP-Sicherheit – Standards und aktuelle SAP-Werkzeuge ......................................................... 79 4 Netzwerksicherheit herstellen .................................... 101 5 Werkzeugkasten des SAP-Sicherheitsexperten ............ 123 6 Schutz von SAProuter und SAP Web Dispatcher ......... 145 7 Schutz des SAP NetWeaver AS ABAP ......................... 163 8 Schutz des SAP NetWeaver AS Java ............................ 191 9 Schutz von Remote Function Calls .............................. 209 10 Passwortschutz ........................................................... 233 11 Schutz des Transportsystems ...................................... 263 12 Schutz der Datenbank ................................................ 281 13 SAP HANA und die Sicherheit der In-Memory-Datenbanken ........................................... 309 14 Erkennung von Angriffsmustern und Forensik ............. 329 15 Mobile Anwendungen sichern .................................... 361 16 Sicherheit im Internet der Dinge ................................ 383 Inhalt Einleitung .................................................................................. 1 Risiko- und Bedrohungsanalyse für SAP-Systeme ........................................................... 25 1.1 1.2 1.3 2 17 SAP-Systeme und die Cyber-Bedrohung .................. Vorgehen zum Erstellen einer Risikomatrix .............. 1.2.1 Risikoinformationen kritisch bewerten ....... 1.2.2 Risikoanalyse auf Basis internationaler Normen ..................................................... 1.2.3 Ein Risiko identifizieren ............................. 1.2.4 Grafische Darstellung des Risikos ............... 1.2.5 Bestimmung des Angriffsvektors und der Verletzbarkeit ............................................ 1.2.6 Bestimmung des Angreifers und der Verletzbarkeit ............................................ 1.2.7 Bestimmung der technischen Auswirkungen eines Angriffs ...................... 1.2.8 Formalisierter Risikofaktor aus dem Modell ...................................................... Internationale Standardmethoden für eine Risikoanalyse .......................................................... 1.3.1 Open Web Application Security Project ..... 1.3.2 NIST Risk Assessment ................................ 1.3.3 Bundesamt für Sicherheit in der Informationstechnik .................................. 29 31 31 33 34 38 39 40 41 43 44 44 46 48 Eine Sicherheitsstrategie entwickeln ...................... 53 2.1 2.2 2.3 Ziele einer Sicherheitsstrategie ................................ 2.1.1 Interne und externe Aufgaben ................... 2.1.2 Status quo feststellen ................................ 2.1.3 Penetrationstest zur Überprüfung des Status quo ................................................. Kosten und Nutzen abwägen .................................. Unternehmensbeispiele für Sicherheitsstrategien .... 2.3.1 Übungszentrum Netzverteidigung .............. 2.3.2 Cyber Control Center der Telekom ............. 57 58 60 61 65 67 68 73 7 Inhalt Inhalt 2.4 3 3.2 3.3 3.4 3.5 3.6 SAP-Sicherheit in der klassischen Sicht .................... 3.1.1 Ebene 1: Rich Client bzw. SAP GUI ............ 3.1.2 Ebene 2: Anwendungsserver und Message Server .......................................... 3.1.3 Ebene 3: Datenbankserver ......................... 3.1.4 Die klassische Drei-Ebenen-Architektur ...... 3.1.5 Verletzbarkeit der historischen SAP-Architektur ......................................... 3.1.6 SAP-Sicherheitshinweise ............................ SAP NetWeaver: Sicherheit mit neuer Softwaregeneration ................................................. SAP Enterprise Threat Detection .............................. 3.3.1 Einsatz in der SAP-internen IT .................... 3.3.2 Architektur der Komponenten .................... 3.3.3 Archive ...................................................... 3.3.4 Anonymisierung personenbezogener Daten ......................................................... 3.3.5 Muster in Log-Dateien erkennen lernen ..... SAP Code Vulnerability Analysis .............................. SAP Solution Manager als Steuerungsinstrument ..... 3.5.1 SAP EarlyWatch ......................................... 3.5.2 Security Self-Service über den SAP Solution Manager ............................... 3.5.3 Custom Code Lifecycle Management .......... Ausblick .................................................................. 79 80 4.3 81 81 82 82 83 5 5.1 84 86 86 87 88 88 90 91 97 97 Netzwerk, Switches, Router und Firewalls ............... 4.1.1 Das ISO/OSI-Referenzmodell ..................... 4.1.2 Verschlüsselung der Netzwerkverbindungen mit SNC ............................... 4.1.3 Firewall in der SAP-Umgebung (ISO/OSI) ................................................... 5.2 5.3 98 98 99 101 101 106 107 SAP-Landschaft analysieren ..................................... 4.2.1 Tier 1: SAP-GUI-Client ............................... 4.2.2 Tier 1: Zugang aus dem Internet und Übergang ins Intranet ................................ 4.2.3 Tier 2: Übergang von Intranet zur SAP-Tier .................................................... 4.2.4 Tier 3: Die SAP-Systeme ............................ Virtuelle Netzwerke und Software-Defined Networks ................................................................ 4.3.1 Die Idee einer neuen offenen Netzwerkarchitektur .................................. 4.3.2 Sicherheit im Software-Defined Network ... 109 110 111 115 117 117 121 122 Werkzeugkasten des SAP-Sicherheitsexperten ..... 123 Netzwerksicherheit herstellen ................................ 101 4.1 8 4.2 SAP-Sicherheit – Standards und aktuelle SAPWerkzeuge .............................................................. 79 3.1 4 Abschließende Überlegungen zur Sicherheitsstrategie ................................................. 77 5.4 5.5 5.6 Kali-Linux-Distribution ........................................... 5.1.1 Die Geschichte der Kali-Distribution .......... 5.1.2 Download und Installation ........................ 5.1.3 Kali Linux und SAP .................................... Rot gegen Blau: Werkzeuge für Angriff und Verteidigung ........................................................... 5.2.1 Vor dem Angriff: Die Zielanalyse ................ 5.2.2 Angriff: Netzwerkerkennung und -analyse mit Nmap .................................................. 5.2.3 Angriff: Server-Erkennung und -analyse mit Metasploit ........................................... Kommerzielle Produkte für Penetrationstests im Bereich SAP ............................................................ 5.3.1 Onapsis X1 und Onapsis OSP .................... 5.3.2 ERPScan .................................................... 5.3.3 Virtual Forge ............................................. 5.3.4 ESNC: Enterprise Security and Compliance ............................................... 5.3.5 Werth IT Auditor ....................................... Gegenmaßnahmen zum Schutz des Netzwerks ........ Patch-Management mit dem SAP Solution Manager ................................................................. Klassische Angriffsvektoren für Hacker und Penetrationstester ................................................... 5.6.1 Oracle-Hack .............................................. 123 124 124 125 126 126 129 133 136 136 137 137 137 137 138 139 141 142 9 Inhalt Inhalt 5.6.2 5.6.3 6 6.2 6.3 6.4 6.5 6.6 Der SAProuter im SAP-Netzwerk ............................. 6.1.1 Wann wird der SAProuter eingesetzt? ........ 6.1.2 Wann wird der SAProuter nicht eingesetzt? ................................................. 6.1.3 SAProuter installieren ................................. 6.1.4 Kontrolle und Protokollierung von Verbindungen zu SAP-Systemen ................. 6.1.5 SAProuter und Secure Network Communications SNC ................................. 6.1.6 SAProuter-String-Information ..................... Angriff auf den SAProuter ........................................ Gegenmaßnahme: Härten des SAProuters ................ Der SAP Web Dispatcher im SAP-Netzwerk ............. Angriff auf den SAP Web Dispatcher ....................... Gegenmaßnahme: Härten des SAP Web Dispatchers ............................................................. Schutz des SAP NetWeaver AS Java ....................... 191 8.1 145 146 147 148 7.4 7.5 Die ABAP-Laufzeitumgebung .................................. Der SAP NetWeaver AS ABAP als Angriffsziel .......... Berechtigungen nach dem Need-to-know-Prinzip .... 7.3.1 Need-to-know-Prinzip umsetzen ................ 7.3.2 Benötigte Anwendungen und Programme ermitteln .................................................... Schutz des SAP NetWeaver AS ABAP gegen Angriffe ................................................................... 7.4.1 Angriffsfläche verringern ............................ 7.4.2 Sicherheitslücken aufspüren ....................... 7.4.3 Kritische Rechte kontrollieren .................... Dokumentation der Absicherungsmaßnahmen ......... 7.5.1 Generelle Anforderungen ........................... 7.5.2 Das Sicherheitskonzept .............................. 7.5.3 Das Berechtigungskonzept ......................... 8.2 9 9.1 150 151 152 153 154 157 Härten des SAP NetWeaver AS Java ........................ 8.1.1 Zugriffe einschränken ................................ 8.1.2 Nicht benötigte Dienste deaktivieren ........ 8.1.3 Kommunikationssicherheit herstellen ........ 8.1.4 Passwort-Regeln festlegen ......................... 8.1.5 Java-Berechtigungen verstehen .................. Angriffe auf den AS Java und Gegenmaßnahmen ..... 192 192 195 197 202 205 206 Schutz von Remote Function Calls ......................... 209 149 9.2 9.3 9.4 9.5 9.6 9.7 Technische Komponenten der RFC-Verbindungen ................................................. RFC-Berechtigungen verstehen und einsetzen ......... Unified Connectivity: eine weitere Schutzebene ...... RFC-Sicherheit auf Client-Seite herstellen ............... RFC-Callback-Sicherheit aktivieren .......................... Den RFC-Gateway absichern ................................... Verschlüsselung aktivieren ...................................... 210 214 223 224 226 228 230 10 Passwortschutz ....................................................... 233 160 Schutz des SAP NetWeaver AS ABAP ..................... 163 7.1 7.2 7.3 10 8 Schutz von SAProuter und SAP Web Dispatcher ... 145 6.1 7 Gegenmaßnahmen zum Schutz der Datenbank ................................................. 143 Gegenmaßnahmen zum Schutz der Netzwerke ................................................. 143 163 164 168 168 170 179 179 182 184 187 188 189 189 10.1 Technologie und Logik von Hash-Prüfungen ........... 10.2 Technische Implementierung der Passwörter im SAP-System ............................................................ 10.3 Werkzeuge: John the Ripper und HashCat .............. 10.4 Wörterbücher beim Angriff ..................................... 10.5 Angriff auf die Passwörter (Hashes) ......................... 10.6 Gegenmaßnahmen: harte Passwörter, SSO und Hashes löschen ....................................................... 10.6.1 Schutz gegen Hash-Diebstahl .................... 10.6.2 Nutzung eines sicheren HashAlgorithmus .............................................. 10.6.3 Bereinigung alter Hash-Werte .................... 10.6.4 Passwort-Policy einführen ......................... 10.6.5 Single Sign-on statt lokale Passwörter nutzen ....................................................... 233 236 242 244 244 245 245 251 256 257 261 11 Inhalt Inhalt 11 Schutz des Transportsystems ................................. 263 11.1 Transport Management System ............................... 11.2 Angriffe auf das Transportsystem ............................. 11.2.1 Schutz vor Angriffen über das Dateisystem ............................................... 11.2.2 Schutz vor Angriffen mit speziellen Transportobjekten ...................................... 11.2.3 Schutz vor Angriffen über die Systembenutzer des TMS ...................................... 11.2.4 Transport von Schad-Code und Sicherheitslücken ....................................... 11.3 Gegenmaßnahme: Härtung des CTS mithilfe des SAP Solution Managers ........................................... 263 265 13.3 265 269 13.4 271 273 278 13.5 12 Schutz der Datenbank ............................................. 281 12.1 Die Rolle der Datenbank in SAP-Systemen .............. 12.2 Generelle Risiken und Absicherungsmaßnahmen ..... 12.2.1 Zugriff und Zugang ..................................... 12.2.2 Daten und Inhalte ...................................... 12.3 Funktionstrennung in einer Oracle-Datenbank ........ 12.4 Angriffe auf SAP-Datenbanken ................................ 12.4.1 SAP-Datenbankschnittstelle ....................... 12.4.2 Datenbankangriffe aus SAPAnwendungen ............................................ 12.4.3 Gegenmaßnahmen zum Schutz vor ABAP-basierten Angriffen ........................... 12.4.4 Ausspähen des SAP-Datenbankservers ....... 12.4.5 Direkte Angriffe auf Betriebssystemebene .................................. 12.4.6 Gegenmaßnahmen zum Schutz vor Angriffen auf Betriebssystemebene ............. 12.4.7 Beispiel: Datenbanksicherheit mit IBM Guardium ................................................... 281 283 283 288 290 293 293 295 297 298 301 303 304 13 SAP HANA und die Sicherheit der In-MemoryDatenbanken ........................................................... 309 13.1 Sicherheit in SAP HANA .......................................... 310 13.2 Architektur von SAP HANA ..................................... 312 12 13.6 13.2.1 Die Datenbankwelt aus der Sicht des Hauptspeichers .......................................... 13.2.2 In-Memory Column Stores ........................ Grundlagen der Sicherheitskonzepte für HANA ....... 13.3.1 Speicherorientierte Datenbank: Die SAP HANA XS Engine ....................................... 13.3.2 Benutzer- und Rollenmanagement ............. 13.3.3 Authentifizierung und Single Sign-on ......... Absicherung der Webanwendungen ....................... 13.4.1 Angriffsvektoren auf die neuen Werkzeuge ................................................ 13.4.2 Serverseitiges JavaScript ............................ 13.4.3 Maßnahmen zur Härtung von Webanwendungen .................................... Penetrationstest auf SAP-HANA-Applikationen ausführen ............................................................... Angriffe auf den Hauptspeicher ............................... 13.6.1 Risikoabschätzung zum Angriffsvektor Hauptspeicher ........................................... 13.6.2 Verschlüsselung bei SAP HANA ................. 13.6.3 Cloud und Verschlüsselung ........................ 312 313 315 316 316 317 318 320 320 322 323 324 325 326 327 14 Erkennung von Angriffsmustern und Forensik ....... 329 14.1 Die Quelle der Muster: die wichtigsten Log-Dateien ............................................................ 14.1.1 Vorbemerkung zur forensischen Analyse .... 14.1.2 Security Audit Log ..................................... 14.1.3 Systemlog .................................................. 14.1.4 Gateway-Logging ...................................... 14.1.5 Logging von Internet Communication Manager und SAP Web Dispatcher ............ 14.1.6 Logging des SAP NetWeaver Application Server Java ................................................ 14.1.7 Logging des Message Servers ..................... 14.1.8 Logging von Datenänderungen in Tabellen .................................................... 14.1.9 Logging von Änderungen an Benutzern und Berechtigungen .................................. 14.1.10 Logging von Änderungsbelegen ................. 14.1.11 Systemtrace ............................................... 330 331 332 334 335 336 338 339 339 341 341 342 13 Inhalt Inhalt 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.1.12 Entwickler-Trace ........................................ 14.1.13 Logging des SAProuter ............................... 14.1.14 Logging von Datenbankzugriffen (SQL Audit) ................................................ Auswertung mit Transaktion ST03 ........................... Auswertung mit Funktionsbausteinen ...................... Usage and Procedure Logging ................................. Netzwerkinformationen, Terminals und SAP-Benutzer-Sessions ............................................ 14.5.1 Snort .......................................................... 14.5.2 Onapsis Detection and Response ............... 14.5.3 IBM Guardium ........................................... Werkzeuge zur Auswertung der Muster: Security Information and Event Management ....................... 14.6.1 IBM Security QRadar SIEM und HP ArcSight ..................................................... 14.6.2 SAP Enterprise Threat Detection ................ 14.6.3 Splunk ........................................................ Sicherheitsmuster .................................................... Grundlegende Sicherheitsaktivitäten ........................ 343 345 346 346 347 349 351 351 353 354 354 355 355 356 357 358 16 Sicherheit im Internet der Dinge ............................ 383 16.1 Sicherheitsebenen des Internets der Dinge ............. 16.1.1 Hardware- und Softwareebene des Internets der Dinge ................................... 16.1.2 Ebene der Daten – Big Data ....................... 16.1.3 Ebene der Anwendungs- und Produktentwicklung .................................. 16.1.4 Ebene der Fertigung .................................. 16.1.5 Ebene des technischen Betriebs ................. 16.1.6 Ebene des Marketings für das Internet der Dinge .................................................. 16.2 SAP-Architektur für das Internet der Dinge ............. 16.3 Kryptografie im Internet der Dinge ......................... 16.3.1 Verschlüsselung auf ASIC und FPGA .......... 16.3.2 Das Spiel mit dem Zufall ............................ 16.4 Gefährdungspotenzial für das Internet der Dinge im SAP-Bereich ....................................................... 16.5 Angriffswerkzeuge für Hardware-Hacks ................... 16.6 Anatomie eines Hardware-Hacks ............................ 16.7 Anatomie eines Industrieanlagen-Hacks .................. 385 385 389 390 392 393 395 396 400 402 404 406 407 410 413 15 Mobile Anwendungen sichern ................................ 361 15.1 Netzwerkarchitektur für den mobilen Zugriff auf SAP-Systeme ........................................................... 15.2 Komponenten der Sicherheitsstrategie für die SAP-Mobile-Infrastruktur ........................................ 15.2.1 Sicherheit für mobile Geräte ....................... 15.2.2 Sicherheit für mobile Anwendungen .......... 15.2.3 Sicherheit für mobile Dokumente ............... 15.2.4 Enterprise Integration ................................ 15.3 Angriffe auf die mobile Landschaft ........................... 15.3.1 Wireless Access Point ................................. 15.3.2 Single Sign-on und Identity Access Management .............................................. 15.3.3 Gestohlene Cookies .................................... 15.3.4 SAP Web Dispatcher .................................. 15.3.5 SAP Gateway und SAP-Backend ................. 14 Die Autoren .............................................................................. 417 362 Index ........................................................................................ 419 366 367 367 370 370 378 378 380 381 381 381 15 Index A B ABAP Test Cockpit 93 ABAP-Laufzeitumgebung 163 Access-Control-Liste 229 ACL 229 Active Directory 363 ALE 209 Altera 386, 398 Amazon 28 Änderungsbeleg, Logging 341 Angriff Angreifer bestimmen 41 AS ABAP 164 Client Side 322 durch Systembenutzer 271 Hauptspeicher 310, 324 Java 206 Microsoft SQL 246 mit Transportobjekt 269 Oracle 246 SAP HANA 324 SAP Web Dispatcher 157 SAProuter 152 technische Auswirkungen 41 Transportsystem 265 Vulnerability 41 Angriffsvektor 39, 141, 394 Apache Cordova 367 apm atlantis 186 Application Layer 105 Application Link Enabling 209 Arbeitsmittel 123 Arbitrary Routing 346 Architektur, Angriffspunkte 82 Archiv 88 ArcSight 355 AS ABAP 씮 SAP NetWeaver AS ABAP AS Java 191 ASIC 387 ATC 93 Audit 187 Audit Logging 318 Authentifizierung 364 Backdoor 328, 402 BAPI 209 Baseline 65 BCODE 237 BEAST 199 Bedrohung klassifizieren 32 Bedrohungsanalyse 25 Behavioural Firewall 328 Behavioural Pattern 89 Benutzerverwaltung, zentrale 252 Berechtigung 364 AS Java 205 fehlende 174 Konzept 189 kritische 184, 186 S_RFC 215 Tabellenzugriff 250 Trace 342 verwalten 168 Bilanzrelevanz 35 Bizsploit 136 Black-Box-Test 63 Bluetooth-Sniffer 410 brconnect 285 Browser Exploit against SSL/TLS 199 Brücke 381 BSI 33, 48 Building Block 383 Bundesamt für Sicherheit in der Informationstechnik 33 Bundestag 39 Business Application Programming Interface 209 C Campus-Netzwerk 115 CDPI 120 CERT 73 Chief Information Officer 53 Chief Information Security Officer 53 Chip 387 CIO 53 Ciphertext 401 419 Index Index CISO 53 CLEANUP_PASSWORD_HASH_ VALUES 256 Client schützen 193 Cloud 327 Code Vulnerability Analysis 씮 SAP Code Vulnerability Analysis Code, dynamischer 92 Code-Analyse 276 CodeProfiler 277 Code-Scanner 277 Command Rule 292 Common Vulnerability Scoring System 44, 83 Config Tool 193 Content-Filter 109 Control Plane 118, 119 Control to Data Plane Interface 120 Cookie 364, 381 Cookie Stealing 207 Cordova 367 Cross-Site Request Forgery 321 Cross-Site Scripting 207, 321 CSS 320, 368 CSS3 320, 368 CUDAhashcat 243 Custom Code Lifecycle Management 98 CVA 씮 SAP Code Vulnerability Analysis CVSS Base Vector 44, 83 Cyber Control Center 60, 73 Team 74 Telekom 68 Cyber Defense Center 74 Cyber Emergency Response Team 73 Cyber Resilience 26 Cyber Security 55 Cyberspace 26 D Data Breach 291 Data Lake 330 Data Link Layer 103 Data Plane 120 Data Volume Security 318 Datenanonymisierung 88 Datenbank 281 Angriff 142 420 Datenbank (Forts.) Benutzer 283, 285 Berechtigungen 291 Datendiebstahl 288 Direktzugriff 291 Kopie 288 Managementsystem 281 Schicht 281 schützen 143 transparente Verschlüsselung 289 Zugang 283 Datenpunkt 393 Datenschutz 35, 37 DBA Cockpit 298 DBCON 117 DBMS 281 DDIC 272 Debugging mit Replace 166 Demilitarisierte Zone 씮 DMZ Detection and Response 353 DIAG 81, 105, 112 Dienst deaktivieren 195 Dienstleister 59 DMZ 111, 154, 363, 364 Dokumentation 187 Dokumentation, Anforderungen 188 Dreischichtenarchitektur 362 Dynamic Information and Action Gateway Protocol 씮 DIAG E Enterprise Integration 370 Entropie-Pool 405 Entwickler-Trace 338 ERPScan 137 ESNC 137 ESP 씮 SAP Event Stream Processor ETD 씮 SAP Enterprise Threat Detection Exploit 84, 134 F Factor 292 False Positive 354, 355 FIDO 375 Firewall 107, 138, 208, 362 Forensik 330 Forwarding Engine 121 Foundry 388 FPGA 386 Funktionstrennung 274 Fuzzing 337 G Geheimnis 411 Google Exploit 127 Grey-Box-Test 63 H HackRF One 408 hak5 409 Hardwarebaustein, Verschlüsselung 402 Hardware-Hack 407, 410 Härtung 138 Hash Algorithmus 234 Code-Version 236 Diebstahl vermeiden 245 entschlüsseln 235 Prüfung 233 sicherer Algorithmus 251 Wert 233 Wert bereinigen 256 Wörterbuch 244 Hash Table 313 HashCat 243 Hauptspeicher Angriff 310, 324 Risikoanalyse 325 schützen 328 Hex-Editor 289 Honeypot 132 Hop 149 HP ArcSight 355 HTML5 320, 368 HTTP Fuzzing 337 HTTP Log 338 I IAM 363, 372 IBM Guardium 304, 354 IBM Security QRadar SIEM 355 ICM 336 Identity and Access Management 363, 372 Incident Management 59 Industrie 4.0 55, 396 Industrieanlagen-Hack 413 Industriesteuerung 71 Information Gathering 127, 128, 146 In-Memory-Datenbank 309 Intel Atom 398 Intel IoT Gateway 386, 397 Intellectual Property 387 internationale Norm 33 Internet Communication Manager 336 Internet der Dinge 383, 385 Architektur 396 Hardware 387 Kryptografie 400 Internet of Things 씮 Internet der Dinge Intrusion Detection System 208 Intrusion Prevention System 208 IoT 씮 Internet der Dinge IP 387 IPS 208 ISO 27001 187 ISO/OSI-Referenzmodell 102 J Java User Management Engine 202 JavaScript 320, 369 Java-Server-Log 338 Java-Sicherheitsrolle 205 Jeep-Hack 384 John the Ripper 243 Jurisdiktion 35, 37 K Kali Linux 123, 125 Kapsel 368 Key Logger 380 Kiss of Death 158, 208 Known Vulnerabilities 208 Kommandozeile 267 Kommunikation sichern 197 421 Index Index KRITIS 49 Kryptografie 401 Geheimnis 411 mobile Anwendungen 374 L LDAP 199, 363 Linux 123, 399 Log 153, 330 Log Learner 90 Log-Datei 90, 330 Logical Unit of Work 164 LUW 164 Netzwerk Analyse 129 Ebenen 103 Erkennung 129 Netzwerkverkehr verschlüsseln 114, 230 Protokoll 198 Scan 130 schützen 143 Sicherheit 101, 138 Tunnel 201 vertrauenswürdiges 376 Next-Generation-Firewall 365 NFC 374 NIST 46 Nmap 129, 300 M Machine Learning 356 Maltego 128 Man in the Middle 157, 199 McAfee Embedded Control 399 MDM 367 Memory Attack 324 Message Server, Logging 339 Metasploit 133, 320 Microsoft SQL Server, transparente Verschlüsselung 290 Mikroprozessor 387 Mobile 361 mobile Anwendungen Datensicherheit 373 Kryptografie 374 Mobile Application Management 367 Mobile Device Management 367 Mobile-Architektur 361, 370 Mobile-Endknoten 372 mobiles Gerät 366 N Nachricht, Verschlüsselung 401 National Institute of Standards and Technology 46 Native Routing 345 Native SQL 295 Near Field Communication 374 Need-to-know-Prinzip 168, 178 Network Layer 103, 104 422 O Objektprivileg 291 oclHashcat 243 ODBC 117 Onapsis 353 Onapsis OSP 136 Onapsis Security Platform 353 Open SQL 294, 346 OPS$-Mechanismus 285 Oracle 142 Passwortregeln 284 Verschlüsselung 289 Oracle Listener 287 Organisation, interne 58 Oszilloskop 412 OWASP 44 P Padding Oracle on Downgraded Legacy Encryption 199 Paketfilter 108 PASSCODE 238 Passwort Angriff 244 im Altsystem sichern 252 Policy einführen 257 Prüffunktion 284 SAP-Implementierung 236 schützen 202, 233, 245 Tabelle schützen 246 Patch 138 Patch Management 139 Payload 301 Peer Review 404 Penetrationstest 60, 61 Abschlussgespräch 65 Dokumentation 65 SAP HANA 323 Varianten 63 Vorbereitung 62 Personalisierung 404 Phishing 63 PhoneGap 367 Physical Layer 103 Pineapple 378, 409 Pivoting 167 Policy 107 POODLE 199 Port Mirroring 353 Port Monitoring 353 Presentation Layer 105 PRNG 405 Protokoll verschlüsseln 198 Proxyfilter 108 PWDSALTEDHASH 238, 253 Q QRadar 355 Qualitätssicherung 275 RFC (Forts.) Client 115, 224 Funktionsbaustein 215, 219 Gateway sichern 228 schützen 209 technische Komponenten 210 Trusted 211 Verschlüsselung 230 RFC-Gateway 115 RF-Hack 408 Risiko Analyse 25, 33 darstellen 38 Faktor 34 formalisierte Betrachtung 30, 43 Formel 30 identifizieren 34 Informationen bewerten 31 Klassifikation 36 Matrix 31 Rolle, Beschreibung 190 Route String 151 Route-Permission-Tabelle 149, 152, 154 RPC 81 RSA-Schlüssel-Generator 375 RTFM 126 Rule Set 292 RZ11 332 S R Radio Frequency 408 Rauschen 405 Realm 292 Reconnaissance 298 Remote Function Call 씮 RFC Remote Procedure Call 81, 105 Replay 412 REPOSRC 302 Reputation 35 Reverse Engineering 326, 412 RFC 81, 105, 115, 141 ACL 229 Baustein 142 Berechtigung ermitteln 217 Berechtigung prüfen 214 Callback 226 Safe Harbour 390 Salt 235 SAML 317 SAP Afaria 367 SAP Attack Vectors 29 SAP Business Suite 372 SAP Code Inspector 277, 359 SAP Code Vulnerability Analysis 86, 91, 92, 297 SAP Cryptographic Library 107 SAP EarlyWatch Session 97 SAP Enterprise Threat Detection 86, 355 Architektur 87 Lernmodus 90 SAP Event Stream Processor 87, 397 SAP Fiori 320, 369 423 Index Index SAP Gateway 372 SAP GUI 80 SAP GUI, Hack 111 SAP HANA Angriff 324 Architektur 312 Authentifizierung 317 Column Store 313 in der Cloud 327 Internet der Dinge 396 Penetrationstest 323 Persistenz 315 Sicherheit 309 Verschlüsselung 326 SAP HANA Cloud Platform 396 SAP HANA Studio 319 SAP HANA XS 88, 316, 320 SAP Java Virtual Machine 191 SAP Logon Ticket 317, 364, 381 SAP Mobile Document Management 370 SAP Mobile Platform 367, 368 SAP NetWeaver 84 SAP NetWeaver Administrator 193 SAP NetWeaver AS ABAP 163 absichern 179 Rechte prüfen 184 schützen 163 Sicherheitslücken finden 182 SAP NetWeaver AS Java 191 SAP Patch Day 83 SAP Solution Manager 97, 139 Angriffsziel 168 Usage and Procedure Logging 351 SAP SQL Anywhere 397 SAP Web Dispatcher 376, 381 Angriff 157 Funktionen 154, 156 härten 160 Logging 336 SAPCAR 148 SAProuter Angriff 152 Einsatzgebiet 146 härten 153 im Netzwerk 145 Kaskadierung 154 Logging 153 SAP-Sicherheitshinweis 83 SAPSSO2 364, 381 424 SAPUI5 322 Sarbanes-Oxley Act 35 SCADA 392, 413 SDN 117 SDR 408 Secure Keystore 374 Secure Network Communication 씮 SNC Secure Storage in File System 286 Security Assertion Markup Language 317 Security Audit Log 332 Security Baseline Template 189 Security Event 329, 354 Security Log 337 Security Operations Center 74 Security Optimization SelfService 183 Security Optimization Service 183 Security Self-Service 98 SELECT-Statement 346 Sensor 386 Server Analyse 133 Erkennung 133 Session Layer 105 Shell-Administrator 194 shodan.io 126 Sicherheit 79 Bereich 323 Konzept 189 Maßnahmen dokumentieren 187 Organisation 59 politische Dimension 56 Rolle 59 SAP Solution Manager 97 Software 75 Veränderungen 56 Sicherheitsstrategie Bewertung 55 entwickeln 53 Fallbeispiele 67 Kosten 65 Nutzen 65 Ziele 57 Sicherheitsvorfall 332, 354 SIEM 42, 119, 354 Single Sign-on 261, 376 SM20 333 SM21 335 SMICM 337 SMMS 339 SNC 106, 230 SNC Client Encryption 114 Sniff 106, 381 Snort 351 SoC 385 Social Hacking 394 SOC-Manager 74 Software-Defined Network 117 Software-Defined Radio 408 SOX 35 SPAN 353 Splunk 356 SPWD 249 SQL Audit 346 SQL Injection 94, 273, 277, 296 SQL*Plus 291 SSFS 286 SSL 198, 317 SSO 261, 376 ST01 342 ST04N 298 ST11 344 Stateful Inspection 108 Status quo Dokumentation 57 feststellen 60 STMS 340 strings 289 stunnel 201 Stuxnet 326, 413 S-User 148 Switch 118 Switched Port Analyzer 353 SWNC_STATREC_READ 347 System Landscape Directory 191 System on a Chip 385 System Profiler 137 System Recommendations 139 Systemlog 334 Systemprivileg 291 Systemtrace 342 Systemumgebung 36 Tabelle (Forts.) Protokollierung 339 REPOSRC 302 USR02 301 Tablespace, Verschlüsselung 289 Tap 103, 305 TDE 289 Tier 107, 363 TMS 263 Tokenized Event 333 Topologie 107 Transaktion ATC 93 DBACOCKPIT 298 RSRFCCHK 213 RZ11 332 SCU3 340 SM20 333 SM21 335 SMICM 337 SMMS 339 sperren 181 ST01 342 ST11 344 STAUTHTRACE 218 STMS 340 SU24 221 UCONCOCKPIT 223 Transistor 405 Transparent Data Encryption 289 Transport Domäne 264 Layer 104 Schad-Code 273 sichern 265 Verzeichnis 265 Weg 264 Transport Management System 씮 TMS Transportsystem Angriff 265 schützen 263 TRNG 405 Trojaner 413 T Tabelle /SDF/UPL_LOG 350 DBTABLOG 340 425 Index U Ubertooth 394, 410 Übungszentrum Netzverteidigung 67, 68 UCON 223 UCON Cockpit 223 UME-Rolle 206 Unified Connectivity Framework 223 UPL 349 URL-Filtering 156 Usage and Procedure Logging 349 USB/UART-Adapter 412 User Interface 368 USR02 301 Wearable 394 Web Client 193 Webanwendung, sichern 318, 322 Werkzeug 123, 125 Werth IT Auditor 137 White-Box-Test 64 Wind River 399 Wireless Access Point 372, 378 X X1 136 .xsaccess 323 XSJS 319, 320 XSRF 321 XSS 207, 321 V Verb Tampering 338 Verschlüsselung 106, 400 Verschlüsselung, transparente 289 Virtual Forge Code Profiler 297 Visual Administrator 193 VMware 122 W WAP 372 Waterhole 63 426 Z ZenMap 129 zentrale Benutzerverwaltung 252 Zero-Day-Exploit 32, 84 Zertifikat 362, 380 Zielanalyse 126 Zufallszahl 47, 404 Zugriff begrenzen 192 Zwei-Faktor-Authentifizierung 375 ZYBO-Board 400 Wissen aus erster Hand. Holger Stumm ist Gründer und Geschäftsführer von log(2), einem auf SAP-Sicherheit spezialisierten Beratungsunternehmen. Für seine Kunden entwickelt er strategische Sicherheitskonzepte, analysiert die Systeme in Hinblick auf deren Sicherheit und erstellt Risikoanalysen, u.a. mit Hilfe von Penetrationstests. Holger Stumm ist seit 2014 zertifizierter Partner der Allianz für Cyber-Sicherheit des Bundesamts für Sicherheit in der Informationstechnik. Daniel Berlin ist Security-Spezialist mit langjähriger Erfahrung und arbeitet in einer internationalen Bankengruppe. Er führt Analysen im Bereich SAP-Sicherheit durch und bewertet Bedrohungsszenarien. Daniel Berlin hat mehrere SAP-Sicherheitszertifizierungen abgeschlossen und erstellt regelmäßig Konzepte zu SAP-Berechtigungen. Seine Erfahrungen in der Programmierung erlauben es ihm, auch technische Aspekte der Systemsicherheit zu analysieren und zu bewerten. Holger Stumm, Daniel Berlin SAP-Systeme schützen 426 Seiten, gebunden, Februar 2016 69,90 Euro, ISBN 978-3-8362-3851-9 www.sap-press.de/3907 Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag. Teilen Sie Ihre Leseerfahrung mit uns!
