Question 1

AI 智能体操作我的基础设施,难道不危险吗?

Accepted Answer

这是个应该提出的好问题。ThreatClaw 正是围绕这一约束而设计:多层防御被直接编译进二进制文件中，不可配置、不可绕过、不可在部署后禁用。在默认模式下,智能体只观察和建议:未经人工明确批准(通过 Slack/Telegram/邮件/Signal 的 HITL),它绝不采取行动。代码在 AGPL v3 许可下开源,因此您可以在部署前审计每一行代码。

Question 2

如果 LLM 产生幻觉或提出荒谬的操作怎么办?

Accepted Answer

AI 永远无法自行触发任何操作。每一个被建议的操作都会经过编译进二进制文件的静态过滤器,该过滤器只识别已知的、可逆的、目标经过验证的操作。任何与预定义操作不匹配的建议都会在执行前被拒绝。在默认模式下,操作员会收到完整的建议(分析 + 指标 + 预期影响),并在聊天中一键批准或拒绝。

Question 3

本地 AI 还是云端 AI,该选哪个?

Accepted Answer

我们的默认推荐是本地 AI(通过 Ollama 在您的服务器上运行 LLM):您 100% 的数据都留在本地,不可能发生任何泄露。云端 AI 可作为复杂或模棱两可案例的第二意见来添加，在这种情况下,所有敏感数据会在发送前自动替换为可逆令牌。云端 LLM 永远看不到任何标识符、IP 或凭证。用于还原的映射仅存在于内存中,绝不落盘。

Question 4

匿名化是如何工作的,如果它遗漏了什么怎么办?

Accepted Answer

在调用任何外部 LLM 之前,数据会经过一个用 Rust 编写的匿名化器,它会自动检测常见的敏感标识符(技术、财务、个人),并将其替换为可逆令牌。收到响应后,令牌会在本地还原。映射仅存在于内存中。

任何基于模式匹配的匿名化器都存在残余风险,我们对此坦诚以待。三重缓解措施:(1) 您可以用自己业务特定的规则(内部项目名称、命名约定)来扩充覆盖范围,(2) 默认选项仍是本地主权 AI,不会将任何数据带出服务器,(3) 匿名化器代码在 AGPL 下开源，您可以审计它能检测什么,并按需补充。

Question 5

具体来说,ThreatClaw 做什么?

Accepted Answer

ThreatClaw 是一款自主网络安全智能体,持续运行在您的基础设施上。它摄取可用的信号源(syslog 日志、IDS 告警、SIEM 事件、扫描、CTI),通过多层检测关联事件,并为每个事件生成一份完整档案:带置信度的裁定、失陷指标、受影响范围,以及 1 到 3 项可立即执行的纠正措施。根据所选模式:它通知您并由您批准(HITL),或直接执行低风险操作(自主)。

Question 6

它能在我的系统上执行哪些操作?

Accepted Answer

所有可能的操作都在开源代码中定义，没有任意 shell,没有动态命令。总体而言:隔离失陷终端、在防火墙上封禁 IP、锁定可疑用户账户、隔离恶意文件、停止 Docker 容器、采集取证证据。每一个操作都会记录在一份经加密签名的审计日志中,任何破坏性操作在默认模式下都需要人工批准。

Question 7

ThreatClaw 能消费哪些观测数据源?

Accepted Answer

原生支持超过 19 种信号源:SIEM(Wazuh、FortiGate、OPNsense)、企业防火墙、EDR 代理(Velociraptor)、通过 syslog 采集的 Linux/Windows 服务器日志、漏洞扫描、威胁情报(CrowdSec)、IDS/IPS 告警,以及任何支持标准 syslog 协议的设备。一家典型的中小企业每天产生 4 500 条噪音告警;ThreatClaw 将这一切整合为寥寥数个已鉴定、可操作的事件。

Question 8

我如何收集我的日志?

Accepted Answer

ThreatClaw 内置一个集成的 syslog 收集器,监听标准的 514 端口。您将 Linux 服务器(auth.log、syslog)、Windows(通过 syslog 的事件日志)、防火墙和 Docker 容器指向该端点。日志存储在本地 PostgreSQL 中,并经过检测层(Sigma 规则、IDS、ML)生成优先级排序的告警。无需外部 SaaS 日志管理，一切都留在您的服务器上。

Question 9

为什么选择 Rust 作为智能体的核心?

Accepted Answer

安全智能体在客户的基础设施上以高权限运行。如果它自身存在内存漏洞,那将是一场噩梦。Rust 在编译期就消除了最常被利用的几类 bug(缓冲区溢出、释放后使用、竞态条件、空指针解引用)。这是不可妥协的先决条件,而非审美选择。

Question 10

ThreatClaw 是否符合 NIS2 / GDPR / ISO 27001?

Accepted Answer

坦诚地说:合规是一个取决于您具体情境的组织性流程,而不是工具里的一个勾选框。ThreatClaw 具体带来的是:可作为证据的加密审计追踪、11 份预填的监管报告(NIS2、GDPR、ISO 27001、EU AI Act、ISO 42001、NIST AI RMF、NIST CSF 2.0、EU CRA、SOC 2、HDS、PCI-DSS)、可按表配置的数据保留、在任何云端发送前对个人数据进行匿名化。工具记录您的合规过程,但不替代它。

Question 11

如果智能体本身被攻陷了怎么办?

Accepted Answer

这正是编译进二进制文件的防御层所针对的场景。在不透露细节的前提下(防御型智能体不会公开公布其防御地图，反规避策略),总体而言:启动时校验二进制完整性,若被篡改则拒绝启动;操作面被限制在编译期已知、攻击者无法扩展的操作;签名的审计追踪用于事后重建;在可疑行为下自动停止的机制。若您想审计细节,AGPL v3 源代码始终可用。

Question 12

ThreatClaw 里有多少个 CVE?

Accepted Answer

策略:发布版二进制中零容忍严重 CVE。二进制在 CI 的每次构建中都由 cargo audit 分析,SBOM(软件物料清单)在每个发布标签处发布。任何被上报的 CVE 都会在 GitHub 上开一个公开工单,严重 CVE 需在 72 小时内修复。您可以自行获取 SBOM,用您惯用的工具(Trivy、Grype 等)扫描以核实二进制状态。

Question 13

部署 ThreatClaw 需要什么?

Accepted Answer

一台安装了 Docker 的 Linux 服务器。最低 8 GB 内存(若启用本地 LLM 建议 16 GB)。20 GB 磁盘(下载 AI 模型后为 50 GB)。一条安装命令:`curl -fsSL https://get.threatclaw.io | sudo bash`。随后一个引导向导会配置 AI、通信渠道、自主级别和日志源。首次可用部署预计需要 30 分钟。

Question 14

ThreatClaw 真的免费吗?

Accepted Answer

代码在 AGPL v3 许可下开源,在 GitHub 上免费且可审计，所有层级的功能完全相同。Free 层允许监控数量有限的资产(适合微型企业/小型中小企业/实验环境)。对于更大的资产规模,付费的 Starter / Pro / Business 层解锁更高的上限。详情见"价格"页面。人工陪伴服务(部署、校准、RSSI 培训)由 CyberConsulting.fr 单独提供，正是这项业务为工具的开发提供资金。

Question 15

我可以监控多台服务器/多个站点吗?

Accepted Answer

可以。您在配置中为每个目标定义一个模式(默认 HITL / 自主)和一种访问类型(SSH、WinRM、暴露的 API,或目标上的本地代理)。ThreatClaw 实例集中进行分析,并在正确的目标上执行已批准的操作。对于多站点,支持"区域收集器 + 中央聚合器"的架构。

Question 16

发生事件时我如何收到告警?

Accepted Answer

通过您配置的渠道:邮件、Slack、Telegram、Discord、Signal,或指向您内部工具的自定义 webhook。在 HITL 模式下,批准直接在聊天中完成(带防重放 nonce,以防止重复使用过往的批准)。还提供一个实时 Web 仪表板,用于集中视图和合规报告。

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

你们的检测订阅源是否映射到监管要求(NIS2、ReCyF)?

Accepted Answer

是的。每份订阅都附带按要求的覆盖图:对于每条 NIS2 要求(ENISA 附录)和 ReCyF,我们指出你的哪些规则覆盖它,以及缺口清单。链路可追溯且公开(Sigma 到 ATT&CK 到 NIST 800-53 到 CSF 2.0 到 NIS2)。这是设计层面的覆盖:它证明目录覆盖了该要求,既非认证,也非实时度量。许多要求纯属组织性,无法用规则覆盖;我们如实将其列为缺口。覆盖图以可读报告和 OSCAL(机器可读标准)形式提供。

Question 32

我使用 GRC(CISO Assistant 等)。可以把你们的覆盖导入其中吗?

Accepted Answer

可以,通过一个连接器。它在 GRC 中创建或更新你的审计,并为你的规则覆盖的每条要求附加一份 ThreatClaw 证据和控制项,然后把该要求置为"待确认"。你或你的 CISO 确认并给出最终的"合规":连接器绝不会自行勾选你的合规,它只是替你省去预填。我们还提供可加载的映射 library 和用于其他工具的 OSCAL 导出。技术说明:CISO Assistant 不接收 OSCAL,因此我们的连接器使用其 REST API。

Question 33

你们覆盖 DORA 吗?

Accepted Answer

部分覆盖,我们坦白讲。与 NIS2 不同,不存在官方的欧盟 DORA 对应表。因此我们把规则对应到它们直接支持的 DORA 条款:检测(第 8、10 条)、保护(第 9 条)、韧性测试(第 24 至 27 条)。我们的 red-team 包是一个支持 TLPT 条款的测试工具,并非由监管机构界定范围的认证 TLPT 项目。到 ISO 或 NIST 的对应通过一个公认的第三方框架(SCF)进行,并如实注明。我们不主张治理、事件报告、第三方管理或业务连续性。

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.

您的问题。我们诚实的回答。

AI 与您的数据