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, 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
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
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
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
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, 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 customization process. (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 them up, see the blog post Three recurring Security Hub usage patterns and how to deploy them
. -
Implementation example
The AWS SRA
code library
Amazon GuardDuty
Amazon GuardDuty
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
AWS Config
AWS Config
You can evaluate the configuration settings of your AWS resources by using AWS Config rules. AWS Config provides a library of customizable, predefined rules called managed rules, or you can write your own custom rules. You can run AWS Config rules in proactive mode (before resources have been deployed) or detective mode (after resources have been deployed). 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.
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 AWS CLI commands to validate JSON-formatted or YAML-formatted structured data such as CloudFormation change sets, JSON-based Terraform configuration files, or Kubernetes configurations. You can run the evaluations locally by using the AWS CloudFormation Guard CLI
as part of your authoring process or run it within your deployment pipeline . If you have AWS Cloud Development Kit (AWS CDK) applications, you can use cdk-nag for proactive checking of best practices.
Implementation example
The AWS SRA
code library
Amazon Security Lake
Amazon Security Lake
AWS SRA recommends that you use the Log Archive account as the delegated administrator account for Security Lake. For more information about setting up the delegated administrator account, see Amazon Security Lake in the Security OU – Log Archive account section. Security teams that want to access Security Lake data or need the ability to write non-native logs to the Security Lake buckets by using custom extract, transform, and load (ETL) functions should operate within the Security Tooling account.
Security Lake can collect logs from different cloud providers, logs from third-party solutions, or other custom logs. 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:
-
Data access – Subscribers can directly access the Amazon S3 objects for Security Lake. Security Lake manages the infrastructure and permissions. When you configure the Security Tooling account as a Security Lake data access subscriber, the account is notified of new objects in the Security Lake buckets through Amazon Simple Queue Service (Amazon SQS), and Security Lake creates the permissions to access those new objects.
-
Query access – Subscribers can query source data from AWS Lake Formation tables in your S3 bucket by using services such as Amazon Athena. Cross-account access is automatically set up for query access by using AWS Lake Formation. When you configure the Security Tooling account as a Security Lake query access subscriber, the account is given read-only access to the logs in the Security Lake account. When you use this subscriber type, the Athena and AWS Glue tables are shared from the Security Lake Log Archive account with the Security Tooling account through AWS Resource Access Manager (AWS RAM). To enable this capability, you have to update the cross-account data sharing settings to version 3.
For more information about creating subscribers, see Subscriber management in the Security Lake documentation.
For best practices for ingesting custom sources, see Collecting data from custom sources in the Security Lake documentation.
You can use Amazon QuickSight
Design consideration
If an application team needs query access to Security Lake data to meet a business requirement, the Security Lake administrator should configure that Application account as a subscriber.
Amazon Macie
Amazon Macie
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
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
IAM Access Analyzer findings also help you identify unused access granted in your AWS organizations and accounts, including:
-
Unused IAM roles – Roles that have no access activity within the specified usage window.
-
Unused IAM users, credentials, and access keys – Credentials that belong to IAM users and are used to access AWS services and resources.
-
Unused IAM policies and permissions – Service-level and action-level permissions that weren't used by a role within a specified usage window. IAM Access Analyzer uses identity-based policies that are attached to roles to determine the services and actions that those roles can access. The analyzer provides a review of unused permissions for all service-level permissions.
You 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:
-
IAM policy validation – IAM Access Analyzer validates your policies against IAM policy grammar and AWS best practices. You can view findings for policy validation checks, including security warnings, errors, general warnings, and suggestions for your policy. Over 100 policy validation checks are currently available and can be automated by using the AWS Command Line Interface (AWS CLI) and APIs.
-
IAM custom policy checks – IAM Access Analyzer custom policy checks validate your policies against your specified security standards. Custom policy checks use automated reasoning to provide a higher level of assurance on meeting your corporate security standards. The types of custom policy checks include:
-
Check against a reference policy: When you edit a policy, you can compare it with a reference policy, such as an existing version of the policy, to check whether the update grants new access. The CheckNoNewAccess API compares two policies (an updated policy and a reference policy) to determine whether the updated policy introduces new access over the reference policy, and returns a pass or fail response.
-
Check against a list of IAM actions: You can use the CheckAccessNotGranted API to ensure that a policy doesn't grant access to a list of critical actions that are defined in your security standard. This API takes a policy and a list of up to 100 IAM actions to check whether the policy allows at least one of the actions, and returns a pass or fail response.
-
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.
-
You must have a CloudTrail trail enabled for your account to generate a policy based on access activity.
-
IAM Access Analyzer doesn't identify action-level activity for data events, such as Amazon S3 data events, in generated policies.
-
The
iam:PassRole
action isn't tracked by CloudTrail and isn't included in generated policies.
Access Analyzer is deployed in the Security Tooling account through the delegated administrator functionality in AWS Organizations. The delegated administrator has permissions to create and manage analyzers with the AWS organization as the zone of trust.
Design consideration
-
To get account-scoped findings (where the account serves as the trusted boundary), you 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 examples
-
The AWS SRA code library
provides a sample implementation of IAM Access Analyzer . It demonstrates how to configure an organization-level analyzer within a delegated administrator account and an account-level analyzer within each account. -
For information about how you can integrate custom policy checks into builder workflows, see the AWS blog post Introducing IAM Access Analyzer custom policy checks
.
AWS Firewall Manager
AWS Firewall Manager
Firewall Manager is particularly useful when you want to protect your entire AWS organization instead of a small number of specific accounts and resources, or if you frequently add new resources that you want to protect. Firewall Manager uses security policies to let you define a set of configurations, including relevant rules, protections, and actions that must be deployed and the accounts and resources (indicated by tags) to include or exclude. You can create granular and flexible configurations while still being able to scale control out to large numbers of accounts and VPCs. These policies automatically and consistently enforce the rules you configure even when new accounts and resources are created. Firewall Manager is enabled in all accounts through AWS Organizations, and configuration and management are performed by the appropriate security teams in the Firewall Manager delegated administrator account (in this case, the Security Tooling account).
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
Amazon EventBridge
Amazon EventBridge
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
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.
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
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
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.
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
The AWS SRA recommends a distributed key management model in which the KMS keys reside locally within the account where they are used, and you allow those who are responsible for the infrastructure and workloads in a specific account to manage their own keys. 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. 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 a single AWS account, and simplifies reporting, auditing, and other compliance-related tasks. 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 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 Security best practices for AWS Key Management Service in the AWS KMS documentation.
An alternate 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.
The AWS SRA combines the centralized and distributed models. 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. The Application account section later in this guide describes the KMS key patterns used to secure workload-specific resources.
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
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.
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
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
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.
-