Anforderungen ans Security Information and Event Management, Teil 2 Sicherheitsüberwachung auch auf Applikationsebene

Bedrohungen adressieren längst nicht mehr nur die Betriebssystemebene mit Diensten wie FTP, Telnet und E-Mail. Weil immer mehr Attacken auf der Anwendungsebene ablaufen, fordern Firmen vermehrt eine Applikationsüberwachung durchs Security Information and Event Management (SIEM).

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

(ISC)2 Inc.

Während das Security Information and Event Management (SIEM) beim Netzwerk-Monitoring gute Arbeit leistet, bleiben Anwendungen häufig noch unkontrolliert. Dies gilt vor allem für Webportale, Warenwirtschaftsprogramme, Personendatenverarbeitungs- oder Transaktionssysteme, die aus dem Internet zu erreichen sind.

Vor allem Banken weisen eindringlich darauf hin, dass sie eine Applikationsüberwachung im SIEM benötigen. So berichtete die FAZ bereits Mitte September 2009 über einen Bankangestellten namens Kweku Adoboli, der in London von der Polizei festgenommen worden war. Der 31-Jährige hatte seinerzeit Risikogeschäfte getätigt und die Verluste über fiktive Buchungen verschleiert.

„Von den Risikokontrollen der Investmentbank UBS unentdeckt war der junge Händler Spekulationsgeschäfte in Milliardenhöhe eingegangen“, schrieb die FAZ seinerzeit. „Die Londoner Finanzaufsicht, die Financial Services Authority (FSA), und die schweizerische Aufsicht untersuchen, warum der Händler den Verlust anhäufen konnte und die Risikosysteme der Bank nicht früher Alarm schlugen.“

Applikationskontrolle – leichter gesagt als getan

Offensichtlich können Investmentbänker unkontrolliert kriminelle Geschäfte machen, Unternehmen mit Milliarden Verlusten ruinieren, Arbeitsplätze gefährden und sogar Länder wie die Schweiz in enorme Schwierigkeiten bringen. Solche Sicherheitsrisiken müssen unbedingt auf Applikationsebene erkannt und verhindert werden.

Vermutlich hat die UBS deshalb SIEM- Spezialisten gesucht. Doch den Missbrauch von Anwendungsprogrammen oder Datenbanken zu erkennen, ist eine extrem komplexe Aufgabe. Jedes System funktioniert in seiner Logik grundsätzlich verschieden.

Das Benutzerverhalten wird – wenn überhaupt – programmabhängig in ganz verschiedenen Formaten aufgezeichnet, wie das fiktive Beispiel auf der folgenden Seite erläutert.

Probleme bei der Überwachung von Anwendungen

Gehen wir von folgendem Fall aus: Mithilfe eines Transaktionssystems nimmt ein Investmenthändler Buchungen an der Böse vor. Im weiteren Verlauf wird hier von einem Anwendungsprogramm und einer Datenbank gesprochen. Er hat Gleitzeit und kann sich deshalb jederzeit an dem Programm anmelden und abmelden.

Samstags, Sonntags und Feiertags wird in der Regel nicht gearbeitet. Vom Personal gesteuerte Transaktionen während den arbeitsfreien Zeiträumen wären verdächtig und könnten entsprechend alarmiert werden. Automatisch gesteuerte Transaktionen laufen aber meistens während den arbeitsfreien Zeiten.

Vor diesem Hintergrund müssten das Anwendungsprogramm und auch die Datenbank die automatischen und benutzergesteuerten Transaktionen in ihren Logdaten für das Monitoring unterschiedlich kennzeichnen. Das ist besonders in der Datenbank nicht immer der Fall. Der Zusammenhang zwischen den Aufzeichnungsdaten des Programms und denen der Datenbank muss außerdem nachvollziehbar sein.

Das Anwendungsprogramm und die Datenbank protokolliert im Idealfall die An- und Abmeldevorgänge (aber auch erfolglose Versuche) der Benutzer mit der genauen Uhrzeit und dem Benutzernahmen. Zusätzlich müssen alle Ausführungen und Transaktionen auch durch die Datenbank erfasst werden.

Die hierdurch erzeugte Datenmenge der Aufzeichnungen kann sehr groß werden, so dass diese die IT-Systeme mit ihrer Hardware an ihre Leistungsgrenzen bringen. Es ist dabei zu bedenken, dass sich nicht nur die Benutzer, sondern dass sich auch automatisch ausgeführte Programme unter Umständen mit jedem einzelnen SQL-Aufruf an der Datenbank anmelden.

Technische Herausforderungen

Das Speichervermögen der Festplatten, sowie die Prozessoren müssen bezüglich der Leistungsfähigkeit für das Monitoring besonders angepasst werden. Sonst wird das Anwendungsprogramm unbrauchbar langsam.

Die Protokolle müssen vom SIEM lesbar und auswertbar sein. Das SIEM wird jede einzelne Zeile in einzelne Begriffe zerlegen müssen. Wenn das Anwendungsprogramm für ein einzelnes Ereignis mehrere Zeilen schreibt, weiß der Parser des SIEM nicht, in welcher Zeile die Ereignisbeschreibung beginnt und mit welcher es endet.

Mit solchen Protokolldaten kann es Probleme geben: Anwendungsprogramme und Datenbanksysteme und SIEM sind oft nicht aufeinander abgestimmt. Individuelle Anpassungen sind u.U. machbar aber dann auch sehr teuer. Zusätzlich muss das Benutzerverhalten in der Event-Datenbank gespeichert werden. Analysten sollten dazu in der Lage sein, im SIEM durch selbst geschriebene Regeln falsches von normalen Verhalten unterscheiden.

Diese Regeln werden von den Hersteller nicht mit dem Produkt, also „out of the box“ mitgeliefert, sondern müssen individuell von Analysten eng in Zusammenarbeit mit Bankfachleuten erarbeitet werden. Geeignete Lösungen können grundsätzlich nur in einem längeren und gemeinsamen Lernprozess entwickelt werden.

Sind erst einmal geeignete Regeln implementiert, ist aber nicht garantiert, dass sich interne Mitarbeiter, getrieben durch kriminelle Energie, absichtlich durch ihr Verhalten dieser Kontrollfunktion entziehen. Die Regeln sind eben nur so gut, wie die Fantasie der Analysten und der Bankfachleute, die sie geschrieben haben. Das hat zur Folge, dass die Regeln im SIEM immer wieder überarbeitet und verbessert werden müssen.

Rechtliche Schwierigkeiten der IT-Forensik

Selbst wenn eine technische Lösung in Sicht ist, so kann alles noch vor dem Gericht scheitern. Die gesammelten Daten müssen „echt“ sein und als Beweismittel vor Gericht standhalten. Es darf kein Verdacht aufkommen, dass diese Ereignisdaten nachträglich manipuliert worden sind.

Um eine wirksame Kontrolle zu erreichen, müssen wie bereits erwähnt auch die personenbezogenen Daten protokolliert werden. Hier spielt das Betriebsverfassungs- und das Datenschutzgesetz eine wesentliche Rolle. Das Verfahren muss mit dem Betriebsrat abgestimmt sein. Das Aufbewahrungsverfahren muss gemäß den Datenschutzrichtlinien erfolgen.

Nachdem alle technischen und rechtlichen Herausforderungen gelöst sind, müssen geeignete Prozesse, die das Incident Handling beschreiben, entwickelt werden. Verdächtige Personen dürfen von der Ermittlung keine Kenntnisse erhalten. Das Personal muss fachlich und organisatorisch in der Lage sein, den Fall sicher aufzuklären.

Hier sind noch einmal die Hauptprobleme und Lösungsansätze zusammengefasst:

• Anwendungsprogramme und Datenbanken müssen geeignete Ereignisdaten liefern können. Benutzernamen müssen den Transaktionen zugeordnet werden können.

• Die Hardware müsste unter Umständen neu angepasst werden, weil das Transaktionslogging aktiviert wird. Es wird empfohlen, vor der Aktivierung im Livebetrieb ein Lasttest durchzuführen.

• Das Datenschutzgesetz und Betriebsverfassungsgesetz ist absolut wichtig aber bei einer Applikationsüberwachung ein Problem. Es wird empfohlen den Datenschutzbeauftragten und den Betriebsrat zu beteiligen.

• Wie in klassischen Security-Incident-Prozessen ist das Risiko sehr groß, dass Verursacher während des Ermittlungsverfahrens Kenntnisse erhalten und den Fall vertuschen. Deshalb wird in der Entwicklung des Prozesses und in der Auswahl des Sicherheitspersonals sehr viel Sorgfalt geboten.

• Vor Gericht werden nur die Beweismittel zugelassen, die im Originalzustand sind und nicht manipuliert werden können. Deshalb ist besondere Sorgfalt bei der Speicherung der Aufzeichnungsdaten geboten.

Über den Autor:Udo Sprotte ist (ISC)²-zertifizierter CISSP und Senior Security Consultant.

(ID:38047810)