Incident Response Changes in the Cloud – Who you gonna call?

An Intrinsec discussion paper

“Incident response and computer forensics in a cloud environment require fundamentally different tools, techniques, and training for responders to accurately assess a situation and capture appropriate evidence when conducting an incident response that follows federal incident response guidelines. The response plan must address the possibility that incidents, including privacy breaches and classified spills, may impact the cloud and shared cloud customers.”

-           NIST Challenging Security Requirements for US Government Cloud Adoption (Draft)

Your company has made the decision to leverage the cloud.  Hopefully, they have come to you to ensure that data stored in the cloud is maintained responsibly.  You’ve considered multi-tenancy, performed your threat modelling and recommended encryption for data at rest as well as in transit, so you’re done, right?  Not so fast…

When something goes wrong, and you know it will, how are you going to respond?   Does your incident response plan reflect the changes that arise as a result of moving to the cloud?

• Do you have a phone number to call? 
• Is there a key contact with the cloud provider established? 
• Are they available 24/7/365?
• How does your CIRT respond to a brute force attack on an IaaS instance in the cloud?  Can they even detect such an obvious attack?
• Under what circumstances does the cloud provider get engaged?
• Are your incident response people aware they are merely Informed and not Responsible, Accountable or sometimes not even Consulted during an incident?
• Does your service provider have a logging mechanism in place that you can leverage so you are alerted to issues?

Now here’s another question, worthy of its own paragraph…Under which circumstances will your Cloud Provider take your system offline to protect other clients?  See, in a public cloud environment, you are secondary to the service as a whole.  Think about what your plan is to deal with an infected workstation within your network?  What is the first step?  Is it removing the offending system from the network?  The same principles apply for the cloud provider:  remove the instance(s), eradicate the problem, then re-introduce the instance(s).

Anyone who has taken Cloud Security Alliance training knows that these lines of communication have to be established in advance of an incident, not during the incident!  Students also know that security (and response) is shared between the customer and the provider, the extent to which the consumer is in charge depends greatly on the service (SaaS – PaaS - IaaS) model.

I hope this introduction to Incident Response in the cloud has made you think of potential pitfalls that you may experience in your particular scenario.  I also hope this information is an example of how it is very simple to procure cloud computing services, but doing so responsibly is a whole other issue.  Traps must be identified before any migration to, or development in the cloud takes place.  Incident Response is just one such trap.

For further information on Cloud Security Alliance training, please access http://www.intrinsec.ca/cloud-security-alliance-training.html

Sincerely,

Graham Thompson, CISSP, CISA, CCSK