Warum Logging und Monitoring zur Angriffsfläche gehören

Die OWASP API Security Top 10 führten in der Ausgabe 2019 einen eigenen Eintrag API10:2019 Insufficient Logging & Monitoring. OWASP beschreibt das Risiko knapp: Ohne oder mit unzureichender Protokollierung und Überwachung ist es nahezu unmöglich, verdächtige Aktivitäten zu verfolgen und rechtzeitig darauf zu reagieren. Angreifer nutzen genau diese Lücke aus, um Systeme unbemerkt zu missbrauchen, und gewinnen so Zeit, um sie vollständig zu kompromittieren.

In der Ausgabe 2023 wurde dieser Punkt nicht gestrichen, sondern in API8:2023 Security Misconfiguration aufgenommen. Dort zählt OWASP unter den Schwachstellen ausdrücklich falsch gesetzte oder fehlende Logging-Features auf. Logging ist damit kein nachgelagertes Betriebsthema, sondern Teil der sicheren Konfiguration des gesamten API-Stacks.

OWASP nennt zwei typische Szenarien für unzureichendes Logging: durchgesickerte Zugangsschlüssel einer Admin-API, bei denen die Organisation mangels Logs nicht rekonstruieren kann, welche Daten abgeflossen sind, und ein Credential-Stuffing-Angriff, bei dem fehlgeschlagene Logins zwar geschrieben, aber nie ausgewertet wurden, sodass kein Alarm ausgelöst wurde. Beide zeigen das Kernproblem: Logs zu schreiben genügt nicht, sie müssen auch kontinuierlich überwacht werden.

MusterSichtbares Verhalten im LogBeispiel-Ereignis (OWASP-Vokabular)
BOLA-Probing / Objekt-EnumerationSequenzielles Durchiterieren von Objekt-IDs, viele Autorisierungsfehlerauthz_fail, malicious_direct_reference
Scraping / DatenabgriffHohes, gleichmäßiges Volumen über Listen- und Detail-Endpunkteexcess_rate_limit_exceeded
Credential StuffingViele fehlgeschlagene Logins für viele Konten, verteilte Quellenauthn_login_fail, authn_login_fail_max
Account-ÜbernahmeAnmeldung aus unplausibler Geolokation, Token-Wiederverwendungauthn_impossible_travel, authn_token_reuse
Endpunkt- / Inventar-ScanGehäufte 404 und Zugriffe auf nicht spezifizierte Pfademalicious_excess_404

Missbrauchsmuster und ihre Log-Indikatoren

Was geloggt werden muss

OWASP gibt für API-Logging eine klare Mindestmenge vor. Protokolliert werden sollten alle fehlgeschlagenen Authentifizierungsversuche, verweigerte Zugriffe (Autorisierungsfehler) und Fehler bei der Eingabevalidierung. Der OWASP Logging Cheat Sheet ergänzt diese Liste um die Ereignisse, die in einer API sicherheitsrelevant sind:

  • Authentifizierung: erfolgreiche und fehlgeschlagene Anmeldungen, Sperrungen, Passwort- und Token-Änderungen. Gehäufte Fehlversuche für dasselbe Konto, aus vielen IP-Adressen oder in schnellen Stößen sind Frühindikatoren für Brute-Force, Credential Stuffing und Password Spraying.
  • Autorisierung: Zugriffskontroll-Verstöße, also Anfragen auf Objekte oder Funktionen, für die der Aufrufer keine Berechtigung hat. Solche Ereignisse sind das Logging-Korrelat von BOLA und BFLA.
  • Eingabe- und Ausgabevalidierung: Protokollverstöße, ungültige Parameter, Schema-Verletzungen. Ein Fehlschlag gegen eine endliche Wertemenge ist laut OWASP ein hohes Sicherheitsereignis, weil er nur durch Angriffsaktivität entstehen kann.
  • Session- und Token-Ereignisse: verdächtige JWT-Validierungsfehler, manipulierte Session-Bezeichner, Token-Wiederverwendung.
  • Höher privilegierte Funktionen: Nutzerverwaltung, Rechteänderungen, administrative Aktionen sowie Start, Stopp und Konfigurationsänderungen von Diensten.

Auf Transport- und Statusebene gehören vor allem die 4xx- und 5xx-Antworten ins Monitoring. Eine ungewöhnliche Häufung von 401/403 deutet auf Berechtigungs-Probing, viele 404 auf Enumeration oder Inventar-Scans, und ein Anstieg von 5xx auf fehlerhafte oder überlastende Anfragen. OWASP weist zugleich darauf hin, dass es keine universelle Checkliste gibt: Umfang und Detailgrad sollten sich am Sicherheitsrisiko orientieren, sonst entsteht Alarm-Rauschen, in dem echte Vorfälle untergehen.

Was niemals ins Log gehört

Logs sind selbst ein lohnendes Angriffsziel und unterliegen Datenschutzrecht. OWASP behandelt Logs daher als sensible Daten, deren Integrität im Ruhezustand und bei der Übertragung gesichert sein muss. Bestimmte Inhalte dürfen nach dem OWASP Logging Cheat Sheet gar nicht oder nur maskiert, gehasht oder verschlüsselt erscheinen:

  • Authentifizierungs-Passwörter und Access Tokens sowie Session-Bezeichner (bei Bedarf durch einen Hash-Wert ersetzen).
  • Verschlüsselungsschlüssel und andere Geheimnisse, Datenbank-Verbindungszeichenfolgen.
  • Bank- und Zahlungskartendaten sowie sensible personenbezogene Daten (etwa Gesundheits- oder Ausweisdaten).
  • Quellcode der Anwendung und Daten höherer Schutzklasse, als das Logging-System speichern darf.
  • Daten, deren Erhebung in der jeweiligen Rechtsordnung unzulässig ist oder für die kein Einverständnis vorliegt.

Auch weniger heikle Felder wie IP-Adressen, interne Netzwerknamen, Dateipfade oder Kontaktdaten sind mit Bedacht zu behandeln. Der OWASP Logging Vocabulary Cheat Sheet formuliert das als Verantwortung des Daten-Stewards: Eine IP-Adresse kann für Detektion nützlich sein, in Kombination mit anderen Feldern aber personenbeziehbar werden. Das deckt sich mit dem Grundsatz der Datenminimierung. Ein häufiger, vermeidbarer Fehler ist das Mitloggen vollständiger Request-Header oder -Bodies, in denen Authorization-Header oder Tokens stehen.

Strukturierte Logs, Korrelation und SIEM

Damit Logs maschinell auswertbar sind, fordert OWASP ein Format, das eine Log-Management-Lösung konsumieren kann, mit genügend Detail, um den Akteur zu identifizieren. Jeder Eintrag sollte das Wann, Wo, Wer und Was festhalten: Zeitstempel, Anwendungs- und Host-Kennung, Quelladresse und Nutzeridentität (sofern bekannt) sowie Typ und Schwere des Ereignisses.

Der OWASP Logging Vocabulary Cheat Sheet schlägt dafür ein einheitliches JSON-Schema und eine standardisierte Ereignis-Benennung vor, etwa authn_login_fail, authn_login_fail_max, authz_fail, excess_rate_limit_exceeded oder malicious_excess_404. Zeitangaben sollen im ISO-8601-Format mit UTC-Offset stehen, damit Einträge über Systeme hinweg vergleichbar sind. Ein Eintrag kann etwa so aussehen:

  • { "datetime": "2026-01-01T01:01:01-0700", "appid": "foobar.netportal_auth", "event": "authn_login_success:joebob1", "level": "INFO", "source_ip": "165.225.50.94", "request_uri": "/api/v2/auth/", "request_method": "POST" }

Für die Schwere-Einstufung etabliert RFC 5424 (Syslog) die bekannten Stufen von Emergency bis Debug. Eine durchgängige Korrelations-ID pro Anfrage erlaubt es, einen Aufruf über Gateway, Microservices und nachgelagerte Dienste hinweg zu verfolgen, was bei verteilten Architekturen entscheidend ist.

OWASP empfiehlt, alle Logs des API-Stacks und der Hosts in einem SIEM (Security Information and Event Management) zusammenzuführen und mit Dashboards und Alarmen zu versehen, damit verdächtige Aktivitäten früher erkannt und beantwortet werden. NIST SP 800-92 (Guide to Computer Security Log Management) liefert dazu den organisatorischen Rahmen: zentrale Log-Management-Infrastruktur, definierte Aufbewahrung sowie wiederholbare Prozesse zur Auswertung. In der weitergehenden Automatisierung knüpft SOAR (Security Orchestration, Automation and Response) an, das auf erkannte Muster mit definierten Playbooks reagiert, etwa einem Token-Widerruf oder einer temporären Sperre.

Anomalie-Erkennung: Enumeration, Scraping und BOLA-Muster

Viele API-Angriffe bestehen aus formal gültigen Einzelanfragen, die erst im Muster auffällig werden. Eine BOLA-Ausnutzung etwa funktioniert, indem ein Angreifer Objekt-Bezeichner wie Nutzer- oder Auftrags-IDs durchiteriert. Jede einzelne Anfrage kann syntaktisch korrekt und authentifiziert sein. Auffällig wird das Verhalten über die Zeit: sequenzielles Hochzählen von IDs, ein hoher Anteil an Zugriffen auf fremde Objekte, viele 403-Antworten oder ungewöhnlich viele unterschiedliche Objekte pro Sitzung.

Typische Missbrauchsmuster und ihre Indikatoren:

  • Objekt-Enumeration / BOLA-Probing: monoton steigende oder zufällig durchprobierte Bezeichner, viele Autorisierungsfehler. Vendor-Werkzeuge wie Cloudflare API Shield erkennen BOLA-Versuche unter anderem an Enumeration über Objekt-IDs.
  • Scraping / Datenabgriff: hohes, gleichmäßiges Anfragevolumen über Auflistungs- und Detail-Endpunkte, oft mit auffälligem User-Agent oder breiter Streuung der Quell-IPs.
  • Credential Stuffing / Account-Übernahme: viele fehlgeschlagene Logins für unterschiedliche Konten von wenigen Adressen oder verteilt, ungewöhnliche Geolokation (authn_impossible_travel).
  • Endpunkt- und Inventar-Scans: gehäufte 404 und Anfragen auf nicht spezifizierte Pfade (malicious_excess_404).

Erkennung baut auf zwei Ebenen auf: Schwellenwerte und Raten (etwa Anfragen pro Token, 4xx-Quote pro Endpunkt) sowie Verhaltens-Baselines, die den normalen Zugriff eines Clients lernen und Abweichungen melden. Voraussetzung für beides ist ein pro Endpunkt und Konsument korrekt zugeordneter, strukturierter Log-Strom. Wichtig ist die Abgrenzung: Anomalie-Erkennung deckt Missbrauch auf, ersetzt aber keine serverseitige Autorisierungsprüfung, die BOLA an der Wurzel verhindert.

Audit-Trail, Nachvollziehbarkeit und Bezug zu Improper Inventory

Logging erfüllt zwei verwandte Zwecke: Detektion in nahezu Echtzeit und einen belastbaren Audit-Trail für die spätere Aufklärung. OWASP betont, dass die Integrität der Logs gesichert sein muss, unter anderem gegen Log Injection, damit Aufzeichnungen vor Gericht und in der Forensik verwertbar bleiben. Im deutschen Kontext beschreibt der BSI-IT-Grundschutz-Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen, wie Informationen gesammelt, korreliert und ausgewertet werden, um Ereignisse möglichst vollständig und zeitnah zu erkennen. Voraussetzung dafür ist laut BSI eine umfassende Protokollierung, die im Baustein OPS.1.1.5 Protokollierung geregelt ist.

Es gibt eine enge Wechselwirkung mit Improper Inventory Management (API9:2023): Was nicht im API-Inventar steht, wird in der Regel auch nicht überwacht. Vergessene, undokumentierte oder veraltete Endpunkte (Shadow- und Zombie-APIs) erzeugen entweder keine Logs oder Logs, die niemand auswertet, und werden so zum bevorzugten Ziel. Umgekehrt deckt das Monitoring des realen Verkehrs Endpunkte auf, die in keiner Spezifikation auftauchen. Vollständiges Inventar und vollständiges Logging bedingen einander.

Genau hier setzt Venedys Anspruch der Nachvollziehbarkeit an: belegbare Befunde statt einer Black Box. Befunde an einer Schnittstelle lassen sich auf die zugrundeliegenden Beobachtungen zurückführen, sodass Sicherheits- und Compliance-Verantwortliche nicht nur erfahren, dass ein Risiko besteht, sondern warum. Das ergänzt die hier beschriebenen Logging- und Monitoring-Praktiken, ersetzt sie aber nicht.

Quellen

Weiterlesen
API9Improper Inventory Management API8Security Misconfiguration GrundlagenAPIs im Betrieb