Digital Forensics and Incident Response (DFIR) – Teil 3

• Rückblick
• osquery
• osquery Agent Installation
• Überprüfen der Installation
• Agent Konfiguration
  • Enrollment Secret
  • Das TLS Zertifikat
  • Starten des osquery Agenten
  • Überwachung und Logs
  • Testen der Verbindung
• fleet
• fleet Installation
  • Konfiguration des osquery Servers
  • Konfiguration der osquery Agenten
    • Linux-Agent Konfiguration
    • Windows-Agent Konfiguration
  • Starten des Agenten
• Überwachung und Abfragen
• Abfragen und Auswertung
• Komplexere Abfragen
  • Netzwerkverbindungen
• Überlegungen zur Datenerfassung
• Zusätzliche Überlegungen
• Erweiterte Auswertung mit Hilfe von AI
• Anwendungsfälle für ML mit osquery
• Integrationsbeispiele
• Herausforderungen und Best Practices
• SIEM Integration

Rückblick

In den beiden vorangegangenen Artikeln wurden die drei Lösungen zur Erfassung von System und Infrastruktur Informationen vorgestellt:

• osquery
• Velociraptor
• WAZUH

In diesem und den zwei kommenden Artikel wird für ein besseres Verständnis versucht, Interessierten einen Einblick in die Interna dieser Anwendungen zu geben, die Art und Weise, wie sie ihre Arbeit verrichten, darzulegen und welche Unterstützung sie für die forensische Analyse bieten. Dazu wird eine Standardinstallation in ihre Bestandteile aufgeschlüsselt und die einzelnen Konfigurationsschritte dargelegt.

Der Artikel wird eine einfache, möglichst generische Installation der jeweiligen Lösungen aufzeigen und wie die Anwendung genutzt werden kann.

Wir verzichten hier auf die Installation von osquery als Server und zeigen in Bezug auf die Installation von osquery als Agent nur die grundlegende Konfiguration auf, da ansonsten für die Integration und Verteilung von Konfigurationen der FleetDM fleet Server zum Einsatz kommt.

osquery

Den Start wird osquery machen – als Agent. Den Server wird fleet mit seinem osquery Drop-In Replacement orbit übernehmen.

osquery steht als Installationspaket für verschiedene Linux Distributionen (Arch, Red Hat, Debian/Ubuntu, openSuse, SuSE Enterprise), Windows und MacOS zur Verfügung.

Technisch betrachtet ist eine osquery Installation immer die gleiche. Das Programm osqueryd (osquery daemon) fungiert sowohl als Agent auf den Clients als auch als Hauptkomponente der osquery Anwendung. Es wird zusammen mit der Installation von osquery bereitgestellt und muss nicht separat installiert werden.

Welche Funktion sie erfüllt, wird über die /etc/osquery/osquery.conf gesteuert. Die beide wesentlichen Tools sind:

• osqueryi: Das interaktive Befehlszeilen-Interface, das für Ad-hoc-Abfragen verwendet wird.
• osqueryd: Der Daemon, der als Agent läuft. Er führt geplante Abfragen im Hintergrund aus, überwacht den Zustand des Systems und sendet die gesammelten Daten an einen zentralen Server (wenn konfiguriert).

Sobald osquery installiert ist, sind sowohl osqueryi als auch osqueryd verfügbar.

Grundsätzlich kann die Installation der Agenten mit Hilfe einer schon vorhandenen Software Management oder MDM Lösung wie Microsoft System Center oder andere System oder (Mobile) Device Management verteilt und aktualisiert werden. Dies bedeutet allerdings eine Zweiteilung oder zusätzlich Schicht im gesamten Wartungsprozess.

Um zusätzliche Pflege von Konfigurations- und Überwachungsendpunkte zu vermeiden – beispielsweise sollten System oder Device Management Lösungen wie MS System Center in Bezug auf die erfolgreiche Verteilung ( die verteilte Software startet und lässt sich verwendet), ebenfalls überwacht werden.

Mit Blick auf System und Device Management Plattformen bietet sich der FleetDM fleet Server als idealer Begleiter einer osquery Plattform an.

Die beiden Software Lösungen verbindet seit der Entstehung Kolide Fleet eine gemeinsame Vergangenheit und seit der Einstellung von Kolide Fleet durch Kolide als aktives Open Source Projekt hat FleetDM den Code als Fork für ihre eigene fleet Lösungen übernommen und bietet eine kostenlose (Open Source) sowie eine kostenpflichtige Lösung mit Support und Ergänzungen für den Enterprise Einsatz an.

Seit der Übernahme von Kolide durch 1Password im Februar 2024 hat die Firma begonnen sein Portfolio neben dem Fleet Management auf Zero Trust Lösungen in Zusammenarbeit mit Okta zu erweitern und fokussiert sich ausschliesslich auf SaaS Lösungen.

osquery Agent Installation

osquery wird in diesem Artikel nur als Agent (Client) Komponente benötigt. Für die zentrale Verwaltung und Installation von weiteren Clients und das Sammeln von Logs und Systeminformationen von osquery Agenten auf verschiedenen Hosts empfiehlt es sich, eine Lösung wie fleet zu verwenden. Dazu weiter unten Im Kapitel fleet Installation mehr.

Bis Version 5.8.2 finden sich auf hub.docker.com osquery Images. Diese sind zum Zeitpunkt des Artikels seit einem Jahr nicht mehr aktualisiert worden. Die letzte osquery stabile Version ist derzeit 5.12.1 und diese wird nur als Paket bereitgestellt. Im Github Verzeichnis von osquery finden Interessierte unter osquery / tools / docker / ein README.md sowie die notwendigen Dateien, um mit Hilfe von docker build ein eigenes Image aus den osquery Paketen für Debian oder Red Hat zu erstellen.

Eine typische Paket basierte Installation für verschiedene Distributionen sieht wie folgt aus:

Arch Linux

Für Arch Linux und Derivate in den Paketquellen zur Verfügung und kann ohne zusätzliche Pakete installiert werden.

sudo pacman -Syu
sudo pacman -S osquery

Ubuntu/Debian

Hinzufügen der Paketquelle:

sudo apt-get update
sudo apt-get install -y gnupg software-properties-common curl
sudo add-apt-repository ppa:osquery/osquery
sudo apt-get update
sudo apt-get install -y osquery

Installation des osquery Paket:

sudo apt-get update
sudo apt-get install -y osquery

CentOS/RHEL

Hinzufügen der Paketquelle:

sudo yum update
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://pkg.osquery.io/rpm/osquery-s3-rpm.repo
sudo yum install -y osquery

Installation des osquery Paket:

sudo yum install -y osquery

Visualisierung einer osquery Server Installation:

Überprüfen der Installation

Nachdem die Installation abgeschlossen ist, kannst du überprüfen, ob osquery korrekt installiert wurde:

osqueryi --version

Dies sollte die installierte Version von osquery anzeigen.

Im Anschluss daran wird die entsprechende systemd Unit für den Start des osqueryd aktiviert und der osquery Dienst gestartet:

sudo systemctl enable osqueryd
sudo systemctl start osqueryd

Agent Konfiguration

Für den Agent wird eine JSON Konfiguration benötigt, in der für den "tls_hostname": Parameter der Name des fleet Servers eingetragen wird und im Parameter "tls_server_certs": der Pfad zum Zertifikat für die TLS Verbindung zum fleet Server sowie den Pfad im "enroll_tls_endpoint": Parameter zu der Datei mit dem Enrollment Secret.

Das Enrollment Secret wird im nächsten Schritt generiert.

Für Testzwecke reichen die übrigen Konfigurationsangaben aus. Für den produktiven Einsatz sollten die Angaben zu schedule, processes, decorators, packs und gegebenenfalls weitere Parameter auf die eigenen Bedürfnisse angepasst werden.

{
  "options": {
    "config_plugin": "filesystem",
    "logger_plugin": "tls",
    "logger_tls_endpoint": "/api/v1/osquery/log",
    "tls_hostname": "your-central-server.example.com:443",
    "tls_server_certs": "/etc/osquery/server.pem",
    "enroll_tls_endpoint": "/api/v1/osquery/enroll",
    "enroll_secret_path": "/etc/osquery/enroll_secret",
    "config_tls_endpoint": "/api/v1/osquery/config",
    "config_refresh": 10,
    "logger_path": "/var/log/osquery",
    "log_result_events": "true",
    "schedule_splay_percent": "10",
    "disable_logging": "false",
    "database_path": "/var/osquery/osquery.db",
    "extensions_autoload": "/etc/osquery/extensions.load",
    "extensions_timeout": "3",
    "utc": "true",
    "worker_threads": "2"
  },
  "schedule": {
    "system_info": {
      "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
      "interval": 3600
    },
    "processes": {
      "query": "SELECT * FROM processes;",
      "interval": 60
    }
  },
  "decorators": {
    "load": [
      "SELECT uuid AS host_uuid FROM system_info;",
      "SELECT user AS username FROM logged_in_users WHERE user <> '' LIMIT 1;"
    ]
  },
  "packs": {
    "osquery-monitoring": "/usr/share/osquery/packs/osquery-monitoring.conf"
  }
}

Enrollment Secret

In dem Oneliner muss der String des Enrollment Secret für die Authentifizierung des Agenten ersetzt werden.

echo "your-enrollment-secret" | sudo tee /etc/osquery/enroll_secret

Der Inhalt dieser Datei sollte mit dem enrollment secret übereinstimmen, das auf dem osquery-Server, hier fleet, konfiguriert ist.

Das TLS Zertifikat

Im produktiven Einsatz kommt hier ein kommerzielles Zertifikat zum Einsatz oder alternativ auch eines von Let’s Encrypt. Bei Let’s Encrypt ist darauf zu achten, dass die Chain das komplette Zertifikat, also inklusive des der signierenden Root CA enthält, da osquery nicht auf die CA des Host zurückgreift.

Für Testzwecke kann ein selbstsigniertes Zertifikat verwendet werden.

Den privaten Schlüssel erstellen:

openssl genrsa -out server.key 2048

Das selbstsigniertes Zertifikat erstellen:

openssl req -new -x509 -key server.key -out server.pem -days 365

In der Datei server.pem ist das Zertifikat, und die Datei server.key enthält den dazugehörigen privaten Schlüssel.

Anschliessend wird die Datei server.pem, die das Zertifikat enthält, auf den fleet Server kopiert. Der Pfad könnte z. B. /etc/osquery/server.pem sein.

Starten des osquery Agenten

Nachdem die Konfiguration abgeschlossen ist, wird der osquery-Daemon gestartet:

sudo systemctl enable osqueryd
sudo systemctl start osqueryd

Überwachung und Logs

Überprüfen der Logs, um sicherzustellen, dass der Agent korrekt mit dem Server kommuniziert:

sudo tail -f /var/log/osquery/osqueryd.results.log

Testen der Verbindung

Um zu überprüfen, ob der Agent erfolgreich mit dem Server verbunden ist und konfiguriert wurde, wird osqueryi eine Abfrage durchgeführt:

osqueryi --json "SELECT * FROM osquery_info;"

Damit wäre die Konfiguration eine ersten Agenten abgeschlossen. Dieser Vorgang wurde einmal manuell durchgespielt, um die einzelnen Schritte aufzuzeigen. In einer produktiven Umgebung erstellt fleet die Konfigurationen, stellt eine Paket mit Agent und Konfiguration zusammen und rollt die Agent auf die entsprechenden Hosts aus.

Der Agent wurde hiermit einmalig manuell konfiguriert. Im weiteren Verlauf soll der Agent aber seine Konfiguration von einem fleet Server beziehen. Dazu nimmt der Agent regelmässig Kontakt mit dem fleet Server auf und holt sobald eine neue Konfiguration vorliegt, diese ab.

Somit muss der Client durch System Management Software oder mit Hilfe von Software zur Automatisierung installiert werden.

Fleet Automations: Während Fleet nicht direkt die Installation übernimmt, ist es möglich über Fleet Richtlinien festlegen, die das Vorhandensein von osquery auf den Hosts überwachen und den Admin benachrichtigen, falls osquery nicht installiert ist. Es kann dann ein Skript oder eine Richtlinie erstellt werden, die auf Hosts ohne osquery hinweist, um das manuelle Deployment anzustoßen.

Konfigurationsmanagement-Tools: Tools wie Ansible, Puppet oder Chef können verwendet werden, um osquery-Pakete auf den Zielsystemen zu installieren und zu konfigurieren.

Softwareverteilungstools: Tools wie SCCM (für Windows) oder Munki (für macOS) könnten verwendet werden, um osquery-Pakete auf mehreren Systemen zu verteilen und zu installieren.

fleet

Seinen Urspung hat FleetDM fleet in dem ehemaligen Open Source Projekts Kolide Fleet. Das Kolide Projekt hat das Fleet Projekt im November 2020 eingestellt und dessen unter der MIT Lizenz stehenden Source Code diente als Basis für den Fork für FleetDM’s gleichnamige Lösung.

Während osquery in der aktuellen Version nicht als Docker Image für einen Container Betrieb bereitgestellt wird, kann man FleetDM jedoch als Docker Image bekommen – noch, denn auch hier zeichnet sich eine Tendenz zu einer ausschliesslichen Bereitstellung als SaaS ab.

Fleet kann die Konfiguration von osquery-Agenten über verschiedene Mechanismen zentral verwalten. Diese Konfiguration erfolgt hauptsächlich über das Fleet Web-Interface und wird über folgende Methoden an die Agenten weitergegeben:

1. Zentrale Konfigurationsdateien:
   • Fleet erlaubt es Administratoren, zentral Konfigurationsdateien für die osquery-Agenten zu erstellen und zu verwalten. Diese Konfigurationsdateien enthalten Einstellungen wie geplante Abfragen, Logging-Optionen, und andere Richtlinien.
   • Die Agenten holen sich regelmäßig die Konfiguration von Fleet über HTTP/S. Dabei fragt der osquery-Agent beim Fleet-Server nach Updates für seine Konfigurationsdatei.
2. Live Querying:
   • Fleet ermöglicht es Administratoren, Live-Abfragen an die osquery-Agenten zu senden, die auf den Hosts sofort ausgeführt werden. Die Ergebnisse werden dann in Echtzeit zurück an Fleet übermittelt.
3. Policy Management:
   • Fleet bietet ein Policy-Management-System, mit dem Administratoren Compliance-Checks definieren können. Die Agenten führen diese Richtlinien regelmäßig aus und melden den Compliance-Status zurück an den Server.
4. Distributed Queries:
   • Fleet kann verteilte Abfragen senden, die von den Agenten ausgeführt werden. Die Ergebnisse dieser Abfragen werden zentral gesammelt und analysiert.

Der gesamte Kommunikationsprozess zwischen Fleet und den osquery Agenten erfolgt über das TLS-Protokoll, was eine sichere und verschlüsselte Übertragung der Konfigurationsdaten und Abfrageergebnisse sicherstellt. Dies geschieht entweder direkt über den Fleet-Server oder in Kombination mit einem Proxy, je nach Netzwerkarchitektur und Sicherheitsanforderungen.

Wie im Kapitel osquery Agent Installation erwähnt fleet die Software Komponente orbit, welche als leichgewichtiger osquery Installer und Autoupdater fungiert. orbit kann zudem als Drop-In Replacement für osquery dienen und Daten der Agenten empfangen. fleet kann mit oder ohne orbit betrieben werden. fleet bietet eine webbasierte Oberfläche für das Management von osquery Client Konfigurationen und kann mit sowohl Windows- als auch Linux-Agenten kommunizieren.

Für Lasttrennung zwischen osquery Server Management und Abfragen über das UI besteht die Möglichkeit FleetDM fleet einmal als Adminstrations und Abfrage Instanz und einmal als Senke für die Agents zu installieren. Die Instanzen können für eine hohe Verfügbarkeit hinter einem haproxy oder anderen betrieben werden.

fleet benötigt eine MySQL Datenbank ab Version 8.x und verwendet das InnoDB Storage Backend. Für das Caching von Abfragen kann wird redis unterstützt. Single SignOn über SAML mit okta IDM als Identity Provider ist ebenfalls möglich.

fleet Installation

fleet wird in diesem Beispiel als Container bereitgestellt. Es wird eine aktuelle Docker Version 27.x vorausgesetzt.

In diesem Beispiel wird fleet nach /opt/containers/fleet installiert.

mkdir -R /opt/containers/fleet
cd /opt/containers/fleet
vi docker-compose.yml

Die folgenden Konfiguration wird für die fleet Container Installation verwendet:

services:
  fleet:
    image: fleetdm/fleet:v4.55.1
    ports:
      - "8080:8080"
      - "443:443"
    environment:
      - FLEET_URL=http://localhost:8080
      - MYSQL_USERNAME=fleet
      - MYSQL_PASSWORD=fleet_password
      - MYSQL_ROOT_PASSWORD=root_password
    volumes:
      - ./fleet-data:/var/lib/mysql
      - ./server.pem:/etc/osquery/server.pem
      - ./server.key:/etc/osquery/server.key
    depends_on:
      - mysql

  mysql:
    image: mysql:9.0.1
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
    volumes:
      - ./mysql-data:/var/lib/mysql

Anschliessend wird der Container gestartet.

sudo docker-compose up -d

Zugriff auf die Fleet-Weboberfläche:

Jetzt sollte im Browser unter der Adresse http://<your-server-ip>:8080 die Fleet-Weboberfläche zu sehen sein.

Konfiguration des osquery Servers

Fleet übernimmt die Konfiguration des zentralen Servers. Da der fleet Server künftig die osquery Agenten bereitgestellt, kann aus dem Kapitel für die osquery Agenten Installation die Konfiguration übernommen werden.

1. Erstellen des Enrollment Secrets: Auf der Fleet-Weboberfläche kannst du ein Enrollment Secret generieren. Dies wird in der Konfigurationsdatei der Agenten verwendet, um sie zu authentifizieren.
2. Server-Zertifikat: Sicherstellen, dass der Server mit einem SSL-Zertifikat gesichert ist. Wenn kein öffentliches Zertifikat vorhanden ist, kann ein selbstsigniertes Zertifikat verwendet werden.

Konfiguration der osquery Agenten

Linux-Agent Konfiguration

Für die Verwendung des osquery Agenten unter Linux kann die Konfigurationsdatei /etc/osquery/osquery.conf auf dem Linux-Client aus der Vorlage weiter oben aus dem Konfigurationsbeispiel und den entsprechenden Anpassungen für die Variablen aus dem Kapitel für die osquery Agenten Installation verwendet werden.

Windows-Agent Konfiguration

Unter Windows wird eine Konfigurationsdatei im Pfad C:\ProgramData\osquery\osquery.conf mit diesem Inhalt benötigt. Auch hier müssen in dem Parameter "tls_hostname": der Name des fleet Servers eingetragen werden und im Parameter "tls_server_certs": der Pfad zum Zertifikat für die TLS Verbindung zum fleet Server sowie den Pfad im "enroll_tls_endpoint": Parameter zu der Datei mit dem Enrollment Secret.

{
  "options": {
    "config_plugin": "tls",
    "logger_plugin": "tls",
    "tls_hostname": "your-central-server.example.com:443",
    "tls_server_certs": "C:\\ProgramData\\osquery\\server.pem",
    "enroll_tls_endpoint": "/api/v1/osquery/enroll",
    "enroll_secret_path": "C:\\ProgramData\\osquery\\enroll_secret",
    "config_tls_endpoint": "/api/v1/osquery/config",
    "logger_tls_endpoint": "/api/v1/osquery/log",
    "config_refresh": 10,
    "disable_logging": "false",
    "database_path": "C:\\ProgramData\\osquery\\osquery.db",
    "utc": "true"
  },
  "schedule": {
    "system_info": {
      "query": "SELECT hostname, cpu_brand, physical_memory FROM system_info;",
      "interval": 3600
    }
  },
  "decorators": {
    "load": [
      "SELECT uuid AS host_uuid FROM system_info;",
      "SELECT user AS username FROM logged_in_users WHERE user <> '' LIMIT 1;"
    ]
  }
}

Starten des Agenten

Linux:

sudo systemctl enable osqueryd
sudo systemctl start osqueryd

Windows:

Für Windows bitte sicherstellen, dass der osqueryd Dienst in den Diensten aktiviert und gestartet ist.

Überwachung und Abfragen

Mit Fleet können jetzt die Abfragen zentral verwalten, die Logs überwacht und die Daten visualisiert, die von den osquery-Agenten auf den Windows- und Linux-Hosts gesammelt werden.

Abfragen und Auswertung

Wir möchten noch eine Reihe von Abfragen vorstellen, die eine kleine Einführung in die Shell osqueryi und eine Anregung für eigene weiterführende Datenanalyse geben sollen.

osquery bietet eine SQL-ähnliche Sprache, um Daten abzufragen. Hier sind einige einfache Beispiele für Abfragen.

Grundlegende Informationen:

SELECT hostname, osversion, architecture FROM os;

Prozesse:

SELECT pid, name, parent_pid FROM processes;

Netzwerkverbindungen:

SELECT local_address, remote_address, state FROM process​_open​_sockets;

Dateisystem:

SELECT path, size FROM file;

Komplexere Abfragen

Netzwerkverbindungen

Trennung interner und externer IP Adressen

Zunächst eine Erfassung aller Netzwerkverbindungen, die als per Whitelist als intern deklariert sind. Die übrigen sind jene, den die Anfrage keinen bekannten Host zugeordnen werden können. Diese Abfrage kann einen schnellen Überblick über interne, in der Whitelist Tabelle erfasste IPs, und externe IP Adressen geben.

SELECT local_address, remote_address, state, 
       -- DNS-Auflösung (kann variieren je nach osquery-Version und Konfiguration)
       dns_name 
FROM process​_open​_sockets
WHERE remote_address NOT IN (SELECT ip_address FROM whitelist)
AND state = 'ESTABLISHED';

Diese Abfrage erstellt eine Tabelle, die die IP-Adresse, den Port der Verbindung, den Anwendungsnamen, den Pfad der ausführbaren Datei, die Aufrufparameter der ausführbaren Datei sowie das verwendete Protokoll enthält. Falls keine Anwendung zugeordnet werden kann, wird dies in der Spalte „process_name“ als „unbekannter Prozess“ angezeigt. Das Protokoll gibt Auskunft darüber, ob es sich um eine direkte TCP/UDP oder ein VPN handelt.
Dies kann Hinweise auf eine unbekannte, versteckt laufende Software geben.

SELECT
    p.pid,
    p.name AS process_name,
    IFNULL(p.path, 'unbekannter Prozess') AS executable_path,
    IFNULL(p.cmdline, '') AS cmdline,
    l.local_address,
    l.local_port,
    l.remote_address,
    l.remote_port,
    CASE
        WHEN l.remote_port IS NULL THEN 'LISTEN'
        ELSE 'ESTABLISHED'
    END AS connection_state,
    CASE
        WHEN l.protocol = 6 THEN 'TCP'
        WHEN l.protocol = 17 THEN 'UDP'
        WHEN l.protocol = 50 THEN 'ESP (IPsec)'
        WHEN l.protocol = 51 THEN 'AH (IPsec)'
        WHEN l.protocol = 47 THEN 'GRE'
        WHEN l.protocol = 115 THEN 'L2TP'
        ELSE 'UNKNOWN'
    END AS protocol
FROM
    process_open_sockets l
LEFT JOIN
    processes p
ON
    l.pid = p.pid
ORDER BY
    process_name, local_address, local_port;

Erläuterung der Abfrage:

• process_open_sockets: Diese Tabelle enthält Informationen zu allen offenen Netzwerkverbindungen, einschließlich der lokalen und entfernten IP-Adressen und Ports.
• processes: Diese Tabelle enthält Informationen zu laufenden Prozessen, einschließlich ihrer PID (Process ID), ihres Namens, des Pfads zur ausführbaren Datei und der Kommandozeilenparameter.
• LEFT JOIN: Verknüpft die Tabellen process_open_sockets und processes über die PID. Ein LEFT JOIN sorgt dafür, dass alle Einträge aus der Tabelle process_open_sockets enthalten sind, auch wenn keine zugehörige Anwendung (Prozess) gefunden wird.
• IFNULL(): Diese Funktion sorgt dafür, dass, wenn kein Wert für den Anwendungsnamen oder den Pfad zur ausführbaren Datei vorhanden ist, stattdessen der Text „unbekannter Prozess“ angezeigt wird.
• CASE-Konstruktion: Bestimmt, ob die Verbindung in einem „LISTEN“- oder „ESTABLISHED“-Status ist, basierend auf der Verfügbarkeit eines Remote-Ports.
• l.protocol: Das Feld protocol in der Tabelle process_open_sockets enthält die Protokollnummer. 6 steht für TCP und 17 für UDP. Andere Werte können ebenfalls vorhanden sein, falls es sich um andere Protokolle handelt. Die Beschreibung der numerischen Bezeichner können auf der Webseite der IANA unter Address Family Numbers nachgeschlagen werden.
• CASE-Konstruktion für das Protokoll: Diese CASE-Anweisung übersetzt die numerische Protokollnummer in ihre benannten Entsprechungen (TCP, UDP). Falls das Protokoll unbekannt ist, wird es als UNKNOWN gekennzeichnet.

Palantir hat auf Github das Repository Palantir osquery Configuration erstellt. Dieses wird seit 5-6 Jahren schon nicht mehr gepflegt, es kann dennoch als nützliche Quelle für Prozesslisten und andere Software, wie zum Beispiel Browser-Erweiterungen Hilfe bei dem Aufbau eigener Informationssammlungen über seine Hosts und andere Infrastrukturkomponenten geben.

Überlegungen zur Datenerfassung

Damit die ermittelten Informationen eine langfristigen Wert darstellen, sollten weitere Überlegungen respektive Planungen vorgenommen und im System Management Handbuch festgehalten werden.

Hier einige Beispielfragestellungen, die die Kapitel mit Vorgaben, Vorlagen und anderen ergänzenden wichtigen zusätzlichen Informationen füllen sollen.

• Wie sollen diese Daten dauerhaft und somit für Audits, Revisionen, Alarmierungen und Vergleichsanalysen im IR Fall oder als Basis für Visualisierungen auf einem Dashboard im OPC oder NOC festgehalten werden.
• Wie werden Fehlarme verhindert oder zumindest reduziert?
• Auf welchem Weg soll Visualisierung erfolgen?
• Welche Tools, Anwendungen oder Plattformen möchte ich für Dashbaords und andere grafische Darstellung verwenden?
• Welche Software wird für Auswertungen verwendet?
• Was sind die Datenquellen im Unternehmen
  • IPAM: Anwendungen für das Netzwerk und IP Adressmanagement
  • Service Management: CMDB
  • Dokumentation: DMS Lösungen wie Confluence, xWIKI,Microsoft Sharepoint, OpenKM, etc… .

Nachfolgend einige Ideen und Anregungen zu den Fragen zuvor:

Datenexport:

• Speichern der Ergebnisse: Speicherung der Ergebnisse der Abfrage in einem Format, das von dem jeweiligen Visualisierungstool unterstützt wird (z.B. CSV, JSON). Streaming von kontinuierlich erfassten Informationen in eine Datenbank mit entsprechendem Datenmodell und Überlegungen zu Aufbewahrungsfristen.
• Zeitliche Aufteilung: Um Trends zu erkennen, sollten die Ergebnisse zeitlich aufgeteilt werden und für jeden Zeitraum eine separate Datei erstellen.
• Snapshots und Aggregationserstellung: von langen Zeitreihen oder Datenaufkommen, damit Auditing weiterhin möglich ist, aber keine übermässige Datenhaltung stattfindet, deren späterer Nutzen möglicherweise gering oder durch Überalterung nicht merh vorhanden ist.

Visualisierung: Mögliche Tools und Visualisierungen:

• Grafana oder Kibana:
  • Zeitliche Entwicklung: Zeigen Sie die Anzahl unbekannter Verbindungen über die Zeit in einem Liniendiagramm an.
  • Top-Zieladressen: Erstellen Sie ein Balkendiagramm mit den am häufigsten kontaktierten IP-Adressen und deren zugehörigen Domains.
  • Geo-Visualisierung: Wenn die geografische Verteilung der IP Adressen bekannt ist, kann diese im Dahboard innerhalb einer Weltkarte dargestellt werden.
  • Suchfunktionen: Ermöglichen eine schnelle Suche nach bestimmten IP-Adressen oder Domains.
  • Beide Anwendungen, Grafana wie Kibana bietet eine hohe Flexibilität bei der Gestaltung von Dashboards.
• Andere Tools:
  • Python: Mit Bibliotheken wie Matplotlib, Seaborn oder Plotly können Sie individuelle Visualisierungen erstellen.
  • R: Mit Paketen wie ggplot2 oder plotly können Sie ebenfalls hochwertige Grafiken erzeugen.

Zusätzliche Überlegungen

• Whitelist: Eine sorgfältig gepflegte Whitelist bekannter Verbindungen ist unerlässlich, um Fehlalarme zu reduzieren. Um eine Whitelist zu erstellen, bedarf es zuvor eine Erfassung aller Systemprozesse des jeweiligen Betriebessystems und aller auf dem OS laufen Unternehmensanwendungen und ihrer Subprozesse.
• DNS-Auflösung: Die DNS-Auflösung kann zeitaufwendig sein und die Performance beeinträchtigen. Es kann sinnvoll sein, die Auflösung in bestimmten Intervallen durchzuführen oder einen Caching-Mechanismus zu verwenden.
• Anreicherung: Die Daten um zusätzliche Informationen anreichern, z.B. durch Abgleich mit Threat Intelligence Feeds, um die Bedeutung der Verbindungen besser einzuschätzen.
• Automatisierung: Integrierung von wichtigen Abfragen, Datenexporter und Visualisierungen in eine automatisierte Pipeline, um regelmäßige Updates zu erhalten.

Erweiterte Auswertung mit Hilfe von AI

Die Integration von maschinellem Lernen (ML) in osquery eröffnet zusätzliche Möglichkeiten zur Erkennung von Anomalien und zur Proaktiven Sicherheit. Hier sind einige Anwendungsfälle und Integrationsbeispiele:

Anwendungsfälle für ML mit osquery

• Anomalieerkennung:
  • Netzwerkverkehr: Identifikation ungewöhnlicher Verbindungsmuster, Protokollnutzungen oder Datenübertragungsraten.
  • Systemverhalten: Erkennung von Abweichungen in Systemressourcenverbrauch, Prozessverhalten oder Dateisystemzugriffen.
• Bedrohungsdetektion:
  • Malware: Erkennung von charakteristischen Verhaltensweisen von Malware, wie z.B. die Ausführung verdächtiger Befehle oder die Kommunikation mit bekannten Command-and-Control-Servern.
  • Insider-Bedrohungen: Identifizierung von ungewöhnlichem Nutzerverhalten, das auf böswillige Aktivitäten hinweisen könnte.
• Vorhersage von Ausfällen:
  • Hardware: Vorhersage von Hardwareausfällen basierend auf Sensordaten und historischen Leistungsmetriken.
  • Software: Identifizierung von potenziellen Softwarefehlern oder Instabilitäten.

Integrationsbeispiele

1. Direkte Integration in osquery:

• Benutzerdefinierte Funktionen:
  • Schreiben Sie benutzerdefinierte Funktionen in SQL oder einer anderen unterstützten Sprache, um ML-Modelle zu laden und Vorhersagen zu treffen.
  • Beispiel: Eine Funktion, die ein Modell zur Erkennung von DDoS-Angriffen auf Basis von Netzwerkverkehrsdaten lädt und die Ergebnisse zurückgibt.
• Plugins:
  • Entwickeln Sie Plugins, um osquery um neue Funktionen zu erweitern.
  • Beispiel: Ein Plugin, das regelmäßig ein ML-Modell zur Erkennung von Anomalien in Logdateien trainiert und aktualisiert.

2. Integration über eine Datenpipeline:

• Datenextraktion: Verwenden Sie osquery, um relevante Daten (z.B. Netzwerkverbindungen, Prozessinformationen, Logdateien) zu extrahieren.
• Datenspeicherung: Anbindung einer Streamingdatenbank an osquery und Speichern von Anfragen mit hoher Kadenz und geringer Lasterzeugung
• Datenaufbereitung: Bereiten Sie die Daten für das ML-Modell vor (z.B. Feature Engineering, Normalisierung).
• Modelltraining: Trainieren Sie ein ML-Modell (z.B. Random Forest, Support Vector Machine) auf den vorbereiteten Daten.
• Vorhersage: Verwenden Sie das trainierte Modell, um Vorhersagen zu treffen und Anomalien zu identifizieren.
• Visualisierung: Visualisieren Sie die Ergebnisse mit Tools wie Grafana oder Kibana.

3. Integration in eine SIEM-Lösung:

• Datenexport: Exportieren Sie osquery-Daten in eine SIEM-Lösung (z.B. Exabeam, Splunk, Elastic).
• ML-Integration: Nutzen Sie die ML-Fähigkeiten der SIEM-Lösung oder integrieren Sie ein externes ML-Modell.
• Anomaliedetektion: Identifizieren Sie Anomalien basierend auf den osquery-Daten und anderen relevanten Informationen.

Herausforderungen und Best Practices

• Datenqualität: Stellen Sie sicher, dass die von osquery extrahierten Daten sauber und vollständig sind.
• Modellwahl: Wählen Sie das geeignete ML-Modell für die jeweilige Aufgabe aus.
• Feature Engineering: Die Auswahl und Erstellung relevanter Features ist entscheidend für die Leistung des Modells.
• Modellwartung: Modelle müssen regelmäßig neu trainiert und aktualisiert werden, um sich an verändernde Bedingungen anzupassen.
• False Positives und False Negatives: Finden Sie einen guten Kompromiss zwischen Sensitivität und Spezifität.

SIEM Integration

Die Integration von osquery in SIEM-Systeme (Security Information and Event Management) ist ein wichtiger Schritt, um eine umfassende Sichtbarkeit auf die Sicherheit Ihrer IT-Infrastruktur zu erhalten.

Warum SIEM und osquery zusammen?

• Erweiterte Analyse: SIEM-Systeme bieten leistungsstarke Analysefunktionen, um Muster, Anomalien und Bedrohungen in großen Datenmengen zu erkennen.
• Korrelation: Sie können osquery-Daten mit anderen Sicherheitsdaten (z.B. Firewall-Logs, IDS-Alarme) korrelieren, um einen umfassenderen Kontext zu erhalten.
• Automatisierung: SIEM-Systeme ermöglichen die Automatisierung von Reaktionen auf Sicherheitsvorfälle, wie z.B. das Auslösen von Alarmen oder das Blockieren von IP-Adressen.

Welche SIEM-Systeme lassen sich integrieren?

Die meisten gängigen SIEM-Systeme bieten Schnittstellen für die Integration externer Datenquellen. Dazu gehören:

• FleetDM: Fleet selber bietet SIEM Funktionalität, mit vulnerability check, Berichten, Datenkontexte bis auf Chip-Level, Automatic CVE Mitigation.
• Exabeam: Die auf Google Cloud basierende Cloud-native Architektur bietet eine schnelle Datenaufnahme, eine extrem schnelle Abfrageleistung sowie leistungsstarke Verhaltensanalysen und KI.
• Splunk: Sehr flexibel und anpassbar, unterstützt eine Vielzahl von Datenformaten und bietet leistungsstarke Such- und Analysefunktionen.
• Elastic Stack: Basiert auf Elasticsearch, Logstash und Kibana, bietet eine Open-Source-Alternative mit hoher Skalierbarkeit.
• IBM QRadar: Kommerzielles SIEM mit umfangreichen Funktionen zur Bedrohungserkennung und -reaktion.
• Microsoft Sentinel: Cloud-native SIEM-Lösung, die eng mit anderen Microsoft-Produkten integriert ist.
• ArcSight: Etablierte SIEM-Lösung mit Fokus auf große Unternehmen.

Wie erfolgt die Integration?

Die genaue Vorgehensweise hängt vom jeweiligen SIEM-System und der gewünschten Tiefe der Integration ab. Im Allgemeinen gibt es folgende Möglichkeiten:

1. Syslog:
   • osquery oder fleet kann seine Ergebnisse direkt als Syslog-Nachrichten an den SIEM-Server senden.
   • Vorteile: Einfach einzurichten, weit verbreitet.
   • Nachteile: Beschränkte Flexibilität bei der Datenformatierung.
2. HTTP-API:
   • osquery oder fleet kann seine Ergebnisse über eine HTTP-API an das SIEM-System senden.
   • Vorteile: Hohe Flexibilität bei der Datenformatierung, ermöglicht komplexere Integrationen.
   • Nachteile: Mehr Konfigurationsaufwand.
3. Forwarder:
   • Ein Forwarder-Agent sammelt die osquery-Ergebnisse und leitet sie an das SIEM-System weiter.
   • Vorteile: Zentralisierte Verwaltung, zusätzliche Verarbeitungsmöglichkeiten.
   • Nachteile: Erhöhte Komplexität.

Beispiel: Integration von osquery in Splunk

• osquery Konfiguration: Konfigurieren Sie osquery so, dass es seine Ergebnisse in einem bestimmten Format (z.B. JSON) an einen HTTP-Endpoint sendet.
• Splunk Konfiguration: Richten Sie in Splunk einen HTTP-Eingang ein, um die Daten von osquery zu empfangen.
• Datenverarbeitung: Verwenden Sie Splunk’s Suchsprache, um die Daten zu durchsuchen, zu filtern und zu visualisieren.

Beispiel-Abfrage in Splunk:

index=osquery source=my_osquery_host sourcetype=osquery_results process_name="*"
| stats count by process_name

Weitere Überlegungen:

• Daten Enrichment: Ergänzen der osquery-Daten mit zusätzlichen Informationen aus anderen Quellen (z.B. Active Directory, DNS).
• Alerting: Konfiguration von Alarmen, um auf bestimmte Ereignisse aufmerksam zu machen (z.B. ungewöhnliche Prozessaktivitäten, neue Benutzerkonten).
• Automatisierung: Verwenden der Möglichkeiten des SIEM-Systems, um automatisierte Reaktionen auf Sicherheitsvorfälle einzurichten (z.B. Quarantäne von infizierten Systemen).