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:

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

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, which are 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. You can use the Security Hub central configuration feature from the delegated administrator account (in this case, Security Tooling) to specify how the Security Hub 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 you don't use central configuration, you must configure Security Hub 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 can 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 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. Security Hub processes findings by using a standard format called the AWS Security Finding Format (ASFF). Security Hub correlates the findings across integrated products to prioritize the most important ones. You can enrich the metadata of Security Hub 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. 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 can use automation rules to automatically update findings. As Security Hub 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 can 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 to Amazon Detective to investigate an Amazon GuardDuty finding. Security Hub recommends aligning the delegated administrator accounts for services such as Detective (where they exist) for smoother integration. For example, if you do not align administrator accounts between Detective and Security Hub, navigating 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 its monitoring features, Security Hub supports integration with Amazon EventBridge to automate the 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. For additional discussions and examples, see the 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.

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

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.

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 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. You can get essential insights such as a summary of compliance by resources, the top 10 accounts that have noncompliant resources, a comparison of running and stopped EC2 instances by type, and EBS volumes by volume type and size.

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.

Amazon Security Lake

Amazon Security Lake is a fully managed security data lake service. You can use Security Lake to automatically centralize security data from AWS environments, software as a service (SaaS) providers, on premises, and third-party sources. Security Lake helps you build a normalized data source that simplifies the usage of analytics tools over security data, so you can get a more complete understanding of your security posture across the entire organization. The data lake is backed by Amazon Simple Storage Service (Amazon S3) buckets, and you retain ownership over your data. Security Lake automatically collects logs for AWS services, including AWS CloudTrail, Amazon VPC, Amazon Route 53, Amazon S3, AWS Lambda, and Amazon EKS audit logs.

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. We recommend 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 AWS 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:

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 QuickSight, Amazon OpenSearch, and Amazon SageMaker to set up analytics against the security data that you store in Security Lake.

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.

AWS IAM Access Analyzer

As you accelerate your AWS Cloud adoption journey and continue to innovate, it’s critical to maintain tight control over fine-grained access (permissions), contain access proliferation, and ensure that permissions are used effectively. 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 IAM Access Analyzer provides tools to efficiently set fine-grained permissions, verify intended permissions, and refine permissions by removing unused access to help you meet your enterprise security standards. It gives you visibility into external and unused access findings through dashboards and AWS Security Hub. Additionally, it supports Amazon EventBridge for event-based custom notification and remediation workflows.

The IAM Access Analyzer external 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 to analyze all supported resources within the zone of trust, and generates findings for principals that can access the resources from outside the zone of trust. These findings help identify resources that are shared with an external entity and help you preview how your policy affects public and cross-account access to your resource before you deploy resource permissions.

IAM Access Analyzer findings also help you identify unused access granted in your AWS organizations and accounts, including:

You can use the findings generated from IAM Access Analyzer to gain visibility into, and remediate, any 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 can 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 can 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:

Security teams and other IAM policy authors can 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.

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.

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. 

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. 

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

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.

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.

AWS Artifact

AWS Artifact is hosted within the Security Tooling account to separate the compliance artifact management functionality from the AWS Org Management account. This separation of duty is important because we recommend that you avoid using the AWS Org Management account for deployments unless absolutely necessary. Instead, pass on deployments to member accounts. Because audit artifact management can be done from a member account and the function closely aligns with the security and compliance team, the Security Tooling account is designated as the 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.

AWS Artifact doesn't support the delegated administration feature. Instead, you can 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 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.

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.

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 the publication of a new common vulnerabilities and exposures (CVE) report that affects the resource. Amazon Inspector supports Center of 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 the Amazon Inspector service. 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 AWS 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.

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.

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.