AWS
AWS (Amazon Web Services) is a comprehensive, evolving cloud computing platform provided by Amazon that includes a mixture of infrastructure as a service (IaaS), platform as a service (PaaS) and packaged software as a service (SaaS) offerings.
Amazon Elastic Container Registry (ECR) is a fully-managed Docker container registry that makes it easy for developers to store, manage, and deploy Docker container images. Amazon ECR is integrated with Amazon Elastic Container Service (ECS), simplifying development to production workflow.
Amazon CloudWatch is a monitoring and management service that provides data and actionable insights for AWS, hybrid, and on-premises applications and infrastructure resources.
Connecting your AWS account to our system will allow us to analyze it and find vulnerabilities regarding IaC and Artifact integrity, using our own tools as well as other security tools such as Prowler.
The connection is being established by giving us (and only us) permissions for specific, carefully picked resources/ policies that will enable us to run the tools on them.
Connection options
Automatic
A sort of "plug-and-play" to connect a single AWS account, everything is pre-configured to what we need in order to run our tools, it will automatically create for you the user, role, and policies that we require, all you have to do is follow the instructions.
Log in to your AWS console.
Under the Automatic tab, click the 'Cloud Formation Assume Role' button.
On the CloudFormation page: 3.1. Check the two acknowledgment boxes at the bottom. 3.2. Click Create stack. Note: if you have already created a Cloud Formation stack before for ox-security you will need to rename the stack name, otherwise it will issue an error (Stack [ox-security] already exists)
Once the stack has been created, open CloudFormation outputs and copy the OxRoleArn value
In the OX Connector below paste the value in the field AWS Role ARN.
Click Connect.
You should receive a message that the connection was successful, if not please repeat the steps above.
Manual
This is a more advanced way of configuration for companies who want to create all the user/ roles/ policies that we need themselves.
Log in to your AWS console.
Create a new role in the AWS IAM Console.
Select Another AWS account for the Role Type.
For Account ID, enter 351456651185 (OX's account ID). This means that you are granting OX read only access to your AWS data.
Select Require external ID and enter the one generated in the OX AWS integration tile. Make sure you leave Require MFA disabled.
Click Next: Permissions.
In the Attach permissions policies screen Filter policies search and include the following policies:
ViewOnlyAccess
SecurityAudit
Click Next: Tags and Next: Review.
Name the Role OxAWSIntegrationRole or one of your own choosing, and provide an appropriate description.
Click Create Role
Once the Role creation is complete, open the Role and copy the Role ARN value.
In the OX Connector below paste the value in the field AWS Role ARN.
Click Connect.
You should receive a message that the connection was successful, if not please repeat the steps above.
Organization
In case you have multiple AWS accounts, this configuration is the right one for you. By connecting your AWS management account to our system we will be able to scan all of the accounts under it for vulnerabilities.
The way we do it is similar to the automatic connection (meaning we do the heavy lifting for you by creating all the assets needed), with an extra step to connect your management account with all of the accounts under it.
Log into your AWS console and navigate to the CloudFormation service.
Click on 'StackSets' and then 'Create StackSet'.
In the Choose a template page:
Under 'Permissions' select the 'Service-managed permissions' option.
Under 'Prerequisite - Prepare template' make sure the 'Template is ready' option is selected.
Under 'Specify template' select the 'Amazon S3 URL' option.
Under 'Amazon S3 URL' paste the following link 'https://dev-ox-cloudformation-template.s3.eu-west 1.amazonaws.com/aws/dev_ox_aws_integration_stackset_template.yml'.
Click Next.
In the Specify StackSet details page:
Set StackSet name 'ox-security' (note - it has to be unique from other stackset names).
Change the description if you want.
Set 'External Id' - paste the 'AWS External ID' we generated for you below.
Make sure 'IAMRoleName' and 'OxAWSAccountId' are already filled.
Click Next.
In the Configure StackSet options page:
Under 'Execution configuration' make sure 'Managed execution' is set to 'Inactive'.
Click Next.
In the Set deployment options page:
Set 'Add stacks to stack set' to 'Deploy new stacks'.
Set 'Deployment targets' to 'Deploy to organization'.
Set 'Automatic deployment' to 'Enabled'.
Set 'Account removal behavior' to 'Delete stacks'.
In the 'Specify regions' section select the region your organization is in.
In the 'Deployment options' section set 'Maximum concurrent accounts' to 1, 'Failure tolerance' to 0 and 'Region Concurrency' to 'Sequential'.
Click Next.
Review the configuration:
Check that the configuration is correct and change if necessary.
Check the 'I acknowledge that AWS CloudFormation...' checkbox under the 'Capabilities' section and click 'Submit'.
You have now successfully deployed the StackSet.
Click the 'Cloud Formation Assume Role' button below.
On the CloudFormation page:
Check the acknowledgement box at the bottom.
Click Create stack.
Note: if you already created a Cloud Formation stack before for ox-security you will need to rename the stack name otherwise it will issue an error (Stack [ox-security] already exists).
Once the stack has been created, open CloudFormation outputs, copy the OxRoleArn value and paste it in the 'AWS Role ARN' below.
Click Connect.
You should receive a message that the connection was successful, if not please repeat the steps above.
When using “Service-managed permissions” (Enabled in AWS Organizations), the parent/admin account has a stack set admin role named AWSServiceRoleForCloudFormationStackSetsOrgAdmin, while the child/target accounts have the stack set execution role named stacksets-exec-<id>. As the name suggests, the CloudFormation service automatically adds both roles to their respective accounts to establish the trust relationship. However, this method only adds the default trust and permission policies (administrative access), and does not allow the user to customize the IAM roles when they are created. Please note that some CSPM Tools might flag this role as a violation, thus it is recommended to remove the stacksets-exec-<id> role from the target accounts.
Last updated