DDoS-Berichte richtig lesen: Welche Nachweise nach einem Angriff zählen
Ein hoher Angriffspeak beweist keine erfolgreiche Dienstverfügbarkeit. So verbinden Sie Verkehrsdiagramme, Nutzerwirkung und Maßnahmen zu einem nützlichen Betriebsbericht.
Aktualisiert:
Nach einem DDoS-Angriff zeigt ein Diagramm oft zuerst den höchsten Ausschlag. Für Betrieb und Geschäftsleitung sind weitere Fragen entscheidend: Welche Dienste waren betroffen? Konnten Kunden sie nutzen? Welche Maßnahme hat geholfen, und was muss sich vor dem nächsten Vorfall ändern? Ein brauchbarer Bericht verbindet diese Perspektiven.
Beginnen Sie mit der Wirkung auf den Dienst
Die erste Seite sollte den betroffenen Dienst, den beobachteten Zeitraum und die Auswirkungen in wenigen Sätzen erklären. Trennen Sie eine bestätigte Unterbrechung von einzelnen Kundenmeldungen oder einer noch ungeklärten Auffälligkeit. Eine Meldung wie keine Ausfälle beobachtet braucht den Zusatz, mit welchen Prüfungen und aus welchen Netzen beobachtet wurde.
Ein Beispiel zur Einordnung: Ein Kundenportal ist aus zwei Prüfstandorten erreichbar; der Anmeldevorgang wird jedoch nicht geprüft. Daraus folgt eine Aussage über diese Erreichbarkeitsprüfungen. Eine durchgehend funktionierende Anmeldung lässt sich daraus nicht ableiten. Diese Präzision hilft auch bei Rückfragen von Kunden.
Jedes Verkehrsdiagramm benötigt eine lesbare Definition
- Messpunkt: Wo wurde der Verkehr erfasst, und betrifft die Anzeige eine IP-Adresse, ein Präfix oder mehrere Dienste?
- Einheit und Richtung: Zeigt das Diagramm Bit/s, Pakete/s oder Anfragen/s sowie ein- oder ausgehenden Verkehr?
- Zeitbezug: Welche Zeitzone und welche Zusammenfassung pro Messintervall gelten?
- Verkehrskategorie: Zeigt die Reihe beobachteten, verworfenen oder weitergeleiteten Verkehr?
- Datenqualität: Gibt es Stichproben, fehlende Messwerte oder Änderungen der Erfassung?
Verwerfen und Weiterleiten beschreiben zunächst die Entscheidung eines Systems. Weitergeleiteter Verkehr ist dadurch noch nicht als vollständig legitim nachgewiesen. Auch ein Rückgang am Messpunkt belegt für sich nicht, warum er eingetreten ist. Halten Sie Interpretation und Messwert im Bericht getrennt.
Netzbeobachtung und Anwendungstest zusammen lesen
Passive Messungen beobachten vorhandenen Verkehr. Aktive Messungen nutzen eigens erzeugte Prüfverbindungen oder Pakete. RFC 7799 grenzt diese Verfahren voneinander ab. Für einen Betriebsbericht beantworten sie ergänzende Fragen: Die Verkehrsbeobachtung zeigt Last und Behandlung; ein passender Anwendungstest zeigt, ob ein definierter Vorgang vom Prüfstandort aus gelingt.
RFC 7799: aktive und passive Messverfahren
Dokumentieren Sie Unsicherheiten ausdrücklich. Fünfminutenmittel können kurze Spitzen verdecken; ein ausgefallener Messsammler erzeugt eine Datenlücke. RFC 2330 fordert, Messfehler und ihre Ursachen zu verstehen und zu dokumentieren. Fehlende Werte sollten daher sichtbar fehlen und nicht als null Verkehr erscheinen.
RFC 2330, Abschnitt 6.3: Messunsicherheit und Fehler
Eine gemeinsame Zeitachse verhindert voreilige Schlüsse
Führen Sie das erste beobachtete Ereignis, die erste Nutzerbeeinträchtigung, Erkennung, Maßnahmen und bestätigte Wiederherstellung getrennt auf. Verwenden Sie eine gemeinsame Zeitzone und vermerken Sie ungenaue Zeitangaben. Die Aktivierung einer Maßnahme und die Erholung einer Anwendung können zeitlich auseinanderliegen.
Bewahren Sie die zugrunde liegenden Protokolle und Auszüge mit nachvollziehbarer Herkunft auf. Wer hat welchen Export zu welchem Zeitpunkt erstellt? Welche Systeme fehlen? NIST SP 800-92 behandelt die Planung und den Betrieb von Logmanagement. Für den Bericht genügt oft ein kurzer Verweis auf die intern abgelegten Belege.
NIST SP 800-92: Guide to Computer Security Log Management
Aus dem Bericht müssen umsetzbare Aufgaben entstehen
NIST SP 800-61 Revision 3 ordnet Erkenntnisse aus Vorfällen in eine fortlaufende Verbesserung der Sicherheitsorganisation ein. Übertragen Sie diesen Gedanken auf wenige konkrete Aufgaben mit Verantwortlichem und Termin. Eine offene Frage zur Erreichbarkeit wird dadurch beispielsweise zu einem zusätzlichen Anwendungstest mit definiertem Prüfergebnis.
NIST SP 800-61 Revision 3: Incident Response und fortlaufende Verbesserung
Vorlage für die interne Zusammenfassung
Dienst und Zeitraum · bestätigte Nutzerwirkung · wesentliche Messwerte mit Bezugsgröße · durchgeführte Maßnahmen · verbliebene Unsicherheiten · nächste Aufgabe mit Verantwortlichem und Termin.
Besprechen Sie bereits bei der Auswahl eines Schutzdienstes, welche Daten im Ereignisfall verfügbar sein sollen und wer sie zusammenführt. Das ist eine Anforderung an die Zusammenarbeit. Ein bestimmtes Portal oder automatisch erzeugter Bericht ist damit noch nicht zugesagt.