Effektive C2-Beaconing-Erkennung

Ein umfassender Satz von Signalen ist erforderlich und sollte Quell-, Ziel- und Traffic-Merkmale wie SSL/TLS-Zertifikate enthalten, die sowohl auf der Quelle (Malware in der Umgebung) als auch auf dem Ziel (C2-Server) verwendet werden, Domäne/IP/URL, Quellenmerkmale wie die Eigenschaften des Benutzeragenten/-prozesses, Traffic-Größe/Burstiness/-Muster, HTTP-Header/Payload/URI, um nur einige zu nennen.

Bei der Betrachtung verschiedener Signale über Zeit, Volumen, Netzwerkschichten und die allgemeine Erstellung von Traffic-Profilen kann die Verhaltenserkennung einen allgemeinen und effektiven Mechanismus zur Erkennung der neuesten Malware über verdächtige und bösartige C2-Beaconing-Aktivitäten bieten.

Abbildung 6: Umfassende Signale

Die Signaltypen haben mehrere Dimensionen:

• Netzwerkfluss: Quell- und Zielattribute sowie Datenverkehrsmuster
• Netzwerkschichten: unterschiedliche Signale von Schicht 3 bis 7 (Anomalien bei TCP/IP-Headern, SSL/TLS-Fingerabdrücken, HTTP-Headern/Nutzlasten und Inhalten auf Anwendungsebene)
• Zeit: Häufigkeit, anomale Timing-Muster zur Erkennung seltener und langsamer Aktivität
• Daten: Inhalt und Volumen (anomale Paketgrößen, Bursts, kumulative Statistiken)

Darüber hinaus gibt es mehrere Signaltypen:

• Basierend auf Traffic-Mustern (Volumen, Timing, Inhalt), einschließlich wiederholtem Beaconing in Verbindung mit ungewöhnlichem User-Agent oder Domäne.
• Heuristiken (z. B. verdächtige Registrare oder bekannte bösartige SSL-Fingerabdrücke)
• Anomalien (ungewöhnliche Domäne, Benutzeragenten oder SSL-Fingerabdrücke)

Ein wichtiger Punkt ist, dass einige der oben genannten Signale Teil aktueller Ansätze und bestehender Lösungen sind. Dies unterstreicht den Punkt, dass ein bestimmtes Signal, wie z. B. eine Verkehrsspitze (großes Volumen), für sich genommen weder gut noch schlecht, effektiv oder ineffektiv ist. Vielmehr ist der Kontext und die Verarbeitung des Signals der entscheidende Faktor. Wenn ein Signal, das anfällig für Fehlalarme ist, an einem Netzwerkperimeter verwendet wird, um Datenverkehr zu blockieren/zuzulassen, kann dies zu schwerwiegenden Betriebsproblemen führen. Wenn es jedoch in ein Anomalieerkennungssystem eingespeist wird, das dieses Signal in eine granulare Risikometrik (siehe unten) und ein gut trainiertes Modell einbezieht, kann es äußerst effektiv sein, neue Bedrohungen auf robuste Weise mit geringen Fehlalarmen zu erkennen.

Für die effektive Erkennung von C2-Beaconing aus C2-Framework-Toolkits sind Modelle für maschinelles Lernen erforderlich, die auf einer umfassenderen Palette von Signalen basieren, um die heutigen C2-Framework-Toolkits und zukünftiges verdächtiges Netzwerkverhalten zu identifizieren, das auf C2-Aktivität hinweisen könnte.

Abbildung 7: Erkennung von Anomalien

Die Anomalieerkennung sollte auf Modellen auf Benutzer-/Geräte-, Rollen- und Organisationsebene basieren. Das heißt, Anomalien setzen voraus, dass wir eine gültige "normale" Grundlinie der Aktivität oder des Verhaltens haben, mit der wir vergleichen können. Das Erkennen verdächtiger Aktivitäten kann unter verschiedenen Umständen auftreten. Es gibt Anomalien, die auf den Aktionen eines Benutzers im Vergleich zu seiner historischen "normalen" Baseline oder auf der "normalen" Baseline der Organisation oder auf den Personen in ähnlichen Rollen basieren. Alle haben ihre gültigen Anwendungsfälle, die sich von den anderen ausschließen, und ein guter Ansatz umfasst mehrere Modelle mit unterschiedlichen Bereichen.

Trainingsdatasets sollten sowohl bösartigen als auch harmlosen Datenverkehr enthalten:

• Bösartiger Datenverkehr kann mit allgemeinen C2-Testtools, spezifischen C2-Adversarial-Beaconing-Tests auf der Grundlage öffentlich verfügbarer Konfigurationen von C2-Framework-Tools sowie benutzerdefinierten Konfigurationen aus der Perspektive eines Red Teams und offiziellen Red Team-Übungen simuliert werden.
• Gutartiger Traffic oder gültiger Traffic wird am besten von einer signifikanten Anzahl tatsächlicher Benutzer in realen Organisationen über genügend Zeit gesammelt, um sich gegen Benutzer- und Organisationsverzerrungen zu normalisieren.

Trainingsdatasets sind die Kehrseite des Testens von Datasets, und es sollte viel Zeit für die Analyse und Validierung guter Trainings- und Testdaten aufgewendet werden. Einige der Faktoren, die bei der Erstellung guter Testdatensätze zu finden sind, werden in einem nachfolgenden Abschnitt erläutert.

Die Ausgabe der Anomalieerkennung ist entscheidend. Der beste Ansatz führt keine einfachen Block-/Allow- oder Alert-/Stille-Bestimmungen auf der Grundlage eines Rohsignals durch, sondern verfolgt und passt stattdessen fein abgestufte Risikometriken auf Benutzer-, Rollen- und Organisationsebene an, die dann für Abhilfemaßnahmen wie Warnungen, Coaching oder Blockieren verwendet werden können.

Dieser Ansatz zur Verfolgung und Reaktion auf Risiken unterscheidet sich grundlegend von dem, was heute typischerweise verwendet wird. Die meisten Perimeterschutzmaßnahmen, die präventiv sind und in der Regel Datenverkehr blockieren/warnen/zulassen, sind im Allgemeinen statisch und anfällig für hohe Falsch-Positiv-Raten. Das Endergebnis ist, dass diese Lösungen mit einer konservativen Politik ausgestattet sind, um bestimmte und bekannte Risiken zu blockieren, was dann eine große Anzahl von False Negatives eröffnet. Bei Firewalls sehen wir False-Positive-Probleme mit übermäßig aggressiven Blockierungsaktionen, die auf IP-Bedrohungsinformationen basieren. Bei IPS-Lösungen haben wir die False-Positive-Herausforderungen bei statischen Signaturen diskutiert, die versuchen, hochgradig konfigurierbaren und dynamischen C2-Datenverkehr zu erkennen.

Aber Fehlalarme auf einer Perimeterschicht können als Signal für eine intelligentere Schicht sehr nützlich sein. In diesem Szenario würden wir es nicht für eine binäre Bewertung (Zulassen/Blockieren, Melden/Ignorieren) verwenden, sondern als feinkörnige Risikometrik, die im Laufe der Zeit angepasst wird (z. Benutzerrisikobewertung) mit einem abgestimmten Schwellenwert, bevor Maßnahmen ergriffen werden. Eine granulare Risikometrik, z. B. eine Risikobewertung von 1000 (kein Risiko) bis 0 (extremes Risiko) für einen Benutzer oder ein Gerät oder sogar eine IP-Adresse, ermöglicht es uns, das Grauspektrum zu modellieren, das mit realen Bedrohungen verbunden ist, bei denen es selten klare 100 % bösartige oder 100 % gutartige Bewertungen gibt.

Konzeptionell wird dies in der folgenden Abbildung dargestellt, in der drei verschiedene Signale erkannt werden können, die für sich genommen anfällig für falsch positive Ergebnisse wären. Wenn sie jedoch mit einem inkrementellen Risiko verbunden sind und von einem abgestimmten Machine Learning-Modell bewertet werden, bewerten dieselben Signale das kumulative Risiko im Laufe der Zeit und liefern letztendlich eine Anomalieerkennung mit hoher Zuverlässigkeit.

Abbildung 8: Granulare Risikometriken

Beachten Sie, dass die Signale in diesem Beispiel möglicherweise nicht so einfach sind wie statische Signale. Zum Beispiel könnte ein "ungewöhnlicher Domain-Benutzeragent und SSL/TLS-Zertifikat" eine Anomalie sein, wenn man sie mit der vergangenen "normalen" Datenverkehrsbasis für diesen bestimmten Benutzer oder mit ähnlichen Jobrollen von Benutzern oder der gesamten Organisation vergleicht. Ein "verdächtiger Registrar" kann eine Verschmelzung von Domain-Reputationen sein, die im Laufe der Zeit korreliert sind. Und "periodisches Beaconing" ist nicht mehr nur eine einfache Übereinstimmung mit einer festen Rate oder Dauer, sondern kann stattdessen abnormale, aber regelmäßige und wiederholte Aktivitäten innerhalb eines Zeitfensters erkennen, das der Bot-bezogenen Aktivität im Gegensatz zu gültigen Anwendungs-Daemon-Callouts ähnelt.

In der Praxis können wir so einen Risikobewertungswert schrittweise und angemessen auf der Grundlage eines Low-Fidelity-Signals anpassen. Es führt zu keiner Blockierungs- oder Warnaktion, bis die kumulative Risikobewertung einen abgestimmten, oberen Schwellenwert überschreitet. Auf diese Weise können wir Fälle erfassen, in denen es viele leicht riskante Indikatoren mit geringer Genauigkeit gibt, die in Kombination mit einem Indikator mit höherer Genauigkeit und höherem Risiko für einen bestimmten Benutzer oder ein bestimmtes Gerät kumulativ eine kritische Risikowarnung und -maßnahme mit einer drastisch geringeren Wahrscheinlichkeit von Fehlalarmen erzeugen.

Ein neuer Ansatz kann theoretisch solide sein und in der Praxis kläglich scheitern, und der Beweis liegt oft in den Daten oder Tests. Anbieter, die Lösungen anbieten, und Organisationen, die nach Lösungen suchen, benötigen einen robusten Ansatz zum Testen neuer Bedrohungen und zur Bewertung von Lösungen. Um genaue Ergebnisse zu erzielen, ist es wichtig, mit einem vielfältigen Datensatz zu testen, der sowohl bösartigen als auch gutartigen Datenverkehr enthält.

Harmloser Verkehr
Gutartiger Traffic sollte realistisch und umfassend sein und in Bezug auf die Anzahl der Benutzer und die Aktivität der Produktion ähneln. Guter Traffic, der oft nutzerabhängig ist, sollte über eine große Stichprobe von Nutzern und einen angemessenen Zeitraum untersucht werden. Mit diesem Testdatensatz werden die Falsch-Positiv-Raten (FP) gemessen. Die wichtigste Varianz in den Datensätzen sind Clientsignale, wie z. B. die verwendeten Anwendungen, Benutzeragenten und Client-SSL/TLS-Zertifikate, Zielsignale, die in den Zieldomänen/IP-Adressen angezeigt werden, und Verkehrsmustersignale in den Headern, der Nutzlast, der Größe und dem Timing.

Die gute Nachricht ist, dass gutartiger Traffic leicht aus dem täglichen Betrieb der Benutzer des Unternehmens entnommen werden kann, während die schlechte Nachricht ist, dass er als gutartig validiert werden muss. Der praktische Ansatz besteht darin, den gutartigen Datenverkehr statistisch auf einen bestimmten angemessenen Konfidenzfaktor abzutasten und sich dann die meiste Zeit auf die Warnungen der zu testenden C2-Erkennungslösung zu konzentrieren und die Warnungen als richtig positiv oder falsch positiv zu überprüfen. Mit anderen Worten: Führen Sie vorab eine Stichprobe durch und verifizieren Sie, um eine Baseline zu bilden, gehen Sie davon aus, dass der gutartige Datensatz sauber ist, und fahren Sie dann mit der Identifizierung falsch positiver Ergebnisse auf der Grundlage von Tests fort.

Abbildung 9: Gutartige Traffic-Tests

Bösartiger Datenverkehr
Die Verwendung öffentlicher Profile aus beliebten C2-Framework-Tools bietet eine solide Grundlage für das Testen von schädlichem Datenverkehr. Diese Profile stellen praktische, häufig verwendete Konfigurationen dar, die Abwehrmaßnahmen umgehen und bei der Messung von Falsch-Negativ-Raten (FN) helfen. Es muss jedoch viel darüber nachgedacht werden, einen repräsentativen Datensatz für "schlechten Traffic" zu erstellen, da die Abdeckung und die Tests der Datensätze potenziell mehrere Ebenen umfassen, wie im folgenden Diagramm dargestellt:

Abbildung 10: Testen von bösartigem Datenverkehr

1. Tools zur Simulation von Sicherheitsverletzungen und Angriffen wie SafeBreach eignen sich hervorragend für Abdeckungstests und wiederholte Tests. Ihre C2-Testfälle beinhalten in der Regel zumindest eine Simulation der Aktivität von C2-Frameworks. Der Vorteil besteht darin, dass eine große Bandbreite an Funktionen verfügbar ist, einschließlich allgemeiner Malware-Angriffe, mit gut gestalteten GUIs und Architekturen sowie wiederholbaren Testverfahren und -berichten. Diese Tools bieten Ihnen eine breite Palette von Szenarien, darunter: Low-Slow-Aktivität, IaaS/CSP-Infrastruktur, HTTP- und Nicht-HTTP-Datenverkehr bis hin zu SSL/HTTPS-Datenverkehr und Spoofing einer Vielzahl von Benutzeragenten.
2. C2-Framework-Tools (öffentliche Profile). Das tiefgreifende Testen von C2-Frameworks erfordert konzentrierte Arbeit. Ein Ansatz besteht darin, einen Testdatensatz zu erstellen, der auf den spezifischen öffentlichen Profilen von C2-Framework-Tools, z. B. Cobalt Strike, basiert. Diese öffentlichen, formbaren Profile werden in der Regel weit verbreitet und von vielen Benutzern und böswilligen Akteuren verwendet, da sie nützliche Emulationen von gutartigen Anwendungen wie Google Mail enthalten. Dieser Ansatz bietet in der Regel umfassendere Tests rund um die spezifischen C2-Frameworks.
3. C2-Framework-Tools (benutzerdefinierte Profile). Die interne Anpassung der C2 Malleable Profiles kann ein noch realistischeres Testen von C2-Frameworks ermöglichen. Diese benutzerdefinierten Konfigurationen können während interner Red Team-Vorgänge vorgenommen werden. Dies erfordert mehr Arbeit und Investitionen, da die Red-Team-Operatoren die Tools des C2-Frameworks fließend beherrschen müssen.
4. Realistische Angriffe. Die realistischsten Tests sind Black-Box-Tests mit externen Pen-Testing- oder Bug-Bounty-Programmen. In diesen Szenarien sind die Anforderungen der Übung sorgfältig konstruiert, um tatsächliche POC-Exploits zu erfordern oder zu fördern, die bestimmte C2-Framework-Tools oder C2-Beaconing-Verhalten verwenden, mit Einschränkungen, die eine Erkennung über einen bestimmten Zeitraum vermeiden. Die Ziele der Übungen sind nicht nur das Testen von Erstzugriffsvektoren, was die Norm ist, sondern auch die Konzentration auf die Aktivität nach dem Verstoß, indem die Fähigkeit gezeigt wird, eine Backdoor-Nutzlast mit demonstrierter C2-Aktivität zu installieren. Dies bereichert den Testdatensatz über die C2-Frameworks hinaus und kann Backdoor-POC-Code mit benutzerdefinierter C2-Kommunikation testen und ist auch ein hervorragender Test für die Widerstandsfähigkeit eines Erkennungstools gegenüber einem erfahrenen "Angreifer", der andere oder benutzerdefinierte TTPs verwendet.

Das Testen kann mehrere oder mehrere Ansätze umfassen, aber es sollten explizite Entscheidungen darüber getroffen werden, wie die Testdatensätze erstellt, gesammelt und validiert und wie die erwarteten Ergebnisse gemessen werden. Das Erstellen und Sammeln der Testdatensätze ist sehr wichtig, damit das Testen automatisiert und einfach wiederholt werden kann.

Es ist auch wichtig, während des Tests vollständige Metriken zu messen: Richtig und falsch positiv, richtig und falsch negativ. Während das Sammeln aller Metriken offensichtlich klingt, ist es schwierig, präzise in der Definition und klar und wiederholbar in der Messmethodik zu sein, was zu irreführenden Ergebnissen führt.

Falsch positive und falsch negative Ziele
Mit den neuen ausweichenden Bedrohungen, die durch C2-Frameworks geschaffen werden, werden allen neueren Erkennungslösungen die weithin akzeptierten FP- und FN-Raten fehlen. Es ist jedoch wichtig, FP- und FN-Ziele zu erstellen. Mit Testdatensätzen von bekannter Qualität können Baselines für die aktuelle Umgebung und Benutzer/Geräte erstellt werden, wodurch dann vernünftige Ziele relativ zu diesen Baselines erstellt werden können.

Angenommen, ein Unternehmen, das nur über ein IPS verfügt, beginnt mit der Evaluierung neuer C2-Erkennungslösungen und es ist unklar, welche FP/FN-Raten akzeptabel sind. Das Unternehmen kann immer noch vernünftige Ziele festlegen, indem es eine Testmethodik befolgt, wie z. B.:

• Erstellen Sie qualitativ hochwertige Testdaten für gutartigen Traffic auf der Grundlage von Produktionsdaten und bösartigen Traffic auf der Grundlage von z. B. öffentlichen C2-Formbarprofilen für Cobalt Strike und durch manuelle Validierung von Stichproben dieser Datensätze.
• Erstellen Sie eine klare, wiederholbare Testmethodik, indem Sie Test- und Messwerkzeuge definieren.
• Messen Sie alle Metriken (TP/TN/FP/FN) während des Tests
• Testen Sie neue Lösungen und vergleichen Sie Metriken. Zum Beispiel könnte das IPS speziell für bessere TP-Raten für den bösartigen Datenverkehr abgestimmt werden, aber sicherstellen, dass auch FP/TN/FN-Raten gemessen und validiert werden. Dann kann die Wirksamkeit verschiedener Lösungen richtig bewertet werden, insbesondere in Bezug auf die Gesamtauswirkungen auf die Organisation, wie im Abschnitt "Auswirkungen" unten beschrieben.
• Testen Sie neue Datensätze und vergleichen Sie sie. Achten Sie darauf, die Datasets so anzupassen, dass sie angemessene Anpassungen durch einen Angreifer widerspiegeln. Es gibt mehrere Möglichkeiten, dies zu tun.
  • Beim Testen von Cobalt Strike können beispielsweise die C2 Malleable Profiles leicht modifiziert werden, um gutartige Apps etwas anders zu emulieren oder völlig neue gutartige Apps, die innerhalb des jeweiligen Unternehmens verwendet werden. Dies kann durch das Sniffing von ausgehendem HTTP/S-Datenverkehr über einen Proxy erfolgen.
  • Testen Sie nicht nur eines, sondern mehrere C2-Framework-Tools, da sie sich in Fähigkeiten und Techniken unterscheiden. Die Verwendung eines anderen C2-Framework-Tools ist ebenfalls eine gute Änderung, da das C2-Traffic-Shaping anders sein wird.
  • Das Erstellen einer benutzerdefinierten Test-Payload mit einer eigenen, handcodierten C2-Kommunikation ist eine weitere Möglichkeit, die Test-Datasets zu ändern, erfordert jedoch die meiste Zeit und Investition.

Prüfung der Belastbarkeit
Durch das Testen mit neuen Datensätzen über verschiedene Lösungen hinweg gewinnen wir auch wertvolle Einblicke in die Steifigkeit vs. Resilienz verschiedener Lösungen. In diesem Artikel haben wir das Problem angesprochen, dass hartcodierte und signaturbasierte Ansätze nicht nur weniger effektiv für die Erkennung von C2-Frameworks sind, sondern auch starr sind, was zu hohen FP/FN-Raten führt und eine einfache Umgehung mit einfachen Angriffsänderungen, wie z. B. formbaren Profiländerungen, ermöglicht.

Die Resilienz jeder Lösung kann getestet werden, indem sichergestellt wird, dass die Datensätze innerhalb des Vernünftigen modifiziert werden (d. h. innerhalb derselben TTP-Kategorie bleiben). Mit anderen Worten, wir können einen realistischen Resilienztest durchführen, indem wir die C2-Kommunikation innerhalb des bösartigen Datenverkehrsdatensatzes mit Hilfe von C2-formbaren Profilen ändern und die TP/TN/FP/FN-Raten überwachen. Wir sehen, wie die Abdeckung variiert, und wir verstehen auch, welche Änderungen an der Erkennungslösung vorgenommen werden müssen, um die Abdeckung für bestimmte TP/TN/FP/FN-Ziele aufrechtzuerhalten.

Ein erneutes Testen mit geänderten Datensätzen auf diese Weise ist vergleichbar mit einem Angreifer, der seine TTP ändert. Es bewertet die Ausfallsicherheit und Effektivität der neuen Erkennungslösung, da wir sehen können, ob sie immer noch in der Lage ist, Änderungen innerhalb derselben Bedrohungstechnikkategorie (C2-Kommunikation über HTTP/S) zu erkennen.

Falsch positive und falsch negative Auswirkungen
Die Messung der FP/FN-Raten ist gut und ermöglicht eine relative Verbesserung, aber wir müssen auch die Auswirkungen von FPS und FNs messen oder zumindest schätzen, da es sonst unmöglich ist, den tatsächlichen Nutzen einer Nachweislösung zu bewerten. Mit anderen Worten, ein RP-Satz von 1 % oder eine Verbesserung des RP-Satzes um 5 % hat keinen Kontext, es sei denn, wir können die Auswirkungen dieses 1 % oder +5 % auf eine Weise messen, die für die Entscheidungsträger im Sicherheitshaushalt sinnvoll ist.

Hier sind zwei Ansätze, die dabei helfen können, TP/TN/FP/FN-Sätze in eine quantifizierbarere Wirkung zu übersetzen:

1. Auswirkungen auf die Benutzer im Zeitverlauf: Betrachten Sie die absolute Anzahl falsch positiver Ergebnisse, die den FP-Raten entspricht, und normalisieren Sie sie im Laufe der Zeit als Rate pro Benutzer. Dies ist ein qualitatives Maß, aber oft sinnvoller als %-Sätze oder absolute Zahlen. Anstelle von 1 % FPs oder 2.437 falsch positiven Ergebnissen kann es beispielsweise einfacher sein, die Auswirkungen von 0,1 falsch positiven Ergebnissen pro Benutzer und Tag zu bewerten. Wenn es sich um ein sicheres Web-Gateway handelt, könnte jemand im Unternehmen anhand der Auswirkungen auf die Benutzer im Laufe der Zeit bestimmen, ob ein bestimmtes FP-Ziel akzeptabel ist. In diesem Fall führt C2-Framework-fähige Malware zu Sicherheitsverletzungen, und die Auswirkungen auf die Benutzer sind eher als Ausfallzeiten oder Datenverluste pro Benutzer über einen bestimmten Zeitraum gekennzeichnet. Wir haben eine Wahrscheinlichkeit von N%, jedes Jahr einen Verlust pro Benutzer zu $X. Dies sind oft grobe Schätzungen, aber jeder Anfang ist nützlich, da er durch regelmäßige Iteration überarbeitet und verbessert werden kann. Wenn die Auswirkungen im Laufe der Zeit in Bezug auf die Benutzer bewertet werden, wird es einfach, Erkennungs- oder Schutzlösungen zu bewerten, die oft nach der Anzahl der Benutzer pro Jahr berechnet werden.
2. Auswirkungen auf den Sicherheitsbetrieb in Bezug auf Zeit, Geld und Wahrscheinlichkeit von Sicherheitsverletzungen. Neben den Auswirkungen auf die Endbenutzer sollten auch die administrativen Auswirkungen bewertet werden, insbesondere auf die Betriebsmitarbeiter, die häufig Zeit mit der Bearbeitung von Erkennungswarnungen verbringen. Die Zeit, die für die Reaktion auf laute Warnungen aufgewendet wird, kann direkt in die VZÄ-Gehaltskosten umgerechnet werden. Der zusätzliche Faktor der Alarmmüdigkeit ist eine reale Auswirkung, die in Bezug auf die Wirksamkeit (Zeit bis zur Reaktion) und vor allem als Zeit- und Aufmerksamkeitsverlust für wirklich schwerwiegendere Bedrohungen, die verloren gehen oder nicht untersucht werden, abgeschätzt werden kann. Diese letztgenannte Auswirkung wird zu einem Faktor für die Auswirkungen von Sicherheitsverletzungen – Sicherheitsverletzungen sind wahrscheinlicher, wenn Sicherheitsvorgänge zu viele Fehlalarme aufweisen, die untersucht und gelöscht werden müssen.

Eine Folgenabschätzung ist oft der einzige Weg, um wichtige Erkenntnisse zu verstehen, wie z. B. die tatsächlichen Kosten der Erkennungswirksamkeit. Beispielsweise ist eine übermäßig aggressive Erkennungslösung mit einer Konfiguration aus niedrigen FNs und hohen FPs nutzlos und schädlich, da Sicherheitsvorgänge übermäßig viel Zeit mit der Reaktion auf Low-Fidelity-Warnungen verschwenden, anstatt sich an Aktivitäten mit höherer Hebelwirkung zu beteiligen. Ebenso setzt eine zu konservative Erkennungslösung mit niedrigen FPs, aber hohen FNs das Unternehmen einem hohen Risiko für eine potenzielle Sicherheitsverletzung aus, was aus Sicht der Gesamtrisikobewertung inakzeptabel sein kann.

Die Auswirkungen sollten gleichzeitig mit den Kernmetriken TP/FP/TN/FN geschätzt und bewertet werden.

Realitätsnahe Tests

Ein rotes Team mit Menschen, nicht nur mit automatisierten Sicherheitsverletzungen oder Pen-Test-Tools. Es wird dringend empfohlen, nicht nur Produktionsbenutzer und -umgebungen zum Testen von C2-Beaconing-Lösungen zu verwenden, sondern auch realistische gegnerische Szenarien wie Pen-Tests oder Bug-Bounties. Durch die Anpassung der Bounty-Beträge und -Anforderungen, um die explizite Implantation und erfolgreiche Post-Exploitation-Aktionen beliebter C2-Framework-Toolkits zu zeigen, können wir den "bösartigen Traffic" real und messbar machen. Dies könnte auf jede C2-Beaconing-Aktivität ausgeweitet werden, einschließlich benutzerdefiniertem Code zum Testen der Ausfallsicherheit der Erkennungslösung, und die Testanforderung sollte den Nachweis einer erfolgreichen täglichen Beaconing-Aktivität und Befehlsausführung über eine Woche ohne Erkennung umfassen.

Wenn ein externer Pentest oder ein Bug-Bounty-Programm wiederholt wird, sind die Unterschiede in den Erkennungsraten messbar und nützlich für die Bewertung der Wirksamkeit und des ROI.

Mit einem rigorosen Testansatz wird nicht nur die Wirksamkeit der Tests umfassend gemessen, sondern es können auch fortlaufende Ziele und Ziele relativ zu einem aktuellen/historischen Ausgangswert erstellt werden. Und wenn die gleichen Tests und Messungen für mehrere Lösungen durchgeführt werden, ist es sicherlich trivial, die Leistung zu vergleichen und Kauf-/Implementierungsentscheidungen zu treffen.

Forschung und Design im Zusammenhang mit diesen Konzepten und dem Gesamtansatz werden ausführlicher diskutiert in: Sicherheitssysteme und Methoden zur Erkennung von formbarer Führung und Kontrolle (Mulugeta).