安全性事件回應的建議

  • 發行項

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

SE：12 定義及測試涵蓋各種事件的有效事件回應程式，從當地語系化問題到災害復原。 清楚定義哪些小組或個別執行程式。

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

大部分的企業都有中央安全性作業小組 (也稱為資訊安全作業中心 (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 的雲端採用架構提供事件回應規劃和安全性作業的相關指引。 如需詳細資訊，請參閱 安全性作業。

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單