Architecture and requirements

Intro and overview for CDR for AWS, general requirements, network setup requirements for QUX deployments, and deployment overview.

Introduction

CDR for AWS offers advanced Threat Detection & Response coverage for your AWS control plane. We leverage AI & ML techniques to monitor all activity in your organization’s global AWS footprint for malicious behaviors.

CDR for AWS leverages CloudTrail logs and contextual IAM information to find malicious activity, and then attribute it to the malicious actor itself using Vectra’s Kingpin technology.

This guide will enable you to set up Vectra’s CloudTrail integration to allow us to offer protection for your organization. CDR for AWS is available in both Vectra’s Respond UX and the Quadrant UX. See this article for UX differences.

Overview

AWS CloudTrail is a service automatically enabled for all AWS customers at no cost. Most customers create a "Trail" that saves AWS CloudTrail logs to an AWS S3 bucket, from which various consumers can pick up the logs for different use-cases. CDR for AWS leverages this model.

• AWS CloudTrail logs events to an S3 bucket.
• Amazon SNS (Simple Notification Service) will be configured to notify Vectra when new logs are available.
• Vectra will then pull the log files from the S3 bucket.
• Vectra processes the management and data events through proprietary algorithms to generate Detections.

Vectra provides an AWS CloudFormation template to automate the setup of SNS and the authorized IAM role.

General Requirements

• CDR for AWS requires an entitlement for the offering either through a purchase or a trial (POC/POV).

  • Click See how it works at CDR for AWS to schedule a demo or Contact Us to arrange a trial.
• CDR for AWS requires that CloudTrail logging to a single S3 bucket be enabled for your AWS account(s).

  • This includes multi-region setups, and we suggest setting up an organizational CloudTrail.
  • This Getting started with AWS CloudTrail tutorial provides additional guidance if needed.
• Vectra requires Management Events and recommends S3 Data Events from AWS CloudTrail.

  • For Management events, AWS KMS events are NOT required.

    • The ability to stop logging these events was added by AWS recently and if you already have Trails setup, it is likely that this setting is enabled. You can disable this setting to save costs and reduce noise if you don’t need the data elsewhere. Vectra has determined that these logs don’t contain sufficient security value to justify their added costs.
  • S3 Data Events provide detail for 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.
  • S3 Data Events are recommended for all high-value S3 buckets within your organization.
  • For additional guidance on CloudTrail S3 Data Events please see Guidance on CloudTrail S3 Data Events and Enabling and Validating S3 Data Events later in this overall guide.
  • Logging S3 data events may result in higher CloudTrail costs for high usage S3 buckets. Please see Appendix 4 for more detail.
• When deploying in an AWS Region created after 2019 additional steps are required.

  • Please see Enabling STS in AWS Regions Created After 2019 in Appendix 3 for more detail.

Network Setup (Quadrant UX deployments only)

This is only required for customers using Vectra’s Quadrant UX. Customers using the Respond UX do NOT need to set firewall rules for this. For more detail about the different UX’s, please see this article.

Your Vectra Brain must be able to securely access Vectra’s managed resources over TCP/443 HTTPS connections to report detection events to your Vectra UI. Please configure your firewall rules accordingly.

FQDN Specific FW Rules	IP Specific FW Rules	Required For
https://authgateway.uw2.public.app.prod.vectra-svc.ai/	54.245.33.175 52.42.70.176 100.21.109.72 52.26.91.157	Data Sources deployed in US
https://authgateway.ew1.public.app.prod.vectra-svc.ai/	54.171.40.108 54.246.213.148 54.75.47.147	Data Sources deployed in EU
https://authgateway.ec2.public.app.prod.vectra-svc.ai	16.62.18.237 16.62.142.98 51.96.54.201	Data Sources deployed in Switzerland
https://authgateway.cc1.public.app.prod.vectra-svc.ai/	3.96.112.208 52.60.211.221 15.222.69.161	Data Sources deployed in Canada
https://authgateway.as2.public.app.prod.vectra-svc.ai/	13.54.11.66 13.55.79.24 13.55.106.102	Data Sources deployed in Australia

Deployment Overview

The simplest deployment method is to use a Vectra provided CloudFormation template. This template automates tasks that would otherwise have to be done manually. Vectra links to this template from the onboarding flow. It is also available via request.

Please see the appendices for guidance on related topics or deploying manually. In general, deployment consists of the following steps:

• Creating a CDR for AWS connection in the Vectra UI.
• Creating an SNS topic (or using an existing one) to notify Vectra when new logs are available to retrieve.
• Creating a role in your AWS account to allow Vectra to retrieve logs from the S3 bucket where your CloudTrail logs are located.
• Providing Vectra with the AWS role ARN, S3 bucket location, and SNS topic ARN.

  • Vectra will subscribe the SNS topic to your S3 Bucket after submitting these.

Please Note:

After the data source connector for AWS CloudTrail has been fully configured, it can take several hours to a day for all AWS related detections to be able to fire and for enrichment (attribution to a specific source account at the bottom of a role chain) to be available for any detections that fire as a result of the new connector. This is because the data source connector might have been activated after the role chain was started and therefore Vectra might not have the full role chain in its forwarded data.