Question 1

Um agente de IA que mexe na minha infraestrutura, não é perigoso?

Accepted Answer

É a pergunta certa a fazer. O ThreatClaw foi concebido em torno desta restrição: várias camadas de defesa são compiladas diretamente no binário, não configuráveis, não contornáveis, não desativáveis após a implantação. No modo padrão, o agente observa e propõe: nunca age sem aprovação humana explícita (HITL via Slack/Telegram/email/Signal). O código é open source sob AGPL v3, portanto você pode auditar cada linha antes de implantar.

Question 2

E se o LLM alucinar ou propuser uma ação absurda?

Accepted Answer

A IA nunca pode acionar uma ação por conta própria. Cada ação proposta passa por um filtro estático compilado no binário, que só reconhece operações conhecidas, reversíveis e com alvo validado. Uma sugestão que não corresponde a nenhuma ação prevista é rejeitada antes da execução. No modo padrão, o operador recebe a proposta completa (análise + indicadores + impacto previsto) e valida com um clique no chat, ou recusa.

Question 3

IA local ou IA na nuvem, qual escolher?

Accepted Answer

A nossa recomendação padrão é a IA local (LLM via Ollama no seu servidor): 100% dos seus dados ficam com você, nenhum vazamento é possível. A IA na nuvem pode ser adicionada como segunda opinião em casos complexos ou ambíguos, nesse caso, todos os dados sensíveis são automaticamente substituídos por tokens reversíveis antes do envio. O LLM na nuvem nunca vê um identificador, IP ou credencial. O mapeamento de restauração vive apenas na memória, nunca em disco.

Question 4

Como funciona a anonimização e o que acontece se ela deixar algo passar?

Accepted Answer

Antes de qualquer chamada a um LLM externo, os dados passam por um anonimizador escrito em Rust que detecta automaticamente os identificadores sensíveis comuns (técnicos, financeiros, pessoais) e os substitui por tokens reversíveis. Ao receber a resposta, os tokens são restaurados localmente. O mapeamento vive apenas na memória.

O risco residual de qualquer anonimizador baseado em padrões existe, e nós o reconhecemos. Três mitigações: (1) você pode enriquecer a cobertura com as suas próprias regras específicas do seu negócio (nomes de projetos internos, convenções de nomenclatura), (2) a opção padrão continua sendo a IA soberana local que não retira nenhum dado do servidor, (3) o código do anonimizador é open source AGPL, você pode auditar o que ele sabe detectar e complementá-lo se necessário.

Question 5

Concretamente, o que o ThreatClaw faz?

Accepted Answer

O ThreatClaw é um agente autônomo de cibersegurança que roda continuamente na sua infraestrutura. Ele ingere as fontes de sinal disponíveis (logs syslog, alertas IDS, eventos SIEM, scans, CTI), correlaciona os eventos por meio de várias camadas de detecção e produz para cada incidente um dossiê completo: veredito com nível de confiança, indicadores de comprometimento, perímetro afetado e 1 a 3 ações corretivas prontas para executar. Conforme o modo escolhido: ele notifica você para validação (HITL) ou executa diretamente as ações de baixo risco (autônomo).

Question 6

Quais ações ele pode executar no meu sistema?

Accepted Answer

Todas as ações possíveis são definidas no código open source, nenhum shell arbitrário, nenhum comando dinâmico. Em geral: isolar um endpoint comprometido, bloquear um IP no firewall, bloquear uma conta de usuário suspeita, colocar um arquivo malicioso em quarentena, parar um container Docker, capturar evidências forenses. Cada ação é registrada em um log de auditoria assinado criptograficamente, e qualquer ação destrutiva exige aprovação humana no modo padrão.

Question 7

Quais fontes de observação o ThreatClaw pode consumir?

Accepted Answer

Mais de 19 fontes de sinal são suportadas nativamente: SIEM (Wazuh, FortiGate, OPNsense), firewalls corporativos, agentes EDR (Velociraptor), logs de servidores Linux/Windows via syslog, scans de vulnerabilidades, threat intelligence (CrowdSec), alertas IDS/IPS e qualquer equipamento que fale o protocolo syslog padrão. Uma PME típica gera 4.500 alertas/dia de ruído; o ThreatClaw consolida tudo isso em alguns poucos incidentes qualificados e acionáveis.

Question 8

Como eu coleto os meus logs?

Accepted Answer

O ThreatClaw inclui um coletor syslog integrado que escuta na porta padrão 514. Aponte os seus servidores Linux (auth.log, syslog), Windows (Event Log via syslog), firewalls e containers Docker para esse endpoint. Os logs são armazenados em um PostgreSQL local e passam pelas camadas de detecção (regras Sigma, IDS, ML) que geram alertas priorizados. Nenhum SaaS externo de gerenciamento de logs é necessário, tudo permanece no seu servidor.

Question 9

Por que escolheram Rust para o núcleo do agente?

Accepted Answer

Um agente de segurança roda com privilégios elevados na infraestrutura do cliente. Se o próprio agente tiver bugs de memória, é um pesadelo. Rust elimina em tempo de compilação as classes de bugs mais exploradas (buffer overflow, use-after-free, condições de corrida, dereferência de ponteiro nulo). É um pré-requisito inegociável, não uma escolha estética.

Question 10

O ThreatClaw está em conformidade com NIS2 / RGPD / ISO 27001?

Accepted Answer

Resposta honesta: a conformidade é um processo organizacional que depende do seu contexto, não uma caixa a marcar em uma ferramenta. O que o ThreatClaw traz concretamente: trilha de auditoria criptográfica utilizável como prova, 11 relatórios regulatórios pré-preenchidos (NIS2, RGPD, ISO 27001, EU AI Act, ISO 42001, NIST AI RMF, NIST CSF 2.0, EU CRA, SOC 2, HDS, PCI-DSS), retenção de dados configurável por tabela, anonimização dos dados pessoais antes de qualquer envio à nuvem. A ferramenta documenta o seu processo, não o substitui.

Question 11

O que acontece se o próprio agente for comprometido?

Accepted Answer

É exatamente o cenário para o qual as camadas de defesa embutidas no binário foram projetadas. Sem entrar em detalhes (um agente defensivo não publica publicamente o mapa das suas defesas, política antievasão), em geral: integridade do binário verificada na inicialização com recusa de iniciar se adulterado, superfície de ação limitada a operações conhecidas em tempo de compilação que um atacante não pode estender, trilha de auditoria assinada para reconstrução forense, mecanismo de parada automática em caso de comportamento suspeito. O código-fonte AGPL v3 permanece acessível se você quiser auditar os detalhes.

Question 12

Quantas CVEs há no ThreatClaw?

Accepted Answer

Política: zero CVE crítica tolerada no binário de release. O binário é analisado pelo cargo audit na CI a cada build, e o SBOM (software bill of materials) é publicado a cada tag de release. Qualquer CVE reportada abre um ticket público no GitHub com uma janela de patch de 72 horas para as CVEs críticas. Você pode verificar o estado do binário por conta própria recuperando o SBOM e escaneando-o com a sua ferramenta habitual (Trivy, Grype, etc.).

Question 13

Do que eu preciso para implantar o ThreatClaw?

Accepted Answer

Um servidor Linux com Docker instalado. Mínimo de 8 GB de RAM (16 GB recomendados se você ativar o LLM local). 20 GB de disco (50 GB com os modelos de IA baixados). Um único comando de instalação: `curl -fsSL https://get.threatclaw.io | sudo bash`. Um assistente de onboarding configura em seguida a IA, os canais de comunicação, o nível de autonomia e as fontes de logs. Conte com 30 minutos para uma primeira implantação funcional.

Question 14

O ThreatClaw é realmente gratuito?

Accepted Answer

O código é open source sob licença AGPL v3, gratuito e auditável no GitHub (todas as funcionalidades são idênticas em todos os planos. O plano Free permite monitorar um número limitado de ativos (ideal para microempresas / PMEs / labs). Para parques maiores, os planos pagos Starter / Pro / Business desbloqueiam limites mais altos. Consulte a página de Preços para detalhes. O acompanhamento humano (implantação, calibração, treinamento do RSSI) é oferecido separadamente pela CyberConsulting.fr) é o negócio de serviços que financia o desenvolvimento da ferramenta.

Question 15

Posso supervisionar vários servidores / sites?

Accepted Answer

Sim. Você define cada alvo na configuração com um modo (HITL por padrão / autônomo) e um tipo de acesso (SSH, WinRM, API exposta ou agente local no alvo). A instância ThreatClaw centraliza as análises e executa as ações aprovadas no alvo certo. Para múltiplos sites, há suporte a uma arquitetura com coletores regionais + agregador central.

Question 16

Como sou alertado em caso de incidente?

Accepted Answer

Pelos canais que você configurar: email, Slack, Telegram, Discord, Signal ou webhook personalizado para a sua ferramenta interna. No modo HITL, a aprovação é feita diretamente no chat (com nonce anti-replay para impedir a reutilização de uma aprovação anterior). Um dashboard web em tempo real também está disponível para a visão centralizada e os relatórios de conformidade.

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

Os vossos feeds de deteção estão mapeados aos requisitos regulatórios (NIS2, ReCyF)?

Accepted Answer

Sim. Cada assinatura vem com um mapa de cobertura por requisito: para cada requisito NIS2 (anexo ENISA) e ReCyF, indicamos quais das suas regras o abordam, mais a lista de lacunas. A cadeia é rastreável e pública (Sigma para ATT&CK para NIST 800-53 para CSF 2.0 para NIS2). É cobertura de projeto: comprova que o catálogo aborda o requisito, não é uma certificação nem uma medição em tempo real. Muitos requisitos são puramente organizacionais e não podem ser cobertos por regras; mostramo-los honestamente como lacunas. O mapa é entregue como relatório legível e em OSCAL (o padrão machine-readable).

Question 32

Uso um GRC (CISO Assistant, etc.). Posso importar a vossa cobertura?

Accepted Answer

Sim, através de um conector. Cria ou atualiza a sua auditoria no GRC e, para cada requisito que as suas regras cobrem, anexa uma prova e um controlo ThreatClaw, depois coloca o requisito em estado "a validar". Você, ou o seu CISO, validam e afirmam o "conforme" final: o conector nunca marca a sua conformidade sozinho, apenas lhe poupa o pré-preenchimento. Fornecemos também uma library de correspondência carregável e a exportação OSCAL para outras ferramentas. Nota técnica: o CISO Assistant não ingere OSCAL, por isso o nosso conector usa a sua API REST.

Question 33

Cobrem o DORA?

Accepted Answer

Parcialmente, e dizemo-lo com franqueza. Ao contrário do NIS2, não existe uma tabela de correspondência DORA oficial da UE. Por isso ancoramos as nossas regras aos artigos DORA que suportam diretamente: deteção (art. 8, 10), proteção (art. 9), testes de resiliência (art. 24 a 27). O nosso pack red-team é uma ferramenta de teste que apoia o artigo TLPT; não é a prestação TLPT certificada com âmbito validado pela autoridade. A correspondência para ISO ou NIST passa por um referencial terceiro reconhecido (SCF), citado como tal. Não reivindicamos governança, reporte de incidentes, gestão de terceiros nem continuidade.

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.

As suas perguntas. As nossas respostas honestas.

A IA e os seus dados