Die Werkzeuge, die Sie schon betreiben, füttern Ihr Managementsystem.

Was dabei tatsächlich passiert

Die Kette ist kurz und sie ist durchgezogen. Zwischen Erkennung und zugewiesener Aufgabe tippt niemand etwas ab.

1. 1

   Melden

   Wazuh, Zabbix, Graylog, CrowdSec, TheHive und andere liefern Alarme, Schwachstellen und Anlagen in die Plattform.

2. 2

   Einordnen

   Aus der Meldung wird ein Vorfall oder eine Schwachstelle im Managementsystem, mit Herkunft, Zeitpunkt und Bezug zur betroffenen Anlage.

3. 3

   Einstufen

   Der OdyAgent liest den Vorfall, kennt den Katalog der Schweregrade, sucht vergleichbare Fälle und reicht eine Einstufung zurück.

4. 4

   Zuweisen

   Daraus entsteht auf Wunsch ein Ticket in Jira oder ServiceNow, mit Sperre gegen Doppelanlage und eigener Prüfspur.

Die Konnektoren zu Wazuh, Zabbix und den übrigen Melde- und Überwachungssystemen lesen. Geschrieben wird in die Ticketsysteme.

Cloud-Nachweise, ohne dass wir Ihre Cloud-Schlüssel halten

Für AWS, Azure, Google Cloud, Microsoft 365 und Kubernetes bindet OdySecure etablierte Open-Source-Prüfwerkzeuge an. Der Prüflauf startet in Ihrer Umgebung, mit Berechtigungen, die Sie selbst vergeben und verwalten. OdySecure empfängt den signierten Bericht. Aus Prowler und ScubaGear entstehen Nachweise an den Controls, aus Trivy Einträge im Schwachstellenmodul.

• Prowler

  Prüft AWS, Azure, Google Cloud, Microsoft 365 und Kubernetes gegen Hunderte Sicherheitsregeln und ordnet die Ergebnisse der ISO 27001 zu. In Prowler 5.39 ist über alle Umgebungen zusammen 58 Controls aus Anhang A mindestens eine technische Prüfung zugeordnet.

• ScubaGear

  Werkzeug der US-Behörde CISA. Prüft die Härtung von Microsoft 365 und Entra ID gegen die SCuBA-Baselines; die Zuordnung zur ISO 27001 läuft über die amtlichen Tabellen von CISA und NIST.

• Trivy

  Prüft Container-Abbilder und Abhängigkeiten auf bekannte Schwachstellen. Die Befunde landen im Schwachstellenmodul.

Jeder Nachweis aus Prowler und ScubaGear trägt einen Frischezustand: frisch unter 30 Tagen, veraltet von 30 bis 90 Tagen, danach abgelaufen. Im Audit ist also auch zu sehen, wann zuletzt geprüft wurde.

Ein bestandener Cloud-Check ist ein Beleg. Ob eine Kontrolle wirkt, bewertet ein Mensch. Nachweise entstehen auf diesem Weg für Controls mit zugeordneter Prüfung.

Endpunktschutz anbinden: Microsoft Defender, Intune und CrowdStrike Falcon

OdySecure liest Vorfälle und Geräte aus Ihrem Endpunktschutz aus, mit Leserechten, die Sie selbst vergeben und entziehen. Aus einem Vorfall oder Alarm dort wird ein Vorfall im Managementsystem. Geräte gehen als Vorschlag in den Anlagenbestand; übernommen wird, was ein Mensch bestätigt.

• Microsoft Defender und Intune

  Liest Vorfälle samt ihrer Alarme aus Microsoft Defender XDR sowie Geräte aus Defender for Endpoint und aus Intune. Die Schwachstellen je Gerät landen im Schwachstellenmodul. Angemeldet wird über eine App-Registrierung in Ihrem Microsoft-Verzeichnis mit vier Leserechten. Wir empfehlen ein Zertifikat statt eines Geheimnisses. Für die Schwachstellen braucht Defender eine Lizenz mit Schwachstellenverwaltung, etwa Defender for Endpoint P2. Wer nur Defender oder nur Intune nutzt, vergibt nur die passenden Rechte.

  Stand: Die Anbindung ist gebaut, ihre Abnahme an einem echten Microsoft-Mandanten steht noch aus. Bis sie bestanden ist, lässt sich die Anbindung nicht einschalten.

• CrowdStrike Falcon

  Liest Alarme und Endgeräte. Aus den Alarmen werden Vorfälle, die Endgeräte gehen als Vorschlag in den Anlagenbestand. Angemeldet wird über einen API-Client mit drei Lese-Scopes; schreibende Scopes fragt OdySecure nicht an.

  Stand: lässt sich seit September 2026 einschalten.

Alle diese Berechtigungen sind Leserechte. OdySecure kann deshalb in Defender, Intune oder Falcon nichts auslösen. Ein Gerät zu isolieren oder dort einen Vorfall zu schließen, bleibt bei Ihrem Team. Die Anbindung endet, sobald Sie die App-Registrierung oder den API-Client löschen. Was bis dahin übernommen wurde, bleibt im ISMS.

Häufige Fragen