Angriffe auf Softwaresysteme können nicht ohne Weiteres erkannt werden, wenn kein entsprechendes Logging und Monitoring integriert ist. Mit Logging ist jedoch nicht das obligatorische Logfile gemeint, das die allermeisten Anwendungen ohnehin besitzen. Dieses beinhaltet üblicherweise Logausgaben der Business-Logik sowie Debugging-Informationen. Für die Suche sicherheitskritischer Aspekte ist dieses Logfile aus mehreren Gründen nicht besonders hilfreich.
Dieses Logfile hat meist keine besonders lange Lebensdauer. Üblicherweise wird es im Betrieb der Anwendung so eingestellt, dass es sich nach drei bis zehn Tagen überschreibt, damit nicht zu viel Speicherplatz verbraucht wird. Wenn ein Einbruch geschehen ist und analysiert werden muss, wird für die forensische Analyse allerdings Zugriff auf Logeinträge benötigt, die auch Monate und Jahre zurückliegen. Statistisch gesehen werden Einbrüche in Systeme erst nach drei bis sieben Monaten erkannt. Zu diesem Zeitpunkt sind die normalen Logfiles längst überschrieben worden.
Zudem beinhalten normale Logfiles zu viel Grundrauschen durch oft wenig informative Ausgaben, die bei der forensischen Analyse nicht helfen.
Deshalb bedarf es separater Logfiles für sicherheitsrelevante Ereignisse, die anders behandelt werden müssen als die normalen Logfiles. Wir nennen sie deshalb zur besseren Unterscheidung Security-Logs.
Foto: welcomia - shutterstock.com
Unternehmen wissen nicht, dass sie angegriffen werden
Anwendungen ohne Security-Logs besitzen unzureichende Protokollierung und Überwachung, was meist zu fehlender Reaktion auf Vorfälle oder Angriffe führt. Ein Angriff passiert daher meist unbemerkt, sodass ein Angreifer ungestört die Anwendung analysieren und Schwachstellen in aller Ruhe ausnutzen kann.
Wird eine Anwendung attackiert, wollen die Aggressoren zunächst die Persistenz aufrechtzuerhalten. Das bedeutet, eine Schwachstelle so zu manipulieren, dass sie dauerhaft und langfristig ausgenutzt werden kann. Eine solche Hintertür in ein System kann dann über Monate hinweg verwendet werden, oft ohne auch nur einen Verdacht des Missbrauchs auszulösen.
Im zweiten Schritt wollen sich die Angreifer von diesem einen gekaperten System im Netz der Anwendung ausbreiten, um weitere Systeme zu steuern. Ziel dabei ist es, über die Erweiterung der Angriffsinfrastruktur mehr Kontrolle über die Anwendung zu erlangen und so das eigentliche Ziel optimal erreichen zu können: die Manipulation, den Diebstahl oder die Zerstörung interessanter Daten - je nach Motiv oder Auftrag des Angreifers.
Die Auswirkungen dieser Schwachstelle lassen sich wie folgt beschreiben: Bei unzureichendem Logging und Monitoring in einer Anwendung werden Bedrohungen und Angriffe nicht erkannt, sowie das tiefere Eindringen und die Infiltration durch Angreifer gefördert. Wird nicht entdeckt, dass ein Angriff stattfindet, dann kann auch nicht darauf reagiert werden. Ein Angreifer wird sich deshalb in den Systemen ausbreiten und auch seine Spuren verwischen können.
Die Auswirkungen von unzureichendem Logging und Monitoring lassen sich wie folgt zusammenfassen:
Ereignisse wie Logins, fehlgeschlagene Authentifizierungen und kritische Aktionen werden nicht protokolliert;
Warnungen und Fehler erzeugen keine oder unklare Protokollmeldungen;
Anwendungen werden nicht auf verdächtige Aktivitäten hin überwacht;
Protokolle werden nur lokal gespeichert und nicht ausgewertet;
Logfiles werden nach ein paar Tagen überschrieben, so dass Angriffe dann nicht mehr ausgewertet werden können;
Anwendungen können keine aktiven Angriffe in Echtzeit erkennen, eskalieren oder alarmieren;
angemessene Alarmierungsschwellen und Eskalationsprozesse sind weder vorhanden noch wirksam;
Penetrationstests und Scans mit Angreifer-Tools lösen keine Warnmeldungen aus.
Bei den meisten Anwendungen gibt es nur schlechte oder gar keine Security-Logs. Ohne diese Informationen haben IT-Teams jedoch nur sehr beschränkte Möglichkeiten, um:
Angriffe zu erkennen;
kompromittierte User-Accounts zu finden;
Missbrauch von Berechtigungen zu erkennen;
auf Ereignisse zu reagieren.
Viele Unternehmen und Organisationen wissen daher einfach nicht, dass sie angegriffen wurden. Noch weniger können analysieren, wie sie angegriffen wurden und was genau der Angreifer gemacht hat.
Anforderungen an Security-taugliches Logging und Monitoring
Welche Anforderungen an Logging und Monitoring ergeben sich aus diesen Erkenntnissen? Zwar liegen manchmal Logausgaben von Anwendungen vor, aber diese sind, wie beschrieben, kurzlebig und meist uneinheitlich. Logausgaben sehen im Sourcecode dann nicht selten so ähnlich aus:
log.error("Something bad happened to " + name, exception);
Das Problem bei einer solchen Logausgabe ist, dass sie nur sehr schwer automatisiert auswertbar ist. Ein Alarmsystem braucht jedoch Ereignisse, die automatisiert verarbeitet und vernünftig interpretiert werden können. Andernfalls ist eine angemessene Reaktion nicht möglich.
Wünschenswert für eine automatisiert auswertbare Ausgabe wären folgende Angaben:
genaue Zeitangabe in universellem, global gültigem Format;
Bewertung des Schweregrads für jedes Ereignis;
Identität des Kontos beziehungsweise Benutzers, der das Ereignis verursacht hat;
Quell-IP-Adresse, die der Anfrage zugeordnet ist;
Benutzerkontext über Anwendungsebenen hinweg, zum Beispiel über internen Webservice, alle beteiligten Backend-Services, Messaging-Queue, Datenbanken etc.;
Ergebnis des Ereignisses und, wenn möglich, ob der Angriff erfolgreich war oder nicht.
Eine entsprechende Logausgabe könnte so aussehen:
Log.security( UserContext, // containing username, ip address, browser etcApplicationEvents.DataValidationFailure, exception);
Ein Freitext in der Logmeldung erschwert es, Ereignisse zu identifizieren und zu korrelieren. Tritt ein HTTP-Request zunächst in die erste Schicht der Anwendung ein und verursacht durch die entsprechende Business-Logik weitere Aufrufe in verschiedenen Backend-Services, dann ist es bei der Forensik extrem schwierig und aufwendig, ein Szenario nachzuvollziehen, wenn nicht zugeordnet werden kann, welche ursprüngliche Request die Anfragen in den Backend-Systemen ausgelöst hat. Deshalb ist es in diesem Fall sehr hilfreich, eine Korrelations-ID für den eingehenden Request zu vergeben und diese ID durchgehend für alle weiteren Aufrufe in der Anwendung weiterzugeben. Diese Korrelations-ID wird dann bei allen Security-Logausgaben angegeben, damit bei der späteren Analyse alle zusammenhängenden Aufrufe gefunden werden können.
Die Anforderungen an Logging und Monitoring sind sehr vielfältig, da sowohl forensische als auch datenschutzrechtliche Aspekte berücksichtigt werden müssen:
eine zentrale Funktion für alle Logging-Vorgänge verwenden, um die Übersicht zu behalten und homogene Ausgaben zu erzeugen;
sicherstellen, dass ein Mechanismus vorhanden ist, um eine Log-Analyse durchzuführen;
den Zugriff auf Protokolle auf autorisierte Personen beschränken;
keine sensiblen Informationen loggen, wie unnötige Systemdetails, Session-IDs oder Passwörter;
nur vertrauenswürdige Daten loggen;
mit ausreichendem Benutzerkontext protokollieren, um verdächtige oder bösartige Konten zu identifizieren (zum Beispiel Login-, Zugriffskontroll- und serverseitige Fehler bei der Eingabevalidierung);
angemessene Vorhaltezeit der Logs definieren, um verzögerte forensische Analysen zu ermöglichen;
universelles Format verwenden, damit Logs automatisch gelesen werden können;
kritische Transaktionen sollen über einen Audit-Trail mit Integritätskontrollen verfügen, um Manipulationen oder Löschungen zu verhindern, wie beispielsweise nur angehängte Datenbanktabellen;
wirksame Überwachung und Alarmierung sicherstellen, damit verdächtige Aktivitäten erkannt und rechtzeitig reagiert werden kann
Notfallreaktions- und Wiederherstellungsplan erarbeiten, damit im Ernstfall klar ist, welche Maßnahmen ergriffen werden müssen, um den Schaden einzudämmen.
Um alle diese Anforderungen zu erfüllen, bedarf es der durchdachten Integration eines Monitoring-Systems. Dieses sollte zentral zugänglich sein und unabhängig von der Anwendung die Ereignisse protokollieren und schützen. Der Zugriff auf die geloggten Daten sollte streng reglementiert sein, damit sowohl unautorisierten Personen Zugang zu diesen sensiblen Informationen verwehrt werden als auch ein Angreifer seine Spuren nicht beseitigen kann.
Was bedeutet Monitoring auf Anwendungs-Level?
Betrachtet man den Technologie-Stack einer Anwendung und ihrer darunterliegenden Komponenten, dann existieren im professionellen Betrieb bereits einige Monitoring-Komponenten auf dem Level der Netzwerk-Infrastruktur. Dazu zählen etwa Firewalls, Intrusion-Detection-Systeme (IDS) und Intrusion-Prevention-Systeme (IPS).
Diese sind wichtig und notwendig, allerdings haben sie den Nachteil, dass sie sehr wenig Informationen zum Kontext der Anwendung haben. Sie können also meist nicht beurteilen, ob der Request an eine Anwendung ein ganz normaler und legitimer Zugriff ist, oder ob es sich um einen Angriffsversuch handelt. Monitoring auf Anwendungs-Level bedeutet also, dass innerhalb der Anwendung, also beispielsweise im Quellcode selbst, untersucht und bewertet wird, was der Request für einen genauen Sinn und Zweck hat.
Wird etwa versucht, durch bekannte Angriffsvektoren über SQL-Injection auf das Datenbankmanagementsystem (DBMS) zuzugreifen, so kann dies in der Eingabevalidierung durch Abgleich mit einer Blacklist erkannt werden. Ebenso könnten Angriffe via Cross Site Scripting (XSS) oder XML External Entity (XXE) identifiziert werden. Beim einem Brute-Force-Angriff auf die Authentifizierungs-Komponente oder dem Aushebeln des Berechtigungssystems durch Privilege Escalation können ebenfalls Security-Logeinträge geschrieben werden, damit sämtliche Aktivitäten dokumentiert sind. Dabei ist es auch egal, ob diese Angriffsversuche erfolgreich sind oder nicht. Für die Forensik ist es wichtig zu wissen, ob ein Angriff stattfindet oder stattgefunden hat und von wo aus dieser durchgeführt wurde. Nur so können Abwehrmaßnahmen bereits beim Angriffsversuch stattfinden, und nicht erst nach dem erfolgreichen Einbruch.
Ein Monitoringsystem auf Anwendungs-Level ist also eine wichtige Ergänzung zu bestehenden Systemen, die auf Host- oder Netzwerk-Level arbeiten. Mit dessen Hilfe werden die Angreifer (und nicht nur die Schwachstellen) erkannt und die Auswirkungen eines Angriffs verhindert oder wenigstens reduziert.
OWASP AppSensor- mehr als nur ein Monitoring-Tool
Eine mögliche Implementierung eines solchen Monitoring-Systems wurde von dem Open Web Application Security Project (OWASP) mit dem AppSensor-Projekt umgesetzt. Es handelt sich dabei um ein Projekt-Template oder -Framework, das bereits viele der oben genannten Funktionen bereithält.
AppSensor ist mehr als nur ein Monitoring-Tool - es ist ein Security-Protection-System auf Anwendungs-Level. Es konzentriert relevante Security-Informationen zentral an einem Ort, damit sie nicht im Rauschen der Logs untergehen. Es sorgt für dynamische Abwehr, indem Events von der Anwendung aus über eine Programmierschnittstelle (API) direkt übergeben werden können, wenn etwa Logins wiederholt scheitern. Nur die Anwendung kennt den kompletten Kontext und kann wertvolle Informationen dazu liefern. Dadurch wird eine sinnvolle Abwehr erst möglich, etwa um Accounts auszusperren oder die IP-Adresse des Angreifers zu blockieren.
AppSensor arbeitet für die Erkennung und Einschätzung von Angriffen mit Policies. Ein einfaches Beispiel einer solchen Policy könnte sein:
Erfolgen zehn falsche Login-Events in fünf Minuten für einen User, wird der Account blockiert.
An den Erkennungspunkten im Quellcode wird ein Event an AppSensor gesendet. Dadurch kann dann in AppSensor durch die Policy festgelegt werden, was getan werden muss - in diesem Fall den Account zu blockieren. Events können auf verschiedene Arten an AppSensor geschickt werden:
individuell über die AppSensor-API;
durch aspektorientierte Programmierung (AOP);
oder über externe Tools.
Im Code könnte das dann so aussehen:
if ( isUserAuthorized( account ) ) { // present/view account} else { //new code for appsensor appSensor.addEvent( logged_in_user, "INSUFFICIENT_AUTHORIZATION" )}
Beim Scheitern des Logins im "else"-Zweig wird dann die Logik für das Feuern des Events eingebaut. AppSensor prüft nun seine Policy und reagiert entsprechend. Die Abwehrmaßnahme "blockiere den Account" wird beispielweise durch ein Skript umgesetzt, das per SQL-Befehl den Benutzeraccount blockiert und ihn nach einer Karenzzeit wieder entsperrt. AppSensor agiert hier also als Schaltzentrale, um solche Ereignisse angemessen zu orchestrieren.
Eine andere Policy, etwa um einen Credential-Stuffing-Angriff zu erkennen und zu vereiteln, könnte so aussehen: Erkenne, ob in kurzer Zeit von einer einzigen IP-Adresse Anmeldeversuche für viele Benutzer kommen - auch wenn nur je ein Mal. Mit AppSensor lassen sich solche Angriffe erkennen und Maßnahmen ergreifen.
Die Architektur von AppSensor
Das Herz von AppSensor ist die Server-Komponente, die mit Events aus der zu überwachenden Anwendung versorgt wird. In der Webanwendung werden über die AppSensor-API Events aufgezeichnet, die im Server registriert und ausgewertet werden. Die Auswertung geschieht anhand der Policies, die dann im Ernstfall Maßnahmen einleiten, indem sie an den Response-Handler die entsprechenden Befehle erteilen. Der Response-Handler kann sich innerhalb der Webanwendung oder in einer separaten Anwendung befinden.
Foto: exxeta
Das AppSensor-Dashboard
Die zentrale Stelle für das Monitoring ist das AppSensor-Dashboard. Es ist dem Integrations-Team überlassen, wie genau das Dashboard gestaltet wird, denn die Monitoring-Anwendung von AppSensor wird üblicherweise selbst entwickelt. Alle Daten, die visualisiert werden sollen, werden vom AppSensor-Server zur Verfügung gestellt.
Die Abbildung unten zeigt die Variante einer Design-Studie, die die eingegangenen Events der Anwendung als Indikator und Details dazu in der Detection-Tabelle anzeigt. Außerdem werden eingeleitete Maßnahmen in der Response-Tabelle angezeigt, sowie Trends und Statistiken rechts unten aufgeführt. Wird ein Angriff erkannt, leuchten die Indikatoren zunächst rot und werden nach gewisser Zeit orange, gelb, dann wieder weiß. Die rote Ampel links oben zeigt an, dass gerade ein SQL-Injection Angriff stattfindet.
Foto: OWASP AppSensor project
Durch ein solches Sicherheits-Monitoring kann tatsächlich bemerkt werden, dass ein Angriff stattfindet - und zwar rechtzeitig. Zudem können die Abwehrmaßnahmen im Dashboard in Echtzeit verfolgt werden.
Der Aufwand, die Sensoren in eine existierende Anwendung einzubauen, ist minimal. Erheblich größer ist der Aufwand, den AppSensor-Server aufzusetzen und das Dashboard zu entwickeln, das letztendlich den Leitstand für das Sicherheitsmonitoring darstellt. Dazu sollte am besten ein separater Server verwendet werden, der unabhängig von der Anwendung existiert und auch für andere zu überwachende Anwendungen zur Verfügung stehen kann. Wenn Sever und Dashboard einmal errichtet sind, ist die Integration neuer Sensoren in der Anwendung sowie die Integration neuer Anwendungen ein verhältnismäßig kleiner Aufwand.
Fazit
Ein Monitoring-System wie AppSensor, das auf sicherheitskritische Events reagiert, bietet Transparenz und die Möglichkeit, Abwehrmaßnahmen in Echtzeit durchzuführen. Zudem bringt es Mehrwerte hinsichtlich Prävention und Reaktion mit sich. Die Investition in ein Monitoring-System ist eine sinnvolle und notwendige Maßnahme, um die Sicherheit gemäß den Anforderungen an eine moderne IT-Umgebung maßgeblich zu erhöhen. (jd)