tenable發佈了一篇利用您的內部日誌進行更好的異常檢測和事件回應
本文介紹了Tenable Cloud Security如何通過豐富雲端活動日誌數據，為用戶提供快速響應和修復雲端風險所需的上下文。文章指出，傳統的安全方法在雲端環境中存在數據收集和分析的挑戰，並展示了Tenable Cloud Security如何幫助用戶解決這些挑戰，提高雲端安全姿態管理（CSPM）的效率和效果。
一個組織發現，它的雲端成本在短時間內急劇上升，卻沒有明顯的原因。因此，該公司開始懷疑是否遭到了入侵。安全調查發現，DevOps團隊不小心在公共IP上創建了一個過度授權的Amazon Machine Image (AMI)。這些權限是作為DevOps團隊的模板的一部分，因此每次新的AMI被啟動時，它都會創建一個過度授權和易受攻擊的實例。通過訪問服務器，攻擊者可以利用過度的權限來運行加密挖礦程序，從免費的計算服務中獲益，而被攻擊的實體則要為昂貴的計算利用付出代價。
為什麼這次入侵沒有被及時發現呢？傳統的安全方法失敗了，因為機器日誌本身並不能顯示這種錯誤配置。只有更深入的調查才能以一種被動的方式識別和控制這個問題。這裡存在幾個挑戰：
日誌數據的缺失 在傳統的本地基礎設施中，由組織直接擁有和控制，豐富的日誌數據幾乎就在您的指尖。在雲端，基礎設施是由雲服務提供商（CSP）擁有的。事件響應團隊調查攻擊的能力因此取決於CSP收集的數據。這一點更加具有挑戰性，因為每個CSP都有自己的默認設置和數據收集的細微差別，這不僅會影響收集的數據，還會影響訪問數據的成本和數據保留的時間。如果事件響應團隊缺乏對每個CSP的默認設置的細節和數據捕獲和保留策略的獨特差異的了解，他們可能會在數據中留下嚴重的缺口，阻礙調查和修復工作。
日誌數據的複雜性 即使收集了所有必要的數據，事件響應團隊也需要能夠理解和分析這些數據，以找出潛在的風險和異常。然而，這些數據通常是非常複雜和雜亂的，需要專業的雲端知識和工具來解讀。例如，AWS CloudTrail日誌記錄了AWS賬戶的API活動，包括誰、什麼、何時、從哪裡和如何進行的操作。這些日誌可以提供寶貴的信息，但也可能包含大量的噪音和冗餘，使得事件響應團隊難以快速找到關鍵的信息。
日誌數據的不足 即使事件響應團隊能夠收集和分析日誌數據，這些數據本身也可能不足以提供完整的事件響應所需的上下文。例如，日誌數據可能顯示一個用戶在一個特定的時間和地點訪問了一個特定的資源，但這並不能告訴您這個用戶是否有權訪問這個資源，或者這個資源是否存在漏洞或其他風險。為了獲得更全面的視角，事件響應團隊需要將日誌數據與其他數據源相關聯，例如身份和訪問管理（IAM）數據、漏洞數據和網絡配置數據。
日誌數據的時效性 最後，事件響應團隊需要能夠及時收集和分析日誌數據，以減少攻擊者的居住時間和數據泄露的影響。然而，這可能受到數據收集和分析工具的性能和可用性的限制。例如，如果事件響應團隊使用的工具不能及時處理大量的日誌數據，或者在關鍵時刻出現故障，那麼他們可能會錯過一些重要的信息，或者無法及時採取行動。
為了解決這些挑戰，事件響應團隊需要一種能夠幫助他們利用日誌數據的工具，同時提供更多的上下文和指導。
詳情請看：
Tap Into Your Inner Logs for Better Anomaly Detection and Incident Response