In a previous blog, I covered four cloud features that can help incident response teams. In today’s blog, I’m focusing on how to prepare your Amazon Web Services (AWS) environment so you can reduce your stress levels if and when you have an actual cyber security incident. Incident response can be extremely stressful, especially when you find an attacker still active in your network. The more you can plan and stage your environment, the easier it will be for your team to deal with an emergency. Even if you are going to outsource the investigation or the response, having this in place will allow you to “stop the bleeding” and get your incident responders the data they need.
This blog includes specific options for your AWS environment. If you are using a different cloud computing provider or platform, many of the same recommendations still apply, but the tools and methods will be different. Now let’s talk about what you can do now to set you up for success later.
Protect the Evidence
Make sure you’re taking advantage of logging in your cloud environment. Regardless if an incident occurs in the cloud or in your physical network, the incident response (IR) team is going to need your logs to determine exactly what happened and the extent of the compromise. Your log files are evidence for any potential investigation, so make sure they are retained and protected from tampering. Amazon CloudWatch and CloudTrail logs have options for encryption that you can easily enable. CloudTrail also has a file validation option that is enabled by default.
When dealing with any cloud environment, it’s important not to forget application and system logs. Where feasible those logs should be pulled and protected as well. Not all incidents will be caught immediately, so it’s important to ensure all your logs are not rolled over and lost. We’ve responded to incidents where the initial compromise occurred more than a year before it was identified. Industry standard is maintaining your security logs for a minimum of six months, but if you can maintain them longer, then you should do so.
Those logs also should not be accessible by everyone, however. Use IAM Groups and Roles to carefully control who has access to your logs. Depending on your environment set up an IR Group or Role now, that gives your response team Read-Only access to your logs for investigations.
Streamline Containment
Create an EC2 Security Group that can be used to isolate any compromised systems in the network. The group should be extremely restrictive and block all outbound traffic. This group can also allow access from an investigator’s system if required.
If your company has its own in-house forensic team, you could also maintain a Virtual Private Cloud (VPC) staged for forensic investigations. This cloud should be locked down just like the IR Security Group, using Route Tables to prevent any traffic to the Internet and allowing only your investigator to communicate with the system. Keep a pre-built copy of your forensic workstation in the VPC ready to go for when you need it. Check out SIFTonEC2 for a possible forensic workstation if needed.
Summary
Bottom line, you can do some quick small things to pre-stage your AWS environment for an incident. Even if you plan to outsource the investigation and forensics to a third party like Delta Risk, you can save your IT team some heartburn by having these functions set up and documented in your response plan.