Onboarding AWS Environments to Intelligence

This topic describes how to onboard an AWS Amazon® Web Services. Public cloud platform that offers global compute, storage, database, application and other cloud services. environment to Intelligence with an automated onboarding experience. For a legacy procedure with manual onboarding, see Custom Onboarding of AWS Environments to Intelligence.

Your AWS environment has to be onboarded to CloudGuard before you can onboard it to Intelligence. If your account is not yet onboarded, follow the instructions in Unified Onboarding of AWS Environments.

How It Works

Intelligence uses VPC Flow Logs and CloudTrail logs from your AWS account. These logs have to be stored in an Amazon S3 bucket. Intelligence analyzes only the new logs that CloudGuard starts to receive after you onboarded the account to Intelligence. The S3 bucket sends PutObject event notifications to an SNS topic, and the topic is connected through an SNS Subscription to the Intelligence SQS Reliable and scalable hosted queues for storing messages as they travel between computers.-queue endpoint. When CloudGuard receives this event notification, it runs the S3 GetObject on the path specified in the notification to retrieve the log.

During the onboarding process, CloudGuard establishes the connection to receive notifications regarding new log files and obtains permissions to run the S3 GetObject on one or more log buckets. For easier handling of the required configuration, CloudGuard can create a CloudFormation Template (CFT) to run in your AWS environment.

S3 bucket for each account

The architecture diagram below illustrates how to onboard an S3 bucket for each account.

Centralized S3 bucket

A centralized S3 bucket is an Amazon S3 bucket that stores logs for multiple AWS accounts. Use the onboarded centralized S3 bucket to easily monitor and run log analysis of all your AWS accounts that send logs to this S3 bucket.

The onboarding initiates from the AWS account that has the centralized S3 bucket already configured in its environment. CloudGuard then retrieves a list of AWS accounts that send Flow Logs or CloudTrail logs to the centralized S3 bucket. You can select the applicable AWS account(s) to onboard from this list. To onboard all AWS accounts to Intelligence, use Automatic Onboarding.

The onboarding of an organizational unit is supported only when a centralized S3 bucket is configured in your AWS organization structure.

The architecture diagram below illustrates how to onboard several AWS accounts to a centralized S3 bucket.

Known Limitations

AWS allows you to set only one event notification on a specific prefix with a specific event type. You cannot onboard an S3 bucket if the bucket has the event notifications set, and one of the notifications meets two conditions below:
- The notification has an empty prefix filter set (that is, all of the bucket) or an explicit AWS log-prefix set.
- The event type is PutObject or all object-created events.
For Intelligence, you can onboard an S3 bucket through one SNS topic only.
Intelligence cannot analyze the involved IAM Identity and Access Management (IAM) - A web service that customers can use to manage users and user permissions within their organizations. policies: S3 bucket policy, existing SNS topic policy, and policies of the CloudGuard IAM trust role. Therefore, permission-related issues can occur you create the onboarding stack.
You cannot onboard an account to Intelligence if you use an encrypted SNS topic.

For these and other CloudGuard limitations, see Known Limitations.

Onboarding to Account Activity or Traffic Activity

Note - You must onboard Flow Logs and CloudTrail separately for each account.

Follow these steps in CloudGuard to enable Account Activity with CloudTrail:

In CloudGuard, open the Environments page from the Assets menu.
From the list of the AWS environments, find the AWS environment to be onboarded to Intelligence.
In the account row and the Account Activity column, click Enable to start the Intelligence onboarding wizard.

As an alternative, you can click and open the environment page. From the top right, select Add Intelligence > CloudTrail.
Follow the on-screen instructions to complete the wizard.

Follow these steps in CloudGuard to enable Traffic Activity with Flow Logs:

In CloudGuard, open the Environments page from the Assets menu.
From the list of the AWS environments, find the AWS environment to be onboarded to Intelligence.
In the account row and the Traffic Activity column, click Enable to start the Intelligence onboarding wizard.

Or, you can click and open the environment page. From the top right, select Add Intelligence > Flow Logs.
Follow the on-screen instructions to complete the wizard.

Wizard Stages

Welcome - Read carefully the onboarding prerequisites and make sure that the AWS environments to be onboarded meet all the required conditions.
S3 Buckets
1. Select one or more S3 buckets A bucket is a container for objects stored in Amazon S3 (Amazon Simple Storage Service). to be onboarded.
2. Set Auto Onboard to ON to let CloudGuard:
  - detect all onboarded AWS accounts that send logs of a certain type to this centralized S3 bucket
  - automatically onboard these accounts to Intelligence
  The toggle button is enabled only for new buckets that you select to onboard. To update the onboarded bucket(s) mode, go to the Intelligence tab on the environment page. For more information, see Automatic Onboarding.
You can see the status details for each S3 bucket on the right pane. The details help you troubleshoot issues that prevent onboarding of the S3 bucket. For more information on possible issues, see Errors, Warnings, and Troubleshooting.
CloudFormation Template - Create a stack from the provided CFT. For more information, see CFT Resources and Permissions.

During the process, CloudGuard shows the onboarding status on the bottom part of the page. Click Check Now to see the current status of the configuration. For more information, see Status Check.

CloudGuard skips this step if your AWS account already has all the required resources.
Accounts - For centralized S3 buckets, select the AWS accounts that you want to onboard and see their logs.

CloudGuard skips this step if only one AWS account sends logs to this S3 bucket.
Done - Make sure the onboarding is successful.

AWS Onboarding Permissions

When you launch a CloudFormation stack, the stack gets its permissions through two primary processes.

It inherits the permissions of the user who creates the stack. The user has one of these credentials:
- IAM user
- Federated user (SSO Single Sign-On (SSO) - A session/user authentication process that permits a user to enter one name and password in order to access multiple applications./SAML)
It receives an IAM Role assigned directly to the stack.

To assign a dedicated role to the onboarding stack, the role must allow for the AWS CloudFormation service to assume it.

For successful onboarding, it is necessary to give the stack all the necessary permissions.

Some of the permissions include a Delete step. It is applicable when it is necessary to create a dedicated IAM role for the stack, rather than use the user's permissions. As a result, this role is used for the deletion of the stack.

Permissions

Four primary conditions that have an effect on your customized CloudFormation template:

A bucket that is already preconnected to an existing SNS topic with an Event Notification.

This is the most basic, in terms of the resources created, template. It requires these permissions:
Copy
```
"iam:DetachRolePolicy",

"iam:GetRolePolicy",

"iam:PutRolePolicy",

"sns:Subscribe",

"sns:Unsubscribe"
```

A bucket will connect, as part of the current template, to an existing SNS topic. In that case, it is necessary to add permissions* to create an AWS Lambda function that adds the applicable event notification.

Copy

"ec2:DescribeNetworkInterfaces",

"iam:AttachRolePolicy",

"iam:CreatePolicy",

"iam:CreateRole",

"iam:GetPolicy",

"iam:GetRole",

"iam:GetRolePolicy",

"iam:DeletePolicy",

"iam:DeleteRole",

"iam:DeleteRolePolicy",

"iam:DetachRolePolicy",

"iam:ListPolicyVersions",

"iam:PassRole",

"iam:PutRolePolicy",

"lambda:CreateFunction",

"lambda:DeleteFunction",

"lambda:GetFunction",

"lambda:GetFunctionCodeSigningConfig",

"lambda:GetFunctionConcurrency",

"lambda:InvokeFunction",

"lambda:PutFunctionConcurrency",

"logs:CreateLogGroup",

"logs:DeleteLogGroup"

*Note - In addition, the permissions from point 1 are necessary.

A bucket connected, as part of the current template, to a new SNS topic (that is created in the current template). More permissions* are necessary for the creation of a SNS topic.
Copy
```
"sns:CreateTopic",

"sns:GetTopicAttributes",

"sns:ListSubscriptionsByTopic",

"sns:SetTopicAttributes",

"sns:TagResource"
```

*Note - In addition, the permissions from points 1 and 2 are necessary.

If you select buckets from multiple regions as part of one process, stack sets are used that necessitate more permissions*:

Copy

"cloudformation:CreateStackInstances",

"cloudformation:CreateStackSet",

"cloudformation:DeleteStackInstances",

"cloudformation:DeleteStackSet",

"cloudformation:DescribeStackSet",

"cloudformation:DescribeStackSetOperation",

"cloudformation:GetTemplateSummary",

"iam:CreateRole",

"iam:GetRole",

"iam:GetRolePolicy",

"iam:DeleteRole",

"iam:DeleteRolePolicy",

"iam:DetachRolePolicy",

"iam:PassRole",

"iam:PutRolePolicy"

*Note - In addition, the permissions from points 1 and 2 or from points 1 and 3 are necessary.

CFT Resources and Permissions

Common Permissions

CloudGuard generates a customized CloudFormation Template based on your bucket selection. Based on the setup in your account, the template can include these resources:

IAM inline policy added to the CloudGuard trust role.

The policy grants these permissions:
- s3:GetObject - Only on the onboarded log buckets
- sns:Subscribe - Only on the topics connected to the onboarded log buckets
- sns:Unsubscribe
- kms:Decrypt – Only if the onboarded log bucket is KMS AWS Key Management Service (AWS KMS) - A managed service that simplifies the creation and control of encryption keys that are used to encrypt data.-encrypted or the stored CloudTrail log files are encrypted
SNS Topic – If the log bucket is not pre-connected to SNS topics
SNS Topic Policy - The policy allows all of the buckets in the AWS account to publish event notifications to the topic. The policy allows subscription to the Intelligence SQS queue endpoint.
SNS Subscription to the Intelligence SQS queue endpoint.
Lambda function - It is used to create a correct event notification on the S3 bucket if there is no such notification.
CloudWatch Log Group – To store logs from Lambda.
Lambda Execution IAM Role and Lambda Execution IAM Policy - To grant the lambda the following permissions:
- logs:CreateLogStream, logs:PutLogEvents – Allow logging in CloudWatch, standard lambda permissions.
- s3:GetBucketNotification, s3:PutBucketNotification – Allow reading the existing notifications on the bucket and appending the correct one. This permission applies only to the bucket onboarded in the process.

Resources for Multiple Buckets

If you select multiple buckets from different regions as part of one onboarding process, then is necessary for CloudGuard to have more resources. These resources are necessary because CloudFormation does not allow interaction with multiple regions from one stack.

Stack Sets – A stack set for each selected region.
Stack – A stack for each region.
Two IAM roles that CloudGuard role does not have permission to assume.
- IAM Role (Admin Custom Role) - The role that can be assumed by CloudFormation and can assume the execution role below.
- IAM Role (Execution Custom Role) – The role with the exact permissions that the CFT needs to complete.

IAM Custom Role

If necessary, configure a custom IAM role to reduce the scope of your administrative role and allow CloudFormation to use this role to create, change, or delete resources in the stack.

This custom role can be assigned through:

A regular IAM user
A federated user
An IAM role

You can select this role in the Permissions section when you configure stack options.

Important - To make sure that the stack creation is successful:

Make sure that the IAM user (or the federated user, or the IAM role) that creates the stack has all the permissions for the involved resources listed above.
After you have generated a template, do not change the account configuration until the template reaches a steady (not in progress) state.

Status Check

You can see in real time the status of part of the configurations added as part of the CFT.

This process verifies that:

All required S3 bucket event notifications were added to the correct SNS topics, with the correct prefix filter and event type.
All connected SNS topics are at this time subscribed to the correct Intelligence SQS endpoint based on the onboarding log type.

This process does not make sure that the permissions are added successfully to the CloudGuard trust role. And it does not make sure that the stack reached a Create_Complete state.

Possible results:

Complete - The checked configurations appended successfully. You can continue with the onboarding process.
Not Complete - Some parts of the configuration are missing. Possibly, the stack creation did not complete. Wait until the stack reaches a stable state and retry the call.

Automatic Onboarding

CloudGuard can detect all onboarded AWS accounts that send logs of a certain type to the centralized S3 bucket and automatically onboard them to Intelligence.

For accounts that send CloudTrail logs to the centralized S3 bucket, CloudGuard can automatically onboard them to Account Activity.
For accounts that send Flow Logs to the centralized S3 bucket, CloudGuard can automatically onboard them to Traffic Activity.

If you do not select this option, you have to onboard each account to Intelligence manually.

To update the Auto Onboard status:

On the Assets > Environments page, click to open an environment onboarded to Intelligence.
Go to the Intelligence tab.
In the Auto Onboard column, click the toggle button to change the status of automatic onboarding.

Note - Automatic Onboarding is applicable to a certain log type on the entire bucket. On the environment page, Intelligence tab, you can sometimes see more than one row of a bucket for different log scopes (VPCs). However, when you enable Automatic Onboarding on one row, it is enabled on all other rows of the same bucket and the same log type.

Errors, Warnings, and Troubleshooting

When you select from available S3 buckets for onboarding, you can see the bucket status on the right pane. The bucket status can be:

Available - You can continue to the next step and onboard the S3 bucket.
Onboarded - This S3 bucket is already onboarded. For centralized S3 buckets, you can continue and onboard more accounts with the bucket.

Cannot onboard - You cannot onboard this S3 bucket. Resolve the related issue or select a different S3 bucket.

Note - Some AWS account configurations do not allow S3 bucket onboarding, for example, when the S3 bucket is already connected to a non-SNS endpoint.

Errors prevent your S3 bucket from onboarding; with warnings, you can continue the process.

Best Practice - Attempt to resolve issues from a status warning before you continue to onboard the S3 bucket. Although CloudGuard allows you to move on to the next step, this can cause Intelligence not to do a full analysis of your account.

Warning and Error Messages

Warning / Error	Details	Corrective Action
Warning	Flow Logs traffic filter is not set to ‘ALL’	Add new Flow Logs with ALL traffic selected
Warning	Flow Logs custom log format is insufficient	Add new Flow Logs with all default attributes present.
Warning	Couldn't get S3 bucket encryption configuration	For the `AccessDenied` error, check the S3 bucket policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the `S3:GetEncryptionConfiguration` action on the bucket resource.
Warning	S3 Bucket wasn't listed properly	For the `AccessDenied` error, check the S3 bucket policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the `S3:listobjects` action on the bucket resource.
Warning	Couldn't resolve bucket's kms key	For the `AccessDenied` error, check the S3 bucket policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the `kms:listaliases` action.
Warning	SQS Subscription to the onboarded SNS topic not found	-
Warning	Onboarded S3 bucket’s SNS topic not found	-
Warning	CloudTrail is not multi-region	Change a trail that applies to one Region to apply to all Regions, see AWS documentation
Warning	Logs will be received partially	Each S3 bucket can be onboarded through a topic, hence CloudGuard receives only part of the logs. Select the topic or configure the separation of the S3 bucket prefixes.
Warning	Bucket is in another account and requires action	The S3 bucket is in a different account. Select the account on the Environments page and onboard to Intelligence from the account.
Warning	"Access Denied" error received from AWS	After the warning is corrected (see AccessDenied Error), you must select the S3 bucket in the onboarding wizard and onboard it again. It is not necessary to offboard the bucket.
Warning	The configured event notification destination on the S3 bucket does not exist.	Remove the S3 bucket event notifications from the invalid destinations and reload the page. The invalid SNS topic's ARN Amazon Resource Names (ARNs) uniquely identify AWS resources. They are required to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls. that CloudGuard detected shows in the warning on the CloudGuard portal.
Warning	AWS `AuthorizationError` received for SNS topic encryption	Check the SNS topic policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the SNS:GetTopicAttributes action on the topic resource.
Error	Couldn't get S3 bucket notifications	For the `AccessDenied` error, check the S3 bucket policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the `s3:getbucketnotification` action on the bucket resource.
Error	Couldn't get S3 bucket location	For the `AccessDenied` error, check the S3 bucket policy and the CloudGuard trust role policies. Make sure the trust role is allowed to do the `s3:getbucketlocation` action on the bucket resource.
Error	Couldn't resolve S3 bucket's account	Make sure the bucket is in the AWS account that is onboarded to CloudGuard Review the CloudGuard trust role and the bucket policy to make sure they allow all required actions
Error	Encrypted SNS topics connected	Intelligence cannot onboard buckets connected through an encrypted SNS topic. Remove encryption if you want to use a specific topic.
Error	The S3 bucket has a direct connection that is not supported anymore.	Remove the S3 bucket event notification to the Intelligence endpoint and reload the page.
Error	We cannot connect to the existing bucket's event notification due to an AWS limitation.	There is an AWS limitation that cannot define different event notifications if there are overlapping prefixes for the same event type. Solution - See below.

Troubleshooting: Failed Connection to Existing Bucket's Event

This error shows because AWS allows the event notification to have only one endpoint of the ‘put’ type. It cannot define more than one event notification if there are overlapping prefixes for the same event type. To solve the issue, use the fact that an SNS topic can have multiple subscriptions.

If you already have a destination, create an SNS topic to send the data to the CloudGuard SQS and the existing destination, which can be an SNS, Lambda, or SQS.

For this, build the structure on the AWS side and use the option of manual onboarding of Intelligence in CloudGuard. This allows you to select the SNS topic manually.

For more information, see AWS documentation.

If you cannot successfully finish the onboarding process:

Contact Check Point Support Center
After several hours attempt again. Sometimes, maintenance or network issues on AWS can cause interference with onboarding.
Onboard with the legacy procedure in Custom Onboarding of AWS Environments to Intelligence

Onboarding Verification

When the onboarding is complete, make sure that the new logs of the onboarded AWS account start to appear in the CloudGuard portal in Events > Cloud Logs > Account Activity or Network Traffic. This can take less than 30 minutes.