6-8 什么才是正确的风险应对 · 波仔的网络与信息安全课

📄 一句话概括

风险应对的四种选择（规避、降低、转移、接受）之所以常常退化成【一律降低】，是因为风险准则没有在评估开始前定好——准则先定，评价就变成机械动作，而不是政治动作。

📝 本节和前面几节的关系

6-2 里 PDCA 的 Plan 阶段，核心动作就是这一节讲的风险评估与处置；6-7 的 BCP 和 6-16 的冗余投入，都属于【处置】这一步挑出来的手段。 它和 4-13 是同一件事的两个尺度：4-13 给单条漏洞打分（CVSS／EPSS／KEV），这一节给整个场景排优先级——前者回答【这个洞多严重】，后者回答【钱该先花在哪儿】。

一、六步循环

ISO/IEC 27005 把风险管理描述成一个循环。这六步的顺序本身包含了很多设计意图：

步骤	做什么
① 建立语境	确定范围与准则：保护什么、用什么准则、可接受水平
② 识别风险	资产、威胁、脆弱性、现有控制，要完整不要精确
③ 分析风险	估可能性与影响，算出风险值
④ 评价风险	与准则比对，按风险偏好排序
⑤ 处置风险	规避、降低、转移、接受，四选一
⑥ 监督审查	剩余风险入账，定期复看

三个容易被跳过的细节，恰恰是这六步最要紧的地方：

① 里最重要的是【准则】。【可接受风险水平】必须在评估开始前就定好并形成文件。否则评估会陷入一种无效争论：某个场景出现了，一半人认为它很严重、一半人认为可以接受——而这个分歧其实不是对风险的判断分歧，而是对【什么是高风险】的定义分歧。先把定义谈好，后面的评价就变成机械动作：拿数字对阈值。
② 里最重要的是【完整性】。识别阶段不要把可能性与影响混进来估。原因很微妙：一旦要求现场估【这个威胁发生的可能性大不大】，团队会下意识地跳过他们觉得不太可能的风险——于是识别清单里只剩【常见的那几类】。正确做法是先尽量把场景列全，之后再统一打分。
⑥ 最容易被省略。风险处置完之后，剩下那一块（剩余风险）必须正式记录——因为它意味着【我知情，且我选择接受】。没有这一步，【接受】就变成了【忘记】。

二、5×5 风险矩阵

最常见的量化方式是【风险值 = 可能性 × 影响】，画成 5×5 的矩阵：

      L1      L2      L3      L4      L5
  I5  5低     10中    15高    20极高  25极高
  I4  4低     8中     12高    16高    20极高
  I3  3低     6中     9中     12高    15高
  I2  2低     4低     6中     8中     10中
  I1  1低     2低     3低     4低     5低

L1~L5 是可能性由低到高，I1~I5 是影响由低到高。阈值（20／12／6）由组织在风险准则里自己定。

这个矩阵最大的价值是让讨论有个共同参照。但它有一个众所周知的盲区，值得单独讲：

它只看两个维度，看不到【恢复难度】。举个具体例子：【机房断电】这个场景，可能性给 2（大城市市电基本可靠）、影响给 5（全业务中断），算出来是 10，落在【中风险】。但任何有经验的人都会说这个必须重视——因为它的影响虽然算 5，实际后果可能持续数天，而且恢复过程复杂（涉及电力、制冷、消防多个专业）。

处理这个盲区有三种做法：① 在准则里给这类场景设专门条款（比如【影响为 5 的场景一律按高风险处理】）；② 把【恢复难度】并进影响评分（给影响加一个【持续时间】的细分维度）；③ 用更精细的量化方法（下面第四段要讲的 FAIR）。三种都可以，关键是别让矩阵的机械结果自动变成结论。

三、动手 Demo：给五个场景打分

assets = [
    ("对外门户的 SQL 注入", 4, 5, "降低：上 WAF 并改代码"),
    ("员工弱口令", 4, 3, "降低：强制策略 + 多因子"),
    ("机房断电", 2, 5, "转移：UPS + 保险 + 备用站点"),
    ("旧系统未打补丁", 5, 4, "规避：下线或隔离该模块"),
    ("供应商接口泄漏", 3, 4, "转移并降低：合同 + 接口限权"),
]
for name, li, im, act in assets:
    v = li * im
    tag = "极高" if v >= 20 else ("高" if v >= 12 else ("中" if v >= 6 else "低"))

实跑输出：

三、给五个场景打分，出结论
  场景                    可能性  影响    风险值  等级    处置建议
  对外门户的 SQL 注入     4       5       20      极高    降低：上 WAF 并改代码
  员工弱口令              4       3       12      高      降低：强制策略 + 多因子
  机房断电                2       5       10      中      转移：UPS + 保险 + 备用站点
  旧系统未打补丁          5       4       20      极高    规避：下线或隔离该模块
  供应商接口泄漏          3       4       12      高      转移并降低：合同 + 接口限权
  → 注意机房断电这一行：矩阵算出中风险，但业务直觉告诉你要重视。
     原因是矩阵只看可能性与影响，没看恢复难度。
     所以准则里可以再加一个维度，或对这类场景直接设专门条款。

四、剩余风险必须正式记录
  阶段                          风险值
  处置前（固有风险）            20，极高
  降低措施生效后                8，中
  剩余风险                      8，接受并持续监控，责任人写进台账
  → 风险不会因为做了措施就归零。剩下那一块，是要签字接受的。

读这个输出：

四个处置选项在这组数据里都出现了，这是刻意安排的。【降低】（上 WAF、改代码、加多因子）最常见，但【规避】（下线或隔离旧系统）往往被忽略——在很多场景里，【不做这件事】其实是性价比最高的处置。【转移】（保险、备用站点、合同条款）的价值在于它把钱变成可预算的固定成本。【接受】则必须留下记录。
【旧系统未打补丁】这一行值得多看两眼：可能性 5、影响 4，是矩阵里最难处理的一类。打补丁为什么不算最优解？因为对一个已停止维护的旧系统来说，打补丁本身可能引入新的不兼容——所以更彻底的处置是【规避】：把这个模块下线，或者把它彻底隔离到独立网段、只允许特定终端访问。这就是为什么处置选项要有四种而不是一种：最彻底的方案常常不是修补。
第四段那一行【剩余风险 8，接受并持续监控，责任人写进台账】是最容易被漏掉的。风险处置完之后一定会剩下东西——比如上了 WAF 之后，SQL 注入的风险降低了，但业务逻辑漏洞还在、账号被盗的风险还在。给剩余风险指定责任人和复查周期，等于承认【我们知道还留着这块，我们盯着它】——这一句写进台账，比前面那一堆打分更有价值。

四、2026 年的两个变化

【量化方法在往【说人话】的方向走】。 FAIR 模型在金融行业与大型企业里应用增多，它的特点是把风险换算成货币价值（比如【这个场景的年度预期损失是 300 万，波动区间是 100 万到 800 万】）。它的价值在沟通上：【高风险】这个词在预算会上说服力有限，【年预期损失 300 万】立刻可以被比较——这正是 6-7 里算连续性投入时用的同一个思路。 代价是它需要更多输入数据（事件频率、损失分布），估不准的时候结论也不可靠——所以它更适合放在决定大额投入的场景，而不是所有场景都上。
【资产清单这件事，从【台账】变成了【持续发现】】。 CyCognito 2026 报告指出：企业平均有 37% 的互联网暴露资产根本不在 IT 部门的资产清单里——这些影子资产是攻击者的首选目标（6-13 会展开这件事）。因此 2026 年的资产管理已从静态台账演进为动态的攻击面管理（ASM）：用自动化持续发现暴露在互联网上的域名、IP、云资源、SaaS 与 API。 对风险识别这一步的影响很直接：识别清单的来源不能再是【我们自己的台账】，而必须是【外部扫描到什么 + 我们自己知道什么】两者对照——差集那一部分，就是上一轮风险评估漏掉的东西。

五、⚠️ 2026 现状

【成本效益分析是标准要求的，不是可选项】。 如果控制成本高于预期损失，经济上就说不过去——这时候该考虑转移或接受，而不是硬上措施。 这条常常被技术团队忘掉：从【应该做到最好】出发，很容易给一个年损失几万元的场景配上几十万的方案。 标准并不反对做过头（有些场景确实要留冗余），但它要求你能说出理由——【业务要求零中断】是一个理由，【我们一直这么做】不是。
【风险准则里要写的三类准则，别只写一类】。 实践中最常见的遗漏是只写了【风险等级怎么定】，而漏掉另外两类：① 风险评估准则（可能性与影响怎么分档，用什么标尺）；② 影响准则（财务、合规、声誉、人员各占什么权重）；③ 风险接受准则（什么等级必须处理、谁来批准接受、接受的有效期多久）。第三类最容易被跳过，而它恰恰是让【接受】这个动作变得可追责的关键——没有它，【接受】就等于【忘了】。
【【供应商】应该单独进风险清单】。 2026 年的数据里，涉及第三方的泄露在持续上升（6-13 有具体比例）。原因是依赖变多了：云服务、SaaS、外包开发、数据接口、物流与支付通道。对这类风险，处置手段里【转移】（合同条款、责任约定）和【降低】（接口限权、数据最小化）通常比【自建】更划算——所以风险评估的输出里，应该明确列出【这条风险的责任方是谁】，而不只是【我们打算怎么做】。
【NIS2 这类法规把【风险分析】从最佳实践变成了义务】。 欧盟 NIS2 第 21 条要求实体具备【风险分析与信息系统安全的政策】——ISO/IEC 27005 正好提供了经检验的方法来满足这类要求。这个趋势的普遍意义是：风险评估从【内部管理动作】变成了【需要能出示证据的合规动作】——所以过程和结论都要留痕，不能只在脑子里过一遍。（国内的对应要求见 6-10。）

30 秒实验

今天做两个动作，各 15 秒：

给【我的手机丢了】这个场景打两个分：可能性（你过去三年丢过几次）与影响（照片、验证码、工作群、支付）。然后问自己一个问题：我现在的处置是哪一种——规避（不带出去）、降低（锁屏 + 远程擦除）、转移（保险）、接受（就这样吧）？ 多数人会发现自己的处置是【接受】但从来没正式想过——这正是风险台账要解决的问题。
想一个你所在环境里【可能性很低、但影响极大】的场景（比如核心交换机故障、主数据库损坏、唯一掌握某密码的人离职）。然后检查一件事：它在你的风险清单上吗？ 这一类的典型问题是它们永远排不进【按可能性排序】的前列，所以永远得不到处理——正确的做法是对这类场景单独设条款（比如【影响为 5 的一律按高优先处理】）。

这一节要带走的一句是：风险应对的难点不在算分，而在两件事——准则有没有提前定好（否则评价会变成争论），以及剩余风险有没有被记录下来（否则【接受】会变成【遗忘】）。

常见误区

错误：风险管理就是【把所有风险都降到最低】。——纠正：这是最容易导致资源错配的做法。风险管理的目标是【把风险控制在可接受水平】，而不是【消灭风险】——因为后者既做不到，也会把预算耗在不重要的地方。从 1-7 那条线看得很清楚：安全是有成本的，成本花在这里就花不到那里。一个具体的对照：给【某内部系统被篡改】这种年损失几万元的场景配上几十万的方案，与给【核心支付链路中断】这种年损失上千万的场景配基础方案，是两种相反的错误——前者浪费，后者冒险。 正确顺序永远是先排序、再分配资源，而排序的依据来自准则里定义的影响权重——不是来自谁的声音大。
错误：处置风险就是在四种手段里挑一个，挑完就结束了。——纠正：处置完之后必须做两件事，否则这一步是白做的。第一，确认【措施真的生效】——比如你决定【降低】，上了 WAF，那要验证它确实拦住了目标攻击类型（很多措施在执行层面打了折扣：策略设成只记录不阻断、规则只覆盖了一部分路径）。第二，记录剩余风险——风险不会归零，处置后仍留下的那部分必须指定责任人与复查周期。这两件事缺失的典型后果是：报告上写着【该风险已处置】，而实际攻击面没有明显变化，直到某天出事，才发现当初的措施从未验证过。 在监督机制里，这件事对应的是 6-3 讲的第一项指标：措施的有效性要能被度量。
错误：既然要用【可能性 × 影响】，那可能性就按【过去发生过几次】来算。——纠正：这样算会系统性低估新出现的风险。原因在于：新攻击手法、新上线的系统、新接入的外部依赖，它们的【历史发生次数】都是零——但零次不代表不会发生，只代表它太新。 更稳的算法通常把可能性拆成两部分：威胁的频率（外部环境里这类攻击有多活跃）与脆弱性的程度（防御有多容易被绕过）——前者可以靠威胁情报（附录 A.5.7 就是这一项），后者靠技术评估。 一个实用原则是：对新增的资产与外部依赖，第一次评估时宁可把可能性往上提一档——因为没有历史数据本身就是一种不确定，而不确定应该被保守处理。（这也是 4-13 里 EPSS 这类【预测利用可能性】的指标有价值的原因：它提供的是外部环境信号，而不是你自己的历史。）
错误：【接受】是最省事的选项，直接勾上就行。——纠正：【接受】是所有处置里最需要论证的一种，因为它意味着你主动决定不做任何事。它需要至少三个条件：① 有明确的批准人（通常要比日常执行层级更高）；② 有有效期（比如【接受至 2027-03-31】，到期自动重新评估）；③ 有触发重评的条件（比如资产范围变化、发生相关事件、外部威胁环境变化）。最典型的坏味道是：一份风险清单里大量条目标着【接受】，但没有任何一条注明是谁批准的、什么时候到期——这种【接受】实质上是【忘了】，一旦出事，追责时无法解释。顺便说，【接受】和【暂缓】要区分开：前者是决定不做，后者是决定先不做但要排期——两者都应该有期限，但【暂缓】必须有一条排进计划的任务。

自测三问（点开对答案）

1. 为什么风险准则必须在评估开始前就定好？ —— 因为**准则决定了评价这一步是【机械动作】还是【政治动作】**。**如果准则缺失，评价阶段实际发生的事是这样的**：**每个场景出现时，相关方各自按自己的经验和立场判断【这算不算高风险】**——**业务方倾向于说【可以接受】，安全方倾向于说【必须处理】**，**而这两方其实都没有错，只是用的标尺不同**。**一旦准则在事前统一（可能性怎么分档、影响怎么加权、什么等级必须处置、谁来批准接受），评价就退化成一个查表动作**：**算出数值、对照阈值、得到等级**——**讨论的焦点从【这算不算严重】转到【打分依据是否准确】，而后者是可以核对的事实问题。** **这也解释了为什么准则要在【评估开始前】定**：**事后定准则，等于按结论去调标准**，**而那份评估就失去了意义。** 2. 为什么说【剩余风险】这一步不能省？ —— 因为**它是【接受】这件事唯一的书面凭证，也是下一次评估的起点**。**风险处置不会让它归零**：**上了 WAF 之后，SQL 注入的风险降低了，但绕过 WAF 的手法、业务逻辑漏洞、账号被盗这些风险还在**——**这些留下来的部分如果不记，就会在下一次评估时被重新发现一遍，甚至根本不会被发现**。**记录剩余风险的三个作用**：**① 让管理层明确知道自己承担了什么**（否则他们会以为【做过处置】等于【风险没了】）；**② 给责任人一个明确的观察对象**（**【盯着什么】比【注意安全】具体得多**）；**③ 提供下次评估的基准**（**明年看这一条时，可以直接问【它变好了还是变坏了】**）。**实务上一个简单做法是**：**在风险台账里给每条剩余风险加三列——责任人、复查日期、复查结论**，**并让这三列成为监督会的议题之一**（6-3 的月度四问里，第 ④ 问就是它的位置）。 3. 5×5 矩阵算出来是【中风险】，但业务上都知道它很严重（比如机房断电），该怎么办？ —— **不要让矩阵的机械结果自动变成结论**。**矩阵只是把两个维度的打分相乘，它无法表达【恢复难度】【持续时间】【不可逆性】这些同样重要的性质**。**有三种成熟的补救方式**：**① 在准则里设【影响封顶】条款**——**比如规定【影响评分达到 5 的场景一律按高优先处理，不论可能性多少】**（**机房断电正好落在这条上**）；**② 把影响拆细**——**把【影响】分成财务、合规、声誉、恢复时长几个子维度分别打分再合成**（**这样【恢复要几天】就会体现在分数里**）；**③ 对这类场景单列清单**——**不进矩阵，直接列为【重点保障场景】，按场景配置资源而不按分数**。**三种做法里，第 ① 和第 ③ 最容易落地**，**因为它们不需要改整个评估方法**，**只需要在准则里多加一两句**。**这也说明一件事：矩阵是工具，准则是规则；规则可以覆盖工具的盲区，反过来不行。**

☐ 下一节（6-9 防止对不当内容的访问）