IT-Forensik Wiki - Benutzerbeiträge [de]

Systeme zur Angriffserkennung

2026-04-10T12:21:18Z

St180824:

'''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.

[[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

Systeme zur Angriffserkennung

2026-04-10T12:08:40Z

St180824:

Datei:SzA-SQLi.png

2026-04-10T12:07:28Z

St180824:

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

Systeme zur Angriffserkennung

2026-04-10T12:01:44Z

St180824:

Systeme zur Angriffserkennung

2026-04-10T10:32:32Z

St180824:

'''''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.

Systeme zur Angriffserkennung

2026-04-10T10:28:04Z

St180824:

'''''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.

'''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.

'''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.

'''''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.

Systeme zur Angriffserkennung

2026-04-10T10:23:44Z

St180824: Die Seite wurde neu angelegt: „'''''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 We…“

'''''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.

'''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.

'''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.

'''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.

'''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.

'''''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.

Hauptseite

2026-04-10T10:05:03Z

St180824: /* S */

Willkommen auf dem IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur aktuell ==
Roderich Obenaus, Marco Beck: '''Forensische Herausforderungen dezentraler Netzwerke: Eine vergleichende Analyse von ZeroNet und Tor Hidden Services''', Projektarbeit, Studiengang Bachelor "IT-Forensik", WINGS - Hochschule Wismar, Juni 2025,
[[Media:ProjektII-Obenaus-Beck.pdf|Download PDF-Dokument]]

== Literatur Übersichten ==

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Projektarbeiten]]

[[Forensik in DB]]

Antje Raab-Düsterhöft: [https://www.amazon.de/Forensik-Ein-Grundkurs-Antje-Raab-D%C3%BCsterh%C3%B6ft/dp/3662690896/ref=sr_1_1?crid=3R1C68K8I9D7G&dib=eyJ2IjoiMSJ9.uiOyjCoCVNBEDxYi_UywKURV45hgfjLaOTGRLZmHb3vTptUnwBld6SqiBl8NXzOVGk9f43125KCwp7Gnnf2gf8pTQI1Kis9kH_dZvoE4j1kz8G9RvagRT IT-Forensik - Ein Grundkurs. Springer Verlag, November 2024], ([https://link.springer.com/book/10.1007/978-3-662-69090-1 digitale Version])

[[Christian Peter (MT)]]: '''Einsatz von Open Source Software für die forensische Sicherung und Analyse von iOS und dessen Derivaten auf verschiedenen Apple-Geräten'''. Master Thesis, Hochschule Wismar, Mai 2025

Artikel [https://t3n.de/news/digitale-verbrechen-was-macht-eigentlich-ein-it-forensiker-1629195/?utm_source=rss&utm_medium=feed&utm_campaign=t3n-news "Digitale Verbrechen: Was macht eigentlich ein IT-Forensiker?"] 10.6.2024

== Stichworte IT-Forensik ==
=== A ===
[[ACPO]]

[[Adware]]

[[Aggregation]]

[[AmCache]]

[[Angriffe auf Forensik-Software]]

[[Anti-Forensik]]

[[Anwendungsarchitektur]]

[[Arbeitsspeicher]]

[[Asset Relocation]]

[[APT]]

[[Autopsy]]

[[Alternative Data Stream (ADS)]]

=== B ===
[[BBED]]

[[Betriebssystem]]

[[Bitlocker]]

[[Blacklisting]]

[[BLOB]]

[[BlockchainForensik|Blockchain Forensik]]

[[Blockchainbasierte Datenbank]]

[[Broken Authentication]]

[[Brute Force]]

[[BSI-Vorgehensmodell]]

[[Bundesdatenschutzgesetz (BDSG)]]

[[BurpSuite]]

=== C ===
[[Cache]]

[[Canarytoken]]

[[CERT-Taxonomie]]

[[Chain of Custody]]

[[Cheat Engine]]

[[Checkliste IT-Forensik für Unternehmen]]

[[Chip-Off]]

[[Clickjacking]]

[[Cloud Log Forensik]]

[[Cold Backup]]

[[Command-and-Control-Server]]

[[Computer Sabotage]]

[[Containervirtualisierung]]

[[Cookies]]

[[Cross Site Request Forgery (CSRF)]]

[[Cross Site Scripting (XSS)]]

[[CryptoLocker]]

[[CSA - Cloud Security Alliance]]

[[CTI - Cyber Threat Intelligence]]

[[CVE - Common Vulnerabilities and Exposures]]

[[Cybercrime]]

=== D ===
[[Darknet]]

[[Dateiheader]]

[[Datenanalyse]]

[[Datenbank Firewall]]

[[Datenbankausführungsplan]]

[[Datenbankforensik]]

[[Datenreduktion]]

[[Datensammlung]]

[[Datenschutz in der IT-Forensik]]

[[Datenvernichtung]]

[[Datenverschleierung]]

[[DDL & DML]]

[[Deep Packet Inspection]]

[[Deep Web]]

[[Diamond-Modell]]

[[Wörterbuchangriff|Dictionary Attack]]

[[Diff]]

[[Digitale Artefakte]]

[[Digitale Forensik]]

[[DLL (.dll Dateien)]]

[[DLP]]

[[DNS-Spoofing]]

[[DNS-Tunneling]]

[[Dokumentation]]

[[DoS & DDoS]]

[[Doxing]]

[[.DS-Store]]

[[Dual Use Software]]

[[Dumpster Diving]]

[[Dynamische Analyse]]

=== E ===
[[E-Mail-Header]]

[[E-Mail-Verschlüsselung und Signatur in der IT-Forensik]]

[[eDiscovery]]

[[Egg Hunting]]

[[ENISA]]

[[Ermittlungsprozess]]

[[Error Based SQL Injection]]

[[Exchangeable Image File Format (EXIF)]]

[[Exploit]]

=== F ===
[[File Carving]]

[[Fileless Malware]]

[[Fingerprinting (Browser)]]

[[Fingerprinting (Betriebssystem)]]

[[Flash Speicher]]

[[Flüchtige Daten]]

[[Footprinting]]

[[Forensik]]

[[Forensic Data Mining]]

[[Forensic Readiness]]

[[Forensische Duplikation]]

[[Forensischer Koffer]]

[[Fragmentierung]]

[[Fuzzing]]

=== G ===
[[Geotag]]

[[GeoIP-Datenbank]]

[[Gerichtsfestigkeit]]

[[Google Hacking]]

[[GrapheneOS]]

=== H ===
[[Hackback]]

[[Hardware-Sicherheitsmodul]]

[[Hashcat]]

[[Hashwert]]

[[hiberfil.sys]]

[[Hilfstatort]]

[[Honeypot]]

[[Human Interface Device (HID)]]

=== I ===
[[ICMP - Internet Control Message Protocol]]

[[Identitätsanbieter]]

[[IDS - Intrusion Detection System]]

[[Image]]

[[Imaging]]

[[IMSI-Catcher]]

[[Incident-Response-Team]]

[[Indicator of Compromise]]

[[Inline (Queries) SQL Injection]]

[[Integrität]]

[[IT-Forensik]]

[[IT-Forensiker]]

[[IT-Forensisches Gutachten]]

[[IPS - Intrusion Prevention System]]

=== J ===
[[Jailbreak]]

[[John the Ripper]]

[[Journaling-Dateisystem]]

[[Juice Jacking]]

[[Jump Lists]]

=== K ===

[[Installieren eines Live-Kali-Linux-System auf USB-Stick|Kali-Linux-Live-System auf USB-Stick installieren]]

[[Kaltstartattacke]]

[[Kausalität in der Forensik]]

[[Key Derivation Function]]

[[Kerberos]]

[[Keystroke Injection Attack Tool]]

[[Korrelation]]

[[Keylogger]]

=== L ===
[[Lateral Movement]]

[[LDAP-Injection]]

[[Litigation Hold]]

[[Live-Forensik]]

[[Local file inclusion]]

[[Locard'sche Regel]]

[[Lockheed Martin Cyber Kill Chain]]

[[Log-File]]

[[LogMining]]

[[Logical Volume Manager (LVM)]]

=== M ===
[[MACtime]] (Modification, Access, Change)

[[Magnet Axiom]]

[[Makrovirus]]

[[Malware]]

[[Malware-Klassen]]

[[MariaDB-Audit-Plugin|MariaDB Audit Plugin]]

[[Memory Forensics]]

[[Metadaten]]

[[Mobiltelefon-Forensik]]

[[Metadata Carving]]

=== N ===
[[Netcat]]

[[Netflow]]

[[Never-Touch-Original]]

[[Nmap]]

[[NTFS]]

[[Nutzdaten]]

=== O ===
[[OCR]]

[[Online-Forensik]]

[[Offline-Forensik]]

[[Ontologie & Semantik]]

[[Oracle DB]] (Forensische Aspekte)

[[Order of Volatility]]

[[OSINT]]

[[OSINT-Werkzeug]]

[[Out-of-Band]]

=== P ===
[[Pass-the-Hash-Attack]]

[[Passwortsicherheit]]

[[Payload]]

[[Partition]]

[[PCMCIA]]

[[Penetrationstest]]

[[PhotoDNA]]

[[Public Key Infrastructure (PKI)|PKI]]

[[Plausible Deniability]]

[[PostgreSQL Command Execution]]

[[Post-Mortem-Analyse]]

[[Prepared Statement]]

[[Privilege Escalation]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[Public Key Infrastructure (PKI)|Public Key Infrastructure]]

[[Purview eDiscovery (Microsoft)]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[PIC]]

=== Q ===

[[Query Log]]

[[QRT: Quick Reaction Team]]

[[QRT: Quick Response Team]]

=== R ===

[[Radare 2 - Reverse Engineering Framework]]

[[Rainbow Table]]

[[Ransomware]]

[[Privilege_Escalation|Rechteausweitung]]

[[Redo Logs]]

[[Registry]]

[[Remote Access Trojaner (RAT)]]

[[Replay Attack]]

[[Reverse Engineering]]

[[Rogue Access Point & Evil Twin]]

[[Rootkit]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Schwachstelle]]

[[Security Information and Event Management (SIEM)]]

[[Security Operations Center (SOC)]]

[[Seitenkanalattacke]]

[[Semantik]]

[[Server Side Request Forgery]]

[[Shellbags]]

[[ShimCache]]

[[Sigma]]

[[Skimming]]

[[Skript-Kiddie]]

[[Slack Space]]

[[Sleuthkit]]

[[Smishing]]

[[Sparse Image]]

[[Stack-basierte Buffer-Overflow Angriffe in Microsoft Windows]]

[[Statische Analyse]]

[[Sniffing]]

[[Sealbag]]

[[Secure Erase]]

[[Server Side Request Forgery]]

[[SpiderFoot]]

[[Spuren]]

[[SQL Injection]]

[[SQL Stored Procedures]]

[[SQLite Datenbanken auslesen mittels Python]]

[[Sqlmap]]

[[SSL Inspection]]

[[Steganographie]]

[[Steghide]]

[[Supply Chain Attack]]

[[Systeme zur Angriffserkennung]]

=== T ===
[[Tatort]]

[[Team Win Recovery Project]]

[[Threat Intelligence]]

[[Thumbnail Cache unter Windows]]

[[Thunderspy]]

[[Timeline]]

[[Triage]]

[[Trigger in DBMS]]

[[Trugspur]]

[[Tsurugi-Linux]]

[[Totmannschalter]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]<br>
[[UNION Based SQL Injection]]

=== V ===
[[Verfügbarkeit]]

[[Vertraulichkeit]]

[[Vertraulichkeit in Datenbanksystemen]]

[[VPN]]

[[Volume Shadow Copies]]

[[Vorsorge für die IT-Forensik]]

[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Warm-Boot-Angriff]]

[[Watering-Holes]]

[[Web-Application-Firewall]]

[[Whitelisting]]

[[Why-Because-Analyse (WBA)]]

[[Windows-RAM auslesen]]

[[Windows-Papierkorb]]

[[Windows-Prefetch]]

[[Wiping]]

[[Wireshark]]

[[Write Blocker]]

[[Wörterbuchangriff]]

[[Worm]]

=== X ===
[[Xmount]]

[[X-Ways]]

=== Y ===
[[Yara Regeln]]

=== Z ===
[[Zeit]]

[[Zeitstempel]]

[[Zeitbasierte SQL Injection Attacken]]

[[Zenmap]]

[[Zero-Day-Exploit]]

[[Ziele einer forensischen Untersuchung nach A. Geschonneck]]

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://www.wings.hs-wismar.de/de/fernstudium_bachelor/it_forensik IT-Forensik, Bachelor]

[https://www.wings.hs-wismar.de/de/fernstudium_master/it_sicherheit_und_forensik/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]