Amazon Web Services (AWS) is a cloud hosting platform that offers cloud computing and infrastructure services.
Secureframe scans various AWS resources and configurations to ensure compliance and automatically gather evidence.
Connecting the Integration
To integrate AWS with Secureframe, navigate to Integrations and search for “AWS” on the “Available Integrations” page. (If you have the Custom Integration feature, click on "Add native connection"). Click “Connect” and follow the steps in the connection form.
Secureframe integrates with both Organization & Account. To connect an Account, an Organization must also be connected.
Additional AWS settings can be found via Integrations>AWS>Settings where you may add and remove specific regions.
Integration Requirements
To successfully complete the AWS integration with Secureframe, the following conditions must be met: AWS Security Token Service (STS) must be enabled in all applicable regions.
Note: If your organization is served from our UK data center (including EU-based customers using this option), STS must be enabled specifically in the eu-west-2 (London) region. If this region is disabled in your AWS configuration, the integration may fail. This requirement is due to AWS regional API behavior and cannot be bypassed at this time.
Connecting at different levels of the hierarchy (Organization & Account)
AWS allows users to manage connections at various levels in the hierarchy e.g. Organization, Organization Units and Member Accounts. Secureframe allows you to integrate with the Organization level as well as the member account (child) connection in order to:
- Make it easier to pull in and set up multiple account connections under an organization at once, allowing you to save time
- Provide a cleaner experience in organizing and managing the different levels of the hierarchy enabled in your AWS account
- Make it easier to identify accounts by automatically discovering accounts associated to your organization
- Make it easier to exclude the accounts that you do not want to sync with Secureframe
Manage connections/sync
You can now easily manage your account (child) connections directly from the Integrations page.
- To sync all accounts under a connection click the sync button
- In order to sync or manage only specific accounts under a connection, click the # of connections
- You can now view and manage the settings, rename the connection, reconnect and archive an account (child) account directly from this screen
- You can also view and change included regions and accounts if you click into the AWS integration settings (cogwheel icon).
Migrating existing connections in Secureframe to Parent/Child connections
If you already have multiple AWS accounts set up as separate connections in Secureframe and you want to take advantage of managing your connections through the parent/child connection, follow these steps:
- Archive any individual existing account connections you have that you are expecting to be pulled in by the organization (management account) connection. Note: if you have any account connections that you’re not expecting to be brought in by the organization connection, you do not need to archive those account connections in Secureframe.
-
- Click the kebab menu on individual account connections.
- Click Archive.
-
- Once your connections have been archived, click on available connections, search for “AWS” and click “Add connection” or “Connect” under AWS.
- Follow the steps outlined in the connection form for organization. The “root management” account is the one that has to be integrated with Secureframe. When you click “Create stack” in step 2, the CloudFormation stack will create an AWS Stack in your account. You may then navigate to AWS StackSets and deploy it to all target accounts. You may also choose to skip this step and manually create this role if you do not want to use the Secureframe CloudFormation stack. Please refer to the AWS documentation if doing manually.
- Go to your AWS StackSet and deploy the created SecureframeOrgRoles StackSet, ensure you have automatic deploys enabled so new accounts added to the organization will automatically get the role.
- In step 6 of the connection form, you will be able to view a list of member accounts/child connections and select those you wish to integrate with Secureframe. These can be changed later via the integration settings.
- Click Finish. When completed, you will now be able to see the number of child connections under an organization account (and their details) directly in the main integrations page.
- When you click on the number of child connections, you will be able to see details of the child connections and be able to:
- Filter through child accounts
- Sync individual child connections or sync all child connections under the organization
- Rename the connection (organization or child)
- Exclude any individual child connections you don’t want integrated with Secureframe
ECR & Region Considerations
Deployment Regions - Yes, you can deploy the Secureframe CloudFormation stack in any AWS region—not just us‑west‑2 —even when integrating with AWS Organizations. Region selection does not impact Secureframe’s ability to function or pull account data.
ECR Scanning Behavior -Secureframe scans AWS ECR repositories using only the latest image tag by default. If a latest tag isn't present, it scans the most recently pushed image instead. Older tags with vulnerabilities are not continuously reported unless they match one of those conditions.
Supported Regions
The AWS regions supported through the Secureframe integration include:
- "us-east-1",
- "us-east-2",
- "us-west-1",
- "us-west-2",
- "eu-west-3",
- "eu-west-2",
- "eu-west-1",
- "eu-north-1",
- "eu-central-1",
- "sa-east-1",
- "ca-central-1",
- "ap-southeast-2",
- "ap-southeast-1",
- "ap-south-1",
- "ap-northeast-3",
- "ap-northeast-2",
- "ap-northeast-1",
# Regions below require opt in see https://docs.aws.amazon.com/general/latest/gr/rande-manage.html
- "af-south-1",
- "ap-east-1",
- "ap-south-2",
- "ap-southeast-3",
- "ap-southeast-4",
- "eu-central-2",
- "eu-south-1",
- "eu-south-2",
- "me-central-1",
- "me-south-1"
Region Selection for CloudFormation Stack
Secureframe does not require that you deploy the CloudFormation stack in us-west-2.
Whether you're setting up a single AWS account or integrating via AWS Organizations, you can choose any AWS region during the connection process.
After clicking the “Create Stack” button in the connection setup flow, simply use the region dropdown in the top-right corner of the AWS CloudFormation console to switch to your preferred region before proceeding with the deployment.
📌 There is no need to manually download and re-upload the template — region selection can be done directly in the AWS console.
⚠️ Important
Do not modify the automatically generated ExternalID or StackIdentifier, as these are critical for establishing and maintaining a secure connection with Secureframe.
Permissions, Fields Pulled, Controls and Automated Tests
- Click the provided link or navigate to the “Integration” page.
- Select the “Available” tab.
- Search for the integration.
- Click “View Details”.
Evidence Types
Secureframe pulls evidence for dozens of types of AWS resources and their configuration as it relates to security and compliance, including:
- EC2 Instances
- S3 Buckets
- IAM Roles and their associated policies AWS Inspector vulnerability reports
Update the Scan Stack for AWS CloudFormation
Secureframe has identified permission updates for AWS that need to be applied in all customer accounts to ensure that scans continue to perform correctly. The template URL specified below contains our most recent iteration of the permissions needed for Secureframe Scans. The file can be opened with most text editors.
Use these instructions to update the AWS Secureframe CloudFormation Stack with the latest template:
- In your AWS account, navigate to the AWS region where the Secureframe Stack was created when the AWS Connection and CloudFormation page were first created. The default is the us-west-2 region.
- Refer to these instructions to update an AWS CloudFormation stack (console).
- Specifyhttps://secureframe-templates.s3-us-west-2.amazonaws.com/secureframe.template for the Amazon S3 URL of the template file.
- Ifus-west-2 is a disabled region, download the template file provided here and upload it directly.
- DO NOT change the existing External ID Parameter and proceed to Step 5.
- This stack manages an IAM Role. Mark the checkbox for “I acknowledge that AWS CloudFormation might create IAM resources with custom names”.
- Click the button to update the stack.
Any permission issues with an individual test should be corrected by syncing the AWS integration after updating these permissions.
Stack Changelog
2023-05-31
These actions have been added to the policy:
- "ecs:GetTaskProtection"- "ses:GetEmailIdentity"- "wafv2:GetLoggingConfiguration"2023-02-24
The updated role continues to rely on the AWS SecurityAudit managed policy. Because AWS has updated the managed policy, we have removed many actions from the secureframe-additional-permissions policy that were duplicates.
These actions have been added to the policy:
- "elasticfilesystem:DescribeBackupPolicy"- "elastictranscoder:ListPipelines"- "es:ListVpcEndpoint*"- "ses:ListEmailIdentities"- "wafv2:GetWebACLForResource"AWS Identity Center
We’ve enhanced our AWS integration to include AWS Identity Center. With this update, the Access tab will now display a broader set of users, thanks to the automatic sync with AWS Identity Center. Organizations do not need to take any action to benefit from this improvement—the user list will update automatically to reflect additional users in your AWS environment.
UK-Based Customers
For UK-based customers, Secureframe’s backend is hosted in the eu-west-2 (London) AWS region.
To support secure, temporary access credentials, Secureframe uses AWS Security Token Service (STS). Because the backend resides in eu-west-2, STS must be enabled in that region for the integration to work correctly.
If STS is disabled in eu-west-2, connection errors may occur. You can enable STS for that region in your AWS account by following AWS's instructions on managing regional STS endpoints.
Remediating AWS Parent/Child Connection Error
An error may occur when migrating an existing AWS integration in Secureframe to parent/child connections. If you experience this error take the following steps to remediate the issue.
- Go into the AWS Console > CloudFormation > StackSets. You should see a StackSet called SecureframeOrgRoles.
-
Open the stackset and select add stacks to StackSet.
- Select deploy new stacks and deploy to organization.
-
Under “Specify Regions”, select any region
- Click Next, and then Submit
- Go to stack instances under the secureframe org roles stackset and you should see deployments happening to the accounts in the organization. Wait for the stackset to deploy to ALL accounts in the org,
- Resync your existing AWS connection in Secureframe.
Remediating AWS test errors
If you experience the following error:
Here are the recommended steps to remediate this error:
Perform the following steps to setup the metric filter, alarm, SNS topic, and subscription.For each step, you will need to replace the pieces of each command that are in angle brackets, i.e. <piece>, with the appropriate value for your account.
If you get errors about names, you may need to quote your values with single or double quotes.
1. Create a metric filter based on filter pattern provided which checks for cloudtrail configuration changes and the '<cloudtrail_log_group_name>' taken from audit step 1.
aws logs put-metric-filter --log-group-name <cloudtrail_log_group_name> --filter-name <cloudtrail_cfg_changes_metric> --metric-transformations metricName=<cloudtrail_cfg_changes_metric>,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = CreateTrail) || ($.eventName = UpdateTrail) || ($.eventName = DeleteTrail) || ($.eventName = StartLogging) || ($.eventName = StopLogging) }'**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together.
2. Create an SNS topic that the alarm will notify
aws sns create-topic --name <sns_topic_name>**Note**: you can execute this command once and then re-use the same topic for all monitoring alarms.
3. Create an SNS subscription to the topic created in step 2
aws sns subscribe --topic-arn <sns_topic_arn> --protocol <protocol_for_sns> --notification-endpoint <sns_subscription_endpoints>**Note**: you can execute this command once and then re-use the SNS subscription for all monitoring alarms.
4. Create an alarm that is associated with the CloudWatch Logs Metric Filter created in step 1 and an SNS topic created in step 2
aws cloudwatch put-metric-alarm --alarm-name <cloudtrail_cfg_changes_alarm> --metric-name <cloudtrail_cfg_changes_metric> --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions <sns_topic_arn>AWS Errors
AWS Common Error Messages Help Article
AWS GovCloud
Secureframe now offers the ability to connect and sync resources from AWS GovCloud in addition to commercial cloud instances.
What Secureframe Creates in Your AWS Environment
The CloudFormation setup creates the following resources:
Single Account Connection:
-
CloudFormation Stack:
SecureframeRole-<unique-id> -
IAM Role:
SecureframeRole-<unique-id>with read-only permissions (SecurityAudit policy + additional read permissions)
Organization Connection:
-
CloudFormation Stack:
SecureframeOrgRole-<unique-id>in management account -
CloudFormation StackSet:
SecureframeOrgMembers-<unique-id>— automatically deploys the IAM role to member accounts -
IAM Role:
SecureframeOrgRole-<unique-id>in each account
All roles use cross-account trust with Secureframe's AWS account (728997465891) and require an External ID for security.
Common Test Questions
The CloudTrail S3 Bucket Server Access Logging test is failing. Since this is a log archive account, we don't sync it with Secureframe, could that be the issue?
- Yes, that is the issue. To evaluate this test we check to see if logging is enabled on the S3 bucket.
- If it is in an account that is not synced to Secureframe, then we cannot evaluate that and thus it would fail.
- If you have no plans to sync this bucket, you can ignore the result with a justification.
What’s the difference between the “Monitoring for Cloud Infrastructure,” “GuardDuty enabled (AWS),” and “CloudWatch Monitoring Metrics (AWS)” tests?
These three AWS-related tests each serve a different purpose from a compliance perspective:
| Test Name | Purpose | Compliance Context |
|---|---|---|
| Monitoring for Cloud Infrastructure | Verifies that basic logging and monitoring are enabled in your cloud environment. | General monitoring control — ensures logging is turned on somewhere. |
| GuardDuty enabled (AWS) | Checks that AWS GuardDuty is enabled for threat detection and anomaly alerts. | Not always required, but threat detection is a common expectation. |
| CloudWatch Monitoring Metrics (AWS) | Validates that AWS CloudWatch metrics are actively collecting monitoring data. | Another form of logging; often overlaps with the first test. |
✅ Note: You typically don’t need to pass both "Monitoring for Cloud Infrastructure" and "CloudWatch Monitoring Metrics" — they serve similar purposes.
🔐 Threat detection, however, is generally expected for most frameworks, even if GuardDuty itself isn’t mandatory.
Frequently Asked Questions (FAQ)
We have a few S3 buckets that do not have block public access enabled because those buckets are intentionally publicly accessible. How should we handle this test?
- Yes, the best course here is to ignore those failing tests and provide a reason explaining why they are publicly accessible.
Does Secureframe detect WAF implemented via Cloudflare and apply it to the AWS WAF test?
- No—Secureframe currently does not cross-reference Cloudflare WAF with the AWS-specific “Application Load Balancer WAF” test. The test is specifically checking if an AWS WAF is directly attached to the ALB, so Cloudflare—even if integrated—is not considered a “pass” for this test automatically.
- Assuming you want the tests to pass without marking the control as "not applicable" we recommend uploading a manual screenshot or PDF showing Cloudflare WAF settings/rules applied to the relevant endpoints. Include a brief explanation in the evidence description that Cloudflare WAF is protecting the ALBs instead of AWS WAF.
Our AWS integration is throwing an error regarding the enablement of STS in AWS in the eu-west-2 region, but this region is disabled in our AWS and they want to keep it that way?
- At this time, the integration requires AWS STS to be enabled in the eu-west-2 region for UK-based customers.
How can I prove that my EC2 instance is not in the default VPC?
- Check the VPC ID
- In the AWS Console, go to EC2 > Instances.
- Select your instance and find the VPC ID under the Networking tab.
- Then go to VPC > Your VPCs and find that VPC ID.
- If the "Default VPC" column is No, it’s not the default.
Why am I seeing a KMS Key Policy permission error when using Secureframe?
- This error typically occurs for one of two reasons—either at the integration level or due to a restrictive KMS key policy. Below are the common scenarios and how to resolve them:
What should I do if the error is related to integration-level permissions?
- This means the Secureframe IAM role is missing a required permission. To fix it:
- Open the IAM console in AWS.
- Select the Secureframe role.
- Go to the Permissions tab.
- Find and edit the policy named secureframe-additional-permissions.
- Add the missing permission mentioned in the error message.
- Save the changes.
What should I do if the error is related to the KMS key policy itself?
- This happens when the Secureframe-assumed STS role doesn't have access to the KMS key due to a restrictive key policy. To resolve it:
- Open the AWS KMS console and select the affected key.
- Review the key’s resource policy.
- Ensure the Secureframe role is explicitly granted the necessary permissions (e.g., kms:DescribeKey, kms:Decrypt).
- Save the updated policy.
Can I deploy the CloudFormation stack in a region other than us-west-2 for an AWS Organizations integration?
us-west-2.If you prefer to use a different AWS region:
- You can download the CloudFormation template and upload it manually to any region that fits your infrastructure setup.
- The region you choose does not impact the integration’s functionality, even for AWS Organizations.
- Just be sure to follow the setup steps provided in the AWS integration builder flow within the Secureframe platform, and do not modify the auto-generated
External ID.
For organizations managing a large number of AWS accounts, integrating via AWS Organizations is fully supported — and region selection will not affect Secureframe’s ability to pull account details and activity.
Is there a way to prevent new AWS accounts from automatically being onboarded into Secureframe?
Yes. Secureframe distinguishes between user accounts and member accounts in AWS:
User accounts (individual IAM users) must always be tracked for SOC 2 compliance.
Member accounts (new AWS accounts created under your AWS Organization) can be included or excluded during the integration setup.
If you want to exclude new member accounts (for example, when giving each new employee a personal AWS account), you’ll need to adjust your AWS integration configuration. In some cases, this may require reconnecting the integration and selecting only the organizational units (OUs) or specific accounts you want monitored. (Tip: This allows you to keep compliance scope limited to production, staging, or shared environments, while excluding personal/development accounts that don’t need SOC 2 coverage.)
How does Secureframe check and report vulnerabilities for AWS ECR images when multiple tags exist?
- Secureframe scans AWS ECR repositories against the latest tag by default. If a
latesttag does not exist, the system will instead scan the most recently pushed image, regardless of its tag. This ensures Secureframe is always evaluating the most up-to-date image in your repository. Vulnerabilities from older or inactive tags are not continuously synced—only the most recent image (latest tag or most recent push) is considered in reporting.
Related to
Comments
0 comments
Article is closed for comments.