Amazon Web Services Integration

1. Log in to your AWS VPC console.
2. Select Your VPCs.
3. Right-click a VPC, then select Create Flow Log.

4. Select one of the following options from the Filter drop-down:

   • Select All to log both accepted and rejected IP traffic, allowing Cisco XDR to see both types of traffic.
   • Select Accept to log only accepted IP traffic, allowing Cisco XDR to see only accepted traffic.
5. Select the Send to an S3 bucket Destination.

6. Enter an S3 bucket ARN in which you want to store flow log data.

   Note: If the S3 bucket does not exist, AWS creates it after you commit your changes.

7. For Log record format, select Custom format.
8. Select all attributes, except reject-reason, from the Log format drop-down list. We require all version 2 attributes (AWS default format) but recommend version 3 attributes in a custom log format.

Note: Make sure to follow Steps 7 and 8. We do not support the reject-reason field added in the VPC Flow Logs version 8. The Troubleshooting: Virtual Private Cloud (VPC) Flow Logs section provides information that may help if these steps are missed.

9. For Log file format, select Text. This is the default format.
   
10. Click Create flow log.

Note: If restricting access to this S3 bucket based on IP, make sure that communication with the relevant IPs is allowed. Go to IP Address for Integrations to see the list of public IPs used by Cisco XDR.

Warning: The following configuration will delete any objects in the bucket, including flow logs, after 1 day. We recommend this configuration if you are only storing VPC flow logs in this bucket for use with Cisco XDR.

1. Log in to the AWS S3 console.
2. In the Buckets list, choose the name of the bucket where you want to store VPC flow logs.
3. Select the Management tab.
4. In the Lifecycle rules section, click Create lifecycle rule.
5. Enter a unique name for the Lifecycle rule, for example Expire after 1 day.
6. For the scope of the lifecycle rule, select This rule applies to all objects in the bucket.
7. Check the I acknowledge that this rule will apply to all objects in the bucket check box.
8. Under Lifecycle rule actions, select Permanently delete previous versions of objects.
9. Under Permanently delete noncurrent versions of objects, set Days after objects become noncurrent to 1.
10. Click Create rule.
11. Back in Lifecycle Configuration, click the radio button next to the rule just created, and in the Actions drop-down, click Enable rule.

1. In the Cisco XDR navigation menu, choose Administration > Integrations.

2. On the Integrations page, click the My Integrations tab and select your Amazon Web Services integration.

3. Go to the VPC Flow Logs tab.

4. Click Add VPC flow log.

5. In the S3 Path field, paste in the saved Destination name.

   Note: You can add more than one configured S3 bucket. You only need to configure one IAM access policy and role for your Cisco XDR integration with AWS.

6. Select the IAM Role from the Credentials list that corresponds to the account that owns the S3 bucket.

7. Expand the Policy document and follow the instructions to attach the S3 access policy to the IAM role you selected.

8. Click Add.

Note: If you already have a KMS key, you can add the required permissions to the key. For more information, see Add IAM policies in the external account.

1. Log in to the AWS KMS console.

2. In the navigation pane, select Customer managed keys.

3. Click Create key.

4. Select the Key type and Key usage.

5. Click Next.

6. Enter a name for the KMS key.

7. (Optional) Enter a description, tag key, and tag value.

8. Click Next.

9. Select the IAM users and roles that can administer the KMS key. Make sure to include the role (for example, cisco-xdr-integration) created in Step 1: Create the IAM Role of the Amazon Web Services panel in the Integration guides area.

10. Click Next.

11. Select the IAM users and roles that can use the key in crytographic operations. Make sure to include the role (for example, cisco-xdr-integration) created in Step 1: Create the IAM Role of the Amazon Web Services panel in the Integration guides area.

12. Click Next.

13. (Optional) Choose if you want to allow other AWS accounts to use the KMS key.

14. Click Next.

15. Review the key settings that you chose. You can still go back and change all settings.

16. Click Finish to create the KMS Key.

Below is a sample KMS policy that should be applied to the KMS key. Note that the relevant sections of the policy are:

• "Allow use of the key" SID

• "Allow attachment of persistent resources" SID

{
    "Version": "2012-10-17",
    "Id": "key-consolepolicy-3",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<your-account-id>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<your-account-id>:role/admin"
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<your-account-id>:role/cisco-xdr-integration",
                    "arn:aws:iam::<your-account-id>:role/admin"
                ]
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<your-account-id>:role/cisco-xdr-integration",
                    "arn:aws:iam::<your-account-id>:role/admin"
                ]
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        },
        {
            "Sid": "Allow Logs Delivery to use the key",
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "<your-account-id>"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:us-east-1:<your-account-id>:*"
                }
            }
        }
    ]
}

To finish configuring the AWS KMS encryption to work with Cisco XDR:

1. Configure VPC Flow Logs to send to an S3 bucket and ensure the encryption is your KMS key. For more information on creating the S3 bucket, see Configuring S3 Bucket Flow Log Data Storage.

2. Verify that the S3 bucket is currently collecting flows by navigating to the bucket in the AWS S3 console and checking that recent data has been sent to the bucket properly.

3. Add the S3 bucket to Cisco XDR. For more information, see Configuring Cisco XDR to Access Flow Log Data from an S3 Bucket.

1. Log in to the AWS CloudTrail console.

2. Select Trails and create a new trail or display details of existing multi-region trail that you want to use as a source of logs. The Trail needs to have Read and Write API Activity enabled for Management events.

3. Copy the Trail log bucket name and the prefix.

1. In the Cisco XDR navigation menu, choose Administration > Integrations.

2. On the Integrations page, click the My Integrations tab and select your Amazon Web Services integration.

3. Go to the CloudTrail tab.

4. Click Add a CloudTrail S3 path.
5. Enter a Name for the CloudTrail path.
6. In the Trail log bucket name field, paste the saved Trail log bucket name.
7. In the Prefix field, paste the saved prefix.
   

8. Select the IAM Role from the Credentials list that corresponds to the account that owns the S3 bucket.

9. Expand the Policy document and follow the instructions to attach the S3 access policy to the IAM role you selected.

10. Click Create.

A NAT gateway is a Network Address Translation (NAT) service. When using a NAT gateway, instances in a private subnet can connect to services outside your VPC, but external services can't initiate a connection within those instances. The NAT Gateway only allows outbound access.

Can AWS Store VPC Flows That Navigate From a NAT Gateway?

AWS provides the ability to store VPC flows both from the private Elastic Cloud Compute (EC2) node to the NAT gateway and also to the external internet using a custom VPC flow log configuration. AWS stores the originating traffic source in the pkt-srcaddr and pkt-dstaddr fields.

Note: For more details about how AWS manages traffic from NAT devices in a VPC, refer to Traffic Through a NAT Gateway.

When customers add the required fields (pkt-dstaddr and pkt-srcaddr), Cisco XDR collects and displays the originating sources reported by AWS:

• AWS releases traffic with the endpoint and NAT stored under the pkt-addr fields.
• The pkt-dstaddr and pkt-srcaddr fields display both the originating endpoint traffic and the NAT gateway traffic.

How Can I Tell if the Custom VPC Flow Log Configuration is Set Up in My Tenant?

To verify your current configuration, review the header of your VPC flow log files in Amazon Simple Storage Service (S3). Then search for the pkt-srcaddr and pkt-dstaddr fields.

Note: Without these fields in S3, Cisco XDR doesn't have visibility into the traffic sent from a private IP to the internet when it’s behind the NAT gateway.

How Does Cisco XDR Manage VPC Flow Logs From AWS?

If the pkt-dstaddr and/or pkt-srcaddr are present in the flow, Cisco XDR uses these fields instead of the srcaddr and the dstaddr to determine the destinations (reporting the “true” network source). AWS releases flows with the NAT gateway labeled as the pkt-dstaddr and/or pkt-srcaddr. Cisco XDR treats these flow as if they originate directly from the NAT gateway.

Note: For more information about these fields, refer to Traffic Through a NAT Gateway.

What Should I Expect From Traffic that Navigates Through a NAT Gateway Regarding Flows?

In Cisco XDR, we see and record the following two flows:

• flow for the endpoint navigation through the NAT gateway
• flow for the NAT gateway itself

How Does Cisco XDR Model the Endpoint and the NAT Gateway It Navigates Through?

Cisco XDR models both the endpoint and the NAT Gateway itself as two separate entities. Flows associated with the endpoint device are associated with the endpoint; flows associated with the NAT Gateway device are associated with the NAT gateway.

Typically, you will not see a one-to-one match in the detections released for the NAT gateway with the endpoint navigation through the NAT gateway. Cisco XDR searches for anomalies based on past behavior. The endpoints have different behavioral profiles. For example, an outbound traffic spike for an endpoint navigation through a NAT Gateway may not be anomalous for the NAT Gateway itself.

What Kind of Flows Are Visible With the pkt-srcaddr and pkt-dstaddr Fields Included?

The following example shows how AWS VPC flow log traffic as it transitions through a NAT gateway when both the pkt-srcaddr and pkt-dstaddr fields are included.

Note: Multiple flows are provided in the logs that represent unidirectional flow of data.

In this example:

• The blue line represents traffic from the EC2 node to the internet when the pkt-srcaddr and pkt-dstaddr fields are available.
• The black line represents traffic from the NAT Gateway to the internet regardless of additional pkt-srcaddr and pkt-dstaddr fields.

Note: Cisco XDR always uses the pkt-srcaddr and pkt-dstaddr fields if available.

There are two types of AWS load balancers: Network Load Balancer (NLB) and Application Load Balancer (ALB).

How Does Cisco XDR Capture Traffic that Navigates through a Network Load Balancer (NLB)?

Cisco XDR manages NLB traffic similar to the way NAT Gateways traffic is managed, with the exception that the pkt-dstaddr and/or pkt-srcaddr fields aren’t required. AWS replicates the flows across Elastic Network Interfaces (ENIs).

Note: For more details about how AWS preserves the client IPs that navigate through a NLB, refer to the AWS documentation.

The following example shows how traffic navigates through a NLB.

In this example:

• The blue line represents traffic from the EC2 node to the internet.
• The black line represents traffic from the NLB to the internet.

Note: The pkt-srcaddr and pkt-dstaddr fields are not required to see the traffic as shown.

How Does Cisco XDR Capture Traffic that Navigates through an Application Load Balancer

In AWS VPC flow logs, Application Load Balancers (ALBs) terminate the TCP connections. Additionally:

• The outbound bytes from the EC2 node to the internet are visible and appear in the logs.
• The inbound flows from the internet to the EC2 node are routed through the ALB and are not shown in the EC2 node directly.

The following example shows how traffic navigates through an Application Load Balancer (ALB).

In this example:

• The red line represents traffic from the EC2 node to the ALB.
• The black line represents traffic from the ALB to the internet.

Note: The pkt-srcaddr and pkt-dstaddr fields are not required to see the traffic shown as shown.