Dieser Beitrag aus unserer Reihe zur OWASP Top 10, den zehn häufigsten Sicherheitslücken in Webapplikationen, beschäftigt sich mit unzureichendem Logging und Monitoring.
Um effektiv auf Sicherheitsvorfälle reagieren zu können und andauernde oder wiederholte Angriffe zu vermeiden, ist es essentiell ein entsprechendes Logging und Monitoring zu etablieren. Wird dies nur unzureichend umgesetzt, dann können Angreifer in Netzwerken weiter vordringen und Daten erbeuten, verändern oder zerstören. Die Aufdeckung eines Cyber-Angriffs dauert in vielen Fälle zu lange und wird im schlechtesten Fall nicht durch interne Überwachungs- und Kontrollmaßnahmen entdeckt, deshalb wird diese Problematik hier noch einmal aufgegriffen.
Beispielszenarien
Unzureichende Maßnahmen bezogen auf die Protokollierung, das Erkennen und Monitoring von Vorfällen sowie die nicht darauf vorhandenen Reaktionen liegen u. a. bei nachstehenden Gegebenheiten vor:
- Erfolgreiche oder fehlgeschlagene Log-ins oder andere auditierbare Ereignisse werden nicht protokolliert.
Beispielhaft kann von einem Szenario ausgegangen werden, in dem Angreifer nach Nutzern mit häufig verwendeten und trivialen Passwörtern scannen. Betroffene Accounts können bei diesem Brute-Force-Angriff übernommen werden. Bei allen anderen Nutzern hinterlässt dieses bösartige Vorhaben keine falschen Login-Versuche in der Protokollierung. Entsprechend könnte diese Angriffsmethode mit weiteren Passwörtern wiederholt werden.
- Auftretende Warnungen und Fehler erzeugen keine, unzureichende oder nicht eindeutige Protokolleinträge.
- Die Protokolle von Anwendungen sowie Schnittstellen werden nicht ausreichend hinsichtlich verdächtiger Aktivitäten analysiert.
Beispiel: Ein großer fiktiver US-Großhändler verfügt über eine Sandbox, um E-Mail-Anhänge auf Schadsoftware zu überprüfen. Die als Sicherheitssoftware agierende Sandbox entdeckt einen potentiell bösartigen E-Mail-Anhang und generiert daraufhin eine Warnung, auf die von niemanden angemessen reagiert wird. Erst als die Hausbank betrügerische Kreditkarten-Transaktionen meldete, wird der Sicherheitsvorfall aufgedeckt.
- Es erfolgt nur eine lokale Speicherung von Protokolldaten.
- Bei potentiellen Risikovorfällen existieren keine bzw. nur unwirksame Schwellenwerte für eine Alarmierung sowie Prozesse zur Eskalation.
- Der Einsatz von Penetrationstests und Scans mit DAST-Werkzeugen (Dynamic Application Security Testing), wie z. B. OWASP ZAP, lösen bei der untersuchten Webapplikation bzw. der darunter liegenden Infrastruktur keine Alarme aus.
- Aktive Angriffe können nicht durch die eingesetzten Überwachungsmaßnahmen erkannt werden und keinen (nahezu) Echtzeit-Alarm auslösen.
Generell kann die Preisgabe von Protokollierungs- und Alarmierungsmeldungen an den Nutzer oder einen Angreifer zum Abfluss von Daten führen; der Verlust der Vertraulichkeit sensibler Daten ist demzufolge gefährdet.
Gegenmaßnahmen
Für alle von Anwendungen gespeicherten oder prozessierten Daten sollten folgende Maßnahmen durchgeführt werden:
- Wirksame Monitoring- und Alarmierungsverfahren sollten eingerichtet werden, um verdächtige Aktivitäten zeitnah entdecken und bearbeiten zu können
- Alle erfolglosen Login- und Zugriffsversuche sowie Fehler bei der serverseitigen Eingabevalidierung müssen mit einem aussagekräftigen Benutzerkontext protokolliert werden, um verdächtige Accounts zu identifizieren. Um auch später forensische Analysen vornehmen zu können, ist ein ausreichend langes Vorhalten dieser Informationen notwendig.
- Protokollierungen sollten in einem Format vorliegen, welches eine einfache (Weiter-) Verarbeitung durch Analyse- und Managementwerkzeuge ermöglicht.
- Für wichtige Transaktionen sollten Audit-Trails mit einem Integritätsschutz gespeichert werden, um Verfälschungen oder ein Löschen vorzubeugen. Dies kann z. B. durch den Einsatz von Datenbanktabellen gewährleistet werden, die nur das Anhängen von neuen Datensätzen zulassen. Wer noch einen Schritt weiter gehen möchte, setzt auf nur einmal beschreibbare Speichermedien (WORM).
- Für Sicherheitsvorfälle sollten Notfall- und Wiederherstellungspläne etabliert werden, bspw. kann hierfür der Leitfaden zur Behandlung von Computersicherheitsvorfällen (SP 800-61 Rev. 2) des NIST herangezogen werden.
Auf dem Markt gibt es diverse kommerzielle als auch Open-Source-Frameworks, die den Schutz von Anwendungen verbessern sollen. Der OWASP AppSensor, WebApp Firewalls wie ModSecurity mit dem OWASP ModSecurity Core Rule Set und geeignete Protokollanalysewerkzeuge inklusive Alarmierung sind hier zu nennen.
Zusammenfassung
Der Ausgangspunkt für fast alle größeren Sicherheitsvorfälle, ist auf das Fehlen bzw. die Ausnutzung von unzureichenden Protokollierungs-, Monitoring- und Alarmierungs-Maßnahmen zurückzuführen. Fehlendes Monitoring und die verzögerte Bearbeitungszeit von potentiellen Risikoereignissen nutzen Angreifer für unentdeckte Angriffe aus. Im Jahr 2020 (vgl. hier) lag die durchschnittliche Dauer zur Identifizierung von Vorfällen bei 207 Tagen und weiteren 73 Tagen für die Behebung. International schneiden die Unternehmen in Deutschland dabei noch am besten ab, benötigen aber trotzdem noch eine beträchtliche Zeitspanne von durchschnittlich 128 Tagen bis zur Entdeckung eines Risikoereignisses und weitere 32 Tage für die anschließende Eindämmung. Schwachstellen-Scans gehen den meisten Angriffen voraus. Wenn solche Scans nicht adäquat abgewehrt werden, dann existiert eine hohe Wahrscheinlichkeit für einen erfolgreichen Angriff. Ein Penetrationstest kann eine mögliche Strategie sein, um ausreichende Monitoring-Maßnahmen nach einem Testdurchlauf anhand der Logging-Einträge eines betrachteten Systems festzustellen
Übrigens gibt es seit dem 24. September 2021 eine neue Version der OWASP Top 10. Es sind drei neue Kategorien (A04:2021 – Unsicheres Design, A08:2021 – Software- und Datenintegritätsmängel, A10:2021 – Server-Side Request Forgery (SSRF)) und vier Kategorien mit geänderten Bezeichnungen und Umfängen (A02:2021 – Kryptographische Fehler, A06:2021 – Anfällige und veraltete Komponenten, A07:2021 – Fehler bei der Identifizierung und Authentifizierung, A09:2021 – Fehler bei der Sicherheitsprotokollierung und -überwachung) hinzugefügt sowie einige weitere Konsolidierungen vorgenommen worden.