有一題練習題是這樣的：事件處理完，要寫 after-action report，管理層想把這次暴露出來的流程問題修正掉，問該做哪一件事。
我選了 RCA，正解是 lessons learned。

這兩個詞的定義我其實都背得出來，單獨問 RCA 是甚麼、lessons learned 是甚麼，我都答得對。
但題目換成一個情境，要我自己對號入座，就開始亂了。
同一塊還有 playbook 跟 IR plan、BIA 跟 DRP，也是一樣的狀況，所以這篇就把這幾份文件放在一起講。

RCA 往回找，lessons learned 往前改

RCA（Root Cause Analysis，根因分析） 在回答的是「這次到底是怎麼發生的」。
它往回看，一路追到技術上的那個根源：哪個洞、哪個設定、攻擊者從哪裡進來、怎麼一步一步走到這裡。

寫 RCA 的順序大致是先確認發生了甚麼事，再把時間軸建起來，然後把「現象」跟「造成現象的原因」分開，最後記錄下來。
這邊有個小地方，時間軸不是第一步，要先確認問題本身是甚麼，才知道時間軸要從哪裡拉。

Lessons learned（事後檢討） 在回答的是「我們這次處理得怎麼樣，下次怎麼做更好」。
它看的不是攻擊者，是自己：告警有沒有人看到、通報有沒有卡住、該找的人找不找得到、哪一步花太多時間。
然後給建議、改流程。

Day21 講到最後一站「事後檢討」，lessons learned 就是這一站在做的事。

所以回頭看開頭那題，關鍵字是「修正流程問題」。
RCA 會告訴你洞在哪裡，但它不負責回答流程哪裡爛掉。
另一題問 RCA 的目的是甚麼，我也錯了，正解是找出造成事件的根因，「提出改善流程的建議」是 lessons learned 的工作。

拿同一件事寫兩次看看

光講定義還是很抽象，我直接捏一個事件，分別用兩種角度寫一段，以下情境是我自己編的（虛構）。

某間公司的備份伺服器在週六凌晨被入侵，攻擊者把備份檔刪掉，接著內網幾台主機被加密。

寫成 RCA 大概會長這樣：

攻擊者先透過一封釣魚信拿到一台使用者電腦的控制權。
這台電腦跟備份伺服器的管理介面在同一個網段，彼此連得到。
備份軟體有一個已經公開、原廠也出了修補的漏洞，這台沒有補。
攻擊者利用這個漏洞登入備份伺服器，橫向移動摸透整個架構後，把storage全加密了，備份也不例外。

寫成 lessons learned 大概會長這樣：

備份伺服器不在每月 patch 的清單裡，原因是資產清單上沒有它。
週六凌晨 SIEM 其實有跳告警，但假日沒有人值班看。
出事後要找備份軟體的原廠支援，翻了半小時找不到合約跟窗口。
大家各自處理，沒有一份「備份被刪」的處置步驟可以照著走。
建議：資產清單重新盤點、假日告警要有人接、IR plan 補上廠商聯絡資訊、新增一份對應的 playbook。

兩段放在一起看，RCA 裡面出現的是網段、漏洞、釣魚信，是技術。
lessons learned 裡面出現的是清單、值班、窗口、步驟，是人跟流程。
備份管理介面不要跟一般使用者放同一個網段，這件事 Day15 也有提到過，RCA 找到的就是這種東西。

檢討完，要改的是誰?

lessons learned 寫完之後，那些建議要落到哪裡?
大部分會回到 IR plan 跟 playbook 上，把這次沒寫到、寫錯的地方補起來。

還有一題問演練做完之後，要用哪一份文件當改進的依據，我也錯了，正解是 lessons-learned register，也就是把每次檢討出來的強項、弱點逐條登記的那份紀錄。
IR plan 在這裡是被改的那份，不是拿來改別人的那份。

這也讓我想到 Day16 最後講的，寫下來做紀錄是好習慣。
lessons learned 如果只在會議上講講沒有寫下來，下一次出事沒意外的話就要出意外了，大家又不知道該怎麼辦了。

Playbook 跟 IR plan，一個是全局，一個是單一劇本

playbook 是甚麼 Day11 講過了，它是一份寫好的流程，碰到某種事第一步做甚麼、第二步做甚麼。
這裡要分的是它跟 IR plan 的差別。

IR plan（Incident Response Plan） 是整體的框架。
IR team 有誰、每個人的角色、事件怎麼分級、甚麼情況要往上報、要通知哪些人、對外由誰發言。
它不會告訴你勒索軟體的第一步要做甚麼，它告訴你的是整個應變的組織跟規則。

Playbook 是針對特定一種事件的逐步操作。
勒索軟體一份、釣魚信一份、帳號被盜一份，每一份都是拿起來就能照著走的步驟。

有一題是一張勒索軟體的 ticket 進來，要做 triage（初步分類與處置），問該照哪一份文件做。
正解是 playbook，這題我一樣兩輪都錯。
回頭看，題目講的是一種特定事件而且要動手處理，這時候該拿起來的是那份劇本，不是整本規則。

以我目前的工作情境來想的話，IR plan 比較像是一份「出事時誰負責、要打給誰」的總表，playbook 比較像是「換一顆故障硬碟」那種一步一步的SOP。

在出事之前：BIA、BCP、DRP

上面幾份都跟事件有關，這三份是平時就要準備好，為了「萬一整個停掉」在寫的。

BIA（Business Impact Analysis，營運衝擊分析） 是先評估：哪些業務停下來影響最大、可以停多久、可以掉多少資料。
這裡會定出兩個數字：

• RTO（Recovery Time Objective）：可以容忍停機多久，服務要在這個時間內回來。
• RPO（Recovery Point Objective）：可以容忍掉多少資料，往回推到哪一個備份點還可以接受。

RPO 跟我工作上碰的備份很有關係，如果 RPO 定一小時，那備份排程至少就得每小時跑一次，但非特殊行業應該很難做到這麼高頻率的備份，畢竟跑備份的時候還是有可能會影響效能的。

BCP（Business Continuity Plan，營運持續計畫） 是讓業務繼續下去，就算系統還沒回來，生意要怎麼繼續做，可能是先改人工作業、換一個地方辦公，舉個案例就是庫存管理系統停擺，改手動紀錄，生意照樣可以做。
DRP（Disaster Recovery Plan，災難復原計畫） 是讓系統回來，照 BIA 定好的 RTO、RPO，把服務還原、切到備援站點。
我的理解是 DRP 算是 BCP 底下的其中一塊，一個顧業務，一個顧系統。

這邊我錯的是一題問 RTO、RPO 是由哪一份文件決定的，正解是 BIA。
DRP 是照著這兩個數字去執行的那一份，數字本身是 BIA 那一步談出來的。
所以順序是先 BIA，知道甚麼最重要、能停多久，BCP 跟 DRP 才知道要往哪個方向寫。

整理一下

大家可以想一下，有沒有看過自己公司的IR plan，自己在裡面又扮演甚麼腳色呢?