0

I am trying to compile a list of areas one should be aware of when doing Incident Response on public cloud environments, e.g. a hybrid public cloud, where some services are provisioned in local data-center, while is in the cloud.

Some thoughts:

  • Pulling RAM to do memory forensics will be hard, if not impossible, to do on a SAAS, PAAS, or similar service.
  • Physical access to devices will in most cases be impossible. If you have to get the physical disk that stored illegal material, you are most likely out of luck.
  • The service you are using may be limited, altered or in other ways different than what you are normally using. E.g. Azure SQL as a Service, you don't have a fully fledged database as you are used to. Plan for this.

Some concerns that is not directly impacted by Incident Handling, but my cause it to happen:

  • Isolation vs. Multi-tenancy. In some way, you are going to share resources. Your cloud service may have other clients ruining it for your systems.
  • The above may also apply to security. Compromise of one SAAS client, might lead to compromise of others if the vendor is not configured properly.
  • VM Escape is a dreaded possibility. A compromise in the underlying hypervisor might compromise all hosts.
  • If you're not familiar with the cloud service's ACL's, you may be unsuspectingly exposing services on the open internet, that you otherwise thought to be internal only.
  • Cloud vendor may not be as dilligent as you when it comes to limiting physical access. #BadUSB
  • Your data may be susceptible for e-discovery, even if you had nothing to do with the incident.

Does anyone have any other thoughts or concerns on how a public cloud may impact our incident handling? Preferably we could keep in mind the 6 phases too:

  • Preparation
  • Identification / Analysis
  • Containment
  • Eradication
  • Recovery
  • Lesson Learned
1

A lot of this comes down to partnership, identification of responsibilities and communication between you and the cloud Service Provider (CSP)

Preparation

Identify who is responsible for monitoring suspicious activity. Do you capture logs, monitor and review logs and alerts? Does the CSP?

Identification/Analysis

If you suspect an incident, do you know who to talk to at the CSP? If the CSP suspects an incident, will they contact you? If so, is this standard or an escalation path? i.e. are you informed in a timely manner or too late?

Containment

Do you have the tools to do this? Do you know what resources you're sharing with others? As a hybrid cloud offering, do you have other facilities, environments you can rely on? How do you identify infection and propagation thereof? Who do you inform? Do you have to tell the CSP before you contain the problem? Must they take action on your behalf?

Eradication

Do you have resource available to eradicate when also containing? Can you confirm eradication? Can CSP confirm or vouch for same?

Recovery

Do you have backups, clean images? Do you need to re-synchronise with other environments? Do you have mechanisms to achieve this and verify the integrity of your systems, applications, data once complete?

Lessons learned

If this happens again, can you reduce all the workload above? Based on how the situation was managed, should you give more or less responsibility to the CSP? Can you improve communication and transparency of activities? Is it possible to change those issues you identify require change or must alternatives be identified?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.