梦想国际威胁与全球网络威胁情报AI

梦想国际威胁：一个IP已经被几十家安全机构标记以后，为什么它仍然不一定是企业现在最需要处理的风险？

每天早上情报平台推过来的指标里，总有几条评分很高、被很多来源同时标记。分析师最容易做的动作是直接把它加进封禁列表，而最容易跳过的动作是先问一句：这条指标和我们自己有关系吗？

先说一个具体场景。某条IP指标在多个公开来源同时出现，标签写着扫描、暴力破解、恶意托管，聚合平台给出的分数接近满分。第一眼看这条指标，确实像是应该马上处理的东西。但把它放回自己的环境里追问一层：它探测的是哪些端口？我们对外有没有开放这些端口？过去三十天的边界日志里，它和我们发生过任何一次连接吗？如果三个问题的答案都是没有，那么这条指标对当前风险的贡献接近于零，它的正确归宿是入库备查，而不是插队。

标记次数到底说明什么，这里值得想清楚。它反映的是这个指标在别人的观察范围里出现得有多广，而不是它对你构成的威胁有多大。一台被用来扫全网的云主机，会同时出现在成千上万个组织的日志里；它出现在你的情报源里，是因为它在扫描所有人，不是因为它盯上了你。把观察广度当成风险高度，是情报使用里最普遍的一个转换错误，也是最容易被分数排序掩盖过去的一个。

一条可用的情报应该分得清三件事。Observed（事实）是能被日志证明的观察，例如"该地址在某时间段内对大量公网主机发起过端口探测"；Assessment（评估）是基于事实做出的推断，例如"该地址可能被用于某类批量扫描活动"；Confidence（置信度）是对这个推断有多确定，用Low、Medium、High明确标出来。至于"该地址属于某个特定组织或某国背景团体"这类归因结论，需要的证据远远超出公开情报能提供的范围。归因本身是很难的工作，把猜测写成结论，会让后续所有基于它的决策都建立在空气上。证据不足时，最专业的写法有时就是"目前只能确认异常，不能确定攻击归属"。

从这张表能看出来，决定优先级的不是指标本身的分数，而是"判断依据"那一列。真正应该先确认的是公司到底有没有这个组件、这个服务、这个授权。而要回答这个问题，需要三样东西：一份还在持续更新的资产清单、一张对外暴露面视图、以及一个能在终端和日志里做全量检索的能力。缺任何一样，情报流程都会退回到按分数排序——因为那时候，分数是唯一还算得出来的东西。

还有一个容易被忽略的成本：封禁列表本身是要维护的。指标没有过期机制时，列表只会越来越长，其中一部分地址早就被云厂商回收，重新分配给了正常服务。半年后某个合作伙伴的接口突然连不上，排查一圈才发现是很久以前加进去的一条情报还留在那里。所以往列表里加东西之前，最好先想清楚谁会在什么条件下把它拿出来——加入规则和退出规则应该是同一次决定的两半。

另一个方向是相关性会变。今天完全不相关的一条指标，可能在下个季度变得相关：收购了一家子公司、上线了一个新的SaaS、引入了一个新的开源依赖，暴露面就变了。所以关联不应该只在情报进来的那一刻做一次。资产清单发生变化时，历史情报值得重新跑一遍。很多组织既有情报库也有资产库，但两者只在入库那一瞬间相遇过一次，之后再没有对过账。

AI在这里的位置比较清楚。把情报里的组件名、版本号、域名、哈希和资产库、软件物料清单、日志做自动对齐，是典型的重复劳动，模型做得比人快也比人全，而且不会因为今天指标多就跳过几条。但对齐结果只是候选：要不要封禁、要不要停服，仍然需要人来批准，因为误封的代价不落在安全团队身上，落在正在使用这个地址的业务上。模型给出的每一条建议都应当附带它所依据的原始记录，让复核的人能在一分钟内验证，而不是只看到一个结论。

把这一套收敛成一句可执行的判断：情报进来先做关联；关联不上的记录备查并写清楚复查条件；关联得上的再按暴露面和业务关键度排序。这样做的直接效果是处置队列会明显变短，而队列里剩下的每一条，都能说清楚它为什么在这里。

安全告警已经按照严重程度排好顺序以后，为什么Business Criticality还可能完全改变优先级？

一份按严重度排好的告警列表看上去很有说服力：分数从高到低，从上往下处理就行。问题在于，这个分数是在完全不知道你公司长什么样的前提下算出来的。

先看一个对比。告警A是一个中等严重度的权限配置问题：某个服务账号被授予了超出实际需要的读取范围，而这个账号运行在核心交易链路上，这条链路停一小时会直接影响下单和结算。告警B是一个高严重度的远程代码执行问题，落在一台测试机上，这台测试机所属的业务半年前已经下线，没有公网入口，没有生产数据，凭证也和生产环境完全隔离。按技术评分，B排在A前面；按实际处置顺序，几乎所有有经验的团队都会先处理A。

差别在于两个分数描述的根本不是同一件事。技术严重度是一个通用属性，它回答的是"这个问题在最坏假设下能造成多大破坏"；为了让不同组织之间能够比较，它必须假设一个理想化的、对攻击者最友好的环境。业务关键度是一个本地属性，它回答的是"这个系统对我们意味着什么"，这件事只有你自己知道，任何外部评分体系都算不出来。用通用属性做全球排序是合理的，用它直接做本地排序，就等于把一半信息扔掉了。

补偿控制这一项要特别小心。"我们前面有防护设备，所以可以降级"是一句需要验证的话，不是一句可以直接采信的话。要降级，至少得先确认三件事：规则确实覆盖了这条利用路径、规则处在拦截模式而不是观察模式、这个系统的流量确实经过这层防护而不是通过某个内部直连绕过去了。基于假设的降级，实际效果等同于没有处理，却会在台账上留下"已缓解"的记录——这比不处理更危险，因为它让问题从待办清单里消失了。

那么业务关键度由谁来定？这件事不应该由安全团队独自完成。安全团队知道系统有什么问题，业务负责人才知道系统停了会发生什么。可行的做法是把业务关键度写进资产台账，和系统负责人、恢复时间目标、数据分级放在一起，由业务侧确认并定期复核。没有这份台账，任何优先级模型都缺一个必需的输入，最后只能退回去按分数排。很多组织的优先级排不好，根因不在安全，在于资产台账没人认领。

重新排序之后，沟通方式也要跟着变。当一条高严重度的告警被排到后面，负责那个系统的人一定会问为什么。这时候能不能给出一个具体理由——不可从外部访问、无生产数据、已有网络隔离并且验证过——决定了这套排序机制能不能长期运行下去。排序不是安全团队的内部黑箱，它是要被质疑的；经得起质疑的排序，才有人愿意照着执行。相反，只给一个综合分数、说不清怎么算出来的排序，第一次被推翻之后就没人再看了。

AI在这一步适合做的是拼装工作：把告警、资产台账、暴露面视图、数据分级自动关联起来，给出一个建议顺序。这类跨系统查表和对齐，人做起来又慢又容易漏。要求也很明确：模型输出的每一次顺序调整都要带上理由和数据来源，让人能看懂也能反驳。尤其是往下降级的建议必须经过人工复核——把一个问题从高排到低，如果判断错了，是真的漏掉；从低排到高，最多是多花了一点时间。两种错误的代价不对称，复核的力度也就不应该对称。

所以严重度排序不是终点，而只是排序流程的第一个输入。真正决定处置顺序的，是这条告警落在哪个系统上、那个系统对业务意味着什么、以及它一旦失守还能把攻击者带到哪里去。

事件发生两周以后才被发现时，什么决定企业还能不能重新拼出完整时间线？

很多组织在"多久能发现"上投入了不少资源，却很少检查另一个问题：发现之后，还能不能把发生过什么完整地讲清楚。这是两种不同的能力，需要的也是两套不同的准备。

先把过程摊开看一遍。下面这条时间线是一个常见的推演过程，用来说明调查通常卡在哪一步，点击每一步可以展开细节。

这条时间线上真正的分叉点在第四步。到那一步为止，团队的检测能力是有效的：规则命中了，人也及时介入了。真正卡住调查的，是一个在事件发生之前很久就已经做完的决定——某个平台的审计日志保留多久、要不要开启对象级别的访问记录、这笔费用算不算值得。那笔账通常是在采购或者上线阶段算的，而算账的人多半没有想过它会在某次调查里成为瓶颈。

默认值是另一个反复出现的问题。大多数平台的日志保留期是产品的默认值，不是你的需求；一部分平台还把更长的保留期和更细的审计事件放在更高的套餐里。这意味着"我们有日志"这句话需要拆成三问：哪些事件类型有？保留多久？字段够不够用来做关联？三个问题里任何一个答案不理想，事后调查都会停在同一个地方。

Forensic Readiness（取证准备）要解决的，正是这些必须在事前决定的事：

• 留什么：身份与认证、权限与授权变更、数据访问与导出、管理面配置修改，这四类无论如何都要覆盖，因为它们构成了攻击链的骨架。
• 留多久：保留周期应该按"最坏情况下多久才会被发现"来定，而不是按存储成本来定。如果对停留时间的现实预期是以周甚至月计，只保留几天的日志在调查里基本没有用。
• 留在哪：日志最好离开产生它的系统，集中到一个即使该系统账号被控制也无法修改的位置。
• 谁能访问：取证访问本身是高权限操作，需要审批和留痕，否则调查能力会变成新的滥用面。
• 怎么证明没被改过：完整性校验和访问记录，决定了这份证据在复盘和可能的法律程序里还站不站得住。

还有一种更隐蔽的缺失：日志有，但缺字段。记录了"某账号导出了文件"，却没有记录导出了哪些文件；记录了登录成功，却没有记录会话标识，导致后续动作无法和这次登录挂上钩。跨系统调查还有一个基础前提是时间同步——各系统时区不统一或者时钟存在漂移，时间线就拼不起来，而这件事往往到需要拼的时候才第一次被发现。这些都属于在平静时期花半天就能确认、在事件中却要付出几天代价的项目。

AI在还原阶段确实有价值：跨系统对齐时间戳、把分散事件聚成一条可读的链、生成初步叙述和待验证清单，这些都是模型比人快的部分。但有一条硬要求——叙述里的每一句话都要能回指到具体的原始日志行。不能追溯的叙述在复盘会上没有说服力，在需要出具材料的场合更没有价值。同样，涉及取证数据的访问和导出属于高影响操作，应当保留人工审批，而不是交给自动化流程随手完成；调查工具本身的权限，也要纳入和其他高权限账号一样的治理范围。

有一个可以立刻安排的动作：做一次取证演练。随机挑一个账号和一个过去的日期，试着还原它三十天内的行为。演练的目的不是考核分析师，而是暴露配置问题——哪个系统的日志已经过期、哪个字段缺失、哪个平台的访问需要临时申请权限、哪两套系统的时间戳对不齐。这类问题在平静时期发现只是一张待办清单，在事件中发现就是几天的延迟。