学习DORA 04｜漏洞三个月没修，出了事到底该怪谁？

layout: single author_profile: true read_time: true comments: false share: true ———–

假设一下Tenable扫出来一个核心系统有高危漏洞。IT确认这个漏洞需要修复，但是修补需要停机两个小时。业务部门说最近是结算期，不能停。

于是第一次延期。

下个月还是不能停。

再下个月继续延期。

三个月以后，这个漏洞真的被利用了，出了安全事件。那这件事到底该怪谁？

我觉得吧：IT肯定有责任，然后公司的管理层也有责任，毕竟没有尽到监管义务。这应该也算大多数人的第一反应。一般来讲，漏洞是IT的东西，没修，那不就是IT的问题么。但是继续往下聊以后，发现这个事情其实没那么简单。因为“漏洞没修”这四个字，根本看不出来中间到底发生了什么。有可能是IT压根不知道，有可能是知道了但是忘了，有可能是想修，业务不让停，有可能已经评估过了，管理层认为现在停机会造成更大的业务风险，所以决定暂时接受。

这几种情况最后看起来都是：

漏洞三个月没有修。

但性质完全不一样。

IT发现了漏洞，不代表IT可以决定一切

假设Tenable发现漏洞以后，IT和Security做完分析：

High Risk，需要两周内修复。

正常情况下，事情当然很简单，安排窗口，打补丁，验证，然后关闭。但实际情况经常没有这么顺。业务部门可能说：

现在不能停。

这个理由是很合理的，比如月底结算、客户交易高峰、重大项目上线，或者这个系统本身就是一个重要业务系统。

这时候就会出现一个挺有意思的问题。修漏洞有风险，不修漏洞也有风险。

现在修
→ 可能造成业务中断

现在不修
→ 继续暴露在安全风险里面

所以所谓“风险管理”，很多时候根本不是消灭风险。而是在两个都不太舒服的选项里面选一个。

IT可以告诉你，这个漏洞技术上有多严重，Security可以告诉你：攻击面在哪里。

但IT并没有天然的权力去决定，为了修这个漏洞，我们愿意让整个业务停两个小时。这种决定已经不是纯技术问题了。

那谁可以说：这个风险我们先接受？

这个问题我以前其实没有认真想过。在很多公司里，实际操作可能特别随意。 业务说：最近比较忙，下个月再修吧。IT说：行，毕竟摸鱼不香吗。 excel里的Due Date从5月改成6月。6月到了以后： 还是不行。 再改成7月。 看起来一直在“跟踪整改”，其实什么都没发生。

学DORA，发现真正的问题可能不是：为什么这个漏洞还没修？

而是：谁决定它可以不修？

这两个问题完全不一样。

如果决定暂时不修，至少应该把事情变成一个正式的风险决策。 这是我学到的在管理上狠很重要的一个点，风险决策管理

比如：

发现漏洞
   ↓
确认无法按期修复
   ↓
说明为什么不能修
   ↓
重新评估风险
   ↓
有没有临时控制措施
   ↓
谁接受这个风险
   ↓
接受多长时间
   ↓
什么时候重新检查

DORA当然没有发给每家银行一张统一的“漏洞延期审批表”。但它要求ICT risk management是有治理、有责任、有记录、有监督的。所以Exception不应该等于，算了，下个月再看看。

它应该是一个真正被识别出来的风险，有人知道它，有人接受它，而且这个接受应该有期限。

但这里又有一个坑：签字接受风险，不等于签字背锅

假设IT已经明确说明：高危漏洞，建议两周内修复。

业务Owner正式决定：因为季度结算，接受三个月的风险。

同时也做了一些临时措施，比如网络隔离、限制访问、加强监控。

结果第二个月还是被攻击了。

那么我们思考下：

那不是管理层失职么？毕竟你签字接受了风险。

后来发现这个理解也不完全对。

接受风险的意思，本来就是：

我知道它可能发生，但基于目前的信息，我决定暂时承受这个风险。

风险管理不是预测未来。

如果只要风险最后真的发生，就反推当时的决定一定错误，那风险管理就没法做了。

最后会变成：

没出事
→ 决策正确

出了事
→ 决策错误

这就有点事后诸葛亮了。

所以更准确的说法应该是：

管理层或者Risk Owner需要对这个决定负责，但“负责”不等于“失职”。这个度确实很难把握，尤其是在某些地方的氛围，绝不担责，你懂的。

英文里面这两个词区别反而挺直观：

Accountability is not the same as fault.

真正应该回头检查的是，当时为什么接受？是不是超出了公司的risk tolerance？三个月这个期限有没有依据？临时控制到底有没有用？是谁批准的？这个人有没有权限？风险接受以后有没有继续监控？

如果这些东西都做得合理，最后风险还是发生了，那只能说：

一个已经被接受的residual risk真的发生了。

这和“没人管，然后莫名其妙出事”完全不是一回事。这个点我以前其实分得不是很清楚。我认为DORA设计的不错。不得不说欧美的很多管理学理念是走在前面的。

Management Body也不是每天审批CVE

上一篇和Day 1都碰到过management body。

DORA Article 5把ICT风险的最终治理责任放在management body。

但如果理解成：每一个高危漏洞最后都要送董事会签字。那估计董事会一天什么也不用干了，就在那里批CVE。Management body管的不是每一个具体技术问题。应该管的是这套机制。

比如： 什么风险可以由System Owner接受？ 什么风险需要Risk审批？ 什么风险超过阈值以后必须升级？ 最长可以延期多久？ 什么情况必须向Senior Management报告？ critical or important function是不是有更严格的要求？

这些规则应该提前定好。所以真正合理的结构应该是：

日常漏洞
→ IT / Security处理

无法按期整改
→ System / Business Owner

严重风险或者长期延期
→ Risk / Security Committee

超过risk tolerance
→ 更高管理层

具体到底30天、60天还是90天，我觉得不重要。每家机构可以不一样。真正重要的是：

过了deadline以后，到底会发生什么？

这个问题我觉得特别难搞。因为很多表格都有Due Date。但Due Date过了以后呢？

有时候答案就是：

再发一封邮件。

再过一个月：

再发一封。

再过一个月：

再提醒一下。

这其实只是tracking，不一定真的叫governance。如果真正有治理，应该是越拖，事情越往上走，而不是永远停在原来的Excel那一行里面。

三道防线这个东西，这次终于稍微理解了一点

以前也经常看到Three Lines of Defence。 说实话，以前一直觉得是银行和审计特别喜欢发明的一种组织架构名词。 这次拿漏洞这个例子套进去，反而一下子就明白了。 第一道通常是业务、IT这些真正拥有和运行风险的人。 比如IT负责修漏洞，System Owner负责系统，业务负责业务影响。

第二道是Risk、Compliance或者相关的Security oversight。 他们不是每天替IT打补丁，而是去问：

为什么这个漏洞已经超期90天？ 你说不能修，有没有正式依据？ 谁接受了风险？ 临时控制在哪？

第三道是Internal Audit。 Audit更狠一点。 它甚至不一定关心这个漏洞技术上到底是什么CVE。 它可能随机抽十个高危漏洞，然后发现：

漏洞发现：1月
整改期限：2月
现在：8月
状态：Open
原因：Business unavailable
Risk acceptance：没有
Compensating control：没找到证据
Escalation：没有
Owner：已经离职了

到这里其实根本不用继续研究CVE，整套流程已经很说明问题了。

Audit完全可以问：

你们这个Vulnerability Management到底有没有真的在运转？

所以Internal Audit不是去替Security做第二遍漏洞扫描。

它是在检查：

前面那些所谓的控制，是不是只有制度上写着，实际上根本没工作。

理解加深后，我突然意识到，或者说以前也懂，只是不知道自己知道：我们平时做的很多表格其实都是证据（注意 ，不是台账管理那么简单）

这件事情跟我现在的工作其实特别接近。

漏洞表。 PDCA。 整改记录。 邮件。 Ticket。 Meeting minutes。 Risk acceptance。

有时候真的会觉得这种东西很烦。一个技术问题，修掉不就完了吗，为什么后面还要跟这么多东西。但现在从DORA的角度看，我开始有一点理解这些东西为什么存在。因为最后监管或者Audit问的经常不是：

你当时有没有讨论过？

而是：

Show me the evidence.

然后问题就会变成：

Who decided?

When?

Based on what?

For how long?

Who approved it?

What temporary controls were applied?

Was it reviewed again?

How was it finally closed?

你嘴上说：

我们当时开过会了。

没什么用。你说：

Security当时已经提醒过业务。

证据呢？业务说：

我们当时知道有这个风险。 谁接受的？所以最后这些看起来特别行政化的东西，其实是在记录一件事情：

一个风险从被发现，到最后被关闭，中间到底发生了什么。

现在想想，这可能才是很多GRC工作的核心。不是把Excel填得更漂亮。而是确保以后真的有人能把整个decision trail翻出来。

所以漏洞三个月没修，到底怪谁？

现在再回头看今天最开始的问题，我已经没办法简单回答：

IT。

也不能直接回答：

管理层。

应该先把中间过程翻出来。

如果IT压根没发现、没跟踪、没处理，那当然首先是IT控制的问题。

如果IT已经提出修复，但是业务一直拒绝，又没有正式risk acceptance，没有compensating control，也没有向上升级，那就是整套治理链出了问题。

如果风险被正式评估、由有权限的人接受、有临时控制、有期限、有持续review，最后还是出了事，那至少不能仅仅因为“出事了”，就倒推整个风险管理一定失败。

出了事故以后当然还要复盘。

甚至可能发现当时的评估模型不对、risk tolerance太宽、临时控制没有想象中有效。

但那是另一个问题。

我现在觉得DORA把ultimate responsibility放到management body，不是在说：

系统出了什么问题，最后都让董事会背锅。

而是在说：

公司必须建立一套机制，不能让重大ICT风险长期存在，却没人知道是谁决定的。

今天我觉得最好记的一句话反而不是法规原文。

是：

一个风险长期存在不一定代表风险管理失败。真正可怕的是，没人知道为什么它还在那里、谁接受了它，以及准备接受多久。

还有一句：

Risk acceptance is not risk elimination, and accountability is not the same as fault.

So, be informed, be accountable, and keep the evidence.