Thought Leadership
Wie genau funktionieren eigentlich Bedrohungserkennung und Schwachstellen-Analyse? Warum die Synergie beider Methoden eine reduzierte Reaktionszeit bei unerwünschten Ereignissen und gleichzeitig eine optimierte Gefahrenerkennung ermöglicht, erklärt Ralf Kempf, CTO von Pathlock Deutschland, am Beispiel eines IT-Hauses.
Wie sie jeweils funktionieren und wie die zielgerichtete Verbindung aus Threat Detection und Vulnerability Management zu einer deutlichen Verbesserung der SAP-Sicherheit führt, lässt sich gut am Beispiel eines klassischen IT-Bürogebäudes veranschaulichen. Denn Schwachstellen zuverlässig zu identifizieren und Bedrohungen in Echtzeit zu erkennen, ist oftmals der entscheidende Faktor für die Systemsicherheit, sei es ein Gebäude oder SAP.
Vulnerability Management
Beim Schwachstellen- oder Vulnerability Management geht es darum, Systeme anhand der Momentaufnahme an einem bestimmten Stichtag zu untersuchen und sie hinsichtlich Zugangsschutz, Verfügbarkeit, Konsistenz und Wiederherstellbarkeit der Daten in einen sicheren Betrieb zu bringen. Kommen wir zu unserem Beispiel eines Bürogebäudes: Es gibt zunächst die Perimeter-Sicherheit. Diese beginnt bei der Zufahrt zum Gelände – hier muss man vielleicht schon mal einen PIN-Code eingeben, um in die Tiefgarage zu kommen. Mit dem Zugang über die Tiefgarage erfolgt die Kanalisierung des Traffics der Mitarbeiter. Im Eingangsbereich ist eine Tür, für die man eine Keycard benötigt. Als Gast muss man sich beim Pförtner anmelden. Ansonsten sind alle Türen optimalerweise abgeschlossen, man möchte also ganz generell unautorisierten Zugang verhindern, und Ähnliches tut man bei IT-Systemen.
Zumindest die letzten zehn Jahre war eine IT meist in einem Gebäude konzentriert: Das Rechenzentrum war im Keller, ich konnte das kontrollieren, war Herr meiner Daten, hatte eine Firewall und konnte ziemlich genau überblicken, wer reinkommt. Ich hatte zudem gut überwachte Wartungszugänge oder einen Citrix-Terminal. Solch ein IT-Haus zu betreiben ist an sich schon hochkomplex, weil es viele Zuständigkeiten gibt: den Sicherheitsdienst, den Hausmeister, die Gebäudetechnik. Ganz ähnlich ist es bei der IT: Netzwerk Management, Access Control, SAP-Basis und IT-Basis. Und genau das ist Vulnerability-Management: Wir stellen eine Liste auf – und dankenswerterweise gibt es gerade von der SAP hervorragende Vorgaben, wie man deren Systeme sichert und überwacht.
Auf dieser Liste muss man Punkt für Punkt durchgehen und sie genau wie bei einer Gebäude-Leittechnik abhaken: Sind unnötige Türen stets abgeschlossen oder ist während der Mittagspause ein Hintereingang offen, der unbemerkten Zutritt erlaubt? Vulnerability Management versucht also immer, das Mindestmaß der Stabilität, Verfügbarkeit und Erreichbarkeit zu gewährleisten. Und das nicht nur einmal, sondern wie bei einem Gebäude: Der Hausmeister macht seinen täglichen Kontrollgang und jede Nacht prüft der Schließdienst alle Türen.
Threat Detection
Begeben wir uns nun in das Gebäude: Es sind Leute im Meetingraum, andere wie üblich an ihren Arbeitsplätzen, manche unterwegs oder im Dialog auf dem Flur, also der ganz normale Büroalltag. Jetzt ist es 12:30 Uhr und wir wissen eigentlich, was in einem Unternehmen zur Mittagspause passiert: Die Leute verlassen ihre Büros und gehen in Richtung Kantine. Das heißt, wir haben hier eine ganz normale standardisierte Bewegung der Mitarbeiter.
Was wir jetzt bei der Threat Detection machen, ist vor allem, auftretende Anomalien zu entdecken, also User Behavioral Analysis zu betreiben, indem wir beobachten: Bewegt sich jemand auffällig anders im Gebäude? Wenn wir jetzt einen Eindringling haben, der mit einer gefälschten ID hinein und am Empfang vorbeigekommen ist: Sein Ziel wird jetzt eben nicht die Kantine sein, sondern er bewegt sich in genau die entgegengesetzte Richtung und durchsucht Büros, ob irgendwo ein nicht gesperrter Rechner zu finden ist. Er verhält sich ganz anders als alle anderen Mitarbeiter, zu diesem Zeitpunkt und auch generell, weil er schnell nacheinander in Raum 3, 4 und 5 schaut.
Hier müssten dann sozusagen die Alarmglocken läuten, wenn ein Benutzer plötzlich anfängt, sich jenseits üblichen Verhaltens zu bewegen. Das Auffällige können zum Beispiel andere Downloads oder andere Mengen davon sein. Oder es sind ungewöhnliche Geolocations, von denen aus sich dieser Mitarbeiter anmeldet. Oder es werden bestimmte Transaktionen in den SAP-Systemen zu sonderbaren Zeiten ausgeführt. All das ist dann eine Anomaly Detection, die sonderbares Verhalten feststellt und den ersten Alarm der Threat Detection triggert.
Schwachstellen zuverlässig zu identifizieren und Bedrohungen in Echtzeit zu erkennen, ist oftmals der entscheidende Faktor für die Systemsicherheit.
Ralf Kempf, CTO, Pathlock Deutschland
Wenn wir nun auf unseren Eindringling zurückkommen, kann es natürlich sein, dass er einen nicht gesperrten Rechner findet oder über eine Schnittstelle in das System gelangt und anfängt, Konfigurationsänderungen zu machen oder sich bestimmte Belege anzuschauen, zum Beispiel HR- und Kontodaten. Das heißt, hier passiert etwas im System, indem er nur die Transaktion aufruft und mit den Augen oder einer Kamera die Informationen stiehlt. Er könnte aber auch anfangen, sicherheitsrelevante Parameter im SAP-System zu verändern, Businessbelege, Mengen einer Bestellung, Steuerinformationen oder gesamte Aufträge im SAP-System manipulieren. Es gehört dann zur Threat Detection, in beiden Fällen ein solches Verhalten innerhalb des SAP-Systems festzustellen, unabhängig davon, ob eine richtige ID benutzt wurde oder von wo er reingekommen ist. Dies darf keine Rolle spielen, denn der Perimeter hat ihn nicht entdeckt, am Vulnerability Management ist er damit vorbeigekommen.
Hier stellt sich die Frage, wie erkenne ich dann Anomalien wie abweichendes Benutzerverhalten und wie kann ich es über einen längeren Zeitraum monitoren? Denn die unterschiedlichen Schritte eines Hacks geschehen meist über einen längeren Zeitraum. Sie sind dann zusammenzutragen und miteinander zu korrelieren, um sagen zu können: Im Change Documents Log habe ich dieses Ungewöhnliche gesehen, im Security Audit Log und im User Change Log jenes. Alles zusammengefasst kann ich dann feststellen, dies ist eine faktische Hacking-Attacke.
Das Beste aus zwei Welten
Also ist das, was wir im Vulnerability Management machen, vom Prinzip her erst mal die Grundlage, um später eine effektive Threat Detection umsetzen zu können, da man sonst den Wald vor lauter Bäumen nicht sieht. Anders gesagt: Was nützt ein Tool, das akribisch dokumentiert, dass jemand durch eine Tür rein und raus geht, wenn ich weder weiß, wer das ist, noch ob er diesen Raum betreten darf. Entscheidender Punkt ist, dass Kunden sich dem Vulnerability Management und der Integration von Threat Detection intensiv widmen. Wenn eine Tür offen ist, jemand eine Keycard kopiert oder die Kamera aus ist, muss ich Hinweise bekommen, und zwar zeitnah. Kein Hexenwerk, aber die Teams müssen sich abstimmen und praxisorientierte Szenarien abbilden. Prozesse müssen festgelegt sein und ihre Schnittmenge technisch so befüllt werden, dass die Daten fließen. Und hier ist es entscheidend, einen Prozess zu haben, wie man damit umgeht, wenn man eine Schwachstelle beheben will oder eine Bedrohung erkennt. Und auch, dass die Rückkopplung funktioniert, denn am Anfang steht ja häufig zunächst eine Vermutung: Wer sich entgegen dem Mitarbeiterstrom zur Kantine durch mehrere Büros bewegt, ist vielleicht auch nur der Hausmeister, der gerade Fenster wartet.
