AWS Verified Access v1.0.0 Plugin for Risk Exchange

This document explains how to configure the AWS Verified Access v1.0.0 plugin with the Risk Exchange module of the Netskope Cloud Exchange platform. This plugin is used to fetch users from the log streams present inside a CloudWatch log group attached to a verified access instance. This plugin does not support performing actions on the users.

Prerequisites

A Netskope tenant (or multiple, for example, production and development/test instances).
A Netskope Cloud Exchange tenant with the Tenant plugin and Risk Exchange module already configured.
Connectivity to your AWS Verified Access console.

CE Version Compatibility

Netskope CE v5.1.0

AWS Verified Access Plugin Support

The CRE AWS Verified Access plugin fetches users and their respective details from the log streams of log groups present in CloudWatch. This plugin does not support performing any actions.

Type of data pulled	Users
Actions Supported	No actions

Mappings

Mappings are used to view the pulled Users, and details. Mapped fields during plugin configuration will be visible on the Records page once the data is pulled. Here are the suggested mappings that should be used while configuring the plugin.

Pull Mapping for Users

Plugin Field Label	Expected Data Type	Suggested Field Label	Aggregate Strategy
Email Address	String	Email Address	Unique
Username	String	Username	Overwrite
UUID	String	UUID	Unique

Permissions

AWS Access Verified Cloudwatch permissions to the IAM user. Follow the steps mentioned in the Create an AWS CloudWatch policy section.

API Details

List of APIs Used

This plugin uses Python libraries to get logs from AWS Cloudwatch log groups attached to the AWS Verified Access Instance.

Library: The AWS SDK for Python (Boto3).

Usage: The AWS SDK for Python (Boto3) to create, configure, and manage AWS services, such as Amazon Simple Queue Service (Amazon SQS), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudWatch Logs and Amazon Simple Storage Service (Amazon S3). The SDK provides an object-oriented API as well as low-level access to AWS services.

Creating Cloudwatch Log Client:

cloudwatch_logs = session.client(
                "logs",
                aws_access_key_id=self.aws_public_key,
                aws_secret_access_key=self.aws_private_key,
                aws_session_token=self.aws_session_token,
                region_name=self.configuration["region_name"].strip(),
                config=Config(proxies=self.proxy, user_agent=self.useragent),
            )

Describe Log Streams:

response = cloudwatch_logs.describe_log_streams(
                **describe_log_streams_params
            )

Getting Log Events:

response_events = cloudwatch_logs.get_log_events(
                            **params
                        )

Performance Matrix

Below is the performance matrix conducted on a Large CE Stack with below-mentioned specifications by pulling 10K users.

Stack Size

Large

RAM: 32 GB

Core: 16

Time taken to store the pulled and updated user records

~10 mins

User Agent

netskope-ce-5.1.0-cre-aws-verified-access-v1.0.0

Workflow

Configure an AWS Verified Access instance (if you don’t already have one).
Create CloudWatch Log Group.
Attach the log group with Verified Access instance.
Create an AWS Cloudwatch policy.
Configure the AWS Verified Access plugin.
Add a Risk Exchange Business Rule for AWS Verified Access.
Add SIEM Mappings for AWS Verified Access.
Validate the for AWS Verified Access plugin.

Click play to watch a video.

Configure a Verified Access Instance

Follow the steps mentioned in the link below to set up the required configurations for Verified Access.

https://catalog.workshops.aws/verifiedaccessworkshop/en-US/labs/lab1

Create CloudWatch Log Group

Log in to AWS Console.
Search for and click on CloudWatch.
Click Log groups.
Click Create log group.
Enter the name of the log group, and click Save.
Search for the created log group.

Attach the Log Group with the Verified Access Instance

Log in to AWS Console.
Search for Verified Access and click on AWS Verified Access.
Click Verified Access instance ID.
Click Verified Access Instance logging configuration.
Click Modify Verified Access instance logging configuration.
Select the log group in the Log group dropdown. Click Modify configuration. The Log Group is ready to use.

Create an AWS CloudWatch Policy

Search for IAM in the search box, and in the left panel, click Policies.
Click Create Policy.

Click on the JSON tab, enter this policy, and then click Next.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:*"
            ],
            "Resource": [
                "arn:aws:logs:*:*:*"
            ]
        }
    ]
}

Enter a Name and click Create Policy.
Attach this policy to the user. Go to IAM > Users. Select the user for which you want to attach a policy, click Add permissions, and select the Add permissions option.
Select Attach policies directly under the Permissions options, and then search for and select the policy created in the previous step for the source queue.
Click Next and then click Add permissions. The policy will be attached to the user.

Plugin Authentication Methods

IAM Role Anywhere Authentication

Prerequisites

The AWS Certificate Manager service is required to be enabled to authenticate the plugin using the AWS IAM Roles Anywhere Authentication Method.

Note to sure you create the Private Certificate Authority, Trust Anchor and Profile in the same region in which your Verified Access instance and CloudWatch Log Group resides.

Create a Policy

This Policy contains the required permissions for creating Private CA Certificate (including Permissions for creating Trust Anchor and Profile) and using the IAM Roles Anywhere.

Go to Policy Generator and select IAM Policy as policy type, enter Add Statement details, and generate a policy.
- Select Type of Policy: IAM Policy
- Effect: Allow
- AWS Service: AWS Private Certificate Authority
- Actions:
  - CreateCertificateAuthority
  - DescribeCertificateAuthority
  - GetCertificate
  - GetCertificateAuthorityCertificate
  - GetCertificateAuthorityCsr
  - ImportCertificateAuthorityCertificate
  - IssueCertificate
  - ListCertificateAuthorities
- ARN: *
Click Add Statement.
Scroll back up to add another statement.
- Select Type of Policy: IAM Policy
- Effect: Allow
- AWS Service: AWS Identity and Access Management (IAM)
- Actions:
  - AttachRolePolicy
  - CreateAccessKey
  - CreateRole
  - DeleteRole
  - PassRole
- ARN: *
Click Add Statement.
Scroll back up to add another statement.
- Select Type of Policy: IAM Policy
- Effect: Allow
- AWS Service: AWS Certificate Manager
- Actions:
  - DescribeCertificate
  - ExportCertificate
  - GetCertificate
  - ListCertificates
  - ListTagsForCertificate
  - RequestCertificate
- ARN: *
Click Add Statement.
Scroll back up to add another statement.
- Select Type of Policy: IAM Policy
- Effect: Allow
- AWS Service: AWS Identity and Access Management Roles Anywhere
- Actions:
  - CreateProfile
  - CreateTrustAnchor
  - GetProfile
  - GetTrustAnchor
  - ListProfiles
  - ListTrustAnchors
- ARN: *
Click Add Statement.
Click Generate Policy.
Copy the Policy as it will be used in the next step for creating the policy required for creating the Private CA certificates.
Go to AWS Console and select IAM from All Services. Click Policies in the left panel, and then click Create Policy.
Copy the policy to the JSON tab, click Next:Tags, and then click Next:Review
.
Enter a name (like netskope-ce-rolesAnywhere-policy) and click Save Changes.

Create a Private Certificate Authority

Log in to AWS Console.
Search for Certificate Manager.
Click AWS Private CA.
Click Create a private CA.
For Mode Options, select General-purpose.
For CA type options, select Root.
Enter the Organization (O).
For Key algorithm options, select RSA 2048.
Add tags if any (optional).
Check the checkbox in the CA permissions options section.
Check the checkbox in the Pricing section.
Click Create to create the CA certificate.
From Actions, select Install CA Certificate.
Click Confirm and Install.

Create a Trust Anchor

Search for the IAM service, go to Roles under Access management scroll down to Roles Anywhere and select Manage.
Click Create a Trust anchor.
Enter a Trust anchor name, like netskope-ce-aws-verified-trust-anchor.
Select AWS Certificate Manager Private CA (created in the previous steps) as a Certificate authority (CA) source. Select the Certificate that was created in the previous step in AWS Private Certificate Authority.
Add tags if required.
Click Create a trust anchor.
Click on the created Trust Anchor and copy the Trust Anchor ARN.

Create an IAM Role

Go to IAM services in the AWS Console.
Click Role in the Access Management submenu.
Click Create Role.
In the Trusted entity type, select Custom Trust Policy.

Replace the Custom trust Policy with this Trust Policy. This policy contains the permissions for using the roles anywhere service:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "rolesanywhere.amazonaws.com"
                ]
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession",
                "sts:SetSourceIdentity"
            ]
        }
    ]
}

Click Next.
In the Permissions policies, select the policy created in Create an AWS CloudWatch Log Policy.
Click Next.
Provide a Role name (like netskope-ce-aws-verified-access-role) and Description for the role.
Click Create role. Search for the created role and click on the Role Name.
Make a note of the Role ARN as this will be required in the Plugin configuration parameter Role ARN for the authentication method AWS IAM Roles Anywhere.

Create a Profile

Select Roles under Access management.
Scroll down to Roles Anywhere and click Manage.
Expand the Setup steps.
Click Step 2: Configure roles.
Click Configure a profile.
Enter a Profile name, like netskope-ce-aws-verified-access-profile.
Select the role created in Create IAM Role.
Remove the Inline Policy.
Click Create a profile.
Select the created Profile and copy the Profile ARN.

Request a Private Certificate

Go to AWS Certificate Manager > Request certificate.
Select Request a private certificate.
Click Next.
Select the Certificate authority created in the previous step.
Provide a domain name in the Fully qualified domain name field, like netskope-ce-verified-access.com.
Select RSA 2048 as the Key algorithm.
Add tags if required.
Acknowledge the Certificate renewal permissions.
Click Request.
Go to List certificates from the navigation pane of AWS Certificate Manager.
Select the certificate created previously.
Click Export.
Enter a passphrase. Make a note of the passphrase as it will be required for the Configuration of the AWS Security Lake Plugin using the AWS IAM Roles Anywhere Authentication method.
Click Generate PEM Encoding.
Download all the Certificates as it won’t be visible again. For new certificates, you will need to Export them again.

The Certificate body, Certificate Private Key will be required for the Configuration of the AWS Verified Access Plugin using the AWS IAM Roles Anywhere authentication method. For more info, go to AWS IAM Role Anywhere.

AWS Authentication

Create a Role

Go to IAM services in the AWS Console.
Click Create role.
Select the AWS Service.
Under Use case, select EC2.
Click Next.
Select the permission policy created in Create an AWS Cloudwatch policy.
Click Next.
Enter a Role Name (like aws-verified-access-instance-role) and Description.
Click Create Role.

Assign a Role to an EC2 Instance

Log in to your EC2 instance console.
Click Instances under Instances.
Go to Action > Security > Modify IAM Role.
Select the Role that you created above in Create a Role. (netskope-ce-instance-role).
Click Add IAM Role or Modify IAM Role. Note that both EC2 instance and Queue should be on the same region.

Assign a Role to a K8s Instance

Open your Role created for ServiceAccount while creating K8s instance.
Attach the policy created in Create an AWS Cloudwatch Policy.

Configure the AWS Verified Access Plugin

In Cloud Exchange, go to Settings > Plugins. Search for and select the AWS Verified Access v1.0.0 (CRE) plugin box.
Enter a Configuration Name, and modify the Sync Interval is needed.
Click Next. Select “Deployed on AWS” if an instance is deployed on AWS.
Enter the Configuration Parameters:
- Authentication Method: Select the method to be used for authentication (Deployed on AWS/AWS IAM Roles Anywhere)
- Private Key: Private Key for decrypting the AWS Private CA Certificate. Required for AWS IAM Roles Anywhere authentication type.
- Certificate Body: Certificate Body for AWS Public/Private CA Certificate. Required for AWS IAM Roles Anywhere authentication type.
- Password Phrase: Password Phrase for decrypting the CA Certificate. Required for AWS IAM Roles Anywhere authentication type.
- Profile ARN: AWS Profile ARN for AWS client authentication. Required for AWS IAM Roles Anywhere authentication type.
- Role ARN: AWS Role ARN for AWS client authentication. Required for AWS IAM Roles Anywhere authentication type.
- Trust Anchor ARN: AWS Trust Anchor ARN for AWS client authentication. Required for AWS IAM Roles Anywhere authentication type.
- Region Name: Region in which Verified Access service is running. Make sure that the region name matches the region in the Profile ARN and Trust Anchor ARN.
- CloudWatch Log Group Name: The log group name to fetch the user details from Verified Access logs. To get the log group name go to CloudWatch > Log Groups.
- Initial Range (in days): Number of days to sync the data. In every plugin run data from the provided days will be synced.
Notes
- Only Initial Range, CloudWatch Log Group Name, region is mandatory when “Deployed on AWS” is selected in “Authentication method”.
- If a user wants to configure a plugin in other than an AWS instance then need to generate the configuration parameters by the steps mentioned in the IAM Role Anywhere Configuration section.
Click Next. Select the Entity from the Entity dropdown. The Entity fields can be created from the Schema editor page, or using the + Add Field option from the field dropdown. Provide the field mappings. For the suggested mapping, refer to the Mappings section.
Click Save. Your new plugin appears on the Risk Exchange Plugin page.

Add a Risk Exchange Business Rule for AWS Verified Access

In Risk Exchange, go to Business Rules.
Click Create New Rule.
Enter a Rule Name, and select the Entity in which fields were mapped while configuring the plugin, and then provide filters as needed.
Click Save.

Add Risk Exchange Actions for AWS Verified Access

The AWS Verified Access plugin supports the following action type:

No Action

This action does not perform any action on the users, but can generate alerts in Ticket Orchestrator if the Generate Alerts toggle button is enabled.

NOTE: Refer to the Netskope guide in order to configure Netskope related actions for the user records pulled from AWS Verified Access CloudWatch log group. To configure the other actions supported by Netskope, refer to the Risk Exchange plugins guide.

To configure this action:

In Risk Exchange, go to Actions and click Add Action Configuration.
Select your Business Rule, plugin Configuration, and select No action in Actions dropdown. Turn on the Require Approval toggle if approval is required before performing the Generate Alert action. Click Save.
Manual Sync the action if users are already present in Records. To Validate the generated alerts go to Ticket Orchestrator Module > Alerts.
Click Save.

Validate the AWS Verified Access Plugin

Validate on Cloud Exchange

To validate the pulling of users from the Log group.

Go to the Logging in Cloud Exchange. Search for the plugin logs.
In Risk Exchange, go to Records, and select the Entity that was selected while configuring the AWS Verified Access plugin to view the pulled users.

Data is pulled from the log streams present inside a CloudWatch log group attached with a verified access instance. Go to CloudWatch > Log groups > awsverifiedaccesslogs. Log Streams will be available; the users available in these log streams will be pulled.

Troubleshooting the AWS Verified Access Plugin

Unable to configure the CRE AWS Verified Access plugin.

If you are unable to configure the AWS Verified Access plugin, it could be due to one of these reasons:

For the authentication method IAM role anywhere, Certificate and other configuration parameters may not be present in the same region.
For the authentication method IAM role anywhere, any steps are missing while creating Role ARN, Trust anchor ARN, Profile ARN.
If the Netskope CE is deployed on AWS using the Deployed on AWS authentication method, the proper role is not attached to the EC2 instance.
There are invalid values provided to the configuration parameters.
IAM permissions are not provided to the user on the AWS platform.

To solve these issues, follow these steps:

Make sure that the certificate and other configuration parameters are created in the same region.
Make sure to follow the steps IAM Role Anywhere Configuration to not miss any step.
Make sure to follow the Role Assign section to assign a proper role to the EC2 instance.
Make sure valid values are provided in the configuration parameters. Go to the Logging page and verify the log message.
Provide the IAM permissions to the user for which configuration parameters were created.

Unable to pull/view users from the CRE AWS Verified Access

If you are unable to pull users from AWS Verified Access, then it could be due one of these reasons:

Users are not present in the log group.
Proper policy is not attached to the role or EC2 instance.
Logs are not generated in the log group.
Users are pulled but in Records the users are displayed in a row with comma-separated values.

To solve these issues, follow these steps:

In the AWS console, go to CloudWatch > Log groups. Select the log group provided in plugin configuration. Verify if any users exist there.
Attach the policy properly by following the Create an AWS CloudWatch policy and Create IAM Role steps.
Verify the created Verified access setup and attachment to the log group. To verify the attachment follow the Attach the log group with the Verified Access instance steps.
Make sure that the fields created in an entity are marked as unique.

Limitation

Users can be fetched from a single log group at a time, because from AWS only one log group can be attached to the Verified Access instance. You can update the name of the log group if you need to pull users from another log group, or configure a new plugin with a different log group name.

AWS Verified Access v1.0.0 Plugin for Risk Exchange