Bei Elastic setzen wir eine große und vielfältige Menge an Verhaltenserkennungsregeln über mehrere Datensätze, Umgebungen und Schweregrade hinweg ein. Die meisten dieser Regeln sind atomar und jeweils darauf ausgelegt, ein bestimmtes Verhalten, Signal oder Angriffsmuster zu erkennen. Darüber hinaus erfassen und leiten wir externe Warnmeldungen von Sicherheitsintegrationen wie Firewalls, EDR, WAF und anderen Sicherheitskontrollen weiter.
Das Ergebnis ist eine hohe Transparenz, aber auch ein erhebliches Alarmaufkommen. Aus unseren Telemetriedaten geht hervor, dass selbst bei Berücksichtigung ausschließlich der Nicht -Bausteinregeln 65 einzigartige Erkennungsregeln fast 8000 Warnmeldungen pro Tag und Produktionscluster generieren. Die Analyse jeder einzelnen Warnmeldung ist weder skalierbar noch kosteneffektiv.
Hier kommen Regeln höherer Ordnung ins Spiel.
Regeln höherer Ordnung erfassen kein einzelnes Verhalten. Stattdessen korrelieren sie verwandte Warnmeldungen im Laufe der Zeit, über verschiedene Datenquellen hinweg oder innerhalb eines gemeinsamen Kontextes (wie Host, Benutzer, IP oder Prozess). Indem wir Signale zu aussagekräftigen Mustern gruppieren, können wir Prioritäten setzen und den Bedarf an aufwendigen und teuren Analysen jeder einzelnen Warnmeldung reduzieren, unabhängig davon, ob diese manuell, automatisiert oder mithilfe von KI durchgeführt werden.
In diesem Blogbeitrag erläutern wir unseren Ansatz zum Erstellen von Regeln höherer Ordnung in Elastic, teilen praktische Beispiele und heben die wichtigsten Erkenntnisse hervor, die wir dabei gewonnen haben.
Was sind Regeln höherer Ordnung?
Regeln höherer Ordnung (Higher-Order Rules, HOR) sind Erkennungen, die Warnungen als Eingabe verwenden, indem sie entweder Warnungen mit anderen Warnungen korrelieren (Warnung-auf-Warnung) oder Warnungen mit zusätzlichen Daten wie Rohereignissen, Metriken oder Kontexttelemetrie kombinieren.
Im Gegensatz zu atomaren Regeln, die ein einzelnes Verhalten erkennen, identifizieren Regeln höherer Ordnung Muster über verschiedene Signale hinweg. Ihr Zweck ist nicht, die Basiserkennung zu ersetzen, sondern Kombinationen von Befunden zu verbessern, die mit größerer Wahrscheinlichkeit eine tatsächliche Angriffsaktivität darstellen. In der Praxis führen sie zu zuverlässigeren Befunden und verbessern die Priorisierung bei der Triage. Regeln höherer Ordnung sind so konzipiert, dass sie mit Bausteinregeln zusammenwirken. Die Regeln der Bausteine erzeugen Warnmeldungen, die nicht in der Standard-Warnmeldungsansicht angezeigt werden. Dadurch wird das Rauschen reduziert, während gleichzeitig korrelierte Erkennungen bereitgestellt werden. Viele der in diesem Artikel genannten Basisregeln können auch als Bausteinregeln konfiguriert werden, sodass für die Analystenprüfung nur Korrelationen höherer Ordnung angezeigt werden.
Die zentrale Erkenntnis besteht darin, dass unabhängige Detektionen, die auf dieselbe Entität hinweisen, das Vertrauen verstärken, wobei jedes zusätzliche Signal die Wahrscheinlichkeit erhöht, dass die Aktivität real und nicht harmlos ist. Diese drei Gestaltungsprinzipien setzen diese Erkenntnis in die Praxis um:
1. Entitätsbasierte Korrelation
Regeln korrelieren Aktivitäten von gemeinsam genutzten Entitäten wie Host, Benutzer, Quell-IP, Ziel-IP oder Prozess – und ermöglichen es Analysten so, schnell zu erkennen, wann mehrere Ergebnisse auf dasselbe Asset oder dieselbe Identität zurückzuführen sind.
2. Datenquellenübergreifende Sichtbarkeit
Einige Regeln funktionieren innerhalb einer einzigen Integration (z. B. Endpunkterkennungen von Elastic Defend oder EDR-Systemen von Drittanbietern). Andere kombinieren absichtlich Signale aus verschiedenen Domänen – Endpunkt mit Netzwerk (PANW, FortiGate, Suricata), Endpunkt mit E-Mail oder Endpunkt mit Systemmetriken –, um mehrstufige oder oberflächenübergreifende Aktivitäten zu erfassen.
3. Zeit und Prävalenzbewusstsein
Die temporale Logik spielt eine Schlüsselrolle.
Neu beobachtete Regeln heben das erste Auftreten einer bestimmten Warnung innerhalb eines definierten Rückblickzeitraums (z. B. fünf Tage) hervor und gewährleisten so, dass auch eine einzelne seltene Warnung zur Überprüfung angezeigt wird.
Prävalenzbasierte Logik (z. B. durch Verwendung von INLINE STATS) filtert Warnmeldungen heraus, die nur auf einer kleinen Anzahl von Hosts weltweit auftreten, wodurch Rauschen reduziert und anomales Verhalten hervorgehoben wird.
Der vollständige Satz der Regeln höherer Ordnung umfasst Korrelationen, die sich ausschließlich auf Endpunkte beziehen, domänenübergreifende Erkennungen (Endpunkt + Netzwerk, Endpunkt + E-Mail), laterale Bewegungsmuster (z. B. alert_1 host.ip = alert_2 source.ip), ATT&CK-konforme Gruppierungen (Einzel- oder Mehrfachtaktikaktivität), neu beobachtete Warnungen und die Korrelation von Warnungen mit Ereignissen (z. B. Warnungen in Kombination mit abnormalen CPU-Metriken). In den folgenden Abschnitten werden repräsentative Beispiele aus diesen Kategorien vorgestellt.
Korrelation und neu beobachtete Regeln höherer Ordnung
In der Praxis sehen risikoreiche Aktivitäten nicht immer gleich aus.
Manchmal offenbart sich ein Kompromiss durch mehrere zusammenlaufende Signale. Manchmal erscheint es auch als einzelne Warnmeldung, die noch nie zuvor gesehen wurde.
Um beiden Realitäten gerecht zu werden, gliedern wir unsere übergeordneten Regeln in drei sich ergänzende Muster:
- Korrelationsregeln beziehen sich auf mehrere Warnungen oder Ereignisse, die mit einer gemeinsamen Entität (Host, Benutzer, IP oder Prozess) verknüpft sind.
- Neu beobachtete Regeln: eine einzelne Warnung, die selten ist oder zum ersten Mal innerhalb eines definierten Zeitfensters auftritt.
- Hybride Muster, die Korrelation mit der Logik des ersten Erkennens kombinieren, können den Verdacht weiter verstärken und besonders interessante Aktivitäten aufdecken.
Korrelationsregeln erhöhen das Vertrauen durch Signaldichte und -diversität: Wenn mehrere unabhängige Detektionen auf dieselbe Entität hinweisen, steigt die Wahrscheinlichkeit einer tatsächlichen böswilligen Aktivität.
Neu beobachtete Regeln befassen sich mit dem gegenteiligen Fall, geringes Volumen, aber hohe Neuheit. Sie priorisieren Warnmeldungen nach ihrer Seltenheit im Laufe der Zeit, um sicherzustellen, dass erstmalige oder höchst ungewöhnliche Erkennungen nicht übersehen werden, nur weil sie einmalig auftreten.
Zusammen bilden diese Ansätze die Grundlage für eine effiziente und skalierbare Triage-Strategie.
Lasst uns in Beispiele eintauchen und die Unterschiede, Stärken und Nachteile der einzelnen Muster untersuchen.
Korrelation von Endpunktwarnungen
Ein wesentlicher Teil der Erkennung von Angriffen in der Praxis erfolgt über die Telemetrie von Endgeräten. Es liefert umfassende Kontextinformationen zu Prozessaktivitäten, Befehlszeilen, Dateiverhalten und Benutzeraktionen und ist damit eine der leistungsstärksten Erkennungsquellen.
Gleichzeitig sind Endpunktumgebungen dynamisch. Legitime Software, Admin-Tools und Anwendungen von Drittanbietern (und seit Kurzem auch GenAI Endpoint Utility 🥲) können ein hohes Alarmvolumen und viele Fehlalarme auslösen, was eine kontinuierliche Optimierung erforderlich macht.
Korrelationen höherer Ordnung tragen dazu bei, dieses Problem zu lösen, indem sie den Fokus von einzelnen Warnmeldungen auf mehrere unterschiedliche Signale auf demselben Host oder Prozess verlagern. Dies erhöht das Vertrauen und reduziert gleichzeitig unnötigen Untersuchungsaufwand.
Die folgende ES|QL-Abfrage wird ausgelöst, wenn 3 eindeutige Elastic Defend-Verhaltensregeln ODER Warnungen von verschiedenen Funktionen vorliegen (z. B. ein shellcode_thread mit Verhalten, eine malicious_file mit Verhalten) ODER mehr als 2 Malware-Warnungen innerhalb eines 24-Stunden-Zeitfensters vom selben Host:
from logs-endpoint.alerts-* metadata _id
| eval day = DATE_TRUNC(24 hours, @timestamp)
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
| stats Esql.alerts_count = COUNT(*),
Esql.event_code_distinct_count = count_distinct(event.code),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, day
| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)Um den Verdacht weiter zu erhärten, können wir auch Elastic Defend-Warnungen korrelieren, die zum selben Prozessbaum gehören:
from logs-endpoint.alerts-*
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null
// aggregate alerts by process.Ext.ancestry and agent.id
| stats Esql.alerts_count = COUNT(*),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.event_code_distinct_count = COUNT_DISTINCT(event.code),
Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id),
Esql.message_values = VALUES(message),
... by process.Ext.ancestry, agent.id
// filter for at least 3 unique process IDs and 2 or more alert types or rule names.
| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2)
// keep unique values
| stats Esql.alert_names = values(Esql.message_values),
Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values),
... by agent.id
| keep Esql.*, agent.idBeispiel für Übereinstimmungen:
Um unsere Berichterstattung zu vervollständigen, müssen wir auch nach seltenen Atomsprengköpfen suchen. Das folgende ES|QL-Skript ist so konzipiert, dass es alle 10 Minuten mit einem Rückblickfenster von 5 oder 7 Tagen ausgeführt wird. Die Lookback-Funktion aggregiert alle Warnmeldungen nach Regelnamen über das gesamte Zeitfenster, um den Zeitpunkt des ersten Auftretens zu berechnen. Der letzte Filter (Esql.recent <= 10) stellt sicher, dass nur Regeln angezeigt werden, deren erster Auftrittszeitpunkt innerhalb des aktuellen 10-minütigen Ausführungsfensters liegt, und erkennt so effektiv den Moment, in dem eine Regel zum ersten Mal im Betrachtungszeitraum ausgelöst wird. Dadurch werden sowohl seltene Fehlalarme als auch unauffällige Verhaltensweisen sichtbar, die sonst in der Menge untergehen könnten:
from logs-endpoint.alerts-*
| WHERE event.code == "behavior" and rule.name is not null
| STATS Esql.alerts_count = count(*),
Esql.first_time_seen = MIN(@timestamp),
Esql.last_time_seen = MAX(@timestamp),
Esql.agents_distinct_count = COUNT_DISTINCT(agent.id),
Esql.process_executable = VALUES(process.executable),
Esql.process_parent_executable = VALUES(process.parent.executable),
Esql.process_command_line = VALUES(process.command_line),
Esql.process_hash_sha256 = VALUES(process.hash.sha256),
Esql.host_id_values = VALUES(host.id),
Esql.user_name = VALUES(user.name) by rule.name
// first time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)
| keep host.id, rule.name, Esql.*Die gleiche Logik lässt sich auch auf externe Warnmeldungen von anderen EDR-Systemen von Drittanbietern anwenden:
Endpunkt mit Korrelation von Netzwerkwarnungen
Ein leistungsstarker Erkennungsansatz besteht in der Korrelation von Endpunktwarnungen mit Netzwerkwarnungen. Dies hilft, die Schlüsselfrage zu beantworten:
Welcher Prozess hat diese Netzwerkwarnung ausgelöst?
Netzwerkwarnungen allein liefern oft keinen Kontext zum Prozess, z. B. welcher Benutzer oder welche ausführbare Datei die Aktivität initiiert hat. Durch die Kombination von Netzwerkwarnungen mit Endpunkttelemetriedaten (EDR-Daten) können Sie die Warnungen anreichern mit:
- Prozessname und Hash
- Befehlszeile und übergeordneter Prozess
- Benutzer- und Geräteinformationen
Die folgende Abfrage korreliert jede Elastic Defend-Warnung mit verdächtigen Ereignissen von Netzwerksicherheitsgeräten wie Palo Alto Networks (PANW) und Fortinet FortiGate. Der Join-Schlüssel ist die IP-Adresse: Bei Netzwerkwarnungen ist dies source.ip, bei Endpunktwarnungen ist es host.ip. Die Abfrage normalisiert diese mithilfe von COALESCE in ein einziges Feld und ermöglicht so die Korrelation über Datenquellen hinweg, die unterschiedliche Feldnamen für dieselbe Entität verwenden. Dies könnte darauf hindeuten, dass dieser Host kompromittiert ist und dadurch Warnmeldungen von mehreren Datenquellen ausgelöst werden.
FROM logs-* metadata _id
| WHERE
(event.module == "endpoint" and event.dataset == "endpoint.alerts") or
(event.dataset == "panw.panos" and event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", ...)) or
(event.dataset == "fortinet_fortigate.log" and (...)) or
(event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", ...))
| eval
fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null
| stats Esql.alerts_count = COUNT(*),
Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
Esql.message_values_distinct_count = COUNT_DISTINCT(message),
... by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
| where concat_module_values like "*endpoint*"Beispiel für Übereinstimmungen zwischen Elastic Defend- und FortiGate-Warnungen, bei denen die Quell-IP der FortiGate-Warnung mit der Host-IP der Elastic Defend-Endpunktwarnung übereinstimmt:
Die folgende EQL-Abfrage korreliert Suricata-Warnungen mit Elastic Defend-Netzwerkereignissen, um Kontextinformationen zum Quellprozess und Host bereitzustellen:
sequence by source.port, source.ip, destination.ip with maxspan=5s
// Suricata severithy 3 corresponds to information alerts, which are excluded to reduce noise
[network where event.dataset == "suricata.eve" and event.kind == "alert" and event.severity != 3 and source.ip != null and destination.ip != null]
[network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]Beispiel für Übereinstimmungen, die die Suricata-Warnung bestätigen und sie mit dem Zielwebserverprozess nginx aus Elastic Defend-Ereignissen verknüpfen, die den Web-Exploit-Versuch bestätigen:
Endpunktsicherheit mit Observability
Die Korrelation von Observability-Telemetriedaten mit Sicherheitswarnungen ist eine leistungsstarke Erkennungsstrategie.
Der Backdoor-Vorfall bei XZ Utils hat gezeigt, dass sicherheitsrelevante Anomalien zunächst als Leistungseinbußen und nicht als herkömmliche Sicherheitswarnungen auftreten können. In diesem Fall führte ein ungewöhnliches Verhalten des SSH-Daemons zu eingehenderen Untersuchungen und schließlich zur Entdeckung von Schadcode.
Dies unterstreicht ein wichtiges Prinzip: Betriebsanomalien können frühe Anzeichen für eine Kompromittierung sein.
Mit dem Elastic Agent können neben Sicherheitstelemetriken auch Systemmetriken wie CPU- und Speicherauslastung erfasst werden. Durch die Korrelation von anormalen Ressourcenspitzen mit SIEM-Warnmeldungen, entweder nach Prozess oder nach Host, können wir die Erkennungssicherheit erhöhen und risikoreiche Aktivitäten früher aufdecken.
Eine ES|QL-Korrelationsregel kann beispielsweise einen Prozess identifizieren, der eine anhaltende CPU-Auslastung von 70 % aufweist und gleichzeitig die Quelle einer Speichersignaturwarnung für einen Kryptominer von Elastic Defend ist. Einzeln betrachtet kann jedes Signal eine niedrige oder mittlere Ausprägung haben. Zusammengenommen stellen sie mit hoher Wahrscheinlichkeit böswillige Aktivitäten dar.
Wir haben über 30 Erkennungsmechanismen höherer Ordnung entwickelt, die verschiedene Arten von Beziehungen abdecken. Auch wenn wir hier nicht alle Aspekte abdecken können, bieten die folgenden Links genügend Kontext, um diese Regeln an Ihre Umgebung anzupassen:
Endpunktwarnungen:
Mehrere Elastic Defend-Warnungen pro Agent
Mehrere Elastic Defend-Warnungen aus einem einzelnen Prozessbaum
Mehrere seltene Elastic Defend-Verhaltensregeln pro Host
Neu beobachtete Elastic Defend-Verhaltenswarnung
Mehrere externe EDR-Warnungen pro Host
Endpunkt und Netzwerk:
Neu aufgetretene Palo Alto Netzwerkwarnung
Neu aufgetretene Suricata-Warnung mit hoher Priorität{
FortiGate SOCKS-Datenverkehr von einem ungewöhnlichen Prozess
Korrelation zwischen PANW und Elastic Defend – Command-and-Control-Schnittstelle
Korrelation zwischen Elastic Defend und Netzwerksicherheitswarnungen
Korrelation zwischen Suricata und Elastic Defend – Netzwerk
Generische MITRE ATT&CK-Warnungen:
Warnungen in verschiedenen ATT&CK-Taktiken pro Host
Mehrere Warnungen in derselben ATT&CK-Taktik pro Host
Generische Korrelation mehrerer Integrationen:
Warnungen aus mehreren Integrationen nach Quelladresse
Warnungen aus mehreren Integrationen nach Zieladresse
Warnungen aus mehreren Integrationen nach Benutzername
Neu aufgetretene Warnung mit hoher Priorität
Korrelation lateraler Bewegungen:
Verdächtige laterale Bewegung von einem kompromittierten Host
Warnungen vor lateralen Bewegungen von einer neu beobachteten Quelladresse
Warnungen vor lateralen Bewegungen von einem neu beobachteten Benutzer
Korrelation von Beobachtbarkeit und Sicherheit:
Erkennungsalarm für einen Prozess mit CPU-Spitze
Mehrere Alarme für einen Host mit CPU-Spitze
Neu beobachteter Prozess mit hoher CPU-Auslastung
Korrelation von maschinellem Lernen:
Mehrere Warnmeldungen von maschinellem Lernen nach Influencer-Feld
Weitere Korrelationsideen:
Mehrere Schwachstellen pro Asset über Wiz
Korrelation von Elastic Defend und E-Mail-Benachrichtigungen
Verdächtige Kerberos-Authentifizierungsticketanfrage
Zugriff auf mehrere Cloud-Geheimnisse über die Quelladresse
Diese Beispiele veranschaulichen, wie die Korrelation von Warnmeldungen über Endpunkte, Netzwerk und Observability hinweg den Kontext anreichern, Untersuchungen beschleunigen und die Erkennungssicherheit verbessern kann. Wir erweitern aktiv die Abdeckung in diesem Bereich, um zusätzliche Korrelationsszenarien zu unterstützen.
Sie können diese aktivieren, indem Sie auf der Seite zur Regelverwaltung nach dem Tag-Wert „Regeltyp: Regel höherer Ordnung“ filtern:
Über einen Zeitraum von 15 Tagen blieb die Anzahl der Alarme im akzeptablen Bereich (~30 Alarme/Tag). Durch gezieltes Feintuning anfänglicher Ausreißer dürften diese auf etwa 20 Alarme pro Tag reduziert und die Gesamtsignalqualität deutlich verbessert werden.
Überlegungen und Abwägungen
Regeln höherer Ordnung bergen das Risiko von Verzögerungen bei der Ablaufplanung. Da sie Alarmindizes abfragen, entsteht eine systembedingte Verzögerung zwischen dem Auslösen von Basisalarmen und dem Auftreten von Korrelationen. Die Intervalle für die Regelplanung und die Rückkopplungsfenster sollten so eingestellt werden, dass ein Gleichgewicht zwischen Aktualität und Leistungskosten besteht. Darüber hinaus hängt die HOR-Qualität direkt von der Qualität der Basiserkennungen ab. Eine fehlerhafte atomare Regel führt zu einer Kaskade von Fehlalarmen in jeder Korrelation, die sich darauf bezieht. Wir empfehlen, die Basisregeln gründlich anzupassen, bevor abhängige Regeln höherer Ordnung aktiviert werden. Schließlich können ESQL-Abfragen über breite Indexmuster (z. B. logs-*) können in großem Umfang teuer sein. In Umgebungen mit hohem Datenaufkommen können die Abfragekosten erheblich reduziert werden, indem Indexmuster auf bestimmte Datensätze beschränkt oder Datenansichten verwendet werden.
Fazit
Regeln höherer Ordnung sind unerlässlich für die Priorisierung der Alarmbearbeitung und die Verwaltung des Alarmvolumens für die Automatisierung und KI-gestützte Analyse. In Kombination mit Entity Risk Scoring können Regeln höherer Ordnung direkt in Host- und Benutzerrisikoprofile einfließen und so eine quantitative Priorisierungsebene schaffen, die den manuellen Triageaufwand weiter reduziert. In unseren Produktionstests erzeugte die Mehrzahl dieser Erkennungen ein mittleres bis niedriges Alarmaufkommen, wodurch sie sich für den praktischen Einsatz eignen. Auch wenn anfänglich eine kleine Anzahl fehlerhafter Regeln oder falsch positiver Ergebnisse auftreten mag, führt deren Ausschluss auf der Ebene der atomaren Regeln schnell zu einem robusten Satz von Korrelationen mit hohem Wert.
Um ihre Effektivität zu maximieren, sind zwei operative Vorgehensweisen entscheidend. Zunächst muss sichergestellt werden, dass die Eingangswarnungen Schweregrade verwenden, die sowohl das Rauschen als auch die Auswirkungen in der realen Welt genau widerspiegeln. Die Bereinigung und Normalisierung des Schweregrades ist die Grundlage für eine sinnvolle Korrelation. Zweitens: Fangen Sie klein an und erweitern Sie gezielt: Vermeiden Sie es, jedes mögliche Warnsignal miteinander in Zusammenhang zu bringen. Taktiken, die von Natur aus verrauscht sind (wie z. B. die Entdeckung), sollten ausgeschlossen, Signale mit geringer Schwere nachrangig behandelt und Regeln, die die Korrelationsergebnisse unverhältnismäßig stark beeinflussen, als veraltet eingestuft werden.
Bei korrekter Anwendung optimieren Regeln höherer Ordnung die Ermittlungen, verbessern die Erkennungsgenauigkeit und steigern die Effizienz und Vertrauenswürdigkeit moderner Sicherheitsoperationen erheblich.