Angreifer:innen machen Verteidiger:innen das Leben gerne schwer. Eine der besten Methoden für Angreifer:innen, unentdeckt zu agieren, besteht darin, Sicherheitstools auf einem kompromittierten Gerät zu deaktivieren.
Manchmal erledigen die Benutzer:innen die harte Arbeit für sie. Wenn ein:e frustrierte:r Benutzer:in einen Sicherheitsservice deaktiviert, der sie anscheinend bei der Arbeit behindert, eröffnet dies Angreifer:innen dieselbe Möglichkeit. Das gilt auch für unbeabsichtigte Aktionen, wie ein fehlgeschlagenes Update.
Leider versäumen es viele Verteidiger:innen auch, zu überprüfen, ob kritische Sicherheitstools ausgeführt werden, und schaffen dadurch einen eklatanten blinden Fleck. Die meisten Organisationen verlassen sich auf regelmäßige Compliance-Prüfungen, die diese Lücken zwischen den Audits weit offen lassen. Zu oft stellt ein Unternehmen erst nach einer Kompromittierung fest, ob Sicherheitstools aktiv waren, wenn es zu spät ist.
Deshalb freuen wir uns, erweiterte Statusprüfungen für den Okta Verify-Client für macOS und Windows einzuführen. Diese Funktion verwandelt jeden Authentifizierungsablauf in einen permanenten Tooling-Watchdog. Durch die Ausführung einer osquery-SQL-Abfrage in dem Moment, in dem ein Account versucht, sich zu authentifizieren, können Administrator:innen überprüfen, ob vorgeschriebene Sicherheitstools nicht nur bereitgestellt sind, sondern auch aktiv ausgeführt werden. Wenn die Schutzmaßnahmen fehlen, erhält das Gerät keinen Zugriff.
Im Folgenden sehen wir uns an, wie Sie diese Funktion nutzen können – aber beginnen wir zunächst damit, warum sie wichtig ist.
Die verborgene Lücke
Die meisten Unternehmen verfügen über eine klar definierte Liste von Tools, mit denen jeder verwaltete Endpoint ausgestattet sein sollte, von EDR-Agenten bis hin zu MDM-Geräten und darüber hinaus. Obwohl die genaue Zusammenstellung der Tools von Organisation zu Organisation variiert, erfüllt jede Kategorie von Sicherheitstools einen einheitlichen Zweck, der für eine gut geschützte Umgebung entscheidend ist.
Das Problem ist: nur weil Sie etwas bereitgestellt haben, bedeutet das nicht, dass es immer noch läuft. Agenten stürzen ab und Dienste werden deaktiviert – manchmal durch Benutzer:innen, die ihren Laptop beschleunigen möchten, und manchmal durch Malware, die genau weiß, welchen Prozess sie zuerst beenden muss. Ein VPN-Client liefert ein Update aus, das den Dienst unterbricht, und das Team erfährt erst davon, wenn Sie Wochen später ein Muster in den Helpdesk-Tickets bemerken. Nichts davon wird im regulären Monitoring erfasst, es sei denn, Sie suchen gezielt nach fehlenden Prozessen, und die meisten Teams tun dies nicht.
Dieses Problem wird dadurch verschärft, dass die meisten Compliance-Prüfungen das Vorhandensein des Sicherheitstools nur einmal überprüfen, selbst wenn es später nicht mehr den Compliance-Anforderungen entspricht. Erweiterte Statusprüfungen kehren dies um: Die Prüfung erfolgt bei jedem Authentifizierungsereignis. Stoppt ein Tool also um 09:00 Uhr, wird der Zugriff für die nutzende Person um 09:05 Uhr verweigert.
Beeinträchtigung der Abwehr in freier Wildbahn
Angreifer:innen wissen, dass sie bereits ein wichtiges Ziel erreicht haben, wenn sie Ihren Sicherheitsbetrieb blind machen können. Diese Aktionen sind so weit verbreitet, dass MITRE ATT&CK dafür eine eigene Taktik namens Defense Impairment hat, die aus 18 verschiedenen Techniken besteht. Eine der am weitesten verbreiteten Techniken ist T1685: Disable or Modify Tools, worauf sich unsere unten stehende Tooling-Watchdog-Abfrage konzentriert.
Während Angreifer:innen viele Kategorien von Sicherheitstools deaktivieren, ist der Einsatz von EDR-Killern bei Ransomware-Angriffen alltäglich geworden, wobei die Akteur:innen EDRs häufig vor der Verschlüsselung deaktivieren. Beispielsweise verlassen sich Betreiber:innen der Gentlemen-Ransomware auf ihre Malware „GentleKiller“, um Telemetrieprozesse wie osqueryd.exe zu deaktivieren. In ähnlicher Weise verwendet die Reynolds-Ransomware eine Bring-Your-Own-Vulnerable-Driver-Technik (BYOVD) und setzt einen anfälligen Treiber als Waffe ein, um lokale EDR-Agent-Prozesse auf einer Vielzahl von Plattformen zu beenden. Indem Sie verhindern, dass sich Geräte mit deaktivierten Tools bei Ihren geschützten Ressourcen (Apps und Daten) authentifizieren, können Sie diese Angreifer:innen stoppen, bevor sie erfolgreich Daten verschlüsseln.
Das Watchdog-Muster
Die Erkennungsabfrage, die wir in diesem Beitrag vorstellen – und die Sie im Repository okta/customer-detections finden – betrachtet dies als einen „digitalen Health Check“ für ein Benutzergerät. Anstatt nur nach einem einzelnen Prozess zu suchen, fungiert die Abfrage wie eine Scorecard. Die Abfrage vergibt an das Gerät einen Punkt für jede obligatorische Sicherheitstool-Kategorie, die aktiv ausgeführt wird, und das Gerät „besteht“ nur, wenn seine Gesamtpunktzahl den Zielwert erreicht. Jeder Kategorie von Sicherheitstools wird eine eigene Common Table Expression (CTE) zugewiesen, die eine 1 liefert, wenn ein relevanter Prozess derzeit aktiv ist, und eine 0, wenn nicht. Das Endergebnis fasst jede Kategorie zusammen und stellt sicher, dass die Prüfung die Authentifizierung nur dann zulässt, wenn jedes erforderliche Tool berücksichtigt wurde.
Hier ist ein Beispiel dafür, wie ein Gerät bewertet werden könnte …
Werden Telemetriedaten übermittelt? Ja, die Punktzahl ist also 1
Wird auf dem Gerät EDR ausgeführt? Ja, die Punktzahl ist also 1
Wird auf dem Gerät MDM ausgeführt? Ja, die Punktzahl ist also 1
Wird auf dem Gerät DLP ausgeführt? Ja, die Punktzahl ist also 1
Wird auf dem Gerät VPN/ZTNA ausgeführt? Nein, daher beträgt die Punktzahl 0
Wird auf dem Gerät DNS-Sicherheit ausgeführt? Ja, der Score ist also 1
Wird auf dem Gerät Schwachstellenmanagement ausgeführt? Ja, der Score ist also 1
Scorecard: 6 von 7 fehlgeschlagen! Daher würde dem Gerät kein Zugriff gewährt.
Es gibt sieben Kategorien, die jeweils die wichtigsten Anbieter in diesem Bereich für macOS und Windows abdecken:
WITH telemetry_running AS (
-- Fleet Orbit Supervisor + osquery-Daemon
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN ('osqueryd', 'orbit', 'osqueryd.exe', 'orbit.exe')
),
edr_running AS (
-- CrowdStrike Falcon | SentinelOne | VMware Carbon Black Cloud |
-- Microsoft Defender for Endpoint | Elastic Security | Palo Alto Cortex XDR |
-- FireEye/Trellix | Sophos | Trend Micro | ESET
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN (
'com.crowdstrike.falcon.Agent', 'CSFalconService.exe', 'falcon-sensor',
'SentinelAgent', 'SentinelAgent.exe', 'sentineld',
'cbagentd', 'CbDefense.exe',
'wdavdaemon', 'MsMpEng.exe', 'MsSense.exe',
'elastic-agent',
'CyveraConsole', 'CyServer.exe',
'xagt', 'xagt.exe',
'SophosScanD', 'SAVAdminService.exe',
'iCoreService', 'Ntrtscan.exe',
'esets_daemon', 'ekrn.exe'
)
),
Die verbleibenden fünf CTEs folgen demselben Muster für MDM, DLP, VPN/ZTNA, DNS-Sicherheit und Schwachstellenmanagement. Sie alle fließen in einen einzigen Bewertungsschritt ein:
final_score AS (
SELECT
CASE WHEN telemetry_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN edr_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN mdm_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dlp_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vpn_ztna_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dns_security_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vuln_scanner_running.total > 0 THEN 1 ELSE 0 END
AS score
FROM telemetry_running, edr_running, mdm_running, dlp_running,
vpn_ztna_running, dns_security_running, vuln_scanner_running
)
AUSWÄHLEN
CASE WHEN score = 7 THEN 1 ELSE 0
END AS security_tools_healthy
FROM final_score;
Einige Punkte, die bei der Struktur dieser Abfrage zu beachten sind:
Es misst die Kategorieabdeckung. Die Logik CASE WHEN total > 0 THEN 1 für jede Kategorie begrenzt jedes Signal auf 1, bevor sie alle addiert werden. Ohne dies würde ein einzelnes Tool, das fünf Prozesse erzeugt, mit 5 statt mit 1 zur Punktzahl beitragen, und ein Gerät, dem vier Tool-Kategorien fehlen, könnte dennoch bestehen, nur weil es über einen sehr aktiven EDR-Agenten verfügt. Die Obergrenze stellt sicher, was die Prüfung tatsächlich misst: die Kategorieabdeckung, nicht die Prozessanzahl.
Es normalisiert verschiedene Anbieter zu einem einheitlichen Signal. Diese Abfrage verwendet unabhängige CTEs anstelle einer einfacheren WHERE-Klausel, um über verschiedene Tool-Anbieter hinweg zu normalisieren. Unabhängig davon, ob auf einem Gerät CrowdStrike oder SentinelOne ausgeführt wird, ergibt die EDR-Kategorie immer eine „1“. Eine monolithische WHERE-Klausel würde eine reine Prozessanzahl zurückgeben, was den eigentlichen Punkt verfehlt: unabhängig davon, wie viele Prozesse das EDR erzeugt, wird es nur als ein einziges Tool gewertet.
Es deckt sowohl macOS als auch Windows ab. Eine der Herausforderungen bei der Erstellung plattformübergreifender Posture Checks besteht darin, dass macOS-Tools oft keine Windows-Entsprechung haben und umgekehrt.. Diese Prüfung regelt Folgendes: macOS-Geräte erhalten den Wert 1 für MDM über JamfDaemon, kandji-daemon, mosyled oder addigy-agent; Windows-Geräte erhalten den Wert 1 für den Intune-MDM-Prozess Microsoft.Management.Services.IntuneWindowsAgent.exe. Das Gleiche gilt für plattformspezifische EDR-Prozessnamen. Da jede Kategorie so konzipiert ist, dass sie beide Plattformen innerhalb derselben CTE abdeckt, bleibt der Schwellenwert auf beiden Betriebssystemen bei score = 7, sodass keine plattformspezifischen Varianten der Abfrage erforderlich sind.
Nutzen Sie es für sich
Nicht jede Organisation setzt alle sieben Tool-Kategorien ein. Zum Beispiel nutzen einige ihr EDR für das Schwachstellenmanagement und andere verwalten die DNS-Sicherheit möglicherweise auf der Netzwerkebene statt am Endpoint. Die Prozessnamenliste in jeder CTE deckt die wichtigsten Anbieter in jeder Kategorie ab, damit die Prüfung mit geringen bis keinen Anpassungen organisationsübergreifend funktioniert. Allerdings ist diese Abfrage ein Ausgangspunkt, keine endgültige Konfiguration. Bevor Sie diese Prüfung im Erzwingungsmodus bereitstellen, müssen Sie sie an Ihre Umgebung anpassen und testen.
Suchen Sie zunächst die spezifische Erkennungsabfrage im Repository „okta/customer-detections“. Wir empfehlen, das Projekt zu klonen.
Passen Sie als Nächstes die Abfrage an Ihre spezifische Umgebung an. Gehen Sie jede CTE durch und vergewissern Sie sich, dass der Prozessname Ihres Anbieters in der Liste enthalten ist – falls nicht, fügen Sie ihn hinzu. Senken Sie dann den Schwellenwert, sodass er der Anzahl der Kategorien entspricht, die Sie tatsächlich benötigen. (Beispielsweise sollte ein Stack mit fünf Tools =5 verwenden, nicht =7.) Wir empfehlen, die Prüfung lokal mit osqueryi auszuführen, um sie zu überprüfen. Verfeinern Sie die Prozessnamen und passen Sie den Score-Schwellenwert an, bis er perfekt auf die erforderliche Sicherheitstechnologie Ihrer Organisation abgestimmt ist.
Führen Sie die Abfrage eine Woche lang im Überwachungsmodus für Ihre Flotte aus. Dies zeigt Ihnen, welche Kategorien auf echten Geräten null verzeichnen, was oft das erste Anzeichen dafür ist, dass ein Tool vom erwarteten Zustand abgewichen ist.
Führen Sie die Abfrage im Durchsetzungsmodus aus, sobald Sie sicher sind, dass sie wie erwartet funktioniert.
Den Kreis schließen
Auch wenn diese Tooling-Watchdog-Prüfung vielleicht nicht spektakulär erscheint, ist sie eine wichtige Grundlage, die man eingerichtet haben sollte. Mit dieser Prüfung können Sie verifizieren, dass die Sicherheitstechnologie, für die Sie bezahlt und die Sie bereitgestellt haben, tatsächlich auf jedem Gerät ausgeführt wird, das sich in Ihrer Umgebung authentifizieren möchte.
In den nächsten Tagen werden wir untersuchen, was passiert, wenn Sie erweiterte Compliance-Prüfungen für eine völlig andere Herausforderung verwenden.
