Systeme zur Angriffserkennung: Unterschied zwischen den Versionen

Aus IT-Forensik Wiki
St180824 (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
St180824 (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''''Systeme zur Angriffserkennung - Technische/technisch organisatorische und forensische Anforderungen gemäß BSIG'''''
'''Systeme zur Angriffserkennung - Technische/technisch organisatorische und forensische Anforderungen gemäß BSIG'''


Systeme zur Angriffserkennung (SzA) sind zentrale Komponenten der IT-Sicherheitsarchitektur für Betreiber Kritischer Infrastrukturen. Sie ermöglichen die frühzeitige Identifikation und Abwehr von Angriffen auf informationstechnische Systeme und sind gemäß § 8a Abs. 1a BSIG verpflichtend einzusetzen. SzA sind durch technische Werkzeuge und organisatorische Prozesse unterstützte Systeme, die Angriffe durch den Abgleich von Systemdaten mit bekannten Angriffsmustern erkennen. Seit dem 1. Mai 2023 müssen Betreiber Kritischer Infrastrukturen den Einsatz solcher Systeme nach dem Stand der Technik nachweisen.
Systeme zur Angriffserkennung (SzA) sind zentrale Komponenten der IT-Sicherheitsarchitektur für Betreiber Kritischer Infrastrukturen. Sie ermöglichen die frühzeitige Identifikation und Abwehr von Angriffen auf informationstechnische Systeme und sind gemäß § 8a Abs. 1a BSIG verpflichtend einzusetzen. SzA sind durch technische Werkzeuge und organisatorische Prozesse unterstützte Systeme, die Angriffe durch den Abgleich von Systemdaten mit bekannten Angriffsmustern erkennen. Seit dem 1. Mai 2023 müssen Betreiber Kritischer Infrastrukturen den Einsatz solcher Systeme nach dem Stand der Technik nachweisen.


'''Technische Anforderungen'''
''Technische Anforderungen''


Die technischen Anforderungen gliedern sich in drei zentrale Bereiche:
Die technischen Anforderungen gliedern sich in drei zentrale Bereiche:
Zeile 13: Zeile 13:
• ''Reaktion'': Automatisierte oder manuelle Maßnahmen zur Behandlung und Abwehr von Sicherheitsvorfällen. Sicherstellung, dass bei Alarmen zeitnah und angemessen reagiert wird. Dokumentation und Nachweisführung aller ergriffenen Maßnahmen.
• ''Reaktion'': Automatisierte oder manuelle Maßnahmen zur Behandlung und Abwehr von Sicherheitsvorfällen. Sicherstellung, dass bei Alarmen zeitnah und angemessen reagiert wird. Dokumentation und Nachweisführung aller ergriffenen Maßnahmen.


'''Protokollierung und Detektion'''
''Protokollierung und Detektion''


Die Protokollierungsdaten werden zentral im Security Operation Center gespeichert und ausgewertet. Die Infrastruktur umfasst einen zentralen Logserver und ein internes Logmanagement. Die Planung, Umsetzung und der Betrieb der Protokollierung folgen dem IT-Grundschutzbaustein OPS.1.1.5. Die Detektion orientiert sich am MITRE ATT&CK Framework und deckt alle relevanten Cyberbedrohungen ab. Advanced Detection Technology und NextGen Antivirus sorgen für die Erkennung von bösartigen Dateien, Prozessen und verdächtigen Aktivitäten. Threat Intelligence basiert auf einer Datenbank mit Millionen von IoCs (Indicators of Compromise), die von Drittanbietern und eigenen Untersuchungen stammen. Memory Protection erkennt Bedrohungen auf Kernel-Ebene und verhindert das Beenden von Schutzprozessen. AMSI (AntiMalware Scan Interface) Alerts erkennen bösartige Skriptbefehle. Die Protokolldaten werden kontinuierlich überwacht und ausgewertet, um bei sicherheitsrelevanten Ereignissen eine unmittelbare Alarmierung zu gewährleisten. Die Security-Analysten werden durch einen Dienstleister bereitgestellt.
Die Protokollierungsdaten werden zentral im Security Operation Center gespeichert und ausgewertet. Die Infrastruktur umfasst einen zentralen Logserver und ein internes Logmanagement. Die Planung, Umsetzung und der Betrieb der Protokollierung folgen dem IT-Grundschutzbaustein OPS.1.1.5. Die Detektion orientiert sich am MITRE ATT&CK Framework und deckt alle relevanten Cyberbedrohungen ab. Advanced Detection Technology und NextGen Antivirus sorgen für die Erkennung von bösartigen Dateien, Prozessen und verdächtigen Aktivitäten. Threat Intelligence basiert auf einer Datenbank mit Millionen von IoCs (Indicators of Compromise), die von Drittanbietern und eigenen Untersuchungen stammen. Memory Protection erkennt Bedrohungen auf Kernel-Ebene und verhindert das Beenden von Schutzprozessen. AMSI (AntiMalware Scan Interface) Alerts erkennen bösartige Skriptbefehle. Die Protokolldaten werden kontinuierlich überwacht und ausgewertet, um bei sicherheitsrelevanten Ereignissen eine unmittelbare Alarmierung zu gewährleisten. Die Security-Analysten werden durch einen Dienstleister bereitgestellt.


'''Externe Informationsquellen und Patchmanagement'''
''Externe Informationsquellen und Patchmanagement''


Um aktuelle Informationen zu Angriffsmustern zu erhalten, werden fortlaufend die technischen Vulnerabilitäten für die Systeme im Anwendungsbereich geprüft. Hierfür dienen nationale und internationale CERT-Meldungen, CVE-Listen, Hersteller-Webseiten als Grundlage. Die jeweiligen Empfänger der Informationen müssen diese sichten und auswerten. Ein zentrales Patchmanagement sorgt dafür, dass alle relevanten Systeme und Anwendungen auf dem aktuellen Stand gehalten werden.
Um aktuelle Informationen zu Angriffsmustern zu erhalten, werden fortlaufend die technischen Vulnerabilitäten für die Systeme im Anwendungsbereich geprüft. Hierfür dienen nationale und internationale CERT-Meldungen, CVE-Listen, Hersteller-Webseiten als Grundlage. Die jeweiligen Empfänger der Informationen müssen diese sichten und auswerten. Ein zentrales Patchmanagement sorgt dafür, dass alle relevanten Systeme und Anwendungen auf dem aktuellen Stand gehalten werden.


'''Abhilfemaßnahmen'''
''Abhilfemaßnahmen''


Für die Alarmtypen Host, File, Network und User existieren spezifische Abhilfemaßnahmen. Für Dateien können Maßnahmen wie Löschen, Download zur weiteren Investigation oder Quarantäne durchgeführt werden. Prozesse können beendet werden, ohne die Datei zu löschen. Für Netzwerke und Hosts sind Maßnahmen wie Herunterfahren, Neustart, Deaktivierung der Netzwerkschnittstellenkarte, Ausführung von Befehlen oder Skripten, Löschen oder Deaktivieren von Services und Tasks, Isolierung des Endpunkts, Öffnen einer Remote Shell, Blockierung von Netzwerkverbindungen und Wiederherstellung kompromittierter Dateien vorgesehen. Für User können Accounts deaktiviert oder aktiviert werden.
Für die Alarmtypen Host, File, Network und User existieren spezifische Abhilfemaßnahmen. Für Dateien können Maßnahmen wie Löschen, Download zur weiteren Investigation oder Quarantäne durchgeführt werden. Prozesse können beendet werden, ohne die Datei zu löschen. Für Netzwerke und Hosts sind Maßnahmen wie Herunterfahren, Neustart, Deaktivierung der Netzwerkschnittstellenkarte, Ausführung von Befehlen oder Skripten, Löschen oder Deaktivieren von Services und Tasks, Isolierung des Endpunkts, Öffnen einer Remote Shell, Blockierung von Netzwerkverbindungen und Wiederherstellung kompromittierter Dateien vorgesehen. Für User können Accounts deaktiviert oder aktiviert werden.


'''Forensische Anforderungen'''
''Forensische Anforderungen''


Protokollierungsdaten müssen manipulationssicher gespeichert werden, um die Integrität und Authentizität der Daten für forensische Analysen zu gewährleisten. Es sind Verfahren zur digitalen Signatur und zur sicheren Zeitstempelung der Protokolldaten zu implementieren. Alle sicherheitsrelevanten Ereignisse und Vorfälle müssen nachvollziehbar dokumentiert werden. Die Chain of Custody (Beweismittelkette oder Beweismittelüberwachung) ist durchgängig zu gewährleisten, um die gerichtliche Verwertbarkeit sicherzustellen. Die Dokumentation umfasst die Erfassung, Speicherung, Analyse und Weitergabe von Daten sowie die Identifikation verantwortlicher Personen und Prozesse. Im Falle eines Sicherheitsvorfalls sind forensische Analysen durchzuführen, um Ursache, Ablauf und Auswirkungen des Angriffs zu rekonstruieren. Die Systeme zur Angriffserkennung müssen Schnittstellen für die Extraktion und Analyse von Protokolldaten bereitstellen. Incident-Response-Prozesse sind so zu gestalten, dass forensische Anforderungen (z. B. unveränderte Datensicherung, schnelle Reaktionszeiten, Dokumentation aller Maßnahmen) erfüllt werden.
Protokollierungsdaten müssen manipulationssicher gespeichert werden, um die Integrität und Authentizität der Daten für forensische Analysen zu gewährleisten. Es sind Verfahren zur digitalen Signatur und zur sicheren Zeitstempelung der Protokolldaten zu implementieren. Alle sicherheitsrelevanten Ereignisse und Vorfälle müssen nachvollziehbar dokumentiert werden. Die Chain of Custody (Beweismittelkette oder Beweismittelüberwachung) ist durchgängig zu gewährleisten, um die gerichtliche Verwertbarkeit sicherzustellen. Die Dokumentation umfasst die Erfassung, Speicherung, Analyse und Weitergabe von Daten sowie die Identifikation verantwortlicher Personen und Prozesse. Im Falle eines Sicherheitsvorfalls sind forensische Analysen durchzuführen, um Ursache, Ablauf und Auswirkungen des Angriffs zu rekonstruieren. Die Systeme zur Angriffserkennung müssen Schnittstellen für die Extraktion und Analyse von Protokolldaten bereitstellen. Incident-Response-Prozesse sind so zu gestalten, dass forensische Anforderungen (z. B. unveränderte Datensicherung, schnelle Reaktionszeiten, Dokumentation aller Maßnahmen) erfüllt werden.
Zeile 31: Zeile 31:
Bei meldepflichtigen Vorfällen ist die Zusammenarbeit mit Behörden (z. B. BSI, BNetzA, Polizei) sicherzustellen. Die Übermittlung von Beweismaterial muss den gesetzlichen Vorgaben entsprechen. Die Verarbeitung und Speicherung von Protokolldaten muss unter Berücksichtigung datenschutzrechtlicher Vorgaben erfolgen. Lösch- und Speicherfristen sind einzuhalten, ggf. ist eine Anonymisierung oder Pseudonymisierung erforderlich.
Bei meldepflichtigen Vorfällen ist die Zusammenarbeit mit Behörden (z. B. BSI, BNetzA, Polizei) sicherzustellen. Die Übermittlung von Beweismaterial muss den gesetzlichen Vorgaben entsprechen. Die Verarbeitung und Speicherung von Protokolldaten muss unter Berücksichtigung datenschutzrechtlicher Vorgaben erfolgen. Lösch- und Speicherfristen sind einzuhalten, ggf. ist eine Anonymisierung oder Pseudonymisierung erforderlich.


'''''Systeme zur Angriffserkennung (SzA) bei SQL-Injektions'''''
'''Systeme zur Angriffserkennung (SzA) bei SQL-Injektions'''


Webanwendungen mit Datenbankanbindung bestehen typischerweise aus mehreren logisch getrennten Komponenten, darunter Webserver, Applikationslogik und Datenbanksystem.
Webanwendungen mit Datenbankanbindung bestehen typischerweise aus mehreren logisch getrennten Komponenten, darunter Webserver, Applikationslogik und Datenbanksystem.
Zeile 39: Zeile 39:
Die Umsetzung eines SzA basiert auf dem Prinzip der zentralen Ereignisaggregation. Die beteiligten Systemkomponenten bleiben in ihrer Funktion unverändert, liefern jedoch Protokolldaten, die für die Angriffserkennung und spätere Analyse genutzt werden. Dadurch wird es möglich, sicherheitsrelevante Vorgänge nicht isoliert auf einer einzelnen Systemebene zu betrachten, sondern im Zusammenhang des gesamten Systemverhaltens zu analysieren.
Die Umsetzung eines SzA basiert auf dem Prinzip der zentralen Ereignisaggregation. Die beteiligten Systemkomponenten bleiben in ihrer Funktion unverändert, liefern jedoch Protokolldaten, die für die Angriffserkennung und spätere Analyse genutzt werden. Dadurch wird es möglich, sicherheitsrelevante Vorgänge nicht isoliert auf einer einzelnen Systemebene zu betrachten, sondern im Zusammenhang des gesamten Systemverhaltens zu analysieren.


'''Protokolldaten als gemeinsame Datenbasis'''
''Protokolldaten als gemeinsame Datenbasis''


Ein SzA setzt voraus, dass sicherheitsrelevante Ereignisse zuverlässig erfasst und zentral gespeichert werden. Aus theoretischer Sicht handelt es sich hierbei um die Zusammenführung verteilter Systemzustände in eine gemeinsame, zeitlich konsistente Datenbasis.
Ein SzA setzt voraus, dass sicherheitsrelevante Ereignisse zuverlässig erfasst und zentral gespeichert werden. Aus theoretischer Sicht handelt es sich hierbei um die Zusammenführung verteilter Systemzustände in eine gemeinsame, zeitlich konsistente Datenbasis.
Zeile 55: Zeile 55:
Gleichzeitig bildet diese zentrale Logging-Basis die Grundlage für forensische Analysen, da sie eine nachvollziehbare Dokumentation des Systemzustands über einen längeren Zeitraum hinweg bereitstellt.
Gleichzeitig bildet diese zentrale Logging-Basis die Grundlage für forensische Analysen, da sie eine nachvollziehbare Dokumentation des Systemzustands über einen längeren Zeitraum hinweg bereitstellt.


'''Analyse und Korrelation sicherheitsrelevanter Ereignisse'''
''Analyse und Korrelation sicherheitsrelevanter Ereignisse''


Die Erkennung von SQL-Injektions erfolgt nicht durch die isolierte Betrachtung einzelner Logeinträge, sondern durch die Analyse von Mustern und Zusammenhängen innerhalb der gesammelten Ereignisdaten. Dieser Ansatz basiert auf der Annahme, dass Angriffe charakteristische Merkmale aufweisen, die sich in Protokolldaten widerspiegeln. Dies bedeutet, dass auffällige Web-Requests mit nachfolgenden Systemreaktionen in Beziehung gesetzt werden. Beispielsweise können ungewöhnliche Parameterinhalte in HTTP-Anfragen gemeinsam mit einer erhöhten Anzahl fehlerhafter Datenbankabfragen als Hinweis auf eine mögliche SQL-Injektion interpretiert werden.
Die Erkennung von SQL-Injektions erfolgt nicht durch die isolierte Betrachtung einzelner Logeinträge, sondern durch die Analyse von Mustern und Zusammenhängen innerhalb der gesammelten Ereignisdaten. Dieser Ansatz basiert auf der Annahme, dass Angriffe charakteristische Merkmale aufweisen, die sich in Protokolldaten widerspiegeln. Dies bedeutet, dass auffällige Web-Requests mit nachfolgenden Systemreaktionen in Beziehung gesetzt werden. Beispielsweise können ungewöhnliche Parameterinhalte in HTTP-Anfragen gemeinsam mit einer erhöhten Anzahl fehlerhafter Datenbankabfragen als Hinweis auf eine mögliche SQL-Injektion interpretiert werden.
Zeile 63: Zeile 63:
Aus forensischer Perspektive ist diese Korrelation von zentraler Bedeutung, da sie es ermöglicht, den zeitlichen Ablauf eines Angriffs nachzuvollziehen und Ursache-Wirkung-Beziehungen zwischen Web- und Datenbankereignissen herzustellen.
Aus forensischer Perspektive ist diese Korrelation von zentraler Bedeutung, da sie es ermöglicht, den zeitlichen Ablauf eines Angriffs nachzuvollziehen und Ursache-Wirkung-Beziehungen zwischen Web- und Datenbankereignissen herzustellen.


'''Klassifikation und Weiterverarbeitung erkannter Angriffshinweise'''
''Klassifikation und Weiterverarbeitung erkannter Angriffshinweise''


Wird ein Ereignis oder eine Ereigniskombination als potenzieller Angriff identifiziert, erfolgt im SzA eine entsprechende Klassifikation. In der Umsetzung bedeutet dies in der Regel die Kennzeichnung des Ereignisses als sicherheitsrelevant sowie dessen strukturierte Speicherung zur weiteren Auswertung.
Wird ein Ereignis oder eine Ereigniskombination als potenzieller Angriff identifiziert, erfolgt im SzA eine entsprechende Klassifikation. In der Umsetzung bedeutet dies in der Regel die Kennzeichnung des Ereignisses als sicherheitsrelevant sowie dessen strukturierte Speicherung zur weiteren Auswertung.
Zeile 71: Zeile 71:
Diese strukturierte Aufbereitung ist insbesondere im Hinblick auf forensische Untersuchungen relevant, da sie eine gezielte Auswahl und Priorisierung relevanter Ereignisse ermöglicht und die spätere Analyse nicht auf ungefilterten Rohdaten basiert.
Diese strukturierte Aufbereitung ist insbesondere im Hinblick auf forensische Untersuchungen relevant, da sie eine gezielte Auswahl und Priorisierung relevanter Ereignisse ermöglicht und die spätere Analyse nicht auf ungefilterten Rohdaten basiert.


'''Bedeutung des SzA für forensische Analysen'''
''Bedeutung des SzA für forensische Analysen''


Neben der laufenden Angriffserkennung erfüllt ein SzA eine wichtige unterstützende Funktion für die IT-Forensik. Durch die zentrale und zeitlich geordnete Speicherung sicherheitsrelevanter Ereignisse entsteht eine Ereignischronologie, die eine nachträgliche Rekonstruktion von Angriffsszenarien ermöglicht.
Neben der laufenden Angriffserkennung erfüllt ein SzA eine wichtige unterstützende Funktion für die IT-Forensik. Durch die zentrale und zeitlich geordnete Speicherung sicherheitsrelevanter Ereignisse entsteht eine Ereignischronologie, die eine nachträgliche Rekonstruktion von Angriffsszenarien ermöglicht.
Zeile 78: Zeile 78:


Das SzA fungiert damit als Bindeglied zwischen dem laufenden Systembetrieb und der forensischen Detailanalyse einzelner Systemkomponenten. Es ersetzt keine spezialisierte forensische Untersuchung, stellt jedoch den notwendigen Kontext bereit, um weiterführende Analysen zielgerichtet und effizient durchführen zu können.
Das SzA fungiert damit als Bindeglied zwischen dem laufenden Systembetrieb und der forensischen Detailanalyse einzelner Systemkomponenten. Es ersetzt keine spezialisierte forensische Untersuchung, stellt jedoch den notwendigen Kontext bereit, um weiterführende Analysen zielgerichtet und effizient durchführen zu können.
[[Datei:SzA-SQLi.png|zentriert|Systemschaubild eines SzA (Architektur) im Kontext von SQL-Injektions auf eine Webanwendung mit angebundenem Datenbanksystem]]
'''Quellen:'''
Bundesamt für Sicherheit in der Informationstechnik, Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Datum 18.11.2024: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/oh-sza.pdf?_blob=publicationFile&v=8

Aktuelle Version vom 10. April 2026, 12:21 Uhr

Systeme zur Angriffserkennung - Technische/technisch organisatorische und forensische Anforderungen gemäß BSIG

Systeme zur Angriffserkennung (SzA) sind zentrale Komponenten der IT-Sicherheitsarchitektur für Betreiber Kritischer Infrastrukturen. Sie ermöglichen die frühzeitige Identifikation und Abwehr von Angriffen auf informationstechnische Systeme und sind gemäß § 8a Abs. 1a BSIG verpflichtend einzusetzen. SzA sind durch technische Werkzeuge und organisatorische Prozesse unterstützte Systeme, die Angriffe durch den Abgleich von Systemdaten mit bekannten Angriffsmustern erkennen. Seit dem 1. Mai 2023 müssen Betreiber Kritischer Infrastrukturen den Einsatz solcher Systeme nach dem Stand der Technik nachweisen.

Technische Anforderungen

Die technischen Anforderungen gliedern sich in drei zentrale Bereiche:

• Protokollierung: Zentrale Erfassung und Speicherung aller sicherheitsrelevanten Protokoll- und Protokollierungsdaten. Die Daten müssen für die Auswertung gefiltert, normalisiert, aggregiert und korreliert werden. Die Protokollierungsinfrastruktur ist ausreichend zu dimensionieren und mit den notwendigen technischen, personellen und finanziellen Ressourcen auszustatten.

• Detektion: Kontinuierliche Überwachung und Auswertung der Protokollierungsdaten. Automatisierte Alarmierung bei sicherheitsrelevanten Ereignissen (SRE). Einsatz zusätzlicher Detektionssysteme (z. B. NIDS) an definierten Netzsegmenten. Einbindung und Bewertung externer Informationsquellen zur Aktualisierung der Angriffsmuster.

• Reaktion: Automatisierte oder manuelle Maßnahmen zur Behandlung und Abwehr von Sicherheitsvorfällen. Sicherstellung, dass bei Alarmen zeitnah und angemessen reagiert wird. Dokumentation und Nachweisführung aller ergriffenen Maßnahmen.

Protokollierung und Detektion

Die Protokollierungsdaten werden zentral im Security Operation Center gespeichert und ausgewertet. Die Infrastruktur umfasst einen zentralen Logserver und ein internes Logmanagement. Die Planung, Umsetzung und der Betrieb der Protokollierung folgen dem IT-Grundschutzbaustein OPS.1.1.5. Die Detektion orientiert sich am MITRE ATT&CK Framework und deckt alle relevanten Cyberbedrohungen ab. Advanced Detection Technology und NextGen Antivirus sorgen für die Erkennung von bösartigen Dateien, Prozessen und verdächtigen Aktivitäten. Threat Intelligence basiert auf einer Datenbank mit Millionen von IoCs (Indicators of Compromise), die von Drittanbietern und eigenen Untersuchungen stammen. Memory Protection erkennt Bedrohungen auf Kernel-Ebene und verhindert das Beenden von Schutzprozessen. AMSI (AntiMalware Scan Interface) Alerts erkennen bösartige Skriptbefehle. Die Protokolldaten werden kontinuierlich überwacht und ausgewertet, um bei sicherheitsrelevanten Ereignissen eine unmittelbare Alarmierung zu gewährleisten. Die Security-Analysten werden durch einen Dienstleister bereitgestellt.

Externe Informationsquellen und Patchmanagement

Um aktuelle Informationen zu Angriffsmustern zu erhalten, werden fortlaufend die technischen Vulnerabilitäten für die Systeme im Anwendungsbereich geprüft. Hierfür dienen nationale und internationale CERT-Meldungen, CVE-Listen, Hersteller-Webseiten als Grundlage. Die jeweiligen Empfänger der Informationen müssen diese sichten und auswerten. Ein zentrales Patchmanagement sorgt dafür, dass alle relevanten Systeme und Anwendungen auf dem aktuellen Stand gehalten werden.

Abhilfemaßnahmen

Für die Alarmtypen Host, File, Network und User existieren spezifische Abhilfemaßnahmen. Für Dateien können Maßnahmen wie Löschen, Download zur weiteren Investigation oder Quarantäne durchgeführt werden. Prozesse können beendet werden, ohne die Datei zu löschen. Für Netzwerke und Hosts sind Maßnahmen wie Herunterfahren, Neustart, Deaktivierung der Netzwerkschnittstellenkarte, Ausführung von Befehlen oder Skripten, Löschen oder Deaktivieren von Services und Tasks, Isolierung des Endpunkts, Öffnen einer Remote Shell, Blockierung von Netzwerkverbindungen und Wiederherstellung kompromittierter Dateien vorgesehen. Für User können Accounts deaktiviert oder aktiviert werden.

Forensische Anforderungen

Protokollierungsdaten müssen manipulationssicher gespeichert werden, um die Integrität und Authentizität der Daten für forensische Analysen zu gewährleisten. Es sind Verfahren zur digitalen Signatur und zur sicheren Zeitstempelung der Protokolldaten zu implementieren. Alle sicherheitsrelevanten Ereignisse und Vorfälle müssen nachvollziehbar dokumentiert werden. Die Chain of Custody (Beweismittelkette oder Beweismittelüberwachung) ist durchgängig zu gewährleisten, um die gerichtliche Verwertbarkeit sicherzustellen. Die Dokumentation umfasst die Erfassung, Speicherung, Analyse und Weitergabe von Daten sowie die Identifikation verantwortlicher Personen und Prozesse. Im Falle eines Sicherheitsvorfalls sind forensische Analysen durchzuführen, um Ursache, Ablauf und Auswirkungen des Angriffs zu rekonstruieren. Die Systeme zur Angriffserkennung müssen Schnittstellen für die Extraktion und Analyse von Protokolldaten bereitstellen. Incident-Response-Prozesse sind so zu gestalten, dass forensische Anforderungen (z. B. unveränderte Datensicherung, schnelle Reaktionszeiten, Dokumentation aller Maßnahmen) erfüllt werden.

Bei meldepflichtigen Vorfällen ist die Zusammenarbeit mit Behörden (z. B. BSI, BNetzA, Polizei) sicherzustellen. Die Übermittlung von Beweismaterial muss den gesetzlichen Vorgaben entsprechen. Die Verarbeitung und Speicherung von Protokolldaten muss unter Berücksichtigung datenschutzrechtlicher Vorgaben erfolgen. Lösch- und Speicherfristen sind einzuhalten, ggf. ist eine Anonymisierung oder Pseudonymisierung erforderlich.

Systeme zur Angriffserkennung (SzA) bei SQL-Injektions

Webanwendungen mit Datenbankanbindung bestehen typischerweise aus mehreren logisch getrennten Komponenten, darunter Webserver, Applikationslogik und Datenbanksystem.

Sicherheitsrelevante Ereignisse entstehen dabei auf unterschiedlichen Ebenen und zu unterschiedlichen Zeitpunkten. Ein SzA ist in diesem Kontext nicht als eigenständiges Subsystem zu verstehen, sondern als übergreifende Auswertungsschicht, die Informationen aus diesen Komponenten zusammenführt und analysiert.

Die Umsetzung eines SzA basiert auf dem Prinzip der zentralen Ereignisaggregation. Die beteiligten Systemkomponenten bleiben in ihrer Funktion unverändert, liefern jedoch Protokolldaten, die für die Angriffserkennung und spätere Analyse genutzt werden. Dadurch wird es möglich, sicherheitsrelevante Vorgänge nicht isoliert auf einer einzelnen Systemebene zu betrachten, sondern im Zusammenhang des gesamten Systemverhaltens zu analysieren.

Protokolldaten als gemeinsame Datenbasis

Ein SzA setzt voraus, dass sicherheitsrelevante Ereignisse zuverlässig erfasst und zentral gespeichert werden. Aus theoretischer Sicht handelt es sich hierbei um die Zusammenführung verteilter Systemzustände in eine gemeinsame, zeitlich konsistente Datenbasis.

In Webanwendungen mit Datenbankanbindung entstehen relevante Ereignisse unter anderem:

• bei der Verarbeitung von http-Requests auf Web-Ebene,

• während der Ausführung von Applikationslogik,

• bei der Verarbeitung von Datenbankabfragen und zugehörigen Fehlermeldungen.

Die zentrale Speicherung dieser Protokolldaten ermöglicht eine zeitlich geordnete Betrachtung des Systemgeschehens. Für die Angriffserkennung ist dies insbesondere deshalb relevant, weil SQL-Injektions häufig nicht in einem einzelnen Ereignis bestehen, sondern als Abfolge mehrerer zusammenhängender Aktionen auftreten.

Gleichzeitig bildet diese zentrale Logging-Basis die Grundlage für forensische Analysen, da sie eine nachvollziehbare Dokumentation des Systemzustands über einen längeren Zeitraum hinweg bereitstellt.

Analyse und Korrelation sicherheitsrelevanter Ereignisse

Die Erkennung von SQL-Injektions erfolgt nicht durch die isolierte Betrachtung einzelner Logeinträge, sondern durch die Analyse von Mustern und Zusammenhängen innerhalb der gesammelten Ereignisdaten. Dieser Ansatz basiert auf der Annahme, dass Angriffe charakteristische Merkmale aufweisen, die sich in Protokolldaten widerspiegeln. Dies bedeutet, dass auffällige Web-Requests mit nachfolgenden Systemreaktionen in Beziehung gesetzt werden. Beispielsweise können ungewöhnliche Parameterinhalte in HTTP-Anfragen gemeinsam mit einer erhöhten Anzahl fehlerhafter Datenbankabfragen als Hinweis auf eine mögliche SQL-Injektion interpretiert werden.

Die Korrelation mehrerer Ereignisse erhöht die Aussagekraft der Erkennung, da einzelne Auffälligkeiten auch durch legitimes Nutzerverhalten entstehen können.

Aus forensischer Perspektive ist diese Korrelation von zentraler Bedeutung, da sie es ermöglicht, den zeitlichen Ablauf eines Angriffs nachzuvollziehen und Ursache-Wirkung-Beziehungen zwischen Web- und Datenbankereignissen herzustellen.

Klassifikation und Weiterverarbeitung erkannter Angriffshinweise

Wird ein Ereignis oder eine Ereigniskombination als potenzieller Angriff identifiziert, erfolgt im SzA eine entsprechende Klassifikation. In der Umsetzung bedeutet dies in der Regel die Kennzeichnung des Ereignisses als sicherheitsrelevant sowie dessen strukturierte Speicherung zur weiteren Auswertung.

Theoretisch stellt dieser Schritt den Übergang von der reinen Ereignisanalyse zur Sicherheitsbewertung dar. Das SzA trifft dabei keine abschließende Aussage über die tatsächliche Wirksamkeit eines Angriffs, sondern stellt konsolidierte Informationen bereit, die für weiterführende Analysen genutzt werden können.

Diese strukturierte Aufbereitung ist insbesondere im Hinblick auf forensische Untersuchungen relevant, da sie eine gezielte Auswahl und Priorisierung relevanter Ereignisse ermöglicht und die spätere Analyse nicht auf ungefilterten Rohdaten basiert.

Bedeutung des SzA für forensische Analysen

Neben der laufenden Angriffserkennung erfüllt ein SzA eine wichtige unterstützende Funktion für die IT-Forensik. Durch die zentrale und zeitlich geordnete Speicherung sicherheitsrelevanter Ereignisse entsteht eine Ereignischronologie, die eine nachträgliche Rekonstruktion von Angriffsszenarien ermöglicht.

Im Zusammenhang mit SQL-Injektions erlaubt diese Chronologie insbesondere die Untersuchung, ob verdächtige Web-Anfragen lediglich Angriffsversuche darstellten oder zu tatsächlichen Datenbankinteraktionen führten. Die gemeinsame Betrachtung von Web- und Datenbankprotokollen ermöglicht es, Angriffspfade nachzuvollziehen und deren Auswirkungen besser einzuordnen.

Das SzA fungiert damit als Bindeglied zwischen dem laufenden Systembetrieb und der forensischen Detailanalyse einzelner Systemkomponenten. Es ersetzt keine spezialisierte forensische Untersuchung, stellt jedoch den notwendigen Kontext bereit, um weiterführende Analysen zielgerichtet und effizient durchführen zu können.

Systemschaubild eines SzA (Architektur) im Kontext von SQL-Injektions auf eine Webanwendung mit angebundenem Datenbanksystem
Systemschaubild eines SzA (Architektur) im Kontext von SQL-Injektions auf eine Webanwendung mit angebundenem Datenbanksystem


Quellen: Bundesamt für Sicherheit in der Informationstechnik, Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Datum 18.11.2024: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/oh-sza.pdf?_blob=publicationFile&v=8