接下來，這個系列我們跟著英國的專家，探討一下SOC，看看SOC的發展趨勢，當然我們還是秉承一貫的聲明，這些內容是為了大家能夠多一個參考，在開展工作中，一定有因地制宜，切實履行我國的法律法規，履行法定義務，做到合規和安全。

因此，如果在英國正在實施一個大型數字項目，并在項目的每個階段都遵循GOV.UK 服務手冊。

您現在已準備好上線，但項目的認證機構需要知道該服務是否具有“保護性監控”。這意味著團隊需要花費時間和精力來采購（或建立）安全運營中心（SOC）。

或者確實如此？

構建 SOC 是一項需要投入大量時間和金錢的任務。本博客探討組織是否有可能以不需要“全脂”SOC 的方式設計系統。

SOC 如何工作？

SOC 通常由與操作人員不同的團隊來運行。這有助于區分管理數字服務的人員和監控安全日志的人員之間的職責。

SOC 本身通常有專門的工具，最常見的是 SIEM（安全信息和事件管理）工具。它以日志和數據源作為輸入，執行一些關聯和規則檢查，然后輸出警報以進行分類。SOC 工具的許可可能很昂貴，通常以企業為中心的解決方案往往成本最高（并且通常需要每年續訂）。

SOC 團隊通常包括：

• 安全分析師對事件和警報進行分類
• 安全工程師管理工具（以及將項目引入 SOC）
• 某種形式的管理和行政職能

并且在某些情況下

• 威脅情報功能

遇到安全事件，沒有日志來幫助弄清楚發生了什么，并且必須向高層報告，這是一個糟糕的情況。在某些情況下，出于法律和取證目的可能需要日志，因此證明其處理和完整性的監管鏈非常重要。

根據 SIEM 工具，有些工具提供日志的加密完整性和驗證，以確定日志是否已被篡改。SOC 通常是確保日志的一個很好的策略：

• 安全收集
• 經授權的個人可以訪問
• 根據組織政策
• 不是簡單地收集以備不時之需（或被遺忘）

然而，設置自己的 SOC 可能既昂貴又耗時，因此一種選擇是外包 SOC。然而，外部 SOC 分析師可能缺乏（例如）項目架構的知識，并且可能無法像內部 SOC 那樣及時響應警報。

GPG13：房間里的大象

NCSC 的前身 CESG 發布了有關保護性監測的“良好實踐指南”(GPG)。被稱為 GPG13，負責處理風險的人員經常在服務上線之前使用 GPG13 作為要求。在某些情況下，這將保護性監控變成了一項復選框練習，SOC 工具的營銷材料將其產品描述為“符合 GPG13”。

隨著應用程序和服務的架構和技術堆棧開始多樣化，這個問題變得更加嚴重，因為服務所有者沒有動力去識別和監控未記錄在 GPG13 中的風險。

GPG13 在 NCSC 成立之前已被棄用。然而，我們仍然讓客戶在他們的保證過程中引用 GPG13，并且偶爾會被問到何時發布更換指南。為了區分“GPG13 保護性監控方法”和 NCSC 當前的方法，我將使用術語“安全監控”來描述使用云原生服務構建的服務所考慮的方法。

云如何改變一切？

英國政府于 2013 年推出了“云優先”政策，目標是讓政府部門在考慮傳統的本地部署之前考慮云優先解決方案。

那么，向云的轉變如何調整我們的安全要求呢？對于從本地基礎設施直接遷移到托管 IaaS 的部署，這并不會減少對 SOC 的需求，因為沒有固有的共享責任模型來減少運營責任。通過遵循和實施NCSC 的云安全指南，組織可以越來越多地轉向云提供商提供的監控工具（而不是依賴 SIEM、SOC 或專業安全人員）。

SOC 的一個關鍵優勢是能夠識別特定于環境的風險并發出警報。此要求不會隨著安全監控而消失，識別和監控任何自定義警報仍然很重要。

什么，沒有 SOC？

那么，什么樣的方法已經被用作全脂 SOC 的替代方案呢？以下是目前正在采用的一些政府項目：

• 完全云原生架構僅使用“云原生”服務的已部署服務，利用圍繞服務使用進行嚴格身份管理的優勢，并且沒有傳統上部署在虛擬機上的部署、修補和故障排除服務的運營開銷。
• 零接觸生產部署的服務，工程師永遠無法直接訪問生產服務（除了嚴格監控和審核的打破玻璃解決方案之外）。這降低了系統風險并減少了安全監控用例。
• 環境分離對應保持隔離的功能使用單獨的云帳戶。例如，存儲安全監控日志和不應訪問的服務（即使在玻璃破碎事件期間）的帳戶托管在單獨的云帳戶中，并具有嚴格的訪問控制和警報。
• 簡化日志收集云原生服務提供自己的日志（以及整合和分析日志的服務）。隨著安全監控要求的簡化，事件的記錄也被簡化。日志現在采用一致的格式，并且可以收集并存儲在云端。一些云提供商提供了解決日志完整性的選項，例如存儲可用于驗證日志完整性的校驗和，并且在審核期間可能有用。
• 取代已經擁有中央 SOC 的 SIEM政府部門發現入門服務是一項耗時的任務。通過保持架構簡單，一些人已經能夠通過擴展其云原生日志記錄解決方案以及將規則和警報直接構建到平臺中來取代 SIEM 的要求。安全開發實踐意味著運營團隊對安全負有責任，因此不需要安全團隊。事件管理至關重要，了解該做什么以及他們的責任也很重要。
• 打破玻璃有時需要直接生產訪問。這可能是由于操作需要（例如調查性能下降），也可能是安全事件的一部分的要求。在某些項目中，運營團隊負責調查和運行事件，這是通過記錄良好的流程和程序、良好的訪問和變更控制以及嚴格的系統審核來實現的。訪問是有時間限制的，所有事件都由團隊中的其他人審核和監控。
• 驗證日志記錄如果日志記錄停止工作并且沒有人注意到，那么所有這一切都將毫無用處。如果在時間窗口內未觀察到令牌，則可以向服務注入金絲雀令牌并發出警報/錯誤。

最后的想法

在官方構建服務的地方，“云優先”應該是重點，這應該包括上述所有強調的領域，以幫助加強和簡化安全監控要求。

對于 AWS（例如），您擁有嚴格控制的云原生服務，例如 GuardDuty、Security Hub、CloudTrail、CloudWatch。因此，您無需部署 SIEM，而是讓運營團隊擁有監控權，在設計簡單且安全的環境中工作。通過賦予運營團隊更多的服務所有權，我們會發現安全監控變得可以重復使用，就像現在部署基礎設施時發生的情況一樣。

在評估項目是否需要 SOC 時，您應該考慮依賴 SOC 的功能以及這些功能是否以其他方式涵蓋：

• 如果事件發生，您是否需要日志來調查事件？云原生服務（如果配置正確）可以做到這一點，您將需要考慮日志保留以及可以訪問或刪除日志的角色。
• 是否需要在攻擊發生時進行檢測？云原生/無服務器架構在可能的攻擊性質方面將受到更多限制，因為組件通常是單一目的，需要處理底層基礎設施。通過評估您的架構中可能存在的攻擊類型，您可以設置特定的警報。
• 是否有管理事件的要求？與上述一樣，在無服務器環境中警報的性質會有所不同，并且該服務的運營團隊可能比一般 SOC 分析師更能夠識別可疑行為。然后，重要的一步是確保運營團隊知道如何升級懷疑并測試該流程。

NCSC 認為，基于 SOC 和保護性監控的系統在安全工具箱中仍然占有一席之地。對于某些企業IT系統（例如端點）和基于傳統IaaS的架構（以及比官方分類更高的系統），仍然需要提供系統的反應性監控。集中式 SOC 也有好處，政府部門可以識別更廣泛的攻擊，這些攻擊正在探測組織使用的多種服務。

David S，高級安全架構師

后記：所謂師夷長技以制夷，在思想解放的情況下，要充分發揮“拿來主義”，同時也要根據自己的需要修剪成自己所需要的樣子。