AiSOC 将安全告警调查做成可审计流程

AiSOC 想把安全告警处理串成一条能追责的流水线：接入日志，靠规则发现异常，让 AI 调查，再由人批准响应。它最值得程序员关注的，是如何限制模型权限、保存证据，以及区分「演示跑通」与「真实有效」。

项目公开了不少不那么漂亮的数字：7023 条规则只有 2538 条被计入可执行；本地模型返回合格结果，也不等于判断准确。读这份 README，更适合学习一套 AI 系统的工程约束，而不是寻找已经成熟的自动化安全专家。

为什么先跑规则，再让 AI 调查

AiSOC 是采用 MIT 许可、支持自托管的安全运营中心（SOC）。输入是安全工具产生的遥测数据，包括日志和事件；输出是关联后的事件、AI 调查记录与待批准的响应方案。

它没有把整堆日志直接交给模型。数据先统一结构，提取 actor、action、resource、location、outcome，再经 Kafka 进入检测引擎。actor.kind 来自厂商文档定义的字段，不靠猜测。

规则负责筛选，关联模块负责把相关告警合成事件，AI 接着读取告警、关联记录、实体信息和历史结论，调用工具调查。这种分工让模型处理一个已有上下文的问题，也让前面的检测过程更容易复现。

接入侧列出 91 个连接器，覆盖 Splunk、Sentinel、Elastic、CrowdStrike、Okta、AWS 等；另有四类采集器，对接 S3/SQS、GCP Pub/Sub、Azure Event Hubs 和 syslog/CEF。采集器保留可恢复游标，并限制每轮拉取量，积压时通过背压控制输入。

检测能力则要分开看：磁盘上有 7023 条规则，其中 2538 条通过可执行验证；另有 76 条滑动窗口规则，73 条跨事件计数，3 条匹配有顺序的事件序列。

规则能触发，只证明路径可达，不能证明它能识别真实攻击。

项目要求把符合厂商格式的事件送过真实连接器和引擎，观察规则确实触发。--prove-gate 还会回退 Windows 连接器，要求全部 1,687 条 Windows 规则停止触发，用破坏实验检查验证是否有效。仍有两条规则因缺少行为基线无法触发，这个数量此前是 119。

迁移也有类似边界：内置 2,005 条 Splunk 规则，1,734 条可以转换，其中 1,711 条只是部分转换。不能把「转换成功」当作检测语义完整保留。

AI 能查证据，但权限不能跟着提示词走

AiSOC 的 agent 可以选择类型化工具并传递参数，例如查询数据湖、遍历关系图、补充外部信息，但不能直接编写 SQL。由假设生成威胁狩猎时，模型也只能填写封闭结构，字段值通过参数绑定进入查询。

大白话解释：模型负责提出「查什么」，程序负责限定「允许怎样查」。

调查过程写入 Investigation Ledger，记录提示词、工具调用、引用、结论和 token 成本。可核验的陈述需要指向对应记录，其他内容标为未引用；调查还能导出签名证据包，提示词以摘要形式提供，使用 OCSF 1.9.0。

这类记录方便复核，但不会自动让答案正确。项目另做证据校验：如果结论引用了证据中根本不存在的指标，就降级为人工复核。发送提示词前，也会拒绝原始日志、OCSF 载荷和疑似秘密值，而不是发出去后再补救。

执行响应还有独立门槛。部署、租户、playbook 三个开关必须同时允许，默认全部关闭；否则只生成预览计划。审批暂停状态存进 Postgres，重启后可以继续，也会在过期时留下结果。

即便 playbook 已获批准，每一步仍要在派发时检查自身的能力契约。审批人必须具备对应权限级别，并且不能是动作申请人。租户可以显式授权某个动作自主执行，但这种授权需要具体到动作。

批准一个流程，不能等于批准它里面可能出现的任何操作。

这也是普通 AI 工具开发可以直接借鉴的边界：权限检查应落在实际执行入口，不能只写进系统提示词。

能在本机跑通，究竟证明了什么

项目提供的最短启动路径只有两行：

git clone https://github.com/beenuar/AiSOC && cd AiSOC
make up

关键是 make up：它会创建 .env、生成十五个秘密值，并创建管理员账号。管理员密码在本机生成，只显示一次；丢失后通过 make bootstrap ARGS=--reset-password 重置。

运行要求是 Docker Compose v2、Docker VM 内 8 GB 内存和 20 GB 可用磁盘，以及 python3 3.9+、bash。首次启动下载约 2 GB 模型，只有 make clean 会清除对应卷。make doctor 检查环境和数据存储，make smoke 则追踪一条真实输入，经 Kafka、检测、关联和 Postgres，最终从公开 API 读回告警，示例输出为 10/10 stages 通过。

下面的请求演示如何向接入 API 推送事件，凭据由 make ingest-token 生成：

curl -X POST http://localhost:8081/v1/ingest/batch \
  -H 'Content-Type: application/json' -H "Authorization: Bearer $AISOC_INGEST_TOKEN" \
  -d '{"connector_id":"edr-1","connector_type":"crowdstrike","events":[{"severity":"high",
       "title":"Encoded PowerShell from Office","host":"WIN-FIN-01"}]}'

要看的是 Authorization 这一行：租户归属从凭据确定，不由调用者另传一个请求头决定。接口规范位于 docs/openapi.yaml。

演示约三分钟，但终端等待经过缩短且有标注；原文还说明，配套静态截图来自 v20.1.0，录像比截图更早。版本徽章标为 21.0.0，不能把所有展示材料当作同一次运行。

默认模型是 Ollama 运行的 llama3.2:3b-instruct-q4_K_M，约 2 GB，面向纯 CPU 推理。作者报告，在 50 条告警上，约束 JSON 输出前有 44 次返回可用结果，约束后为 50 次。这证明输出格式更稳定，尚不能证明安全判断更准。可用 make up-gpu、make up-host-llm 或在控制台配置其他提供商，但作者没有实际测试托管提供商，相关行明确写作 not measured。

项目对演示数据也做了区分：向导里的五个样例走真实接入链路；make demo 加载的固定语料全部标记 is_synthetic = true。新安装自带的 CISA KEV 情报是真实外部数据，但不能据此推导真实事故处理效果。

评估里最有价值的，是分母和口径没有藏起来。告警减少比例分别为旧分组的 75.3%、生产分组键的 33.3%，以及修复缺失标识问题后、检测形态语料上的 24.5%。它们条件不同，不能挑最大的数字宣传。模型适用性还按任务评估，与 balanced accuracy 恰为 0.250 的确定性基线比较。

历史回放则在检索查询层限制证据时间，并禁止真实动作。用新情报重查旧日志被单列为另一种模式，不能冒充当时已经预测到了威胁。

我的判断

我更认可 AiSOC 对能力边界的处理：可执行规则需要实证，未测模型写明未测，样例数据明确标识，动作权限放到执行入口。这些约束比给 agent 增加几个工具更值得学习。

但这份材料仍是项目自述。它没有提供足够的真实生产对照，无法证明相比成熟 SIEM 加人工调查，或现有告警系统加 AI 助手，AiSOC 在准确率、误报率和处置时间上更好。文中也明确承认，基准数字衡量的是底层机制的自洽性，不是线上 agent 准确率。

「Stable」要求每次 PR 都运行真实基础设施上的生产路径检查，并通过破坏后的负向验证，这是较高的工程门槛；它仍不能替代长期运行证据。

另外，自托管并不等于低运维成本。Kafka、Postgres、多个数据存储和本地模型都需要维护。AiSOC 也不替代长期日志保留与合规检索，没接入的数据不会自动发现。对一般团队，先把数据源和现有规则维护好，可能比直接部署完整平台更有收益。

能拿来做什么

• 负责 Node 服务接入的团队，可以先用单一事件源验证完整链路，再检查字段映射、租户凭据与告警结果；不要把容器启动成功当作验收通过。
• 做 AI 调查助手时，可以借鉴类型化工具、参数绑定和证据引用，把「模型输出格式合格」与「结论有依据」分别验证。
• 给 agent 接入写操作时，可以将预览、持久化审批和执行时鉴权分开实现，确保流程重启或步骤变化后，权限约束仍然成立。
• 评估安全类 AI 项目时，可以沿用它的披露方式：列清真实调用、合成数据、失败样本和未测项，再用自己的事件语料判断是否值得继续投入。