Compromise Response

Because you should be running an intrusion detection system, you should know very quickly if and when an actual compromise occurs. If you respond rapidly, you can take advantage of the cloud to eliminate exploit-based downtime in your infrastructure.

When you detect a compromise on a physical server, the standard operating procedure is a painful, manual process:

  1. Remove intruder access to the system, typically by cutting the server off from the rest of the network.

  2. Identify the attack vector. You don’t want to simply shut down and start over, because the vulnerability in question could be on any number of servers. Furthermore, the intruder very likely left a rootkit or other software to permit a renewed intrusion after you remove the original problem that let him in. It is therefore critical to identify how the intruder compromised the system, if that compromise gave him the ability to compromise other systems, and if other systems have the same vulnerability.

  3. Wipe the server clean and start over. This step includes patching the original vulnerability and rebuilding the system from the most recent uncompromised backup.

  4. Launch the server back into service and repeat the process for any server that has the same attack vector.

This process is very labor intensive and can take a long time. In the cloud, the response is much simpler.

First of all, the forensic element can happen after you are operating. You simply copy the root filesystem over to one of your block volumes, ...

Get Cloud Application Architectures now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.