05AI威胁狩猎:为什么大模型不能无人值守?

admin 2026-07-12 05:27:31 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: AI可辅助威胁狩猎生成假设、扩展查询和整理证据,但无人值守的狩猎易将统计异常包装成安全事实。文章强调SOC应作为证据系统,AI只做证据工程,最终裁决需人工确认,并提供了落地实施方案和检查清单。 综合评分: 87 文章分类: 安全运营,AI安全,安全建设,安全工具,威胁情报


cover_image

05 AI 威胁狩猎:为什么大模型不能无人值守?

lidasimida lidasimida

安全学习之路

2026年7月10日 09:28 广东

在小说阅读器读本章

去阅读

重要边界:本文只面向防守运营、内部治理、授权验证和安全建设;不提供攻击复现步骤、payload、绕过脚本、凭证获取或真实目标入侵路径。

目录

·先给结论:AI 可以帮助生成狩猎假设、扩展查询和整理证据,但无人值守的 hunting 很容易把统计异常包装成安全事实。

·一、对象和机制:SOC 不是告警收件箱,而是证据系统

·二、看什么材料:每个判断都要能回到证据

·三、AI 如何介入:只做证据工程,不做最终裁判

·四、资料核验:本文判断依赖哪些权威来源

·五、技术加深:真正决定成败的工程细节

·六、案例拆解:材料、AI、人工验证和闭环

·七、扩展场景:生产环境里更复杂的问题

·八、落地实施方案:从低风险场景开始

·九、上线检查清单:别让 AI 输出直接进生产

·十、读者最容易误解的问题

·专业术语注释

·参考资料

先给结论:AI 可以帮助生成狩猎假设、扩展查询和整理证据,但无人值守的 hunting 很容易把统计异常包装成安全事实。

威胁狩猎和告警响应不同:告警响应从已有信号出发,狩猎从假设出发。一个好的 hunting 假设必须能被查询验证,也必须允许被反证。AI 最适合扩展思路和组织材料,不适合独立裁决组织里是否已经被入侵。

图 1:AI 威胁狩猎:为什么大模型不能无人值守?核心链路

一、对象和机制:SOC 不是告警收件箱,而是证据系统

AI 威胁狩猎流程可以拆成五步:提出假设、选择数据源、生成查询、整理证据、人工复核。每一步都要保留输入、查询、结果、解释和反证,否则 hunting 会从工程流程变成模型讲故事。

一个可运行的 AI SOC 不是把所有日志丢给模型,而是先把对象、字段、实体、权限和证据边界固定下来。模型可以帮助人更快组织材料,但不能替代数据治理、权限设计、人工审批和事件响应责任。

二、看什么材料:每个判断都要能回到证据

图 2:AI 威胁狩猎:为什么大模型不能无人值守?对象-材料-判断矩阵

下面这张表把文章里的关键对象拆成材料、AI 任务和人工闸门。写 SOC 类文章时,只有这三列都能说清楚,结论才算站得住。

| | | | | | — | — | — | — | | 对象 | 看什么材料 | AI 适合做什么 | 人工必须验什么 | | 假设 | ATT&CK 技术、情报、异常模式、历史事件 | 生成可验证假设 | 确认假设是否有业务意义 | | 查询 | SIEM 查询、EDR 搜索、云审计过滤条件 | 改写查询模板和字段映射 | 确认查询不会误伤数据语义 | | 证据 | 命中结果、时间线、资产和身份上下文 | 聚类和摘要 | 确认是否支持假设 | | 结论 | 支持、反证、未充分、需继续观察 | 生成报告草稿 | 最终判断和优先级 |

三、AI 如何介入:只做证据工程,不做最终裁判

AI 在 SOC 中最稳妥的定位,是把分散材料变成结构化证据包。证据包至少包含:evidence_id、source、timestamp、entity、summary、supports、does_not_prove、confidence、next_question。supports 写它支持什么,does\_not\_prove 写它不能证明什么,这能显著减少模型把推断写成事实。

AI 输出默认分成四栏:事实、推断、待验证问题、反证记录。事实必须能回到来源;推断必须写依据;待验证问题不能冒充结论;反证记录要进入关闭原因或规则优化。这个分层比“让模型给一个风险等级”更慢一点,但更适合生产 SOC。

四、资料核验:本文判断依赖哪些权威来源

为了避免把 AI SOC 写成概念堆砌,本文把关键判断绑定到公开资料和可复核框架。资料只作为方法依据,不把厂商产品能力直接等同于企业落地效果。

| | | | | — | — | — | | 资料或框架 | 可以确认什么 | 对本文的约束 | | MITRE ATT&CK | ATT&CK 可作为 hunting 假设的行为语言,但不能替代内部数据验证。 | hunting 文章要从假设和证据出发,不从模型自由搜索出发。 | | Google Cloud Threat Horizons H1 2026 | 云环境中身份、漏洞利用、日志破坏和取证准备是重点趋势。 | AI hunting 场景要关注身份、云审计、取证时间线。 | | NIST AI RMF | AI 风险管理强调治理、测量和管理。 | 无人值守 hunting 的主要风险是未测量、不可审计和不可解释。 |

五、技术加深:真正决定成败的工程细节

威胁狩猎的入口不是“找异常”,而是“提出可验证假设”。一个好假设包含主体、行为、目标、时间窗、数据源和预期反证。AI 可以帮助补全这些元素。

AI 生成查询时常见错误有字段不存在、时间窗过大、把统计异常当安全异常、忽略业务基线、把外部情报直接套到内部环境。上线前必须让查询先在历史数据上回放。

hunting 结果要分为 confirmed、refuted、inconclusive 三类。inconclusive 不是失败,它说明需要补数据源或延长观察周期。AI 最危险的是把 inconclusive 写成 confirmed。

技术上要特别警惕一种假象:模型把材料说得很顺,并不代表材料已经足够。SOC 场景里的可靠性来自字段、来源、权限、时间、证据强度和人工复核,而不是来自语言表达本身。

六、案例拆解:材料、AI、人工验证和闭环

案例一:假设“异常服务账号在夜间横向访问”

材料怎么收:服务账号登录、目标主机、访问协议、历史基线和变更窗口。

AI 怎么做:生成查询思路,归并命中账号和目标资产。

人工怎么验:确认服务账号任务计划、备份窗口和合法批处理。

修复怎么闭环:若风险成立,进入账号权限审计和检测规则;若反证,更新基线。

不能证明什么:夜间访问不能直接证明横向移动。

案例二:从外部情报转成内部 hunting 假设

材料怎么收:情报报告中的 TTP、IOC、目标行业、内部资产和检测覆盖。

AI 怎么做:抽取 TTP,映射到内部数据源和可查询字段。

人工怎么验:确认情报可信度、内部相关性和数据可见性。

修复怎么闭环:形成 hunting 任务、检测规则或观察项。

不能证明什么:外部情报匹配行业不等于组织已受影响。

案例三:异常进程树是否值得继续追

材料怎么收:进程树、命令行、文件签名、用户会话、软件分发记录。

AI 怎么做:聚类相似进程树,输出异常点和反证线索。

人工怎么验:确认是否是运维工具、软件升级或脚本任务。

修复怎么闭环:把确认的异常模式转成检测,误报写回狩猎知识库。

不能证明什么:进程树罕见不等于恶意。

七、扩展场景:生产环境里更复杂的问题

扩展场景 1:服务账号横向访问假设

现场材料:夜间服务账号访问多个不常访问的主机,但正好处于备份窗口。

AI 介入:AI 生成查询并把命中按资产组和时间窗聚类。

人工校验:运维确认备份任务、变更单和账号用途。

闭环产出:若反证成立,更新基线;若不成立,进入权限审计。

扩展场景 2:云密钥异常使用

现场材料:同一访问密钥在新 ASN、新区域和新 User-Agent 下出现 API 调用。

AI 介入:AI 整理调用序列、资源影响和缺失的 MFA/轮换记录。

人工校验:云安全团队确认合法自动化、CI/CD 任务和密钥归属。

闭环产出:输出密钥轮换、最小权限和检测规则改进项。

这些场景的共同点是:AI 先把复杂材料组织成可讨论对象,再由人确认事实边界和业务影响。只要跳过人工校验,AI SOC 就会从提效工具变成风险放大器。

八、落地实施方案:从低风险场景开始

| | | | | — | — | — | | 阶段 | 具体做法 | 产出标准 | | 定义假设 | 用一句话写清行为、主体、目标和时间窗口。 | 可查询。 | | 选数据源 | 只选能支撑或反证假设的数据源。 | 避免乱搜。 | | 生成查询 | AI 可起草,人工校验字段和语义。 | 避免幻觉查询。 | | 沉淀结果 | 把支持、反证和未充分分开记录。 | 可复盘。 |

落地时不要从自动封禁、自动隔离、自动删除这类高风险动作开始。更稳妥的顺序是:先做摘要和证据包,再做历史案例检索和检测规则辅助,最后才在低风险 playbook 上做受控自动化。每一步都要保留输入、输出、人工修改和回归结果。

九、上线检查清单:别让 AI 输出直接进生产

| | | | | — | — | — | | 检查项 | 怎么检查 | 合格标准 | | 假设模板 | 写清主体、行为、目标、时间窗、数据源。 | 能被查询验证。 | | 查询回放 | 在历史数据和误报样本上运行。 | 误报原因可解释。 | | 反证记录 | 保留合法业务、变更单、维护窗口。 | 避免 hunting 污染规则库。 | | 沉淀路径 | 结果转成规则、基线、权限审计或观察项。 | 不是一次性报告。 |

检查清单不是为了增加流程负担,而是为了把模型输出从“看起来合理”变成“可以上线承担责任”。如果某一项无法检查,说明当前能力还应该停留在辅助阶段。

十、读者最容易误解的问题

AI 能自动 hunting 吗?

不建议无人值守。AI 可辅助假设和查询,结论要人工确认。

好的 hunting 假设长什么样?

能说明主体、行为、目标、时间和可验证数据源。

AI 生成查询最常见问题是什么?

字段不存在、语义错用、查询范围过大或把统计异常当事实。

为什么要记录反证?

反证能阻止探索性结果被误写成安全事件。

狩猎结果怎么落地?

转成检测规则、基线更新、权限整改或后续观察项。

IOC 可以直接变 hunting 吗?

可以作为线索,但更重要是转成 TTP 和内部数据源问题。

如何控制成本?

先做高价值资产和高可信假设,不做全网无边界搜索。

怎么评估 hunting 成功?

看有效发现、误报减少、规则沉淀和可见性缺口修复。

专业术语注释

·**SOC**:Security Operations Center,安全运营中心,负责监测、研判、响应和复盘安全事件。

·**SIEM**:Security Information and Event Management,集中采集、关联和查询安全日志的平台。

·**SOAR**:Security Orchestration, Automation and Response,用于编排响应流程和自动化动作。

·**EDR**:Endpoint Detection and Response,终端检测与响应系统。

·**XDR**:Extended Detection and Response,跨终端、网络、云和身份的扩展检测响应。

·**ATT&CK**:MITRE ATT&CK,描述攻击战术、技术和过程的知识库。

·**Threat Hunting**:威胁狩猎,主动提出假设并寻找证据的安全运营活动。

·**IOC**:Indicator of Compromise,失陷指标,如 IP、域名、哈希等。

·**IOA**:Indicator of Attack,攻击行为指标,更关注行为模式。

参考资料

·MITRE ATT&CK, current website version v19.1 since 2026-04-28, https://attack.mitre.org/resources/versions/

·NIST AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework

·NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025-04-03, https://csrc.nist.gov/pubs/sp/800/61/r3/final

·Google Cloud Threat Horizons Report H1 2026, https://cloud.google.com/security/report/resources/cloud-threat-horizons-report-h1-2026


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:安全学习之路 lidasimida lidasimida《05 AI 威胁狩猎:为什么大模型不能无人值守?》

评论:0   参与:  0