本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 事後處理
<a name="post-incident-activity"></a>

 威脅態勢不斷變化，因此組織有效保護環境的能力也務必同樣保持動態。持續改進的關鍵是反覆查看事件和模擬的結果，以改善您有效偵測、回應和調查可能安全事件的能力、減少可能的漏洞、回應時間，以及返回安全操作。下列機制可協助您驗證組織是否具備最新功能和知識，以便在任何情況下有效回應。

# 建立從事件中學習的架構
<a name="establish-framework-for-learning"></a>

 實作*經驗教*訓的架構和方法不僅有助於改善事件回應功能，也有助於防止事件重複發生。透過從每個事件中學習，您可以協助避免重複相同的錯誤、暴露或錯誤設定，不僅可以改善您的安全狀態，還可以將因可預防的情況而損失的時間降至最低。

 實作經驗教訓是非常重要的，其可在高層級實現以下幾點：
+  什麼時候開設經驗教訓課程？ 
+  經驗教訓課程中包含哪些內容？ 
+  經驗教訓課程的進行方式？ 
+  這個課程的參與者以及參與方式？ 
+  如何識別待改善之處？ 
+  如何確保有效追蹤和實作改善項目？ 

 除了列出的這些高階成果之外，請務必提出正確的問題，從程序中衍生出最高價值 （導致可行改善的資訊）。考慮這些問題，有助您發起經驗教訓的討論：
+  事件是什麼？ 
+  第一次識別事件的時間？ 
+  事件的識別方式？ 
+  哪些系統對活動發出提醒？ 
+  涉及哪些系統、服務和資料？ 
+  具體發生的事件？ 
+  哪些方面做得很好？ 
+  哪些方面做得不好？ 
+  哪個流程或程序失敗或未能擴展以回應事件？ 
+  在以下幾個領域有哪些可以改善之處：
  +  **人物** 
    +  需要聯絡的對象實際上是否有空，並且聯絡人清單是最新的嗎？ 
    +  人們是否缺少有效回應和調查事件所需的培訓或能力？ 
    +  適當的資源是否已準備就緒且可供使用？ 
  +  **流程** 
    +  是否遵循流程和程序？ 
    +  是否已記錄並提供這類事件的流程和程序？ 
    +  是否缺少必要的流程和程序？ 
    +  回應人員是否能夠即時存取所需的資訊以回應問題？ 
  +  **技術** 
    +  現有的提醒系統是否能有效地識別活動，並據以發出提醒？ 
    +  是否需要改善現有提醒，或是需要針對此類事件建立新的提醒？ 
    +  現有的工具是否允許對事件進行有效的調查 （搜尋/分析）？ 
+  可以做什麼來協助加快這類事件的識別速度？ 
+  可以做什麼來協助避免這類事件再次發生？ 
+  負責改善計畫的人是誰，您將如何測試是否已實作此計畫？ 
+  要實作和測試之額外監控/預防性控制/程序的時間表為何？ 

 此清單並非全包式，旨在作為識別組織和業務需求的起點，以及如何分析這些需求，以最有效地從事件中學習並持續改善您的安全狀態。最重要的是透過將經驗教訓納入事件回應流程，文件和利害關係人期望的標準部分。

# 建立成功的指標
<a name="establish-metrics-for-success"></a>

 指標是有效衡量、評估和改善事件回應功能的必要指標。如果沒有指標，則沒有參考可準確測量或甚至識別您的組織效能 （或未）。對於尋求建立期望和參考以實現卓越營運的組織而言，事件回應中有一些常見的指標是很好的起點。

# 平均偵測時間
<a name="mean-time-to-detect"></a>

 *平均偵測時間*是發現潛在安全事件所需的平均時間。具體而言，這是從第一個入侵指標出現到初始識別或提醒之間的時間。

 您可以使用此指標來追蹤偵測和警示系統的效能。有效的偵測和提醒機制是驗證可能的安全事件不會停留在您的環境中的關鍵。

 平均偵測時間愈長，就愈需要建立額外或更有效的提醒和機制，以識別和探索可能的安全事件。平均偵測時間越短，偵測和提醒機制的運作就越好。

# 確認的平均時間
<a name="mean-time-to-acknowledge"></a>

 *確認的平均時間*是確認潛在安全事件並排定優先順序所需的平均時間。具體而言，這是產生警示與 SOC 成員或事件回應人員識別並排定警示優先順序以進行處理之間的時間。

 您可以使用此指標來追蹤您的團隊處理和排定警示優先順序的程度。如果您的團隊無法有效識別警示並排定優先順序，則回應將會延遲且無效。

 確認的平均時間越高，就越需要驗證您的團隊是否獲得適當的資源和訓練，以快速確認可能的回應安全事件並排定其優先順序。確認的平均時間越短，您的團隊就越能回應安全提醒，表示他們已做好充分準備，並能夠妥善排定優先順序。

# 平均回應時間
<a name="mean-time-to-respond"></a>

 平均回應時間是開始對潛在安全事件的初始回應所需的平均時間。具體而言，這是從潛在安全事件的初始提醒或探索到採取第一個回應動作之間的時間。這類似於平均確認時間，但與簡單辨識或確認情況相比，這是特定回應動作的測量 （例如，取得系統資料、包含系統）。

 您可以使用此指標來追蹤您的準備程度，以回應安全事件。如前所述，準備是有效回應的關鍵。請參閱本文件的 [準備](preparation.md)一節。

 回應的平均時間愈長，就愈需要驗證您的團隊都已正確訓練如何回應，以便有效記錄和使用回應程序。回應的平均時間越短，您的團隊就越能識別已識別警示的適當回應，並執行必要的回應動作，以開始返回安全操作的旅程。

# 包含的平均時間
<a name="mean-time-to-contain"></a>

 *平均遏制時間*是遏制潛在安全事件所需的平均時間。具體而言，這是從潛在安全事件的初始提醒或發現到有效防止攻擊者或遭入侵系統進一步傷害的回應動作完成之間的時間。

 您可以使用此指標來追蹤您的團隊緩解或遏制可能安全事件的能力。無法快速有效地遏制可能的安全事件會增加可能進一步入侵的影響、範圍和暴露。

 平均遏制時間越高，建置知識和功能的需求就越高，以快速有效地緩解和遏制您遇到的安全事件。控制的平均時間越短，您的團隊就越能理解和採用必要的措施來緩解和控制已識別的威脅，以減少對業務的影響、範圍和風險。

# 復原的平均時間
<a name="mean-time-to-recover"></a>

 *復原的平均時間*是完全傳回來自可能安全事件之安全操作所需的平均時間。具體而言，這是從潛在安全事件的初始提醒或探索到業務恢復正常運作和安全，而不受事件影響之間的時間。

 您可以使用此指標來追蹤您的團隊在安全事件發生後，將系統、帳戶和環境送回安全操作的有效性。無法快速或有效地恢復安全操作不僅會影響安全性，還可能增加對業務及其操作的影響和費用。

 復原的平均時間愈長，您的團隊和環境就愈需要準備適當的機制 （例如，容錯移轉程序和 CI/CD 管道，以安全地重新部署乾淨系統），將安全事件對營運和業務的影響降到最低。復原的平均時間越短，您的團隊就越能有效地將安全事件對營運和業務的影響降到最低。

# 攻擊者停留時間
<a name="attacker-dwell-time"></a>

 *攻擊者停留時間*是未經授權的使用者可存取系統或環境的平均時間。這類似於平均遏制時間，但時間範圍從攻擊者取得系統或環境存取權的初始時間開始，可能早於初始提醒或探索。

 您可以使用此指標來追蹤有多少系統和機制一起運作，以減少攻擊者或威脅影響您環境的時間、存取和機會。減少攻擊者停留時間應該是您的團隊和業務的首要任務。

 攻擊者停留時間越高，就越需要識別事件回應程序的哪些部分需要改進，以確保您的團隊能夠最大限度地減少環境中威脅或攻擊的影響和範圍。攻擊者停留時間越短，您的團隊就越能將威脅或攻擊者在環境中擁有的時間和機會降到最低，最終降低營運和業務的風險和影響。

# 指標摘要
<a name="metrics-summary"></a>

 建立和追蹤事件回應的指標可讓您有效地測量、評估和改善事件回應功能。為了達成此目的，本節中已反白顯示許多常見的事件回應指標。表 5 摘要說明這些指標。

* 表 5 – 事件回應指標*


|  指標  |  Description  | 
| --- | --- | 
|  平均偵測時間  |  探索潛在安全事件所需的平均時間  | 
|  確認的平均時間  |  確認 （和排定優先順序） 可能的安全事件所需的平均時間  | 
|  平均回應時間  |  開始對潛在安全事件的初始回應所需的平均時間  | 
|  包含的平均時間  |  包含可能安全事件所需的平均時間  | 
|  復原的平均時間  |  完全傳回來自可能安全事件的安全操作所需的平均時間  | 
|  攻擊者停留時間  |  攻擊者可以存取系統或環境的平均時間  | 

# 使用入侵指標 (IOCs)
<a name="use-indicators-of-compromise"></a>

 *入侵指標* (IOC) 是在網路、系統或環境中觀察到的成品，可以 （具有高度可信度） 識別惡意活動或安全事件。IOCs可以以各種形式存在，包括 IP 地址、網域、網路層級成品，例如 TCP 旗標或承載、系統或主機層級成品，例如可執行檔、檔案名稱和雜湊、日誌檔案項目或登錄項目等。它們也可以是項目或活動的組合，例如在系統上存在特定項目或成品 （特定檔案或一組檔案和登錄項目）、以特定順序執行的動作 （從特定 IP 登入系統，後面接著特定異常命令），或網路活動 （進出特定網域的異常傳入或傳出流量），這些動作可能指出特定威脅、攻擊或攻擊者方法。

 當您努力反覆改善事件回應計畫時，您應該實作架構來收集、管理和利用 IOCs做為機制，以持續建置和改善偵測和提醒，並改善調查的速度和有效性。您可以從將 IOCs 的收集和管理納入事件回應程序的分析和調查階段開始。透過主動識別、收集和儲存 IOCs 作為程序的標準部分，您可以建置資料儲存庫 （做為更全面的威脅情報計劃的一部分），進而用於改善現有的偵測和警示、建立額外的偵測和警示、識別之前看到成品的位置和時間、建置和參考文件，以了解先前如何進行涉及相符 IOCs調查等。

# 持續教育和訓練
<a name="continuous-education-and-training"></a>

 教育和訓練是不斷發展和持續的工作，應刻意追求和維護。有多種機制可以驗證您的團隊是否保持與不斷發展的技術狀態以及威脅態勢相稱的意識、知識和能力。

 其中一種機制是採用持續教育作為團隊目標和營運的標準部分。如準備一節所述，您的事件回應人員和利益相關者必須接受有效訓練，以偵測、回應和調查其中的事件 AWS。不過，教育不是「一次完成」的工作。必須持續進行教育，以確認您的團隊持續了解最新的技術進展、更新和改進，以改善回應的有效性和效率，以及新增或更新可用於改善調查和分析的資料。

 另一個機制是驗證模擬是否定期執行 （例如每季），並專注於業務的特定成果。請參閱本文件的 [執行定期模擬](run-regular-simulations.md)一節。

 雖然執行初始桌面練習是產生初始基準以進行改善的好方法，但持續測試是持續改進和維護最新up-to-date且準確反映目前操作狀態的關鍵。針對最新和最關鍵的安全情況以及最重要的或最新的回應功能進行測試，並將學到的經驗納入教育、操作和程序/程序，將驗證您是否能夠持續改善整體的回應程序和程式。