Question 1

Ein KI-Agent, der meine Infrastruktur berührt, ist das nicht gefährlich?

Accepted Answer

Das ist die richtige Frage. ThreatClaw wurde um diese Einschränkung herum entworfen: Mehrere Verteidigungsschichten sind direkt in die Binärdatei kompiliert, nicht konfigurierbar, nicht umgehbar. Im Standardmodus beobachtet und schlägt der Agent vor: Er handelt nie ohne explizite menschliche Genehmigung (HITL via Slack/Telegram/E-Mail/Signal). Der Code ist Open Source unter AGPL v3.

Question 2

Was, wenn das LLM halluziniert oder eine absurde Aktion vorschlägt?

Accepted Answer

Die KI kann nie allein handeln. Jede vorgeschlagene Aktion durchläuft einen statischen Filter, der nur bekannte, reversible Operationen mit validiertem Ziel erkennt. Ein Vorschlag, der nicht passt, wird vor der Ausführung abgelehnt. Im Standardmodus erhält der Operator den vollständigen Vorschlag und validiert mit einem Klick, oder lehnt ab.

Question 3

Lokale KI oder Cloud-KI, welche wählen?

Accepted Answer

Unsere Standardempfehlung ist lokale KI (LLM via Ollama auf Ihrem Server): 100 % Ihrer Daten bleiben bei Ihnen. Cloud-KI kann als zweite Meinung bei komplexen Fällen ergänzt werden, sensible Daten werden automatisch durch reversible Token ersetzt. Das Cloud-LLM sieht nie einen echten Identifier.

Question 4

Wie funktioniert die Anonymisierung und was, wenn sie etwas übersieht?

Accepted Answer

Vor jedem externen LLM-Aufruf durchlaufen Daten einen in Rust geschriebenen Anonymisierer, der gängige sensible Identifier erkennt und durch reversible Token ersetzt. Das Mapping lebt nur im Arbeitsspeicher.

Das Restrisiko jedes musterbasierten Anonymisierers besteht. Drei Maßnahmen: eigene Regeln, standardmäßig lokale KI, Open-Source-Code zur Auditierung.

Question 5

Was macht ThreatClaw konkret?

Accepted Answer

ThreatClaw ist ein autonomer Cybersecurity-Agent, der kontinuierlich läuft. Er sammelt Signalquellen (Syslog, IDS, SIEM, Scans, CTI), korreliert über mehrere Erkennungsschichten und produziert pro Vorfall ein komplettes Dossier. Je nach Modus: benachrichtigt er zur Validierung oder führt risikoarme Aktionen direkt aus.

Question 6

Welche Aktionen kann er auf meinem System ausführen?

Accepted Answer

Alle Aktionen sind im Open-Source-Code definiert, keine Shell, keine dynamischen Befehle. Endpoint isolieren, IP blocken, Konten sperren, Dateien in Quarantäne, Docker stoppen, forensisch sichern. Signiertes Audit-Log, menschliche Genehmigung für destruktive Aktionen im Standardmodus.

Question 7

Welche Beobachtungsquellen kann ThreatClaw nutzen?

Accepted Answer

19+ Signalquellen nativ unterstützt: SIEM (Wazuh, FortiGate, OPNsense), Firewalls, EDR (Velociraptor), Linux/Windows-Logs via Syslog, Schwachstellen-Scans, CTI (CrowdSec), IDS/IPS. Ein typisches KMU generiert 4 500 Alerts/Tag, ThreatClaw konsolidiert das auf wenige qualifizierte Vorfälle.

Question 8

Wie sammle ich meine Logs?

Accepted Answer

ThreatClaw enthält einen integrierten Syslog-Kollektor auf Port 514. Richten Sie Linux/Windows-Server, Firewalls und Docker-Container darauf aus. Logs in lokalem PostgreSQL, durchlaufen die Erkennungsschichten. Kein externer SaaS nötig.

Question 9

Warum Rust für den Agent-Kern?

Accepted Answer

Ein Sicherheits-Agent läuft mit hohen Privilegien. Hat er selbst Speicherfehler, ist das ein Albtraum. Rust eliminiert zur Kompilierzeit die am häufigsten ausgenutzten Bug-Klassen. Pflicht, kein ästhetischer Entscheid.

Question 10

Ist ThreatClaw NIS2- / DSGVO- / ISO-27001-konform?

Accepted Answer

Ehrliche Antwort: Compliance ist ein organisatorischer Prozess. Was ThreatClaw konkret bringt: kryptografischer Audit-Trail, 11 vorausgefüllte Berichte (NIS2, DSGVO, ISO 27001, EU AI Act, ISO 42001, NIST AI RMF, NIST CSF 2.0, EU CRA, SOC 2, HDS, PCI-DSS), konfigurierbare Datenspeicherung, Anonymisierung vor Cloud-Versand. Das Tool dokumentiert, ersetzt aber nicht.

Question 11

Was, wenn der Agent selbst kompromittiert wird?

Accepted Answer

Genau dieses Szenario ist die Verteidigungsschichten gewachsen. Ohne Details (kein öffentlicher Verteidigungs-Map, Anti-Evasion-Policy): Binär-Integrität beim Start, eingeschränkte Aktions-Surface, signiertes Audit-Log, automatischer Stopp bei Auffälligkeiten. AGPL-Quellcode für Audits verfügbar.

Question 12

Wie viele CVEs hat ThreatClaw?

Accepted Answer

Policy: null kritische CVE im Release-Binary toleriert. cargo audit in der CI bei jedem Build, SBOM bei jedem Release-Tag veröffentlicht. Gemeldete CVE → öffentliches GitHub-Ticket, 72-Stunden-Patch für kritische. Sie können selbst per Trivy/Grype prüfen.

Question 13

Was benötige ich, um ThreatClaw zu deployen?

Accepted Answer

Ein Linux-Server mit Docker. Mindestens 8 GB RAM (16 GB mit lokalem LLM). 20 GB Disk (50 GB mit KI-Modellen). Befehl: `curl -fsSL https://get.threatclaw.io | sudo bash`. Onboarding-Wizard konfiguriert alles. 30 Minuten für ein erstes funktionierendes Deployment.

Question 14

Ist ThreatClaw wirklich kostenlos?

Accepted Answer

Der Code ist Open Source AGPL v3, kostenlos und auf GitHub auditierbar, alle Funktionen identisch in allen Tiers. Der Free-Tier überwacht eine begrenzte Asset-Anzahl. Für größere Bestände schalten Starter / Pro / Business höhere Limits frei. Siehe Tarife. Onboarding wird separat von CyberConsulting.fr angeboten.

Question 15

Kann ich mehrere Server / Standorte überwachen?

Accepted Answer

Ja. Definieren Sie jedes Ziel mit einem Modus (HITL/autonom) und Zugriffstyp (SSH, WinRM, API, lokaler Agent). Die Instanz zentralisiert Analyse und führt genehmigte Aktionen aus. Multi-Site mit regionalen Kollektoren + zentralem Aggregator unterstützt.

Question 16

Wie werde ich bei einem Vorfall benachrichtigt?

Accepted Answer

Über die Kanäle, die Sie konfigurieren: E-Mail, Slack, Telegram, Discord, Signal oder benutzerdefinierter Webhook. Im HITL-Modus erfolgt die Genehmigung direkt im Chat (mit Anti-Replay-Nonce). Echtzeit-Web-Dashboard für zentrale Ansicht und Compliance-Berichte verfügbar.

Question 17

What are the ThreatClaw rule packs?

Accepted Answer

A subscription to ready-to-use detection rule packs, continuously updated and signed. They cover 8 engines, Sigma (SIEM/EDR), YARA (files/memory), NIDS Suricata (network), Falco (container/cloud), Nuclei (vulnerabilities), OPA (IaC compliance), osquery and Velociraptor (DFIR), plus IOC and LLM red-team feeds. Every rule ships with its investigation playbook. Full catalog: 6,400+ Sigma and 12,000+ YARA rules.

Question 18

Aren't these just repackaged open-source rules?

Accepted Answer

No. We forge our own in-house rules (malware families, offensive tools, LOLBins, vulnerable drivers, brand typosquatting…) you won't find anywhere else. For the community sources we do include, we genuinely curate them: per-file license verification, deduplication, validation on the real engine (a rule that doesn't compile doesn't ship), anti-false-positive testing on a large corpus. We don't resell scraped rules, we deliver proven detection.

Question 19

Is there a free demo pack?

Accepted Answer

Yes. A free sample of our in-house rules across every engine we run (Sigma, YARA, osquery, Velociraptor, Falco, network, policy), each detection with its CACAO 2.0 investigation playbook. The Sigma rules come already converted for 6 SIEMs (Splunk, Sentinel, Elastic, QRadar, CrowdStrike, Panther), and a NIS2 compliance sample is included. Downloadable directly from the "Rules" menu or the feed pages, no signup required.

Question 20

Do the Sigma rules come converted for my SIEM?

Accepted Answer

Yes. Every Sigma rule ships already converted for Splunk (SPL), Microsoft Sentinel (KQL), Elastic (Lucene), QRadar (AQL), CrowdStrike (LogScale) and Panther (SDYAML), paste straight into your SIEM. When a rule doesn't map cleanly to a SIEM (a field missing from its schema), we ship what genuinely converts rather than a broken query.

Question 21

What is an "investigation playbook"?

Accepted Answer

For every rule, a step-by-step sheet the analyst follows when the rule fires: confirm the alert, find the origin, scope the impact, remediation leads. In the CACAO 2.0 standard (OASIS), importable into your SOAR. Generated deterministically, without AI: each step derives from a fact the rule carries (ATT&CK, known false positives, MITRE D3FEND), nothing is invented, and the playbook is read-only (never an executable command; response stays a human decision).

Question 22

How often are the packs updated?

Accepted Answer

Continuously. Packs are rebuilt and published daily; your sync script picks up the new version on its next run. Each release is signed (Ed25519) and passes an anti-poisoning gate that refuses suspicious changes (mass detection removal, dangerous capability appearing without review).

Question 23

Can I use the rules without the ThreatClaw agent?

Accepted Answer

Yes. The rule subscription is decoupled from the agent: it's a standalone feed you plug into your own stack (SIEM, YARA engine, Suricata, osquery, etc.). The ThreatClaw agent consumes them natively, but it is not required.

Question 24

You aggregate several sources: how do you handle duplicates?

Accepted Answer

By similarity comparison between rules, not by matching names or hashes, which would let variants through. Near-duplicates are removed from the shipped pack, and the grey zone, rules that are close without being identical, is set aside for human review rather than shipped by default. It is an invisible part of the work and yet the first reason a raw aggregate is unusable in production.

Question 25

What format do the packs arrive in?

Accepted Answer

In the native format of the engine concerned, ready to load: nothing to convert on your side. Alongside it comes an index describing every rule with its security references, and thematic groupings by category, by attack technique or by compliance requirement. That is what lets you load a targeted subset rather than the whole pack, and evidence coverage to an auditor.

Question 26

How do I know the pack was not tampered with in transit?

Accepted Answer

Every release is signed with Ed25519, and your sync script verifies the seal before extracting anything: without a verifiable seal it refuses and stops, there is no fallback path. What matters is where the private key lives: never on the continuous-integration machine, the one that downloads third-party content and runs engines on it. It never leaves our own machine. The rule is simple: the machine that ingests untrusted content never holds the key.

Question 27

What stops someone from quietly weakening a rule upstream?

Accepted Answer

This is the real threat model for a detection feed, and it is not malware: nobody needs to execute code, adding one exclusion or breaking one condition is enough to blind every subscriber at once, silently. Two safeguards. Sources are pinned to an exact revision, so taking an upstream change is a deliberate act rather than something time does to you. And every release goes through a gate that compares it with the previous one: an abnormal delta quarantines the version and the feed you receive stays untouched.

Question 28

Is there any executable code in your packs?

Accepted Answer

No, never. A pack contains text only: rules, YAML, JSON, SQL. The scenario where you download and run a booby-trapped binary does not exist here. For the vulnerability-template pack, an extra filter drops anything that could act rather than observe, along with intrusive and denial-of-service categories.

Question 29

How do you keep a rule from drowning my SOC in false positives?

Accepted Answer

Two stages. At build time, every rule must compile on the real engine you actually run, not on a linter, and that check is blocking: what fails does not ship. Then the whole pack is audited against a corpus of real legitimate activity, not synthetic traffic, and rules that fire on it are dropped or moved to monitor-only. We do not claim zero false positives in your environment, which is not ours: we guarantee that a rule which is noisy on normal activity does not reach you unexamined.

Question 30

How is it licensed and priced?

Accepted Answer

The rule feed subscription is separate from the agent license (open source, AGPL v3). Part of the in-house rules is proprietary (not redistributable); community sources keep their original license, verified per file and documented. For subscription pricing, see the Pricing page or contact us.

Question 31

Sind Ihre Erkennungs-Feeds den regulatorischen Anforderungen (NIS2, ReCyF) zugeordnet?

Accepted Answer

Ja. Jedes Feed-Abo enthält eine Abdeckungskarte je Anforderung: Für jede NIS2-Anforderung (ENISA-Anhang) und ReCyF zeigen wir, welche Ihrer Regeln sie adressieren, samt Lückenliste. Die Kette ist nachvollziehbar und öffentlich (Sigma zu ATT&CK zu NIST 800-53 zu CSF 2.0 zu NIS2). Das ist Design-Abdeckung: Sie belegt, dass der Katalog die Anforderung adressiert, sie ist weder eine Zertifizierung noch eine Echtzeitmessung. Viele Anforderungen sind rein organisatorisch und lassen sich nicht per Regel abdecken; wir zeigen sie ehrlich als Lücken. Die Karte kommt als lesbarer Bericht und in OSCAL (dem maschinenlesbaren Standard).

Question 32

Ich nutze ein GRC (CISO Assistant usw.). Kann ich Ihre Abdeckung importieren?

Accepted Answer

Ja, über einen Connector. Er erstellt oder aktualisiert Ihr Audit im GRC und hängt für jede von Ihren Regeln abgedeckte Anforderung einen ThreatClaw-Nachweis und ein Control an, dann setzt er die Anforderung auf "zu prüfen". Sie oder Ihr CISO validieren und setzen das finale "konform": Der Connector hakt Ihre Compliance nie von selbst ab, er spart Ihnen nur das Vorbefüllen. Wir liefern außerdem eine ladbare Mapping-Library und den OSCAL-Export für andere Tools. Technischer Hinweis: CISO Assistant liest kein OSCAL ein, unser Connector nutzt daher dessen REST-API.

Question 33

Decken Sie DORA ab?

Accepted Answer

Teilweise, und das sagen wir offen. Anders als bei NIS2 gibt es keine offizielle EU-DORA-Zuordnungstabelle. Wir stützen unsere Regeln daher auf die DORA-Artikel, die sie direkt unterstützen: Erkennung (Art. 8, 10), Schutz (Art. 9), Resilienztests (Art. 24 bis 27). Unser Red-Team-Pack ist ein Testwerkzeug, das den TLPT-Artikel unterstützt; es ist nicht das behördlich abgegrenzte, zertifizierte TLPT-Engagement. Die Zuordnung zu ISO oder NIST läuft über ein anerkanntes Drittframework (SCF), als solches ausgewiesen. Governance, Vorfallmeldung, Drittparteienmanagement und Kontinuität beanspruchen wir nicht.

Question 34

Can I deploy your rules for my own clients?

Accepted Answer

Yes for the aggregated part, which comes exclusively from permissively licensed sources and stays redistributable, including for MSSP use. Copyleft components are isolated in their own bundle, under their own licence, with attribution. Our in-house forged rules are proprietary and reserved for your own subscriber use: they are not redistributable. Every pack ships a NOTICE file spelling out exactly what falls under what.

Question 35

What happens if I cancel my subscription?

Accepted Answer

You keep what you have already downloaded, we disable nothing remotely. What you lose is the flow: no new rules, no false-positive corrections, no coverage of threats that appear after you leave. That is the key thing to understand about this product: the value is not in today’s bundle, it is in the fact that it changes every week.

Ihre Fragen. Unsere ehrlichen Antworten.

KI und Ihre Daten