Any organization with sensitive data can be the target of a cyberattack, regardless of size or industry sector. As more and more enterprises move to the cloud, the threat landscape is evolving at an accelerated rate in which adversaries deploy advanced tactics to reach their end-goal. Incident response plays a critical role in securing your data and preventing an attack from wreaking havoc on your organization.
The foundation of a successful cloud incident response program focuses on preparation, operations, and post-incident activity. NIST and SANS — both trusted organizations have developed IR frameworks with incident response steps that closely align with these phases. Vectra AI CDR for AWS Incident Response was developed based on these phases, out of necessity to align with the NIST Incident Response lifecycle, coupled with operations encompassing AI-driven detection, analysis with containment, eradication and recovery. The AWS Security Incident Response guide outlines many methods for automating incident response techniques.
The AWS Security Incident Response guide outlines that preparing for an incident is essential. After detecting an event in the detection phase of an incident response and analyzing it in the analysis phase — you can use the automated solution for containment of the four supported AWS services. Containment of the incident is critical to addressing threats in real-time. What does an automated containment instance look like?
Why Vectra's AWS entity lockdown
Security is the top priority at Vectra. AWS has a shared responsibility model: AWS manages the security of the cloud, and customers are responsible for security in the cloud. Such a model leaves the customer in complete control of their security implementation, however, security incident response can be complex. Adopting Vectra CDR for AWS entity lockdown automation capabilities improves your SecOps teams’ response speed and simplifies the incident response operations, so your organization is better prepared for when an event takes place and can minimize the threat before it can wreak havoc on your organization.
Here is how we do it:
SecOps must respond and investigate when a deviation from the baseline occurs, such as from a misconfiguration or a change in external factors. Vectra CDR for AWS Entity Lockdown solution better prepares your team for security events by providing the following:
- AWS principle of least privilege: Only need to expose an SNS publish permission. Strongly controlled access.
- Automated workflow: The solution can integrate cleanly into existing workflows and be activated automatically to ensure out-of-band control to stop attacks from escalating into impact.
- Automated audit trail: The solution enables compliance auditing and logging.
- Cross-region and cross-account: Work from a single location across your entire AWS environment to simplify usage.
- Specific/Targeted: Ensures the compromised credentials are comprehensively locked out, so the attacker can't just leverage a different attack path. This ensures only the compromised credentials are locked out to avoid impacting business as usual activities.
AWS containment architecture and design
Vectra CDR for AWS uses an AWS SNS topic message to trigger a Lambda function. First, the AWS SNS message is published either manually or through a third-party tool, for example, Amazon Security Hub or SOAR. Then, the Lambda code triggers further actions based on the message's content. The SNS message requires two message attributes. An ARN of the entity to isolate and an ExtranalId. The user sets the ExtranalId during the deployment of the CloudFormation template. This field is static and is used to validate the SNS message by the Incident Response Lambda function.
This will accomplish the following tasks as illustrated in Figure 1:
- An AWS SNS message is published with an AWS entity ARN for containment and ExternalId.
- An AWS Lambda function is invoked by the SNS message. The Lambda function executes the incident response business logic based on the entity type.
- An AWS SNS audit email will be sent out to the user throughout the process. One email for the start of the process, one for success or failure, and one if the message falls into the dead-letter queue.
When the Lambda function is invoked, the following business logic is performed: The incident response business logic is illustrated in Figure 2.
Determine AWS entity type. Supported entities: Lambda, IAM User, IAM Role and EC2.
TheLambda function will attach a DenyAll AWS managed policy if the entity type is IAM Role or User.
If the entity type is an AWS Lambda function, the following logic is applied:
- Attach DenyAll AWS managed policy to the Lambda execution role.
- Set Lambda function property function_currency to 0. This will prevent the function from being triggered.
The following logic is applied if the entity type is an AWS EC2 instance.
Security group rules begin as an implicit denial of all traffic. When no rules are present, you create rules allowing specific traffic. Inbound traffic is allowed out regardless of outbound rules and vice versa; this is how AWS implements stateful connections within security groups. You can add or remove rules at any time, and changes are immediately applied to the instances associated with the security group. But, the effect of some rule changes can depend on how the traffic is tracked. Understanding how tracked connections work is vital to implementing effective security group containment. If a connection is tracked, it can maintain internet connectivity, despite attaching a security group with no rules. Security groups use connection tracking to track information about traffic to and from the instance — this is how they implement stateful connections even though not all traffic flows are tracked. There is one exception... ICMP traffic is always tracked.
Untracked connections apply to any traffic type with a quad zero rule for all ports in the either direction. You can see a examples of tracked and untracked connections.
- TCP or UDP flows for all traffic (0.0.0.0/0 Tracked. :/0) and there is a corresponding rule in the other direction that permits all response traffic (0.0.0.0/0 or :/0) for all ports (0-65535), then that flow of traffic is not tracked - Not tracked.
- Inbound and outbound TCP traffic on port 22 (SSH) is tracked, because the inbound rule allows traffic from 203.0.113.1/32 only, and not all IP addresses (0.0.0.0/0) - Tracked.
- Inbound and outbound TCP traffic on port 80 (HTTP) is not tracked, because the inbound and outbound rules allow traffic from all IP addresses - Not tracked.
- ICMP traffic is always tracked - Tracked.
If you remove the outbound rule for IPv4 traffic, all inbound and outbound IPv4 traffic is tracked, including traffic on port 80 (HTTP). The same applies for IPv6 traffic if you remove the outbound rule for IPv6 traffic. - Tracked.
Security groups are highly effective and target containment of a single Ec2 instance. Terminating tracked and untracked connections requires a multi-step process to terminate active connections and prevent a future one. All untracked connections are immediately terminated when applying the Vectra entity lockdown solution. However, only active tracked connections are terminated, which is very important to understand. In our solution, active connections are any connection that has network traffic flowing continuously or not more than 1-minute intervals.
The following solution will work for continuously active connections. For example, if the compromised EC2 Instance is being used for crypto mining or is part of a ransomware attack.
When the Incident Response Lambda function is invoked, and the entity type to isolate is an AWS EC2 instance, the following actions are performed.
- Attach conditional policy to deny all action to Instance Profile for compromised EC2 instance. A lot of solutions suggest detaching the Instance Profile Role from the instance. However, although such action would prevent the instance from initiating new sessions, it would not revoke existing sessions. For example, if the attacker exploited a misconfigured application and got security credentials from instance metadata, these credentials would remain active for up to 12 hours.
- Checks the VPC where the EC2 instances reside if an untrack connection security group exists; if not, create one, then apply the security group to the instance. This security group has a single ingress and egress rule of 0.0.0.0/0, converting tracked to untracked connections.
- Check the VPC for the existence of an isolation security group. If one does not exist, create one, then apply the security group to the instance. This security group has no ingress and egress rules. Assigning this security group will completely isolate the EC2 Instance.
Deploying Vectra CDR for AWS
To deploy Vectra CDR for AWS, you first need to access the CloudFormation templates. If you are using one AWS account, then you will only need the deployment Incident Response Resource template. However, you will need to deploy two templates if you have a multi-account setup and want a cross-account incident response solution. Deploying the first template in your AWS security account will host incident response resources. The second template will create a cross-account IAM Role in the other accounts that you want the solution to cover. The solution README fully documents the AWS CloudFormation templates and stack details. You can find additional resources in the GitHub repository.
Vectra CDR for AWS Automation
To start your automation, you will first need to deploy Vectra CDR for AWS CloudFormation stack. Then, if you're using the AWS console, you can publish an SNS message from the service resource screen. If you’d like to use the AWS CLI or the AWS SDK, the Incident Response SNS ARN can be found in the AWS CloudFormation stack output tab. A detailed walkthrough for each approach can be found in the README of the GitHub repository.
Addressing AWS incident containment
As mentioned previously, by following the CloudFormation, your SOC analyst will only need SNS publish privileges to respond to an AWS incident. A security service such as Amazon Security Hub or SOAR can also publish a message as part of the SecOps team workflow. Therefore, the SOC analyst would not need administrative privileges over suspicious AWS services. By following the steps outlined, your SecOps team will be able to create incident response by utilizing native AWS tools. This methodology also supports cross-account and cross-region containment. If you delete the stack in each account, a manual cleanup will be required to remove these security groups created for EC2 isolation.
Incident response is an integral part of a cyber security strategy for all enterprises. Through AWS incident containment, your SecOps team will have the assurance of knowing how to automate the isolation of an EC2 instance, an IAM user and Role, and a Lambda function to respond to any suspicious entities in your AWS environment.
What’s next?
Experience the power of Vectra CDR for AWS firsthand with our free trial.