When we are talking about Incident Response, the first and probably the most important standard that comes to mind is Computer Security Incident Handling Guide from NIST. And in this guide, there are a series of events and actions that comprise the incident response life cycle.
We have number one, preparation. That leads into detection and analysis, which then is followed by containment eradication and recovery, but possibly used in a cycle with detection analysis. And finally, we have post-incident activity, which is really just a mixture of Sections Three and going back to Section One, Preparation.
The first section of the Incident Response Life Cycle, is Preparation. And within Preparation, there are a number of different tasks that you’re going to want to know about from a security perspective. And we’re gonna start with Limiting the Blast Radius. And for this particular step, there are a couple of different concepts that are pretty straightforward and that you can associate with this. First of these, is deploying your accounts using AWS Organizations. Next, is to deploy your networks using multiple VPCs. Both of these can help you when there is a security event and you need to restrict the amount of resources that the actor can possibly have access to. Next, is Self-Documenting Infrastructure. And AWS gives you a couple of different ways to go about this. There are different services and features that can help you document your infrastructure without having to explicitly open a text editor. First of these is AWS Config. This is great from an inventory perspective. CloudFormation, where you’re actually defining infrastructure elements using text files and then creating them from those text files. And third, AWS SSM. The system’s manager service gives a number of features for inventorying at a deeper level including, network information, installed software, and license usage. The next step is creating Procedures and Run Books.
Our next task is to generate a Normal Behavior Baseline, and AWS provides a couple of ways to make this happen. The first of these is pretty straightforward. Just using the monitoring service, called CloudWatch. GuardDuty is an excellent tool and can be used to identify an abnormal behavior in your account.
There are three specific services that are going to be very helpful to the AWS customer in Assessing Risks. The first of these is Amazon Inspector. Next, we have GuardDuty, and the last one Amazon Macie. This is a service that can help you assess whether or not permissions on S3 buckets are too permissive.
Next we have Network Security.There are a number of different features that you can use to help improve the security from a network perspective. You can you Network Access Control Lists, Security Groups, both of these are going to be part of the VPC context and used together. You can use VPC Flow Logs for auditing the network traffic flow within VPC. And finally, you can use the AWS Web Application Firewall service. This is used in conjunction with CloudFront, and applies to web traffic, where you have the ability to identify and potentially drop abnormal requests.
Our next step, is the ability to Store Relevant Event Information. This is absolutely a proactive step that should be done as part of your strategic planning for security in AWS. And there are a range of features that you can use here as well. CloudWatch Logs is a great way to store log files durably with excellent ways of accessing them for analysis purposes. You have AWS Config streams, where you can create snapshots of the metadata configuration for your resources. You can use CloudWatch Events to keep track of what’s happening in your AWS account. You can store access logs in S3 in addition to CloudWatch Logs. And you can use CloudTrail Logs, that are stored in either Cloudwatch Logs or S3 to help correlate between behavior and actions that were taken to create that behavior.
*This article is based on Pearson IT Education materials and Chad Smith lectures