“交赎金还是不交赎金？”这是一个值得深入思考的问题

近日，有商业银行的专家询问勒索软件应对演练的问题：“究竟该由哪个部门牵头？风险管理部，信息科技部还是其它部门？……”这是一个有意思的问题。

正好我也在关注勒索软件攻击事件应对，想到另外一个重要的问题，“该不该交赎金？”因为，这两年与不少业内专家交流过，有不少人说过：“得交啊，不交怎么行？”可是这个问题的答案是否就这么简单！！！

“交赎金还是不交赎金”，这是一个值得深入思考的问题。

在《Ransomware: Understand. Prevent. Recover.》这本Amazon排名第一名的勒索软件的书中，作者 Allan Liska 在第19章《The Most Asked Question: Should We Pay the Ransom?》，系统讨论了支付赎金的利弊与复杂性。以下是该章节核心内容的总结，以及建议的决策流程设计：

一、支付赎金的现实考量

支持支付赎金的理由：

• 业务中断影响重大 — 无法恢复关键系统，业务损失不断扩大；无法通过备份恢复，或恢复速度太慢。
• 数据泄露或威胁公开 — 包含敏感客户数据、知识产权或高管通信内容；担心声誉风险、监管合规问题（尤其在金融、医疗、政府领域）。
• 员工/客户生命安全受威胁 — 医疗、能源、交通等关键基础设施的持续中断可能导致生命风险；紧急情况下组织需以公众/客户安全为第一优先。
• 攻击者沟通中显示出可控性 — 对方遵守协议、有支付后成功解密的历史；存在谈判空间，如减价、样本解密、延长期限。

不建议支付的理由：

• 支付无法保证恢复 — 攻击者可能不会交出有效的解密工具；数据可能已损坏，解密失败率不低。
• 支付鼓励犯罪 — 支持攻击者业务模型、资助进一步攻击；被标记为“付款目标”，可能遭遇后续勒索（double extortion）。
• 合规与法律风险 — 若攻击团伙属于被制裁实体（如OFAC清单），支付行为可能触法；金融机构、上市公司支付行为需报告监管方，或面临信披义务。
• 可能无法避免信息泄露 — 即便支付，数据也常在暗网上被出售；攻击者常在数月后再次发起威胁，要求“删数据”或“二次保护费”。

二、支付赎金的判断与决策流程（建议版）

以下是可供企业在勒索软件事件中参考的支付决策流程框架：

阶段0：准备阶段（未发生攻击前）

• 明确企业立场（如“不支付原则”或“条件支付”）
• 法律顾问、保险公司、外部事件响应（Incident Response）公司事前签约
• 建立支付前审批机制：如CISO + 法律 + CEO/董事会共同决定

阶段1：初步评估阶段

• 确认影响 — 哪些系统被加密？是否涉及数据外泄？是否有样本文件被公布？
• 评估恢复能力 — 是否存在未被感染的离线备份？恢复时间是否能接受？是否能实现关键业务最小运行？
• 法律合规评估 — 攻击者是否在受制裁名单？是否需报告执法机关？企业是否受到监管约束（如GDPR、HIPAA、SEC规则等）？

阶段2：决策会商阶段

建议组建临时“Ransomware决策工作组”，包含以下关键成员：

角色	关注重点
CEO/COO	全局影响、声誉管理、业务恢复
CISO/技术主管	恢复能力、安全溯源
法律顾问	合规、制裁清单、法律风险
PR/公关负责人	声明与媒体应对
外部专家（如谈判顾问）	攻击者背景、谈判策略
网络安全保险代表（若有）	保单是否覆盖支付？赔付条件？

阶段3：决策与行动

若决定不支付：

• 向执法机构报案
• 启动完整恢复计划
• 发布外部声明（如适用）

若决定支付（建议至少满足以下条件）：

• 无可行的恢复路径
• 数据确实存在泄露威胁
• 攻击团伙不在制裁清单
• 经合规律师评估支付合法
• 谈判顾问判断攻击者可信且历史上守约
• 组织内最高管理层批准

支付过程中建议：

• 使用受监管第三方（如谈判公司）执行支付流程
• 要求对方先提供部分样本解密文件验证
• 全程记录与攻击者互动信息，以供未来调查或取证

三、作者的结论态度

作者明确指出：

支付赎金是一种失败的选择，但某些情况下不得不选。问题不在于是否支付，而是你是否在做出决定前进行了清醒、系统性的分析。

---

原文发表于公众号“王曙说”