用ChatGPT做应急响应桌面演练

简而言之： 用概括性的方式把你的系统、供应商和数据描述给模型，然后让它构造一个带定时注入事件的90分钟场景，而不是一段事件描述。这种演练可以稳定地暴露出三到四个「这件事我们没有流程」的时刻。真正的交付物不是场景本身——而是复盘时那份带负责人和日期的问题清单。

大多数应急响应预案都是写一次、批准、归档，然后再也没有被测试过。它们读起来很好。里面有响应团队、有严重性分级、有一棵联络树。它们唯一没做过的事，是在一个房间里，让十二个人在时间压力下、信息不完整的情况下真正做一次决定。

桌面演练存在的意义正在于此：不是为了证明预案有效，而是为了找出它在哪里无效。中小企业跳过它的原因很直接——请咨询公司做一次带引导的演练是一笔实实在在的开销，而自己写一个真实可信的场景其实很难。那需要知道一次攻击从内部看究竟是什么样子、逐小时是什么节奏，而大多数没经历过的人写出来的场景都太干净了。

这件事很适合交给语言模型。构造场景是一项形式相当明确的写作任务，而模型读过数量极其庞大的事件报告。它不了解你的环境，也没法主持那个房间。但它把「到底要不要做这场演练」的最大障碍去掉了。

没被测试过的应急预案，为什么会在当天失效

失效的方式很一致，而且没有一条是关于技术能力的。

没人知道由谁来宣布这是一起事件。 预案上写着「启动应急响应团队」。它没写在周日晚上十点，谁有权把这句话说出口——于是第一个小时都花在群里讨论「这到底算不算一次事件」。

联络名单是过期的。 两个人已经离职，一个号码是某间没人进得去的办公室里的座机，而预案本身就存在那台刚刚被加密的文件服务器上。预案存放在哪里，本身就是预案的一部分。

没人决定过对外要说什么。 客户、员工、保险公司、监管机构——以及在越来越多的司法辖区里，一个带明确时钟的通报义务。在事件当中起草对外声明，产出的东西你事后会后悔；提前起草，只要二十分钟。

技术上的处置背后没有业务决策。 为了遏制，我们要不要把ERP下线——而工厂就跑在它上面？这不是一个IT决定，而如果演练从来没有逼某个人真正做过这个决定，那它到时候会做得又糟又慢。

恢复从来没有端到端测过。 备份是有的。但它们能不能恢复、把主系统完整恢复一次实际要多久、以及备份本身是不是从一个已被攻陷的网络里就能访问到——这是三个不同的问题，而各家组织通常是在事件当中才知道答案。

一场桌面演练能在九十分钟里把这五条全部找出来。这就是做它的全部理由。

构造一个贴合你公司的场景，而不是一个模板

让模型给「一个勒索软件桌面演练场景」，产出的东西会既通用又舒服。舒服就是失败状态——如果房间里没人感到不确定，那这场演练就是走过场。

输入：你的系统、你的供应商、你的数据、你真实会遇到的攻击者

给模型四样东西，都用概括的方式描述。

你在跑什么，按功能描述。 「一套云端ERP、一台文件服务器、一个邮件平台、一个部署在某个厂区本地的制造执行系统，以及一支分散销售团队的远程访问。」让场景落地的是功能和拓扑。具体版本、主机名和IP段对演练毫无帮助，应当留在外面。

你依赖谁，按类别描述。 外包的IT服务商、代发薪机构、有系统对接的物流伙伴。供应链场景恰恰是最有用的一类，因为其中的响应大部分是非技术的，而几乎没人演练过。

哪些数据出事会疼。 客户个人数据、图纸、价格、员工档案。它决定了场景里通报与披露那条分支，而那正是大多数组织最薄弱的地方。

一个真实的攻击者，而不是一个高深的攻击者。 常见情形是钓鱼导致的凭据失窃、一个没打补丁的对外服务，或者一个被攻陷的供应商账号。明确要求它围绕「对你这个规模和行业的公司来说合理的入口」来构造场景。国家级对手是一个更差的演练，因为面对它的大部分注入事件，诚实的答案都是「我们会找人帮忙」。

然后告诉模型房间里实际有谁——IT负责人、运营、财务、人力、一位董事——并要求它写出能逼每一个人做决定的注入事件。一场由IT回答所有问题的演练，对这个组织什么都没测出来。

注入与升级：一个场景如何在九十分钟里始终让人不舒服

真正的演练和一次讨论之间，结构性的差别在于定时注入：每隔一段时间释放新信息，改变局面，并且经常让刚刚做出的决定失效。

要求它在九十分钟里给出六到八个注入事件，每个都带时间戳、所揭示的信息，以及它被设计出来要逼出的那个决定。好的序列会沿三条轴同时升级——技术范围、业务影响、外部压力。大致像这样：一条告警，然后是「其实三天前就开始了」的证据，然后是一个业务系统失效，然后是一位客户直接发问，然后是数据外传的证据，然后是一个截止时间。

有两条指令能让场景明显变好。要求注入事件制造冲突，而不只是制造复杂度——运营想把系统恢复、安全想把它隔离，这一刻才是值得演练的，因为它是真正会被争执的那个决定。而且要求至少有一个没有好答案的注入，即每个选项都要付出代价。真实事件就是由这种时刻构成的，而演练的意义就在于「以前做过一次类似的决定」。

场景文档只给引导者看。参与者只拿到第一个注入。

实例：一家120人公司的勒索软件桌面演练

一家制造企业，有办公室和工厂，一套云端ERP、一台本地文件服务器和MES，以及一家外包IT服务商。九十分钟，八个人，一名引导者。

T+0。 两名员工反映文件打开报错，服务台收到三张工单。什么都还没确认。*逼出：这算不算一次事件，以及由谁来定？*

T+10。 文件服务器失去响应，共享目录里出现了勒索信。*逼出：遏制。你要不要隔离厂区网络，以及谁来批准让工厂断网？*

T+25。 日志显示初始入侵发生在九天前，走的是外包服务商的远程访问账号。*逼出：与供应商的对话，以及一个令人不适的认知——你平时会打电话求助的那一方，现在本身就在事件里面。*

T+40。 MES性能劣化，车间主管来问要不要停线。*逼出：一个有真实小时成本的业务决策，而做决策的人不在IT。*

T+55。 一位客户来邮件问他们的图纸有没有受影响，同时有记者打进了总机。*逼出：对外沟通，以及到底有没有人被授权可以说话。*

T+70。 出现了加密之前数据已被外传的证据。*逼出：通报义务、联系保险公司、以及法律顾问——这条分支大多数团队从来没走过。*

T+80。 备份管理控制台是对着那个已被攻陷的域做认证的。*逼出：过去八十分钟里所有人一直依赖的那个恢复假设。*

实际做下来，这场演练在大多数组织里会产出同一份清单：没有指定的事件指挥官、没有带外通信渠道、主系统的恢复时间从没测过、没有事先起草好的客户声明。这几条没有一条需要预算才能修。但如果你是在事件当中才开始修，每一条都要好几周。

AI生成的场景 vs 有引导的演练 vs 现成模板

成本与执行时间 — AI生成的场景压倒性胜出。一个小时准备，没有外部费用，而且你可以做到每季度一次而不是每年一次。
与你真实环境的贴合度 — AI生成的场景明显胜过模板，并且在你提供了真实语境的前提下逼近有引导的演练。模板描述的是一家通用的公司；模型描述的是你这家。
房间里的压力 — 有引导的演练胜出。一位熟练的外部引导者会对舒服的答案提出反驳、会注意到谁在往谁身上推，也不会允许房间用「这个IT会处理」来把一个注入事件糊弄过去。
读出组织内部的动态 — 引导者绝对胜出。最有价值的发现通常关于权限与迟疑，而这些对一个有经验的外人是可见的，对一个同事主持的场次则未必。
对保险公司或审计方的可信度 — 有引导的演练胜出。一份独立报告具有内部会议纪要所没有的证据分量——尽管一场真实演练的良好内部记录，仍然远胜于没有。
现成模板 — 只在省力这一项上胜出。它产出的是一场讨论而不是一场演练，因为所有人都看得出这个场景不是为他们写的。

对大多数中小企业来说，明智的路径不是二选一。用AI生成的演练按季度做，便宜地练出肌肉记忆、找出显而易见的缺口；每年一次——或者在重大审计之前——请一位引导者来做独立的那一次。做了那些便宜的，反而让贵的那一次收益高得多，因为引导者的时间会花在真正的薄弱环节上，而不是花在你本可以自己发现的问题上。

复盘才是交付物

演练本身不是重点。趁所有人还在房间里做的那三十分钟复盘，才是价值真正被创造出来的地方，而它恰恰是最常因为时间不够而被砍掉的一步。

用三个问题来做。有哪些事我们不知道该怎么做？有哪些我们以为没问题、结果从来没验证过？如果这是真的，我们哪里会做错？

然后把每一个答案转换成一条有指名负责人和日期的发现。不是「改进沟通」，而是「起草一份面向客户的对外声明，并在三周内由总经理批准，负责人是某某」。一场只产出主题清单的桌面演练什么也没产出；一场产出八条有主的行动项的演练，产出的是一份工作计划。

这些发现的聚集方式是可预测的：权限与升级、带外通信、恢复时间假设、第三方依赖，以及通报义务。如果你的清单长这样，说明演练奏效了。在离开房间之前就把下一次排上，并且在六个月后重跑同一个场景——第二次跑是在测试那些修复到底有没有落地，而这一点任何新场景都测不出来。

正确的做法——如何安全地描述你的环境，以及何时该让IT介入

三点实务提醒。

用功能的方式描述你的环境，而不是取证的方式。 「一台本地文件服务器加一套云端ERP」和一份写着你的主机名、IP段、固件版本、管理员账号名的文档之间，有实质性的区别。前者已经是一个好场景所需的全部。后者是一份放在第三方服务里的踩点资料。使用带有合同化数据处理条款的企业版，并把「场景对应到真实系统」的那一版留在你自己的文档里。

别让场景变成一次影子风险评估。 桌面演练告诉你的是「你怎么响应」；它不告诉你「你有多暴露」。这是两个不同的问题，而把第一个回答得很好，反而可能对第二个产生虚假的安心感。这些发现值得汇入一个有优先级、对标框架的视图——而这正是BrocentIT风险评估所产出的东西：一份对标ISO 27001、NIST CSF和CIS Controls的厂商中立评估，附带一份可直接呈给董事会的报告，以及90天、六个月、十二个月的整改路线图。桌面演练之后，正确的下一个交付物是它，而不是又一场演练。

运营层面的发现，和实际运维你IT的那一方一起修掉。 带外通信、经过测试的恢复时间、特权访问复核、供应商访问控制，这些都是日常工作，也正是我们的AI+支持与托管IT支持存在的意义。Brocent自2007年在北京创立以来一直在支持亚洲各地的客户，总部位于新加坡，香港办公室自2016年设立。至于「人」这一半的准备度，钓鱼邮件模拟演练测试的正是这些场景大多数的起点，而用AI识别钓鱼邮件覆盖的是同一个问题的技术面。

常见问题

为了构造场景而把我们的基础设施描述给AI，安全吗？

这完全取决于你描述到多细。功能性的描述——「一套云端ERP、一台本地文件服务器、一家外包IT服务商」——几乎没有风险，而且已经是场景所需的全部。主机名、IP段、固件版本、账号名和网络拓扑图则是另一回事，而且对演练没有任何帮助。使用带有合同化数据处理承诺的企业版而不是个人账号，并把场景与真实系统之间的对应关系留在你自己的文档里。

房间里应该有谁？

不能只有IT。这场演练测的是组织的决策能力，所以你需要：有权批准把某个系统下线的人、对客户说话的人、负责员工沟通的人，以及一位能拍板带钱决策的董事。八到十二人是一个可行的规模。如果每一个注入事件都是IT在回答，那这个场景没有在测试这个组织——重写注入，把决定逼到其他角色身上。

应该多久做一次？

如果场景是你自己生成的，那就每季度一次——当成本只是一个小时的准备时，这是现实可行的。最低限度每年一次，并且在任何重大变化之后：换了核心系统、发生并购、更换IT服务商，或者真的出过一次事件。六个月后重跑同一个场景被严重低估了：它测试的是上一轮的发现有没有真的关闭，而这是新场景做不到的。

这能满足保险公司或审计方的要求吗？

有时候能，取决于他们要的是什么。很多保险公司和框架会问「应急响应是否经过测试」并要求证据——那就保留日期、参与者、场景摘要、发现和整改状态的记录，而这些内部演练完全能产出。但如果对方明确要求独立评估或正式报告，那么内部引导的演练无法替代。读一下要求的原文，别往任何一个方向想当然。

这些发现该怎么处理？

在任何人离开房间之前，把每一条转换成有主、有日期的行动项，并且在一个固定时间点复核，而不是等到下一次演练。可以预期它们会聚集在权限、带外通信、恢复时间假设和第三方访问这几处。大多数是花时间而不是花钱的流程修复。如果某条发现指向的是结构性缺口——没有经过测试的恢复能力、没有值得调查的日志——那它属于一份有优先级的整改计划，而不是一张行动清单。

从哪里开始

把那四样输入写下来——按功能列出你的系统、你的重要供应商、出事会疼的数据，以及你真正预期的入口——然后生成一个九十分钟的勒索软件场景。在动笔写之前先把会议室订好，因为被排进日历的那场演练才是真的会发生的那场。如果复盘暴露出来的缺口不是靠流程就能补上的，那正是「一份有优先级的整改计划比又一场演练更值钱」的那个时刻：联系我们。