© Kitti Kahotong / 123rf.com

Das nach einem Raubsaurier benannte Open-Source-Tool Velociraptor steht im Zentrum einer Lösung, die Cybergefahren in industriellen Umgebungen automatisiert erkennt und abwehrt. Auch kritische Infrastrukturen lassen sich damit schützen.

Im Cyberspace geht es sehr dynamisch zu: Immer neue Angriffsvektoren kommen ans Licht, etwa die Infiltration der Lieferketten von Softwareprodukten wie beim SolarWinds-Vorfall oder der Diebstahl eines Master-Keys für Microsoft-Cloud-Dienste. Solche Bedrohungen machen selbst vor kritischen Infrastrukturen (KRITIS) nicht halt. So erscheint es beinahe unvermeidlich, dass es früher oder später auch dort zu einem IT-Ausfall durch einen Cyberangriff kommt. Beispielsweise konnte der Landkreis Anhalt-Bitterfeld 2021 nach einer Cyber-Attacke für 157 000 Bürger keine Sozialleistungen mehr auszahlen und musste die Arbeit für zweieinhalb Wochen größtenteils einstellen. Der Gesetzgeber greift daher regulativ ein und schreibt Zertifizierungen wie ISO 27001 und Methoden wie den IT-Grundschutz vor.

Anpassung an die Gefahr

Wir beschreiben hier einen adaptiven Ansatz, der die Verteidigung der KRITIS dynamisch an der Bedrohungslage ausrichtet. Dazu kombiniert er Informationen der Cyber Threat Intelligence (CTI) mit Methoden der adaptiven Live-Forensik. Dadurch lässt sich der Angriff schnell erkennen und die Sicherheitsmaßnahmen kurzfristig anpassen.

Wir verwenden in diesem Zusammenhang die MITRE-ATT&CK-Wissensbasis [1] im Kontext CTI sowie das Open-Source-Tool Velociraptor [2] als Werkzeug der Digital Forensics and Incident Response (DFIR). Velociraptor ermöglicht eine detailliertere und damit verbesserte Sicht auf den Status der beobachteten Endpunkte des Systems. Das Framework bietet eine vorinstallierte Liste mit sogenannten Artefakten, die man an zentraler Stelle konfiguriert und auf den Endpunkten ausführt. Die Abfragen lassen sich zudem individuell mit der nativen Abfragesprache Velociraptor Query Language (VQL) erstellen.

Wir arbeiten dabei in einer Testumgebung. Kritische Infrastrukturen weisen heute verschiedene Netzwerkbereiche auf. So werden operative Technologien (OT) in der Produktion eingesetzt, wo es gilt, Sensoren und Aktoren für die automatisierte Fertigung zu steuern. Ein OT- und Kontrollnetzwerk wird sorgsam durch eine Firewall vom eingesetzten IT-Management-Netzwerk getrennt. Zu den weiteren Bereichen zählt das Netzwerk des Security Operation Center (SOC), das wichtige Funktionen zur Überwachung bereitstellt. Daneben gibt es eine demilitarisierte Zone, die unter anderem die E-Mail-Kommunikation sichert und das Einbinden externer Cloud-Dienste ermöglicht. In diesem Beitrag konzentrieren wir uns auf eine typische Komponente eines OT-Kontrollnetzwerks: Programmable Logic Controller (PLC) kontrollieren und steuern dort industrielle Abläufe in der Fertigung.

Anhand eines ausgewählten Advanced Persistent Threat (APT) der Operational Technology (OT) zeigen wir exemplarisch, wie das effektive Zusammenwirken zur Detektion funktioniert. Man kann davon ausgehen, dass der ausgewählte APT derzeit auch in der Ukraine und in Westeuropa eingesetzt wird, sodass sich unser Beispiel auf eine aktuelle und tatsächliche Gefahr für KRITIS bezieht.

Beispiel Sandworm-Team

Als Fallbeispiel betrachten wir die APT-Gruppe Sandworm. Man geht davon aus, dass sie derzeit aktiv mit Cyberangriffen gegen kritische Infrastrukturen in das Kriegsgeschehen in der Ukraine eingreift. Das Sandworm-Team wird dem russischen Militärnachrichtendienst zugeordnet und für die Angriffe gegen die Energieversorgung in der Ukraine 2015/2016 sowie den globalen Angriff mit dem Virus NotPetya verantwortlich gemacht. 2018 ging der Angriff gegen die Organisation for the Prohibition of Chemical Weapons (OPCW) in Den Haag auf das Konto dieser Gruppe.

Das Verhalten dieser Gruppe lässt sich unter Zuhilfenahme der ICS-Matrix der MITRE-ATT&CK-Wissensbasis eingehend studieren. In der MITRE-ATT&CK-Nomenklatur bezeichnet Tactics die Ziele des Angreifers (das Warum eines Angriffsschritts), während Techniques zugehörige, grundlegende Vorgehensweisen (das Wie) beschreibt. In unserem Fallbeispiel betrachten wir die Fähigkeiten der Gruppe zu Angriffen gegen die sogenannte Operational Technology.

Die ICS-Matrix weist Angriffsvektoren gegen OT aus. Zusätzlich liefern zahlreiche Webseiten der Wissensbasis ergänzende Informationen. Über Github steht eine passende Browser-Anwendung zur Verfügung: Der sogenannte Navigator [3] erlaubt es, die Daten der ICS-Matrix interaktiv zu durchforsten, zu filtern, zu markieren und die Ergebnisse zu speichern. So erhält man einen guten ersten Einblick in den Datenbestand. Für tiefergehende Analysen lassen sich die Daten der MITRE-Datenbank über die mitgelieferte Python-API [4] auslesen und mit Business-Intelligence-Werkzeugen analysieren.

Abbildung 1 stellt den Angriffsvektor des Sandworm-Teams dar. Die bekannten Schadcodes KillDisk, Industroyer2 und BlackEnergy werden zur Ausführung einiger MITRE-Techniques eingesetzt, die nicht unmittelbar zum Angriffsvektor der Sandworm-Gruppe zählen. Damit muss man jederzeit auch mit der Ausführung dieser Techniques rechnen, zum Beispiel begleitend zum eigentlichen Angriff als Ablenkungs- oder Störmaßnahme. In der Abbildung sind mögliche Angriffstechniken dieser Gruppe markiert, und zwar sowohl im Zug eines Hauptangriffs als auch möglicher flankierender Attacken.

Abbildung 1: Der Angriffsvektor des Sandworm-Teams im Überblick.

Die Fähigkeiten des Sandworm-Teams schlagen sich in nahezu allen Tactics der ICS-Matrix nieder. Die Gruppe setzt mehrere Techniques ein, um ihre Ziele zu erreichen. In der Phase Tactic — Initial Access setzt die Gruppe die Technique Spearphishing Attachment ein. Dabei versenden die Angreifer individuell maßgeschneiderte E-Mails mit im Anhang integrierter Schadsoftware. Beim Öffnen des Anhangs wird der Zugang zum System erschlichen. Die notwendigen Informationen, um eine Nachricht so suggestiv zu formulieren, dass der Empfänger den Anhang prompt öffnet, erhält die Gruppe aus Social-Engineering-Aktivitäten.

Tactics

In der Phase Tactic — Execution setzen die Angreifer die Technique Scripting ein. Sie schleusen Skripte in die kritische Infrastruktur ein und nutzen dann vorhandene Interpreter, um die Skripte auf dem Zielsystem auszuführen. Nach dem Etablieren des Zugangs zum Zielsystem wird der Skript-Interpreter missbraucht, um zur Laufzeit des Angriffs bösartige Skripte auszuführen und bei Bedarf neue maliziöse Skripte im Zielsystem zu erstellen.

Im weiteren Verlauf des Angriffs setzt die Gruppe reguläre Protokolle ein, um detaillierte Informationen über das Zielsystem zu erlangen. Beispielsweise werden die Systeminfrastruktur und die Netzwerkarchitektur aufgeklärt. Dazu kommt in der Phase Tactic — Discovery die Technique Remote System Information Discovery zum Einsatz. Entsprechende Funktionen stellt unter anderem die Schadsoftware Industroyer2 bereit.

Nach der Aufklärung des Zielsystems manövriert die Gruppe durch die einzelnen Teilsysteme und weitet den Zugang auf weitere Teilbereiche aus. In der Phase Tactic — Lateral Movement nutzen die Angreifer die Technique Remote Services, um sich zwischen einzelnen Assets und Netzwerk-Segmenten zu bewegen. Im Zielsystem vorhandene Dienste wie RDP, SMB, SSH werden zum Remote-Zugriff auf Daten und deren Transfer zwischen Segmenten eingesetzt. Gegebenenfalls verändern die Angreifer sogar Konfigurationen der Managementsysteme und Arbeitsstationen oder laden weiteren Schadcode herunter und führen ihn auf Endgeräten der kritischen Infrastruktur aus.

Zu guter Letzt erzeugt die Gruppe Wirkung in der kritischen Infrastruktur, indem sie in der Phase Tactic — Impact die Technique Loss of View einsetzt. Dadurch kann es zu einem anhaltenden oder dauerhaften Verlust der Sicht auf den Status des ICS-Systems kommen. Der aktuelle Betriebszustand wird also effektiv verborgen. Das verhindert, dass der Bediener eingreift, und es kommt dadurch zu Schäden am System.

Die Sandworm-Gruppe setzt verschiedene Arten von Malware ein, darunter die Schadprogramme KillDisk, Industroyer2 und BlackEnergy. KillDisk überschreibt Speicherbereiche des Betriebssystems mit zufälligen Bytes, sodass sich das Betriebssystem im Anschluss nicht mehr starten lässt. Industroyer2 unterstützt das IEC-104-Protokoll aus dem SCADA-Umfeld. Das Kürzel SCADA steht für Supervisory Control and Data Acquisition, ein Steuerungssystem, das Daten von Industrieanlagen erfasst, analysiert und visualisiert.

IEC 104 ist das am häufigsten eingesetzte Kommunikationsprotokoll, um zu überwachenden SCADA-Systemen periodisch Daten wie zum Beispiel Statusinformationen zuzusenden sowie Ereignisse mitzuteilen. Es nutzt Ethernet und TCP/IP zur Kommunikation. Mit diesem Protokoll lassen sich Kriterien zur Auslösung von Ereignissen sowie periodisch zu meldende Grundgrößen konfigurieren. Damit kann man über dieses Protokoll Fernwirkung auf SCADA-Systeme ausüben.

Abhilfe durch Überwachung

Das BSI-Gesetz verlangt, die zur Angriffserkennung eingesetzten Systeme anhand geeigneter Parameter im laufenden Betrieb kontinuierlich und automatisch zu überwachen. Sie sollen fortwährend in der Lage sein, Bedrohungen zu identifizieren und zu vermeiden sowie geeignete Gegenmaßnahmen einzuleiten, wenn Störungen auftreten. Mit diesem Ziel wirkt der Anwender den identifizierten Tactics und Techniques der Sandworm-Gruppe entgegen. Um zu verstehen, wie sich dieses Ziel erreichen lässt, testen wir zunächst verfügbare Funktionen des Velociraptor-Frameworks anhand einzelner Techniques.

Wir beginnen mit der ersten Phase des Angriffs, Tactics — Initial Access. Sandworm setzt unter anderem die Technique T0865 Spearphishing unter Zuhilfenahme der Schadsoftware S0089 BlackEnergy ein. Die Angreifer verpacken den Schadcode als Eintrag in ein maliziöses Word-Dokument, das sie als Anhang einer E-Mail versenden. Sobald der Empfänger den Anhang öffnet, wird der Schadcode ausgeführt. In einem Github-Repository [5] findet sich eine Yara-Regel, die diesen Vorgang detektiert (Listing 1). Das Tool Yara kann Malware identifizieren und klassifizieren.

Rule BlackEnergy
{
  meta:
    description = "Detects VBS Agent from BlackEnergy Report - file Dropbearrun.vbs"
    author = "Florian Roth"
    reference = "http://feedproxy.google.com/~r/eset/blog/~3/BXJbnGSvEFc/"
    date = "2016-01-03"
    hash = "b90f268b5e7f70af1687d9825c09df15908ad3a6978b328dc88f96143a64af0f"
  strings:
    $s0 = "WshShell.Run \"dropbear.exe -r rsa -d dss -a -p 6789\", 0, false" fullword ascii
    $s1 = "WshShell.CurrentDirectory = \"C:\\WINDOWS\\TEMP\\Dropbear\\\"" fullword ascii
    $s2 = "Set WshShell = CreateObject(\"WScript.Shell\")" fullword ascii /* Goodware String - occured 1 times */
  condition:
    filesize < 1KB and 2 of them
}

Mithilfe des Velociraptor-Frameworks führen wir diese Yara-Regel auf allen angeschlossenen Arbeitsplatzrechnern aus. Die Ausführung kann kontinuierlich und zeitlich parallel erfolgen. Dazu integriert man den Velociraptor-Server in die Infrastruktur und konfiguriert ihn für die Zielumgebung. Im Anschluss verteilt man Agenten auf die Endpunkte. Über die Verbindung mit dem Agenten lassen sich Abfragen auf einzelnen oder mehreren Endpunkten gleichzeitig ausführen. Die dadurch entstehenden Artefakte werden dann zum Server hochgeladen und dort gesichert (Abbildung 2).

Abbildung 2: Der Aufbau der Velociraptor-Architektur.

Die Administration des Velociraptor-Servers erfolgt über eine Weboberfläche für den Administrator. Dieses Interface bietet Funktionen, um die Dateisysteme der Endpunkte zu durchforsten sowie Kommandos auf den Endpunkten auszuführen. Zudem werden an dieser Stelle ständige Abfragen zusammengestellt und terminiert.

Zum Ausführen der Regel dient die Skriptsprache VQL (Listing 2). Yara-Regeln ermöglichen es grundsätzlich, auf Basis von Signaturen Schadcode in Dateisystemen und im Kontext von Prozessen aufzuspüren. Tauscht man die Regel aus, lässt sich auf dieselbe Weise andere Schadsoftware detektieren. Es gibt unter anderem auch Yara-Regeln für KillDisk und Industroyer2.

LET Yararule = '''rule Name {...}'''
----------------- File Detection -----------------
LET Globs = 'C:/Users/**'
SELECT * FROM foreach(row={
   SELECT FullPath FROM glob(globs=Globs)
}, query={
   SELECT str(str=String.Data) As Hit,
   String.Offset As Offset,
   Filename FROM yara(accessor="file", files=FullPath, rules=Yararule)
})
LIMIT 50

Abschließend lässt sich die VQL-Abfrage in ein Artefakt umwandeln. Dazu bietet das Framework ein Template, das man mit VQL-Ausdrücken ausfüllt. Alternativ stehen vorgefertigte Artefakte zur Verfügung. Wir haben dieses Artefakt in eine kontinuierliche Abfrage überführt, einen sogenannten Hunt. Er wird potenziell auf allen verbundenen Endpunkten ausgeführt. Über die Administrationsoberfläche lässt sich das Vorgehen konfigurieren und steuern.

Dieses erste Beispiel demonstriert die grundsätzlichen Funktionen zum kontinuierlichen Überwachen eines vernetzten Systems.

Industriesteuerungen

Ein Programmable Logic Controller (PLC) steuert gemäß bestimmter Algorithmen Anlagen und Maschinen in der Produktionsumgebung. Im Einsatz durchlaufen PLCs einen stetigen Prozesskreislauf. Ihre Programmierung erfolgt mit spezifischen Programmiersprachen, die der Standard IEC 61131 [6] beschreibt: Instruction List (IL), Ladder Diagram (LD), Functional Block Diagram (FBD), Sequential Functional Chart (SFC), Structured Text (ST). Die Sprachen IL und ST sind textbasiert, die anderen (LD, FBD und SFC) grafisch ausgeprägt. In allen Sprachen lassen sich Funktionen und Funktionsblöcke verwenden. Blöcke können in einer der anderen Sprachen geschrieben oder vom PLC-Hersteller als Softwarebibliotheken zur Verfügung gestellt werden. Manche Hersteller stellen Quellcode bereit, andere legen ihn nicht offen.

Abbildung 3 zeigt exemplarisch ein Programm in der grafisch ausgeprägten Sprache Ladder Diagram (LD). Es bildet den Datenfluss eingehender Daten über eine logische Verarbeitung zu einem Ausgabedatum ab. Wird der Eingangskontakt In1 geschlossen, fließen die Daten zum Ausgangspunkt Out1, der sich daraufhin öffnet und die Daten ausgibt. Denselben Vorgang kann man textbasiert mit der Programmiersprache ST ausdrücken. Beide Programme sind intuitiv zu verstehen und leicht nachzuvollziehen.

Abbildung 3: Ein einfaches Beispiel für ein Programm in der Sprache Ladder Diagram im Editor.

Diese recht theoretische Betrachtung macht bereits das Plus an Flexibilität deutlich, das ein PLC gegenüber den zuvor eingesetzten physischen Relais bietet. Über die Programmierschnittstellen kann man die logischen Abläufe entsprechend der Aufgabe gestalten. Dadurch ergeben sich allerdings potenzielle Angriffspunkte: Die Programmierung könnte verändert werden, oder jemand könnte die Variablen modifizieren oder Softwarebibliotheken austauschen. Der Angreifer könnte Logfiles manipulieren oder löschen, Eingangs- oder Ausgangssignale blockieren oder Seitenkanalangriffe starten, indem er beispielsweise die Stromversorgung unterbricht. Wir überprüfen im nächsten Schritt, in welcher Weise sich die Sandworm-Gruppe diese oder weitere Angriffspunkte zunutze macht.

Durch Auswerten der Daten der MITRE-ATT&CK-for-ICS-Wissensbasis (Version 14) haben wir eine Übersicht aller Techniques erzeugt, die das Sandworm-Team verwendet und die sich gegen PLCs richten. Dazu wählten wir alle Assets aus, die einen Eintrag PLC aufweisen, und filterten das Attribut source name nach der Gruppe Sandworm Team. Diese Auswahl bewerkstelligen wir mit der Python-Schnittstelle und Python-Panda-Datenstrukturen. Als Ergebnis erhielten wir alle Techniques, die Sandworm gegen PLCs einsetzt.

Die verwendeten Angriffstechniken betreffen vier Tactics des Angriffsvektors: Execution, Lateral Movement, Inhibit Response Function und Impair Process Control. Die vier Angriffstechniken T0803 (Block Command Message), T0804 (Block Report Message), T0816 (Device Restart/Shutdown) sowie T0857 (System Firmware) sind der Phase Inhibit Response Function zugeordnet (siehe Tabelle “Techniques gegen PLCs”). Ihre Ausführung beeinträchtigt die korrekte Funktion des PLC, seine Antworten werden abgeblockt.

Für jede dieser Techniques weist das MITRE-ATT&CK-Framework Möglichkeiten zu deren Detektion aus, inklusive relevanter Datenquellen. Zukünftig wird man den Zusammenhang zwischen Technique und Datenquellen noch intuitiver visuell abrufen können. Dazu arbeiten die MITRE-Forscher gerade im Beta-Stadium an einem Wissensgraph mit dem Namen MITRE DEFEND.

Das Monitoring der ausgewiesenen Datenquellen setzen wir jetzt mit dem Velociraptor-Framework um. Mit der Software OpenPLC [7] lässt sich eine Testumgebung aufbauen, um die Funktion des PLC zu simulieren. Die Codebasis umfasst zahlreiche Dateien. Beispielsweise ist die Anwendung »PLC.so« als Shared Library kompiliert, sodass man die Anwendung in den Laufzeitkontext des PLC laden, dort vom Hauptprogramm »plc\_main« aus aufrufen und ausführen kann. Beim Kompilieren wird ein MD5-Hash-Wert generiert und in der Datei »lastbuildPLC.md5« gespeichert. Die zuvor in der Editierumgebung konfigurierten Variablen liegen in der Datei »VARIABLES.csv«. Den Algorithmus haben wir durch den Compiler in ST übersetzt und in der Datei »plc.st« gespeichert.

VQL-Skripte

Im ersten Schritt implementieren wir ein VQL-Skript, das die Logfiles des PLC überwacht, ausliest (Listing 3), analysiert und sichert. Das Plugin »upload()« bildet automatisch die Hash-Werte. Anhand der Hashes lässt sich zu einem späteren Zeitpunkt prüfen, ob die gesicherten Logfiles verändert wurden. Das Velociraptor-Framework verwaltet zu jedem Datensatz entsprechende Metadaten, die unter anderem die Hash-Werte und den Namen enthalten. Damit ist der Nachweis der Integrität der Dateien sichergestellt.

/* - Festlegen des Logfiles */
LET Logfile <= '/**/PLC/PLC.log'
/* - Logfile auslesen, ggf. Alarm bei Shutdown */
SELECT * FROM foreach(
  row={
    SELECT * FROM parse_lines(filename=Logfile, accessor='file')
  },
  query={
    SELECT * FROM scope()
    WHERE Line =~ "shutdown initiated" AND log(message='Alarm: PLC wird heruntergefahren!')
  }
)
/* - upload der Log-Messages zum Server */
SELECT upload(file=Logfile, name='PLC_Logfile.log', accessor='file', mtime=now()) FROM scope()

Im zweiten Schritt überprüft ein VQL-Skript das Netzwerk auf blockierte Verbindungen (Listing 4). Diese Maßnahmen empfiehlt das MITRE-ATT&CK-for-ICS-Framework mit Bezug auf die Technique T0803 Block Command Message unter der Kennung DS0029 “Network Traffic: Network Traffic Flow”. Wir implementieren die Detektionsmaßnahme im konkreten Beispiel der Testumgebung. Der PLC läuft unter Windows und nutzt TCP/IP zur Kommunikation.

Zur Detektion verfolgen wir die Verwendung von Sockets über das Event Tracing im System. Wir lassen alle Prozesse anzeigen, die bei dem Versuch, eine Verbindung aufzubauen, eine Fehlermeldung erhalten. Der eigentliche PLC ist abgeblockt und kann keine Signale erhalten. Die umliegenden Komponenten empfangen deshalb bei Kommunikationsversuchen mit dem PLC Fehlermeldungen. Diese Sachlage nutzen wir zur Detektion aus. Die GUID des Providers erhält man auf dem Windows-System über das Kommando »logman query providers«.

/* Monitoring ETW-Provider Microsoft-Windows-Winsock-Sockets */
LET DATA = SELECT System, EventData
         FROM watch_etw(guid='{BDE46AEA-2357-51FE-7367-D5296F530BD1}')
         WHERE EventData.ErrorCode =~ "unreachable"
/* Ausgabeprozess, der den Socket verwendet */
SELECT * FROM foreach(
  row=DATA, query=
  {
    SELECT Pid, Ppid, Name, EventData.Protocol, EventData.ErrorCode
    FROM pslist(pid=System.ProcessID)
  }
)

Der dritte Schritt dient der Überprüfung der Integrität der Codebasis des PLCs (Listing 5). Direkt nach dem Erstellen der Codebasis bilden wir Hashes und speichern sie. Das eingesetzte VQL-Skript berechnet auf Anfrage die Hash-Werte der Codebasis erneut und vergleicht sie mit den Originalen. Stimmen beide Hash-Werte überein, ist die Integrität nachgewiesen, anderenfalls liegt eine nachträgliche Manipulation vor. Das Skript loggt das Ergebnis, sodass man im Fall einer Manipulation unmittelbar Schutzmaßnahmen treffen kann.

--Erzeugen und Vergleichen des Hash-Wertes des ST-
/* - festlegen der Datei mit ST Quellcode */
LET Datei = '/**/PLC/plc.st'
/* - einlesen des originalen Hash-Werts H1 */
LET H1 = '440e20fe034d799af09e029fdab27858'
/* - berechnen des Hash-Werts H2 und davon MD5-Hash H3 */
LET H2 = SELECT hash(path=FullPath).MD5 AS Hash FROM glob(globs=Datei)
LET H3 = H2[0].Hash
/* - vergleichen der Hash-Werte und loggen des Ergebnis */
SELECT * FROM if(condition=(H1=H3),
  then={
    SELECT H1,H3 FROM scope()
    WHERE log(message='OK: %v sind gleich %v', args=[H1,H3])
  },
  else={
    SELECT H1,H3 FROM scope()
    WHERE log(message='Fehler: %v weichen ab %v', args=[H1,H3])
  })

Fazit

Mit den drei gezeigten VQL-Skripten lassen sich in der PLC-Umgebung relevante Datenquellen überwachen, untersuchen und sichern. Im Verlauf des gesamten Protokollierungszyklus wurden die Ergebnisse aller Detektionen gesammelt und im Kontext des gesamten Angriffsvektors ausgewertet.

Der gewählte adaptive Ansatz zur Angriffserkennung deckt zum einen die Mindestanforderungen des BSI-Gesetzes ab. Zum anderen erzielt er eine deutliche Flexibilisierung gegenüber neuen Cyberbedrohungen, indem er die jeweils aktuellen Erkenntnisse der Cyber Threat Intelligence (im Beispiel durch MITRE ATT&CK) einbezieht. (jcb/jlu)