
Produktionsreife Detection- & Response-Abfragen für osquery
osquery-Abfragen für Erkennung & Incident Response, mit über 250 produktionsreifen Abfragen.

ODK (osquery-defense-kit) ist insofern einzigartig, als die Abfragen dafür konzipiert sind, als Teil einer Produktions-Pipeline für Erkennung & Response eingesetzt zu werden. Die Erkennungsabfragen sind so formuliert, dass sie bei normalem erwartetem Verhalten null Zeilen zurückgeben, sodass sie so konfiguriert werden können, dass sie Warnmeldungen erzeugen, wenn Zeilen zurückgegeben werden.
Derzeit sind diese Abfragen überwiegend für die Ausführung auf POSIX-Plattformen (Linux & macOS) ausgelegt. Pull Requests zur Verbesserung der Unterstützung anderer Plattformen sind ausdrücklich willkommen.
Führen Sie make detect für eine Point-in-Time-Erkennung aus. Dies erkennt nicht so viel wie eine Produktionsinstallation, da kein Zugriff auf historische Ereignisse besteht.
Laden Sie ein veröffentlichtes Query-Pack an einen geeigneten Ort herunter und verweisen Sie in der packs-Stanza Ihrer osquery.conf-Datei auf diese Dateien.
Führen Sie make collect aus. Dies ist besonders nützlich für Vorher/Nachher-Analysen.
Führen Sie make packs aus. Für mehr Kontrolle können Sie osqtool direkt aufrufen, um Standardintervalle zu überschreiben oder Prüfungen auszuschließen.
Führen Sie make verify aus.
detection/ – Bedrohungserkennungsabfragen, abgestimmt auf die Erzeugung von Warnmeldungen.policy/ – Sicherheitsrichtlinienabfragen, abgestimmt auf die Erzeugung von Warnmeldungen.incident_response/ – Datensammlung zur Unterstützung bei der Reaktion auf mögliche Bedrohungen. Abgestimmt auf die periodische Beweissammlung.Die Erkennungsabfragen sind weiter nach den Taktikkategorien von MITRE ATT&CK unterteilt.
Zum Zeitpunkt der Veröffentlichung werden die Abfragen im Format des osquery-Query-Packs gebündelt. Informationen dazu, wie Sie jederzeit eigene Packs generieren können, finden Sie unter Lokale Pack-Generierung.
Hier ist eine unvollständige Liste der Abfragen, die auf der Grundlage dieser Abfragen einen Alarm ausgelöst hätten:
execution/tiny-executable-events.sqlexecution/tiny-executable.sqlexecution/tiny-executable-events.sqlexecution/tiny-executable.sqlexecution/unexpected-shell-parents.sqlexecution/sketchy-fetchers.sqlexecution/sketchy-fetcher-events.sqlc2/unexpected-talkers-linux.sqlc2/exotic-command-events.sqlc2/exotic-cmdline.sqlexecution/unexpected-executable-permissions.sqlexecution/unexpected-executable-directory-linux.sqlexecution/unexpected-tmp-executables.sqlc2/exotic-command-events.sqlc2/exotic-cmdline.sqlinitial_access/unexpected-shell-parents.sqlevasion/missing-from-disk-linux.sqlprivesc/unexpected-setxid-process.sqlprivesc/unexpected-privilege-escalation.sqlprivesc/events/unexpected-privilege-escalation-events.sqlevasion/name_path_mismatch.sqlpersistence/unexpected-cron-entries.sqlexecution/unexpected-executable-directory-linux.sqlHier ist eine unvollständige Liste der Phasen, die von bestimmten Abfragen erkannt worden wären:
Ausführung des ersten Drops, erkannt durch:
c2/unexpected-talkers-macos.sqlAusführung der zweiten Stufe, erkannt durch:
execution/unexpected-executable-directory-macos.sqlpersistence/unexpected-launch-daemon-macos.sqlexecution/unexpected-mounts.sqlTCC-Bypass, erkannt durch:
evasion/unexpected-env-values.sqlAusführung des Spionage-Agents, erkannt durch:
c2/unexpected-talkers-macos.sqlexecution/exotic-command-events.sqlexecution/unexpected-executable-directory-macos.sqlHilfe gesucht! Wir unterstützen jede neue Abfrage, solange sie leicht aktualisiert werden kann, um Fehlalarme zu behandeln.
Benutzer können Ausnahmen für Fehlalarme für bekannte, weit verbreitete Softwarepakete einreichen, müssen jedoch möglicherweise Belege für das Verhalten erbringen.
Obwohl der ursprüngliche Fokus auf Linux und macOS liegt, unterstützen wir das Hinzufügen von Abfragen auf jeder von osquery unterstützten Plattform.
Insbesondere wurden wir nach Windows-Unterstützung gefragt: Chainguard besitzt keine Windows-Rechner, aber wenn Sie Windows-Abfragen haben, die Ihrer Meinung nach nützlich wären und zu unserer Philosophie passen, nehmen wir sie sehr gerne an!
Wir bemühen uns, reale Fehlalarme aus unseren detection-Abfragen auszuschließen.
Die Verwaltung von Fehlalarmen ist leichter gesagt als getan – Pull Requests sind willkommen!
Zusammengenommen sollten Abfragen auf einem bereitgestellten System im Tagesdurchschnitt nicht mehr als 2 % der Wanduhrzeit verbrauchen.
Bereitgestellte Intervalle werden automatisch anhand der von osqtool unterstützten Tags bestimmt, das wir für die Pack-Erstellung verwenden.