Question 1

Un agente IA che tocca la mia infrastruttura, non è pericoloso?

Accepted Answer

È la domanda giusta da porsi. ThreatClaw è stato progettato attorno a questo vincolo: diversi livelli di difesa sono compilati direttamente nel binario, non configurabili, non aggirabili, non disattivabili dopo il deployment. In modalità predefinita, l'agente osserva e propone: non agisce mai senza l'approvazione umana esplicita (HITL tramite Slack/Telegram/email/Signal). Il codice è open source sotto licenza AGPL v3, quindi potete verificare ogni riga prima di distribuirlo.

Question 2

E se il LLM allucina o propone un'azione assurda?

Accepted Answer

L'IA non può mai attivare un'azione da sola. Ogni azione proposta passa attraverso un filtro statico compilato nel binario, che riconosce solo operazioni note, reversibili e con un obiettivo validato. Un suggerimento che non corrisponde ad alcuna azione prevista viene rifiutato prima dell'esecuzione. In modalità predefinita, l'operatore riceve la proposta completa (analisi + indicatori + impatto previsto) e approva con un clic nella chat, oppure rifiuta.

Question 3

IA locale o IA cloud, quale scegliere?

Accepted Answer

La nostra raccomandazione predefinita è l'IA locale (LLM tramite Ollama sul vostro server): il 100% dei vostri dati resta da voi, nessuna fuga possibile. L'IA cloud può essere aggiunta come secondo parere sui casi complessi o ambigui, in tal caso, tutti i dati sensibili vengono sostituiti automaticamente con token reversibili prima dell'invio. Il LLM cloud non vede mai un identificativo, un IP o una credenziale. La mappatura di ripristino vive solo in memoria, mai su disco.

Question 4

Come funziona l'anonimizzazione e cosa succede se le sfugge qualcosa?

Accepted Answer

Prima di qualsiasi chiamata a un LLM esterno, i dati passano attraverso un anonimizzatore scritto in Rust che rileva automaticamente gli identificativi sensibili più comuni (tecnici, finanziari, personali) e li sostituisce con token reversibili. Alla ricezione della risposta, i token vengono ripristinati in locale. La mappatura vive solo in memoria.

Il rischio residuo di qualsiasi anonimizzatore basato su pattern esiste, e lo riconosciamo. Tre mitigazioni: (1) potete arricchire la copertura con regole specifiche del vostro settore (nomi di progetti interni, convenzioni di denominazione), (2) l'opzione predefinita resta l'IA sovrana locale che non fa uscire alcun dato dal server, (3) il codice dell'anonimizzatore è open source AGPL, potete verificare ciò che sa rilevare e completarlo se necessario.

Question 5

Concretamente, cosa fa ThreatClaw?

Accepted Answer

ThreatClaw è un agente autonomo di cybersecurity che gira in continuo sulla vostra infrastruttura. Ingerisce le fonti di segnale disponibili (log syslog, alert IDS, eventi SIEM, scansioni, CTI), correla gli eventi attraverso più livelli di rilevamento e produce per ogni incidente un dossier completo: verdetto con livello di confidenza, indicatori di compromissione, perimetro colpito e da 1 a 3 azioni correttive pronte all'esecuzione. A seconda della modalità scelta: vi notifica e voi approvate (HITL), oppure esegue direttamente le azioni a basso rischio (autonomo).

Question 6

Quali azioni può eseguire sul mio sistema?

Accepted Answer

Tutte le azioni possibili sono definite nel codice open source, nessuna shell arbitraria, nessun comando dinamico. In generale: isolare un endpoint compromesso, bloccare un IP sul firewall, bloccare un account utente sospetto, mettere in quarantena un file dannoso, arrestare un container Docker, acquisire prove forensi. Ogni azione viene registrata in un audit log firmato crittograficamente, e qualsiasi azione distruttiva richiede l'approvazione umana in modalità predefinita.

Question 7

Quali fonti di osservazione può utilizzare ThreatClaw?

Accepted Answer

Oltre 19 fonti di segnale sono supportate nativamente: SIEM (Wazuh, FortiGate, OPNsense), firewall aziendali, agenti EDR (Velociraptor), log dei server Linux/Windows via syslog, scansioni delle vulnerabilità, threat intelligence (CrowdSec), alert IDS/IPS e qualsiasi apparecchiatura che parli il protocollo syslog standard. Una PMI tipica genera 4.500 alert/giorno di rumore; ThreatClaw consolida tutto ciò in una manciata di incidenti qualificati e azionabili.

Question 8

Come raccolgo i miei log?

Accepted Answer

ThreatClaw include un collettore syslog integrato in ascolto sulla porta standard 514. Puntate i vostri server Linux (auth.log, syslog), Windows (Event Log via syslog), firewall e container Docker verso quell'endpoint. I log vengono archiviati in un PostgreSQL locale e attraversano i livelli di rilevamento (regole Sigma, IDS, ML) che generano alert prioritizzati. Nessun SaaS esterno di log management necessario, tutto resta sul vostro server.

Question 9

Perché avete scelto Rust per il cuore dell'agente?

Accepted Answer

Un agente di sicurezza gira con privilegi elevati sull'infrastruttura del cliente. Se l'agente stesso ha bug di memoria, è un incubo. Rust elimina in fase di compilazione le classi di bug più sfruttate (buffer overflow, use-after-free, race condition, dereferenziazione di puntatore null). È un prerequisito non negoziabile, non una scelta estetica.

Question 10

ThreatClaw è conforme a NIS2 / GDPR / ISO 27001?

Accepted Answer

Risposta onesta: la conformità è un processo organizzativo che dipende dal vostro contesto, non una casella da spuntare in uno strumento. Ciò che ThreatClaw offre concretamente: audit trail crittografico utilizzabile come prova, 11 report normativi precompilati (NIS2, GDPR, ISO 27001, EU AI Act, ISO 42001, NIST AI RMF, NIST CSF 2.0, EU CRA, SOC 2, HDS, PCI-DSS), ritenzione dei dati configurabile per tabella, anonimizzazione dei dati personali prima di qualsiasi invio al cloud. Lo strumento documenta il vostro percorso, non lo sostituisce.

Question 11

Cosa succede se l'agente stesso viene compromesso?

Accepted Answer

È esattamente lo scenario per cui sono progettati i livelli di difesa integrati nel binario. Senza entrare nei dettagli (un agente difensivo non pubblica pubblicamente la mappa delle sue difese, politica anti-evasione), in generale: integrità del binario verificata all'avvio con rifiuto di avviarsi se manomesso, superficie d'azione limitata a operazioni note in fase di compilazione che un attaccante non può estendere, audit trail firmato per la ricostruzione forense, meccanismo di arresto automatico in caso di comportamento sospetto. Il codice sorgente AGPL v3 resta accessibile se volete verificarne i dettagli.

Question 12

Quante CVE ci sono in ThreatClaw?

Accepted Answer

Politica: zero CVE critiche tollerate nel binario di release. Il binario viene analizzato da cargo audit nella CI a ogni build, e l'SBOM (software bill of materials) viene pubblicato a ogni tag di release. Ogni CVE segnalata apre un ticket pubblico su GitHub con una finestra di patch di 72 ore per le CVE critiche. Potete verificare voi stessi lo stato del binario recuperando l'SBOM e sottoponendolo a scansione con il vostro strumento abituale (Trivy, Grype, ecc.).

Question 13

Di cosa ho bisogno per distribuire ThreatClaw?

Accepted Answer

Un server Linux con Docker installato. Minimo 8 GB di RAM (16 GB consigliati se attivate il LLM locale). 20 GB di disco (50 GB con i modelli IA scaricati). Un unico comando di installazione: `curl -fsSL https://get.threatclaw.io | sudo bash`. Un wizard di onboarding configura poi l'IA, i canali di comunicazione, il livello di autonomia e le fonti di log. Prevedete 30 minuti per un primo deployment funzionante.

Question 14

ThreatClaw è davvero gratuito?

Accepted Answer

Il codice è open source sotto licenza AGPL v3, gratuito e verificabile su GitHub (tutte le funzionalità sono identiche in ogni piano. Il piano Free consente di monitorare un numero limitato di asset (ideale per micro-imprese / PMI / lab). Per parchi più grandi, i piani a pagamento Starter / Pro / Business sbloccano limiti più elevati. Consultate la pagina Prezzi per i dettagli. L'accompagnamento umano (deployment, calibrazione, formazione del RSSI) è offerto separatamente da CyberConsulting.fr) è l'attività di servizi che finanzia lo sviluppo dello strumento.

Question 15

Posso monitorare più server / sedi?

Accepted Answer

Sì. Definite ogni target nella configurazione con una modalità (HITL predefinita / autonoma) e un tipo di accesso (SSH, WinRM, API esposta o agente locale sul target). L'istanza ThreatClaw centralizza le analisi ed esegue le azioni approvate sul target giusto. Per i contesti multi-sede è supportata un'architettura con collettori regionali + aggregatore centrale.

Question 16

Come vengo avvisato in caso di incidente?

Accepted Answer

Tramite i canali che configurate: email, Slack, Telegram, Discord, Signal o webhook personalizzato verso il vostro strumento interno. In modalità HITL, l'approvazione avviene direttamente nella chat (con nonce anti-replay per impedire il riutilizzo di un'approvazione passata). È disponibile anche una dashboard web in tempo reale per la vista centralizzata e i report di conformità.

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

I vostri feed di detection sono mappati ai requisiti normativi (NIS2, ReCyF)?

Accepted Answer

Sì. Ogni abbonamento include una mappa di copertura per requisito: per ogni requisito NIS2 (allegato ENISA) e ReCyF, indichiamo quali vostre regole lo affrontano, più l'elenco delle lacune. La catena è tracciabile e pubblica (Sigma a ATT&CK a NIST 800-53 a CSF 2.0 a NIS2). È copertura di progettazione: attesta che il catalogo affronta il requisito, non è né una certificazione né una misura in tempo reale. Molti requisiti sono puramente organizzativi e non possono essere coperti da regole; li mostriamo onestamente come lacune. La mappa è fornita come report leggibile e in OSCAL (lo standard machine-readable).

Question 32

Uso un GRC (CISO Assistant, ecc.). Posso importare la vostra copertura?

Accepted Answer

Sì, tramite un connettore. Crea o aggiorna il tuo audit nel GRC e, per ogni requisito coperto dalle tue regole, allega una prova e un controllo ThreatClaw, poi imposta il requisito su "da validare". Tu, o il tuo CISO, validate e assegnate il "conforme" finale: il connettore non spunta mai la tua conformità da solo, ti risparmia solo la precompilazione. Forniamo anche una library di corrispondenza caricabile e l'export OSCAL per altri strumenti. Nota tecnica: CISO Assistant non ingerisce OSCAL, quindi il nostro connettore usa la sua API REST.

Question 33

Coprite DORA?

Accepted Answer

Parzialmente, e lo diciamo con franchezza. A differenza di NIS2, non esiste una tabella di corrispondenza DORA ufficiale dell'UE. Quindi ancoriamo le nostre regole agli articoli DORA che supportano direttamente: detection (art. 8, 10), protezione (art. 9), test di resilienza (art. 24 a 27). Il nostro pack red-team è uno strumento di test che supporta l'articolo TLPT; non è l'incarico TLPT certificato con perimetro validato dall'autorità. La corrispondenza verso ISO o NIST passa per un framework terzo riconosciuto (SCF), citato come tale. Non rivendichiamo governance, segnalazione incidenti, gestione dei terzi né continuità.

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.

Le vostre domande. Le nostre risposte oneste.

L'IA e i vostri dati