用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服務商，或者真的出過一次事件。六個月後重跑同一個情境被嚴重低估了：它測試的是上一輪的發現有沒有真的關閉，而這是新情境做不到的。

這能滿足保險公司或稽核方的要求嗎？

有時候能，取決於他們要的是什麼。很多保險公司和框架會問「事件應變是否經過測試」並要求證據——那就保留日期、參與者、情境摘要、發現和改善狀態的紀錄，而這些內部演練完全能產出。但如果對方明確要求獨立評估或正式報告，那麼內部引導的演練無法替代。讀一下要求的原文，別往任何一個方向想當然。

這些發現該怎麼處理？

在任何人離開房間之前，把每一條轉換成有主、有日期的行動項，並且在一個固定時間點複核，而不是等到下一次演練。可以預期它們會聚集在權限、帶外通訊、復原時間假設和第三方存取這幾處。大多數是花時間而不是花錢的流程修復。如果某條發現指向的是結構性缺口——沒有經過測試的復原能力、沒有值得調查的日誌——那它屬於一份有優先順序的改善計畫，而不是一張行動清單。

從哪裡開始

把那四樣輸入寫下來——按功能列出你的系統、你的重要供應商、出事會痛的資料，以及你真正預期的入口——然後生成一個九十分鐘的勒索軟體情境。在動筆寫之前先把會議室訂好，因為被排進行事曆的那場演練才是真的會發生的那場。如果檢討暴露出來的缺口不是靠流程就能補上的，那正是「一份有優先順序的改善計畫比又一場演練更值錢」的那個時刻：聯絡我們。