OWASP Top Ten 2017 (de)

A10:2017-Unzureichendes Logging & Monitoring

 Languages: en [de]
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 2 Verbreitung: 3 Auffindbarkeit: 1 technisch: 2 Geschäftl. ?
Das Ausnutzen unzureichender Protokollierungs- und Monitoring-Maßnahmen ist der Ausgangspunkt fast aller größerer Sicherheitsvorfälle.
Angreifer nutzen fehlendes Monitoring und verzögerte Antwortzeiten auf Vorfälle dazu aus, unentdeckt Angriffe durchzuführen.
Dieser Eintrag in den Top 10 basiert auf einer Umfrage unter Sicherheitsexperten.
Eine mögliche Strategie, um herauszufinden, ob Ihre Monitoring-Maßnahmen ausreichend sind, ist es, die Logging-Einträge Ihres Systems nach einem Penetrationstest zu überprüfen. Die Aktivitäten des Testers sollten so protokolliert worden sein, das Sie daraus mögliche Schäden identifizieren können.
Den meisten erfolgreichen Angriffen gehen Schwachstellen-Scans voraus. Wenn solche Scans nicht abgewehrt werden, besteht ein fast 100 prozentiges Risiko für erfolgreiche Angriffe.
Die Zeit bis zur Aufdeckung eines Einbruchs lag 2016 durchschnittlich bei 191 Tagen – viel Zeit, um Ihren Systemen Schaden zuzufügen.
Ist die Anwendung verwundbar?
Unzureichende Protokollierungs-, Erkennungs- und Monitoring-Maßnahmen sowie fehlende aktive Reaktionen auf Vorfälletreten ständig auf:
* Auditierbare Ereignisse wie erfolgreiche oder fehlgeschlagene Log-ins oder wichtige Transaktionen werden nicht protokolliert.
* Warnungen und Fehler erzeugen keine, unzureichende oder uneindeutige Protokoll-Einträge.
* Protokolle von Anwendungen und Schnittstellen werden nicht ausreichend hinsichtlich verdächtiger Aktivitäten überprüft.
* Protokolle werden nur lokal gespeichert.
* Geeignete Alarmierungs-Schwellen und Eskalations-Prozesse als Reaktion auf (potentielle) Vorfälle liegen nicht vor oder sind nicht wirksam.
* Penetration-Tests und Scans mit DAST-Werkzeugen (wie OWASP ZAP) lösen keine Alarme aus.
* Die eingesetzten Überwachungsverfahren sind nicht in der Lage aktive Angriffe zu erkennen und in Echtzeit oder nahezu Echtzeit Alarm auszulösen.
Wenn Ihre Systeme Protokollierungs- und Alarmierungs-Nachrichten Benutzern oder Angreifern preisgeben, kann dies zum Abfluss von Daten führen (siehe A3:2017-Verlust der Vertraulichkeit sensibler Daten).
Wie kann ich das verhindern?
Führen Sie für alle von Anwendungen gespeicherten oder prozessierten Daten folgende Maßnahmen durch:
* Stellen Sie sicher, dass alle erfolglosen Login- und Zugriffs-Versuche und Fehler bei der serverseitigen Eingabevalidierung mit aussagekräftigem Benutzerkontext protokolliert werden, um verdächtige oder schädliche Accounts zu identifizieren. Halten Sie diese Informationen ausreichend lange vor, um auch später forensische Analysen vorzunehmen zu können.
* Stellen Sie sicher, dass Protokollierungen in einem Format erstellt werden, die eine einfache Verarbeitung durch zentrale Protokollanalyse- und -managementwerkzeuge ermöglicht.
* Speichern Sie für wichtige Transaktionen Audit-Trails mit Integritätsschutz, um Verfälschung oder ein Löschen zu verhindern, z.B. durch Einsatz von Datenbanktabellen, die nur das Anhängen von Datensätzen zulassen.
• Richten Sie wirksame Monitoring- und Alarmierungs-Verfahren ein, damit verdächtige Aktivitäten zeitnah entdeckt und bearbeitet werden.
• Etablieren Sie Notfall- und Wiederherstellungspläne für Sicherheitsvorfälle, z.B. auf Basis von NIST 800-61 rev 2.
Es gibt kommerzielle o. Open-Source-Frameworks zum Schutz Ihrer Anwendungen, wie OWASP AppSensor (old wiki), WebApp Firewalls wie ModSecurity mit dem OWASP ModSecurity Core Rule Set und geeignete Protokollanalyse-Werkzeuge inkl. Alarmierung.
Mögliche Angriffsszenarien
Szenario 1: Eine Open-Source Projektforums-Software, die von einem kleinen Team betrieben wird, wurde auf Grund eines Fehlers in der Software angegriffen. Die Angreifer konnten das interne Quellcode-Repository mit der nächsten Version und allen Inhalten löschen. Obwohl der Quellcode wiederhergestellt werden konnte, führte das Fehlen von Monitoring, Protokollierung und Warnmeldungen zu weit schwerwiegenderen Folgen. Als Konsequenz ist das Projektforum inzwischen nicht mehr aktiv.

Szenario 2: Angreifer scannen nach Nutzern mit häufig benutzten, einfachen Passwörtern. Sie können alle betroffenen Accounts übernehmen. Für alle anderen Nutzer hinterlässt dieser Angriff nur 1 falschen Loginversuch. Nach einiger Zeit könnte der Angriff mit anderen Passwörtern wiederholt werden.

Szenario 3: Ein großer US-Großhändler verfügte über eine Sandbox, die Mail-Anhänge auf Schadsoftware überprüfte.Die Sandbox entdeckte potenziell gefährliche Software, aber niemand reagierte auf diese Meldung. Der Sicherheitsvorfall wurde jedoch erst erkannt, als die Hausbank betrügerische Kreditkarten-Transaktionen meldete.
Referenzen