Appendix 1 - AWS Configuration Notes

Required permissions, data events guidance, bucket location, and KMS notes.

The Permissions Vectra Requires in your AWS Account

Vectra requires specific read-only permissions to monitor your AWS account. These permissions allow us to monitor your CloudTrail logs and contextual information.

Vectra AWS IAM Role

In order for Vectra to access required information in your AWS account, an IAM role will need to be created for Vectra in your AWS account that grants Vectra external access. Your AWS account must be the account that contains the S3 bucket where your CloudTrail logs are stored. Access can be limited to our AWS account exclusively, and a required External ID provides another layer of security. Vectra will assume this role when pulling any information from your AWS account. The role for Vectra will need to allow access from a Vectra AWS account provided during the setup flow. Vectra’s role does not need access to any other account in your organization.

About AWS External IDs

External IDs are uniquely associated with roles that are created to allow 3^rd parties such as Vectra to access your organization’s AWS resources. This will be a secret identifier that will be known by both you and Vectra. You specify the ID when defining the trust policy for the role, and Vectra provides the ID when assuming the role. In any deployment method, Vectra creates the External ID for you, and it should not be changed. For additional information about creating AWS IAM roles and External IDs see the following AWS articles:

• Creating a role to delegate permissions to an IAM user
• Providing access to AWS accounts owned by third parties
• How to use an external ID when granting access to your AWS resources to a third party

The Permissions required for Vectra CDR for AWS to Work Effectively

The role you create for Vectra in your AWS account will need some permissions to access specific data. These permissions are created automatically as part of the CloudFormation Template we offer in the setup process. Otherwise, you will need to manually add these permissions to the role you will grant Vectra access to.

List of Permissions

The table below explains the exact reason that each permissions is required:

Permission	Comment	Scope
s3:GetObject	This permission allows us to pull CloudTrail log data from the S3 bucket you specify.	The CloudTrail S3 bucket
s3:ListBucket	This permission allows us to list the objects within an S3 bucket	The CloudTrail S3 bucket
s3:GetBucketNotification	This allows us to confirm the SNS configuration of the customer’s S3 bucket is correct	The CloudTrail S3 bucket
s3:PutBucketNotification	This allows us to add an SNS topic to the customer’s S3 bucket. This is optional if you already have a SNS notification topic setup for your bucket.	The CloudTrail S3 bucket
sns:Subscribe	This allows us to subscribe our CDR for AWS Service to SNS updates from your CloudTrail S3 bucket	Your SNS topic
sns:Unsubscribe	This allows us to unsubscribe our service if you choose to delete our integration from the Vectra UI. Optional but recommended.	*
cloudtrail:GetTrail	This allows us to get information about the CloudTrail logs that you have	*
cloudtrail:ListTrails	This allows us to get information about the CloudTrail trails that you have.	*
cloudtrail:GetTrailStatus	This allows us to get information about the CloudTrail trails that you have.	*
cloudtrail:DescribeTrails	This allows us to get information about the CloudTrail trails that you have	*
kms:Decrypt	This permission is only required if your CloudTrail S3 bucket is encrypted with KMS	The KMS key used for your CloudTrail S3 bucket
iam:ListAccountAliases	This permission allows us to offer better context around our detections	*
iam:ListUsers	This permission allows us to offer better context around our detections	*
iam:ListRoles	This permission allows us to offer better context around our detections	*

Vectra requires the Amazon Resource Name (ARN) for the role you have created, the S3 bucket you would like us to pull CloudTrail logs from, and the ARN for the SNS topic we will subscribe to.

Guidance on CloudTrail S3 Data Events

S3 data events provide visibility into data plane activities within AWS S3. They cover actions within a S3 resource (e.g., objects copied to/from a bucket) and are often high-volume activities. Visibility into these events is pivotal to identify adversaries executing exfiltration or ransomware attacks.

Vectra currently recommends enabling only S3 data events for all high-value S3 buckets within your organization. This is in addition to the required management events discussed previously. In general, Vectra does not recommend logging data events for high use public or development buckets that contain no valuable data. S3 data events can be enabled for all buckets or specific buckets.

Please see Appendix 4 – AWS Log Ingestion Cost Estimates for additional guidance on data event costs and lifecycle management of these events.

Enabling and Validating S3 Data Events

To enable logging of S3 data events, you must create a new trail or reuse an existing trail and configure it to log S3 data events. To validate that you have this configured, follow the steps below but stop at step 3a.

1. First, sign in to the AWS Management Console and open the Amazon CloudTrail console at https://console.aws.amazon.com/cloudtrail/ and select Trails in the left-hand panel.
2. In the Trails list, choose the name of the Trail.
3. Scroll down to Data events.

   1. If data events are already enabled, line items with details of the S3 bucket and enabled operations will be visible.
   2. If data events are not enabled, click the Edit button to enable the Trail to log data events. Instructions can be found in Enabling CloudTrail event logging for S3 buckets and objects.

Please Note:

Vectra requires centralization of CloudTrail logs. All management events and data events must be stored in the same S3 bucket. If your organization chooses to adopt multiple trails for logging, all trails must be configured to deposit logs into the same S3 bucket configured for the Vectra CDR for AWS connection.

CloudTrail Log S3 Bucket Location and Region

Regardless of the chosen deployment method (CloudFormation Template or manual), Vectra will need the location of your S3 bucket (including Region) that is being used to store the CloudTrail logs. Your CDR for AWS connection must be deployed in the same Region that houses the S3 bucket storing your CloudTrail logs. Please see the steps below to find this location:

• Navigate to the AWS CloudTrail service and click on Trails.
• Find the Trail containing your AWS Management and Data Events.
• Make note of the S3 bucket name and Region so that it can be provided during setup.

  • See the example below of which fields to make note of:

KMS Encrypted S3 Bucket Support

CDR for AWS supports the use of KMS encrypted S3 buckets. The KMS key must be provided to Vectra in the CloudFormation template or if you are doing manual AWS configuration, you must give the Vectra IAM role kms:Decrypt permissions against the specific KMS key used for your S3 bucket. Vectra simply requests the log data from S3 after notification via SNS and AWS does the decryption call against KMS as required.

Architecture with KMS Encryption

Additional AWS KMS Information

• Additional general documentation about the AWS Key Management Service is available here:

  • https://docs.aws.amazon.com/kms/index.html
• Using AWS S3 Bucket Keys.

  • https://docs.amazonaws.cn/en_us/AmazonS3/latest/userguide/bucket-key.html
• Finding the Key ID and ARN.

  • Navigate in AWS to CloudTrail > Trails > Your specific Trail > AWS KMS Key and copy it for use with the CloudFormation template.

• Vectra does not currently support decrypting data with different KMS keys being used in the same S3 bucket.

  • Please get in touch with us if this is a requirement for your organization.