Security OU – Security Tooling account
The following diagram illustrates the AWS security services that are configured in the Security Tooling account.
The Security Tooling account is dedicated to operating security services, monitoring AWS accounts, and automating security alerting and response. The security objectives include the following:
Provide a dedicated account with controlled access to manage access to the security guardrails, monitoring, and response.
Maintain a centralized security infrastructure to monitor security operations data and maintain traceability. Detection, investigation, and response are essential parts of the security lifecycle and support quality processes, legal or compliance obligations, and threat identification and response efforts.
Further support a defense-in-depth organization strategy by maintaining another layer of control over appropriate security configuration and operations such as encryption keys and security group settings. This is an account where security operators work. Security Tooling account access SHOULD default to read-only/audit roles. Write/modify roles MUST be limited in number, and their use MUST be monitored and logged.
Design considerations:
AWS Control Tower names the account under the Security OU the Audit Account by default. You can rename the account during the AWS Control Tower setup.
You can have more than one Security Tooling account. For example, monitoring and responding to security events are often assigned to a dedicated team. Network security might warrant its own account and roles in collaboration with the cloud infrastructure or network team. Such splits retain the objective of separating centralized security enclaves and further emphasize the separation of duties, least privilege, and potential simplicity of team assignments. If you are using AWS Control Tower, it restricts the creation of additional AWS accounts under the Security OU.
Delegated administrator for security services
The Security Tooling account serves as the administrator account for security services that are managed in an administrator/member structure throughout the AWS accounts. This is handled through the AWS Organizations delegated administrator functionality to manage these services. Services in the AWS SRA that currently support delegated administrator include IAM centralized management of root access, AWS Config, AWS Firewall Manager, Amazon GuardDuty, IAM Access Analyzer, Amazon Macie, AWS Security Hub, AWS Security Hub CSPM, Amazon Detective, AWS Audit Manager, Amazon Inspector, AWS CloudTrail, Amazon CloudWatch and AWS Systems Manager. Your security team manages the security features of these services and monitors any security-specific events or findings.
AWS IAM Identity Center supports delegated administration to a member account. AWS SRA uses the Shared Services account as the delegated administrator account for IAM Identity Center, as explained later in the IAM Identity Center section of the Shared Services account.
Centralized root access
The Security Tooling account is the delegated administrator account for IAM centralized management of root access capability. This capability must be enabled at the organization level by enabling credential management and privileged root actions in member accounts. Delegated administrators have to be provided sts:AssumeRoot permissions explicitly to be able to take privileged root actions on behalf of member accounts. This permission is available only after privileged root action in a member account is enabled in the Org Management or delegated administrator account. With this permission, users can perform privileged root user tasks on member accounts, centrally from the Security Tooling account. After you launch a privileged session, you can delete a misconfigured S3 bucket policy, delete a misconfigured SQS queue policy, delete the root user credentials for a member account, and reenable root user credentials for a member account. You can perform these actions from the console, by using the AWS Command Line Interface (AWS CLI) or through APIs.
AWS CloudTrail
AWS CloudTrail
In the AWS SRA, the Security Tooling account is the delegated administrator account for managing CloudTrail. The corresponding S3 bucket to store the organization trail logs is created in the Log Archive account. This is to separate the management and usage of CloudTrail log privileges. For information about how to create or update an S3 bucket to store log files for an organization trail, see the CloudTrail documentation. The organization trail S3 bucket policy, KMS key policy, and SNS topic policy SHOULD include an aws:SourceArn condition. This ensures that the S3 bucket accepts only data that is associated with the specific trail. The trail is configured with log file validation for log file integrity validation. The log and digest files are encrypted by using SSE-KMS. The organization trail is also integrated with a log group in CloudWatch Logs to send events for long-term retention.
Note
You can create and manage organization trails from both management and delegated administrator accounts. However, as a best practice, access to the management account MUST be limited. The organization trail SHOULD be managed from a CloudTrail delegated administrator account.
Design considerations:
CloudTrail does not log data events by default because these are often high-volume activities. However, you should capture data events for specific critical AWS resources, such as S3 buckets, Lambda functions, log events from outside AWS that are either sent to Amazon S3 or forwarded using Amazon SQS and Amazon SNS topics. To do this, configure your organization trail to include data events from specific resources by specifying the Amazon Resource Name (ARN) of each resource.
If a member account requires access to CloudTrail log files for its own account, you can selectively share the organization's CloudTrail log files from the central S3 bucket. However, if member accounts require local Amazon CloudWatch Logs log groups for their account's CloudTrail logs or want to configure log management and data events (read-only, write-only, management events, data events) differently from the organization trail, they can create a local trail with the appropriate controls. Local account-specific trails incur additional cost
.
AWS Security Hub CSPM
AWS Security Hub Cloud Security Posture Management
Security Hub CSPM integrates with AWS Organizations to simplify security posture management across all your existing and future accounts in your AWS organization. You MUST use the Security Hub CSPM central configuration feature from the delegated administrator account (in this case, Security Tooling) to specify how the Security Hub CSPM service, security standards, and security controls are configured in your organization accounts and organizational units (OUs) across Regions. You can configure these settings in a few steps from one primary Region, which is referred to as the home Region. If central configuration is not used, you MUST configure Security Hub CSPM separately in each account and Region. The delegated administrator can designate accounts and OUs as self-managed, where the member can configure settings separately in each Region, or as centrally managed, where the delegated administrator can configure the member account or OU across Regions. You MAY designate all accounts and OUs in your organization as centrally managed, all self-managed, or a combination of both. This simplifies the enforcement of a consistent configuration while providing the flexibility to modify it for each OU and account.
The Security Hub CSPM delegated administrator account can also view findings, view insights, and control details from all member accounts. You MUST designate an home Region within the delegated administrator account to centralize your findings across your accounts and your linked Regions. Your findings are continuously and bidirectionally synced between the home Region and all other Regions.
Security Hub CSPM supports integrations with several AWS services. Amazon GuardDuty, AWS Config, Amazon Macie, IAM Access Analyzer, AWS Firewall Manager, Amazon Inspector, Amazon Route 53 Resolver DNS Firewall, and AWS Systems Manager Patch Manager can feed findings to Security Hub CSPM. Security Hub CSPM processes findings by using a standard format called the AWS Security Finding Format (ASFF). Security Hub CSPM correlates the findings across integrated products to prioritize the most important ones. You MAY enrich the metadata of Security Hub CSPM findings to help better contextualize, prioritize, and take action on the security findings. This enrichment adds resource tags, a new AWS application tag, and account name information to every finding that's ingested into Security Hub CSPM . This helps you fine-tune findings for automation rules, search or filter findings and insights, and assess security posture status by application. In addition, you MAY use automation rules to automatically update findings. As Security Hub CSPM ingests findings, it can apply a variety of rule actions, such as suppressing findings, changing their severity, and adding notes to findings. These rule actions take effect when findings match your specified criteria, such as the resource or account IDs the finding is associated with, or its title. You MAY use automation rules to update select finding fields in the ASFF. Rules apply to both new and updated findings.
During the investigation of a security event, you can navigate from Security Hub CSPM to Amazon Detective to investigate a GuardDuty finding. The delegated administrator account for Security Hub CSPM and Amazon Detective SHOULD be the same account; otherwise, finding pivots to Detective do not work. For a comprehensive list, see Overview of AWS service integrations with Security Hub CSPM in the Security Hub CSPM documentation.
You can use Security Hub CSPM with the Network Access Analyzer
In addition to its monitoring features, Security Hub CSPM supports integration with Amazon EventBridge to automate the remediation of specific findings. You MAY define custom actions to take when a finding is received. For example, you can configure custom actions to send findings to a ticketing system or to an automated remediation system. For additional discussions and examples, see the AWS blog posts Automated response and remediation with AWS Security Hub CSPM
Security Hub CSPM uses service-linked AWS Config Rules to perform most of its security checks for controls. To support these controls, AWS Config MUST be enabled in every account (including the delegated administrator) in every Region where Security Hub CSPM is enabled.
Amazon CloudWatch supports ingesting AWS Security Hub CSPM findings. This helps you centrally analyze and monitor security findings directly in CloudWatch Logs. Security Hub CSPM findings are supported in ASFF and Open Cybersecurity Schema Framework (OCSF) format using CloudWatch Pipelines, providing standardized security data ingestion. You can use CloudWatch Logs Analytics to query findings, create metric filters for monitoring, and you can use Amazon S3 Tables integration for advanced analytics. This helps security teams identify and respond to threats faster across your AWS environment. We recommend creating a CloudWatch telemetry enablement rule that sends Security Hub findings to CloudWatch Logs for all production accounts.
Design considerations:
If a compliance standard, such as PCI-DSS, is already present in Security Hub CSPM, the fully managed Security Hub CSPM service is the easiest way to operationalize it. However, if you want to assemble your own compliance or security standard, which might include security, operational, or cost optimization checks, AWS Config conformance packs offer a simplified customization process. (For more information about AWS Config and conformance packs, see the AWS Config section.)
Common use cases for Security Hub CSPM include the following:
As a dashboard that provides visibility for application owners into the security and compliance posture of their AWS resources
As a central view of security findings used by security operations, incident responders, and threat hunters to triage and take action on AWS security and compliance findings across AWS accounts and Regions
To aggregate and route security and compliance findings from across AWS accounts and Regions, to a centralized security information and event management (SIEM) or other security orchestration system
For additional guidance on these use cases, including how to set them up, see the blog post Three recurring Security Hub CSPM usage patterns and how to deploy them
.
Implementation example:
The AWS SRA code library
provides a sample implementation of Security Hub CSPM . It includes automatic enablement of the service, delegated administration to a member account (Security Tooling), and configuration to enable Security Hub CSPM for all existing and future accounts in the AWS organization.
AWS Security Hub
AWS Security Hub is a unified cloud security solution that prioritizes your critical security threats and helps you respond at scale. Security Hub detects security issues in near real time by automatically correlating and enriching security signals from multiple sources, such as posture management (AWS Security Hub CSPM), vulnerability management (Amazon Inspector), sensitive data (Amazon Macie), and threat detection (Amazon GuardDuty). Security Hub findings relate to exposure, unused access, policy recommendation and network scanning. This enables security teams to prioritize active risks in their cloud environments through automated analyses and contextual insights. Security Hub provides a visual representation of the potential attack path that attackers can exploit to gain access to resources associated with an exposure finding. This transforms complex security signals into actionable insights, so you can make informed decisions about your security quickly.
Security Hub is redesigned to simplify the enablement of associated security service building blocks to arrive at a security outcome. By correlating security findings in a threat matrix across different security signals in near real time, you can prioritize the most critical risks first. The findings are correlated to detect exposure associated with AWS resources. Exposures represent broader weaknesses in security controls, misconfigurations, or other areas that could be exploited by active threats. instance that is reachable from the internet and has software vulnerabilities that have high likelihood of exploitation. Security Hub also programmatically discovers Azure resources, including Azure Virtual Machines (VMs), Azure Container Registry (ACR) container images, Azure Function Apps, and Azure identities, and evaluates them for misconfigurations, internet exposure, and software vulnerabilities. You receive posture checks against security standards including the CIS Benchmarks™ for Microsoft Azure Foundations, unified resource inventory, risk and exposure analysis, and automated response through existing EventBridge integrations. AWS and Azure findings appear in the same prioritized view with the same finding formats and automation workflows, so security teams can operate from one console rather than switching between tools.
Security Hub and Security Hub CSPM are complementary services. Security Hub CSPM provides a comprehensive view of your security posture and helps you evaluate your cloud environment against security industry standards and best practices. Security Hub provides a unified experience that helps you prioritize and respond to critical security issues. Security Hub CSPM findings are routed to Security Hub automatically, where they're correlated with findings from other security services, such as Amazon Inspector, to generate exposures. This helps you identify the most critical risks in your environment.
Security Hub also provides a summary of resources in your AWS environment by type and associated findings. Resources are prioritized by exposures and attack sequences. When you choose a resource type, you can review all the resources associated with that resource type.
Organizations SHOULD optimally enable Security Hub, Security Hub CSPM, as well as other security services: Amazon GuardDuty
In the AWS SRA, the Security Tooling account acts as the delegated administrator for Security Hub, Security Hub CSPM, and other AWS security services. Within the Security Tooling account you can view all resources associated with member accounts. You can also view all the resources in your home AWS Region from linked AWS Regions.
Note
Enabling Security Hub requires three steps, including procedures that take into account whether you have previously enabled Security Hub CSPM. Security Hub is natively integrated with AWS Organizations, which simplifies the configuration and implementation process, and centralizes and aggregates all findings into a single location. In accordance with the AWS SRA best practice, the Security Tooling account SHOULD be the delegated administrator account to manage and configure Security Hub. Security Hub SHOULD be configured to auto-enable in all Regions, OUs, and accounts, including future Regions and accounts. You SHOULD also set up cross-Region aggregation to aggregate findings, resources, and trends from multiple AWS Regions into a single home Region. During configuration, you MAY also enable any native integrations such as Jira Cloud or ServiceNow.
Design considerations:
Security Hub findings are formatted in the Open Cybersecurity Schema Framework (OCSF). Security Hub generates findings in OCSF and receives findings in OCSF from Security Hub CSPM and other AWS services. These OCSF findings can be sent over Amazon EventBridge for automations or stored in a central log aggregation account to perform security log analysis and retention.
The AWS Org Management account cannot designate itself as the delegated administrator in Security Hub. This aligns with the AWS SRA best practice of designating the Security Tooling account as the delegated administrator. Also note:
The designated administrator account for Security Hub CSPM automatically becomes the designated administrator for Security Hub.
Removing delegated administration through Security Hub also removes delegated administration for Security Hub CSPM. Likewise, removing delegated administration through Security Hub CSPM also removes it for Security Hub.
Security Hub includes features that automatically modify and take action on findings based on your specifications. Security Hub supports the following types of automations:
Automation rules, which automatically update findings, suppress findings, and send findings to ticketing tools in near real time based on defined criteria.
Automated response and remediation, which create custom EventBridge rules that define automatic actions to take against specific findings and insights.
Amazon GuardDuty
Amazon GuardDuty is a threat detection service that continuously monitors for suspicious activity and unauthorized behavior to protect your
Note
You MUST capture and retain logs for monitoring and audit independently of GuardDuty. GuardDuty's independent data streams MUST NOT be treated as a substitute for log retention.
In addition to providing foundational data sources, GuardDuty provides optional features to identify security findings. These include EKS Protection, RDS Protection, S3 Protection, Malware Protection, and Lambda Protection. You MAY enable these optional features based on your application requirements. GuardDuty MUST be configured to auto-enable for all new accounts in the AWS organization.
With GuardDuty S3 Protection, GuardDuty monitors Amazon S3 data events in CloudTrail in addition to the default CloudTrail management events. Monitoring data events enables GuardDuty to monitor object-level API operations for potential security risks to data within your S3 buckets.
GuardDuty Malware Protection detects the presence of malware on Amazon EC2 instances or container workloads by initiating agentless scans on attached Amazon Elastic Block Store (Amazon EBS) volumes. GuardDuty also detects potential malware in S3 buckets by scanning newly uploaded objects or new versions of existing objects.
GuardDuty RDS Protection for login activity analyzes login events for potential access threats to Amazon Aurora (Amazon Aurora MySQL-Compatible Edition and Aurora PostgreSQL-Compatible Edition), RDS for PostgreSQL, Amazon RDS for MySQL, and Amazon RDS for MariaDB databases.
GuardDuty EKS Protection includes EKS Audit Log Monitoring and EKS Runtime Monitoring. With EKS Audit Log Monitoring, GuardDuty monitors Kubernetes audit logs from Amazon EKS clusters and analyzes them for potentially malicious and suspicious activity. EKS Runtime Monitoring uses the GuardDuty security agent (which is an Amazon EKS add-on) to provide runtime visibility into individual Amazon EKS workloads. The GuardDuty security agent helps identify specific containers within your Amazon EKS clusters that are potentially compromised. It can also detect attempts to escalate privileges from an individual container to the underlying Amazon EC2 host or to the broader AWS environment.
GuardDuty AI Protection extends GuardDuty threat detection to AI workloads on AWS. GuardDuty analyzes AWS CloudTrail data events from Amazon Bedrock, Amazon Bedrock AgentCore, and Amazon SageMaker AI, along with AWS CloudTrail management events. GuardDuty uses this data to detect potentially suspicious activity that targets foundation models and the applications that invoke them. When GuardDuty identifies a potential threat, it generates one or more AI Protection finding types.
GuardDuty also provides a feature known as Extended Threat Detection that automatically detects multi-stage attacks that span data sources, multiple types of AWS resources, and time within an AWS account. GuardDuty correlates these events, which are called signals, to identify scenarios that present themselves as potential threats to your AWS environment, and then generates an attack sequence finding. This covers threat scenarios that involve compromise related to AWS credentials misuse, and data compromise attempts in your AWS accounts. GuardDuty considers all attack sequence finding types as Critical. This feature is enabled by default, and there is no additional cost associated with it.
In the AWS SRA, GuardDuty is enabled in all accounts through AWS Organizations, and all findings are viewable and actionable by appropriate security teams in the GuardDuty delegated administrator account (in this case, the Security Tooling account). Export GuardDuty findings to a central S3 bucket in the Log Archive account for retention beyond 90 days. The findings in the bucket S3 are encrypted with an AWS KMS customer managed key. The
When AWS Security Hub CSPM is enabled, GuardDuty findings automatically flow to Security Hub CSPM and Security Hub. When Amazon Detective is enabled, GuardDuty findings are included in the Detective log ingest process. GuardDuty and Detective support cross-service user workflows, where GuardDuty provides links from the console that redirect you from a selected finding to a Detective page that contains a curated set of visualizations for investigating that finding. For example, you MAY also integrate GuardDuty with Amazon EventBridge to automate best practices for GuardDuty, such as automating responses to new GuardDuty findings.
Design considerations:
If you have a multi-Region architecture you SHOULD use GuardDuty organization policy to enable GuardDuty per Region and apply default configuration. You can add a Regional override to give a specific Region a different configuration. The default configuration is optional. If you omit it, only the Regions you specify are managed, and every other Region is left unmanaged.
Implementation example:
The AWS SRA code library
provides a sample implementation of GuardDuty . It includes encrypted S3 bucket configuration, delegated administration, and GuardDuty enablement for all existing and future accounts in the AWS organization.
AWS Config
AWS Config
You can evaluate the configuration settings of your AWS resources by using AWS Config Rules. AWS Config provides a library of customizable, predefined rules called managed rules, or you can write your own custom rules. You can run AWS Config Rules in proactive mode (before resources have been deployed) or detective mode (after resources have been deployed). Organizations SHOULD run AWS Config rules in detective mode (after resources have been deployed) and MAY additionally run supported rules in proactive mode (before resources have been deployed) . Resources can be evaluated when there are configuration changes, on a periodic schedule, or both.
A conformance pack is a collection of AWS Config rules and remediation actions that can be deployed as a single entity in an account and Region, or across an organization in AWS Organizations. Conformance packs are created by authoring a YAML template that contains the list of AWS Config managed or custom rules and remediation actions. To get started evaluating your AWS environment, use one of the sample conformance pack templates.
AWS Config integrates with AWS Security Hub CSPM to send the results of AWS Config managed and custom rule evaluations as findings into Security Hub CSPM.
AWS Config Rules can be used in conjunction with AWS Systems Manager to effectively remediate noncompliant resources. You use Systems Manager Explorer to gather the compliance status of AWS Config rules in your AWS accounts across AWS Regions and then use Systems Manager Automation documents (runbooks) to resolve your noncompliant AWS Config rules. For implementation details, see the blog post Remediate noncompliant AWS Config rules with AWS Systems Manager Automation runbooks
The AWS Config aggregator collects configuration and compliance data across multiple accounts, Regions, and organizations in AWS Organizations. The aggregator dashboard displays the configuration data of aggregated resources. Inventory and compliance dashboards offer essential and current information about your AWS resource configurations and compliance status across AWS accounts, across AWS Regions, or within an AWS organization. They enable you to visualize and assess your AWS resource inventory without needing to write AWS Config advanced queries.
If you use AWS Control Tower to manage your AWS organization, a set of AWS Config rules as detective guardrails. You MUST keep mandatory detective controls enabled, SHOULD enable strongly recommended controls, and MAY enable elective controls. These guardrails help you govern your resources and monitor compliance across accounts in your AWS organization. These AWS Config rules will automatically use an aws-control-tower tag that has a value of managed-by-control-tower.
AWS Config MUST be enabled for the management and each member account in the AWS organization and AWS Region that contains the resources that you want to protect. You should centrally manage (for example, create, update, and delete) AWS Config rules across all accounts within your AWS organization. The AWS Config delegated administrator SHOULD deploy a common set of organization Config rules to all accounts. Exclusions MAY be specified and SHOULD be documented. The AWS Config delegated administrator account SHOULD also aggregate resource configuration and compliance data from all member accounts to provide a single view. Organization Config rules MUST be deployed from the delegated administrator account so that member accounts cannot modify them. AWS Config is natively integrated to send findings to AWS Security Hub CSPM, if Security Hub CSPM is enabled and at least one AWS Config managed or custom rule exists.
In the AWS SRA, the AWS Config delegated administrator account is the Security Tooling account. The AWS Config delivery channel is configured to deliver resource configuration snapshots in a centralizedcentralized S3 bucket in the Log Archive account. Because the Log Archive account is the central log repository store, it is used to store resource configuration.
Design considerations:
AWS Config streams configuration and compliance change notifications to Amazon EventBridge. This means that you can use the native filtering capabilities in EventBridge to filter AWS Config events so that you can route specific types of notifications to specific targets. For example, you can send compliance notifications for specific rules or resource types to specific email addresses, or route configuration change notifications to an external IT service management (ITSM) or configuration management database (CMDB) tool. For more information, see the blog post AWS Config best practices
. In addition to using AWS Config proactive rule evaluation, you can use AWS CloudFormation Guard, which is a policy-as-code evaluation tool that proactively checks for resource configuration compliance. The AWS CloudFormation Guard command line interface (CLI) provides you with a declarative, domain-specific language (DSL) that you can use to express policy as code. In addition, you can use AWS CLI commands to validate JSON-formatted or YAML-formatted structured data such as CloudFormation change sets, JSON-based Terraform configuration files, or Kubernetes configurations. You can run the evaluations locally by using the AWS CloudFormation Guard CLI
as part of your authoring process or run it within your deployment pipeline . If you have AWS Cloud Development Kit (AWS CDK) applications, you can use cdk-nag for proactive checking of best practices.
Implementation example:
The AWS SRA code library
provides a sample implementation that deploys AWS Config conformance packs to all AWS accounts and Regions within an AWS organization. The AWS Config Aggregator module helps you configure an AWS Config aggregator by delegating administration to a member account (Security Tooling) within the Org Management account and then configuring AWS Config Aggregator within the delegated administrator account for all existing and future accounts in the AWS organization. You can use the AWS Config Control Tower Management Account module to enable AWS Config within the Org Management account―it isn't enabled by AWS Control Tower.
Amazon Macie
Amazon Macie
Macie is enabled in all accounts through AWS Organizations. Principals who have the required Macie permissions in Macie administrator account, create sensitive data discovery jobs for buckets that are owned by member accounts, and view all policy findings for all member accounts. Sensitive data findings can be viewed only by the account that created the sensitive findings job. For more information, see Managing multiple Macie accounts as an organization in the Macie documentation.
Macie findings flow to AWS Security Hub CSPM for review and analysis. Macie also integrates with Amazon EventBridge to facilitate automated responses to findings such as alerts, feeds to security information and event management (SIEM) systems, and automated remediation.
Design considerations:
If S3 objects are encrypted with an AWS Key Management Service (AWS KMS) key that you manage, you MUST add the Macie service-linked role as a key user to that KMS key to enable Macie to scan the data.
Macie is optimized for scanning objects in Amazon S3. As a result, any Macie-supported object type that can be placed in Amazon S3 (permanently or temporarily) can be scanned for sensitive data. This means that data from other sources—for example, periodic snapshot exports of Amazon Relational Database Service (Amazon RDS) or Amazon Aurora databases, exported Amazon DynamoDB tables
, or extracted text files from native or third-party applications—can be moved to Amazon S3 and evaluated by Macie.
Implementation example:
The AWS SRA code library
provides a sample implementation of Amazon Macie . It includes delegating administration to a member account and configuring Macie within the delegated administrator account for all existing and future accounts in the AWS organization. Macie is also configured to send the findings to a central S3 bucket that is encrypted with a customer managed key in AWS KMS.
IAM Access Analyzer
As you accelerate your AWS Cloud adoption journey and continue to innovate, you MUST continuously right-size IAM permissions to least privilege. Unused access SHOULD be removed. Excessive and unused access presents security challenges and makes it harder for enterprises to enforce the principle of least privilege. This principle is an important security architecture pillar that involves continually right-sizing IAM permissions to balance security requirements with operational and application development requirements. This effort involves multiple stakeholder personas, including central security and Cloud Center of Excellence (CCoE) teams as well as decentralized development teams.
AWS Identity and Access Management Access Analyzer
The IAM Access Analyzer external access analyzer findings feature helps you identify the resources in your AWS organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. The AWS organization or account you choose is known as the zone of trust. The analyzer uses automated reasoning
Similarly, the IAM Access Analyzer internal access analyzer finding feature helps you identify the resources in your AWS organization and accounts that are shared with principals internally within your organization or account. This analysis supports the principle of least privilege by ensuring that your specified resources can be accessed only by the intended principals within your organization. This is a paid feature and requires explicit configuration of resources to inspect. You SHOULD create internal access analyzers only for sensitive resources that must be restricted within the organization.
IAM Access Analyzer findings also help you identify unused access granted in your AWS organizations and accounts, including:
Unused IAM roles – Roles that have no access activity within the specified usage window.
Unused IAM users, credentials, and access keys – Credentials that belong to IAM users and are used to access AWS services and resources.
Unused IAM policies and permissions – Service-level and action-level permissions that weren't used by a role within a specified usage window. IAM Access Analyzer uses identity-based policies that are attached to roles to determine the services and actions that those roles can access. The analyzer provides a review of unused permissions for all service-level permissions.
You MUST triage IAM Access Analyzer findings and SHOULD remediate unintended or unused access based on your organization's policies and security standards. After remediation, these findings are marked as resolved the next time the analyzer runs. If the finding is intentional, you can mark it as archived in IAM Access Analyzer and prioritize other findings that present a greater security risk. Additionally, you can set up archive rules to automatically archive specific findings. For example, you can create an archive rule to automatically archive any findings for a specific Amazon S3 bucket that you regularly grant access to.
As a builder, you SHOULD use IAM Access Analyzer to perform automated IAM policy checks earlier in your development and deployment (CI/CD) process to adhere to your corporate security standards. You MAY integrate IAM Access Analyzer custom policy checks and policy reviews with AWS CloudFormation to automate policy reviews as a part of your development team's CI/CD pipelines. This includes:
IAM policy validation – IAM Access Analyzer validates your policies against IAM policy grammar and AWS best practices. You can view findings for policy validation checks, including security warnings, errors, general warnings, and suggestions for your policy. Over 100 policy validation checks are currently available and can be automated by using the AWS Command Line Interface (AWS CLI) and APIs.
IAM custom policy checks – IAM Access Analyzer custom policy checks validate your policies against your specified security standards. Custom policy checks use automated reasoning to provide a higher level of assurance on meeting your corporate security standards. The types of custom policy checks include:
Check against a reference policy: When you edit a policy, you SHOULD compare it with a reference policy, such as an existing version of the policy, to check whether the update grants new access. The CheckNoNewAccess API compares two policies (an updated policy and a reference policy) to determine whether the updated policy introduces new access over the reference policy, and returns a pass or fail response.
Check against a list of IAM actions: You SHOULD use the CheckAccessNotGranted API to ensure that a policy doesn't grant access to a list of critical actions that are defined in your security standard. This API takes a policy and checks whether the policy allows at least one of the actions, and then it returns a pass or fail response.
Security teams and other IAM policy authors SHOULD use IAM Access Analyzer to author policies that comply with IAM policy grammar and security standards. Authoring right-sized policies manually can be error prone and time consuming. The IAM Access Analyzer policy generation feature assists in authoring IAM policies that are based on a principal's access activity. IAM Access Analyzer reviews AWS CloudTrail logs for supported services and generates a policy template that contains the permissions that were used by the principal in the specified date range. You can then use this template to create a policy with fine-grained permissions that grants only the necessary permissions.
You MUST have a CloudTrail trail enabled for your account to generate a policy based on access activity.
IAM Access Analyzer doesn't identify action-level activity for data events, such as Amazon S3 data events, in generated policies.
The
iam:PassRoleaction isn't tracked by CloudTrail and isn't included in generated policies.
IAM Access Analyzer is deployed in the Security Tooling account through the delegated administrator functionality in AWS Organizations. The delegated administrator has permissions to create and manage analyzers with the AWS organization as the zone of trust.
Design consideration:
To get account-scoped findings (where the account serves as the trusted boundary), you MUST create an account-scoped analyzer in each member account. This can be done as part of the account pipeline. Account-scoped findings flow into Security Hub CSPM at the member account level. From there, they flow to the Security Hub CSPM delegated administrator account (Security Tooling).
Implementation examples:
The AWS SRA code library
provides a sample implementation of IAM Access Analyzer . It demonstrates how to configure an organization-level analyzer within a delegated administrator account and an account-level analyzer within each account. For information about how you can integrate custom policy checks into builder workflows, see the AWS blog post Introducing IAM Access Analyzer custom policy checks
.
Amazon CloudWatch
Amazon CloudWatch monitors your AWS resources and the applications you run on AWS in real time, and it offers tools to give you system-wide observability of your application performance, operational health, and resource utilization. Some AWS services automatically send basic metrics to CloudWatch at no charge. Additionally, CloudWatch provides additional monitoring capabilities for several key pieces of AWS infrastructure:
Database Insights allows you to monitor database performance metrics in real time, analyze SQL query performance, and troubleshoot database load issues for AWS database services.
Lambda Insights provides system-level metrics for AWS Lambda functions, including memory and CPU time tracking, and cold start detection and analysis.
Container Insights allows you to collect and analyze metrics from containerized applications running on Amazon ECS clusters, Amazon EKS clusters, and self-managed Kubernetes clusters on Amazon EC2.
AI-related security events integration allows you to build unified observability and evaluation for generative AI and agentic workloads across models, frameworks, and clouds.
The AWS SRA recommends two options for centralized log collection and analytics across your AWS organization. Amazon CloudWatch Unified Data Store
The Security Tooling account serves as the centralized home for all observability, security, and compliance telemetry across your organization. Designate this account as the CloudWatch delegated administrator for the organization. This delegation grants the Security Tooling account the ability to manage CloudWatch resources including Pipelines, centralization rules, cross-account observability links, and organization-wide metric and log collection—across all member accounts without requiring elevated permissions in the management account.
CloudWatch Unified Data Store provides unified data management and analytics capabilities that consolidate operational, security, and compliance data across your AWS environment and third-party sources into a single service. This eliminates the need for multiple separate data stores and complex ETL pipelines. Additionally, the data collected in CloudWatch can be made available as an Amazon S3 Table for cross-account fine-grained, column-level access control.
Security and operations teams interact with this centralized telemetry through CloudWatch Omni
To protect the availability of the logs and the log management process, configure strict IAM policies and service control policies (SCPs) on the Security Tooling account to provide only necessary permissions to manage CloudWatch. Use detective controls, such as those in AWS Config, to monitor, alert, and remediate this collection of permissions for unexpected changes.
The CloudWatch administrator SHOULD enable organization-wide log collection using centralization rules. Pipelines can be used to collect AWS vended logs (CloudTrail management events, CloudTrail data events for Amazon S3 and Lambda, Amazon VPC Flow Logs, AWS WAF logs, Amazon Route 53 resolver logs, and Amazon EKS audit logs) across all member accounts and AWS Regions. Pipelines can be configured to transform logs into a standardized open-source schema called Open Cybersecurity Schema Framework (OCSF) by using the built-in OCSF processor. With OCSF support, CloudWatch efficiently normalizes and consolidates security data from AWS and other enterprise security sources to create a unified and reliable repository of security-related information.
CloudWatch Pipelines also supports third-party connectors (such as CrowdStrike, SentinelOne, Okta, Entra ID, Wiz, Zscaler, Palo Alto Networks, ServiceNow CMDB) to ingest external security telemetry into the same unified data store.
AWS Security Hub CSPM findings can be ingested into CloudWatch through Pipelines, providing an overview of your compliance posture and whether you're following security recommendations for AWS and AWS Partner solutions.
To gain visibility and actionable insights from logs and events, you can query the data by using CloudWatch Logs Analytics (with Facets-based exploration, natural language queries, and Log Insights SQL/OpenSearch PPL/OpenSearch SQL support), Amazon Athena, Amazon OpenSearch Service, Amazon Redshift, Amazon SageMaker AI, Amazon Quick, and third-party solutions. Users who require interactive access to the centralized telemetry MUST NOT access log data directly. They should access data from through CloudWatch OMNI scoped grants or by querying Amazon S3 Tables (Apache Iceberg format) in the Log Archive account through AWS Lake Formation cross-account grants. This enables fine-grained, column-level access control through Athena, OpenSearch Service, Quick, or third-party SIEM tools. Other AWS accounts and on-premises locations access data through the same Lake Formation governed Amazon S3 Tables or through analytics tools that consume from the Log Archive account.
For long-term immutable storage, CloudWatch MUST send log data to Amazon S3 Object Lock and Glacier policies ensure immutability for regulatory compliance. The Log Archive account serves as a storage sink only and does not run CloudWatch analytics workloads.
As a best practice, we recommend that you restrict the configuration of CloudWatch through development pipelines and prevent configuration changes through the AWS Management Console or the AWS Command Line Interface (AWS CLI). You can configure notifications to detect any unauthorized access to log groups or S3 buckets.
Design consideration:
The Long-term retention of observability and security telemetry is handled natively by Amazon CloudWatch Logs in the Log Archive account retention policies (configurable from 1 day to 10 years, or indefinite) govern how long data is kept, and CloudWatch Logs Intelligent Tiering minimizes storage cost by automatically moving less-frequently-accessed data to lower-cost tiers while keeping it queryable in place. Retention policies plus IAM/SCP guardrails protect data within its retention window, but CloudWatch Logs does not provide write-once-read-many (WORM) immutability. Where regulatory or compliance requirements mandate immutable, tamper-proof (WORM) retention, that capability is provided by the Log Archive account, which remains the organization's dedicated, immutable archive tier. Configure CloudWatch to deliver a copy of the required logs to Amazon S3 in the Log Archive account, where Amazon S3 Object Lock (compliance mode) enforces WORM immutability and S3 Lifecycle policies (including transition to Amazon S3 Glacier storage classes) manage cost-efficient, long-duration retention. The Log Archive account is a durable, access-controlled storage/archive tier only, it does not run CloudWatch analytics or observability workloads.
Depending on your business requirements and team structures, you MAY choose to manage your monitoring resources and services in a single account with your other Operational Tooling services or as a dedicated Monitoring account under Security OU. The core concept of the Monitoring account is to only give read-only functionality to monitor resources, applications, log data, and performance in other AWS accounts. The account in itself is not intended to have the ability to make changes across your AWS Organization. In such a scenario you SHOULD host Amazon CloudWatch within the dedicated Monitoring account and not with Security Tooling account. AWS offers a number of additional tools and services including
OMNI Space:
Centralize into one space; don't fragment. An Omni space sees only the telemetry in its own account and Region, and queries cannot span spaces. Centralize source accounts and Regions into the single space in the Security Tooling account rather than standing up a space per team.
Enable centralization early. Centralization is forward-only and does not backfill (except for initaial enablement)—only telemetry generated after a centralization rule becomes active is replicated. Establish the space and centralization rules as a foundational step (for example, through your landing zone or account vending) so the data is present before you need it.
Model centralization cost. Centralization replicates telemetry into the Security Tooling account, so ingestion and storage are billed there. Scope which accounts, Regions, and signals you centralize, and use CloudWatch Logs Intelligent Tiering to reduce long-term storage cost.
Treat the hosting Region as a data-residency decision. Centralized telemetry comes to rest in the Security Tooling account's Region. Where data-residency requirements prevent consolidating all telemetry into a single Region, host an additional space in the required Region within the same Monitoring account (for example, keep EU telemetry centralized in an EU Region), and scope grants accordingly.
Amazon Security Lake
Amazon Security Lake
AWS SRA recommends that you use the Log Archive account as the delegated administrator account for Security Lake. For more information about setting up the delegated administrator account, see Amazon Security Lake in the Security OU ‒ Log Archive account section. Security teams that want to access Security Lake data or need the ability to write non-native logs to the Security Lake buckets by using custom extract, transform, and load (ETL) functions should operate within the Security Tooling account.
Security Lake can collect logs from different cloud providers, logs from third-party solutions, or other custom logs. AWS recommends that you use the Security Tooling account to perform the ETL functions to convert the logs to Open Cybersecurity Schema Framework (OCSF) format and output a file in Apache Parquet format. Security Lake creates the cross-account role with the proper permissions for the Security Tooling account and the custom source backed by Lambda functions or AWS Glue crawlers, to write data to the S3 buckets for Security Lake.
The Security Lake administrator should configure security teams that use the Security Tooling account and require access to the logs that Security Lake collects as subscribers. Security Lake supports two types of subscriber access:
Data access – Subscribers can directly access the Amazon S3 objects for Security Lake. Security Lake manages the infrastructure and permissions. When you configure the Security Tooling account as a Security Lake data access subscriber, the account is notified of new objects in the Security Lake buckets through Amazon Simple Queue Service (Amazon SQS), HTTPS enfpoint and Security Lake creates the permissions to access those new objects.
Query access – Subscribers can query source data from AWS Lake Formation tables in your S3 bucket by using services such as Amazon Athena. Cross-account access is automatically set up for query access by using Lake Formation. When you configure the Security Tooling account as a Security Lake query access subscriber, the account is given read-only access to the logs in the Security Lake account. When you use this subscriber type, the Athena and AWS Glue tables are shared from the Security Lake Log Archive account with the Security Tooling account through AWS Resource Access Manager (AWS RAM). To enable this capability, you must update the cross-account data sharing settings to version 2 or version 3.
For more information about creating subscribers, see Subscriber management in the Security Lake documentation.
For best practices for ingesting custom sources, see Collecting data from custom sources in the Security Lake documentation.
You can use Amazon Quick Sight
Design consideration:
If an application team needs query access to Security Lake data to meet a business requirement, the Security Lake administrator should configure that Application account as a subscriber.
AWS Firewall Manager
AWS Firewall Manager
Firewall Manager is particularly useful when you want to protect your entire AWS organization instead of a small number of specific accounts and resources, or if you frequently add new resources that you want to protect. Firewall Manager uses security policies to let you define a set of configurations, including relevant rules, protections, and actions that must be deployed and the accounts and resources (indicated by tags) to include or exclude. You can create granular and flexible configurations while still being able to scale control out to large numbers of accounts and VPCs. These policies automatically and consistently enforce the rules you configure even when new accounts and resources are created. Firewall Manager is enabled in all accounts through AWS Organizations, and configuration and management are performed by the appropriate security teams in the Firewall Manager delegated administrator account (in this case, the Security Tooling account).
AWS Config MUST be enabled in every Region that contains resources in scope of Firewall Manager policies. If you don't want to enable AWS Config for all resources, you must enable it for resources that are associated with the type of Firewall Manager policies that you use. When you use both AWS Security Hub CSPM and Firewall Manager, Firewall Manager automatically sends your findings to Security Hub CSPM. Firewall Manager creates findings for resources that are out of compliance and for attacks that it detects, and sends the findings to Security Hub CSPM. Firewall Manager AWS WAF policies SHOULD enable centralized web ACL logging to the Log Archive account.
With Firewall Manager you can have one or multiple administrators who can manage the firewall resources of your organization. When multiple Firewall Manager administrators exist, each administrator's scope SHOULD be restricted to the accounts, OUs, Regions, and policy types they manage. This gives you the flexibility to have different administrator roles within your organization, and helps you maintain the principle of least privilege access. The AWS SRA uses one administrator with full administrative scope delegated to the Security Tooling account.
Design consideration:
Account managers of individual member accounts in the AWS organization can configure additional controls (such as AWS WAF rules and Amazon VPC security groups) in the Firewall Manager managed services according to their particular needs.
Implementation example:
The AWS SRA code library
provides a sample implementation of Firewall Manager . It demonstrates delegated administration (Security Tooling), deploys a maximum allowed security group, configures a security group policy, and configures multiple AWS WAF policies.
Amazon EventBridge
Amazon EventBridge
Design considerations:
EventBridge can route events to a number of different targets. One valuable pattern for automating security actions is to connect particular events to individual AWS Lambda responders, which take appropriate actions. For example, in certain circumstances you MAY want to use EventBridge to route a public S3 bucket finding to a Lambda responder that corrects the bucket policy and removes the public permissions. These responders can be integrated into your investigative playbooks and runbooks to coordinate response activities.
Security operations team MUST integrate the flow of security events and findings into a notification and workflow system such as a ticketing system, a bug/issue system, or another security information and event management (SIEM) system. This takes the workflow out of email and static reports, and helps you route, escalate, and manage events or findings. The flexible routing abilities in EventBridge are a powerful enabler for this integration.
Amazon Detective
Amazon Detective
Detective integrates with Amazon Security Lake to enable security analysts to query and retrieve logs that are stored in Security Lake. You can use this integration to get additional information from CloudTrail logs and Amazon VPC flow logs that are stored in Security Lake while conducting security investigations in Detective.
Detective also ingests findings that are detected by Amazon GuardDuty, including threats that are detected by GuardDuty Runtime Monitoring. When an account enables Detective, it becomes the administrator account for the behavior graph.
Additional optional data sources for Detective include Amazon EKS audit logs and AWS Security Hub CSPM. The Amazon EKS audit log data source enhances the information provided about the following entity types: Amazon EKS clusters, Kubernetes pods, container images, and Kubernetes subjects. The Security Hub CSPM data source is part of AWS security findings, where it correlates findings across products into Security Hub CSPM and ingests them into Detective.
Detective automatically groups multiple findings that are related to a single security compromise event into finding groups. Threat actors typically perform a sequence of actions that lead to multiple security findings spread across time and resources. Therefore, finding groups should be the starting point for investigations that involve multiple entities and findings. Detective also provides finding group summaries by using generative AI that automatically analyzes finding groups and provides insights in natural language to help you accelerate security investigations.
Detective integrates with AWS Organizations. The organization management account delegates a member account as the Detective administrator account. In the AWS SRA, this is the Security Tooling account. The Detective administrator account has the ability to automatically enable all current member accounts in the organization as Detective member accounts, and also add new member accounts as they get added to the AWS organization. Detective administrator accounts also have the ability to invite member accounts that currently do not reside in the AWS organization, but are within the same Region, to contribute their data to the primary account's behavior graph. When a member account accepts the invitation and is enabled, Detective begins to ingest and extract the member account's data into that behavior graph.
Design consideration:
You can navigate to Detective finding profiles from the GuardDuty and AWS Security Hub CSPM consoles. These links can help streamline the investigation process. The Detective delegated administrator account MUST be the same as the GuardDuty and Security Hub CSPM administrator account for console pivots to work.
AWS Audit Manager
Note
AWS Audit Manager is no longer open to new customers. For more information refer to AWS Audit Manager availability change.
AWS Audit Manager
With Audit Manager you can audit against prebuilt frameworks such as the Center for Internet Security (CIS) benchmark, the CIS AWS Foundations Benchmark, System and Organization Controls 2 (SOC 2), and the Payment Card Industry Data Security Standard (PCI DSS). It also gives you the ability to create your own frameworks with standard or custom controls based on your specific requirements for internal audits.
Audit Manager collects four types of evidence. Three types of evidence are automated: compliance check evidence from AWS Config and AWS Security Hub CSPM, management events evidence from AWS CloudTrail, and configuration evidence from AWS service-to-service API calls. For evidence that cannot be automated, Audit Manager lets you upload manual evidence.
By default, your data in Audit Manager is encrypted by using AWS managed keys. The AWS SRA uses a customer managed key for encryption to provide greater control over logical access. Also configure an S3 bucket in the AWS Region where Audit Manager publishes the assessment report. These buckets should be encrypted with a customer managed key and have a bucket policy that's configured to allow only Audit Manager to publish reports.
Note
Audit Manager assists in collecting evidence that's relevant for verifying compliance with specific compliance standards and regulations. However, it doesn't assess your compliance. Therefore, the evidence that's collected through Audit Manager might not include details of your operational processes that are needed for audits. Audit Manager isn't a substitute for legal counsel or compliance experts. We recommend that you engage the services of a third-party assessor who is certified for the compliance framework(s) that you are evaluated against.
Audit Manager assessments can run over multiple accounts in your AWS Organizations organizations. Audit Manager collects and consolidates evidence into a delegated administrator account in AWS Organizations. This audit functionality is primarily used by compliance and internal audit teams, and requires only read access to your AWS accounts.
Design considerations:
Audit Manager complements other AWS security services such as Security Hub CSPM, Security Hub, and AWS Config to help implement a risk management framework. Audit Manager provides independent risk assurance functionality, whereas Security Hub CSPM helps you oversee your risk and AWS Config conformance packs assist in managing your risks. Audit professionals who are familiar with the Three Lines Model
developed by the Institute of Internal Auditors (IIA) should note that this combination of AWS services helps you cover the three lines of defense. For more information, see the two-part blog series on the AWS Cloud Operations & Migrations blog. In order for Audit Manager to collect Security Hub CSPM evidence, the delegated administrator account for both services must be the same AWS account. For this reason, in the AWS SRA, the Security Tooling account is the delegated administrator for Audit Manager.
AWS Artifact
AWS Artifact
AWS Artifact doesn't support the delegated administration feature. Instead, you MUST restrict this capability to only IAM roles in the Security Tooling account that pertain to your audit and compliance teams, so they can download, review, and provide those reports to external auditors as needed. You SHOULD additionally restrict specific IAM roles to have access to only specific AWS Artifact reports through IAM policies. For sample IAM policies, see the AWS Artifact documentation.
Design consideration:
If you choose to have a dedicated AWS account for audit and compliance teams, you can host AWS Artifact in a security audit account, which is separate from the Security Tooling account. AWS Artifact reports provide evidence that demonstrates that an organization is following a documented process or meeting a specific requirement. Audit artifacts are gathered and archived throughout the system development lifecycle and can be used as evidence in internal or external audits and assessments.
AWS KMS
AWS Key Management Service
AWS SRA recommends a distributed key management model in which the AWS KMS keys SHOULD reside locally within the account where they are used. This model gives your workload teams more control, flexibility, and agility over the use of encryption keys. It also helps avoid API limits, limits the scope of impact to one AWS account only, and simplifies reporting, auditing, and other compliance-related tasks. When KMS keys are decentralized, you MUST enforce guardrails for consistent key management and MUST audit key usage. For more information, see the whitepaper AWS Key Management Service Best Practices. You SHOULD not use a single key in one account for all cryptographic functions. Keys SHOULD be scoped by function and data protection requirements, and to enforce the principle of least privilege. In some cases, encryption permissions would be kept separate from decryption permissions, and administrators would manage lifecycle functions but would not be able to encrypt or decrypt data with the keys that they manage.
The other deployment option is to centralize the responsibility of AWS KMS key management to a single account while delegating the ability to use keys in the Application account by application resources by using a combination of key and IAM policies. This approach is secure and straightforward to manage, but you may encounter challenges due to AWS KMS throttling limits, account service limits, and increased operational overhead for the security team managing keys at scale.
In the Security Tooling account, AWS KMS is used to manage the encryption of centralized security services such as the AWS CloudTrail organization trail that is managed by the AWS Organizations organization.
AWS Private CA
AWS Private Certificate Authority (AWS Private CA), you can create your own CA hierarchy (a root CA, through subordinate CAs, to end-entity certificates) and issue certificates with it to authenticate internal users, computers, applications, services, servers, and other devices, and to sign computer code. Certificates issued by a private CA are trusted only within your AWS organization, not on the internet.
A public key infrastructure (PKI) or security team SHOULD be responsible for managing all PKI infrastructure. This includes the management and creation of the private CA. However, there must be a provision that allows workload teams to self-serve their certificate requirements. The AWS SRA depicts a centralized CA hierarchy in which the root CA is hosted within the Security Tooling account. This enables security teams to enforce stringent security control, because the root CA is the foundation of the entire PKI. However, creation of private certificates from the private CA is delegated to application development teams by sharing out the CA to an Application account by using AWS Resource Access Manager (AWS RAM). AWS RAM manages the permissions required for cross-account sharing. This removes the need for a private CA in every account and provides a more cost-effective way of deployment. For more information about the workflow and implementation, see the blog post How to use AWS RAM to share your AWS Private CA cross-account
Note
AWS Certificate Manager (ACM) also helps you provision, manage, and deploy public TLS certificates for use with AWS services. To support this functionality, ACM has to reside in the AWS account that would use the public certificate. This is discussed later in this guide, in the Application account section.
Design considerations:
With AWS Private CA, you can create a hierarchy of certificate authorities with up to five levels. You can also create multiple hierarchies, each with its own root. The AWS Private CA hierarchy SHOULD adhere to your organization's PKI design. However, keep in mind that increasing the CA hierarchy increases the number of certificates in the certification path, which, in turn, increases the validation time of an end-entity certificate. A well-defined CA hierarchy provides benefits that include granular security control appropriate to each CA, delegation of subordinate CA to a different application, which leads to division of administrative tasks, use of CA with limited revocable trust, the ability to define different validity periods, and the ability to enforce path limits. Your root and subordinate CAs SHOULD reside in separate AWS accounts. For more information about planning a CA hierarchy by using AWS Private CA, see the AWS Private CA documentation and the blog post How to secure an enterprise scale AWS Private CA hierarchy for automotive and manufacturing
. AWS Private CA can integrate with your existing CA hierarchy, which allows you to use the automation and native AWS integration capability of ACM in conjunction with the existing root of trust that you use today. You can create a subordinate CA in AWS Private CA backed by a parent CA on premises. For more information about implementation, see Installing a subordinate CA certificate signed by an external parent CA in the AWS Private CA documentation.
Amazon Inspector
Amazon Inspector
Amazon Inspector continuously assesses your environment throughout the lifecycle of your resources by automatically scanning resources whenever you make changes to them. Events that initiate rescanning a resource include installing a new package on an EC2 instance, installing a patch, and the publication of a new common vulnerabilities and exposures (CVE) report that affects the resource. Amazon Inspector supports Center for Internet Security (CIS) Benchmark assessments for operating systems in EC2 instances.
Amazon Inspector integrates with developer tools such as Jenkins and TeamCity for container image assessments. You can assess your container images for software vulnerabilities within your continuous integration and continuous delivery (CI/CD) tools, and push security to an earlier point in the software development lifecycle. Assessment findings are available in the CI/CD tool's dashboard, so you can perform automated actions in response to critical security issues such as blocked builds or image pushes to container registries. If you have an active AWS account, you can install the Amazon Inspector plugin from your CI/CD tool marketplace and add an Amazon Inspector scan in your build pipeline without needing to activate all the Amazon Inspector service features. This feature works with CI/CD tools hosted anywhere―on AWS, on premises, or in hybrid clouds―so you can consistently use a single solution across all your development pipelines. When Amazon Inspector is activated, it automatically discovers all your EC2 instances, container images in Amazon ECR and CI/CD tools, and Lambda functions at scale, and continuously monitors them for known vulnerabilities.
The network reachability findings of Amazon Inspector assess the accessibility of your EC2 instances to or from VPC edges such as internet gateways, VPC peering connections, or virtual private networks (VPNs) through a virtual gateway. These rules help automate the monitoring of your AWS networks and identify where network access to your EC2 instances might be misconfigured through mismanaged security groups, access control lists (ACLs), internet gateways, and so on. For more information, see the Amazon Inspector documentation.
When Amazon Inspector identifies vulnerabilities or open network paths, it produces a finding that you can investigate. The finding includes comprehensive details about the vulnerability, including a risk score, the affected resource, and remediation recommendations. The risk score is specifically tailored to your environment and is calculated by correlating up-to-date CVE information with temporal and environmental factors such as network accessibility and exploitability information to provide a contextual finding.
Amazon Inspector Code Security scans first-party application source code, third-party application dependencies, and infrastructure as code (IaC) for vulnerabilities. After you activate Code Security, you can create and apply a scan configuration to your code repository to determine frequency, scan type, and repositories to be scanned. Code Security supports static application security testing (SAST), software composition analysis (SCA), and IaC scanning. To configure frequency, you can define scans on demand, at code changes, or periodically. Code scanning captures snippets of code to highlight detected vulnerabilities. The code snippets are stored encrypted with KMS keys. The delegated administrator for an organization cannot view code snippets that belong to member accounts. After you integrate your source code managers (SCMs) with Code Security, all code repositories are listed as projects in the Amazon Inspector console. Code Security monitors only the default branch of each repository. Amazon Inspector streamlines security remediation by providing specific code fix recommendations directly where developers work. The two-way integration with your SCM automatically suggests fixes as comments within pull requests (PRs) and merge requests (MRs) for critical and high findings, and alerts developers to the most important vulnerabilities to address without disrupting their workflow.
To scan for vulnerabilities, EC2 instances may be managed in AWS Systems Manager by using AWS Systems Manager Agent (SSMAgent). No agents are required for network reachability of EC2 instances or vulnerability scanning of container images in Amazon ECR or Lambda functions.
Amazon Inspector is integrated with AWS Organizations and supports delegated administration. In the AWS SRA, the Security Tooling account is made the delegated administrator account for Amazon Inspector. The Amazon Inspector delegated administrator account can manage findings data and certain settings for members of the AWS organization. This includes viewing the details of aggregated findings for all member accounts, enabling or disabling scans for member accounts, and reviewing scanned resources within the AWS organization.
Design considerations:
Amazon Inspector integrates with AWS Security Hub CSPM and Security Hub automatically when both services are enabled. You SHOULD use this integration to send all findings from Amazon Inspector to Security Hub CSPM, which will then include those findings in its analysis of your security posture.
Amazon Inspector automatically exports events for findings, resource coverage changes, and initial scans of individual resources to Amazon EventBridge, and, optionally, to an Amazon Simple Storage Service (Amazon S3) bucket. To export active findings to an S3 bucket, you need an AWS KMS key that Amazon Inspector can use to encrypt findings, and an S3 bucket with permissions that allow Amazon Inspector to upload objects. EventBridge integration enables you to monitor and process findings in near real time as part of your existing security and compliance workflows. EventBridge events are published to the Amazon Inspector delegated administrator account in addition to the member account from which they originated.
Amazon Inspector Code Security integrations with GitHub SaaS, GitHub Enterprise Cloud, and GitHub Enterprise Server require public internet access.
Implementation example:
The AWS SRA code library
provides a sample implementation of Amazon Inspector . It demonstrates delegated administration (Security Tooling) and configures Amazon Inspector for all existing and future accounts in the AWS organization.
AWS Security Incident Response
AWS Security Incident Response
AWS Security Incident Response provides an AI-powered investigative agent that automates evidence gathering and analysis for AWS supported cases. When a security event case is created, the investigative agent activates in parallel with Security Incident Response engineers, automatically collecting relevant information from CloudTrail, IAM, Amazon EC2, and AWS Cost Explorer. The agent correlates this data to generate comprehensive investigation summaries typically within minutes.
In the AWS SRA, AWS Security Incident Response is deployed in the Security Tooling account as a delegated administrator account. The Security Tooling account is selected because it aligns with the account's purpose of operating security services and automating security alerting and responses. The Security Tooling account also acts as the delegated administrator account for Security Hub CSPM and GuardDuty, which, along with AWS Security Incident Response, help simplify workflow management. AWS Security Incident Response is configured to work with AWS Organizations, so you can manage incident responses across your organization's accounts from the Security Tooling account.
AWS Security Incident Response helps you implement the following phases of the incident response lifecycle:
Preparation: Create and maintain response plans and SSM documents for containment actions.
Detection and analysis: Automatically analyze security findings and determine incident severity.
Triage: Open a service-supported case and engage with the AWS Security Incident Response Engineering for additional assistance. Security Incident Response Engineering is a group of individuals who provide support during active security events.
Containment and eradication: Run automated containment actions through SSM documents.
Post-incident activity: Document incident details and conduct post-incident analysis.
You can also use AWS Security Incident Response to create self-managed cases. AWS Security Incident Response can create an outbound notification or case when you need to be aware of, or act on, something that might impact your account or resources. This feature is available only when you enable the proactive response and alert triaging workflows as part of your subscription.
Design considerations:
When you implement AWS Security Incident Response, carefully review and test automated response actions before you enable them in production. Automation can speed up incident response, but improperly configured automated actions could impact legitimate workloads.
Consider using SSM documents in AWS Security Incident Response to implement organization-specific containment procedures while maintaining the service's built-in best practices for common incident types.
If you plan to use AWS Security Incident Response in a VPC, make sure that you have the appropriate VPC endpoints configured for Systems Manager and other integrated services to enable containment actions in private subnets.
Deploying common security services within all AWS accounts
The Apply security services across your AWS organization section earlier in this reference highlighted security services that protect an AWS account, and noted that many of these services can also be configured and managed within AWS Organizations. The common security services listed in this section MUST be deployed in all accounts depicted in the AWS SRA. This enables a consistent set of guardrails and provides centralized monitoring, management, and governance across your AWS organization.
Security Hub CSPM, GuardDuty, AWS Config, IAM Access Analyzer, and CloudTrail organization trails appear in all accounts. The first three support the delegated administrator feature discussed previously in the section The management account, trusted access, and delegated administrators. CloudTrail currently uses a different aggregation mechanism.
The AWS SRA GitHub code repository
Design considerations:
Specific account configurations might necessitate additional security services. For example, accounts that manage S3 buckets (the Application and Log Archive accounts) should also include Amazon Macie, and consider turning on CloudTrail S3 data event logging in these common security services. (Macie supports delegated administration with centralized configuration and monitoring.) Another example is Amazon Inspector, which is applicable only for accounts that host EC2 instances, Amazon ECR images, Lambda functions or code repositories (GitHub, GitLab).
In addition to the services described previously in this section, the AWS SRA includes two security-focused services, Amazon Detective and AWS Audit Manager, which support AWS Organizations integration and the delegated administrator functionality. However, those are not included as part of the recommended services for account baselining, because we have seen that these services are best used in the following scenarios:
You have a dedicated team or group of resources that perform these functions. Detective is best utilized by security analyst teams and Audit Manager is helpful to your internal audit or compliance teams.
You want to focus on a core set of tools such as GuardDuty and Security Hub CSPM at the start of your project, and then build on these by using services that provide additional capabilities.
AWS Network Security Manager
AWS Network Security Manager
You define a set of hierarchical policy objects and apply them to targeted scopes. The lowest level of policy objects are rules. You can group rules into templates, which you can combine into policies with priority-based conflict resolution. You then select accounts and resources to protect with a scope, and enforce your policies by publishing a deployment. When multiple policies protect the same resource, AWS Network Security Manager merges their configurations based on policy priority, providing predictable conflict resolution. Each AWS Network Security Manager resource type—rules, templates, policies, scopes, and deployments—supports immutable, version-numbered snapshots. Use versioning to preserve known-good AWS Network Security Manager resource configurations.
An AWS Network Security Manager policy can be deployed in two modes. Automatic remediation allows you to automatically monitor for drift in policy and apply rules on out-of-sync resources. Manual remediation deploys the desired policy with the associated rules and protections in each account, and then you take manual action for each local account.
Network Security Manager is integrated with AWS Organizations
You can use AWS Network Security Manager in a single account or designate multiple administrator accounts, each with a priority level. When administrators' policies overlap, AWS Network Security Manager resolves conflicts by administrator priority first, then by policy priority within each account.
Use AWS Network Security Manager for the following use cases:
Enforce baseline AWS WAF rules across all accounts – Define a set of AWS WAF rule groups that every internet-facing application must use, then deploy them across your entire organization. AWS Network Security Manager automatically applies the rules to new in-scope resources as they come into scope.
Create specific custom or exception AWS WAF rules across specific resources – Define a set of AWS WAF rules that apply only to a specific set of resources. This set can be a specific business unit or application that you identify by AWS account ID, OU, tag, or Amazon Resource Names (ARNs).
Verify DDoS protection on internet-facing resources – Create an AWS Shield Advanced policy scoped to public resource types and deploy it organization-wide so that critical resources have DDoS protection enabled.
Detect and remediate configuration drift – Use synchronization status monitoring to identify resources whose firewall configurations have drifted from the intended state, and optionally enable automatic remediation to bring them back into compliance.
Delegate security management to multiple teams – Designate multiple administrator accounts with different priority levels and scoped access to specific accounts, organizational units, or firewall types, allowing teams to manage their own security policies within defined boundaries.
AWS Network Security Manager provides synchronization status APIs to query the protection status of individual resources accross your deployment. For more information, see Synchronization and remediation.
In the AWS SRA, Network Security Manager is used within the network account because the network control-focused functionality of the service aligns with the intent of the account.
Design considerations:
AWS Network Security Manager is replacing AWS Firewall Manager, but these two are separate services. If you are currently using AWS Firewall Manager, your existing firewalls and policies will continue to work.
Migration from AWS Firewall Manager to AWS Network Security Manager is planned but is not yet available.
AWS Network Security Manager discovers protected resources in your accounts using a service-linked AWS Config configuration recorder, without requiring you to enable AWS Config separately.
