AWS

Introduction

This article describes the Field Effect MDR integration with Amazon Web Services (AWS).

Integration Details

This integration allows Field Effect MDR to monitor AWS with a focus on audit logging data. We monitor AWS's management plane (via CloudTrail) to monitor "who did what, and when" within your AWS environment. (Learn more)

If AWS GuardDuty is enabled in your environment, Field Effect will be able to monitor these findings. GuardDuty generates a finding whenever it detects unexpected and potentially malicious activity in your AWS environment. (Learn more)

If you enable the optional step below, Field Effect can also monitor CloudTrail data events for the S3 buckets you choose — object-level activity such as GetObject and PutObject calls, not just the management plane. This is off by default; see "Enable S3 Data-Event Log Collection" below.

Field Effect can also recover two kinds of detail that CloudTrail alone doesn't provide, both included in the base setup:

• The actual command text of an AWS Systems Manager Run Command (SendCommand), which CloudTrail redacts for security reasons.
• The configuration and deployment package of a Lambda function shortly after it is created or its code is updated, since CloudTrail's log entry for those events carries very little detail on its own.

Requirements 

To complete this integration, you will need administrator access to both your AWS environment and the Field Effect MDR Portal. 

Setting Up the Integration

To enroll Amazon Web Services (AWS) for cloud monitoring, you’ll need to perform the following tasks:

1. Prepare AWS for the integration

   • Create a new AWS user.

   • Attach the required permissions policies

   • Create the new user's Access Key.

2. (Optional) Enable S3 data-event log collection.

3. (Optional) Enable AWS identity containment (active response).

4. Complete the Integration in the Field Effect MDR Portal.

Prepare AWS for the Integration

The following sections outline the tasks you must complete in AWS before you configure the integration in the Field Effect MDR Portal. 

Create a New AWS User

From the AWS Console, search for "IAM" in the search bar (Alt+S) and click the result. It will take you to the IAM Dashboard.

From the IAM sidebar options, select Users from the Access Management section.  

From the Users page, click the Create User button

Give the user a relevant and memorable name ("Field Effect MDR User") and click Next.

Attach the Required Policies

On the permissions step, set the user's permission option to Attach Policies Directly.

1. Attach these AWS managed policies** (use the search bar to find them):

• AWSCloudTrailReadOnlyAccess

• IAMReadOnlyAccess

• AmazonGuardDutyReadOnlyAccess (optional - only if GuardDuty is enabled in your account)

2. Add this inline policy for Lambda and Run Command detail recovery. On the same step, choose *Create inline policy*, switch to the JSON editor, and paste the following. Give it memorable name like `FieldEffectMDREnrichment`:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PollLambdaFunctionDetails",
            "Effect": "Allow",
            "Action": [
                "lambda:ListFunctions",
                "lambda:GetFunction",
                "lambda:GetFunctionUrlConfig",
                "lambda:ListFunctionUrlConfigs",
                "lambda:GetFunctionConfiguration"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RecoverRunCommandText",
            "Effect": "Allow",
            "Action": [
                "ssm:ListCommands",
                "ssm:ListCommandInvocations",
                "ssm:GetCommandInvocation"
            ],
            "Resource": "*"
        }
    ]
}

This policy is optional in the sense that collection still works without it, but two things return less detail if it's skipped: 

• Run Command text comes back redacted by CloudTrail
• Newly created or updated Lambda functions are logged with only the bare event, not their configuration or code.

After adding the policies, click Next, review, and click Create User. This creates the Field Effect MDR user for the integration.

Create the New User's Access Key

On the Users page, select the newly created user. 

In the Access Keys section, click Create access Key.

For the key's use case, select Application Running Outside AWS and click Next

You'll be presented with the new Access Key and an additional secret access key. Download the .csv file or copy both of these — you will need them when completing the integration in the Field Effect MDR Portal.

(Optional) Enable S3 Data-Event Log Collection

By default, Field Effect monitors your CloudTrail management events only. If your CloudTrail trail is also configured to log data events (object-level S3 activity) to a bucket, Field Effect can collect and monitor those logs too. Skip this section if you have not configured data events, or do not want them monitored.

1. Identify the S3 bucket(s) your CloudTrail data-event trail writes to. In the AWS Console, go to CloudTrail >Trails > your trail, and note the S3 bucket name under its storage configuration.

2. Add a second inline policy to the Field Effect MDR user, scoped to that bucket (or buckets):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadCloudTrailDataEventLogs",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::<YOUR-CLOUDTRAIL-BUCKET-NAME>",
                "arn:aws:s3:::<YOUR-CLOUDTRAIL-BUCKET-NAME>/*"
            ]
        }
    ]
}

Replace <YOUR-CLOUDTRAIL-BUCKET-NAME> with your actual bucket name. If more than one bucket is in scope, repeat both lines (the bucket ARN and the /* object ARN) for each one inside the Resource array.

This grant is intentionally limited to the bucket(s) you name — Field Effect never requests broader S3 access than the specific logs you've chosen to share.

(Optional) Enable AWS Identity Containment

Field Effect can disable a compromised AWS IAM user or role during an incident, and restore it once the incident is resolved. This is off until you complete the steps below and stays off for any account where you skip them.

This is documented in full in a separate article covering setup, what Field Effect can and cannot do, and how to undo a containment yourself — See AWS - Identity Containment (Optional). 

In short: you create and own a deny-all policy named FieldEffectMDRContainment, and grant the Field Effect user permission to attach and detach only that one policy — nothing else. 

Field Effect can never modify the policy's contents, grant permissions, or touch a permissions boundary.

Complete the Integration in the MDR Portal

Note for Partners: This procedure is performed on a per-client basis. Ensure that the Organization Selector is set to the appropriate client before continuing.

After you have prepared AWS for the integration (above), Navigate to the Field Effect Portal's Administration > Integrations page. From the Cloud monitoring tab, click Add.  

The integration wizard will open. Paste the AWS Client ID and the AWS Client Secret you gathered in the previous procedure (Preparing AWS for the Integration) and click Add.

You'll be taken back to the integrations page, and the integration card will show that the integration is connected and promoted to the top, alongside any other connected integrations. Field Effect MDR will now have access to AWS's available reporting and generate AROs when appropriate.