Security OU – Security Tooling account

Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey.

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 the appropriate centralized security infrastructure to monitor security operations data and maintain traceability. Detection, investigation, and response are essential parts of the security lifecycle and can be used to support a quality process, a legal or compliance obligation, and for 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. Read-only/audit roles to view AWS organization-wide information are typical, whereas write/modify roles are limited in number, tightly controlled, 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.

• It might be appropriate to 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. As mentioned earlier, this is handled through the AWS Organizations delegated administrator functionality. Services in the AWS SRA that currently support delegated administrator include AWS Config, AWS Firewall Manager, Amazon GuardDuty, AWS IAM Access Analyzer, Amazon Macie, AWS Security Hub, Amazon Detective, AWS Audit Manager, Amazon Inspector, and AWS Systems Manager. Your security team manages the security features of these services and monitors any security-specific events or findings.

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.

AWS CloudTrail

AWS CloudTrail is a service that supports the governance, compliance, and auditing of activity in your AWS account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. CloudTrail is integrated with AWS Organizations, and that integration can be used to create a single trail that logs all events for all accounts in the AWS organization. This is referred to as an organization trail. You can create and manage an organization trail only from within the management account for the organization or from a delegated administrator account. When you create an organization trail, a trail with the name that you specify is created in every AWS account that belongs to your AWS organization. The trail logs activity for all accounts, including the management account, in the AWS organization and stores the logs in a single S3 bucket. Because of the sensitivity of this S3 bucket, you should secure it by following the best practices outlined in the Amazon S3 as central log store section later in this guide. All accounts in the AWS organization can see the organization trail in their list of trails. However, member AWS accounts have view-only access to this trail. By default, when you create an organization trail in the CloudTrail console, the trail is a multi-Region trail. For additional security best practices, see the AWS CloudTrail documentation.

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 AWS CloudTrail documentation.

Note

You can create and manage organization trails from both management and delegated administrator accounts. However, as a best practice, you should limit access to the management account and use the delegated administrator functionality where it is available.

Design consideration

• 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 CloudWatch 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

AWS Security Hub provides you with a comprehensive view of your security posture in AWS and helps you check your environment against security industry standards and best practices. Security Hub collects security data from across AWS integrated services, supported third-party products, and other custom security products that you might use. It helps you continuously monitor and analyze your security trends and identify the highest priority security issues. In addition to the ingested sources, Security Hub generates its own findings represented by security controls that map to one or more security standards. These standards include AWS Foundational Security Best Practices (FSBP), Center for Internet Security (CIS) AWS Foundations benchmark v1.20 and v1.4.0, National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5, Payment Card Industry Data Security Standard (PCI DSS), and service-managed standards. For a list of current security standards and details on specific security controls, see the Security Hub standards reference in the Security Hub documentation.

Security Hub integrates with AWS Organizations to simplify security posture management across all your existing and future accounts in your AWS organization. The Security Hub delegated administrator account (in this case, Security Tooling) has Security Hub enabled automatically and can choose the AWS accounts to enable as member accounts. The Security Hub delegated administrator account can also view findings, view insights, and control details from all member accounts. You can additionally designate an aggregation 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 aggregator Region and all other Regions.

Security Hub supports integrations with several AWS services. Amazon GuardDuty, AWS Config, Amazon Macie, AWS IAM Access Analyzer, AWS Firewall Manager, Amazon Inspector, and AWS Systems Manager Patch Manager can feed findings to Security Hub. In addition, you can pivot from Security Hub to Amazon Detective to investigate an Amazon GuardDuty finding. Security Hub recommends aligning the delegated administrator accounts for these services (where they exist) for smoother integration. For example, if you do not align administrator accounts between Detective and Security Hub, pivoting from findings into Detective will not work. For a comprehensive list, see Overview of AWS service integrations with Security Hub in the Security Hub documentation.

You can use Security Hub with the Network Access Analyzer feature of Amazon VPC to help continuously monitor the compliance of your AWS network configuration. This will help you block unwanted network access and help prevent your critical resources from external access. For further architecture and implementation details, see the AWS blog post Continuous verification of network compliance using Amazon VPC Network Access Analyzer and AWS Security Hub. 

In addition to monitoring, Security Hub supports integration with Amazon EventBridge to automate remediation of specific findings. You can 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. Further discussion and examples are available in these two AWS blog posts: Automated Response and Remediation with AWS Security Hub and How to deploy the AWS Solution for Security Hub Automated Response and Remediation. 

Security Hub uses service-linked AWS Config rules to perform most of its security checks for controls. To support these controls, AWS Config must be enabled on all accounts—including the administrator (or delegated administrator) account and member accounts—in each AWS Region where Security Hub is enabled. 

Design considerations

• If a compliance standard, such as PCI-DSS, is already present in Security Hub, then the fully managed Security Hub 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 way to do this customization. (For more information about AWS Config and conformance packs, see the AWS Config section.)

• Common use cases for Security Hub 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 up each, see the blog post Three recurring Security Hub usage patterns and how to deploy them.

Implementation example

The AWS SRA code library provides a sample implementation of Security Hub. It includes automatic enablement of the service, delegated administration to a member account (Security Tooling), and configuration to enable Security Hub for all existing and future accounts in the AWS organization.

AWS GuardDuty

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads. You must always capture and store appropriate logs for monitoring and audit purposes, but Amazon GuardDuty pulls independent streams of data directly from AWS CloudTrail, Amazon VPC flow logs, and AWS DNS logs. You don’t have to manage Amazon S3 bucket policies or modify the way you collect and store your logs. GuardDuty permissions are managed as service-linked roles that you can revoke at any time by disabling GuardDuty. This makes it easy to enable the service without complex configuration, and it eliminates the risk that an IAM permission modification or S3 bucket policy change will affect the operation of the service.

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. For new detectors, these optional features are enabled by default except for EKS Protection, which must be manually enabled.

• 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 RDS Protection is designed to profile and monitor access activity to Amazon Aurora databases without impacting database performance.

• 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 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). 

When AWS Security Hub is enabled, GuardDuty findings automatically flow to 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 can also integrate GuardDuty with Amazon EventBridge to automate best practices for GuardDuty, such as automating responses to new GuardDuty findings.

Implementation example

The AWS SRA code library provides a sample implementation of Amazon 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 is a service that enables you to assess, audit, and evaluate the configurations of supported AWS resources in your AWS accounts. AWS Config continuously monitors and records AWS resource configurations, and automatically evaluates recorded configurations against desired configurations. You can also integrate AWS Config with other services to do the heavy lifting in automated audit and monitoring pipelines. For example, AWS Config can monitor for changes in individual secrets in AWS Secrets Manager. 

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). 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 to send the results of AWS Config managed and custom rule evaluations as findings into Security Hub. 

AWS Config rules can be used in conjunction with AWS Systems Manager to effectively remediate noncompliant resources. You use AWS 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 the blog post Remediate noncompliant AWS Config rules with AWS Systems Manager Automation runbooks. 

If you use AWS Control Tower to manage your AWS organization, it will deploy a set of AWS Config rules as detective guardrails (categorized as mandatory, strongly recommended, or elective). 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 each member account in the AWS organization and AWS Region that contains the resources that you want to protect. You can centrally manage (for example, create, update, and delete) AWS Config rules across all accounts within your AWS organization. From the AWS Config delegated administrator account, you can deploy a common set of AWS Config rules across all accounts and specify accounts where AWS Config rules should not be created. The AWS Config delegated administrator account can also aggregate resource configuration and compliance data from all member accounts to provide a single view. Use the APIs from the delegated administrator account to enforce governance by ensuring that the underlying AWS Config rules cannot be modified by the member accounts in your AWS organization.

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 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 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 is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover and help protect your sensitive data in AWS. You need to identify the type and classification of data your workload is processing to ensure that appropriate controls are enforced. You can use Macie to automate the discovery and reporting of sensitive data in two ways: by performing automated sensitive data discovery and by creating and running sensitive data discovery jobs. With automated sensitive data discovery, Macie evaluates your S3 bucket inventory on a daily basis and uses sampling techniques to identify and select representative S3 objects from your buckets. Macie then retrieves and analyzes the selected objects, inspecting them for sensitive data. Sensitive data discovery jobs provide deeper and more targeted analysis. With this option, you define the breadth and depth of the analysis, including the S3 buckets to analyze, the sampling depth, and custom criteria that derive from the properties of S3 objects. If Macie detects a potential issue with the security or privacy of a bucket, it creates a policy finding for you. Automated data discovery is enabled by default for all new Macie customers, and existing Macie customers can enable it with one click.

Macie is enabled in all accounts through AWS Organizations. Principals who have the appropriate permissions in the delegated administrator account (in this case, the Security Tooling account) can enable or suspend Macie in any 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 accounts in Amazon Macie in the Macie documentation.

Macie findings flow to AWS Security Hub 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 can 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.

AWS IAM Access Analyzer

AWS IAM Access Analyzer 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. This detective control helps you identify unintended access to your data and resources, which is a security risk. IAM Access Analyzer also helps validate IAM policies against policy grammar and best practices, and generates IAM policies based on access activity in your AWS CloudTrail logs.

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. Findings from Access Analyzer automatically flow to Security Hub. Access Analyzer also sends an event to EventBridge for each generated finding, when the status of an existing finding changes, and when a finding is deleted. EventBridge can further direct these events to notification or remediation streams. 

Design consideration

• To get account-scoped findings (where the account serves as the trusted boundary), you 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 at the member account level. From there, they flow to the Security Hub delegated administrator account (Security Tooling).

Implementation example

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.

AWS Firewall Manager

AWS Firewall Manager helps protect your network by simplifying your administration and maintenance tasks for AWS WAF, AWS Shield Advanced, Amazon VPC security groups, AWS Network Firewall, and Route 53 Resolver DNS Firewall across multiple accounts and resources. With Firewall Manager, you set up your AWS WAF firewall rules, Shield Advanced protections, Amazon VPC security groups, AWS Network Firewall firewalls, and DNS Firewall rule group associations only once. The service automatically applies the rules and protections across your accounts and resources, even as you add new resources.

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). 

You must enable AWS Config for each AWS Region that contains the resources that you want to protect. 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 and Firewall Manager, Firewall Manager automatically sends your findings to Security Hub. Firewall Manager creates findings for resources that are out of compliance and for attacks that it detects, and sends the findings to Security Hub. When you set up a Firewall Manager policy for AWS WAF, you can centrally enable logging on web access control lists (web ACLs) for all in-scope accounts and centralize the logs under a single 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 AWS Firewall Manager. It demonstrates delegated administration (Security Tooling), deployss a maximum allowed security group, configuress a security group policy, and configures multiple WAF policies.

Amazon EventBridge

Amazon EventBridge is a serverless event bus service that makes it straightforward to connect your applications with data from a variety of sources. It is frequently used in security automation. You can set up routing rules to determine where to send your data to build application architectures that react in real time to all your data sources. You can create a custom event bus to receive events from your custom applications, in addition to using the default event bus in each account. You can create an event bus in the Security Tooling account that can receive security-specific events from other accounts in the AWS organization. For example, by linking AWS Config rules, GuardDuty, and Security Hub with EventBridge, you create a flexible, automated pipeline for routing security data, raising alerts, and managing actions to resolve issues. 

Design considerations

• EventBridge is capable of routing 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 might 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.

• A best practice for a successful security operations team is to 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 supports your responsive security control strategy by making it straightforward to analyze, investigate, and quickly identify the root cause of security findings or suspicious activities for your security analysts. Detective automatically extracts time-based events such as login attempts, API calls, and network traffic from AWS CloudTrail logs and Amazon VPC flow logs. You can use Detective to access up to a year of historical event data. Detective consumes these events by using independent streams of CloudTrail logs and Amazon VPC flow logs. Detective uses machine learning and visualization to create a unified, interactive view of the behavior of your resources and the interactions among them over time—this is called a behavior graph. You can explore the behavior graph to examine disparate actions such as failed logon attempts or suspicious API calls.

Detective also ingests findings that are detected by Amazon GuardDuty. When an account enables Detective, it becomes the administrator account for the behavior graph. Before you try to enable Detective, make sure that your account has been enrolled in GuardDuty for at least 48 hours. If you do not meet this requirement, you cannot enable Detective.

Detective automatically groups multiple findings 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. This helps reduce the triage time and supports more comprehensive security investigations.

Detective integrates with AWS Organizations. The Org 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 consoles. These links can help streamline the investigation process. Your account must be the administrative account for both Detective and the service you are pivoting from (GuardDuty or Security Hub). If the primary accounts are the same for the services, the integration links work seamlessly.

AWS Audit Manager

AWS Audit Manager helps you continually audit your AWS usage to simplify how you manage audits and compliance with regulations and industry standards. It enables you to move from manually collecting, reviewing, and managing evidence to a solution that automates evidence collection, provides a simple way to track the source of audit evidence, enables teamwork collaboration, and helps to manage evidence security and integrity. When it's time for an audit, Audit Manager helps you manage stakeholder reviews of your controls.

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, 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.

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. 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 and AWS Config to help implement a risk management framework. Audit Manager provides independent risk assurance functionality, whereas Security Hub 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 evidence, the delegated administrator account for both services has to 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 is hosted within the Security Tooling account to delegate the compliance artifact management functionality from the AWS Org Management account. This delegation is important because we recommend that you avoid using the AWS Org Management account for deployments unless absolutely necessary. Instead, delegate deployments to member accounts. Because audit artifact management can be done from a member account and the function closely aligns with security and compliance teams, the Security Tooling account is designated as the delegated administrator account for AWS Artifact. You can use AWS Artifact reports to download AWS security and compliance documents, such as AWS ISO certifications, Payment Card Industry (PCI), and System and Organization Controls (SOC) reports. You can restrict this capability to only AWS Identity and Access Management (IAM) roles pertaining to your audit and compliance teams, so they can download, review, and provide those reports to external auditors as needed. You can 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 KMS) helps you create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules to protect cryptographic keys. It follows industry standard lifecycle processes for key material, such as storage, rotation, and access control of keys. AWS KMS can help protect your data with encryption and signing keys, and can be used for both server-side encryption and client-side encryption through the AWS Encryption SDK. For protection and flexibility, AWS KMS supports three types of keys: customer managed keys, AWS managed keys, and AWS owned keys. Customer managed keys are AWS KMS keys in your AWS account that you create, own, and manage. AWS managed keys are AWS KMS keys in your account that are created, managed, and used on your behalf by an AWS service that is integrated with AWS KMS. AWS owned keys are a collection of AWS KMS keys that an AWS service owns and manages for use in multiple AWS accounts. For more information about using KMS keys, see the AWS KMS documentation and AWS KMS Cryptographic Details.

One deployment option is to centralize the responsibility of 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 can encounter hurdles due to AWS KMS throttling limits, account service limits, and the security team being inundated with operational key management tasks. Another deployment option is to have a decentralized model in which you allow AWS KMS to reside in multiple accounts, and you allow those responsible for the infrastructure and workloads in a specific account to manage their own keys. 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. In a decentralized model it is important to deploy and enforce guardrails so that the decentralized keys are managed in the same way and usage of KMS keys is audited according to established best practices and policies. For more information, see the whitepaper AWS Key Management Service Best Practices. AWS SRA recommends a distributed key management model in which the KMS keys reside locally within the account where they are used. We recommend that you avoid using a single key in one account for all cryptographic functions. Keys can be created based on 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. 

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 organization.

AWS Private CA

AWS Private Certificate Authority (AWS Private CA) is a managed private CA service that helps you securely manage the lifecycle of your private end-entity TLS certificates for EC2 instances, containers, IoT devices, and on-premises resources. It allows encrypted TLS communications to running applications. With 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 can 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

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. Ideally, your root and subordinate CAs are 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 is an automated vulnerability management service that automatically discovers and scans Amazon EC2 instances, container images in Amazon Container Registry (Amazon ECR), and AWS Lambda functions for known software vulnerabilities and unintended network exposure.

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 when a new common vulnerabilities and exposures (CVE) report that affects the resource is published.

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.

In order to scan for vulnerabilities, EC2 instances must be managed in AWS Systems Manager by using AWS Systems Manager Agent (SSM Agent). 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 automatically when both services are enabled. You can use this integration to send all findings from Amazon Inspector to Security Hub, 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.

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.

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. Some of these services should be deployed in all accounts, and you will see them in the AWS SRA. This enables a consistent set of guardrails and provides centralized monitoring, management, and governance across your AWS organization. 

Security Hub, GuardDuty, AWS Config, Access Analyzer, and AWS CloudTrail organization trails appear in all accounts. The first three support the delegated administrator feature discussed previously in the Management account, trusted access, and delegated administrators section. CloudTrail currently uses a different aggregation mechanism.

The AWS SRA GitHub code repository provides a sample implementation of enabling Security Hub, GuardDuty, AWS Config, Firewall Manager, and CloudTrail organization trails across all your accounts, including the AWS Org Management account.

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 either EC2 instances or Amazon ECR images.

• 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 at the start of your project, and then build on these by using services that provide additional capabilities.