Documentation — August 29, 2026

10 files changed, 78 insertions, 42 deletions — view the commit on the mirror.

AWS audit log role renamed to cortex-logs-ingestion-access-*; manual deployment method added for AWS, GCP and Azure

The AWS audit log reader role is renamed from CloudTrailReadRole / CortexLogsReadRole to cortex-logs-ingestion-access-*, including in the cross-account KMS key policy example.
A new Deployment Method advanced setting offers Infrastructure as Code (recommended) or Manual onboarding on AWS, Google Cloud Platform and Microsoft Azure.
Custom (BYOB) audit log collection is rebuilt around SNS: the Cortex-created SQS queue subscribes to your SNS topic, so S3 event notifications now target the topic rather than the queue.
Two new BYOB constraints are documented — the Control Tower log bucket must use Bucket owner enforced object ownership, and its objects may be encrypted under at most one customer-managed KMS key.

Highlights

The AWS audit log reader role is renamed to `cortex-logs-ingestion-access-*`

It replaces both CloudTrailReadRole and CortexLogsReadRole in the capability-to-role table, the onboarding steps and the cross-account KMS key policy example customers paste into their own key.
Cloud onboarding gains a Deployment Method choice of Infrastructure as Code or Manual

The same advanced setting is added to all three CSP onboarding pages, with Manual offered for organizations whose policies require provisioning resources and permissions by hand.
BYOB post-deployment steps now route notifications through SNS instead of straight to SQS

The old instruction to point an `s3:ObjectCreated:*` notification at the SQS queue ARN is replaced by two routes: a CloudTrail trail already publishing to the topic needs no extra configuration, otherwise the S3 notification targets the `CloudTrailSnsArn` topic.
Control Tower BYOB buckets must set Object Ownership to Bucket owner enforced

A new requirement section states that with ACLs enabled the logging account may not own the delivered objects, leaving Cortex XSIAM unable to read them even with correct IAM permissions.
Only one customer-managed KMS key per bucket is supported

A new warning notes the template accepts a single `CloudTrailKmsArn` and grants `kms:Decrypt` on that key alone, so objects encrypted under per-account keys will fail to decrypt.
Custom (BYOB) does not require an organization CloudTrail trail

A new FAQ states any trail scope is supported provided every trail delivers to the single named S3 bucket, its notifications reach the single named SNS topic, the stack is in the same region, and at most one customer-managed key is used.

Changes

10 files listed, 9 written up and shaded below.

▸ AWS resource inventory modified +2 −2

xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/aws-resource-inventory

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -44,21 +44,21 @@ In both cases, the AWS Organization management account also receives Cortex XSIA

## Scanning and automation resources

For organization and OU scopes, the CortexPlatformRole, the CortexPlatformScannerRole, and all selected capability policies are propagated to every member account using the member account StackSet. The onboarding helper function, handshake resource, and audit log resources are created only in the management account.


Resource type	Resource name	Purpose	Relevant security capabilities
AWS::IAM::Role	CortexPlatformScannerRole	IAM role for scanner operations. Attached managed policy: ReadOnlyAccess. Trust policy allows scanner identity ARNs populated dynamically from outpost resources data.	Any of the following: DSPM, serverless scanning, registry scanning
AWS::IAM::ManagedPolicy	Cortex-DISCOVERY-Policy	Managed policy attached to CortexPlatformRole. Grants read access to additional AWS services not covered by ReadOnlyAccess.	Always included
AWS::IAM::ManagedPolicy	Cortex-ADS-Policy	Managed policy Cortex-ADS-Policy attached to CortexPlatformRole. Grants EC2 snapshot operations plus KMS support. Write actions are gated by the managed_by: paloaltonetworks tag condition.	Agentless disk scanning
AWS::IAM::ManagedPolicy	Cortex-DSPM-Policy	Managed policy Cortex-DSPM-Policy attached to CortexPlatformRole. Grants permissions for data classification and sensitive-data discovery. Includes a scoped iam:PassRole to rds.amazonaws.com for snapshot-export workflows. Adds export.rds.amazonaws.com as a trusted service on the role's trust policy, and creates an inline policy Cortex-DSPM-Scanner-Policy on CortexPlatformScannerRole.	DSPM
Inline policy	Cortex-DSPM-Scanner-Policy	Inline policy on CortexPlatformScannerRole. Grants the permissions that actually read customer data for sensitive data classification.	DSPM
AWS::IAM::ManagedPolicy	Cortex-Automation-Policy	Managed policy Cortex-Automation-Policy attached to CortexPlatformRole. Grants permissions across a broad range of AWS services for automated remediation, active response, and enrichment. Statements are scoped by action; resources are *.	Automation
AWS::IAM::ManagedPolicy	Cortex-K8s-Security-Policy	Managed policy Cortex-K8s-Security-Policy attached to CortexPlatformRole. Grants scoped EKS access-entry management, all conditioned on the managed_by: paloaltonetworks tag. Bound Kubernetes permission is the AWS-managed AmazonEKSAdminViewPolicy (read-only Kubernetes API access)	Kubernetes security
Inline policy	ECRAccessPolicy	Inline policy on CortexPlatformScannerRole. Grants three ECR actions (BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for container image pull.	Registry scanning
Inline policy	LAMBDAAccessPolicy	Inline policy on CortexPlatformScannerRole. Grants three Lambda read actions (GetFunction, GetFunctionConfiguration, GetLayerVersion) for serverless code retrieval	Serverless scanning


Resource type	Resource name	Purpose	Relevant security capabilities
AWS::IAM::Role	CortexPlatformScannerRole	IAM role for scanner operations. Attached managed policy: ReadOnlyAccess. Trust policy allows scanner identity ARNs populated dynamically from outpost resources data.	Any of the following: DSPM, serverless scanning, registry scanning
AWS::IAM::ManagedPolicy	Cortex-DISCOVERY-Policy	Managed policy attached to CortexPlatformRole. Grants read access to additional AWS services not covered by ReadOnlyAccess.	Always included
AWS::IAM::ManagedPolicy	Cortex-ADS-Policy	Managed policy Cortex-ADS-Policy attached to CortexPlatformRole. Grants EC2 snapshot operations plus KMS support. Write actions are gated by the managed_by: paloaltonetworks tag condition.	Agentless disk scanning
AWS::IAM::ManagedPolicy	Cortex-DSPM-Policy	Managed policy Cortex-DSPM-Policy attached to CortexPlatformRole. Grants permissions for data classification and sensitive-data discovery. Includes a scoped iam:PassRole to rds.amazonaws.com for snapshot-export workflows. Adds export.rds.amazonaws.com as a trusted service on the role's trust policy, and creates an inline policy Cortex-DSPM-Scanner-Policy on CortexPlatformScannerRole.	DSPM
Inline policy	Cortex-DSPM-Scanner-Policy	Inline policy on CortexPlatformScannerRole. Grants the permissions that actually read customer data for sensitive data classification.	DSPM
AWS::IAM::ManagedPolicy	Cortex-Automation-Policy	Managed policy Cortex-Automation-Policy attached to CortexPlatformRole. Grants permissions across a broad range of AWS services for automated remediation, active response, and enrichment. Statements are scoped by action; resources are *.	Automation
AWS::IAM::ManagedPolicy	Cortex-K8s-Security-Policy	Managed policy Cortex-K8s-Security-Policy attached to CortexPlatformRole. Grants scoped EKS access-entry management, all conditioned on the managed_by: paloaltonetworks tag. Bound Kubernetes permission is the AWS-managed AmazonEKSAdminViewPolicy (read-only Kubernetes API access)	Kubernetes security
Inline policy	ECRAccessPolicy	Inline policy on CortexPlatformScannerRole. Grants three ECR actions (BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for container image pull.	Registry scanning
Inline policy	LAMBDAAccessPolicy	Inline policy on CortexPlatformScannerRole. Grants three Lambda read actions (GetFunction, GetFunctionConfiguration, GetLayerVersion) for serverless code retrieval	Serverless scanning

## Log collection resources

The following resources are deployed in the onboarding account (the management account for organization or OU scope). Log collection resources are never propagated to member accounts via the StackSet. In automated log collection mode, Cortex XSIAM provisions the resources listed below. In custom (BYOB) log collection mode, only four resources are created: the SQS queue, SNS subscription to your existing topic, queue policy, and the CloudTrailReadRole.

### Automated log collection resources


Resource type	Resource name	Purpose
AWS::KMS::Key	CloudTrailKMSKey	Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey*, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: CloudTrailReadRole) decrypt the logs.
AWS::S3::Bucket	CloudTrailLogsBucket	S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy
AWS::S3::BucketPolicy	CloudTrailLogsBucketPolicy	Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account.
AWS::SQS::Queue	CloudTrailLogsQueue	SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files.
AWS::SNS::Topic	CloudTrailSNSTopic	SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue.
AWS::SNS::TopicPolicy	CloudTrailSNSTopicPolicy	Enables the CloudTrail service to publish notifications to the SNS topic.
AWS::SNS::Subscription	CloudTrailSNSTopicSubscription	Subscribes the SQS queue to the SNS topic for message delivery.
AWS::SQS::QueuePolicy	SNSPolicy	Enables the SNS topic to send messages to the SQS queue.
AWS::IAM::Role	CloudTrailReadRole	Enables Cortex XSIAM to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex XSIAM's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt.
AWS::IAM::Role	EmptyBucketLambdaExecutionRole	Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket.
AWS::Lambda::Function	EmptyBucketLambda	Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal.
Custom::EmptyBucketDetails	EmptyBucketCustomResource	CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral). CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral).
AWS::CloudTrail::Trail	CloudTrail	Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation). Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true).


Resource type	Resource name	Purpose
AWS::KMS::Key	CloudTrailKMSKey	Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: `cortex-logs-ingestion-access-`) decrypt the logs.
AWS::S3::Bucket	CloudTrailLogsBucket	S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy
AWS::S3::BucketPolicy	CloudTrailLogsBucketPolicy	Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account.
AWS::SQS::Queue	CloudTrailLogsQueue	SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files.
AWS::SNS::Topic	CloudTrailSNSTopic	SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue.
AWS::SNS::TopicPolicy	CloudTrailSNSTopicPolicy	Enables the CloudTrail service to publish notifications to the SNS topic.
AWS::SNS::Subscription	CloudTrailSNSTopicSubscription	Subscribes the SQS queue to the SNS topic for message delivery.
AWS::SQS::QueuePolicy	SNSPolicy	Enables the SNS topic to send messages to the SQS queue.
AWS::IAM::Role	CloudTrailReadRole	Enables Cortex XSIAM to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex XSIAM's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt.
AWS::IAM::Role	EmptyBucketLambdaExecutionRole	Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket.
AWS::Lambda::Function	EmptyBucketLambda	Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal.
Custom::EmptyBucketDetails	EmptyBucketCustomResource	CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral). CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral).
AWS::CloudTrail::Trail	CloudTrail	Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation). Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true).

### Custom (BYOB) log collection

When custom (BYOB) log collection is configured, you provide the existing S3 bucket and CloudTrail trail in your account. Cortex XSIAM provisions the following four resources: CloudTrailReadRole (cortex-logs-ingestion-access), CloudTrail logs queue (cortex-ct-logs-queue-byob-<AccountId>), SNS-to-SQS subscription, and the Queue policy for the CloudTrail logs queue.

### Custom Control Tower (BYOB) log collection

Custom Control Tower (BYOB) audit log collection is designed for AWS organizations where CloudTrail is provisioned and managed through an AWS Control Tower landing zone. When Control Tower manages your organization's CloudTrail setup, it centralizes all audit logs in a dedicated logging account, a separate AWS account that Control Tower provisions specifically to store logs from across the organization. Because the S3 bucket resides in this logging account rather than in the management account and the SNS topic resides in a designated audt account, the standard custom (BYOB) log collection setup cannot subscribe to the SNS topic across account boundaries without additional configuration.

Show markdown source

@@ -44,21 +44,21 @@ In both cases, the AWS Organization management account also receives Cortex XSIA
 ## **Scanning and automation resources**
 
 For organization and OU scopes, the **CortexPlatformRole**, the **CortexPlatformScannerRole**, and all selected capability policies are propagated to every member account using the member account StackSet. The onboarding helper function, handshake resource, and audit log resources are created only in the management account.
 
 <table data-header-hidden><thead><tr><th></th><th></th><th width="260.28515625"></th><th></th></tr></thead><tbody><tr><td><strong>Resource type</strong></td><td><strong>Resource name</strong></td><td><strong>Purpose</strong></td><td><strong>Relevant security capabilities</strong></td></tr><tr><td><strong>AWS::IAM::Role</strong></td><td><strong>CortexPlatformScannerRole</strong></td><td>IAM role for scanner operations. Attached managed policy: <strong>ReadOnlyAccess</strong>. Trust policy allows scanner identity ARNs populated dynamically from outpost resources data.</td><td>Any of the following: DSPM, serverless scanning, registry scanning</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-DISCOVERY-Policy</strong></td><td>Managed policy attached to <strong>CortexPlatformRole</strong>. Grants read access to additional AWS services not covered by <strong>ReadOnlyAccess</strong>.</td><td>Always included</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-ADS-Policy</strong></td><td>Managed policy <strong>Cortex-ADS-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants EC2 snapshot operations plus KMS support. Write actions are gated by the <strong>managed_by: paloaltonetworks</strong> tag condition.</td><td>Agentless disk scanning</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-DSPM-Policy</strong></td><td>Managed policy <strong>Cortex-DSPM-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants permissions for data classification and sensitive-data discovery. Includes a scoped <strong>iam:PassRole</strong> to <strong>rds.amazonaws.com</strong> for snapshot-export workflows. Adds <strong>export.rds.amazonaws.com</strong> as a trusted service on the role's trust policy, and creates an inline policy <strong>Cortex-DSPM-Scanner-Policy</strong> on <strong>CortexPlatformScannerRole</strong>.</td><td>DSPM</td></tr><tr><td>Inline policy</td><td><strong>Cortex-DSPM-Scanner-Policy</strong></td><td>Inline policy on CortexPlatformScannerRole. Grants the permissions that actually read customer data for sensitive data classification.</td><td>DSPM</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-Automation-Policy</strong></td><td>Managed policy <strong>Cortex-Automation-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants permissions across a broad range of AWS services for automated remediation, active response, and enrichment. Statements are scoped by action; resources are *.</td><td>Automation</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-K8s-Security-Policy</strong></td><td>Managed policy <strong>Cortex-K8s-Security-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants scoped EKS access-entry management, all conditioned on the <strong>managed_by: paloaltonetworks</strong> tag. Bound Kubernetes permission is the AWS-managed <strong>AmazonEKSAdminViewPolicy</strong> (read-only Kubernetes API access)</td><td>Kubernetes security</td></tr><tr><td>Inline policy</td><td><strong>ECRAccessPolicy</strong></td><td>Inline policy on <strong>CortexPlatformScannerRole</strong>. Grants three ECR actions (BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for container image pull.</td><td>Registry scanning</td></tr><tr><td>Inline policy</td><td><strong>LAMBDAAccessPolicy</strong></td><td>Inline policy on <strong>CortexPlatformScannerRole</strong>. Grants three Lambda read actions (GetFunction, GetFunctionConfiguration, GetLayerVersion) for serverless code retrieval</td><td>Serverless scanning</td></tr></tbody></table>
 
 ## **Log collection resources**
 
-The following resources are deployed in the onboarding account (the management account for organization or OU scope). Log collection resources are never propagated to member accounts via the StackSet. In automated log collection mode, Cortex XSIAM provisions the resources listed below. In [custom (BYOB) log collection](#custom-byob-log-collection) mode, only four resources are created: the SQS queue, SNS subscription to your existing topic, queue policy, and the CloudTrailReadRole.
+The following resources are deployed in the onboarding account (the management account for organization or OU scope). Log collection resources are never propagated to member accounts via the StackSet. In automated log collection mode, Cortex XSIAM provisions the resources listed below. In [custom (BYOB) log collection](#custom-byob-log-collection) mode, only four resources are created: the SQS queue, SNS subscription to your existing topic, queue policy, and the `cortex-logs-ingestion-access-*` IAM role.
 
 ### Automated log collection resources
 
-<table data-header-hidden><thead><tr><th width="180.71875"></th><th width="213.359375"></th><th></th></tr></thead><tbody><tr><td><strong>Resource type</strong></td><td><strong>Resource name</strong></td><td><strong>Purpose</strong></td></tr><tr><td>AWS::KMS::Key</td><td><strong>CloudTrailKMSKey</strong></td><td>Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey*, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: CloudTrailReadRole) decrypt the logs.</td></tr><tr><td>AWS::S3::Bucket</td><td><strong>CloudTrailLogsBucket</strong></td><td>S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy</td></tr><tr><td>AWS::S3::BucketPolicy</td><td><strong>CloudTrailLogsBucketPolicy</strong></td><td>Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account.</td></tr><tr><td>AWS::SQS::Queue</td><td><strong>CloudTrailLogsQueue</strong></td><td>SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files.</td></tr><tr><td>AWS::SNS::Topic</td><td><strong>CloudTrailSNSTopic</strong></td><td>SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue.</td></tr><tr><td>AWS::SNS::TopicPolicy</td><td><strong>CloudTrailSNSTopicPolicy</strong></td><td>Enables the CloudTrail service to publish notifications to the SNS topic.</td></tr><tr><td>AWS::SNS::Subscription</td><td><strong>CloudTrailSNSTopicSubscription</strong></td><td>Subscribes the SQS queue to the SNS topic for message delivery.</td></tr><tr><td>AWS::SQS::QueuePolicy</td><td><strong>SNSPolicy</strong></td><td>Enables the SNS topic to send messages to the SQS queue.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>CloudTrailReadRole</strong></td><td>Enables Cortex XSIAM to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex XSIAM's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>EmptyBucketLambdaExecutionRole</strong></td><td>Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket.</td></tr><tr><td>AWS::Lambda::Function</td><td><strong>EmptyBucketLambda</strong></td><td>Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal.</td></tr><tr><td>Custom::EmptyBucketDetails</td><td><strong>EmptyBucketCustomResource</strong></td><td><p>CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral).</p><p>CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral).</p></td></tr><tr><td>AWS::CloudTrail::Trail</td><td><strong>CloudTrail</strong></td><td><p>Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation).</p><p>Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true).</p></td></tr></tbody></table>
+<table data-header-hidden><thead><tr><th width="180.71875"></th><th width="213.359375"></th><th></th></tr></thead><tbody><tr><td><strong>Resource type</strong></td><td><strong>Resource name</strong></td><td><strong>Purpose</strong></td></tr><tr><td>AWS::KMS::Key</td><td><strong>CloudTrailKMSKey</strong></td><td>Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey*, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: <code>cortex-logs-ingestion-access-*</code>) decrypt the logs.</td></tr><tr><td>AWS::S3::Bucket</td><td><strong>CloudTrailLogsBucket</strong></td><td>S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy</td></tr><tr><td>AWS::S3::BucketPolicy</td><td><strong>CloudTrailLogsBucketPolicy</strong></td><td>Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account.</td></tr><tr><td>AWS::SQS::Queue</td><td><strong>CloudTrailLogsQueue</strong></td><td>SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files.</td></tr><tr><td>AWS::SNS::Topic</td><td><strong>CloudTrailSNSTopic</strong></td><td>SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue.</td></tr><tr><td>AWS::SNS::TopicPolicy</td><td><strong>CloudTrailSNSTopicPolicy</strong></td><td>Enables the CloudTrail service to publish notifications to the SNS topic.</td></tr><tr><td>AWS::SNS::Subscription</td><td><strong>CloudTrailSNSTopicSubscription</strong></td><td>Subscribes the SQS queue to the SNS topic for message delivery.</td></tr><tr><td>AWS::SQS::QueuePolicy</td><td><strong>SNSPolicy</strong></td><td>Enables the SNS topic to send messages to the SQS queue.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>CloudTrailReadRole</strong></td><td>Enables Cortex XSIAM to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex XSIAM's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>EmptyBucketLambdaExecutionRole</strong></td><td>Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket.</td></tr><tr><td>AWS::Lambda::Function</td><td><strong>EmptyBucketLambda</strong></td><td>Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal.</td></tr><tr><td>Custom::EmptyBucketDetails</td><td><strong>EmptyBucketCustomResource</strong></td><td><p>CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral).</p><p>CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral).</p></td></tr><tr><td>AWS::CloudTrail::Trail</td><td><strong>CloudTrail</strong></td><td><p>Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation).</p><p>Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true).</p></td></tr></tbody></table>
 
 ### Custom (BYOB) log collection
 
 When custom (BYOB) log collection is configured, you provide the existing S3 bucket and CloudTrail trail in your account. Cortex XSIAM provisions the following four resources: CloudTrailReadRole (`cortex-logs-ingestion-access`), CloudTrail logs queue (`cortex-ct-logs-queue-byob-<AccountId>`), SNS-to-SQS subscription, and the Queue policy for the CloudTrail logs queue.
 
 ### Custom Control Tower (BYOB) log collection
 
 Custom Control Tower (BYOB) audit log collection is designed for AWS organizations where CloudTrail is provisioned and managed through an AWS Control Tower landing zone. When Control Tower manages your organization's CloudTrail setup, it centralizes all audit logs in a dedicated logging account, a separate AWS account that Control Tower provisions specifically to store logs from across the organization. Because the S3 bucket resides in this logging account rather than in the management account and the SNS topic resides in a designated audt account, the standard custom (BYOB) log collection setup cannot subscribe to the SNS topic across account boundaries without additional configuration.

▸ ▾ AWS security capabilities and deployment planning modified +20 −6 Renames the S3 reader role to cortex-logs-ingestion-access-* and adds a FAQ confirming Custom (BYOB) accepts any CloudTrail trail scope. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/aws-security-capabilities-and-deployment-planning

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -7,31 +7,45 @@ description: Plan AWS security capabilities for Cortex XSIAM cloud onboarding.

Plan your deployment by selecting the appropriate security capabilities. The onboarding process deploys all selected capabilities using a single CloudFormation template that adds specific functionality to your Cortex XSIAM integration.

Plan your deployment by selecting the appropriate security capabilities. The onboarding process deploys all selected capabilities using a single CloudFormation template that adds specific functionality to your Cortex XSIAM integration.

## Core capability (Discovery)

## Core capability (Discovery)

Discovery is a mandatory capability that is deployed automatically when you onboard an AWS account to Cortex XSIAM. Use this capability to discover and monitor AWS resources. When you onboard using a CloudFormation template, the template provisions the CortexPlatformRole AWS role along with a short-lived helper function that registers the deployment with Cortex XSIAM..

Discovery is a mandatory capability that is deployed automatically when you onboard an AWS account to Cortex XSIAM. Use this capability to discover and monitor AWS resources. When you onboard using a CloudFormation template, the template provisions the CortexPlatformRole AWS role along with a short-lived helper function that registers the deployment with Cortex XSIAM..

## Logging capabilities

## Logging capabilities

The Audit Logs capability collects AWS CloudTrail logs for security analysis and event-driven Asset Inventory. Across all collection modes, Cortex XSIAM provisions the CloudTrailReadRole IAM role to grant Cortex XSIAM read access to the target Amazon S3 bucket. Three collection modes are available depending on your AWS scope:

The Audit Logs capability collects AWS CloudTrail logs for security analysis and event-driven Asset Inventory. Across all collection modes, Cortex XSIAM provisions the cortex-logs-ingestion-access-* IAM role to grant Cortex XSIAM read access to the target Amazon S3 bucket. (For custom Control Tower deployments, this is the name specified in the CloudTrailReadRoleName parameter, which defaults to cortex-logs-ingestion-access-* and is editable.) Three collection modes are available depending on your AWS scope:

• Custom (BYOB) audit log collection: Designed for single-account setups or standard organizations where all resources reside in a single AWS account. Use your existing S3 bucket and CloudTrail trail. Cortex XSIAM provisions the notification pipeline (SQS queue and SNS topic) and connects to your bucket to ingest logs.

• Custom (BYOB) audit log collection: Designed for single-account setups or standard organizations where all resources reside in a single AWS account. Use your existing S3 bucket and CloudTrail trail. Cortex XSIAM provisions the notification pipeline (SQS queue and SNS topic) and connects to your bucket to ingest logs.

hint info

#### Does Custom (BYOB) require an organization CloudTrail trail?

No. Custom (BYOB) collection does not create or manage a CloudTrail trail because you bring your own. Cortex XSIAM has no requirement on the trail's scope: an organization trail, a multi-region trail, or multiple independent regional or per-account trails are all supported, provided that:

• Every trail you want ingested delivers its log files to the single S3 bucket you name in CloudTrailLogsBucket.

• That bucket's notification pipeline (either via CloudTrail's native SNS delivery notification or via an S3 event notification) sends new-object events to the single SNS topic you name in CloudTrailSnsArn.

• The stack is deployed in the same region as that SNS topic and bucket.

• All objects in that bucket are encrypted with at most one customer-managed KMS key (the one you supply as CloudTrailKmsArn), or with SSE-S3 / no encryption.

A common pattern for organization-scope connectors is to set up an organizational trail that delivers logs from all member accounts to a single central S3 bucket. For account-scope or organizational unit-scope connectors, per-account trails in each member account delivering to a central bucket are also supported. If your organization uses AWS Control Tower, use Custom Control Tower (BYOB) instead.

endhint

• Custom Control Tower (BYOB) audit log collection: Designed for AWS organizations governed by AWS Control Tower. Because Control Tower centralizes log storage by placing the S3 bucket in a dedicated logging account and the SNS topic in a dedicated Audit account, this deployment uses a multi-account architecture:

• Custom Control Tower (BYOB) audit log collection: Designed for AWS organizations governed by AWS Control Tower. Because Control Tower centralizes log storage by placing the S3 bucket in a dedicated logging account and the SNS topic in a dedicated Audit account, this deployment uses a multi-account architecture:

• IAM role deployment: Provisioned in the log archive account.

• IAM role deployment: Provisioned in the log archive account.

• SQS queue deployment: Provisioned in the account holding the SNS topic to enable local event subscription and message queuing.

• SQS queue deployment: Provisioned in the account holding the SNS topic to enable local event subscription and message queuing.

• Cortex automated log collection: Cortex XSIAM provisions and manages all required AWS resources (S3 bucket, CloudTrail trail, encryption, and notifications) on your behalf.

• Cortex automated log collection: Cortex XSIAM provisions and manages all required AWS resources (S3 bucket, CloudTrail trail, encryption, and notifications) on your behalf.

In all modes, the supporting infrastructure is deployed in a single AWS region - the region where you launch onboarding. The CloudTrail trail itself is multi-region and captures events from all AWS regions. For Custom (BYOB) mode, regional coverage matches your existing trail's configuration. For full details on deployment modes, ingestion flow, and data security, see Audit Log Collection Architecture.

In all modes, the supporting infrastructure is deployed in a single AWS region - the region where you launch onboarding. The CloudTrail trail itself is multi-region and captures events from all AWS regions. For Custom (BYOB) mode, regional coverage matches your existing trail's configuration. For full details on deployment modes, ingestion flow, and data security, see Audit Log Collection Architecture.

Collection mode│Resources created│Purpose

Collection mode│Resources created│Purpose

| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Custom (BYOB)│SQS Queue, SNS Subscription, SQS Queue Policy│Connect to a customer-managed S3 bucket and CloudTrail trail.

Event notifications flow through customer-owned SQS/SNS resources.

Custom (BYOB)│SQS Queue, SNS Subscription, SQS Queue Policy│Connect to a customer-managed S3 bucket and CloudTrail trail.

Event notifications flow through customer-owned SQS/SNS resources.

Custom Control Tower (BYOB)│SQS Queue, SNS Subscription, SQS Queue Policy, IAM Role (cortex-logs-ingestion-access-<resource>-<suffix>, deployed into the Log Archive account via StackSet)│Connect to the centralized S3 bucket managed by AWS Control Tower in the logging account. The IAM role is deployed cross-account into the logging account; the SQS queue is created in the management account where the Control Tower SNS topic resides.

Custom Control Tower (BYOB)│SQS Queue, SNS Subscription, SQS Queue Policy, IAM Role (cortex-logs-ingestion-access-*, deployed into the Log Archive account via StackSet)│Connect to the centralized S3 bucket managed by AWS Control Tower in the logging account. The IAM role is deployed cross-account into the logging account; the SQS queue is created in the management account where the Control Tower SNS topic resides.

Automated│S3 Bucket, S3 Bucket Policy, KMS Key, CloudTrail Trail, SNS Topic, SNS Topic Policy, SNS Subscription, SQS Queue, SQS Queue Policy, Lambda Function│Cortex XSIAM provisions the S3 bucket, CloudTrail trail, and encryption key, then collects CloudTrail logs automatically.

Automated│S3 Bucket, S3 Bucket Policy, KMS Key, CloudTrail Trail, SNS Topic, SNS Topic Policy, SNS Subscription, SQS Queue, SQS Queue Policy, Lambda Function│Cortex XSIAM provisions the S3 bucket, CloudTrail trail, and encryption key, then collects CloudTrail logs automatically.

## Scanning capabilities

## Scanning capabilities

The following table details the scanning capabilities available during cloud onboarding. The table specifies the IAM roles and resources created and the purpose of each capability. Use this reference to understand the infrastructure footprint and coverage of each scanning capability deployed by Cortex XSIAM. All scanning capabilities operate across all AWS regions in the onboarded account.

The following table details the scanning capabilities available during cloud onboarding. The table specifies the IAM roles and resources created and the purpose of each capability. Use this reference to understand the infrastructure footprint and coverage of each scanning capability deployed by Cortex XSIAM. All scanning capabilities operate across all AWS regions in the onboarded account.

Capability│Purpose│Resources created

Capability│Purpose│Resources created

| ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Agentless Disk Scanning (ADS)│Agentless disk scanning for vulnerabilities.│Custom managed policy Cortex-ADS-Policy added to CortexPlatformRole

Agentless Disk Scanning (ADS)│Agentless disk scanning for vulnerabilities.│Custom managed policy Cortex-ADS-Policy added to CortexPlatformRole
Show markdown source
```
@@ -7,31 +7,45 @@ description: Plan AWS security capabilities for Cortex XSIAM cloud onboarding.
 Plan your deployment by selecting the appropriate security capabilities. The onboarding process deploys all selected capabilities using a single CloudFormation template that adds specific functionality to your Cortex XSIAM integration.
 
 ## Core capability (Discovery)
 
 Discovery is a mandatory capability that is deployed automatically when you onboard an AWS account to Cortex XSIAM. Use this capability to discover and monitor AWS resources. When you onboard using a CloudFormation template, the template provisions the CortexPlatformRole AWS role along with a short-lived helper function that registers the deployment with Cortex XSIAM..
 
 ## Logging capabilities
 
-The Audit Logs capability collects AWS CloudTrail logs for security analysis and event-driven Asset Inventory. Across all collection modes, Cortex XSIAM provisions the `CloudTrailReadRole` IAM role to grant Cortex XSIAM read access to the target Amazon S3 bucket. Three collection modes are available depending on your AWS scope:
+The Audit Logs capability collects AWS CloudTrail logs for security analysis and event-driven Asset Inventory. Across all collection modes, Cortex XSIAM provisions the `cortex-logs-ingestion-access-*` IAM role to grant Cortex XSIAM read access to the target Amazon S3 bucket. (For custom Control Tower deployments, this is the name specified in the `CloudTrailReadRoleName` parameter, which defaults to `cortex-logs-ingestion-access-*` and is editable.) Three collection modes are available depending on your AWS scope:
 
 * Custom (BYOB) audit log collection: Designed for single-account setups or standard organizations where all resources reside in a single AWS account. Use your existing S3 bucket and CloudTrail trail. Cortex XSIAM provisions the notification pipeline (SQS queue and SNS topic) and connects to your bucket to ingest logs.
+
+{% hint style="info" %}
+#### **Does Custom (BYOB) require an organization CloudTrail trail?**
+
+No. Custom (BYOB) collection does not create or manage a CloudTrail trail because you bring your own. Cortex XSIAM has no requirement on the trail's scope: an organization trail, a multi-region trail, or multiple independent regional or per-account trails are all supported, provided that:
+
+* Every trail you want ingested delivers its log files to the single S3 bucket you name in `CloudTrailLogsBucket`.
+* That bucket's notification pipeline (either via CloudTrail's native SNS delivery notification or via an S3 event notification) sends new-object events to the single SNS topic you name in `CloudTrailSnsArn`.
+* The stack is deployed in the same region as that SNS topic and bucket.
+* All objects in that bucket are encrypted with at most one customer-managed KMS key (the one you supply as `CloudTrailKmsArn`), or with SSE-S3 / no encryption.
+
+A common pattern for organization-scope connectors is to set up an organizational trail that delivers logs from all member accounts to a single central S3 bucket. For account-scope or organizational unit-scope connectors, per-account trails in each member account delivering to a central bucket are also supported. If your organization uses AWS Control Tower, use Custom Control Tower (BYOB) instead.
+{% endhint %}
+
 * Custom Control Tower (BYOB) audit log collection: Designed for AWS organizations governed by AWS Control Tower. Because Control Tower centralizes log storage by placing the S3 bucket in a dedicated logging account and the SNS topic in a dedicated Audit account, this deployment uses a multi-account architecture:
   * IAM role deployment: Provisioned in the log archive account.
   * SQS queue deployment: Provisioned in the account holding the SNS topic to enable local event subscription and message queuing.
 * Cortex automated log collection: Cortex XSIAM provisions and manages all required AWS resources (S3 bucket, CloudTrail trail, encryption, and notifications) on your behalf.
 
 In all modes, the supporting infrastructure is deployed in a single AWS region - the region where you launch onboarding. The CloudTrail trail itself is multi-region and captures events from all AWS regions. For Custom (BYOB) mode, regional coverage matches your existing trail's configuration. For full details on deployment modes, ingestion flow, and data security, see Audit Log Collection Architecture.
 
-| Collection mode             | Resources created                                                                                                                                                | Purpose                                                                                                                                                                                                                                                  |
-| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Custom (BYOB)               | SQS Queue, SNS Subscription, SQS Queue Policy                                                                                                                    | <p>Connect to a customer-managed S3 bucket and CloudTrail trail.</p><p>Event notifications flow through customer-owned SQS/SNS resources.</p>                                                                                                            |
-| Custom Control Tower (BYOB) | SQS Queue, SNS Subscription, SQS Queue Policy, IAM Role (`cortex-logs-ingestion-access-<resource>-<suffix>`, deployed into the Log Archive account via StackSet) | Connect to the centralized S3 bucket managed by AWS Control Tower in the logging account. The IAM role is deployed cross-account into the logging account; the SQS queue is created in the management account where the Control Tower SNS topic resides. |
-| Automated                   | S3 Bucket, S3 Bucket Policy, KMS Key, CloudTrail Trail, SNS Topic, SNS Topic Policy, SNS Subscription, SQS Queue, SQS Queue Policy, Lambda Function              | Cortex XSIAM provisions the S3 bucket, CloudTrail trail, and encryption key, then collects CloudTrail logs automatically.                                                                                                                                |
+| Collection mode             | Resources created                                                                                                                                   | Purpose                                                                                                                                                                                                                                                  |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Custom (BYOB)               | SQS Queue, SNS Subscription, SQS Queue Policy                                                                                                       | <p>Connect to a customer-managed S3 bucket and CloudTrail trail.</p><p>Event notifications flow through customer-owned SQS/SNS resources.</p>                                                                                                            |
+| Custom Control Tower (BYOB) | SQS Queue, SNS Subscription, SQS Queue Policy, IAM Role (`cortex-logs-ingestion-access-*`, deployed into the Log Archive account via StackSet)      | Connect to the centralized S3 bucket managed by AWS Control Tower in the logging account. The IAM role is deployed cross-account into the logging account; the SQS queue is created in the management account where the Control Tower SNS topic resides. |
+| Automated                   | S3 Bucket, S3 Bucket Policy, KMS Key, CloudTrail Trail, SNS Topic, SNS Topic Policy, SNS Subscription, SQS Queue, SQS Queue Policy, Lambda Function | Cortex XSIAM provisions the S3 bucket, CloudTrail trail, and encryption key, then collects CloudTrail logs automatically.                                                                                                                                |
 
 ## Scanning capabilities
 
 The following table details the scanning capabilities available during cloud onboarding. The table specifies the IAM roles and resources created and the purpose of each capability. Use this reference to understand the infrastructure footprint and coverage of each scanning capability deployed by Cortex XSIAM. All scanning capabilities operate across all AWS regions in the onboarded account.
 
 | Capability                           | Purpose                                                  | Resources created                                                                                                                                                                                                                        |
 | ------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Agentless Disk Scanning (ADS)        | Agentless disk scanning for vulnerabilities.             | Custom managed policy **Cortex-ADS-Policy** added to **CortexPlatformRole**                                                                                                                                                              |
```
▸ ▾ AWS security model and authentication modified +1 −1 The audit log collection row of the capability-to-role table now names cortex-logs-ingestion-access-* instead of CloudTrailReadRole. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/aws-security-model-and-authentication

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -23,9 +23,9 @@ Cortex XSIAM eliminates the risk of leaked credentials by strictly avoiding stat

The following table maps each capability to the customer-side IAM role and the Cortex-side identity used for authentication:

The following table maps each capability to the customer-side IAM role and the Cortex-side identity used for authentication:

Capability│Customer account IAM role assumed│Cortex XSIAM principal that assumes the role

Capability│Customer account IAM role assumed│Cortex XSIAM principal that assumes the role

| ------------------------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |

| ------------------------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |

Discovery, ADS, Kubernetes Security, Automation, DSPM (platform-level actions)│CortexPlatformRole│role/gcp_saas_role

Discovery, ADS, Kubernetes Security, Automation, DSPM (platform-level actions)│CortexPlatformRole│role/gcp_saas_role

DSPM (data scanning)│CortexPlatformScannerRole│role/dspm_scanner

DSPM (data scanning)│CortexPlatformScannerRole│role/dspm_scanner

Registry scanning│CortexPlatformScannerRole│role/registry_scanner

Registry scanning│CortexPlatformScannerRole│role/registry_scanner

Serverless scanning│CortexPlatformScannerRole│role/scanner_of_serverless

Serverless scanning│CortexPlatformScannerRole│role/scanner_of_serverless

Audit log collection│CloudTrailReadRole│Cortex XSIAM log collector (via Google OIDC: accounts.google.com with a specific audience and Google service-account ID)

Audit log collection│cortex-logs-ingestion-access-*│Cortex XSIAM log collector (via Google OIDC: accounts.google.com with a specific audience and Google service-account ID)
Show markdown source
```
@@ -23,9 +23,9 @@ Cortex XSIAM eliminates the risk of leaked credentials by strictly avoiding stat
 The following table maps each capability to the customer-side IAM role and the Cortex-side identity used for authentication:<br>
 
 | Capability                                                                     | Customer account IAM role assumed | Cortex XSIAM principal that assumes the role                                                                             |
 | ------------------------------------------------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
 | Discovery, ADS, Kubernetes Security, Automation, DSPM (platform-level actions) | CortexPlatformRole                | role/gcp\_saas\_role                                                                                                     |
 | DSPM (data scanning)                                                           | CortexPlatformScannerRole         | role/dspm\_scanner                                                                                                       |
 | Registry scanning                                                              | CortexPlatformScannerRole         | role/registry\_scanner                                                                                                   |
 | Serverless scanning                                                            | CortexPlatformScannerRole         | role/scanner\_of\_serverless                                                                                             |
-| Audit log collection                                                           | CloudTrailReadRole                | Cortex XSIAM log collector (via Google OIDC: accounts.google.com with a specific audience and Google service-account ID) |
+| Audit log collection                                                           | `cortex-logs-ingestion-access-*`  | Cortex XSIAM log collector (via Google OIDC: accounts.google.com with a specific audience and Google service-account ID) |
```

▸ Cortex XSIAM and AWS audit log collection architecture modified +20 −6 Adds the Bucket owner enforced object ownership requirement for Control Tower BYOB and a warning that only one customer-managed KMS key per bucket is supported.

xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/cortex-cloud-and-aws-audit-log-collection-architecture

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -26,29 +26,43 @@ The following stages describe the event-driven ingestion flow for CloudTrail log

8. Cortex forwards the processed logs to your dedicated Cortex single tenant (GCS bucket).

9. Cortex deletes the processed SQS message using sqs:DeleteMessage.

10. The Cortex XSIAM instance processes the logs for security analysis.

### Data security for audit logs

In automated log collection mode, CloudTrail logs are retained in the S3 bucket for seven days (per the bucket's lifecycle expiration rule), and then automatically deleted. In custom (BYOB) and custom Control Tower log collection mode, you manage the S3 bucket lifecycle and retention. In all modes, forwarded log files are stored in your dedicated single-tenant Cortex XSIAM log storage bucket. CloudTrail log files at rest in the customer's S3 bucket are encrypted using the CloudTrail logs CMK (a customer-managed KMS key in your AWS account).

#### S3 Object Ownership requirement (Custom Control Tower

For Custom Control Tower (BYOB) log collection, the S3 bucket storing the CloudTrail log files must have Object Ownership set to Bucket owner enforced (ACLs disabled). This ensures the logging account owns all uploaded log objects, which is required for the s3:GetObject permission on the cortex-logs-ingestion-access-* IAM role to take effect.

Without the correct object ownership setting, log files uploaded to the centralized logging bucket may not be owned by the bucket owner account, which would result in Cortex XSIAM being unable to read them even with the correct IAM permissions configured.

Verify that your Control Tower Log Archive S3 bucket has Object Ownership → Bucket owner enforced enabled before deploying the Cortex XSIAM stack. For more information, see Controlling ownership of objects and disabling ACLs for your bucket in the AWS documentation.

### Key Management Service (KMS) considerations

CloudTrail log files are encrypted at rest in the customer's S3 bucket. How the KMS key is provisioned depends on the deployment mode:

Aspect│Automated log collection│Custom (BYOB) log collection│Custom Control Tower log collection

| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

KMS key creation│Cortex XSIAM creates a new Customer Managed Key (CMK) via CloudFormation.│No KMS key is created. The customer supplies the optional CloudTrailKmsArn parameter at deployment time.│No KMS key is created. The customer supplies the optional CloudTrailKmsArn parameter at deployment time.

Key policy│The Cortex XSIAM-created CMK uses the standard account-root key policy, which delegates access management to IAM. The CloudTrailReadRole role's inline IAM policy (provisioned by the same template) grants kms:Decrypt on the CMK, so no customer key-policy edits are required.│The customer's KMS key policy must explicitly allow the CloudTrailReadRole role to perform kms:Decrypt.│The KMS key used by Control Tower resides in the management account, while the Cortex IAM role is deployed into the logging account. Because the key and the role are in different accounts, the KMS key policy in the management account must explicitly allow the CloudTrailReadRole role (in the logging account) to perform kms:Decrypt. See Grant cross-account KMS key access.

Key policy│The Cortex XSIAM-created CMK uses the standard account-root key policy, which delegates access management to IAM. The CloudTrailReadRole role's inline IAM policy (provisioned by the same template) grants kms:Decrypt on the CMK, so no customer key-policy edits are required.│The customer's KMS key policy must explicitly allow the cortex-logs-ingestion-access-* role to perform kms:Decrypt.│The KMS key used by Control Tower resides in the management account, while the Cortex IAM role is deployed into the logging account. Because the key and the role are in different accounts, the KMS key policy in the management account must explicitly allow the cortex-logs-ingestion-access-* role (in the logging account) to perform kms:Decrypt. See Grant cross-account KMS key access.

Role permission│The audit log reader role inline policy includes kms:Decrypt on the Cortex XSIAM-created CMK.│If CloudTrailKmsArn is provided, the role inline policy includes kms:Decrypt scoped to that ARN. If left empty, the kms:Decrypt statement is omitted entirely.│If CloudTrailKmsArn is provided, the role inline policy includes kms:Decrypt scoped to that ARN. If left empty, the kms:Decrypt statement is omitted entirely.

Unencrypted/SSE-S3 buckets│Not applicable (Cortex XSIAM always creates an encrypted bucket).│If the bucket uses SSE-S3 or no encryption, leave the CloudTrailKmsArn parameter empty.│If the bucket uses SSE-S3 or no encryption, leave the CloudTrailKmsArn parameter empty.

You must use a customer-managed KMS key (CMK), not an AWS-managed or AWS-owned key. CloudTrail requires a symmetric CMK for trail encryption, and the audit log reader role must be granted kms:Decrypt through the key policy, which is only configurable on customer-managed keys.

hint warning

#### One KMS key per bucket

The template accepts a single CloudTrailKmsArn and grants kms:Decrypt on that one key. If the objects in your bucket are encrypted under more than one customer-managed key (for example, each source account encrypts with its own key before delivery), Cortex XSIAM will fail to decrypt the objects protected by the keys you did not specify. Ensure the destination bucket re-encrypts all delivered objects under a single bucket-level CMK, or uses SSE-S3 (in which case leave CloudTrailKmsArn empty).

endhint

hint info

#### Note: Custom Control Tower (BYOB) log collection with KMS encryption

If you provide a CloudTrailKmsArn and the KMS key resides in a different account than the Log Archive account, a manual step is required. The Cortex CloudFormation template automatically grants kms:Decrypt to the cortex-logs-ingestion-access-<resource-suffix> role on the IAM side, but AWS also requires the KMS key resource policy to explicitly allow access from the Log Archive account. You must manually add this statement to the KMS key policy to complete the cross-account handshake. For the full procedure, see grant-cross-account-kms-key-access-for-control-tower-byob-log-collection.

endhint

### The bucket cleanup function lifecycle

Show markdown source

@@ -26,29 +26,43 @@ The following stages describe the event-driven ingestion flow for CloudTrail log
 8. Cortex forwards the processed logs to your dedicated Cortex single tenant (GCS bucket).
 9. Cortex deletes the processed SQS message using **sqs:DeleteMessage**.
 10. The Cortex XSIAM instance processes the logs for security analysis.
 
 ### **Data security for audit logs**
 
 In automated log collection mode, CloudTrail logs are retained in the S3 bucket for seven days (per the bucket's lifecycle expiration rule), and then automatically deleted. In custom (BYOB) and custom Control Tower log collection mode, you manage the S3 bucket lifecycle and retention. In all modes, forwarded log files are stored in your dedicated single-tenant Cortex XSIAM log storage bucket. CloudTrail log files at rest in the customer's S3 bucket are encrypted using the CloudTrail logs CMK (a customer-managed KMS key in your AWS account).
 
+#### S3 Object Ownership requirement (Custom Control Tower
+
+For Custom Control Tower (BYOB) log collection, the S3 bucket storing the CloudTrail log files must have **Object Ownership** set to **Bucket owner enforced** (ACLs disabled). This ensures the logging account owns all uploaded log objects, which is required for the `s3:GetObject` permission on the `cortex-logs-ingestion-access-*` IAM role to take effect.
+
+Without the correct object ownership setting, log files uploaded to the centralized logging bucket may not be owned by the bucket owner account, which would result in Cortex XSIAM being unable to read them even with the correct IAM permissions configured.
+
+Verify that your Control Tower Log Archive S3 bucket has **Object Ownership → Bucket owner enforced** enabled before deploying the Cortex XSIAM stack. For more information, see [Controlling ownership of objects and disabling ACLs for your bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) in the AWS documentation.
+
 ### **Key Management Service (KMS) considerations**
 
 CloudTrail log files are encrypted at rest in the customer's S3 bucket. How the KMS key is provisioned depends on the deployment mode:
 
-| Aspect                     | Automated log collection                                                                                                                                                                                                                                                              | Custom (BYOB) log collection                                                                                                                                         | Custom Control Tower log collection                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| KMS key creation           | Cortex XSIAM creates a new Customer Managed Key (CMK) via CloudFormation.                                                                                                                                                                                                             | No KMS key is created. The customer supplies the optional `CloudTrailKmsArn` parameter at deployment time.                                                           | No KMS key is created. The customer supplies the optional `CloudTrailKmsArn` parameter at deployment time.                                                                                                                                                                                                                                                                                                                                                           |
-| Key policy                 | The Cortex XSIAM-created CMK uses the standard account-root key policy, which delegates access management to IAM. The `CloudTrailReadRole` role's inline IAM policy (provisioned by the same template) grants `kms:Decrypt` on the CMK, so no customer key-policy edits are required. | The customer's KMS key policy must explicitly allow the `CloudTrailReadRole` role to perform `kms:Decrypt`.                                                          | The KMS key used by Control Tower resides in the management account, while the Cortex IAM role is deployed into the logging account. Because the key and the role are in different accounts, the KMS key policy in the management account must explicitly allow the `CloudTrailReadRole` role (in the logging account) to perform `kms:Decrypt`. See [Grant cross-account KMS key access](grant-cross-account-kms-key-access-for-control-tower-byob-log-collection). |
-| Role permission            | The audit log reader role inline policy includes `kms:Decrypt` on the Cortex XSIAM-created CMK.                                                                                                                                                                                       | If `CloudTrailKmsArn` is provided, the role inline policy includes `kms:Decrypt` scoped to that ARN. If left empty, the `kms:Decrypt` statement is omitted entirely. | If `CloudTrailKmsArn` is provided, the role inline policy includes `kms:Decrypt` scoped to that ARN. If left empty, the `kms:Decrypt` statement is omitted entirely.                                                                                                                                                                                                                                                                                                 |
-| Unencrypted/SSE-S3 buckets | Not applicable (Cortex XSIAM always creates an encrypted bucket).                                                                                                                                                                                                                     | If the bucket uses SSE-S3 or no encryption, leave the `CloudTrailKmsArn` parameter empty.                                                                            | If the bucket uses SSE-S3 or no encryption, leave the `CloudTrailKmsArn` parameter empty.                                                                                                                                                                                                                                                                                                                                                                            |
+| Aspect                     | Automated log collection                                                                                                                                                                                                                                                              | Custom (BYOB) log collection                                                                                                                                         | Custom Control Tower log collection                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| KMS key creation           | Cortex XSIAM creates a new Customer Managed Key (CMK) via CloudFormation.                                                                                                                                                                                                             | No KMS key is created. The customer supplies the optional `CloudTrailKmsArn` parameter at deployment time.                                                           | No KMS key is created. The customer supplies the optional `CloudTrailKmsArn` parameter at deployment time.                                                                                                                                                                                                                                                                                                                                                                       |
+| Key policy                 | The Cortex XSIAM-created CMK uses the standard account-root key policy, which delegates access management to IAM. The `CloudTrailReadRole` role's inline IAM policy (provisioned by the same template) grants `kms:Decrypt` on the CMK, so no customer key-policy edits are required. | The customer's KMS key policy must explicitly allow the `cortex-logs-ingestion-access-*` role to perform `kms:Decrypt`.                                              | The KMS key used by Control Tower resides in the management account, while the Cortex IAM role is deployed into the logging account. Because the key and the role are in different accounts, the KMS key policy in the management account must explicitly allow the `cortex-logs-ingestion-access-*` role (in the logging account) to perform `kms:Decrypt`. See [Grant cross-account KMS key access](grant-cross-account-kms-key-access-for-control-tower-byob-log-collection). |
+| Role permission            | The audit log reader role inline policy includes `kms:Decrypt` on the Cortex XSIAM-created CMK.                                                                                                                                                                                       | If `CloudTrailKmsArn` is provided, the role inline policy includes `kms:Decrypt` scoped to that ARN. If left empty, the `kms:Decrypt` statement is omitted entirely. | If `CloudTrailKmsArn` is provided, the role inline policy includes `kms:Decrypt` scoped to that ARN. If left empty, the `kms:Decrypt` statement is omitted entirely.                                                                                                                                                                                                                                                                                                             |
+| Unencrypted/SSE-S3 buckets | Not applicable (Cortex XSIAM always creates an encrypted bucket).                                                                                                                                                                                                                     | If the bucket uses SSE-S3 or no encryption, leave the `CloudTrailKmsArn` parameter empty.                                                                            | If the bucket uses SSE-S3 or no encryption, leave the `CloudTrailKmsArn` parameter empty.                                                                                                                                                                                                                                                                                                                                                                                        |
 
 You must use a customer-managed KMS key (CMK), not an AWS-managed or AWS-owned key. CloudTrail requires a symmetric CMK for trail encryption, and the audit log reader role must be granted kms:Decrypt through the key policy, which is only configurable on customer-managed keys.
 
+{% hint style="warning" %}
+#### **One KMS key per bucket**
+
+The template accepts a single `CloudTrailKmsArn` and grants `kms:Decrypt` on that one key. If the objects in your bucket are encrypted under more than one customer-managed key (for example, each source account encrypts with its own key before delivery), Cortex XSIAM will fail to decrypt the objects protected by the keys you did not specify. Ensure the destination bucket re-encrypts all delivered objects under a single bucket-level CMK, or uses SSE-S3 (in which case leave `CloudTrailKmsArn` empty).
+{% endhint %}
+
 {% hint style="info" %}
 #### Note: Custom Control Tower (BYOB) log collection with KMS encryption
 
 If you provide a `CloudTrailKmsArn` and the KMS key resides in a different account than the Log Archive account, a manual step is required. The Cortex CloudFormation template automatically grants `kms:Decrypt` to the `cortex-logs-ingestion-access-<resource-suffix>` role on the IAM side, but AWS also requires the KMS key resource policy to explicitly allow access from the Log Archive account. You must manually add this statement to the KMS key policy to complete the cross-account handshake. For the full procedure, see [grant-cross-account-kms-key-access-for-control-tower-byob-log-collection](grant-cross-account-kms-key-access-for-control-tower-byob-log-collection "mention").
 {% endhint %}
 
 ### **The bucket cleanup function lifecycle**

▸ ▾ Grant cross-account KMS key access for Control Tower BYOB log collection modified +5 −5 The key policy snippet and the value to look up in the stack Outputs tab both switch to the new role name. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/grant-cross-account-kms-key-access-for-control-tower-byob-log-collection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -6,52 +6,52 @@ description: >-

---

---

# Grant cross-account KMS key access for Control Tower BYOB log collection

# Grant cross-account KMS key access for Control Tower BYOB log collection

This procedure is required if you are using custom Control Tower (BYOB) log collection and you choose to encrypt your logs with a KMS key.

This procedure is required if you are using custom Control Tower (BYOB) log collection and you choose to encrypt your logs with a KMS key.

When a KMS key and the accessing IAM role reside in different AWS accounts, AWS requires a two-way trust handshake to authorize access:

When a KMS key and the accessing IAM role reside in different AWS accounts, AWS requires a two-way trust handshake to authorize access:

• IAM side (Automated): The Cortex XSIAM CloudFormation template automatically attaches kms:Decrypt permissions for your specified key ARN to the CloudTrailReadRole role in the Log Archive account.

• IAM side (Automated): The Cortex XSIAM CloudFormation template automatically attaches kms:Decrypt permissions for your specified key ARN to the cortex-logs-ingestion-access-* role in the Log Archive account.

• KMS key policy side (Manual): You must update the KMS key's resource policy to explicitly trust and allow the Cortex XSIAM IAM role in the Log Archive account to perform the kms:Decrypt action.

• KMS key policy side (Manual): You must update the KMS key's resource policy to explicitly trust and allow the Cortex XSIAM IAM role in the Log Archive account to perform the kms:Decrypt action.

hint info

hint info

#### Prerequisites

#### Prerequisites

Before you begin, retrieve and note the following values:

Before you begin, retrieve and note the following values:

• Logging account ID: The 12-digit AWS account ID of your logging account where the Cortex IAM role is deployed.

• Logging account ID: The 12-digit AWS account ID of your logging account where the Cortex IAM role is deployed.

• Cortex role name: The exact name of the IAM role created by the Cortex XSIAM CloudFormation template in the Log Archive account (e.g., CloudTrailReadRole). You can retrieve this from the Outputs tab of the deployed CloudFormation stack.

• Cortex role name: The exact name of the IAM role created by the Cortex XSIAM CloudFormation template in the Log Archive account (e.g., cortex-logs-ingestion-access-*). You can retrieve this from the Outputs tab of the deployed CloudFormation stack.

• KMS key ID or ARN: The identifier of the KMS key used to encrypt your Control Tower S3 bucket.

• KMS key ID or ARN: The identifier of the KMS key used to encrypt your Control Tower S3 bucket.

endhint

endhint

1. Sign in to the AWS Management Console of the Management account where the KMS key resides.

1. Sign in to the AWS Management Console of the Management account where the KMS key resides.

2. Navigate to Key Management Service (KMS) > Customer managed keys.

2. Navigate to Key Management Service (KMS) > Customer managed keys.

3. Select the KMS key used to encrypt your Control Tower S3 bucket.

3. Select the KMS key used to encrypt your Control Tower S3 bucket.

4. Select the Key policy tab, then click Edit.

4. Select the Key policy tab, then click Edit.

5. In the JSON editor, locate the closing bracket (]) of the Statement array.

5. In the JSON editor, locate the closing bracket (]) of the Statement array.

6. Append a comma (,) to the statement immediately preceding the closing bracket, then paste the following block:

6. Append a comma (,) to the statement immediately preceding the closing bracket, then paste the following block:

```json

```json

{

{

"Sid": "AllowCortexCrossAccountKmsDecrypt",

"Sid": "AllowCortexCrossAccountKmsDecrypt",

"Effect": "Allow",

"Effect": "Allow",

"Principal": {

"Principal": {

"AWS": "arn:aws:iam::<LOGGING_ACCOUNT_ID>:role/<CloudTrailReadRole>"

"AWS": "arn:aws:iam::<LOGGING_ACCOUNT_ID>:role/<cortex-logs-ingestion-access-*>"

},

},

"Action": "kms:Decrypt",

"Action": "kms:Decrypt",

"Resource": "*"

"Resource": "*"

}

}

```

```

Where:

Where:

• <LOGGING_ACCOUNT_ID> is your 12-digit Log Archive account ID.

• <LOGGING_ACCOUNT_ID> is your 12-digit Log Archive account ID.

• <CloudTrailReadRole> is the full name of your Cortex IAM role.

• <cortex-logs-ingestion-access-*> is the full name of your Cortex XSIAM IAM role.

7. Click Save changes.

7. Click Save changes.

### Verify connection

### Verify connection

Once the key policy is updated, verify that Cortex XSIAM can successfully decrypt and ingest the logs:

Once the key policy is updated, verify that Cortex XSIAM can successfully decrypt and ingest the logs:

1. Log in to Cortex XSIAM.

1. Log in to Cortex XSIAM.

2. Navigate to Settings > Data Sources & Integrations > Cloud Accounts.

2. Navigate to Settings > Data Sources & Integrations > Cloud Accounts.
Show markdown source
```
@@ -6,52 +6,52 @@ description: >-
 ---
 
 # Grant cross-account KMS key access for Control Tower BYOB log collection
 
 This procedure is required if you are using custom Control Tower (BYOB) log collection and you choose to encrypt your logs with a KMS key.
 
 When a KMS key and the accessing IAM role reside in different AWS accounts, AWS requires a two-way trust handshake to authorize access:
 
-* IAM side (Automated): The Cortex XSIAM CloudFormation template automatically attaches `kms:Decrypt` permissions for your specified key ARN to the `CloudTrailReadRole` role in the Log Archive account.
+* IAM side (Automated): The Cortex XSIAM CloudFormation template automatically attaches `kms:Decrypt` permissions for your specified key ARN to the `cortex-logs-ingestion-access-*` role in the Log Archive account.
 * KMS key policy side (Manual): You must update the KMS key's resource policy to explicitly trust and allow the Cortex XSIAM IAM role in the Log Archive account to perform the `kms:Decrypt` action.
 
 {% hint style="info" %}
 #### Prerequisites
 
 Before you begin, retrieve and note the following values:
 
-* **Logging account ID**: The 12-digit AWS account ID of your logging account where the Cortex IAM role is deployed.
-* Cortex role name: The exact name of the IAM role created by the Cortex XSIAM CloudFormation template in the Log Archive account (e.g., `CloudTrailReadRole`). You can retrieve this from the **Outputs** tab of the deployed CloudFormation stack.
+* Logging account ID: The 12-digit AWS account ID of your logging account where the Cortex IAM role is deployed.
+* Cortex role name: The exact name of the IAM role created by the Cortex XSIAM CloudFormation template in the Log Archive account (e.g., `cortex-logs-ingestion-access-*`). You can retrieve this from the **Outputs** tab of the deployed CloudFormation stack.
 * KMS key ID or ARN: The identifier of the KMS key used to encrypt your Control Tower S3 bucket.
 {% endhint %}
 
 1. Sign in to the AWS Management Console of the Management account where the KMS key resides.
 2. Navigate to **Key Management Service (KMS) > Customer managed keys**.
 3. Select the KMS key used to encrypt your Control Tower S3 bucket.
 4. Select the **Key policy** tab, then click **Edit**.
 5. In the JSON editor, locate the closing bracket (`]`) of the `Statement` array.
 6.  Append a comma (`,`) to the statement immediately preceding the closing bracket, then paste the following block:
 
     ```json
     {
       "Sid": "AllowCortexCrossAccountKmsDecrypt",
       "Effect": "Allow",
       "Principal": {
-        "AWS": "arn:aws:iam::<LOGGING_ACCOUNT_ID>:role/<CloudTrailReadRole>"
+        "AWS": "arn:aws:iam::<LOGGING_ACCOUNT_ID>:role/<cortex-logs-ingestion-access-*>"
       },
       "Action": "kms:Decrypt",
       "Resource": "*"
     }
     ```
 
     Where:
 
     * `<LOGGING_ACCOUNT_ID>` is your 12-digit Log Archive account ID.
-    * `<CloudTrailReadRole>` is the full name of your Cortex IAM role.
+    * `<cortex-logs-ingestion-access-*>` is the full name of your Cortex XSIAM IAM role.
 7. Click **Save changes**.
 
 ### Verify connection
 
 Once the key policy is updated, verify that Cortex XSIAM can successfully decrypt and ingest the logs:
 
 1. Log in to Cortex XSIAM.
 2. Navigate to **Settings > Data Sources & Integrations > Cloud Accounts**.
```
▸ ▾ How to onboard Amazon Web Services modified +5 −2 Adds the Deployment Method setting, renames the Custom - Control Tower option to Custom Control Tower, and updates the created IAM role name. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/how-to-onboard-amazon-web-services

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -45,16 +45,19 @@ After completing the prerequisites, follow these instructions to onboard your Am

Scanning with an outpost may require additional AWS permissions and may incur additional CSP costs.

Scanning with an outpost may require additional AWS permissions and may incur additional CSP costs.

## Configure advanced settings (optional)

## Configure advanced settings (optional)

• Click Show advanced settings to define the following advanced settings:

• Click Show advanced settings to define the following advanced settings:

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is AWS- or `AWS-`<organizationID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is AWS- or `AWS-`<organizationID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Deployment Method: Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:

• Infrastructure as Code: (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.

• Manual: Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the manual onboarding instructions.

• Scope Modifications: Use these settings to fine-tune your AWS scope, you can modify the scope by including or excluding specific regions. If you selected a Government environment, only AWS GovCloud regions are displayed. Additionally, if you selected an organization or organizational unit as the scope, you can modify the scope by including or excluding specific organizational units or accounts. For more details, see Apply region or account filters.

• Scope Modifications: Use these settings to fine-tune your AWS scope, you can modify the scope by including or excluding specific regions. If you selected a Government environment, only AWS GovCloud regions are displayed. Additionally, if you selected an organization or organizational unit as the scope, you can modify the scope by including or excluding specific organizational units or accounts. For more details, see Apply region or account filters.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in AWS GovCloud environments.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in AWS GovCloud environments.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:

• Off (Default)

• Off (Default)

@@ -65,19 +68,19 @@ After completing the prerequisites, follow these instructions to onboard your Am

• Cloud Tags: Define tags and tag values to be added to any new resource created by Cortex XSIAM in AWS. Note: The managed_by = paloaltonetworks tag is automatically added to all resources. This tag is mandatory. You cannot edit or remove this tag.

• Cloud Tags: Define tags and tag values to be added to any new resource created by Cortex XSIAM in AWS. Note: The managed_by = paloaltonetworks tag is automatically added to all resources. This tag is mandatory. You cannot edit or remove this tag.

• Log Collection Configuration: To maximize security coverage, include the collection of audit logs using CloudTrail. Select the collection method:

• Log Collection Configuration: To maximize security coverage, include the collection of audit logs using CloudTrail. Select the collection method:

• Automated: Select this option to have Cortex XSIAM provisions CloudTrail, S3, SQS, SNS, and KMS key resources in your AWS environment to collect audit logs.

• Automated: Select this option to have Cortex XSIAM provisions CloudTrail, S3, SQS, SNS, and KMS key resources in your AWS environment to collect audit logs.

• Collect data events: You can choose to collect data events, which captures S3 object-level and Lambda invocation events for enhanced visibility.

• Collect data events: You can choose to collect data events, which captures S3 object-level and Lambda invocation events for enhanced visibility.

• Cost considerations: Data events can generate high volumes in active environments (millions of events per day for busy S3 buckets). We recommend you review your CloudTrail pricing and expected event volume before enabling.

• Cost considerations: Data events can generate high volumes in active environments (millions of events per day for busy S3 buckets). We recommend you review your CloudTrail pricing and expected event volume before enabling.

• Custom: (Default) Use this option to use an existing Amazon S3 bucket for storing your CloudTrail logs.

• Custom: (Default) Use this option to use an existing Amazon S3 bucket for storing your CloudTrail logs.

• When you deploy the authentication template, you will enter the following details: S3 bucket name, SNS topic ARN, KMS key ARN (optional, if bucket is encrypted). For CloudFormation, these are entered as stack parameters. For Terraform, you are prompted for these values when you run terraform apply.

• When you deploy the authentication template, you will enter the following details: S3 bucket name, SNS topic ARN, KMS key ARN (optional, if bucket is encrypted). For CloudFormation, these are entered as stack parameters. For Terraform, you are prompted for these values when you run terraform apply.

• Cortex XSIAM creates the SQS queue, the CortexLogsReadRole IAM role, and the S3-to-SNS-to-SQS event notification infrastructure.

• Cortex XSIAM creates the SQS queue, the cortex-logs-ingestion-access-* IAM role, and the S3-to-SNS-to-SQS event notification infrastructure.

• After you deploy the authentication template, you must configure the S3 bucket event notification to send to the Cortex XSIAM-created SQS queue.

• After you deploy the authentication template, you must configure the S3 bucket event notification to send to the Cortex XSIAM-created SQS queue.

• Custom - Control Tower: Select this option if your AWS Organization is managed by AWS Control Tower and uses a centralized Log Archive account. This option is only available for organization scope.

• Custom Control Tower: Select this option if your AWS Organization is managed by AWS Control Tower and uses a centralized Log Archive account where CloudTrail logs are stored in a dedicated account separate from the management account. This option is only available for organization scope and uses service-managed StackSets to deploy the IAM role into the Log Archive account and the SQS queue into the account where the Control Tower SNS topic resides.

• When you deploy the authentication template in CloudFormation, you will enter the following details: S3 bucket name (the centralized Control Tower bucket in the Log Archive account), SNS topic ARN (the Control Tower-provisioned aws-controltower-AllConfigNotifications topic), KMS key ARN (optional), logging account ID (the AWS account ID of the Log Archive account), logging account OU ID (the OU ID of the organizational unit that directly contains the Log Archive account), and the SNS topic OU ID (the OU ID of the organizational unit that directly contains the account where the SNS topic resides).

• When you deploy the authentication template in CloudFormation, you will enter the following details: S3 bucket name (the centralized Control Tower bucket in the Log Archive account), SNS topic ARN (the Control Tower-provisioned aws-controltower-AllConfigNotifications topic), KMS key ARN (optional), logging account ID (the AWS account ID of the Log Archive account), logging account OU ID (the OU ID of the organizational unit that directly contains the Log Archive account), and the SNS topic OU ID (the OU ID of the organizational unit that directly contains the account where the SNS topic resides).

• Cortex XSIAM deploys the IAM role into the Log Archive account and creates the SQS queue in the same account that hosts the customer's CloudTrail SNS topic.

• Cortex XSIAM deploys the IAM role into the Log Archive account and creates the SQS queue in the same account that hosts the customer's CloudTrail SNS topic.

<div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h4>Important</h4><p>It is critical to ensure that your KMS key region and SNS topic region are the exact same as the AWS region where you are deploying the authentication template. For custom Control Tower (BYOB), deploy the stack in the same region as your Control Tower home region, where the SNS topic resides.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h4>Important</h4><p>It is critical to ensure that your KMS key region and SNS topic region are the exact same as the AWS region where you are deploying the authentication template. For custom Control Tower (BYOB), deploy the stack in the same region as your Control Tower home region, where the SNS topic resides.</p></div>

• Upload unknown files to WildFire: Use this option to upload unknown files scanned during registry image scans to WildFire for detonation analysis.

• Upload unknown files to WildFire: Use this option to upload unknown files scanned during registry image scans to WildFire for detonation analysis.

This option expands malware detection by allowing WildFire to analyze new samples found in your registry images. When a detonation result returns a malicious verdict, the system re-evaluates the relevant registry image and creates a malware finding.<br>

This option expands malware detection by allowing WildFire to analyze new samples found in your registry images. When a detonation result returns a malicious verdict, the system re-evaluates the relevant registry image and creates a malware finding.<br>
Show markdown source
```
@@ -45,16 +45,19 @@ After completing the prerequisites, follow these instructions to onboard your Am
 
       Scanning with an outpost may require additional AWS permissions and may incur additional CSP costs.
 
 ## Configure advanced settings (optional)
 
 *   Click Show advanced settings to define the following advanced settings:
 
     * **Instance Name:** Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is ``AWS- or `AWS-`<organizationID>``. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.
+    * **Deployment Method:** Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:
+      * **Infrastructure as Code:** (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.
+      * **Manual:** Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the [manual onboarding instructions](https://app.gitbook.com/o/r4DIGbR5VLvkZy3gAYsu/s/YOG2ZkRhgdY7TNEijOzL/).
     * **Scope Modifications:** Use these settings to fine-tune your AWS scope, you can modify the scope by including or excluding specific regions. If you selected a Government environment, only AWS GovCloud regions are displayed. Additionally, if you selected an organization or organizational unit as the scope, you can modify the scope by including or excluding specific organizational units or accounts. For more details, see [Apply region or account filters](../..#step-5-apply-region-or-account-filters-optional).
     * **Additional Security Capabilities:** Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see [Cloud service provider permissions](../cloud-service-provider-permissions).
       * **Data security posture management:** An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in AWS GovCloud environments.
       * **Registry scanning:** A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see [Configure registry scanning for cloud accounts](../../cloud-posture-and-runtime-security-data-sources/container-registry-scanning/configure-registry-scanning-for-cloud-accounts).
       * **Serverless functions scanning:** Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.
       * **Automation:** Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.
         * **Log Level:** (Optional - for Automation only) Configure the automation integration logging level. Possible values are:
           * Off (Default)
@@ -65,19 +68,19 @@ After completing the prerequisites, follow these instructions to onboard your Am
     * **Cloud Tags:** Define tags and tag values to be added to any new resource created by Cortex XSIAM in AWS. Note: The `managed_by = paloaltonetworks` tag is automatically added to all resources. This tag is mandatory. You cannot edit or remove this tag.
     *   **Log Collection Configuration:** To maximize security coverage, include the collection of audit logs using CloudTrail. Select the collection method:
 
         * **Automated:** Select this option to have Cortex XSIAM provisions CloudTrail, S3, SQS, SNS, and KMS key resources in your AWS environment to collect audit logs.
           * **Collect data events:** You can choose to collect data events, which captures S3 object-level and Lambda invocation events for enhanced visibility.
           * **Cost considerations:** Data events can generate high volumes in active environments (millions of events per day for busy S3 buckets). We recommend you review your CloudTrail pricing and expected event volume before enabling.
         * **Custom**: (Default) Use this option to use an existing Amazon S3 bucket for storing your CloudTrail logs.
           * When you deploy the authentication template, you will enter the following details: S3 bucket name, SNS topic ARN, KMS key ARN (optional, if bucket is encrypted). For CloudFormation, these are entered as stack parameters. For Terraform, you are prompted for these values when you run terraform apply.
-          * Cortex XSIAM creates the SQS queue, the **CortexLogsReadRole** IAM role, and the S3-to-SNS-to-SQS event notification infrastructure.
+          * Cortex XSIAM creates the SQS queue, the `cortex-logs-ingestion-access-*` IAM role, and the S3-to-SNS-to-SQS event notification infrastructure.
           * After you deploy the authentication template, you must configure the S3 bucket event notification to send to the Cortex XSIAM-created SQS queue.
-        * **Custom - Control Tower:** Select this option if your AWS Organization is managed by AWS Control Tower and uses a centralized Log Archive account. This option is only available for organization scope.
+        * **Custom Control Tower:** Select this option if your AWS Organization is managed by AWS Control Tower and uses a centralized Log Archive account where CloudTrail logs are stored in a dedicated account separate from the management account. This option is only available for organization scope and uses service-managed StackSets to deploy the IAM role into the Log Archive account and the SQS queue into the account where the Control Tower SNS topic resides.
           * When you deploy the authentication template in CloudFormation, you will enter the following details: S3 bucket name (the centralized Control Tower bucket in the Log Archive account), SNS topic ARN (the Control Tower-provisioned `aws-controltower-AllConfigNotifications` topic), KMS key ARN (optional), logging account ID (the AWS account ID of the Log Archive account), logging account OU ID (the OU ID of the organizational unit that directly contains the Log Archive account), and the SNS topic OU ID (the OU ID of the organizational unit that directly contains the account where the SNS topic resides).
           * Cortex XSIAM deploys the IAM role into the Log Archive account and creates the SQS queue in the same account that hosts the customer's CloudTrail SNS topic.
 
         <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h4>Important</h4><p>It is critical to ensure that your KMS key region and SNS topic region are the exact same as the AWS region where you are deploying the authentication template. For custom Control Tower (BYOB), deploy the stack in the same region as your Control Tower home region, where the SNS topic resides.</p></div>
     *   **Upload unknown files to WildFire:** Use this option to upload unknown files scanned during registry image scans to WildFire for detonation analysis.
 
         This option expands malware detection by allowing WildFire to analyze new samples found in your registry images. When a detonation result returns a malicious verdict, the system re-evaluates the relevant registry image and creates a malware finding.<br>
 
```

▸ Post-deployment: Custom (BYOB) and Control Tower audit log collection modified +12 −13 Rewrites the CloudFormation and Terraform steps and the troubleshooting entry around SNS-mediated delivery to the SQS queue.

xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/post-deployment-custom-byob-audit-log-collection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,28 +1,29 @@

---

description: Configure AWS audit log collection after Cortex XSIAM deployment.

---

# Post-deployment: Custom (BYOB) and Control Tower audit log collection

If you selected Custom (BYOB) or Custom Control Tower audit log collection, you must configure your S3 bucket to forward event notifications to the SQS queue created by the template. The steps differ depending on your deployment method.

If you selected Custom (BYOB) or Custom Control Tower audit log collection, link your existing CloudTrail notification pipeline to the SQS queue created by the template. The SQS queue receives messages by subscribing to the SNS topic, which acts as the intermediary. You can route these notifications using either of the following methods:

• CloudTrail → SNS: (Recommended) If your CloudTrail trail is already configured to publish delivery notifications to an SNS topic, the Cortex-created SQS queue subscribes to that topic automatically via the SNS subscription resource in the template. No additional S3 configuration is needed.

• S3 → SNS: If your S3 bucket is not yet connected to an SNS topic, configure an S3 event notification on the bucket to send s3:ObjectCreated:* events to the SNS topic named in the CloudTrailSnsArn parameter. The SNS topic then fans out to the SQS queue.

tabs

tab CloudFormation Custom (BYOB)

The CloudFormation stack creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it.

1. In the AWS CloudFormation console, open the stack and select the Outputs tab.

2. Note the sqs_url output value.

3. Derive the SQS queue ARN from the URL (format: arn:aws:sqs:<region>:<account-id>:<queue-name>), or retrieve it from the AWS SQS console.

4. In the AWS Management Console, navigate to your S3 bucket.

4. Confirm which notification route applies to your setup:

5. Under Properties → Event notifications, add a notification:

• If your CloudTrail trail already publishes to the SNS topic you provided as CloudTrailSnsArn: No additional configuration is needed. The template's SNS subscription connects the topic to the SQS queue automatically.

• Event types: s3:ObjectCreated:*

• If your S3 bucket does not yet send notifications to the SNS topic: In the AWS Management Console, navigate to your S3 bucket. Under Properties → Event notifications, add a notification with event type s3:ObjectCreated:* and destination set to the SNS topic ARN you provided as CloudTrailSnsArn. Save the notification configuration.

• Destination: SQS queue. Enter the ARN from step 3.

6. Save the notification configuration.

endtab

tab CloudFormation Control Tower

The Control Tower BYOB CloudFormation stack deploys the SQS queue and SNS subscription automatically via CloudFormation StackSets into the account where your SNS topic resides. No manual S3 event notification configuration is required. The SNS-to-SQS subscription is created by the StackSet.

After the stack completes, you can verify the following in the AWS Management Console:

1. In the SNS topic account, confirm that the SQS queue named <SqsQueueName> (the value you entered in the wizard) exists and has an active subscription to your CloudTrail SNS topic.

@@ -36,38 +37,36 @@ If you are using Control Tower for audit log collection and you choose to encryp

endhint

endtab

tab Terraform (account scope)

The Terraform template creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it.

1. In the terraform apply output, note the sqs_url value.

2. Derive the SQS queue ARN from the URL (format: arn:aws:sqs:<region>:<account-id>:<queue-name>), or retrieve it from the AWS SQS console.

3. In the AWS Management Console, navigate to your S3 bucket.

3. Confirm which notification route applies to your setup:

4. Under Properties → Event notifications, add a notification:

• If your CloudTrail trail already publishes to the SNS topic you provided as cloud_trail_sns_arn: No additional configuration is needed.

• Event types: s3:ObjectCreated:*

• If your S3 bucket does not yet send notifications to the SNS topic: In the AWS Management Console, navigate to your S3 bucket. Under Properties → Event notifications, add a notification with event type s3:ObjectCreated:* and destination set to the SNS topic ARN you provided as cloud_trail_sns_arn. Save the notification configuration.

• Destination: SQS queue. Enter the ARN from step 2.

5. Save the notification configuration.

endtab

endtabs

### Troubleshooting custom audit log collection

Use this section to diagnose issues with custom (BYOB) audit log collection after deploying the authentication template. The most common causes of failure are:

• S3 event notifications not configured or misconfigured: For Terraform and standard CloudFormation deployments, you must manually configure your S3 bucket to forward s3:ObjectCreated:* events to the SQS queue created by the template. If this step is skipped or the wrong SQS ARN is used, logs will not reach Cortex XSIAM.

• S3 event notifications not configured or misconfigured: For Terraform and standard CloudFormation deployments, you must ensure your CloudTrail trail publishes delivery notifications to the SNS topic you provided, or configure your S3 bucket to send s3:ObjectCreated:* events to that SNS topic. The SNS topic fans out to the SQS queue created by the template. If neither route is configured, or the wrong SNS topic ARN is used, logs will not reach Cortex XSIAM.

• Cross-region resources: The S3 bucket, SNS topic, SQS queue, and authentication template deployment must all be in the same AWS region. Cross-region configurations are not supported.

• KMS key policy not updated: (Only relevant for Custom Control Tower audit log collection) If your S3 bucket is encrypted with a customer-managed KMS key, you must manually update the KMS key policy to allow the Cortex log-collector IAM role to call kms:Decrypt. This cannot be done automatically by the template.

• Instance remains in Pending state: This indicates the template deployed successfully but the notification to Cortex XSIAM did not complete. You can connect the instance manually from the Cortex XSIAM pending instances panel. See Manually connect a cloud instance for more details.

Select the tab for your deployment method for specific troubleshooting steps.

tabs

tab CloudFormation Custom (BYOB)

Symptom	Likely cause	Resolution
Stack creation fails with IAM permission errors	AWS credentials lack required CloudFormation or IAM permissions	Ensure your AWS credentials have permissions to create CloudFormation stacks, IAM roles, SQS queues, and the resources required by your selected capabilities.
`CloudTrailSnsArn` parameter rejected	SNS ARN format is incorrect	The ARN must match `arn:(aws\|aws-us-gov):sns:<region>:<account-id>:<topic-name>`.
`CloudTrailKmsArn` parameter rejected	KMS ARN format is incorrect	The ARN must match `arn:(aws\|aws-us-gov):kms:<region>:<account-id>:key/<uuid>`. Leave the field empty if no KMS key is used.
Instance remains in Pending state after stack creation	Lambda notification to Cortex XSIAM failed	Check the Lambda function logs in CloudWatch for errors. If the notification failed, connect the instance manually: select the pending instance, click Connect manually, and provide the `CortexPlatformRole` ARN and External ID shown in the CloudFormation stack Outputs tab.
Logs not appearing in Cortex XSIAM after stack creation	S3 event notification not configured, or configured with wrong SQS ARN	Confirm you have configured the S3 bucket event notification to send `s3:ObjectCreated:*` events to the SQS queue. Retrieve the correct SQS ARN from the `sqs_url` value in the CloudFormation stack Outputs tab. Ensure the S3 bucket, SNS topic, and CloudFormation stack are all in the same AWS region.
KMS decryption errors in Cortex XSIAM	KMS key policy does not allow the `CortexLogsReadRole` to call `kms:Decrypt`	Update the KMS key policy to allow `kms:Decrypt` for the `CortexLogsReadRole-*` IAM role created by the stack. This must be done manually after the stack is deployed.

Symptom	Likely cause	Resolution
Stack creation fails with IAM permission errors	AWS credentials lack required CloudFormation or IAM permissions	Ensure your AWS credentials have permissions to create CloudFormation stacks, IAM roles, SQS queues, and the resources required by your selected capabilities.
`CloudTrailSnsArn` parameter rejected	SNS ARN format is incorrect	The ARN must match `arn:(aws\|aws-us-gov):sns:<region>:<account-id>:<topic-name>`.
`CloudTrailKmsArn` parameter rejected	KMS ARN format is incorrect	The ARN must match `arn:(aws\|aws-us-gov):kms:<region>:<account-id>:key/<uuid>`. Leave the field empty if no KMS key is used.
Instance remains in Pending state after stack creation	Lambda notification to Cortex XSIAM failed	Check the Lambda function logs in CloudWatch for errors. If the notification failed, connect the instance manually: select the pending instance, click Connect manually, and provide the `CortexPlatformRole` ARN and External ID shown in the CloudFormation stack Outputs tab.
Logs not appearing in Cortex XSIAM after stack creation	Notification pipeline not connected: CloudTrail is not publishing to the SNS topic, or the S3 bucket is not sending event notifications to the SNS topic	Confirm that either your CloudTrail trail is configured to publish delivery notifications to the SNS topic ARN you provided as `CloudTrailSnsArn`, or your S3 bucket has an event notification configured to send `s3:ObjectCreated:*` events to that SNS topic. The SNS topic fans out to the SQS queue. Ensure the S3 bucket, SNS topic, and CloudFormation stack are all in the same AWS region.
KMS decryption errors in Cortex XSIAM	KMS key policy does not allow the `CortexLogsReadRole` to call `kms:Decrypt`	Update the KMS key policy to allow `kms:Decrypt` for the `CortexLogsReadRole-*` IAM role created by the stack. This must be done manually after the stack is deployed.

endtab

tab CloudFormation Control Tower

Symptom│Likely cause│Resolution

| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

StackSet operation fails with OPERATION_NOT_FOUND or permission errors│AWS Organizations service-managed StackSets not enabled, or the management account does not have trusted access enabled for CloudFormation│In AWS Organizations, enable trusted access for AWS CloudFormation StackSets. See the AWS documentation.

Show markdown source

@@ -1,28 +1,29 @@
 ---
 description: Configure AWS audit log collection after Cortex XSIAM deployment.
 ---
 
 # Post-deployment: Custom (BYOB) and Control Tower audit log collection
 
-If you selected **Custom (BYOB) or Custom Control Tower** audit log collection, you must configure your S3 bucket to forward event notifications to the SQS queue created by the template. The steps differ depending on your deployment method.
+If you selected **Custom (BYOB)** or **Custom Control Tower** audit log collection, link your existing CloudTrail notification pipeline to the SQS queue created by the template. The SQS queue receives messages by subscribing to the SNS topic, which acts as the intermediary. You can route these notifications using either of the following methods:
+
+* **CloudTrail → SNS**: (Recommended) If your CloudTrail trail is already configured to publish delivery notifications to an SNS topic, the Cortex-created SQS queue subscribes to that topic automatically via the SNS subscription resource in the template. No additional S3 configuration is needed.
+* **S3 → SNS**: If your S3 bucket is not yet connected to an SNS topic, configure an S3 event notification on the bucket to send `s3:ObjectCreated:*` events to the SNS topic named in the `CloudTrailSnsArn` parameter. The SNS topic then fans out to the SQS queue.
 
 {% tabs %}
 {% tab title="CloudFormation Custom (BYOB)" %}
 The CloudFormation stack creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it.
 
 1. In the AWS CloudFormation console, open the stack and select the **Outputs** tab.
 2. Note the `sqs_url` output value.
 3. Derive the SQS queue ARN from the URL (format: `arn:aws:sqs:<region>:<account-id>:<queue-name>`), or retrieve it from the AWS SQS console.
-4. In the AWS Management Console, navigate to your S3 bucket.
-5. Under **Properties → Event notifications**, add a notification:
-   * **Event types:** `s3:ObjectCreated:*`
-   * **Destination:** SQS queue. Enter the ARN from step 3.
-6. Save the notification configuration.
+4. Confirm which notification route applies to your setup:
+   * If your CloudTrail trail already publishes to the SNS topic you provided as `CloudTrailSnsArn`: No additional configuration is needed. The template's SNS subscription connects the topic to the SQS queue automatically.
+   * If your S3 bucket does not yet send notifications to the SNS topic: In the AWS Management Console, navigate to your S3 bucket. Under **Properties → Event notifications**, add a notification with event type `s3:ObjectCreated:*` and destination set to the SNS topic ARN you provided as `CloudTrailSnsArn`. Save the notification configuration.
 {% endtab %}
 
 {% tab title="CloudFormation Control Tower" %}
 The Control Tower BYOB CloudFormation stack deploys the SQS queue and SNS subscription automatically via CloudFormation StackSets into the account where your SNS topic resides. No manual S3 event notification configuration is required. The SNS-to-SQS subscription is created by the StackSet.
 
 After the stack completes, you can verify the following in the AWS Management Console:
 
 1. In the SNS topic account, confirm that the SQS queue named `<SqsQueueName>` (the value you entered in the wizard) exists and has an active subscription to your CloudTrail SNS topic.
@@ -36,38 +37,36 @@ If you are using Control Tower for audit log collection and you choose to encryp
 {% endhint %}
 {% endtab %}
 
 {% tab title="Terraform (account scope)" %}
 The Terraform template creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it.
 
 1. In the `terraform apply` output, note the `sqs_url` value.
 2. Derive the SQS queue ARN from the URL (format: `arn:aws:sqs:<region>:<account-id>:<queue-name>`), or retrieve it from the AWS SQS console.
-3. In the [AWS Management Console](#first-tab), navigate to your S3 bucket.
-4. Under **Properties → Event notifications**, add a notification:
-   * **Event types:** `s3:ObjectCreated:*`
-   * **Destination:** SQS queue. Enter the ARN from step 2.
-5. Save the notification configuration.
+3. Confirm which notification route applies to your setup:
+   * If your CloudTrail trail already publishes to the SNS topic you provided as `cloud_trail_sns_arn`: No additional configuration is needed.
+   * If your S3 bucket does not yet send notifications to the SNS topic: In the AWS Management Console, navigate to your S3 bucket. Under **Properties → Event notifications**, add a notification with event type `s3:ObjectCreated:*` and destination set to the SNS topic ARN you provided as `cloud_trail_sns_arn`. Save the notification configuration.
 {% endtab %}
 {% endtabs %}
 
 ### Troubleshooting custom audit log collection
 
 Use this section to diagnose issues with custom (BYOB) audit log collection after deploying the authentication template. The most common causes of failure are:
 
-* **S3 event notifications not configured or misconfigured**: For Terraform and standard CloudFormation deployments, you must manually configure your S3 bucket to forward `s3:ObjectCreated:*` events to the SQS queue created by the template. If this step is skipped or the wrong SQS ARN is used, logs will not reach Cortex XSIAM.
+* **S3 event notifications not configured or misconfigured**: For Terraform and standard CloudFormation deployments, you must ensure your CloudTrail trail publishes delivery notifications to the SNS topic you provided, or configure your S3 bucket to send `s3:ObjectCreated:*` events to that SNS topic. The SNS topic fans out to the SQS queue created by the template. If neither route is configured, or the wrong SNS topic ARN is used, logs will not reach Cortex XSIAM.
 * **Cross-region resources**: The S3 bucket, SNS topic, SQS queue, and authentication template deployment must all be in the same AWS region. Cross-region configurations are not supported.
 * **KMS key policy not updated:** (Only relevant for Custom Control Tower audit log collection) If your S3 bucket is encrypted with a customer-managed KMS key, you must manually update the KMS key policy to allow the Cortex log-collector IAM role to call `kms:Decrypt`. This cannot be done automatically by the template.
 * **Instance remains in Pending state**: This indicates the template deployed successfully but the notification to Cortex XSIAM did not complete. You can connect the instance manually from the Cortex XSIAM pending instances panel. See [Manually connect a cloud instance](../manually-connect-a-cloud-instance) for more details.
 
 Select the tab for your deployment method for specific troubleshooting steps.
 
 {% tabs %}
 {% tab title="CloudFormation Custom (BYOB)" %}
-<table><thead><tr><th width="204.37109375">Symptom</th><th width="215.3203125">Likely cause</th><th>Resolution</th></tr></thead><tbody><tr><td>Stack creation fails with IAM permission errors</td><td>AWS credentials lack required CloudFormation or IAM permissions</td><td>Ensure your AWS credentials have permissions to create CloudFormation stacks, IAM roles, SQS queues, and the resources required by your selected capabilities.</td></tr><tr><td><code>CloudTrailSnsArn</code> parameter rejected</td><td>SNS ARN format is incorrect</td><td>The ARN must match <code>arn:(aws|aws-us-gov):sns:&#x3C;region>:&#x3C;account-id>:&#x3C;topic-name></code>.</td></tr><tr><td><code>CloudTrailKmsArn</code> parameter rejected</td><td>KMS ARN format is incorrect</td><td>The ARN must match <code>arn:(aws|aws-us-gov):kms:&#x3C;region>:&#x3C;account-id>:key/&#x3C;uuid></code>. Leave the field empty if no KMS key is used.</td></tr><tr><td>Instance remains in Pending state after stack creation</td><td>Lambda notification to Cortex XSIAM failed</td><td>Check the Lambda function logs in CloudWatch for errors. If the notification failed, connect the instance manually: select the pending instance, click <strong>Connect manually</strong>, and provide the <code>CortexPlatformRole</code> ARN and External ID shown in the CloudFormation stack Outputs tab.</td></tr><tr><td>Logs not appearing in Cortex XSIAM after stack creation</td><td>S3 event notification not configured, or configured with wrong SQS ARN</td><td>Confirm you have configured the S3 bucket event notification to send <code>s3:ObjectCreated:*</code> events to the SQS queue. Retrieve the correct SQS ARN from the <code>sqs_url</code> value in the CloudFormation stack Outputs tab. Ensure the S3 bucket, SNS topic, and CloudFormation stack are all in the same AWS region.</td></tr><tr><td>KMS decryption errors in Cortex XSIAM</td><td>KMS key policy does not allow the <code>CortexLogsReadRole</code> to call <code>kms:Decrypt</code></td><td>Update the KMS key policy to allow <code>kms:Decrypt</code> for the <code>CortexLogsReadRole-*</code> IAM role created by the stack. This must be done manually after the stack is deployed.</td></tr></tbody></table>
+<table><thead><tr><th width="204.37109375">Symptom</th><th width="215.3203125">Likely cause</th><th>Resolution</th></tr></thead><tbody><tr><td>Stack creation fails with IAM permission errors</td><td>AWS credentials lack required CloudFormation or IAM permissions</td><td>Ensure your AWS credentials have permissions to create CloudFormation stacks, IAM roles, SQS queues, and the resources required by your selected capabilities.</td></tr><tr><td><code>CloudTrailSnsArn</code> parameter rejected</td><td>SNS ARN format is incorrect</td><td>The ARN must match <code>arn:(aws|aws-us-gov):sns:&#x3C;region>:&#x3C;account-id>:&#x3C;topic-name></code>.</td></tr><tr><td><code>CloudTrailKmsArn</code> parameter rejected</td><td>KMS ARN format is incorrect</td><td>The ARN must match <code>arn:(aws|aws-us-gov):kms:&#x3C;region>:&#x3C;account-id>:key/&#x3C;uuid></code>. Leave the field empty if no KMS key is used.</td></tr><tr><td>Instance remains in Pending state after stack creation</td><td>Lambda notification to Cortex XSIAM failed</td><td>Check the Lambda function logs in CloudWatch for errors. If the notification failed, connect the instance manually: select the pending instance, click <strong>Connect manually</strong>, and provide the <code>CortexPlatformRole</code> ARN and External ID shown in the CloudFormation stack Outputs tab.</td></tr><tr><td>Logs not appearing in Cortex XSIAM after stack creation</td><td>Notification pipeline not connected: CloudTrail is not publishing to the SNS topic, or the S3 bucket is not sending event notifications to the SNS topic</td><td>Confirm that either your CloudTrail trail is configured to publish delivery notifications to the SNS topic ARN you provided as <code>CloudTrailSnsArn</code>, or your S3 bucket has an event notification configured to send <code>s3:ObjectCreated:*</code> events to that SNS topic. The SNS topic fans out to the SQS queue. Ensure the S3 bucket, SNS topic, and CloudFormation stack are all in the same AWS region.</td></tr><tr><td>KMS decryption errors in Cortex XSIAM</td><td>KMS key policy does not allow the <code>CortexLogsReadRole</code> to call <code>kms:Decrypt</code></td><td>Update the KMS key policy to allow <code>kms:Decrypt</code> for the <code>CortexLogsReadRole-*</code> IAM role created by the stack. This must be done manually after the stack is deployed.</td></tr></tbody></table>
 
 <br>
 {% endtab %}
 
 {% tab title="CloudFormation Control Tower" %}
 | Symptom                                                                  | Likely cause                                                                                                                               | Resolution                                                                                                                                                                                                                                                                                    |
 | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | StackSet operation fails with `OPERATION_NOT_FOUND` or permission errors | AWS Organizations service-managed StackSets not enabled, or the management account does not have trusted access enabled for CloudFormation | In AWS Organizations, enable trusted access for AWS CloudFormation StackSets. See the [AWS documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html).                                                                          |

▸ ▾ How to onboard Google Cloud Platform modified +3 −0 Adds the Deployment Method advanced setting with Infrastructure as Code and Manual options. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/google-cloud-platform-cloud-onboarding/how-to-onboard-google-cloud-platform

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -35,16 +35,19 @@ After completing the prerequisites, follow these instructions to onboard your Go

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h4>Note</h4><p>Scanning with an outpost may require additional GCP permissions and may incur additional CSP costs.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h4>Note</h4><p>Scanning with an outpost may require additional GCP permissions and may incur additional CSP costs.</p></div>

## Configure advanced settings (optional)

## Configure advanced settings (optional)

• Click Show advanced settings to define the following advanced settings:

• Click Show advanced settings to define the following advanced settings:

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is GCP- or `GCP-`<organizationID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is GCP- or `GCP-`<organizationID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Deployment Method: Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:

• Infrastructure as Code: (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.

• Manual: Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the manual onboarding instructions.

• Scope Modifications: Use these settings to fine-tune your GCP scope. You can modify the scope by including or excluding specific regions. Additionally, if you selected an organization or folder as the scope, you can modify the scope by including or excluding specific folders or projects. For more details, see Apply region or account filters.

• Scope Modifications: Use these settings to fine-tune your GCP scope. You can modify the scope by including or excluding specific regions. Additionally, if you selected an organization or folder as the scope, you can modify the scope by including or excluding specific folders or projects. For more details, see Apply region or account filters.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:

• Off (Default)

• Off (Default)
Show markdown source
```
@@ -35,16 +35,19 @@ After completing the prerequisites, follow these instructions to onboard your Go
 
       <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h4>Note</h4><p>Scanning with an outpost may require additional GCP permissions and may incur additional CSP costs.</p></div>
 
 ## Configure advanced settings (optional)
 
 *   Click Show advanced settings to define the following advanced settings:
 
     * **Instance Name:** Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is ``GCP- or `GCP-`<organizationID>``. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.
+    * **Deployment Method:** Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:
+      * **Infrastructure as Code:** (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.
+      * **Manual:** Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the [manual onboarding instructions](https://app.gitbook.com/o/r4DIGbR5VLvkZy3gAYsu/s/0gvymnCiCbsv2coOZcc7/).
     * **Scope Modifications:** Use these settings to fine-tune your GCP scope. You can modify the scope by including or excluding specific regions. Additionally, if you selected an organization or folder as the scope, you can modify the scope by including or excluding specific folders or projects. For more details, see [Apply region or account filters](..).
     * **Additional Security Capabilities:** Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see [Cloud service provider permissions](../cloud-service-provider-permissions).
       * **Data security posture management:** An agentless data security scanner that discovers, classifies, protects, and governs sensitive data.
       * **Registry scanning:** A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see [Configure registry scanning for cloud accounts](../../cloud-posture-and-runtime-security-data-sources/container-registry-scanning/configure-registry-scanning-for-cloud-accounts).
       * **Serverless functions scanning:** Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.
       * **Automation:** Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.
         * **Log Level:** (Optional - for Automation only) Configure the automation integration logging level. Possible values are:
           * Off (Default)
```
▸ ▾ How to onboard Microsoft Azure modified +3 −0 Adds the Deployment Method advanced setting with Infrastructure as Code and Manual options. xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/microsoft-azure-cloud-onboarding/how-to-onboard-microsoft-azure

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -66,16 +66,19 @@ Before Cortex XSIAM can proceed with onboarding, the Cortex XSIAM service princi

hint info

hint info

Cortex XSIAM performs a live verification of each tenant's approval status against Azure each time the list is displayed. If a previously approved tenant no longer shows a green checkmark, the Cortex XSIAM service principal may have been removed from the Azure tenant. Run the Azure CLI command again to re-create the service principal, then click Validate.

Cortex XSIAM performs a live verification of each tenant's approval status against Azure each time the list is displayed. If a previously approved tenant no longer shows a green checkmark, the Cortex XSIAM service principal may have been removed from the Azure tenant. Run the Azure CLI command again to re-create the service principal, then click Validate.

endhint

endhint

## Configure advanced settings (optional)

## Configure advanced settings (optional)

• Click Show advanced settings to define the following advanced settings:

• Click Show advanced settings to define the following advanced settings:

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is Azure-<tenantID> or Azure-<subscriptionID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Instance Name: Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is Azure-<tenantID> or Azure-<subscriptionID>. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.

• Deployment Method: Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:

• Infrastructure as Code: (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.

• Manual: Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the manual onboarding instructions.

• Scope Modifications: Use these settings to fine-tune your Microsoft Azure scope. You can modify the scope by including or excluding specific regions. If you selected a Government environment, only Microsoft Azure Government regions are displayed. Additionally, if you selected a tenant or management group as the scope, you can modify the scope by including or excluding specific management groups or subscriptions. For more details, see Apply region or account filters. Scope modifications are not available when you are onboarding Microsoft Entra ID only.

• Scope Modifications: Use these settings to fine-tune your Microsoft Azure scope. You can modify the scope by including or excluding specific regions. If you selected a Government environment, only Microsoft Azure Government regions are displayed. Additionally, if you selected a tenant or management group as the scope, you can modify the scope by including or excluding specific management groups or subscriptions. For more details, see Apply region or account filters. Scope modifications are not available when you are onboarding Microsoft Entra ID only.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions. When you are onboarding Microsoft Entra ID only, only XSIAM analytics is supported as an additional security capability.

• Additional Security Capabilities: Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see Cloud service provider permissions. When you are onboarding Microsoft Entra ID only, only XSIAM analytics is supported as an additional security capability.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in Microsoft Azure Government environments.

• Data security posture management: An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in Microsoft Azure Government environments.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Registry scanning: A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see Configure registry scanning for cloud accounts.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Serverless functions scanning: Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.

• Allow connection to private serverless functions: (Optional - only available with outpost scan) When serverless scanning runs from the outpost environment, it uses a dynamic IP address. Azure Functions with IP-based network restrictions will block the scanner. Enabling this option assigns a fixed IP address that can be whitelisted.

• Allow connection to private serverless functions: (Optional - only available with outpost scan) When serverless scanning runs from the outpost environment, it uses a dynamic IP address. Azure Functions with IP-based network restrictions will block the scanner. Enabling this option assigns a fixed IP address that can be whitelisted.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Automation: Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:

• Log Level: (Optional - for Automation only) Configure the automation integration logging level. Possible values are:
Show markdown source
```
@@ -66,16 +66,19 @@ Before Cortex XSIAM can proceed with onboarding, the Cortex XSIAM service princi
 {% hint style="info" %}
 Cortex XSIAM performs a live verification of each tenant's approval status against Azure each time the list is displayed. If a previously approved tenant no longer shows a green checkmark, the Cortex XSIAM service principal may have been removed from the Azure tenant. Run the Azure CLI command again to re-create the service principal, then click **Validate**.
 {% endhint %}
 
 ## Configure advanced settings (optional)
 
 * Click Show advanced settings to define the following advanced settings:
   * **Instance Name:** Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is `Azure-<tenantID>` or `Azure-<subscriptionID>`. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.
+  * **Deployment Method:** Select whether you want to onboard with a Cortex-generated IaC template or to perform a manual deployment:
+    * **Infrastructure as Code:** (Recommended) Automatically provisions all required cloud resources and permissions using an IaC template.
+    * **Manual:** Select this option if your organization requires manual provisioning to meet internal security and compliance policies. If you choose to onboard manually, follow the [manual onboarding instructions](https://app.gitbook.com/o/r4DIGbR5VLvkZy3gAYsu/s/EGgPqu5Pm2LdBLfMWLeZ/).
   * **Scope Modifications:** Use these settings to fine-tune your Microsoft Azure scope. You can modify the scope by including or excluding specific regions. If you selected a Government environment, only Microsoft Azure Government regions are displayed. Additionally, if you selected a tenant or management group as the scope, you can modify the scope by including or excluding specific management groups or subscriptions. For more details, see [Apply region or account filters](../..#step-5-apply-region-or-account-filters-optional). Scope modifications are not available when you are onboarding Microsoft Entra ID only.
   * **Additional Security Capabilities:** Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see [Cloud service provider permissions](../cloud-service-provider-permissions). When you are onboarding Microsoft Entra ID only, only XSIAM analytics is supported as an additional security capability.
     * **Data security posture management:** An agentless data security scanner that discovers, classifies, protects, and governs sensitive data. DSPM is not currently available in Microsoft Azure Government environments.
     * **Registry scanning:** A container registry scanner that scans registry images for vulnerabilities, malware, and secrets. For more details, see [Configure registry scanning for cloud accounts](../../cloud-posture-and-runtime-security-data-sources/container-registry-scanning/configure-registry-scanning-for-cloud-accounts).
     * **Serverless functions scanning:** Implement serverless scanning to detect and remediate vulnerabilities within serverless functions during the development lifecycle. Seamless integration into CI/CD pipelines enables automated security scans for a continuously secure pre-production environment.
       * **Allow connection to private serverless functions:** (Optional - only available with outpost scan) When serverless scanning runs from the outpost environment, it uses a dynamic IP address. Azure Functions with IP-based network restrictions will block the scanner. Enabling this option assigns a fixed IP address that can be whitelisted.
     * **Automation:** Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.
       * **Log Level:** (Optional - for Automation only) Configure the automation integration logging level. Possible values are:
```

▸ Create a child tenant modified +7 −7 The Child Units Allocation row now links to an in-page minimum resource allocations anchor rather than the external docs site.

xsiam/configure-cortex-xsiam/multi-tenant/onboard-cortex-multi-tenant/onboarding-checklist-for-multi-tenant-central-licensing-deployments/step-2.-create-a-child-tenant

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -12,23 +12,23 @@ Create Cortex XSIAM child tenants in Cortex Gateway after setting up the main ac

• Cortex enables parent-child pairing between tenants located in different geographical regions. To enable this capability, contact your support team.

• To create a child tenant, ensure that you have Account Admin permissions.

In Cortex Gateway, you can view all the available tenants. If you want to create more child tenants than your license permits, contact Customer Support.

1. In the Cortex Gateway, hover over the main account you activated previously until the three-dot menu appears and click Add Child Tenant.

2. Add the following details:

Parameter│Description

    | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

    | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Child Tenant Name│Give the Cortex XSIAM tenant an easily recognizable name.

Choose a name that is 59 or fewer characters and is unique across your company account.

Child Tenant Name│Give the Cortex XSIAM tenant an easily recognizable name.

Choose a name that is 59 or fewer characters and is unique across your company account.

Region│View the region for the child tenant.

Child Tenant Subdomain│Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL.

https://<subdomain>.crtx.<region>.paloaltonetworks.com

This is a public FQDN, so be careful with sensitive information such as the company name.

After activating a child tenant, you can only change the child tenant subdomain once.

Child Tenant Subdomain│Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL.

https://<subdomain>.crtx.<region>.paloaltonetworks.com

This is a public FQDN, so be careful with sensitive information such as the company name.

After activating a child tenant, you can only change the child tenant subdomain once.

Child Units Allocation│Assign the number of employees and Gigabytes you want to allocate to this child tenant. The amount used and the total amount available to this multi-tenant environment are displayed.

Ensure that you meet the minimum requirements for child tenant allocation.

Add Ons│If any license add-ons were purchased with your multi-tenant license, they are listed here. If you acquired compute units (CU) or forensics, you can allocate how many units to allocate to this child tenant.

3. Confirm approval of the terms and conditions of the privacy policy and click Activate.

    Activation can take up to an hour. You should receive notification by email that the child tenant has completed the activation process.

    Activation can take up to an hour. You should receive notification by email that the child tenant has completed the activation process.

4. (Optional) Add another child tenant by repeating steps 1 and 2 or access your newly created tenant.

    In the Cortex Gateway, under your main account, you can see the total number of tenants you are licensed for and how many you have created.

    In the Cortex Gateway, under your main account, you can see the total number of tenants you are licensed for and how many you have created.

    If you reach your limit for child tenants, depending on your license, you may be able to create more tenants. You may be charged for additional tenants. Contact Customer Support if you are approaching your authorized limit.

    If you reach your limit for child tenants, depending on your license, you may be able to create more tenants. You may be charged for additional tenants. Contact Customer Support if you are approaching your authorized limit.

Show markdown source

@@ -12,23 +12,23 @@ Create Cortex XSIAM child tenants in Cortex Gateway after setting up the main ac
 * Cortex enables parent-child pairing between tenants located in different geographical regions. To enable this capability, contact your support team.
 * To create a child tenant, ensure that you have Account Admin permissions.
 
 In Cortex Gateway, you can view all the available tenants. If you want to create more child tenants than your license permits, contact Customer Support.
 
 1. In the Cortex Gateway, hover over the main account you activated previously until the three-dot menu appears and click Add Child Tenant.
 2.  Add the following details:
 
-    | Parameter              | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-    | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-    | Child Tenant Name      | <p>Give the Cortex XSIAM tenant an easily recognizable name.</p><p>Choose a name that is 59 or fewer characters and is unique across your company account.</p>                                                                                                                                                                                                                                                                                                     |
-    | Region                 | View the region for the child tenant.                                                                                                                                                                                                                                                                                                                                                                                                                              |
-    | Child Tenant Subdomain | <p>Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL.</p><p>https://&#x3C;subdomain>.crtx.&#x3C;region>.paloaltonetworks.com</p><p>This is a public FQDN, so be careful with sensitive information such as the company name.</p><p>After activating a child tenant, you can only change the child tenant subdomain once.</p>                                                                 |
-    | Child Units Allocation | <p>Assign the number of employees and Gigabytes you want to allocate to this child tenant. The amount used and the total amount available to this multi-tenant environment are displayed.</p><p>Ensure that you meet the <a href="https://docs-cortex.paloaltonetworks.com/r/5CAbsl8idaK8R43ZLhoTOw/bKQnG2ZF4IN0_h1SsvPwqg?section=UUID-f8450665-a710-7ec2-d40a-7f15349ac119_section-idm234529819989674">minimum requirements</a> for child tenant allocation.</p> |
-    | Add Ons                | If any license add-ons were purchased with your multi-tenant license, they are listed here. If you acquired compute units (CU) or forensics, you can allocate how many units to allocate to this child tenant.                                                                                                                                                                                                                                                     |
+    | Parameter              | Description                                                                                                                                                                                                                                                                                                                                                                                        |
+    | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+    | Child Tenant Name      | <p>Give the Cortex XSIAM tenant an easily recognizable name.</p><p>Choose a name that is 59 or fewer characters and is unique across your company account.</p>                                                                                                                                                                                                                                     |
+    | Region                 | View the region for the child tenant.                                                                                                                                                                                                                                                                                                                                                              |
+    | Child Tenant Subdomain | <p>Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL.</p><p>https://&#x3C;subdomain>.crtx.&#x3C;region>.paloaltonetworks.com</p><p>This is a public FQDN, so be careful with sensitive information such as the company name.</p><p>After activating a child tenant, you can only change the child tenant subdomain once.</p> |
+    | Child Units Allocation | <p>Assign the number of employees and Gigabytes you want to allocate to this child tenant. The amount used and the total amount available to this multi-tenant environment are displayed.</p><p>Ensure that you meet the <a href="#child-tenant-minimum-resource-allocations">minimum requirements</a> for child tenant allocation.</p>                                                            |
+    | Add Ons                | If any license add-ons were purchased with your multi-tenant license, they are listed here. If you acquired compute units (CU) or forensics, you can allocate how many units to allocate to this child tenant.                                                                                                                                                                                     |
 3.  Confirm approval of the terms and conditions of the privacy policy and click Activate.
 
     Activation can take up to an hour. You should receive notification by email that the child tenant has completed the activation process.
 4.  (Optional) Add another child tenant by repeating steps 1 and 2 or access your newly created tenant.
 
     In the Cortex Gateway, under your main account, you can see the total number of tenants you are licensed for and how many you have created.
 
     If you reach your limit for child tenants, depending on your license, you may be able to create more tenants. You may be charged for additional tenants. Contact Customer Support if you are approaching your authorized limit.