本篇內容來自於文獻：Secure your endpoints: "Building a Healthy Fleet"

表格 1. 攻擊類別和控制措施

一個健康的機群是由一堆健康的設備所組成。那麼如何評定設備是健康的呢？Google 認爲一個健康的設備符合以下特徵：

• 能夠抵禦大多數攻擊
• 能夠提供足夠的遙測數據，以便在發生攻擊時加以控制

接下來的章節，讓我們深入探討一個理想機群的各項控制措施為何如此重要，如表格 1. 的 "Control" 欄位。

機群庫存和資產管理 Fleet Inventory and Asset Management

未知的設備 (Unknown devices)：敏感系統被未知或未經管理的設備訪問。

硬體是 OS 和應用程序運行的基礎。限制用戶對硬體配置的更動，可以讓我們更有效率地瞭解機群內設備的能力和限制。一個設備庫存系統可以對能夠連接到敏感系統的設備數量設定上限。

OS 和軟體配置管理 OS and Software Configuration Management

平台妥協 (Platform compromise)：利用平台上操作系統或軟件的錯誤配置來進行攻擊。

軟體管理是維護健康機群的關鍵。一個集中式管理軟體的基礎架構應該確保配置一致性，讓機群內的 instance：

• 預設是安全的，且隨著時間的推移變化越來越小
• 受益於迭代改善的安全性

修補正在運行的操作系統或敏感軟體對於維護良好的安全性至關重要。同樣重要的是在一個集中的位置管理這些軟體配置（例如：軟體自動更新的 policy）。

強制執行的安全策略 Security Policy Enforcement

繞過安全控制 (Security control bypass)：通過未使用或錯誤配置的安全策略繞過系統，導致系統被攻陷。

可信賴的平台應該始終強制執行安全策略 (security policy)，並報告和記錄任何偏差。安全策略通常與上面提到的 OS 和軟體配置管理交織在一起。然而，安全策略是特殊的，因為它是一個強制執行的 Access Control Policy，用戶無法繞過它。

對抗系統遭接管和持續性的彈性 Resilience against System Takeover and Persistence

權限升級 (Privilege escalation)：代碼執行導致特權系統被接管並於系統中持續這個情況

這裡的目標在於分層防禦，以確保惡意軟體的攻擊不一定會威脅系統整體的安全性。要確保主機能夠在一些高級惡意軟體關閉主機的日誌子系統之前報告異常行爲。

軟體完整性和控制 Software Integrity and Control

軟體妥協 (Software compromise)： 安裝和持續運行惡意軟件

您應該要能夠限制未經授權的代碼在平臺上執行。常見的策略包含僅允許執行已知的良好軟體，並明確阻止可疑的惡意軟體。通常，我們更傾向於採用白名單策略（定義您工作需要的應用程序），因爲潛在的惡意軟件數不勝數。

遠程驗證平臺狀態 Remotely Verifiable Platform State

持續攻擊 (Attack persistence)：由於系統缺乏檢查，攻擊者長期持續攻擊

平臺應具備加密驗證完整性機制，可爲底下的平臺提供安全保障，包含韌體到 OS。例如，Intel 的 Boot Guard、安全開機狀態 (secure boot)，和遠程認證 (remote attestation)。

堅實的平臺和用戶驗證 Robust Authentication of Platform and User

繞過身份驗證 (Authentication bypass)：通過竊取密碼或繞過身份驗證來威脅系統的安全性

您應該盡可能地將憑證（比如密碼、密鑰等）存儲在系統的硬件層面 (hardware-backed)，或通過硬件隔離 (hardware-isolated) 的方式來增強安全性。Windows Defender Credential Guard 便是一個例子，它可以將憑證安全地保存在硬體中，以提高系統和用戶的身份驗證安全性。

數據保護 Data Protection

數據泄露 (Data compromise)：未經授權地訪問磁盤、內存或傳輸中的敏感數據

我們假定任何用戶的系統都有一些敏感數據；因此，敏感數據在靜態和動態時都應加密。為處理設備丟失或被盜問題，設備應支持遠程擦除，以銷毀系統中存儲的任何數據或長期憑證。

日誌 Logging and Log Collection for Detecting Threats

攻擊隱蔽性 (Attack concealment)：由於缺乏日志記錄和監控，攻擊者長期存在

為提供深度防禦，平台威脅模型應假定攻擊者會繞過防禦，機器會受到攻擊。為降低這種風險，平台應能記錄此類事件。日志記錄應該要包含用戶和設備對所有敏感數據訪問或修改的審計記錄，包括對平台安全控制、狀態和行為的更改。這些信息應流向集中式日志記錄設施。理想的日志可防止被未經授權的程序篡改。

檢測和響應 Response Capability on Platform / Detection and Response

攻擊否認 (Attack repudiation)：由於攻擊者有能力掩蓋蹤跡而妨礙調查

如果檢測到威脅，平台應該要能夠讓授權的入侵分析員進行遠程事件響應。像 GRR 這樣的工具可以提供遠程訪問，用於執行這種分析。我們更傾向將設備內部的取證工作降至最低，因為這種策略無法擴展以應對廣泛的安全漏洞。理想情況下，授權的分析員應該能夠創建一個經過法庭審查的事件時間線，並通過從受影響的系統進行一次性數據提取來著手調查。通過重新創建事件（攻擊），檢測和響應團隊可以獲得一個全面的事件（攻擊）發生情況，並采取相應的措施。

好的這就是今天的內容~~
讀到 OS config management 就讓我想到了 Google Cloud 的 VM Manager, 他可以做 Patch, OS policies, and OS inventory management。架構圖如下：

圖 1. Google Cloud VM Manager architecture

不過看了一下 VM Manager 的收費方式是 hourly cost per agent, 還是不要實驗比較好哈哈。有點費錢。

Anyway, 明天見！