Incident Response, the Cloud and the CSA Control Objectives

As an information security officer, you don’t want to wait until you’re in the middle of a serious security breach to discover that the forensics, incident reporting and incident responses processes of a cloud service provider (CSP) you’re depending on aren’t what was expected. Incident response is a difficult topic in cloud computing. Between the customer and the CSP, and between the CSP and other CSPs in its supply chain, lie many different interests and trust boundaries. 

I’m in the process of reviewing the new Cloud Security Alliance (CSA) Cloud Control Matrix (CCM) duirng its comment period. The current CCM Version 1.3 is an important tool for communication of customer security requirements, cloud service provider (CSP) assurance characteristics and the audit process. The new CCM Version 3.0 will add additional control objectives that CSPs can develop to. I wrote about these changes in a previous post.

This morning I reviewed the CCM 3.0’s controls for Security Incident Management, E-Discovery and Cloud Forensics (SEF) controls. The six controls are: SEF 1 (Oversight), SEF 2 (Incident Management), SEF 3 (Incident Reporting), SEF 4 (IR legal preparation), SEF 5 (IR metrics) and SEF 6 (Audit tools access). These were also present in the CCM 1.3 but numbered as IS-14, 22, IS-23 IS-24, IS 25 and IS 29. 

I provided the following comments on these controls:

  • General: More detail is required on some of these controls, and an additional control may be needed to address e-discovery, where customers require policy-based data retention functionality and the ability to specify legal holds, especially in a SaaS environment.
  • Oversight: The SEF control objectives need to be described more specifically. Customers need the ability to manage logs they have access to. Policies must also balance the needs of a customer suffering an incident with the CSP and other customers’ needs for security and privacy.
  • Incident management: Customers also need an escalation process to get access to more detailed forensics in the event of an incident. When its impossible for a CSP to directly give multi-tenant logs to a customer there should be a process whereby a mutually-agreeable third party can review the logs for the customer to get them the information they need without compromising security and privacy for the CSP and other customers.
  • Incident reporting: Customers need to understand the CSP’s definition of an “incident” and to have service level agreements (SLAs) for how soon incidents are reported and how much information is given.
  • IR legal preparation and Audits tools access: These controls are described very well in a way that reflects good security practices and customer requirements.

As customers evaluate the question of whether to move a sensitive application to the cloud, and as they evaluate alternative CSP solutions, its very important to look into incident response. Once these CCM 3.0 controls are finalized, the CSA will also produce a standard questionnaire that customers can use and some providers will make their answers to the questions publicly available. You can also get information through audit reports under non-disclosure agreements in some cases. But incident response is one area where you’ll have your security staff, auditors and attorneys look a lot deeper to make sure your interests are protected.

Please comment: Have you experienced an incident in the cloud such as a compromised VM, email account or DDOS attack? If so, how was your experience with the CSP? What would you do differently today, if you could?

Subscribe to Blog Notifications...  HERE