由于云計算的本質，所以當發生安全事件、數據破壞、或其他需要調查和采取行動該找誰時顯得更難以確定。為了滿足相同匯報責任的需求的變化，需要修改標準安全事件響應機制。

對于客戶來說，部署到云的應用程序并不總是把數據完整性和安全性設計放在第一位的。這可能導致脆弱的應用部署進云環境，進而引發安全事故。此外，基礎設施架構的缺陷、加固規程中的錯誤、以及簡單的操作疏忽都會對云服務的運營構成重大的威脅。當然，類似的漏洞同樣也會危及傳統的數據中心的運營。

很明顯，事件處理過程需要專業技術知識，但隱私和法律專家對云安全同樣可以作出重大貢獻。在事件響應中，他們還會在通知、補救、以及隨后可能采取的法律行動中發揮關鍵作用。如果一個組織考慮使用云服務，那么他需要審視有關未被用戶協議和隱私政策制約的員工對數據的訪問的機制是否已經實施。在IaaS和PaaS架構中，云服務提供商自己的應用程序不管理應用程序數據，這和SaaS提供商的應用程序控制數據有所不同。

大型云服務提供商交付SaaS、PaaS和IaaS服務的復雜性造成重大事件響應過程中的隱患，潛在客戶必須評估相應SLA的可接受水平。在評估云服務提供商時，很重要的一點事要意識到供應商可能托管了成百上千的應用程序實例。從事件監測的角度講，任何外部應用程序都會拓寬安全運行中心(SOC)的責任。通常，SOC監測那些由入侵檢測系統和防火墻中產生預警和其他事件的指標，但是，在開放的云環境中這些必須監測的消息來源和通告的數量將會以指數方式增長，例如，SOC可能需要監測消費者之間的活動，還有外部事件。

一個組織需要了解他們所選擇的云服務提供商的事件響應策略。這一策略必須解決識別和通知，以及針對應用程序數據的未經授權訪問的補救選項。更為復雜的是，在不同的數據存放位置，應用數據的管理和訪問有不同的含義和監管要求。例如，如果涉及到的數據在德國，有事件發生，可是如何數據在美國，可能就不認為是“事件”。這使得事件識別充滿挑戰性。

建議

• 在服務部署前，云客戶要明確界定，并且和云服務提供商溝通什么是他們認為的事故(incident)(如數據破壞)，什么僅僅是事件(event)。

• 云客戶參與云服務提供商的事件響應活動可能非常有限。因此，客戶了解與云服務提供商的事件響應小組的既定溝通路徑非常關鍵。

• 云客戶應該調查云服務提供商使用哪些事件檢測和分析工具，以確保他們對自己的系統兼容。在聯合調查，特別是那些涉及法律調查(discovery)或政府干預(intervention)時，云服務提供商的某個私有的或者非常規格式的日志往往會成為主要障礙。

• 設計和保護不當的應用程序和系統可以很容易地“淹沒”每個人的事件響應能力。對系統進行適當的風險管理，并且利用縱深防御的做法在第一時間減少發生安全事件的機會是很關鍵的。

• 安全運行中心(SOC)經常假定對事件響應上只有一個單一的管控模型，但是這對多租戶的云服務提供商來說并不恰當。一個強勁而良好維護的安全信息和事件管理(SIEM)流程用以識別可用數據源(應用程序日志、防火墻日志、以及IDS日志等等)，并且將這些日志合并進可以協助SOC檢測云計算環境事件的通用分析告警平臺。

• 為了極大地方便的進行詳盡的離線分析，可以考察能夠提供整個客戶虛擬環境快照的能力的云服務提供商，這些快照包括防火墻、網絡(交換機)、系統應用程序和數據。

• 遏制(containment)是破壞控制和搜集證據之間的一場賽跑。基于機密性-完整性-可用性(CIA)這樣三位一體的遏制做法才是有效的。

• 補救突出了能夠將系統恢復到某個先前狀態的重要性，甚至需要回到6個月或12個月前的已知可用配置。將法律選擇和要求牢記在心，補救可能還需要支持事件數據的“事后分析”(forensics)記錄。

• 所有因為數據泄漏監管而被分類為“私有”的數據都應該加密，以減少泄漏事件帶來的后果。客戶應在合同中規定相關的加密要求。

• 有些云服務提供商可能擁有一大批擁有獨特應用的客戶。為了能夠給每一個特定客戶提供細顆粒度的事件，這些云服務提供商應該考慮應用層日志框架。這些云服務提供商還應該構建一個注冊表，按照應用程序接口(URL、SOA服務、等)來記錄應用程序所有者。

• 在多租戶環境下，應用級防火墻、代理服務器，以及其它的應用日志工具是當前可用的協助事件響應的關鍵能力。