威胁模型深挖

先明确：威胁模型的产出不是「威胁清单」

如果做完只得到一页「我们要防 X、Y、Z」，那这份模型的用处会很有限 —— 因为没有任何取舍被做出来。

产出 1：资产表

哪些东西一旦被看到或被篡改会造成实际损失。注意「依赖」不等于「资产」 —— 依赖可以替换，资产不能。

产出 2：明确接受的威胁

这是最容易被跳过、也最有价值的一项。写清哪些威胁我们决定不专门防、理由是什么。

没有这一项，团队会反复讨论同一个威胁，每次都得出「再看看」。

产出 3：带责任人的优先级

每一项防护都要有归属。没有责任人的条目会在半年后仍然停留在文档里。

为什么强调「明确接受」：威胁模型的实际用途是让取舍被看见并被记住。把「我们不防这个，因为成本高于收益」写下来，比把它漏掉有用得多 —— 漏掉的威胁会被反复重新讨论，而写下来的取舍只需要在条件变化时复核一次。

第一步：从查询日志反推资产

「识别关键资产」听起来像是坐下来开会讨论，但更可靠的做法是看数据。做法是列三个排序，而不是凭印象列举。

排序依据	怎么排	它揭示了什么
按查询量	统计各域名在一段时间内的查询次数，取前 50	哪些域名的不可用会立刻影响多数人。这份名单决定「可用性优先」的防护
按失败代价	逐个问：这个域名解析失败时，业务是降级还是中断？只保留「中断」的	真正的资产通常比查询量前 50 少得多。这一步是把「高频」与「关键」分开
按信息敏感度	逐个问：这条查询被第三方看到，会造成什么后果？	可能包含不体现在查询量里的域名（内部系统、法务与人事相关服务）

可直接执行的采集示例需要你已有解析器侧的查询日志

# 1) 按查询量取前 50（假设日志含 qname 字段）
awk '{print $NF}' /var/log/dns/query.log \
  | sort | uniq -c | sort -rn | head -50 > top-domains.txt
# 2) 按失败代价分类（这一步是人做的，不是脚本）
#    对上面每个域名标注：中断 / 降级 / 无影响
# 3) 找「查询量低但敏感度高」的遗漏项
#    重点看：内部域、单点登录、代码托管、财务与人事系统
grep -E '\.(internal|corp|lan)$|sso|git|hr|finance' /var/log/dns/query.log \
  | awk '{print $NF}' | sort -u

第 3 步是很多人会漏的：敏感资产往往查询量很低，因为它们只被少数人访问。只按查询量排序会完全看不到它们。

没有日志就做不了这一步，而这正是很多威胁模型退化成「开会列举」的原因。如果目前没有解析器侧日志，那么本页的第一步应该是「先把日志建起来」—— 它同时也是治理的前提。

第二步：用「攻击成本」筛掉不值得防的对手

不是每个对手都值得专门设防。判断依据不是「它有多强」，而是它需要付出多少成本，以及它为什么会选你。

这张阶梯的用处是排除：最上面那一级只针对特定行业或特定目标。若你不属于会被定向选择的类型，那么为它专门设防的性价比很低 —— 应该把资源放在下面三级，因为它们是无差别的。这就是「明确接受某些威胁」的具体依据。

对手	它要付出什么	它会怎么选目标	为什么值得防（或不值得）
同网段攻击者	几乎为零，只需与你在同一网络	无差别，被动收集	值得防。任何加密都能挡住，是性价比最高的一项
出口运营方	零边际成本（能力随位置而来）	大规模、按策略而非按人	值得防。但注意：加密能挡内容，挡不住「你在通信」这件事
终端恶意程序	需先攻陷终端，成本中等	批量投放，不挑人	值得防，但防护点不在 DNS。加密 DNS 对已被攻陷的终端基本无效
定向攻击者	高：需要针对性投入与时间	只选特定目标（行业、职位、数据价值）	多数组织不值得专门防。若你确实属于被选中的类型，DNS 也不是主战场

第三步：画出攻击路径，并为每条定一个检测点

路径图的产出不是「路径本身」，而是检测点。一条画不出检测点的路径，等于放弃了发现它的机会。

攻击路径	环节	可部署的检测点
路径 A：明文链路被劫持	公共网络入口 → 注入伪响应 → 用户被导向钓鱼站 → 凭证泄露	出口出现 53 端口 DNS 流量。这是最容易部署的检测点 —— 若策略要求全部走加密通道，那么任何明文 DNS 都是异常，不需要判断内容
路径 B：受控终端策略被绕过	终端权限失守 → 改写解析器指向 → 走非受控上游 → 绕过审计	终端配置与基线不一致。这类检测的难点不在发现，而在「多久发现一次」—— 需要定期从终端侧反查生效配置，而不是只看下发记录
路径 C：单点上游失效导致中断	上游或链路故障 → 无备用 → 全量解析失败	备用上游从未被真实使用过。这条最隐蔽：只有主上游挂掉那一刻才会暴露，而那时已经来不及。可主动定期演练切换
路径 D：证书过期触发整体不可用	严格模式 + 证书到期 → 全部查询无响应（而非报错）	证书剩余有效期低于阈值。之所以单列，是因为它的失败模式很特殊：不是「变慢」而是「整体不可用」，且现象容易被误判为网络故障

四条路径里有三条的检测点不需要看 DNS 内容 —— 只看「端口」「配置一致性」「切换是否成功」「证书有效期」。这不完全是巧合：在加密 DNS 场景下，能看内容的地方变少了， 可观测的「元事实」反而成为更现实的检测手段。

第四步：一个完整的排序演算

「按影响 × 概率 ÷ 成本排序」这句话本身没有可执行性。下面把它算一遍 —— 你只需要把评分换成自己的。

防护项	影响 1–5	概率 1–5	实施成本 1–5，越低越易	优先级分影响×概率÷成本
关键链路启用加密 DNS	5	5	2	12.5
配置第二个可用上游	5	3	1	15.0
证书到期告警	5	2	1	10.0
日志与监控打通	4	4	3	5.3
终端配置基线核查	3	3	3	3.0
针对定向攻击者的强化	4	1	5	0.8

这组数算出来的结论

先做「第二个可用上游」（15.0）—— 成本最低、影响最高，是这类排序里最常见的胜出项
「针对定向攻击者的强化」垫底（0.8）—— 这正是前面「明确接受」的量化表达
「日志与监控」分不高（5.3）但不能延后：它是其它防护能被验证的前提，属于依赖项而非竞争项

最后一条说明纯排序的局限：依赖关系不能靠分数表达，要单独标注。

用这个表时要注意的两点

「成本」用的是实施成本，不含长期运维成本。若某项需要专人维护，要把它从「低成本」上调 —— 否则排序会偏向那些「装得上但养不起」的项目
分数要能说出依据。与选型手册的评分标准同理：没有判据的分数，换个人打就会得出不同排序

威胁模型最常见的三个失败方式

失败方式	后果	怎么避免
只列威胁，不做取舍	文档很长但无法指导决策，团队仍会反复讨论同样的威胁	每一项都标注「防 / 不防 / 延后」，并写明理由
没有责任人	半年后条目仍停留在文档里，且没人觉得是自己的事	每个优先项后面直接写人名或团队，而不是「安全团队负责」
一次做完就不再更新	资产、对手与网络结构都会变，过期模型会给出误导性的优先级	设一个复核触发条件（如架构变更、安全事件后），而不是定期「重写一遍」