Question 1

Un agente de IA que toca mi infraestructura, ¿no es peligroso?

Accepted Answer

Es la pregunta correcta. ThreatClaw está diseñado alrededor de esta restricción: varias capas de defensa están compiladas directamente en el binario, no configurables, no evitables. En modo predeterminado, el agente observa y propone: nunca actúa sin aprobación humana explícita (HITL vía Slack/Telegram/email/Signal). El código es open source bajo AGPL v3.

Question 2

¿Y si el LLM alucina o propone una acción absurda?

Accepted Answer

La IA nunca puede actuar sola. Cada acción propuesta pasa por un filtro estático compilado en el binario, que solo reconoce operaciones conocidas, reversibles, con objetivo validado. Una sugerencia que no coincide se rechaza antes de ejecutarse. En modo predeterminado, el operador recibe la propuesta completa y valida en el chat, o rechaza.

Question 3

IA local o IA en la nube, ¿cuál elegir?

Accepted Answer

Nuestra recomendación por defecto es IA local (LLM vía Ollama en su servidor): el 100 % de sus datos se quedan con usted. La IA en la nube puede añadirse como segunda opinión en casos complejos, en ese caso, los datos sensibles se sustituyen automáticamente por tokens reversibles. El LLM en la nube nunca ve identificadores reales.

Question 4

¿Cómo funciona la anonimización y qué pasa si omite algo?

Accepted Answer

Antes de cualquier llamada al LLM externo, los datos pasan por un anonimizador escrito en Rust que detecta identificadores sensibles comunes y los reemplaza con tokens reversibles. El mapeo vive solo en memoria.

El riesgo residual de cualquier anonimizador basado en patrones existe. Tres mitigaciones: reglas personalizadas, IA local por defecto, código open source auditable.

Question 5

Concretamente, ¿qué hace ThreatClaw?

Accepted Answer

ThreatClaw es un agente autónomo de ciberseguridad que se ejecuta continuamente. Ingiere fuentes de señal (syslog, IDS, SIEM, scans, CTI), correlaciona vía múltiples capas de detección, y produce para cada incidente un dossier completo. Según el modo: notifica para validación o ejecuta acciones de bajo riesgo.

Question 6

¿Qué acciones puede ejecutar?

Accepted Answer

Todas las acciones están definidas en el código open source, sin shell arbitrario. Aislar endpoints, bloquear IPs, bloquear cuentas, poner archivos en cuarentena, parar containers, capturar evidencia forense. Audit log firmado, aprobación humana por defecto para acciones destructivas.

Question 7

¿Qué fuentes puede consumir ThreatClaw?

Accepted Answer

19+ fuentes nativas: SIEM (Wazuh, FortiGate, OPNsense), firewalls, EDR (Velociraptor), logs Linux/Windows vía syslog, scans, CTI (CrowdSec), alertas IDS/IPS. Una pyme típica genera 4 500 alertas/día; ThreatClaw consolida en pocos incidentes accionables.

Question 8

¿Cómo recopilo mis logs?

Accepted Answer

ThreatClaw incluye un colector syslog integrado en el puerto 514. Apunta sus servidores Linux/Windows, firewalls y containers Docker. Logs en PostgreSQL local, pasan por las capas de detección. No se necesita SaaS externo.

Question 9

¿Por qué Rust para el núcleo del agente?

Accepted Answer

Un agente de seguridad se ejecuta con privilegios altos. Si tiene bugs de memoria, es un desastre. Rust elimina en compilación las clases de bugs más explotadas. Requisito obligatorio, no estético.

Question 10

¿ThreatClaw cumple con NIS2 / RGPD / ISO 27001?

Accepted Answer

Respuesta honesta: la conformidad es un proceso organizacional. Lo que ThreatClaw aporta: audit trail criptográfico, 11 informes regulatorios pre-rellenados, retención configurable, anonimización antes de envío cloud. El tool documenta, no reemplaza.

Question 11

¿Qué pasa si el agente es comprometido?

Accepted Answer

Es exactamente el escenario contra el que las capas de defensa están diseñadas. Sin detalle (no publicamos el mapa defensivo): integridad verificada al inicio, superficie limitada a operaciones conocidas en compile-time, audit-trail firmado, parada automática. Código AGPL disponible para auditar.

Question 12

¿Cuántas CVEs tiene ThreatClaw?

Accepted Answer

Política: cero CVE crítico tolerado en el binario release. cargo audit en CI, SBOM publicado por release. CVE reportadas → ticket público GitHub, parche 72h para críticas. Puede verificar usted mismo con Trivy/Grype.

Question 13

¿Qué necesito para desplegar ThreatClaw?

Accepted Answer

Un servidor Linux con Docker. Mínimo 8 GB RAM (16 GB con LLM local). 20 GB disco (50 GB con modelos IA). Comando: `curl -fsSL https://get.threatclaw.io | sudo bash`. Wizard de onboarding configura todo. 30 minutos para un primer deploy funcional.

Question 14

¿ThreatClaw es realmente gratis?

Accepted Answer

El código es open source AGPL v3, gratuito y auditable en GitHub, todas las funcionalidades idénticas en todos los tiers. El tier Free monitorea un número limitado de activos. Para parques mayores, Starter/Pro/Business desbloquean más capacidad. Ver Tarifas. El acompañamiento humano se factura aparte por CyberConsulting.fr.

Question 15

¿Puedo supervisar múltiples servidores / sitios?

Accepted Answer

Sí. Define cada objetivo con un modo (HITL/autónomo) y tipo de acceso (SSH, WinRM, API, agente local). La instancia centraliza análisis y ejecuta acciones. Multi-sitio soportado con colectores regionales + agregador central.

Question 16

¿Cómo se me alerta en caso de incidente?

Accepted Answer

Vía los canales que configures: email, Slack, Telegram, Discord, Signal o webhook custom. En modo HITL, aprobación en el chat (con nonce anti-replay). Dashboard web disponible para vista centralizada e informes de conformidad.

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

¿Tus feeds de detección están mapeados a los requisitos regulatorios (NIS2, ReCyF)?

Accepted Answer

Sí. Cada suscripción incluye un mapa de cobertura por requisito: para cada requisito NIS2 (anexo ENISA) y ReCyF, indicamos qué reglas tuyas lo abordan, más la lista de brechas. La cadena es trazable y pública (Sigma a ATT&CK a NIST 800-53 a CSF 2.0 a NIS2). Es cobertura de diseño: evidencia que el catálogo aborda el requisito, no es una certificación ni una medición en tiempo real. Muchos requisitos son puramente organizativos y no pueden cubrirse con reglas; los mostramos honestamente como brechas. El mapa se entrega como informe legible y en OSCAL (el estándar machine-readable).

Question 32

Uso un GRC (CISO Assistant, etc.). ¿Puedo importar vuestra cobertura?

Accepted Answer

Sí, mediante un conector. Crea o actualiza tu auditoría en el GRC y, por cada requisito que tus reglas cubren, adjunta una evidencia y un control ThreatClaw, y pone el requisito en estado "por validar". Tú, o tu CISO, validáis y afirmáis el "conforme" final: el conector nunca marca tu cumplimiento por sí solo, solo te ahorra el rellenado previo. También proporcionamos una library de correspondencia cargable y la exportación OSCAL para otras herramientas. Nota técnica: CISO Assistant no ingiere OSCAL, así que nuestro conector usa su API REST.

Question 33

¿Cubrís DORA?

Accepted Answer

Parcialmente, y lo decimos con franqueza. A diferencia de NIS2, no existe una tabla de correspondencia DORA oficial de la UE. Así que apoyamos nuestras reglas en los artículos DORA que respaldan directamente: detección (art. 8, 10), protección (art. 9), pruebas de resiliencia (art. 24 a 27). Nuestro pack red-team es una herramienta de prueba que apoya el artículo TLPT; no es la prestación TLPT certificada con alcance validado por la autoridad. La correspondencia hacia ISO o NIST pasa por un referencial tercero reconocido (SCF), citado como tal. No reivindicamos la gobernanza, el reporte de incidentes, la gestión de terceros ni la continuidad.

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.

Sus preguntas. Nuestras respuestas honestas.

La IA y sus datos