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.