安全事件回應的架構策略

適用於 Azure Well-Architected Framework 安全性檢查清單建議：

本指南說明針對工作負載實作安全事件回應的建議。 如果系統發生安全性危害，系統事件回應方法有助於減少識別、管理和緩解安全性事件所需的時間。 這些事件可能會威脅軟體系統和資料的機密性、完整性和可用性。

大多數企業都有中央安全運營團隊（也稱為安全運營中心 （SOC） 或 SecOps）。 安全性作業小組的職責是快速偵測潛在攻擊、排定優先順序和分級。 該團隊還監控與安全相關的遙測數據並調查安全漏洞。

不過，您也有責任保護您的工作負載。 請務必，任何通訊、調查和搜捕活動都是工作負載小組與 SecOps 小組之間的共同作業。

本指南為您和您的工作負載小組提供建議，以協助您快速偵測、分級和調查攻擊。

定義

您和您的團隊會在出現潛在入侵的訊號或警示時執行事件回應作業。 高保真警報包含充足的安全上下文，使分析師可以輕鬆做出決策。 高保真警示會導致少量誤判。 本指南假設警示系統會篩選低保真訊號，並著重於可能指出真實事件的高保真警示。

指定事件通知連絡人

安全性警示必須到達小組和組織中的適當人員。 在您的工作負載小組中建立指定的聯絡人，以接收事件通知。 這些通知應該包含盡可能多的有關遭入侵資源和系統的資訊。 警示必須包含後續步驟，以便您的團隊可以加快行動。

我們建議您使用保留稽核追蹤的專用工具來記錄和管理事件通知和動作。 透過使用標準工具，您可以保留潛在法律調查可能需要的證據。 尋找機會實施自動化，根據責任方的責任發送通知。 在事件發生期間保持清晰的溝通和報告鏈。

利用貴組織提供的安全資訊事件管理 （SIEM） 解決方案和安全協調流程自動回應 （SOAR） 解決方案。 或者，您可以採購事件管理工具，並鼓勵您的組織針對所有工作負載團隊標準化它們。

與分級小組一起調查

收到事件通知的團隊成員負責根據可用資料設定涉及適當人員的分級程序。 分流團隊（通常稱為 橋接團隊）必須就溝通模式和過程達成一致。 此事件是否需要非同步討論或橋接呼叫？ 團隊應該如何追蹤和傳達調查進度？ 小組可以在哪裡存取事件資產？

事件回應是保持文件最新的重要原因，例如系統的架構佈局、元件層級的資訊、隱私或安全分類、所有者和關鍵聯絡點。 如果資訊不準確或過時，橋樑團隊就會浪費寶貴的時間來嘗試了解系統的工作原理、每個區域的負責人以及事件可能產生的影響。

如需進一步調查，請讓適當的人員參與進來。 您可以包括事件經理、安全官員或以工作負載為中心的潛在客戶。 若要讓分類保持重點，請排除問題範圍之外的人員。 有時，不同的團隊會調查該事件。 可能有一個小組會一開始調查問題並嘗試減輕事件，而另一個專門小組可能會執行鑑識以進行深入調查，以確定廣泛的問題。 您可以隔離工作負載環境，讓鑑識團隊能夠進行調查。 在某些情況下，同一個團隊可能會處理整個調查。

在初始階段，分審團隊負責確定潛在的向量及其對系統的機密性、完整性和可用性（也稱為 CIA）的影響。

在 CIA 類別中，分配一個初始嚴重性級別，指示損害的深度和補救的緊迫性。 此層級預期會隨著時間而變更，因為在分類層級中探索到更多資訊。

在發現階段，確定立即行動方案和溝通計劃非常重要。 系統的運行狀態是否有任何變化？ 如何遏制攻擊以阻止進一步的利用？ 團隊是否需要發送內部或外部溝通，例如負責任的披露？ 考慮偵測和回應時間。 您可能有法律義務在特定時間段內（通常是數小時或數天）向監管機構報告某些類型的違規行為。

如果您決定關閉系統，後續步驟會導致工作負載的災難恢復 （DR） 程序。

如果您未關閉系統，請判斷如何在不影響系統功能的情況下補救事件。

從事件中復原

將安全事件視為災難。 如果補救需要完全復原，請從安全性的角度使用適當的 DR 機制。 恢復過程必須防止復發的機會。 否則，從損毀的備份復原會重新引發問題。 重新部署具有相同漏洞的系統會導致相同的事件。 驗證容錯移轉和容錯回復步驟和程序。

如果系統繼續運作，請評估對系統運行部分的影響。 繼續監控系統，以確保透過實施適當的降級流程來滿足或重新調整其他可靠性和效能目標。 不要因為緩解而損害隱私。

診斷是一個互動式過程，直到確定向量以及潛在的修復和後援。 診斷之後，小組會進行補救，在可接受的期間內識別並套用所需的修正程式。

復原指標會衡量修正問題所需的時間。 如果發生關閉，補救時間可能會很緊迫。 為了穩定系統，需要時間來套用修正程式、修補程式和測試，以及部署更新。 確定遏制策略，以防止進一步的損害和事件的蔓延。 制定根除程序以徹底消除環境中的威脅。

取捨：可靠性目標與補救時間之間有取捨。 在事件期間，您可能不符合其他非功能性或功能性需求。 例如，您可能需要在調查事件時停用系統的一部分，或者您甚至可能需要將整個系統離線，直到您判斷事件的範圍為止。 業務決策者需要明確決定事件期間可接受的目標是什麼。 明確指定對該決定負責的人。

從事件中學習

事件會發現設計或實作中的差距或弱點。 這是一個改進機會，由技術設計方面、自動化、包括測試在內的產品開發流程以及事件回應流程的有效性方面的經驗教訓所驅動。 維護詳細的事件記錄，包括採取的行動、時間表和調查結果。

我們強烈建議您進行結構化的事件後審查，例如根本原因分析和回顧。 追蹤這些檢閱的結果並排定其優先順序，並考慮在未來的工作負載設計中使用您學到的知識。

改善計劃應該包括安全性演練和測試的更新，例如商務持續性和災害復原 （BCDR） 演練。 使用安全性入侵作為執行 BCDR 演練的案例。 演練可以驗證記錄的流程如何運作。 不應該有多個事件回應教戰手冊。 使用單一來源，您可以根據事件的大小以及影響的廣泛程度或局部化程度進行調整。 演習基於假設的情況。 在低風險環境中進行演練，並將學習階段納入演練中。

進行事後審查或事後分析，以確定回應過程中的弱點和需要改進的領域。 根據您從事件中學到的經驗教訓，更新事件回應計劃 （IRP） 和安全性控制。

定義通訊計劃

實作通訊計劃，以通知使用者中斷，並通知內部利害關係人補救和改善。 組織中的其他人必須收到工作負載安全性基準的任何變更通知，以防止未來發生事件。

產生事件報告供內部使用，並在必要時用於法規遵循或法律目的。 此外，採用標準格式報告 （具有已定義區段的文件範本） ，SOC 小組會用於所有事件。 在關閉調查之前，請確定每個事件都有與其相關聯的報告。

Azure 支援服務

Microsoft Sentinel 是 SIEM 和 SOAR 解決方案。 它是警示偵測、威脅可見度、主動搜捕和威脅回應的單一解決方案。 如需詳細資訊，請參閱 什麼是 Microsoft Sentinel？

請確定 Azure 註冊入口網站包含系統管理員連絡資訊，以便透過內部程式直接通知安全性作業。 如需詳細資訊，請參閱 更新通知設定。

若要深入瞭解如何建立從適用於雲端的 Microsoft Defender 接收 Azure 事件通知的指定連絡點，請參閱 設定安全性警示的電子郵件通知。

組織一致性

適用於 Azure 的雲端採用架構提供事件回應規劃和安全性作業的指引。 如需詳細資訊，請參閱 安全作業。

相關連結

• 從 Microsoft 安全性警示自動建立事件
• 使用搜捕功能進行端對端威脅搜捕
• 設定安全性警示的電子郵件通知
• 事件回應概觀
• Microsoft Azure 事件整備程度
• 瀏覽和調查 Microsoft Sentinel 中的事件
• 安全控制：事件回應
• Microsoft Sentinel 中的 SOAR 解決方案
• 訓練：Azure 事件整備簡介
• 更新 Azure 入口網站通知設定
• 什麼是 SOC？
• 什麼是 Microsoft Sentinel？

安全檢查清單

請參閱一組完整的建議。