2026年9月9日 · 公众号：业务连续性+ 原文链接 ↗

【当勒索攻击成为企业危机——REPRA管理者演练笔记 03】

不是编故事：REPRA怎样用”情景—任务—能力”设计一场演练

系列回顾：[当勒索攻击波及三座工厂：为什么管理层也必须参加演练？]{.underline}

系列回顾：它不是”中了一种病毒”：从攻击者进入到企业无法正常经营

一场桌面演练，通常从一个故事开始。

星期二05:40起，衡澜智控的三座制造基地先后报告异常；关键系统无法使用，
生产、质量和客户交付开始受到影响；随后，攻击者发来勒索信息…

一个故事如果”编得好”，很容易吸引人，也很容易让人产生一种错觉：设计演练，就是把事件编得足够紧张，再准备几道问题让大家讨论。

但如果我们继续追问，真正困难的问题才刚刚出现：

为什么三座工厂会同时受到影响？
为什么某个系统中断会传导到生产、质量、供应链和客户？
为什么攻击者此时提出这个要求，而不是另一个要求？
参演团队作出不同选择后，下一步为什么会出现不同的后果和影响？
演练结束时，我们凭什么判断团队表现出了某种能力？

如果这些问题没有依据，故事再精彩，也可能只是一场情节由主持人随时推动、结论主要依靠主观印象的讨论会。

REPRA的做法正好相反：REPRA并不把故事作为起点，而是先研究情景、任务和能力。

三个看似简单的问题

“情景—任务—能力”可以先用三句话来理解：

情景：可能发生什么，将怎样发展，又会带来什么后果和影响？
任务：为了应对这些后果和影响，企业必须完成什么工作？
能力：为了把这些工作做好，企业需要具备什么？

这是一条从风险认识走向组织准备的正向逻辑：

情景 → 任务 → 能力

但在设计演练时，工作方向需要反过来：

能力：本次准备验证什么？
任务：需要参演团队完成什么，留下什么可观察的成果？\
情景：用什么事件和信息，把这些任务自然地”逼”出来？

于是，演练设计采用的是一条逆向逻辑：

待验证能力 → 演练任务与证据 → 事件注入与故事

正向和逆向并不是两套方法。正向链建立内容基础，逆向链从同一基础中选择本场演练需要验证的部分。

第一步不是写剧情，而是弄清风险怎样发生

REPRA首先研究的”情景”，不是一段供主持人朗读的剧情，而是勒索攻击如何发生、发展并影响企业的风险机理。

攻击者可能怎样进入并持续潜伏，如何扩张权限和横向活动，怎样寻找、窃取数据并削弱企业的备份和恢复条件；企业又会在什么时间看到异常，可能产生哪些风险后果，生产、质量、订单、供应链、客户和声誉会受到怎样的业务影响。

为了让这些影响不是凭空出现，REPRA还需要一家具备足够业务细节的典型企业。

在高科技制造业版本中，我们构建了虚拟的汽车电子一级供应商”衡澜智控”，设定了它的产品、客户、制造基地、关键业务活动、主要系统和数据、供应商与物流关系，并给出了简化但可用于决策的业务影响分析（BIA）和全风险评估（RA）结论。

这家公司不是一个只有名称和行业标签的”故事背景”。它已经具备了一套可以相互校验的经营参数：

+———-+——————————————————————————————————-+————————————————————————————————+ | 维度 | 模型设定 | 决策含义 | +:========:+=======================================================================================================+================================================================================================+ | 企业规模 | 境内A股上市；约9,200名员工；年营业收入约96亿元，净利润约7.2亿元；研发投入约10.5亿元 | 生产中断、数据泄露和市场传言可能同时进入经营、披露与声誉议题 | +———-+——————————————————————————————————-+————————————————————————————————+ | 产品结构 | 中央/动力域控制器约占收入34%，BMS约31%，车身与区域控制器约25%，工程与生命周期服务约10% | 源代码、标定、功能安全证据、软件版本和质量追溯的价值与恢复要求并不相同 | +———-+——————————————————————————————————-+————————————————————————————————+ | 制造 | 华东、华中、西南三座制造基地，共设26条SMT线；另有南方软件与测试中心；三地产量约占30%、48%和22% | “还有另一座工厂”不等于能够立即转产，工装、测试程序、物料认证、客户批准和PPAP范围都可能成为约束 | | | | | | 与研发 | | | +———-+——————————————————————————————————-+————————————————————————————————+ | 客户 | 前五大客户约占收入55%，最大客户约占18%；订单余额约32亿元；成品缓冲平均约2.5天 | 中断超过48—72小时后，重点客户供货压力明显上升，恢复顺序必须在客户、产品和承诺之间取舍 | | | | | | 与交付 | | | +———-+——————————————————————————————————-+————————————————————————————————+ | 供应链 | 核心车规级MCU/SoC存在单一来源，库存约13天；PCB、模拟前端、通信器件和物流资源的替代难度各不相同 | “找到替代供应商”并不等于可以立即替代，变更可能触发重新设计、验证和客户认可 | +———-+——————————————————————————————————-+————————————————————————————————+ | 数字依赖 | 统一身份以及ERP、PLM/ALM、MES、QMS/LIMS、WMS/TMS/EDI、备份恢复平台共同支撑三地运营 | 单个系统启动不能证明订单、版本、生产、质量、追溯和客户交付已经恢复可信 | +———-+——————————————————————————————————-+————————————————————————————————+ | 事件起点 | 三地综合负荷约91%；重点客户新产品距SOP还有9天；另一客户09:00到厂审核；4个交易日后计划披露季度经营信息 | 同一场攻击同时压缩生产、客户、质量和资本市场决策窗口，使”继续等调查结果”本身也产生影响 | +———-+——————————————————————————————————-+————————————————————————————————+

这些数值都是演练设计参数，不是行业统计，也不对应任何一家现实企业。它们的作用不是把虚构公司包装得”像真的”，而是约束任务、注入和裁决：如果把三座工厂改成一座，把2.5天成品缓冲改成10天，或者把关键物料从单一来源改成可即时替代，演练中的业务影响、恢复优先级和可选方案也必须随之改变。

这里需要结合两个相互衔接的视角：**RA（风险评估）识别勒索攻击及其与其他风险叠加后可能造成的后果；BIA（业务影响分析）分析业务中断随时间产生的影响、容忍边界和恢复优先顺序。**REPRA把后果与影响结合起来，避免情景只描述攻击威胁，却没有回答企业为什么必须在某个时间作出决定。

企业模型与攻击机理交叉之后，才会形成这个行业版本的演练情景。

在REPRA当前设计中，我们把风险演化归纳为10个情景机制：

高依赖企业、供应链暴露与准备条件；
定向入侵与持续潜伏；
权限扩张与横向活动；
数据发现、窃取与外传；
身份、备份和关键系统受控；
加密破坏与生产经营中断；
数据敲诈与公开施压；
供应链与相关方连锁影响；
恢复不确定性与安全复产；
以及事后责任、损失与治理改进。

这10个机制不是10段剧情，也不是要求每场演练全部出现。它们更像一套”风险生成规则”：解释任务为什么会出现，也约束后续情节不能随意编造。

攻击者画像和隐藏攻击时间线，则为每一次具体演练提供更明确的幕后事实。参演者不会获得”上帝视角”，只能看到企业在当时能够感知、调查或从外部得到的信息；导调人员却必须知道背后真正发生了什么，才能保证前后事实一致，并对不同决策作出有依据的裁决。

从后果和影响出发，企业究竟要完成什么

知道”会发生什么”之后，下一步不是马上写注入卡，而是分析：为了控制风险后果、减轻业务影响、维持关键业务并恢复企业运行，各团队在全过程中必须完成哪些工作。

REPRA把这些工作组织为三个颗粒度层级：

————————————————————————————————— 层级 当前数量 主要作用 ————— ————— ——————————————————————— 关键任务包 12个表达管理层需要解决的相对完整问题或应对工作包，是演练裁剪的内容来源

任务组 30个表达全过程中的工作主题或任务簇

企业参考任务 85项表达可执行、可分工、可交付、可观察的真实世界任务 —————————————————————————————————

这些任务覆盖从事前准备、事件发现与危机启动，到危机指挥部启动与态势研判、危机决策与指挥协调、网络安全处置与IT恢复、运营连续与供应链保供、数据影响、报告披露与相关方沟通、攻击者联络、谈判与支付决策，以及运营恢复规划、综合验收与稳定运行的全过程。

其中，一些看起来”很技术”的基础任务也不能被省略。例如，企业需要持续调查攻击路径，包括初始访问、横向活动、持久化和数据外传路径，清除威胁并阻断再次入侵；同时在可信或受控环境中恢复系统和数据，补录中断期间的信息，并完成技术、业务、质量和供应链验证。

但85项参考任务并不是发给参演者的检查表，更不意味着一次4小时或1小时的演练要把它们全部做完。

它们是一套全过程任务库。每场演练只根据主题和待验证能力，从中选择、组合和压缩少量任务。12个任务包便于选题，30个任务组便于组织，85项参考任务则为演练任务、预期成果和评价证据提供可追溯的依据。

完成了任务，不等于已经证明了能力

任务回答”要做什么”，能力回答”能否在相应条件下把事情做好”。两者有关联，但不是同一件事。

例如，一支团队在指挥板上写下”局部隔离、维持部分生产”，只能说明它作出了一个选择。要判断相关能力，还要继续观察：

是否区分了已知事实、假设、未知事项和攻击者主张；
是否识别了生产、质量、供应链和客户影响；
是否形成了不止一个可执行选项，并比较其后果和影响；
是否说明了不可突破的风险边界；
是否明确责任人、时限、监测指标、升级和回退条件；
新证据出现后，是否能够更新态势并动态调整决策。

因此，REPRA把完成任务所需的共性要求重新组合为能力模型。目前形成了4个能力域、8个一级能力组和24项二级能力：

24项二级能力是REPRA实际使用的能力评价单元，此处仅展示其上层结构；它们与85项参考任务的具体联系将在后文矩阵中呈现。

真正可追溯的映射，发生在85项参考任务与24项二级能力之间，而且是受控的多对多关系。

一项任务可能同时留下专业判断、跨部门协同和危机决策方面的证据；一项能力也不能只凭一次发言或一张表格下结论，而需要多个任务中的直接证据和辅助证据共同支撑。

所以，REPRA采用的评价链条不是”任务打勾—能力得分”，而是：

参考任务 → 团队行为与任务成果 → 主要/辅助能力证据 → 有边界的能力结论

这里的”有边界”很重要。一场短时演练能够观察到某些判断和协同行为，却不能因此宣称已经证明了企业在真实压力下的完整能力。未被本场覆盖的内容，仍需要结合制度与资源审查、专项测试、其他演练或实际事件证据继续验证。

演练设计为什么要把这条链倒过来

当内容基础建立之后，一场具体演练才开始生成。

假设本场希望验证”恢复准入、运营状态调整与治理改进决策”中的一部分，设计人员需要先确定：团队要基于哪些专业证据，决定可信恢复、限制性恢复、分阶段恢复，还是暂缓恢复；还要明确什么情况必须停止或回退。

然后，再从任务库中选择相应任务，例如：

比较不同恢复路径及其时间、数据损失和残余威胁；
验证系统、数据、生产、质量与供应链条件；
形成恢复证据包和可执行选项；
发布带有监测、复核和回退条件的恢复决定。

最后，设计人员才会安排事件注入：备份验证结果、威胁清除进展、客户供货压力、质量部门的限制意见、供应商恢复状态，或者恢复后出现的新告警。

这些注入按照隐藏事实、企业感知和影响时间线进入演练，参演团队的决定又会触发后续后果和影响。由此形成的故事，不是事先写死的一条戏剧性路线，而是一组围绕验证目标、可以被决策改变的事件序列。

这也是动态裁决的基础。

故事仍然重要，但它是载体，不是起点

我们并不否认故事的价值。

一个好的演练故事，能够让参与者迅速进入情境，感受到时间压力、利益冲突和信息不完整；能够把原本分散在IT、生产、质量、供应链、销售、法律、财务和管理层之间的问题，带到同一张危机指挥桌前。

但故事是否精彩，并不是最重要的判断标准。

更重要的是：它能否自然触发预定任务，能否让不同选择产生符合情景逻辑、且有据可循的后果和影响，能否留下可以观察和复盘的能力证据。

所以，REPRA所说的”故事”，实际上是最后被看见的那一层。在它背后，是典型企业模型、业务影响与风险分析、攻击者画像、隐藏攻击时间线、风险情景机制、全过程任务框架、能力模型、证据规则和导调裁决。

参演者不需要先学习这整套方法。他们只需要走进危机指挥部，面对即时能够获得的信息，形成判断并作出决定。

方法的复杂度，应该由产品设计和导调团队承担；参演者获得的体验，则应当简洁、紧张、可信并且值得复盘。

一场演练，不必验证所有能力

REPRA的完整框架是一套内容资产，不是一张要求每场演练全部完成的试卷。

4小时试玩版可以让整建制危机指挥团队经历一条较完整的事件主线，并集中验证若干关键能力；60分钟关卡版则可以每次选择一个管理难题，用较低的参与门槛完成一次决策体验；进入真实企业后，还可以结合其组织、业务、系统、供应链和管理重点，形成定制演练。

无论采用哪一种形式，基本逻辑都不变：

先明确要验证什么能力，再选择需要完成的任务；
用情景和注入让任务自然发生，通过行为与成果留下证据。

故事让人进入演练，任务让团队真正行动，能力证据则让复盘不止停留在”大家很投入、讨论很热烈”。

这就是REPRA为什么不从编故事开始。

一张矩阵，把方法落到工程化结构

如果只看前面的文字，“情景—任务—能力”仍然可能像一种概念表达。下面这张矩阵，是REPRA当前高科技制造业版本的设计底图之一。

矩阵纵向排列85项企业参考任务，横向排列24项二级能力；“主”表示该任务直接形成某项主要能力的证据，“辅”表示只有形成独立、可观察的成果时，才可作为辅助能力证据。每一行任务都能向上追溯至任务组和任务包，每一列能力也都需要来自不同任务的证据支撑。

图：REPRA 85×24任务—能力现行矩阵V1.8。图中”主”为主要能力映射，“辅”为辅助能力映射。

这张矩阵不是一次演练的任务清单，也不是已经得出的企业能力评分。它主要解决三个设计问题：一项演练任务为什么值得设置，它可能留下哪些能力证据，以及某项能力结论究竟由哪些任务成果支撑。

公开测试和企业定制演练，都不会把整张矩阵直接交给参演者。设计人员会根据本场目标从中抽取部分能力与任务，再转化为简洁的事件注入、现场成果和观察要点。参演者看到的是一场容易进入的演练，设计人员背后使用的则是一套可以追溯的结构。

首期公开测试即将启动

REPRA首期公开测试将以高科技制造业典型企业为背景，邀请参与者组成企业危机指挥团队，在有限时间和不完整信息下处理连续出现的管理问题。

参与者不需要具备网络安全技术背景，也不会接受团队排名或企业正式能力评级。我们希望验证的不只是参演团队的决策过程，也包括REPRA本身的规则理解、信息负担、时间节奏、动态裁决与复盘效果。

具体公开测试的时间、地点、参与对象和报名方式，将在下一次推送中正式发布。

如果你希望亲自走进”星期二05:40”的危机指挥部，欢迎留意下一次更新。

说明：本文中的衡澜智控及其客户、基地、产品、人员、财务和事件均为虚构设定，用于承载典型高科技制造业的依赖关系与管理问题，不对应任何一家现实企业。文中10/12/30/85/24为REPRA高科技制造业现行设计结构，后续可能根据公开测试和企业实践继续迭代。REPRA用于演练和培训，不替代网络安全、法律合规、财务、保险、监管报告或危机管理专业意见。

关于 REPRA

REPRA（Response Exercise Package to Ransomware Attack，勒索软件攻击应对演练包）是一款面向企业管理层的勒索软件攻击应对演练产品，尤其适用于对业务持续运行要求较高的组织。首批公开测试计划于近期启动，具体时间、地点与参与方式将在官网及公众号「业务连续性+」公布。

如您或您所在的协会、院校、企业希望优先了解测试安排，或有意组织体验，欢迎与我们联系：电话 010-5360 5969 ｜ 13001090810（微信同号）。

《当勒索攻击成为企业危机——REPRA管理者演练笔记》系列