安全性事件回應的建議
適用於 Azure 架構完善的架構安全性檢查清單建議：
| SE：12 | 定義及測試涵蓋各種事件的有效事件回應程式，從當地語系化問題到災害復原。 清楚定義哪個小組或個別執行程式。 |
|---|
本指南說明針對工作負載實作安全性事件回應的建議。 如果系統的安全性危害，系統事件回應方法有助於減少識別、管理及減輕安全性事件所需的時間。 這些事件可能會威脅軟體系統和數據的機密性、完整性和可用性。
大部分企業都有一個中央安全性作業小組（也稱為資訊安全作業中心（SOC），或 SecOps。 安全性作業小組的責任是快速偵測、排定優先順序和分級潛在的攻擊。 小組也會監視安全性相關的遙測數據，並調查安全性缺口。
不過，您也有責任保護您的工作負載。 重要的是，任何通訊、調查和搜捕活動都是工作負載小組與 SecOps 小組之間的共同作業。
本指南提供建議給您和工作負載小組，協助您快速偵測、分級和調查攻擊。
定義
| 詞彙 | 定義 |
|---|---|
| Alert | 包含事件相關信息的通知。 |
| 警示精確度 | 決定警示之數據的精確度。 高逼真度警示包含立即採取動作所需的安全性內容。 低逼真度警示缺少資訊或包含雜訊。 |
| 誤判為真 | 指出未發生事件的警示。 |
| Incident | 表示未經授權存取系統的事件。 |
| 事件回應 | 偵測、回應及降低與事件相關聯之風險的程式。 |
| 分級 | 分析安全性問題並排定風險降低優先順序的事件回應作業。 |
關鍵設計策略
當有潛在入侵訊號或警示時，您和您的小組會執行事件響應作業。 高逼真度警示包含豐富的安全性內容，可讓分析師輕鬆做出決策。 高逼真度警示會導致誤判為低。 本指南假設警示系統會篩選低逼真度訊號，並著重於可能表示真實事件的高逼真度警示。
指定事件通知連絡人
安全性警示必須連絡小組和組織中的適當人員。 在您的工作負載小組上建立指定的連絡點，以接收事件通知。 這些通知應盡可能包含有關遭入侵資源與系統的資訊。 警示必須包含後續步驟，讓您的小組可以加速動作。
建議您使用特殊的工具來記錄和管理事件通知和動作，以保留稽核記錄。 藉由使用標準工具，您可以保留潛在法律調查可能需要的證據。 尋找實作自動化的機會，以根據責任方的責任傳送通知。 在事件期間保持清楚的通訊和報告鏈結。
利用組織提供的安全性資訊事件管理 （SIEM） 解決方案和安全性協調流程自動化回應 （SOAR） 解決方案。 或者，您可以採購事件管理工具，並鼓勵組織為所有工作負載小組標準化事件管理工具。
使用分級小組調查
接收事件通知的小組成員負責根據可用數據設定涉及適當人員的分級程式。 分級小組，通常稱為 橋牌團隊，必須同意溝通的模式和過程。 此事件是否需要異步討論或網橋呼叫？ 小組應如何追蹤和溝通調查進度？ 小組可以在哪裡存取事件資產？
事件回應是讓檔保持最新狀態的重要原因，例如系統的架構配置、元件層級的信息、隱私權或安全性分類、擁有者和聯繫人重點。 如果資訊不正確或過時，網橋小組會浪費寶貴的時間嘗試了解系統的運作方式、負責每個區域的人員，以及事件的影響。
如需進一步調查，請涉及適當的人員。 您可能會包含事件管理員、安全性人員或以工作負載為中心的潛在客戶。 若要讓分級保持焦點，請排除超出問題範圍的人員。 有時候，個別小組會調查事件。 可能有一個小組一開始調查問題，並嘗試減輕事件，而另一個專門小組可能會執行鑑識，以便深入調查以查明廣泛的問題。 您可以隔離工作負載環境，讓鑑識小組能夠進行調查。 在某些情況下，同一個小組可能會處理整個調查。
在初始階段，分級小組負責判斷系統的潛在向量及其對機密性、完整性和可用性的影響（也稱為 中情局）。
在 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 是什麼？
安全性檢查清單
請參閱一組完整的建議。