# Introduction to AWS Security Hub AWS Security Hub is a unified cloud security solution that prioritizes your critical security issues and helps you respond at scale. Security Hub detects security issues by automatically correlating and enriching security signals from multiple sources, such as posture management, vulnerability management (Amazon Inspector), sensitive data (Amazon Macie), and threat detection (Amazon GuardDuty). This enables security teams to prioritize active risks in their cloud environments through automated analyses and contextual insights. Through intuitive visualizations, Security Hub transforms complex security signals into actionable insights, which enables you to make informed decisions about your security quickly. Security Hub also includes automated response workflows to help you remediate risks, improve team productivity, and minimize operational disruptions. ## Features **Unified security solution** Gain broader visibility across your cloud environment through centralized management in a unified cloud security solution. **Actionable security insights** Gain actionable security insights through advanced analytics to learn about security risks associated with your environment. **Reduced response times** Streamline response times with automated workflows and an integrated ticketing system. **Exposure findings** Security Hub correlates findings from Security Hub CSPM control checks, Amazon Inspector, and other AWS services to detect exposures associated with AWS resources. **Findings are formatted in the Open Cybersecurity Schema Framework (OCSF)** Security Hub generates findings in OCSF and receives findings in OCSF from Security Hub CSPM and other AWS services: + Amazon GuardDuty + Amazon Macie + Amazon Inspector **Dashboard** The Security Hub console provides a comprehensive view of your exposures, threats, security coverage, and resources, as well as an interactive visualization called the attack path graph, which shows how potential attackers can access and take control of resources associated with an exposure finding. **Integrations with third-party products** You can enhance your security posture with Security Hub integrations. For example, if you use Jira Cloud or ServiceNow ITSM, you can use this feature to create tickets from findings. ## Integrations Security Hub receives findings from the following AWS services. + AWS Security Hub CSPM + Amazon GuardDuty + Amazon Inspector + Amazon Macie ## Accessibility Security Hub is available in most AWS Regions. For a list of Regions where Security Hub is currently available, see [Security Hub endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/sechub.html) in the *AWS General Reference*. For information about managing AWS Regions for your AWS account, see [Specifying which AWS Regions your account can use](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) in the *AWS Account Management Reference Guide*. You can enable Security Hub for individual accounts or accounts in your organization. In each Region, you can access and use Security Hub in any of the following ways: **Security Hub console** The Security Hub console is a browser-based interface you can use to create and manage AWS resources. In this console, you can access your account, data, and resources. **Security Hub API** The Security Hub API gives you programmatic access to your account, data, and resources. You can send HTTPS requests directly to Security Hub. **AWS CLI** With [the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html), you can run commands in your system command line to perform tasks and build scripts that perform tasks. In some cases, the AWS CLI can be more useful than the Security Hub console. **AWS SDKs** [AWS SDKs](https://aws.amazon.com/developertools/) consist of libraries and sample code for various programming languages and platforms (C\$1\$1, Go, Java, .NET, and Python). They provide programmatic access to Security Hub and other AWS services in your preferred language and can help you manage tasks such as managing errors, signing requests, and retrying requests. ## Pricing # Security Hub concepts In Security Hub, we build on common AWS concepts and terminology and use these additional terms. **Account** The standard AWS account containing your AWS resources. Sign in to AWS with your AWS account to enable Security Hub. If your account is enrolled in AWS Organizations, your organization designates a Security Hub administrator account. This account can enable other organization accounts as member accounts. An organization can only have one administrator account. An account cannot be an administrator account and a member account simultaneously. Security Hub supports the following accounts: + Organization management account — an AWS account that administers an AWS organization. + Delegated administrator account — an AWS account that manages the use of an AWS service for an AWS organization. + Member account — an AWS account that is a member of an AWS organization. + Standalone account — an AWS account without AWS Organizations enabled **Administrator account** This type of AWS account can view findings for associated member accounts. This type of AWS account becomes an administrator account when the account is designated by an organization management account as the Security Hub administrator account. The Security Hub administrator account can enable any organization account as a member account and can also invite other accounts to be member accounts. An organization can only have one administrator account. An account cannot be an administrator account and a member account simultaneously. **Aggregation Region** An aggregation Region allows you to view security findings from multiple AWS Regions in a single pane of glass. The aggregation Region is the AWS Region where you view and manage findings. Findings are aggregated in the aggregation Region from linked Regions. Updated findings are replicated across Regions. In the aggregation Region, the dashboard and inventory pages include data from all linked Regions. The automations page can only be used to define automation rules in the aggregation region. Third-party ticketing integrations can only be configured in the aggregation region. **Archived finding** A finding with a status of `ARCHIVED`. These findings indicate the finding provider or customer investigating the finding believes the finding is no longer relevant. Finding providers can archive findings they create. Customers can archive any findings that they believe are no longer relevant using the [BatchUpdateFindingsV2](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_BatchUpdateFindingsV2.html) operation of the Security Hub API or by updating the status in the Security Hub console. In the Security Hub console, default filter settings exclude archived findings from finding lists and tables. You can update the filters to include archived findings. If you retrieve findings by using the [GetFindingsV2](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation, the operation retrieves both archived and active findings. The following example shows how to exclude archived findings in the results. ``` { "StringFilters": [ { "FieldName": "status", "Filter": { "Value": "Archived", "Comparison": "EQUALS" } } ] } ``` **Cross-Region aggregation** The aggregation of findings and resources from linked Regions to an aggregation Region. You can view all of your data from the aggregation Region and update findings from the aggregation Region. **Delegated administrator account** In AWS Organizations, the delegated administrator account for a service is able to manage the use of a service for the organization. In Security Hub, the Security Hub administrator account is also the delegated administrator account for Security Hub. When the organization management account first designates the Security Hub administrator account, Security Hub calls Organizations to make that account the delegated administrator account. The organization management account must then choose the delegated administrator account as the Security Hub administrator account in all Regions. **Exposure** Exposures are broader weaknesses in security controls, misconfigurations, or other areas that could be exploited by active threats. Examples of exposures include: + Mis-configured control plane for a resource. + Presence of a software vulnerability that has a high potential for exploitability. + Publicly accessible resource (network or API). **Exposure finding** A type of finding that describes an exposure present in your environment. An exposure finding includes traits and signals. A signal can include one or more types of exposure traits. AWS Security Hub generates an exposure finding when signals from AWS Security Hub CSPM, Amazon Inspector, Amazon GuardDuty, Amazon Macie, or other AWS services, indicate the presence of an exposure. A resource can be involved in one or more exposure findings. If a resource doesn't have any exposure traits or has insufficient traits, Security Hub doesn't generate an exposure finding for that resource. An example of an exposure finding is: An EC2 instance that is reachable from the internet and has software vulnerabilities which have a high liklihood of exploitation. **Finding** The observable record of a security check or security-related detection. Security Hub generates and updates findings through the correlation of other security findings. These are called *exposure findings*. Findings can also come from integrations with other AWS services and third-party products. **Finding ingestion** The import of findings into Security Hub . Finding ingestion events include both new findings and updates to existing findings. **Linked Region** When you enable cross-Region aggregation, a linked Region is a region that aggregates findings and resource inventory to the aggregation Region. In a linked Region, the dashboard and inventory pages only contain findings for that AWS Region. **Open cybersecurity schema framework (OCSF)** The [Open Cybersecurity Schema Framework (OCSF)](https://schema.ocsf.io/) is a collaborative, open-source effort by AWS and leading partners in the cybersecurity industry. OCSF provides a standard schema for common security events, defines versioning criteria to facilitate schema evolution, and includes a self-governance process for security log producers and consumers. For more information, see [OCSF findings in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-ocsf.html). **Member account** An AWS account that granted permission to an administrator account to view and take action on their findings. This kind of AWS account becomes a member account when the Security Hub administrator account enables it as a member account. **Signal** A finding that contributes to an exposure finding. A signal can be referred to as a *contributing finding*. A signal can originate in Security Hub CSPM, AWS Config, or other AWS services, such as Amazon Inspector. **Trait** A security deviation that results in an exposure finding. Trait types include **Assumability**, **Misconfiguration**, **Reachability**, **Sensitive Data**, and **Vulnerability**. A trait is associated with one signal, and a signal can contain multiple traits. For example, a Security Hub CSPM control indicates a customer-managed policy allows administrative access control. This signal contains a misconfiguration trait. # AWS Security Hub Cost Estimator The Security Hub cost estimator is a console feature that provides estimates for capabilities across your AWS environnment. The cost estimator shows you what your individual service costs are across AWS Security Hub CSPM, Amazon Inspector, and Amazon GuardDuty and what your estimated costs would be in Security Hub with Security Hub's simplied pricing plans. You can adjust estimated usage and resource counts to match your AWS usage to increase the accuracy of your estimate. The cost estimator is available in all regions where Security Hub is available. The cost estimator estimates montly costs for security capabilities using two pricing models: + **Individual services pricing** – Pay for each security feature separately (GuardDuty, Amazon Inspector, Security Hub CSPM). + **Security Hub simplified pricing** – Unified pricing across 3 pricing plans, essentials plan with per-resource pricing, threat analytics with per-event and per-GB logs pricing, and Lambda Code scanning with per-resource pricing. The estimator uses AWS Cost Explorer data when available. When Cost Explorer data is unavailable, you can manually enter usage data. Cost estimates are based on observed and user provided usage, and public pricing infomation. Estimates may not reflect enterprise discounts. Key benefits of the cost estimator include: + See how the cost with unified pricing, when enabling Security Hub, compares against cost with individual service without enabling Security Hub + Estimate costs before enabling capabilities + Adjust usage parameters to model different scenarios + Export estimates as PDF for stakeholder review ## Access by account type **Note** For Delegated administrator and member accounts, the cost estimator opens in edit mode by default, allowing you to immediately enter usage data. Management account and standalone accounts open in view mode when Cost Explorer data is available. This feature automatically retrieves information on actual past usage to estimate the cost for certain account types. See below for details on each of the account types and the data that is available for each account type. **Access permissions by account type** | Account Type | Cost Explorer Data | Data Entry | Scope | | --- | --- | --- | --- | | Management Account (MA) | Auto-populated | Manual override available | Organization-wide | | Delegated Administrator (DA) | Auto-populated via cross-account role\$1 | Manual override available | Organization-wide | | Member Account | Auto-populated via cross-account role\$1 | Manual override available | Organization-wide | | Standalone Account (SA) | Auto-populated | Manual override available | Single account | \$1 Requires cross-account IAM role configuration in management account. See [Setting up cross-account access](setting-up-cross-account-access.md) section below. ## Prerequisites ### Required IAM permissions In order to use the all of the cost estimator's capabilties your IAM principal must have the following permissions: **Required IAM permissions for Cost Estimator** | API Operation | Service | Purpose | | --- | --- | --- | | ce:GetCostAndUsage | AWS Cost Explorer | Retrieve historical usage and cost data | | pricing:GetProducts | AWS Pricing | Get current pricing rates | | organizations:ListAccounts | AWS Organizations | Count accounts in organization | | organizations:DescribeOrganization | AWS Organizations | Determine account type | | securityhub:ListOrganizationAdminAccounts | Security Hub | List organization admin accounts | | iam:GetRole | IAM | Check cross-account role existence (Management account only)\$1 | | sts:AssumeRole | IAM | Assume cross-account role (Delegated administrator/Member account only)\$1\$1 | \$1 Required only for Management Account users to verify cross-account role status. \$1\$1 Required only for Delegated Administrator and Organization Member accounts using cross-account access. ### Additional requirements **Cost Explorer** Must be enabled for automatic data population (24-hour processing delay after enablement). # Setting up cross-account access Delegated administrator and member accounts can access organization-wide AWS Cost Explorer data from the management account by configuring a cross-account IAM role. This configuration allows these accounts to view actual usage data without switching to the management account. ## Prerequisites The following items and information are needed in advance of setting up cross-account access for the cost estimator: + Management account must have AWS Cost Explorer enabled. + IAM permissions to create roles in the management account. + Knowlege of the delegated administrator or member account ID that will be granted cross-account access. ## Setup steps The cost estimator provides guided setup instructions directly in the console. To access the instructions navigate to the cost estimator page at [https://console.aws.amazon.com/securityhub/v2/home\$1/costEstimator](https://console.aws.amazon.com/securityhub/v2/home#/costEstimator) in your organization management account. Locate the **Cross-account access** section and follow the steps outlined for setting up the cross account role. ## Role configuration Cross account access for the cost estimator requires setting up an IAM role with a trust policy and a permissions policy. The cross-account role must be created in the management account with the following configuration: **Role name (exact name required)** – AwsSecurityHubCostEstimatorCrossAccountRole **Recommended trust policy:** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{ACCOUNT_ID}:role/{ROLE_NAME}" }, "Action": "sts:AssumeRole" } ] } ``` Edit the policy by replacing the following values in the policy example: + Replace *\$1ACCOUNT\$1ID\$1* with the delegated administrator or member account ID that you are granting cross-account access to. + Replace *\$1ROLE\$1NAME\$1* with the IAM role name in the delegated administrator or member account that you are granting access to. **Recommended permissions policy:** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ce:GetCostAndUsage", "Resource": "*" } ] } ``` **Note** The trust policy restricts access to a specific account and role. Only the specified IAM principal can assume this role, preventing unauthorized access. ## Verification After creating the role in the management account use the following steps to confirm the setup is working. 1. Sign into the delegated administrator or member account. 1. Navigate to the Security Hub cost estimator at [https://console.aws.amazon.com/securityhub/v2/home\$1/costEstimator](https://console.aws.amazon.com/securityhub/v2/home#/costEstimator) 1. The page should automatically: 1. Detect the management account in your organization. 1. Assume the cross-account role. 1. Load Cost Explorer data with organization-wide usage. If successful, you'll see actual usage data instead of manual entry fields. ## Troubleshooting This section covers common issues and solutions that can occur when settting up cross-account access. ### Organizational usage data is not available for this account This alert indicates the cross-account role is not accessible. Possibles caused of this alert are: 1. **Role does not exist:** Management account has not created the role yet. 1. **Solution:** Contact your management account administrator to create the role using the setup guidance. 1. **Role name mismatch:** Role name doesn't match exactly. 1. **Solution:** Verify role name is `AwsSecurityHubCostEstimatorCrossAccountRole`. 1. **Trust policy incorrect:** Trust policy doesn't allow your account to assume the role. 1. **Solution:** Verify trust policy includes your account ID and role name. 1. **Missing AssumeRole permission:** Your IAM principal lacks `sts:AssumeRole`. 1. **Solution:** Contact your administrator to add `sts:AssumeRole` permission. **To view detailed setup instructions:** Click "View instructions" link in the alert to open a modal with step-by-step guidance and policy templates. **Workaround:** You can still use the Cost Estimator by manually entering usage values in edit mode. # Using the cost estimator ## Accessing the cost estimator **To access the Cost Estimator from the Security Hub landing page** 1. Sign in to your AWS account with your AWS organization management or delegated administrator account credentials. Open the Security Hub console in the us-east-1 region at [https://console.aws.amazon.com/securityhub/v2/home]( https://us-east-1.console.aws.amazon.com/securityhub/v2/home). 1. On the landing page, locate the **Pricing** card. 1. Choose **Estimate cost**. **To access the Cost Estimator during Security Hub enable and configuration steps** 1. Locate the **Pricing in the new Security Hub** card in the onboarding interface. 1. Choose **View estimates**. **To access the cost estimator from GuardDuty, Amazon Inspector, or Security Hub CSPM consoles** 1. Navigate to the service dashboard or summary page. 1. Choose **Compare pricing** in the pricing information card. ## Understanding the cost estimator interface ### Page layout The Cost Estimator page contains three main sections: + **Overview section** – Explains unified security management and cost optimization benefits. + **Pricing information** – Expandable panel with capability categories and pricing tiers. + **Pricing comparison table** – Side-by-side cost comparison with capability details. ### Pricing comparison table The table header includes view/edit mode controls and a reset option. The table displays costs in two columns: + **Individual services** – Current or estimated costs for separate security services. + **Security Hub** – Estimated costs using simplified pricing model. ### Pricing region The first column displays pricing context information, including a note that estimates use us-east-1 pricing for calculations. A badge indicates that enterprise discounts are not included in the estimates. ## Viewing cost estimates When using the cost estimator you can view, edit, reset, and export estimates. The cost estimator opens in view mode by default. **To view cost estimates** 1. Access the Cost Estimator using one of the methods described in [Accessing the cost estimator](#accessing-cost-estimator). 1. Review the total monthly costs in the summary row. 1. Review capability groups and their detailed cost breakdowns. 1. Choose capability names to view descriptions in a popover. **Data sources in view mode** The estimator displays data from multiple sources, indicated by labels: + **Default** – Data from AWS Cost Explorer (past 30 days). + **\$1-/mo** – Cost data unavailable (shown when Cost Explorer access is not available). + **Custom usage** – User-entered values. + **Not enabled** – Shows when Cost Explorer permissions do not exist. ## Account-specific behavior The following describes how the cost estimator functions across different types accounts and configurations. ### Delegated administrator and member accounts **With cross-account access configured:** + Cost Explorer data is available with organization-wide usage. + Opens in view mode by default (same as management account). Can switch to edit mode to modify estimates. **Without cross-account access configured:** + Alert displays: "Organizational usage data is not available for this account". + Opens in edit mode by default for manual entry. + Click "View instructions" in alert for setup guidance. ### Management account **With cross-account role created:** + "Cross-account access" section shows configured state. + Displays recommended policies for verification. + Provides link to view role in IAM console. **Without cross-account role created:** + "Cross-account access" section displays setup guide. + Provides step-by-step instructions with pre-populated policies. + Direct link to IAM console for role creation. **Unable to verify role status:** + If there is no permission to call `iam:GetRole`, the console cannot determine if you have created the necessary role. + Shows “Unable to verify” with corresponding error message. ### Standalone account **Without cross-account role created:** + No changes to existing behavior. + Cost Explorer data is available when enabled. + Opens in view mode by default. ## Editing usage values Edit mode allows you to modify dimension values and see real-time cost updates. **To edit usage values** 1. Choose **Edit** in the table header. 1. Enter values in the dimension input fields. 1. View updated costs automatically. 1. Choose **View** to return to view mode. **Important** Edits are not saved when you leave the cost estimator page Modified estimates use us-east-1 (N. Virginia) pricing and do not include enterprise discounts Editing in "Show current cost only" mode automatically switches back to estimated mode ## Resetting the estimator This action clears all custom values and reloads default data from Cost Explorer. **To reset all values to defaults** 1. Choose **Reset** in the table header. 1. In the confirmation dialog, choose **Reset**. ## Exporting estimates While in the cost estimator the data for your estimate can be exported to a PDF file. **To export cost estimates** 1. Ensure you are in view mode. 1. Choose **Download PDF** in the page header. The PDF downloads automatically with filename: `SecurityHub-Cost-Estimate-YYYY-MM-DD.pdf`. ## Troubleshooting This section covers common issues and solutions that can occur when using the cost estimator ### No Cost Explorer data available **Problem** Alert displays "No cost data available for your account". **Solutions by account type** The solution depends on your account type: **Solutions for missing Cost Explorer data** | Account Type | Solution | | --- | --- | | Management Account | Enable Cost Explorer and wait 24 hours for data processing | | Delegated Administrator | Contact Management Account administrator to request access | | Member Account | Contact Management Account or Delegated Administrator for access | | Standalone Account | Enable Cost Explorer and wait 24 hours for data processing | **Workaround** Enter custom values in edit mode. ### Cross-account access not working **Problem** "Delegated administrator or member account displays "Organizational usage data is not available for this account" alert. **Possible causes and solutions** 1. Cross-account role doesn't exist in management account. 1. **Solution:** Contact Management Account administrator to create the role. 1. The cost estimator provides guided setup instructions for management account users. 1. Role name doesn't match exactly. 1. Required role name: `AwsSecurityHubCostEstimatorCrossAccountRole`. 1. **Solution:** Verify role name in IAM console matches exactly (case-sensitive). 1. Trust policy doesn't allow your account. 1. **Solution:** Verify trust policy principal includes your account ID and role name. 1. Format: `arn:aws:iam::{YOUR_ACCOUNT_ID}:role/{YOUR_ROLE_NAME}`. 1. Missing AssumeRole permission. 1. **Solution:** Verify your IAM principal has `sts:AssumeRole` permission. 1. ontact your AWS administrator to add this permission. **Workaround:** Enter custom values in edit mode to manually estimate costs without Cost Explorer data. **Getting detailed instructions** + Click "View instructions" link in the alert to open a modal with: + Step-by-step setup guidance + Pre-populated policy templates + Troubleshooting tips specific to your error ### Permission errors **Problem** "Access denied" error for specific API operations. **To resolve permission errors** 1. Note the denied operation from the error message (e.g., `ce:GetCostAndUsage`). 1. Choose **Copy** to copy the error details. 1. Send the error details to your AWS administrator. 1. Request the required IAM permissions listed in [Required IAM permissions](security-hub-cost-estimator.md#required-iam-permissions). **Note** You can still use edit mode to enter manual values when permissions are missing, except when Pricing API access is denied (prevents all cost estimates). ### Capability shows "Not enabled" **Problem** Capability displays "Not enabled" status. **Explanation** This status appears when you have Cost Explorer access but the capability is not currently active. If you see \$1-/mo instead, this indicates that Cost Explorer data is not available for your account type. **To view cost estimates** 1. Choose **Edit** to enter edit mode. 1. Enter dimension values for the capability. 1. View updated cost estimates. ### Capability shows "Not applicable" **Problem** Capability displays "Not applicable" in Individual services column. **Explanation** This capability is only available through Security Hub simplified pricing, not as a standalone service. ### Modified costs don't match Cost Explorer **Problem** Edited costs differ from original Cost Explorer values. **Explanation** Modified estimates use us-east-1 (N. Virginia) pricing rates and do not include enterprise discounts. Cost Explorer data reflects actual costs with applicable discounts. ## Important notes + **Estimates are based on observed and user provided usage, and public pricing infomation** – Actual costs may vary based on usage patterns and enterprise agreements + **30-day look back** – Cost Explorer data reflects the past 30 days of usage + **Pricing region** – All estimates use us-east-1 (N. Virgina) rates + **No impact on settings** – Changes in the estimator do not affect your current Security Hub or service configurations + **Enterprise discounts** – Modified estimates do not include enterprise discounts; only Cost Explorer data reflects actual discounted costs + **Data refresh** – Cost Explorer data updates daily; refresh the page to see the latest data ## Related information + [AWS Security Hub pricing](https://aws.amazon.com/security-hub/pricing/) + [AWS Cost Explorer User Guide](https://docs.aws.amazon.com/cost-management/latest/userguide/) + [AWS Pricing API Reference](https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/) + [Enabling Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) # Enabling Security Hub You can enable Security Hub for any AWS account. This section of the documentation describes all the steps required to enable Security Hub for an AWS Organization, or a standalone account. ## Enable Security Hub for an AWS Organization This section includes three steps: + In **Step 1**, the AWS organization management account designates a delegated administrator for their AWS Organization, creates the delegated administrator policy, and optionally enables Security Hub for their own account. + In **Step 2**, the delegated administrator for the organization enables Security Hub for their own account. + In **Step 3**, the delegated administrator for the organization configures all member accounts in the organization, for Security Hub and other supported security services. ### Step 1. Delegating an administrator account and optionally enabling Security Hub in the AWS organization management account **Note** This step only needs to be completed in one region of the organization management account. When assigning the delegated administrator account for Security Hub, the account you can choose for your delegated administrator will depend how you have configured a delegated administrator for Security Hub CSPM. If you have configured a delegated administrator for Security Hub CSPM, and that account is not the organizations management account, then that account will automatically be set as the Security Hub delegated administrator and a different account cannot be chosen. If the delegated administrator account for Security Hub CSPM is set as the organizations management account or is not set at all, you can choose which account will be your Security Hub delegated administrator account, except for the organizations management account. For information about designating a delegated administrator in Security Hub, see [Designating a delegated administrator account in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-set-da.html). For information about creating the delegated administrator policy in Security Hub, see [Creating the delegated administrator policy in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-policy-statement.html). **To designate an admistrator for Security Hub** 1. Sign in to your AWS account with your AWS organization management account credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the Security Hub homepage, select **Security Hub**, and choose **Get started**. 1. In the **Delegated administrator** section, choose an administrator account based on the provided options. As a best practice, we recommend using the same delegated administrator across security services for consistent governance. 1. Choose the **Trusted access** checkbox. Choosing this option grants your delegated administrator account the ability to configure certain capabilities, such as GuardDuty Malware Protection, on member accounts. If you uncheck this option Security Hub will not be able to enable these features on your behalf and you will need to enable them directly through the service that the feature is associated with. 1. (Optional) For **Account enablement**, select the box to enable Security Hub for your AWS account. 1. For **Delegated administrator policy**, choose one of the following options to add the policy statement. 1. (Option 1) Choose **Update this for me**. Select the box under the policy statement to confirm Security Hub will automatically create a delegation policy granting all required permission to the delegated administrator. 1. (Option 2) Choose **I want to attach this manually**. Choose **Copy and attach**. In the AWS Organizations console, under **Delegated administrator for AWS Organizations**, choose **Delegate**, and paste the resource policy in the delegation policy editor. Choose **Create Policy**. Open the tab where you are in the Security Hub console. 1. Choose **Configure**. ### Step 2. Enable Security Hub in the delegated administrator account The delegated administrator account completes this step. After the AWS Organization management account designates a delegated administrator for their organization, the delegated administrator must enable Security Hub for their own account before enabling for the entire AWS Organization. **To enable Security Hub in the delegated administrator account** 1. Sign in to your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the Security Hub homepage and choose **Get started**. 1. The security capabilities section outlines the capabilities that are automatically enabled and includedin the base per-resource price of Security Hub 1. (Optional) For **Tags**, determine whether to add a key-value pair to the account setup. 1. Choose **Enable Security Hub** to finish enabling Security Hub. 1. (Recommended) from the popup choose **Configure my organization** and proceed to Step 3. After you enable Security Hub, a service-linked role called [AWSServiceRoleForSecurityHubV2](https://docs.aws.amazon.com/securityhub/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-awssecurityhubv2servicerolepolicy) and a service-linked recorder are created in your account. The service-linked recorder is a type of AWS Config recorder managed by an AWS service that can record configuration data on service-specific resources. With a service-linked recorder, Security Hub enables an event-driven approach for obtaining resource configuration items required for exposure analysis coverage and reporting resource inventory. A service-linked recorder is configured per AWS account and AWS Region. For global resource types, an additional service-linked recorder is automatically created in the home region to record configuration changes for global resources, as AWS Config only records global resource types in their designated home region. For more information, see [Considerations for service-linked configuration recorders](https://docs.aws.amazon.com/config/latest/developerguide/stop-start-recorder.html#stop-start-recorder-considerations-service-linked) and [Recording regional and global resources](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html#select-resources-all). ### Step 3. Create a policy that enables Security Hub in all member accounts After enbling Security Hub in the delegated administrator account for an organization you need to create a policy that defines which services and capabilities are enabled in the organization member accounts. For more information, see [Enabling a configuration with a type of policy](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-da-policy.html#securityhub-v2-configuration-enable-policy). ## Enable Security Hub in a standalone account This procedure describes how to enable Security Hub in a standalone account. A standalone account is an AWS account that has not enabled AWS organizations. **To enable Security Hub in a standalone account** 1. Sign in to your AWS account with your account credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the Security Hub homepage, select **Get started**. 1. In the **Security capabilities** section do one of the following: 1. (Option 1) Choose **Enable all capabilities**. This will turn on all of the Security Hub essential capabilties, threat analytics, and additional capabilties. 1. (Option 2) Choose **Customize capabilities**. Select the threat analytics and additional capabilities that should be turned on. You cannot deselect any capabilities that are part of the Security Hub essential plan capabilities. 1. In the **Regions** section, choose **Enable all Regions** or **Enable specific Regions**. If you choose **Enable all Regions**, you can determine whether to automatically enable new Regions. If you choose **Enable specific Regions**, you must choose which Regions you want to enable. 1. (Optional) For **Resource tags**, add tags as key-value pairs to help you easily identify the configuration. 1. Choose **Enable Security Hub**. After you enable Security Hub, a service-linked role called [AWSServiceRoleForSecurityHubV2](https://docs.aws.amazon.com/securityhub/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-awssecurityhubv2servicerolepolicy) and a service-linked recorder are created in your account. The service-linked recorder is a type of AWS Config recorder managed by an AWS service that can record configuration data on service-specific resources. With a service-linked recorder, Security Hub enables an event-driven approach for obtaining resource configuration items required for exposure analysis coverage and reporting resource inventory. A service-linked recorder is configured per AWS account and AWS Region. For global resource types, an additional service-linked recorder is automatically created in the home region to record configuration changes for global resources, as AWS Config only records global resource types in their designated home region. For more information, see [Considerations for service-linked configuration recorders](https://docs.aws.amazon.com/config/latest/developerguide/stop-start-recorder.html#stop-start-recorder-considerations-service-linked) and [Recording regional and global resources](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html#select-resources-all). # Designating a delegated administrator in Security Hub In the AWS organization management account, you can designate a delegated administrator for your organization. As a best practice, we recommend using the same delegated administrator across security services for consistent governance. The procedure in this topic describes how to designate a delegated administrator in Security Hub. It assumes you previously enabled Security Hub but did not designate a delegated administrator during the enablement workflow. **Considerations** Consider the following when designating a delegated administrator in Security Hub: + The AWS organization management account can designate itself as the delegated administrator in Security Hub CSPM. The AWS organization management account cannot designate itself as the delegated administrator in Security Hub. In this scenario, the AWS organization management account must designate another AWS account as the delegated administrator in Security Hub. As a best practice, we recommend using the same delegated administrator across security services for consistent governance. + If the AWS organization management account designates a delegated administrator in Security Hub CSPM, that delegated administrator automatically becomes the delegated administrator in Security Hub. In this scenario, Security Hub only allows this particular AWS account to serve as the delegated administrator. **Note** If the AWS organization management account uses the same delegated administrator in Security Hub as it does in Security Hub CSPM, removing it through the Security Hub CSPM console or with the AWS Organizations API also removes it in Security Hub. Similarly, removing it through the Security Hub console or with the AWS Organizations API also removes it in Security Hub CSPM. When the delegated administrator is removed from Security Hub CSPM, Central Configuration will automatically opt out. ## Designating a delegated administrator after enabling Security Hub This procedure is for the AWS organization management account to complete. It assumes the AWS organization management account previously enabled Security Hub but did not designate a delegated administrator during the enablement workflow. **Note** After you complete this procedure, you must create a policy allowing the delegated administrator for your organization to configure Security Hub and perform specific actions in AWS Organizations. For more information, see [Creating the delegated administrator policy in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-policy-statement.html). **To designate a delegated administrator in Security Hub** 1. Sign in to your AWS account with your organization management account credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **General**. 1. In **Delegated administrator**, choose **Configure**. Select one of the provided AWS accounts, or enter the 12-digit AWS account number for the AWS account that you want to designate as the delegated administrator for your organization. Choose **Save**. # Creating the delegated administrator policy in Security Hub The AWS organization management account can create a policy allowing the delegated administrator to configure Security Hub and perform specific actions in AWS Organizations. The procedure in this topic describes how to create the policy. When completing the procedure, you can allow Security Hub to create the policy for you or manually create the policy. We recommend allowing Security Hub to create the policy for you, unless you want to customize the policy for a particular use case. The AWS organization management account must complete this procedure only if it enabled Security Hub and designated a delegated administrator, but skipped creating the policy when completing the [enablement](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-enable.html#securityhub-v2-enable-management-account) workflow. For information about how to update this policy, see [Update a resource-based delegation policy with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs-policy-delegate-update.html) in the *AWS Organizations User Guide*. **Note** After you complete this procedure, the delegated administrator can create a policy allowing it to manage member accounts in your organization. For more information, see [Creating a policy as the delegated administrator to manage member accounts](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-da-policy.html). **To create the delegated administrator policy** 1. Sign in to your AWS account with your organization management account credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **General**. 1. For **Delegated administrator policy**, do one of the following: 1. (Option 1) Choose **Create policy**. Select the box under the policy statement to confirm Security Hub will automatically create a delegation policy granting all required permission to the delegated administrator. 1. (Option 2) Open the policy. Choose **Copy and attach**. In the AWS Organizations console, under **Delegated administrator for AWS Organizations**, choose **Delegate**, and paste the resource policy in the delegation policy editor. Choose **Create Policy**. Open the tab where you are in the Security Hub console, and choose **Configure**. # Managing configuration of member accounts in an AWS Organization The delegated administrator for an AWS Organization can configure security capabilities across member accounts and Regions. There are two types of configurations that are available, **Policies** and **Deployments**. **Policies** generate AWS Organizations policies for accounts and Regions for AWS Security Hub and Amazon Inspector. **Deployments** are a one-time action to enable a security capability across selected accounts and Regions for Amazon GuardDuty and AWS Security Hub CSPM. Unlike policies, you cannot view or edit deployments and deployments will not apply to newly enabled accounts. As an alternative, auto-enable features, for new member accounts, are available in Amazon GuardDuty and AWS Security Hub CSPM. ## Security Hub configuration catalog The configuration catalog of Security Hub offers multiple options to help configure your AWS Organization accounts for the security capabilities provided by . The following are the options available in the Security Hub configuration catalog. ### Security Hub (essential and additional capabilities) This is the recommended configuration to deploy for Security Hub. **Type**: Policy and Deployments **Description**: This configuration tyurns on Security Hub's essential security management, posture management, threat analytics, and vulnerability management capabilities. It optionally enables additional capabilities. ### Threat analytics from GuardDuty **Type**: Deployment **Description**: Turn on selected Amazon GuardDuty capabilities to continuously monitor, analyze, and process AWS data sources and logs in your AWS environment. ### Posture management from AWS Security Hub CSPM) **Type**: Deployment **Description**: This configuration turns on Security Hub CSPM's standards and controls which detects when your AWS accounts and resources deviate from security best practices. ### Vulnerability management from Amazon Inspector **Type**: Policy **Description**: This configuration turns on selected Amazon Inspector capabilities that automatically discover workloads, instances, container images, etc., and scans them for vulnerabilities and network exposure. ## Enabling a configuration with a type of policy The following procedure describes how to create a configuration with a type of policy for your AWS Organization accounts. To create a configuration policy the delegated administrator policy needs to be created in the AWS Organization management account. For information about creating the delegated administrator policy in Security Hub, see [Creating the delegated administrator policy in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-policy-statement.html). **To create a policy that enables and disables member accounts** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home?). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. Choose an item with a type of **policy** or **policy and deployment** from the Configuration catalog. To fully configure Security Hub it is recommended to choose **Security Hub (essential and additional capabilities)**. 1. On the **Configure Security Hub** page in the **Details** section enter a name and a description for the policy. 1. In the **Security capabilities** section do one of the following: 1. (Option 1) Choose **Enable all capabilities**. This will turn on all of the Security Hub essential capabilties, threat analytics, and additional capabilties. 1. (Option 2) Choose **Customize capabilities**. Select the threat analytics and additional capabilities that should be turned on. You cannot deselect any capabilities that are part of the Security Hub essential plan capabilities. 1. In the **Account selection** section, select one of the following options. Choose **All organizational units and accounts** if you want to apply the configuration to all organizational units and accounts. Choose **Specific organizational units and accounts** if you want to apply the configuration to specific organizational units and accounts. If you choose this option, use the search bar or organizational structure tree to specify the organizational units and accounts where the policy will be applied. Choose **No organizational units or accounts** if you do not want to apply the configuration to any organizational unit or account. 1. In the **Regions** section, choose **Enable all Regions**, **Disable all Regions**, or **Specify Regions**. If you choose **Enable all Regions**, you can determine whether to automatically enable new Regions. If you choose **Disable all Regions**, you can determine whether to automatically disable new Regions. If you choose **Specify Regions**, you must choose which Regions you want to enable and disable. 1. (Optional) For **Advanced settings**, please refer to the [guidance](https://docs.aws.amazon.com/organizations/latest/userguide/policy-operators.html) from AWS Organizations. 1. (Optional) For **Resource tags**, add tags as key-value pairs to help you easily identify the configuration. 1. Choose **Next**. 1. Review your changes, and then choose **Apply**. Your target accounts are configured based on the policy. The configuration status of your policy will display at the top of the Policies page. Each capability will provide a status on if it was configured or where there are deployment failures. For any failures click on the link for the failure message to see more details. To view the effective policy at the account level, you can review the **Organization** tab on the **Configurations** page where you can choose an account. ## Enabling a configuration with a type of deployment The following procedure describes how to create a configuration with a type of deployment for your AWS Organization accounts. **To create a deployment that enables and disables member accounts** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home?). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. Choose an item with a type of **deployment **from the Configuration catalog. To fully configure Security Hub it is recommended to choose **Security Hub (essential and additional capabilities)**. 1. In the **Security capabilities** section Select the security capabilities that should be turned on. 1. In the **Account selection** section, select one of the following options. Choose **All organizational units and accounts** if you want to apply the configuration to all organizational units and accounts. Choose **Specific organizational units and accounts** if you want to apply the configuration to specific organizational units and accounts. If you choose this option, use the search bar or organizational structure tree to specify the organizational units and accounts where the policy will be applied. Choose **No organizational units or accounts** if you do not want to apply the configuration to any organizational unit or account. 1. In the **Regions** section, choose **Enable all Regions**, **Disable all Regions**, or **Specify Regions**. If you choose **Enable all Regions**, you can determine whether to automatically enable new Regions. If you choose **Disable all Regions**, you can determine whether to automatically disable new Regions. If you choose **Specify Regions**, you must choose which Regions you want to enable and disable. 1. Choose **Configure**. ## Editing a configuration policy You can edit the capabilities, Regions, and accounts assocaited with configurations that have a type of **policy**. The following describes how to edit a configuration policy in Security Hub **To create edit a configuration policy** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home?). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. In the **Configured policies** tab select the radio button for the policy you want to edit. Choose the **Edit**. 1. To make changes in the **Account selection** section, select one of the following options. Choose **All organizational units and accounts** if you want to apply the configuration to all organizational units and accounts. Choose **Specific organizational units and accounts** if you want to apply the configuration to specific organizational units and accounts. If you choose this option, use the search bar or organizational structure tree to specify the organizational units and accounts where the policy will be applied. Choose **No organizational units or accounts** if you do not want to apply the configuration to any organizational unit or account. 1. To make changes in the **Regions** section, choose **Enable all Regions**, **Disable all Regions**, or **Specify Regions**. If you choose **Enable all Regions**, you can determine whether to automatically enable new Regions. If you choose **Disable all Regions**, you can determine whether to automatically disable new Regions. If you choose **Specify Regions**, you must choose which Regions you want to enable and disable. 1. Choose **Next**. 1. Review your changes, and then choose **Update**. Your target accounts are configured based on the policy. ## Deleting a configuration policy You can delete configuration that you have a type of **policy**. When you delete a policy all attached accounts and organiational units will be removed from the policy. The following describes how to delete a configuration policy in Security Hub. **To create delete a configuration policy** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home?). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. In the **Configured policies** tab select the radio button for the policy you want to edit. Choose the **Delete** button. 1. Type **delete** in the confirmation box. Choose the **Delete**. # Removing the delegated administrator account in Security Hub You can remove the delegated administrator account in the Security Hub console at any time. However, this action not only removes the delegated administrator from Security Hub, but also Security Hub CSPM. We recommend only performing this action when you have confirmed this operation with your security account. **Note** If you're using an account other than the organization management account as the Security Hub CSPM delegated administrator, removing it through either the CSPM Console or AWS Organizations API will also remove it from Security Hub. Similarly, if you remove the Security Hub delegated administrator through either the Security Hub Console or AWS Organizations API, it will also be removed from Security Hub CSPM. When the delegated administrator is removed from CSPM, Central Configuration will automatically opt out. **To remove the delegated administrator account** 1. Sign in to your AWS account with your organization management account credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home?). 1. From the navigation pane, choose **General**. 1. In **Delegated administrator**, choose **Remove delegated administrator**. In the pop-up window, enter *remove*, and choose **Remove**. # Re-enabling Security Hub Before re-enabling Security Hub on accounts that were previously disabled using a Security Hub policy, you must first detach the disable policy. If you attempt to re-enable Security Hub while a disable policy is still attached to the account or organizational unit, the disable policy will override the enablement and Security Hub will remain disabled. **To remove the Security Hub disable policy for an organization or an account.** 1. Sign in using your AWS account with your organization management account credentials. Open the Security Hub console at [https://console.aws.amazon.com/organizations/v2/home](https://console.aws.amazon.com/organizations/v2/home). 1. From the navigation panel choose **AWS accounts**. 1. If the current Security Hub disable policy was for your entire organization choose **Root** under the **Organizational stucture**. If the current Security Hub disable policy is for specific accounts, choose the specific account under the **Organizational stucture** and then follow the remaining steps for each account. 1. In the **Policies** tab find the section titled **Security Hub policies** 1. Choose the radio button next to the policy that disables Security Hub. Choose **Detatch**. Once the policy has been attached from your organization or accounts you can then re-enable Security Hub. See [Managing configuration of member accounts in an AWS Organization](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-da-policy.html) for details on re-enabling Security Hub. # Security Hub recommendations The following security services in AWS send findings to Security Hub in the OCSF format. After you enable Security Hub, we recommend enabling these AWS services for additional security. **Security Hub CSPM** When you [enable Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html), you get a comprehensive view of your security state in AWS. This helps you assess your environment against security industry standards and best practices. Although you can get started with Security Hub without enabling Security Hub CSPM, we recommend enabling Security Hub CSPM because Security Hub correlates security signals from Security Hub CSPM to improve your posture management. If you [enable Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html), we also recommend [enabling the AWS Foundational Security Best Practices standard](https://docs.aws.amazon.com/securityhub/latest/userguide/enable-standards.html) for your account. This standard consists of a set of controls that detect when your AWS accounts and resources deviate from security best practices. When you enable the AWS Foundational Security Best Practices standard for your account, AWS Security Hub CSPM automatically enables all of its controls, including controls for the following resource types: + Account controls + Amazon DynamoDB controls + Amazon Elastic Compute Cloud controls + AWS Identity and Access Management (IAM) controls + AWS Lambda controls + Amazon Relational Database Service (Amazon RDS) controls + Amazon Simple Storage Service controls You can disable any of the controls in this list. However, if you disable any of these controls, you cannot receive exposure findings for supported resources. For information about controls that apply to the AWS Foundational Security Best Practices standard, see [AWS Foundational Security Best Practices v1.0.0 (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html). **GuardDuty** When you [enable GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html), you can view all of your threats and security coverage findings in the dashboard of the Security Hub console. If you enable GuardDuty, GuardDuty automatically begins sending data to Security Hub in the OCSF format. **Amazon Inspector** When you [enable Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/getting_started_tutorial.html), you can view all of your exposures and security coverage findings in the dashboard of the Security Hub console. If you enable Amazon Inspector, Amazon Inspector automatically begins sending data to Security Hub in the OCSF format. We recommend activating Amazon EC2 scanning and Lambda standard scanning. When you activate Amazon EC2 scanning, Amazon Inspector scans Amazon EC2 instances in your account for package vulnerabilities and network reachability issues. When you activate Lambda standard scanning, Amazon Inspector scans Lambda functions for software vulnerabilities in package dependencies. For more information, see [Activating a scan type](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html) in the *Amazon Inspector User Guide*. **Macie** When you [enable Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html), you can detect additional exposures for your Amazon S3 buckets. We recommend configuring [automated sensitive data discovery](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-enable.html), so Macie can evaluate your Amazon S3 bucket inventory on a daily basis. # Account coverage in Security Hub Security Hub allows you to enable multiple capabilities across Regions and organization accounts through policies and configurations. Some of these capabilities are from services outside of Security Hub, including Amazon Inspector, Amazon GuardDuty, AWS Security Hub CSPM, and Amazon Macie. You can use the **Account coverage** page to track which accounts and Regions are covered by these capabilities. ## Account coverage page The account coverage page provides visibility into security capability enablement across your AWS accounts. This view helps you identify gaps in your security coverage and track capability adoption across your organization. **To access the Security Hub **Account coverage** page** 1. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Settings** choose **Account coverage**. ### Overview section The **Overview** section displays aggregated security coverage metrics across all monitored accounts. This high-level visualization shows the percentage of accounts with each security capability enabled, offering a comprehensive view of your security posture. You can select each percentage of covered capability to filter the coverage finding results to display findings related to coverage for that capability. The percentages in the Overview section are determined using the following calculation: `(Count of number of accounts and regions the capability is enabled in)`/`((Total number of accounts Security Hub is enabled in)`\$1`(Number of regions the capability is available in))` ### Accounts tab The **Accounts** tab enables account-specific coverage analysis through filtering by account functionality. Each security capability displays a coverage percentage that, when selected, reveals a detailed breakdown of individual features and their coverage percentage within that capability. When you select these percentages, the system filters the coverage finding results to display those that indicate the coverage for that capability and for the account in that row. The percentages in the Accounts tab are determined using the following calculation: `(Count of number of regions the capability is enabled in)`/`(Number of regions the capability is available in)` There are several cases where the coverage percentage might show as 0%: + Security Hub is not enabled in the account and therefore no coverage findings are being ingested. + Security Hub is waiting for coverage findings to be generated. ### Coverage findings tab The **Coverage findings** tab displays informational findings generated when security capability checks detect disabled features in an account. These findings help identify areas where security coverage can be enhanced. Each coverage finding provides information on the title of the coverage finding, the account and region of the finding, and the current status of the finding. Each finding also has a configure link that takes you to the individual service where the configuration for that capability can to be managed, or to the Security Hub configurations page where you can update your current configurations for security services. For more information about coverage findings, see [Coverage findings in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/coverage-findings.html). ## Security coverage widget Account coverage can also be viewed via the **Security coverage widget** in the Security Hub summary dashboard. More details about the widget can be found at [Security coverage widget](https://docs.aws.amazon.com/securityhub/latest/userguide/dashboard-v2.html#security-hub-v2-dashboard-coverage-widget) documentation. # Security Hub Extended plan Security Hub Extended plan helps protect your entire enterprise estate across cloud, endpoint, network, identity, data, email, and browser with an integrated security operations experience centered in AWS Security Hub. With the Security Hub Extended plan, you can select partner solutions that address your security needs and sign up for flexible pay-as-you-go pricing with no upfront investments or long-term commitments required. You can add or remove partner solutions as your business needs evolve. The Security Hub Extended plan is available to all customers who have enabled the Security Hub Essentials plan. Charges for Security Hub Extended plan appear on your monthly AWS bill with AWS as the seller of record. Security Hub Extended plan pricing for all solutions is available on the Extended plan tab of the [Security Hub pricing details page](https://aws.amazon.com/security-hub/pricing/#pricing_details). ## Permissions for the Security Hub Extended plan To subscribe to a partner product from the Security Hub Extended plan, you need the following permissions, in addition to your Security Hub permissions: + `aws-marketplace:ViewSubscriptions` + `aws-marketplace:Subscribe` To unsubscribe to a partner product from the Security Hub Extended plan, you need the following permissions, in addition to your Security Hub permissions: + `license-manager:ListReceivedLicenses` + `aws-marketplace:ListAgreementCharges` + `aws-marketplace:Unsubscribe` For more information on AWS Marketplace permissions, see [Controlling access to AWS Marketplace subscriptions](https://docs.aws.amazon.com/marketplace/latest/buyerguide/buyer-iam-users-groups-policies.html) in the *AWS Marketplace Buyer Guide*. ## Reviewing and signing up for Extended plan partners The Security Hub Extended plan is accessible through the Security Hub delegated administrator account or standalone accounts. On the Security Hub Extended plan page, you can view details about each partner, initiate a subscription to a partner solution, and begin the onboarding process to each partner's solution through the partner's onboarding page. **To access the Security Hub Extended plan and sign up for a partner's product** 1. Sign in to the AWS Management Console using your delegated administrator or standalone account credentials. 1. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. In the navigation pane, choose **Management**, and then choose **Extended plan**. 1. For each partner solution that you want to sign up for, choose **View product**. 1. Review the product pricing details, and then choose **Subscribe** when you're ready to start the process of onboarding to the partner product. 1. After the subscription process completes, choose **Set up your account** to be redirected to the partner's sign-up page. 1. Provide the necessary information for the partner sign-up page, and follow the next steps, provided by the partner, for completing the onboarding steps. **Important** You aren't billed for the partner solution until you complete the onboarding process for the partner product. ## Unsubscribing from an Extended plan partner If you no longer want to use an Extended plan partner solution, you can unsubscribe from the partner listing. To unsubscribe from a partner solution, follow the guidance at [Canceling your SaaS subscription](https://docs.aws.amazon.com/marketplace/latest/buyerguide/cancel-subscription.html#cancel-saas-subscription) in the *AWS Marketplace Buyer Guide*. **Important** In addition to canceling your subscription, follow any additional offboarding steps that are required for the partner solution, based on how you configured the solution for your company. # Understanding cross-Region aggregation in Security Hub Cross-Region aggregation allows you to aggregate findings, resources, and trends from multiple AWS Regions into a single home Region. You can then manage all this data from the home Region. Suppose you set US East (N. Virginia) as the home Region, and US West (Oregon) and US West (N. California) as the linked Regions. When you view the Findings page in US East (N. Virginia), you see the findings from all three Regions. Updates to those findings are also reflected in all three Regions. ## Types of data that are aggregated When cross-Region aggregation is enabled with one or more linked Regions, Security Hub replicates the following data from the linked Regions to the home Region. This occurs in every account that has cross-Region aggregation enabled. + Findings + Resources + Trends In addition to new data in the previous list, Security Hub also replicates updates to this data between the linked Regions and the home Region. Updates that occur in a linked Region are replicated to the home Region. Updates that occur in the home Region are replicated back to the linked Region. If there are conflicting updates in the home Region and the linked Region, then the most recent update is used. Any findings that existed in a region at the time that it becomes a linked region will not be replicated to the home Region unless there is an update to the finding. Once a Region is linked to a home Region there will be a difference in findings between the home Region and the linked Region until findings in the linked Region are updated or they age out. Any resources that existed in a region at the time that it becomes a linked region will be replicated to the home Region, typically within 24-48 hours after the Region becomes linked to a home Region. When removing a linked region, any findings or resources for that region will remain in the home region until the finding or resource ages out. Trends data is based on findings and resources that are present within the region that the trend is for. Trends data in a home Region will reflect the current state of findings and resources that have been synched to the home Region. ![\[When cross-Region aggregation is enabled, Security Hub CSPM replicates new and updated findings between the linked Regions and home Region.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/security-hub-region-aggregation-diagram.png) Cross-Region aggregation does not add to the cost of Security Hub. You are not charged when Security Hub replicates new data or updates. In the home Region, the Summary page provides a view of your active findings and resources across linked Regions. Security Hub only aggregates data from Regions where an account has Security Hub enabled. Security Hub is not automatically enabled for an account based on the cross-Region aggregation configuration. It's possible to have cross-Region aggregation enabled without any linked Regions selected. In this case, no data replication occurs. ## Aggregation for administrator and member accounts Standalone accounts and administrator accounts can configure cross-Region aggregation. If configured by an administrator, the presence of the administrator account is essential for cross-Region aggregation to work in administered accounts. If the administrator account is removed or disassociated from a member account, cross-Region aggregation for the member account will either stop, or if the member account had a cross-Region aggregation configuration before being associated with an administrator, that aggregation configuration will again be in effect for the account. When an administrator account enables cross-Region aggregation, Security Hub replicates the data that the administrator account generates in all linked Regions to the home Region. In addition, Security Hub identifies the member accounts that are associated with that administrator, and each member account inherits the cross-Region aggregation settings of the administrator. Security Hub replicates the data that a member account generates in all linked Regions to the home Region. The administrator can access and manage security findings from all member accounts within the administered regions. Additionally, the administrator can view resource inventory from all member accounts within the administered regions. As a Security Hub member account, you must be signed in to the home Region to view aggregated data from your account from all linked Regions. Member accounts don't have permissions to view data from other member accounts and are not permitted to call the `CreateAggregatorV2`, `DeleteAggregatorV2`, and `GetAggregatorV2` APIs. ## Automation rules and cross-Region aggregation When cross-Region aggregation is enabled automation rules can only be created in the defined home region. Any rule that you define applies to all linked regions unless your rule criteria applies to specific regions. You must create separate automation rules for any region that is not a linked region. Any rules that were created in the home Region, prior to enabling cross-Region aggregation, automatically become applicable in linked Regions. Rules previously created in linked Regions will no longer apply once an aggregator is created. Rules defined in linked Regions will resume applying once the aggregator is deleted or the region is no longer linked. # Enabling cross-Region aggregation You must enable cross-Region aggregation from the AWS Region that you want to designate as the home Region. To enable cross-Region aggregation, you create a Security Hub resource called a finding aggregator. The finding aggregator resource specifies your home Region and linked Regions (if any). You can't use an AWS Region that is disabled by default as your home Region. For a list of Regions that are disabled by default, see Enabling a Region in the AWS General Reference. When you enable cross-Region aggregation, you choose to specify one or more linked Regions if you wish. Enabling cross-Region aggregation does not enable Security Hub in that region. To enable Security Hub in a region refer to Creating a policy as the delegated administrator to manage member accounts in the Security Hub user guide. **To enable cross-Region aggregation (console)** 1. From the administrator account or in a standalone account open the AWS Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home) 1. Using the AWS Region selector, sign in to the Region that you want to use as the aggregation Region. 1. In the Security Hub navigation menu, choose **Settings** and then **General**. 1. In the Cross-Region aggregation section choose **Configure**. 1. By default, the home Region is set to **No aggregation Region**. 1. Under **Home Region**, select the option to designate the current Region as the home Region. 1. Optionally, for **Linked Regions**, select the Regions to aggregate data from. 1. Choose **Save**. # Reviewing cross-Region aggregation settings You can view the current cross-Region aggregation configuration in AWS Security Hub from any AWS Region in the administrator account or in a standalone account. Member accounts cannot view cross-Region aggregation configuration. The configuration includes the home Region, and the linked Regions (if any). Follow the steps to view your current cross-Region aggregation settings **To view cross-Region aggregation settings (console)** 1. Open the AWS Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. On the navigation pane, choose **Settings** and then the **General**. 1. If cross-Region aggregation is not enabled, then the General page displays the option to enable cross-Region aggregation. Only administrator accounts and standalone accounts can enable cross-Region aggregation. 1. If cross-Region aggregation is enabled, then the Regions tab displays the following information: + The home Region + Whether to automatically aggregate findings, resources, and trends from new Regions that Security Hub supports and that you opt into + The list of linked Regions (if any are selected) # Updating cross-Region aggregation settings You can update your current cross-Region aggregation settings in AWS Security Hub by changing the linked Regions or the current home Region. Changes to cross-Region aggregation aren't implemented for an opt-in Region until you enable the Region in your AWS account. Regions that AWS introduced on or after to March 20, 2019 are opt-in Regions. When you stop aggregating data from a linked Region, AWS Security Hub doesn't remove any existing aggregated data from that Region that is accessible in the home Region. You can't use the update procedures in this section to change the home Region. To change the home Region, you must do the following: 1. Delete the current cross-Region aggregation configuration. For instructions, see [Deleting cross-Region aggregation](sh-finding-aggregation-delete.md). 1. Change to the Region that you want to be the new home Region. 1. Enable cross-Region aggregation. For instructions, see [Deleting cross-Region aggregation](sh-finding-aggregation-delete.md). You must update the cross-Region aggregation configuration from the current home Region. **To change the linked Regions (console)** 1. From the administrator account or in a standalone account open the AWS Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. Sign in to the current aggregation Region. 1. In the Security Hub navigation menu, choose **Settings**, then choose **General**. 1. For Cross-Region aggregation, choose **Edit**. 1. For **Linked Regions**, update the selected linked Regions. 1. Choose **Save**. # Deleting cross-Region aggregation If you don't want AWS Security Hub to aggregate data, you can delete your finding aggregator. Alternatively, you can keep your finding aggregator but not link any AWS Regions to the home Region by updating the existing aggregator to have no linked regions selected. To change your home Region, you must delete your current finding aggregator and create a new one. When you delete your finding aggregator, Security Hub stops aggregating data. It doesn't remove any existing aggregated data from the home Region. **Deleting the finding aggregator (console)** You can delete your finding aggregator from the current home Region only. In Regions other than the home Region, the Finding aggregation panel on the Security Hub console displays a message that you must edit the configuration in the home Region. Choose this message to display a link to switch to the home Region. **To stop cross-Region aggregation (console)** 1. Open the AWS Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. Ensure that you're signed in to your current home Region. 1. In the Security Hub navigation menu, choose **Settings**, then choose **General**. 1. Under Cross-Region aggregation, choose **Edit**. 1. Under **Aggregation Region**, choose **No aggregation Region**. 1. Choose **Save**. 1. On the confirmation dialog, in the confirmation field, type **Confirm**. 1. Choose **Confirm**. # Working in the summary dashboard in Security Hub The **Summary** dashboard in the Security Hub console displays an overview of your exposures, threats, resources, and security coverage across security widgets. You can customize the dashboard by adding and removing widgets and by creating and applying filter sets to retrieve data in each widget. ## Considerations Consider the following before interacting with the dashboard: + Customizations like saved filter sets or changes to the layout of widgets are saved automatically. + Data automatically refreshes every time you open the dashboard. + If you configure cross-Region aggregation, the dashboard includes findings from all of your linked regions (when viewing the dashboard in your home region). Consider the following if your account is a delegated administrator account for an organization, member account in an organization, or standalone account. + Customizations made by a delegated administrator account will be saved independently from customizations made by member accounts. Customizations might include saved filter sets or changes to the layout of widgets. + If your account is the delegated administrator account for an organization, data includes findings for your account and member accounts. + If your account is a member account in an organization or a standalone account, data includes findings only for your account. As a best practice, we recommend not including confidential, sensitive, or personally identifiable information (PII) in saved filter sets, custom widgets, or other related free-form text fields. ## Available widgets You can interact with different widgets in the **Executive** and **Triage** tabs of the **Summary** dashboard. The **Executive** tab includes widgets that display trends data for your exposures, threats, and resources and the **Security Coverage** widget to help track your account coverage across different security capabilities. The **Triage** tab includes widgets that display a summary of your exposures, threats, and resources. However, you can add widgets, remove widgets, and manage the position of each widget in both tabs to customize your experience. ### Trends widgets The following widgets display trends data for your exposures, threats, and resources, so you can analyze them over time. #### Trends overview widget ![\[Example of trends overview widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/trends-overview-widget.png) This widget displays an overview of your exposures, threats, resources, and findings in the following time periods: + **Month-over-month** reflects the period-over-period count for the last two months. + **Week-over-week** reflects the period-over-period count for the past two weeks. + **Day-over-day** reflects the period-over-period count for the past 2 days. The number next to the percentage reflects the average period-over-period count to date. Choosing this number directs you to its corresponding dashboard in the console. If you navigate to another dashboard that displays trends data, the dashboard only displays trends data for the last 90 days or in a best-fit time period if your account does not contain findings or resources older than 30 days. **Note** To receive data in this widget, you must enable the following security services: **AWS Security Hub CSPM** – To receive data about exposures **Amazon Inspector** – To receive data about exposures **GuardDuty** – To receive data about threats #### Exposure finding trends widget ![\[Example of exposure finding trends widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/exposure-finding-trends-widget.png) This widget displays the severity of your exposure findings in the following time periods: + **5 days** + **30 days** + **90 days** + **6 months** + **1 year** The visualization displays the average count of your findings over the selected time period. **Severity filters** You can update the graph by including or excluding the following severity filters: + **Fatal** + **Critical** + **High** + **Medium** + **Low** + **Informational** + **Other** + **Unknown** Applied severity filters show at the bottom of the visualization in different boxes. You can hover over the visualization to review the average count of findings for specific points in time. You can also review the average count of findings that match each applied severity filter. You can choose **View all current exposure findings** to be directed to the **Exposure** dashboard. By default, the **Exposure** dashboard only displays trends data for the last 90 days. If your account does not contain exposure findings older than 30 days, the dashboard displays trends data based on a best-fit time period. **Note** To receive data in this widget, you must enable [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/getting_started.html) and [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html). #### Threat finding trends widget ![\[Example of threat finding trends widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/threat-finding-trends-widget.png) This widget displays the severity of your threat findings in the following time periods: + **5 days** + **30 days** + **90 days** + **6 months** + **1 year** The visualization displays the average count of your findings over the selected time period. **Severity filters** You can update the graph by including or excluding the following severity filters: + **Fatal** + **Critical** + **High** + **Medium** + **Low** + **Informational** + **Other** + **Unknown** Applied severity filters show at the bottom of the visualization in different boxes. You can hover over the visualization to review the average count of findings for specific points in time. You can also review the average count of findings that match each applied severity filter. You can choose **View all current threat findings** to be directed to the **Exposure** dashboard. By default, the **Threats** dashboard only displays trends data for the last 90 days. If your account does not contain threat findings older than 30 days, the dashboard displays trends data based on a best-fit time period. **Note** To receive data in this widget, you must enable [GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html). #### Resource trends widget ![\[Example of resource trends widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/resource-trends-widget.png) This widget displays an inventory of your resources in the following time periods: + **5 days** + **30 days** + **90 days** + **6 months** + **1 year** The visualization displays the average count of your resources over the selected time period. You can hover over the visualization to review the average count of resources for specific points in time. You can choose **View current resources** to be directed to the **Resources** dashboard. By default, the **Resources** dashboard only displays trends data for the last 90 days. If your account does not contain resources older than 30 days, the dashboard displays trends data based on a best-fit time period. This widget displays an inventory of your resources in the following time periods: + **5 days** + **30 days** + **90 days** + **6 months** + **1 year** #### Data retention for trends Security Hub retains trends data for one year for all AWS accounts where Security Hub is enabled. After trends data has been retained for one year, it is deleted from Security Hub. Trends data for delegated administrator and standalone accounts is deleted after Security Hub is disabled, or if the accounts are terminated. Trends data retention secnarios for member accounts with Security Hub enabled: + If a member account leaves its organization, Security Hub will still store the trends data, up to when the account left the organization, for a year. + If Security Hub is disabled for a member account, the trends data, up to when the account was disabled, will be retained for a year. + If a member account is terminated, the trends data will be disassociated from the terminated account (e.g., the terminated accountID will be scrubbed) and the rest of the trends data will be retained for one year. ### Summary widgets The following widgets display a summary of your exposures, threats, and resources. #### Exposure summary widget ![\[Example of exposure summary coverage widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/exposure-summary-widget-operations.png) This widget displays your exposures by severity. An exposure is based on an analysis of findings and traits from Security Hub and other AWS security services, such as Amazon Inspector. The list of exposures in this widget is limited to the eight exposures with the highest severity. Exposures with greater severity appear first in the list. If two or more exposures are of equal severity, the list automatically groups those exposures behind more recent exposures. Choosing **View all exposures** directs you to the **Exposure** dashboard. **Note** To receive data in this widget, you must enable [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/getting_started.html) and [Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html). #### Threat summary widget ![\[Example of threat summary widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/threat-summary-widget-operations.png) This widget displays your threats by severity. A threat refers to malicious activity or suspicious activity that can compromise the security of your environment. The list of threats in this widget is limited to the eight threats with the highest severity. Threats with greater severity appear first in the list. If two or more threats are of equal severity, the list automatically groups those threats behind more recent threats. Choosing **View all threats** directs you to the **Threats** dashboard. **Note** To receive data in this widget, you must [enable GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html). #### Resource summary widget ![\[Example of resource summary widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/resource-summary-widget-operations.png) This widget displays resources by type and findings associated with resources. Resources are prioritized by exposures and attack sequences. Choosing **View all resources** directs you to the **Resource** dashboard. #### Security coverage widget ![\[Example of security coverage widget.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/security-coverage-widget.png) The widget displays a summary of your account coverage for the following security capabilities: + Vulnerability management by Amazon Inspector + Threat detection by Amazon GuardDuty + Sensitive data discovery by Amazon Macie + Posture management by AWS Security Hub CSPM Percentages in the **Account coverage** column represent the number of coverage checks that passed and failed for each security capability across AWS accounts and AWS Regions where Security Hub is enabled. You can review which coverage checks passed and failed for a security capability by choosing a percentage. **Covered** indicates the coverage check passed. **Not covered** indicates the coverage check failed. When reviewing percentages for the number of coverage checks that passed and failed, each percentage under **Covered** represents the percentage of coverage findings covered for a security capability. In some cases, percentages for coverage checks are rounded to the nearest whole number. **Suppressed coverage findings** If any of your coverage findings in Security Hub are suppressed, the widget displays a message informing you that coverage has been excluded: *Coverage for security capabilities has been excluded through suppressed coverage findings.* For more information about coverage findings, see [Coverage findings in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/coverage-findings.html). ## Available filters You can apply filters to security widgets using the **Add filter bar**. ![\[Example of summary filters.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/summary-filters.png) Filters are organized in the following categories: + **Shared filters** – applies to all security widgets + **Finding filters** – applies to security widgets that display finding data + **Resource filters** – applies to security widgets that display resource data You can create a filter set by connecting filters using the **and**/**or** operators and then choosing **Save new filter set** in the dropdown. ### Filters applied to the Exposure finding trends widget and Threat finding trends widget Currently, the filters supported for these widgets include the following: + **Account ID** + **Finding class name** + **Finding type** + **Product name** + **Region** + **Status** ### Filters applied to the Resource trends widget Currently, the filters supported for this widget include the following: + **Account ID** + **Region** + **Resource category** + **Resource type** ### Filters not applied to widgets ![\[Example of summary filter that cannot be applied.\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/filter-not-applied.png) If a widget does not support a filter, the filter is not applied to the widget. In this case, the widget displays a warning message letting you know how many filters were not applied and lists the names of which filters it does not support. # Viewing details about resources in Security Hub The **Resources** page tracks common resources across your account and organization. You can access the **Resources** page in the Security Hub console by choosing **Resources** in the navigation pane. The benefit of the **Resources** page is that it helps you monitor your security posture, organize your resources, and review details about your resources. When you choose a resource type, you can review all of the resources associated with the resource type. You can review any findings associated with a resource. The resource types available in the **Resources** page include any resources in your accounts covered by AWS security services contributing findings to Security Hub. **Note** The delegated administrator can view all resources associated with member accounts. If you configured a home AWS Region, you can view all of your resources in your home AWS Region from linked AWS Regions. If you choose a resource, you can review details for that resource. These details include the resource name, ID, ARN, type, and category. You can review the account ID associated with the resource, when the resource was created (timestamp), and where the resource was created (AWS Region). You also can review additional configuration details about the resource. These details can be found in a JSON snippet that you can copy. If you switch from the **Overview** tab to the **Findings** tab, you can review any findings associated with the resource. The **Findings** tab shows the name of each finding, type of each finding, and severity of each finding. You can group findings by different fields and search for findings using filters. If you choose a finding, you can review an overview of the finding, which includes information about compliance and how to remediate issues associated with the finding. The **Traits** tab shows each trait that has been identified about the resource. You can view contributing traits that were used to create an exposure finding for the resource. You can also see contextual traits, which are other security items identified for the resource but did not directly contribute to any exposure findings. If you go back to the resource, you can choose **Open resource** to review the resource in the console for its resource type. For example, if the resource is an IAM resource, you can open the resource in the IAM console. The resources page provides you with different ways to organize and search for resources. You can group resources by type. For example, you can group resources by account ID, finding type, AWS Region, resource category, resource name, and resource type. Quick filters help you review resources by category, accounts, and finding types. # Security Hub and the Open Cybersecurity Findings Format (OCSF) ## OCSF overview Security Hub findings are formatted using OCSF which is an open-source project, delivering an extensible framework for developing schemas, along with a vendor-agnostic core security schema. Vendors and other data producers can adopt and extend the schema for their specific domains. Data producers can map differing schemas to help security teams simplify data ingestion and normalization, so that data scientists and analysts can work with a common language for threat detection and investigation. The goal is to provide an open standard, adopted in any environment, application, or solution, while complementing existing security standards and processes. The framework is made up of a set of data types, an attribute dictionary, and the taxonomy. It is not restricted to the cybersecurity domain nor to events, however the initial focus of the framework has been a schema for cybersecurity events. OCSF is agnostic to storage format, data collection and Extract-Transform-Load (ETL) processes. The core schema for cybersecurity events is intended to be agnostic to implementations. The schema framework definition files and the resulting normative schema are written as JSON. Security Hub currently supports findings in OCSF schema version 1.6. ## Related Resources For more information about OCSF and its implementation, see the following resources: + [Public OCSF Documentation](https://schema.ocsf.io/) + [OCSF Extension Usage Documentation](https://schema.ocsf.io/1.0.0/extensions/) + [OCSF Core Schema Reference](https://schema.ocsf.io/1.0.0/) + [OCSF Extensions Registry](https://github.com/ocsf/ocsf-schema/tree/main/extensions) # AWS extension for OCSF OCSF [schemas](https://schema.ocsf.io/) can be extended by adding new attributes, objects, categories, profiles and event classes. A schema is the aggregation of core schema entities and extensions. Extensions to OCSF allow a particular vendor or customer to augment an existing schema by adding attributes to provide domain-specific customization, improve data interoperability, and add more detailed context for security analysis. The AWS Extension for Open Cybersecurity Schema Framework (OCSF) provides attribute definitions for cloud resources within OCSF events. This extension introduces a new `cloud_resources` profile that extends the standard OCSF `resource_details` object with comprehensive cloud-specific resource attributes, enabling security teams to gain deeper insights into resource configurations, potential vulnerabilities, and critical metadata essential for effective threat detection and investigation across cloud environments. ## Extended `resource_details` object The AWS Extension extends the `resource_details` object with attributes mentioned in the list of attribute references below. These attributes ensure proper identification and classification of cloud resources across different providers within standardized event frameworks. ## AWS Extension for OCSF attribute reference The [Basic attributes](https://docs.aws.amazon.com/securityhub/latest/userguide/aws-extension-basic-attributes.html) and [Resource specific objects](https://docs.aws.amazon.com/securityhub/latest/userguide/aws-extension-resource-specific-objects.html) sections provide examples of each of the attributes that are part of the AWS OCSF extension to resource\$1details. Each of the attribute definitions contains an OCSF status outlining its current relationship to the public OCSF schema: + **Existing**: This attribute was already in standard OCSF resource\$1details and is now part of the AWS extension. + **New**: The attribute is not part of OCSF and was introduced as part of the AWS extension. It does not exist in the core OCSF schema. + **Added to resource\$1details**: The attribute is defined in OCSF but not part of resource\$1details. # Basic attributes These are fundamental attributes used for resource identification, location, and basic metadata. They consist of simple data types such as strings, timestamps, and arrays. ## Cloud Partition The cloud partition where the resource exists. **Requirement** Recommended **Type** String **OCSF status** Existing **Example** ``` { "resources": [ { "cloud_partition": "aws" } ] } ``` ## Owner account ID A 12-digit account identifier that the resource belongs to. **Requirement** Recommended **Type** String **OCSF status** Existing **Example** ``` { "resources": [ { "owner": { "account": { "uid": "123456789012" } } } ] } ``` ## Resource Type The AWS CloudFormation resource type that identifies the specific service and resource. **Requirement** Required **Type** String **Format** Must follow AWS CloudFormation resource type naming convention: `AWS::::` **OCSF status** Existing **Example** ``` { "resources": [ { "type": "AWS::EC2::Instance" } ] } ``` ## Resource identifier The unique identifier for the cloud resource (e.g. i-1234567890abcdef0). **Requirement** Recommended **Type** String **Format** Must be a valid resource identifier. Minimum length of 1. Maximum length of 768. **OCSF status** Existing **Example** ``` { "resources": [ { "uid": "i-1234567890abcdef0" } ] } ``` ## Alternate Resource Identifier The unique identifier for the cloud resource, typically the Amazon Resource Name (ARN). **Requirement** Recommended **Type** String **Format** Should be a valid AWS ARN. Common patterns include: + `"arn:partition:service:region:account-id:resource-id"` + `"arn:partition:service:region:account-id:resource-type/resource-id"` + `"arn:partition:service:region:account-id:resource-type:resource-id"` Note: Some services like S3 use variations such as arn:aws:s3:::bucket-name (without region or account-id). **OCSF status** Existing **Examples** ``` { "resources": [ { "uid_alt": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0" } ] } ``` ``` "{ "resources": [ { "uid_alt": "arn:aws:s3:::my-bucket-name" } ] }" ``` ## Resource Name The unique name for the cloud resource. **Requirement** Recommended **Type** String **Format** User-created names whose values will depend on the environment. **OCSF status** Existing **Example** ``` { "resources": [ { "name": "My-Server-1" } ] } ``` ## Cloud Region The AWS region where the resource is located. **Requirement** Recommended **Type** String **Format** Valid cloud region identifier (e.g., us-east-1, eu-west-1, ap-southeast-2) **OCSF status** Existing **Example** ``` { "resources": [ { "region": "us-west-2" } ] } ``` ## Resource Creation Time The time when the resource was created. **Requirement** Recommended **Type** Timestamp **Format** Unix timestamp in milliseconds since epoch (January 1, 1970, 00:00:00 UTC) **OCSF status** Existing **Example** ``` { "resources": [ { "created_time": 1762019193000 } ] } ``` ## Tags Key-value pairs for resource metadata and organization. **Requirement** Recommended **Type** Array of key:value objects **Format** A generic object allowing to define a key:value pair. **OCSF status** Existing **Example** ``` { "resources": [ { "tags": [ { "name": "Environment", "value": "Production" }, { "name": "Owner", "value": "SecurityTeam" } ] } ] } ``` ## IP Address The IP address associated with the instance in either IPv4 or IPv6 format. **Requirement** Optional **Type** String **Format** Valid IPv4 or IPv6 address **OCSF status** Existing **Example** ``` { "resources": [ { "ip": "10.0.1.25" } ] } ``` ## IP Addresses An array of IP addresses (IPv4 or IPv6) associated with the device. These may include both public and private IP addresses. **Requirement** Optional **Type** Array of IP addresses **OCSF status** New **Example** ``` { "resources": [ { "ip_addresses": ["10.0.1.25", "52.12.34.56"] } ] } ``` ## VPC UID The VPC ID where the resource is located. **Requirement** Optional **Type** String **Format** VPC identifier (e.g. vpc-12345678900) **OCSF status** Added to `resource_details` **Example** ``` { "resources": [ { "vpc_uid": "vpc-0a1b2c3d4e5f6g7h8" } ] } ``` ## Example resource object with basic attributes ``` { "resources": [ { "cloud_partition": "aws", "owner": { "account": { "uid": "123456789012" } }, "region": "us-east-1", "type": "AWS::EC2::NetworkInterface", "uid": "eni-03e6c892dd45e836c", "uid_alt": "arn:aws:ec2:us-east-1:123456789012:network-interface/eni-03e6c892dd45e836c", "zone": "us-east-1f", "vpc_uid": "vpc-0ef6045717b0362f6" } ] } ``` # Resource specific objects These are complex nested objects that provide detailed information for specific resource types and services. Each object contains multiple fields and sub-objects with service-specific configuration and metadata. ## Device Enhanced cloud instance attributes for compute resources including encryption details, image information, instance profile, and launch time. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [Device](https://schema.ocsf.io/1.6.0/objects/device) object definition. AWS Extension adds the following attributes to this object: + `encryption_details` - The encryption details of resource + `image` - Image information + `instance_profile` - The IAM instance profile to associate with the instance + `launch_time` - The time the instance was launched + `uid_alt` - Amazon Resource Name (ARN) of the resource **Example** ``` { "device": { "image": { "uid": "ami-99999999", "name": "LoadTestAMI-Current" }, "instance_profile": { "uid": "LoadTestingInstanceProfileId", "uid_alt": "arn:aws:iam::012345678999:instance-profile/generated" }, "launch_time": 1762019193000, "launch_time_dt": "2025-08-02T02:05:06Z", "model": "m3.xlarge", "network_interfaces": [ { "ip": "198.51.100.0", "security_groups": [ { "name": "LoadTestingSecurityGroupName", "uid": "LoadTestingSecurityId" } ], "uid": "eni-abcdef12" } ], "type": "Virtual", "type_id": 6, "uid": "i-99999999" } } ``` ## Network Interface Network interface details and configuration including attachments and security groups. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [Network Interface](https://schema.ocsf.io/1.6.0/objects/network_interface) object definition. AWS Extension adds the following attributes to this object: + `attachments` - Information about the network interface attachments + `security_groups` - Array of security group unique identifiers + `uid_alt` - Amazon Resource Name (ARN) of the resource **Example** ``` { "network_interface": { "uid": "eni-0a1b2c3d4e5f6g7h8", "uid_alt": "arn:aws:ec2:us-east-1:123456789012:network-interface/eni-0a1b2c3d4e5f6g7h8", "name": "prod-web-server-eni", "attachments": [ { "uid": "eni-attach-0abcd1234efgh5678", "instance_uid": "i-0123456789abcdef0", "name": "/dev/eth0", "state": "attached", "attach_time": 1762019193000 } ], "security_groups": [ { "uid": "sg-0a1b2c3d4e5f6g7h8", "name": "web-server-sg" }, { "uid": "sg-9i8h7g6f5e4d3c2b1", "name": "ssh-access-sg" } ] } } ``` ## Storage Device Storage device details including attachments, encryption, and snapshot information. **Requirement** Optional **Type** Object **OCSF status** New The storage device object includes the following attributes: + `name` - The name of the storage device + `uid` - The unique identifier of the storage devices + `attachments` - The storage device attachments + `encryption_details` - The storage device encryption key + `is_encrypted` - Whether the storage device is encrypted (required) + `snapshot_id` - The storage device snapshot identifier + `uid_alt` - Amazon Resource Name (ARN) of the resource **Example** ``` { "storage_device": { "is_encrypted": false, "name": "LocalVolumeDeviceName1", "snapshot_id": "snap-12345678901234567", "uid": "vol-09d5050dea915943d", "uid_alt": "arn:aws:ec2:us-west-2:123456789000:volume/vol-09d5050dea915943d" } } ``` ## Database Database instance attributes including engine type, endpoint, and user information. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [Database](https://schema.ocsf.io/1.6.0/objects/database) object definition. AWS Extension adds the following attributes to this object: + `cluster_uid` - The database cluster identifier + `db_endpoint` - The database endpoint + `encryption_details` - The database encryption details + `engine` - The database engine name (e.g. mysql) + `is_encrypted` - Whether the database is encrypted + `is_iam_authentication` - Whether IAM authentication is enabled + `is_public` - Whether the database is publicly accessible + `port` - The database port number + `security_groups` - Array of VPC security groups associated with the database instance + `snapshot_details` - The database snapshot details + `status` - The database status (e.g. available) + `subnet_group` - A database subnet group is a collection of subnets in a VPC + `uid_alt` - Amazon Resource Name (ARN) of the resource + `user` - The database user + `version` - The database version **Example** ``` { "database": { "cluster_uid": "SampleDBClusterId", "engine": "mysql", "is_iam_authentication": true, "is_public": false, "type": "Relational", "type_id": 1, "uid": "SampleDBId", "version": "13.6" } } ``` ## Database Cluster Database instance attributes including engine type, endpoint, and user information. **Requirement** Optional **Type** Object **OCSF status** New The database object includes the following attributes: + `uid` - The unique identifier of the database cluster + `uid_alt` - Amazon Resource Name (ARN) of the resource + `name` - The name of the database cluster + `status` - The database cluster status + `engine` - The engine associated with the cluster + `version` - The database cluster version + `cluster_members` - List of database instances that are part of the cluster + `security_groups` - Array of security groups associated with the cluster + `is_encrypted` - Whether the database cluster is encrypted + `is_iam_authentication` - Whether IAM authentication is enabled + `encryption_details` - The database cluster encryption details + `subnet_group` - The subnet group associated with the cluster + `port` - The database cluster port number + `zones` - List of availability zones + `db_endpoint` - The database cluster endpoint + `snapshot_details` - Details of the database snapshot **Example** ``` { "db_cluster": { "uid": "production-aurora-cluster", "uid_alt": "arn:aws:rds:us-east-1:123456789012:cluster:production-aurora-cluster", "name": "production-aurora-cluster", "status": "available", "engine": "aurora-mysql", "version": "8.0.mysql_aurora.3.04.0", "cluster_members": [ "instance-1", "instance-2" ], "security_groups": [ { "uid": "sg-0a1b2c3d4e5f6g7h8", "name": "db-security-group" } ], "is_encrypted": true, "is_iam_authentication": true, "encryption_details": { "key_uid": "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012" }, "subnet_group": { "uid": "production-db-subnet-group" }, "port": 3306, "zones": [ "us-east-1a", "us-east-1b", "us-east-1c" ], "db_endpoint": { "name": "production-aurora-cluster.cluster-abc123xyz.us-east-1.rds.amazonaws.com", "port": 3306 } } } ``` ## Cloud Function Cloud function attributes for serverless functions including handler, layers, and runtime configuration. **Requirement** Optional **Type** Object **OCSF status** New The cloud function object includes the following attributes: + `name` - The name of the cloud function + `uid` - The unique identifier of the cloud function + `uid_alt` - Amazon Resource Name (ARN) of the resource + `encryption_details` - The cloud function encryption details + `handler` - The method in the function code that processes events + `layers` - The list of cloud function layers that contain supplementary code or data + `runtime` - The cloud function language-specific environment + `security_groups` - Array of security groups associated with the cloud function + `subnet_info_list` - Details about subnets associated with the cloud function + `user` - Details about the IAM entity that grants the cloud\$1function permission to access services + `version` - The cloud function version + `vpc_uid` - The unique identifier of the VPC if the cloud function is in a VPC **Example** ``` { "cloud_function": { "name": "my-lambda-function", "uid": "my-lambda-function", "uid_alt": "arn:aws:lambda:us-east-1:123456789012:function:my-lambda-function", "handler": "index.handler", "runtime": "python3.11", "version": "$LATEST", "layers": [ { "name": "my-layer", "uid_alt": "arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1", "version": "1" } ], "security_groups": [ { "name": "lambda-security-group", "uid": "sg-0123456789abcdef0" } ], "subnet_info_list": [ { "uid": "subnet-0a1b2c3d4e5f6g7h8" } ], "vpc_uid": "vpc-0ef6045717b0362f6" } } ``` ## Databucket S3 bucket or data storage attributes. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [Databucket](https://schema.ocsf.io/1.6.0/objects/databucket) object definition. Note: This object is added to resource\$1details by the AWS Extension. The core OCSF Databucket object is used without additional attributes. **Example** ``` { "databucket": { "type": "S3", "type_id": 1, "uid": "my-bucket-name" } } ``` ## Image Image information for compute resources including platform and usage details. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [Image](https://schema.ocsf.io/1.6.0/objects/image) object definition. AWS Extension adds the following attributes to this object: + `platform` - The operating system platform of the image + `in_use_count` - Count of resources using this image **Example** ``` { "image": { "uid": "ami-0abcdef1234567890", "uid_alt": "arn:aws:ec2:us-east-1:123456789012:image/ami-0abcdef1234567890", "name": "my-custom-ami", "platform": "AMAZON_LINUX_2", "in_use_count": 2 } } ``` ## Subnet Info Details about the subnet where the resource is located. **Requirement** Optional **Type** Object **OCSF status** New The subnet info object includes the following attributes: + `uid` - The unique identifier of the subnet + `uid_alt` - Amazon Resource Name (ARN) of the resource + `name` - The name of the subnet + `zone` - The availability zone + `ip_count` - The number of IP addresses in the subnet + `cidr_block` - The CIDR block of the subnet + `is_default` - Whether this is the default subnet + `is_public` - Whether the subnet is publicly accessible + `state` - The state of the subnet + `vpc_uid` - The VPC ID where the subnet is located **Example** ``` { "subnet_info": { "uid": "subnet-0a1b2c3d4e5f6g7h8", "uid_alt": "arn:aws:ec2:us-east-1:123456789012:subnet/subnet-0a1b2c3d4e5f6g7h8", "name": "production-web-subnet-1a", "zone": "us-east-1a", "ip_count": 251, "cidr_block": "10.0.1.0/24", "is_default": false, "is_public": true, "state": "available", "vpc_uid": "vpc-0123456789abcdef0" } } ``` ## User IAM user attributes including instance profiles and policies. **Requirement** Optional **Type** Object **OCSF status** Added to `resource_details`. See the OCSF [User](https://schema.ocsf.io/1.6.0/objects/user) object definition. The user object includes the following attributes: + `instance_profiles` - List of instance profiles attached to an cloud instance + `policies` - Policies that assign permissions for users, groups, roles, and resources **Example** ``` { "user": { "type_id": 1, "uid": "AIDACKCEVSQ6C2EXAMPLE", "uid_alt": "arn:aws:iam::123456789012:user/developers/john.doe", "name": "john.doe", "type": "User", "groups": [ { "name": "Developers" }, { "name": "ReadOnlyAccess" } ], "policies": [ { "name": "AmazonS3ReadOnlyAccess" }, { "name": "AmazonEC2ReadOnlyAccess" } ] } } ``` # Coverage findings in Security Hub Coverage findings for Security Hub provide visibility into which AWS security features are enabled and where there might be gaps in coverage in a standalone account or across an organization's member accounts. Coverage Findings currently support reporting which services and features are enabled for Amazon GuardDuty, Amazon Inspector, Amazon Macie, and AWS Security Hub CSPM. These findings appear in the Security Coverage widget on the Security Hub dashboard with the ability to drill down into more detailed views by specific security capability. **Limitations** + For member accounts, coverage information is aggregated across linked AWS Regions, but only for that member account. + Coverage information is not shown for accounts not onboarded to Security Hub. ## Coverage findings for AWS Security Hub CSPM Security Hub CSPM Coverage Findings assess whether a qualified posture management security standard is enabled in an account. Enabling any Security Hub CSPM Standard will qualify, with the exception of AWS Control Tower and Resource Tagging standards. It can take up to 24 hours to detect standards enabled by default when enabling Security Hub CSPM. ## Coverage findings for Amazon GuardDuty GuardDuty coverage findings assess whether GuardDuty is enabled and which GuardDuty features are enabled in an AWS account: + GuardDuty Malware Protection for Amazon EC2 – Scans Amazon EC2 instances for potential malware + GuardDuty Amazon EKS Protection – Monitors Kubernetes audit logs for threats in Amazon EKS clusters + GuardDuty Lambda Protection – Analyzes Lambda function invocations for potential threats + GuardDuty Amazon S3 Protection – Analyzes data events for potential threats to Amazon S3 buckets + GuardDuty Amazon RDS Protection – Monitors for threats to Amazon RDS databases + GuardDuty Runtime Monitoring – Provides real-time monitoring of runtime behavior in Amazon EC2 instances + GuardDuty Foundational Coverage – Baseline GuardDuty features which are automatically turned on when GuardDuty is enabled **Note** For GuardDuty Foundational Coverage, coverage findings that indicate the feature is turned off mean GuardDuty is not enabled in the account for the coverage finding. It can take up to 24 hours for updates to GuardDuty coverage to reflect across all member accounts in an organization. ## Coverage findings for Amazon Inspector Amazon Inspector coverage findings assess whether Amazon Inspector is enabled and which features are enabled in an account: + Inspector EC2 Scanning – Scans Amazon EC2 instances for vulnerabilities + Inspector ECR Scanning – Scans Amazon ECR container images for vulnerabilities + Inspector Lambda Standard Scanning – Scans Lambda functions for vulnerabilities + Inspector Lambda Code Scanning – Scans Lambda code functions for code vulnerabilities ## Coverage findings for Amazon Macie Macie coverage findings assess whether Macie is enabled across AWS accounts: + Macie Automated Sensitive Data Discovery Coverage – Continuously evaluates your Amazon S3 data estate for sensitive data. It can take up to 24 hours for updates to Macie automated sensitive data discovery for coverage findings to reflect across all member accounts in an organization. ## Suppressing coverage findings By default, security coverage findings evaluate which Amazon GuardDuty, Amazon Inspector, Amazon Macie, and AWS Security Hub CSPM features are enabled for an account and Region. If certain security capabilities are not applicable for you or are an accepted risk, you can use the suppression feature to suppress coverage findings similar to all other findings. When a coverage finding is suppressed it will not be included in the coverage calculations within security coverage widget and the widget will display a message of *Coverage for security capabilities has been excluded through suppressed coverage findings* followed by a count of how many findings have been suppressed. **To suppress a coverage finding in Security Hub** 1. When viewing the security coverage widget choose the **percent covered** link. 1. From the coverage popup choose **View coverage findings**. Each finding with a status of **New** will be a finding that outlines an observed coverage gap. 1. Click the checkbox next to each finding that you would like to suppress. 1. At the top of the page, choose **Update status**, and then choose **Suppressed**. 1. In the **Set status to Suppressed** dialog box, optionally enter a note that details the reason for changing the status. Then choose **Set status**. # Exposure findings in Security Hub An exposure finding in Security Hub represents the correlation of multiple security signals that identify potential security risks in your AWS environment. Exposure findings help you understand and prioritize security risks by automatically analyzing combinations of vulnerabilities, configurations, threats, and resource relationships. An exposure finding includes traits and signals. A signal can include one or more types of exposure traits. Security Hub generates an exposure finding when signals from Security Hub CSPM, Amazon Inspector, GuardDuty, Macie, or other AWS services indicate the presence of an exposure. A resource can be the primary resource in, at most, one exposure finding. If a resource doesn't have any exposure traits or has insufficient traits, Security Hub doesn't generate an exposure finding for that resource. ## How exposure findings work Security Hub generates exposure findings by: + **Analyzing signals from multiple AWS security services**: Security Hub continuously collects and analyzes security signals from multiple AWS security services. It ingests findings from GuardDuty for threat detection, Amazon Inspector for vulnerability assessment, Security Hub CSPM for configuration checks, and Macie for sensitive data exposure. These signals are processed through advanced correlation engines to identify potential security risks. + **Evaluating resource configurations and relationships**: The system performs detailed evaluation of resource configurations against security best practices. It examines service-specific settings, compliance requirements, and security controls. This analysis helps identify misconfigurations that could lead to security vulnerabilities when combined with other factors. + **Assessing network reachability**: A crucial component of exposure findings is the assessment of network reachability. The system evaluates both internet exposure and internal network access paths. It analyzes security group configurations and network ACL settings to determine potential attack vectors. This analysis helps identify resources that might be inadvertently exposed to unauthorized access. + **Correlating related security issues**: The correlation engine maps relationships between AWS resources, analyzing how they interact and identifying potential security implications. It examines IAM permissions, roles, and resource access patterns to understand the broader security context. This process helps identify security risks that might exist due to the combination of seemingly innocent individual configurations. ## Components of an exposure finding Each exposure finding includes: + **Title and description of the potential security risk** - Each exposure finding includes a clear, descriptive title that immediately conveys the nature of the security risk. The description provides detailed information about the potential security impact, affected resources, and the broader context of the exposure. This information helps security teams quickly understand and assess the risk. + **Severity classification (Critical, High, Medium, Low)**: + **Critical severity** indicates immediate attention is required due to high likelihood of exploit and significant potential impact. These findings typically represent easily discoverable and exploitable vulnerabilities. + **High severity** suggests priority attention is needed, with moderate to high exploit likelihood and substantial potential impact. These findings might be relatively easy to exploit but might require specific conditions. + **Medium severity** indicates scheduled attention is required, with lower exploit likelihood and moderate potential impact. These findings typically require more complex exploitation methods. + **Low severity** suggests routine attention is needed, with limited exploit potential and minor impact. These findings are typically difficult to exploit and present minimal risk. + **Contributing traits that led to the exposure**: Contributing traits represent the primary factors that led to the exposure finding. These include direct security vulnerabilities, configuration issues, network exposure conditions, and resource permission settings. Each trait provides specific details about how it contributes to the overall security risk. + **Attack path visualization**: The attack path visualization provides an interactive diagram showing how potential attackers could exploit the identified exposure. It maps resource relationships, network paths, and potential impact flow, helping security teams understand the full scope of the risk and plan effective remediation strategies. + **Detailed remediation guidance**: Each exposure finding includes detailed remediation guidance with specific, actionable steps to address the identified risks. This guidance includes best practice recommendations, configuration correction steps, and prioritized action items. The guidance is tailored to the specific exposure scenario and considers the AWS services involved. + **Resource configuration details**: Configuration of the resource at the time the finding was created as well as current configuration of the resource in the Security Hub resource inventory dashboard. + **Contextual traits providing additional security context**: Contextual traits are additional security markers that were identified by Security Hub but were not used to create an exposure finding. ## Severity classification Exposure findings are classified based on: + Ease of discovery + Ease of exploit + Likelihood of exploit + Public awareness + Potential impact For more information, see [Exposure findings severity classification](https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-findings-severity.html). ## Benefits of exposure findings + **Reduced manual analysis through automated correlation**: Exposure findings significantly reduce the time and effort required for security analysis through automated correlation and intelligent risk prioritization. Security Hub continuously monitors your AWS environment, automatically identifying and correlating security risks that might be missed through manual review. + **Prioritized view of security risks**: Security Hub employs sophisticated risk assessment algorithms to prioritize exposures based on severity, impact, resource criticality, and exploit likelihood. This helps security teams focus their efforts on the most significant risks first, improving the efficiency of security operations. ## Sources of exposure findings Exposure findings incorporate data from: + **Amazon GuardDuty integration** provides continuous threat detection capabilities within exposure findings. It monitors for malicious activities, potential account compromises, and behavioral anomalies. The system incorporates these threat findings into the broader exposure analysis, helping identify when threats combine with other security issues to create significant risks. + **Amazon Inspector** contributes crucial vulnerability assessment data to exposure findings. It provides detailed information about network reachability, software vulnerabilities, and security best practice violations. This integration helps understand how vulnerabilities might be exploited through identified attack paths. + **AWS Security Hub CSPM** ensures that configuration compliance and security standards are considered in exposure analysis. It evaluates resources against established security controls and best practices, providing a foundation for understanding configuration-based risks. + **Amazon Macie** enhances exposure findings with sensitive data discovery and classification capabilities. It identifies where sensitive data exists within your AWS environment and evaluates potential privacy risks, helping understand the potential impact of identified exposures. ## Best practices + **Regularly review exposure findings**: Effective exposure management requires structured review processes. Organizations should implement daily reviews of critical exposures, weekly assessments of overall exposure status, monthly trend analysis, and quarterly security posture evaluations. This layered approach ensures appropriate attention to both immediate risks and long-term security trends. + **Prioritize critical and high-severity exposures**: Successful exposure management depends on effective risk prioritization. Organizations should focus first on critical exposures while considering resource criticality and business impact. This risk-based approach helps ensure security efforts align with business priorities and maximize risk reduction. + **Implement recommended remediation steps**: Exposure remediation should follow a systematic approach. Organizations should carefully implement recommended remediation steps, maintain detailed documentation of changes, conduct thorough testing of modifications, and validate the effectiveness of implemented fixes. This methodical approach helps ensure successful risk mitigation while avoiding unintended consequences. + **Configure automated response rules**: Maximizing the value of exposure findings requires effective automation. Organizations should implement automated response rules, configure appropriate notifications, establish efficient workflows, and maintain comprehensive audit trails. This automation helps ensure consistent and timely response to identified exposures while reducing manual effort. # Supported resource types for exposure findings in Security Hub AWS Security Hub generates exposure findings for the following types of AWS resources: + `AWS::DynamoDB::Table` + `AWS::EC2::Instance` + `AWS::ECS::Service` + `AWS::EKS::Cluster` + `AWS::IAM::User` + `AWS::Lambda::Function` + `AWS::RDS::DBInstance` + `AWS::S3::Bucket` Security Hub generates one exposure finding per primary resource. If a resource doesn't have any exposure traits or has insufficient traits, Security Hub doesn't generate an exposure finding for that resource. # Supported trait types in Security Hub AWS Security Hub generates an exposure finding when AWS Security Hub CSPM control findings and findings generated by other supported AWS services, such as Amazon Inspector, contain exposure traits for a resource. The following table provides information about the supported trait types. | Trait type | Description | Source | Impacted resources | | --- | --- | --- | --- | | Assumability | Indicates a resource with vended AWS Identity and Access Management permissions | Resource configuration from AWS Config | AWS resources with associated AWS Identity and Access Management roles | | Misconfiguration | Indicates a misconfigured resource | AWS Security Hub CSPM control findings, Amazon GuardDuty threat findings, and information about resource confirmation in AWS Config. | All resource types | | Reachability | Indicates open network paths to a resource | AWS Security Hub CSPM control findings, Amazon GuardDuty threat findings, and Amazon Inspector network reachability findings. | Amazon EC2 instances, Amazon EKS clusters, Lambda functions, and Amazon S3 buckets | | Sensitive Data | Indicates that a resource contains sensitive data | Macie sensitive data findings | Amazon S3 buckets | | Vulnerability | Indicates that a resource has a weakness which could be exploited by a threat source. | Amazon Inspector package vulnerability findings and Amazon GuardDuty Amazon EC2 Malware findings. | Amazon EC2 instances, Amazon ECS services, Amazon EKS clusters, and Lambda functions | Each trait can be associated with multiple titles that provide details about the exposure affecting the resource. For example, you might see an **Exploit Available** title for the **Vulnerability** trait in the details for an EC2 exposure finding. # Generating exposure findings Security Hub generates exposure findings in near real-time. As new security findings are ingested and existing findings are updated, Security Hub generates or updates exposure findings in near real time. Security Hub generates one exposure finding per resource ID. If a resource doesn't have any exposure traits or has insufficient traits, Security Hub doesn't generate an exposure finding for that resource. Security Hub doesn't publish exposure findings for resource types not supported by exposure findings. When a resource has a significant number and combination of traits, Security Hub generates an exposure finding. The number and combination of traits also determine the severity level of the exposure finding. # Sample exposure finding AWS Security Hub normalizes exposure findings in the Open Cybersecurity Schema Framework (OCSF). **Sample exposure finding** In the following sample exposure finding, the `related_events` parameter contains details unique to the exposure finding, such as contributing findings. Contributing findings are the traits and signals associated with an exposure finding. A single contributing finding can include one or more traits. The `observables` parameter identifies the resource associated with the contributing finding. This can be different from the `resources` parameter, which identifies the resource associated with the exposure finding. ``` { "activity_id": 1, "activity_name": "Create", "category_name": "Findings", "category_uid": 2, "class_name": "Detection Finding", "class_uid": 2004, "cloud": { "account": { "uid": "123456789012", "name": "production-application" }, "cloud_partition": "aws", "provider": "AWS", "region": "us-east-1" }, "finding_info": { "analytic": { "name": "Exposure", "type": "Rule", "type_id": 1, "uid": "0.0.1" }, "created_time_dt": "2024-11-15T21:39:26.337224100Z", "desc": "Publicly invocable Lambda function executed outside of VPC has vulnerability with known exploit that can be exploited from remote network", "finding.info.modified_time_dt": "2024-11-15T21:39:26.337224100Z", "related_events_count": 3, "related_events": [ { "tags": [ { "name": "Vulnerability", "values": [ "Attack Vector Network", "EPSS Level >= High", "EPSS Level >= Medium", "Exploit Available", "No Privileges Required", "No User Interaction Required", "Vulnerable" ] } ], "product": { "uid": "arn:aws:securityhub:us-east-1::productv2/aws/inspector" }, "observables": [ { "type": "Resource UID", "type_id": 10, "value": "arn:aws:lambda:us-east-1:123456789012:application-function" } ], "type": "Finding", "title": "CVE-2023-33246 - org.apache.rocketmq:rocketmq-controller", "uid": "arn:aws:inspector2:us-east-1:123456789012:finding/1234567890abcdef0" }, { "tags": [ { "name": "Reachability", "values": [ "Publicly Invocable" ] } ], "product": { "uid": "arn:aws:securityhub:us-east-1::productv2/aws/securityhub" }, "observables": [ { "type": "Resource UID", "type_id": 10, "value": "arn:aws:lambda:us-east-1:123456789012:application-function" } ], "type": "Finding", "title": "Lambda function policies should prohibit public access", "uid": "arn:aws:securityhub:us-east-1:123456789012:security-control/Lambda.1/finding/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa" }, { "tags": [ { "name": "Misconfiguration", "values": [ "Deployed outside VPC" ] } ], "product": { "uid": "arn:aws:securityhub:us-east-1::productv2/aws/securityhub" }, "observables": [ { "type": "Resource UID", "type_id": 10, "value": "arn:aws:lambda:us-east-1:123456789012:application-function" } ], "type": "Finding", "title": "Lambda functions should be in a VPC", "uid": "arn:aws:securityhub:us-east-1:123456789012:security-control/Lambda.3/finding/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "title": "Publicly invocable Lambda function executed outside of VPC has vulnerability with known exploit that can be exploited from remote network", "types": [ "Exposure/Potential Impact/Resource Hijacking" ], "uid": "arn:aws:securityhub:us-east-1:123456789012:risk:1234f781c7ae7507f01e2fb460f15ca8fe7f9c95e257698a092cb74a4ea84a42" }, "metadata": { "product": { "name": "Security Hub Exposure Analysis", "uid": "arn:aws:securityhub:us-east-1::productv2/aws/securityhub-risk", "vendor_name": "Amazon" }, "processed_time_dt": "2024-11-15T21:39:58.819Z", "profiles": [ "cloud", "datetime" ], "version": "1.4.0-dev" }, "resources": [ { "cloud_partition": "aws", "region": "us-east-1", "tags": [ { "name": "aws:cloudformation:stack-name", "value": "LambdaProdStack" }, { "name": "aws:cloudformation:stack-id", "value": "arn:aws:cloudformation:us-east-1:123456789012:stack/LambdaProdStack/a1b2c3d4-5678-90ab-cdef-EXAMPLE22222" }, { "name": "aws:cloudformation:logical-id", "value": "lambdar3function94D10D40" } ], "type": "AwsLambdaFunction", "uid": "arn:aws:lambda:us-east-1:123456789012:application-function" } ], "severity": "Critical", "severity_id": 5, "status": "New", "status_id": 1, "time": 1731706766337, "time_dt": "2024-11-15T21:39:26.337224100Z", "type_name": "Detection Finding: Create", "type_uid": 200401, "vendor_attributes": { "severity_id": 5, "severity": "Critical" } } ``` # Determining the severity level of an exposure finding AWS Security Hub assigns each exposure finding a default severity of `CRITICAL`, `HIGH`, `MEDIUM`, or `LOW`. Exposure findings with a severity of `INFORMATIONAL` aren't published. Security Hub uses several factors to determine the default severity level of an exposure finding: + **Awareness** – The extent at which the exposure is not theoretical, but has publicly available or automated exploits. This applies to exposure findings for EC2 instances and Lambda functions. + **Ease of discovery** – Whether automated tools, such as a port scan or internet search, are available to discover the resource at risk. + **Ease of exploit** – The ease at which a threat actor can exploit the exposure. For example, if open network paths or misconfigured metadata exists, a threat actor can more easily exploit the exposure. + **Likelihood of exploit** – The likelihood the exposure will be exploited in the next 30 days. This factor corresponds to the Exploit Protection Scoring System (EPSS) and applies to exposure findings for Amazon EC2 instances and Lambda functions. + **Impact** – The harm if the exploit is carried out. For example, an exposure could lead to loss of accountability, loss of availability, loss of confidentiality from data exposure, or loss of integrity from data corruption. # Reviewing exposure findings You can review all of your exposure findings in the Security Hub console and with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) API. The **Exposures** page in the Security Hub console shows all active exposure findings. Exposure findings are listed by decreasing severity. You can filter your exposure findings by adding and removing filters with the **Add filter** search bar. You can group your exposure findings with the **Group by** dropdown. You can also filter your exposure findings with the **Quick filters** menu. ## Details for exposure findings You can view many details for an exposure finding. These details are divided among tabs in the Security Hub console. The **Overview** tab provides key details about the exposure finding. The **Traits** tab lists the traits and signals associated with an exposure finding. The **Resources** tab provides details about the resource and resource tags associated with an exposure finding. The following list provides descriptions for exposure finding details. + **Finding title** – The title of the exposure finding. + **Severity level** – The severity level of the exposure finding. Security Hub uses the number and combination of traits for a resource to determine the severity level of an exposure finding. The severity level can be `CRITICAL`, `HIGH`, `MEDIUM`, or `LOW`. Security Hub doesn't publish exposure findings with a severity of `INFORMATIONAL`. You can update the `Severity` through the Security Hub console or with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_BatchUpdateFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_BatchUpdateFindingsV2.html) API operation. + **Description** – The description of the exposure finding. + **Type** – The name of the exposure finding type. For example, the name might resemble `Exposure/Potential Impact/Resource Hijacking`. + **Account** – The ID of the AWS account where the exposure finding was generated. + **Age** – Indicates how long the exposure finding has been active. + **Created time** – A timestamp that indicates when the exposure finding was created. + **Modified time** – A timestamp that indicates when the exposure finding was last updated. + **Region** – The AWS Region where the exposure finding was generated. + **Product name** – The name of the product that generated the exposure finding. This will always be **Security Hub Exposure Detection**. + **Company name** – The name of the company that generated the exposure finding. This will always be **AWS**. + **Activity name** – The name of the activity last performed against the finding. + **Status** – The status of this exposure finding. + **Finding ID** – A unique identifier associated with the exposure finding. + **Potential attack path (console only)** – An interactive visualization showing how potential attackers can access and take control of resources associated with an exposure finding. For more information, see [Viewing exposures in Security Hub with the potential attack path graph](potential-attack-path-graph.md). + **Traits** – Identifies trait types and trait titles associated with the exposure finding. In the Security Hub console, you can view traits by trait type or signal. This helps you analyze contributing findings in the context of the related exposure. + **Remediation** – Links to remediation documentation specific to traits identified in the exposure. + **Resources** – Identifies the resource associated with the exposure finding. # Reviewing details for exposure findings This topic describes how to review details about exposure findings in the AWS Security Hub console and with the API. ## Reviewing details for an exposure finding in the Security Hub console **To view details for an exposure finding in the Security Hub console** 1. Sign in using your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home]( https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **Exposures**. 1. Choose an exposure finding that you want to view details. ## Reviewing details for an exposure finding with the API You can review exposure findings with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) API or with the AWS CLI. You can filter all exposure findings with the `metadata.product.feature.uid` field with the `security-hub/Exposure` value. For more information, see [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html). **Example command** The following is an AWS CLI example that retrieves the 10 most recently generated exposure findings in your account. This example is formatted for Linux, macOS, or Unix, and it uses the backslash (\$1) line-continuation character to improve readability. ``` aws securityhub get-findings-v2 \ --max-results '10' \ --filter '{"CompositeFilters": [{"StringFilters": [{"FieldName":"metadata.product.feature.uid","Filter": {"Value":"security-hub/Exposure","Comparison":"EQUALS"}} ]}]}' ``` # Viewing exposures in Security Hub with the potential attack path graph The potential attack path graph is an interactive visualization that shows how potential attackers can access and take control of resources associated with an exposure finding. You can access this graph only in the Security Hub console and from the **Exposures** page. When you view details for an exposure finding, the **Overview** tab includes a section called **Potential attack path**. In this section of the **Overview** tab, you can choose and drag AWS resources in the potential attack path graph. You can focus on specific areas of the attack path graph with the zoom-in and zoom-out icons. You can expand the attack path graph in and out of fullscreen mode through the fullscreen icon. The legend codes the primary resource, involved resource, and contributing trait count by color and shows the trait categories and number of traits in the attack path graph. You can view details for a resource by choosing a resource and choosing **View resource details**. You can also copy the ID and AWS account number associated with a resource. Exposure findings with a reachability trait show the public internet and collapsed network path in the attack path graph. You can view this detail by choosing the collapsed network path node. # Remediating exposure findings The topics in this section describe remediation steps for exposure findings across different AWS services. The `Remediation` field of the [OCSF format](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-v2-ocsf-findings.html) contains two fields: `remediation` and `references`. ``` "Remediation": { "Recommendation": { "remediation":{"desc":"String", "references":["string array"]} } }, ``` **Note** The remediation guidance provided in the following sections might require additional consultation in other AWS resources. # Remediating exposures for DynamoDB tables AWS Security Hub can generate exposure findings for DynamoDB tables. On the Security Hub console, the DynamoDB table involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits in DynamoDB](#misconfiguration) + [The DynamoDB table has point-in-time recovery disabled](#point-in-time-recovery-disabled) + [The DynamoDB table is not covered by a backup plan](#backup-plan-disabled) + [The DynamoDB table has deletion protection disabled](#deletion-protection-disabled) ## Misconfiguration traits in DynamoDB The following describes the misconfiguration traits and remediation steps for DynamoDB tables. ### The DynamoDB table has point-in-time recovery disabled **Enable DynamoDB point-in-time recovery** DynamoDB point-in-time recovery provides continuous automated backups for your DynamoDB table data. For information about how to restore a DynamoDB table to a point in time, see [Restoring a DynamoDB table to a point in time](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html) in the *Amazon DynamoDB User Guide*. ### The DynamoDB table is not covered by a backup plan AWS Backup provides a centralized service to configure, manage, and automate backups across AWS services, including DynamoDB. Without a backup plan, your table lacks scheduled, automated backups with customizable retention periods, creating significant security risks. An attacker could maliciously corrupt or delete your table data. Without proper backups, you may have no recovery option beyond the Point-in-Time Recovery window (if enabled), potentially resulting in permanent data loss. Following data protection best practices, we recommend covering your DynamoDB tables with a backup plan. **Create a backup plan** Before creating a backup plan, determine an appropriate backup frequency and retention periods for your data. For information about how to create a backup plan, see [Assign resources to a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) in the *Amazon DynamoDB User Guide*. ### The DynamoDB table has deletion protection disabled Deletion protection prevents the accidental deletion of DynamoDB tables. When deletion protection is disabled, DynamoDB tables are vulnerable to unintended deletion through console actions, API calls, CLI commands, or automated processes. This can expose your AWS environment to data loss, as an unauthorized entity with access to your AWS environment could intentionally delete tables, resulting in service disruption and permanent data loss. Following data protection best practices, we recommend enabling data protection for DynamoDB tables. **Enable deletion protection** If you manage multiple tables, consider using CloudFormation to update table properties in bulk. You can modify your CloudFormation templates to include `DeletionProtectionEnabled` property and update your stacks. After completing remediation, verify deletion protection is enabled in the **Additional** info dropdown in the table **Settings** tab. # Remediating exposures for EC2 instances AWS Security Hub can generate exposure findings for Amazon Elastic Compute Cloud (EC2) instances. On the Security Hub console, the EC2 instance involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for EC2 instances](#misconfiguration) + [The EC2 instance allows access to IMDS using version 1](#metadata-misconfiguration) + [The IAM role associated with the Amazon EC2 instance has an administrative access policy](#administrative-access-policy) + [The IAM role associated with the Amazon EC2 instance has a service admin policy](#service-admin-policy) + [The Amazon EC2 instance has a security group or network ACL that allows SSH or RDP access](#remote-access-allowed) + [The Amazon EC2 instance has an open security group](#open-security-group) + [Reachability traits for EC2 instances](#reachability) + [The EC2 instance is reachable over the internet](#internet-reachable) + [Vulnerability traits for EC2 instances](#vulnerability) + [EC2 instance has network-exploitable software vulnerabilities with a high likelihood of exploitation](#high-priority-vulnerability) + [The Amazon EC2 instance has software vulnerabilities](#low-priority-vulnerability) + [The EC2 instance has an End-Of-Life operating system](#end-of-life-operating-system-detected) + [The EC2 instance has malicious software packages](#malicious-package) + [The EC2 instance has malicious files](#malicious-file) ## Misconfiguration traits for EC2 instances Here are misconfiguration traits for EC2 instances and suggested remediation steps. ### The EC2 instance allows access to IMDS using version 1 Instance metadata is data about your Amazon EC2 instance that applications can use to configure or manage the running instance. The instance metadata service (IMDS) is an on-instance component that code on the instance uses to securely access instance metadata. If IMDS is not properly secured, it can become a potential attack vector, as it provides access to temporary credentials and other sensitive configuration data. IMDSv2 provides stronger protection against exploitation through session-oriented authentication, requiring a session token for metadata requests and limiting session duration. Following standard security principles, AWS recommends that you configure Amazon EC2 instances to use IMDSv2 and disable IMDSv1. **Test application compatibility** Before implementing IMDSv2, test your instance to ensure its compatibility with IMDSv2. Some applications or scripts may require IMDSv1 for core functionality and require additional configuration. For more information about tools and recommended paths for testing application compatibility, [Transition to using Instance Metadata Service Version 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) in the *Amazon Elastic Compute Cloud User Guide*. **Update instance to use IMDSv2** Modify existing instances to use IMDSv2. For more information, see [Modify instance metadata options for existing instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-existing-instances.html) in the *Amazon Elastic Compute Cloud User Guide*. **Apply updates to instances in an Auto Scaling group** If your instance is part of an Auto Scaling group, update your launch template or launch configuration with a new configuration, and perform an instance refresh. ### The IAM role associated with the Amazon EC2 instance has an administrative access policy Administrative access policies provide Amazon EC2 instances with broad permissions to AWS services and resources. These policies typically include permissions not required for instance functionality. Providing an IAM identity with an administrative access policy on an Amazon EC2 instance (instead of the minimum set of permissions the role attached to your instance profile needs) can increase the scope of an attack if the Amazon EC2 instance is compromised. If an instance is compromised, attackers could utilize these excessive permissions to move laterally across your environment, access data, or manipulate resources. Following standard security principles, we recommend you grant least privileges, which means you only grant the permissions required to perform a task. **Review and identify administrative policies** In the IAM dashboard, find the role with the role name. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements with `"Effect": "Allow", "Action": "*"`, and `"Resource": "*"`. **Implement least privilege access** Replace administrative policies with policies that grant only the specific permissions required for the instance to function. For more information about security best practices for IAM roles, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in Security best practices in the *AWS Identity and Access Management User Guide*. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see [Findings for external and unused access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the *AWS Identity and Access Management User Guide*. Alternatively, you can create a new IAM role to avoid impacting other applications using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. For instructions on replacing an IAM role for an instance, see [Attach an IAM role to an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/attach-iam-role.html) in the *Amazon Elastic Compute Cloud User Guide*. **Secure configuration considerations** If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + **Secure configuration considerations** + **Multi-factor authentication (MFA)** – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see [Require multi-factor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) in the *AWS Identity and Access Management User Guide*. + **IAM conditions** – Setting up condition elements allow you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see [Use conditions in IAM policies to further restrict access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *AWS Identity and Access Management User Guide*. + **Permissions boundaries** – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *AWS Identity and Access Management User Guide*. **Apply updates to instances in an auto scaling group** For Amazon EC2 instances in an AWS auto scaling group, update the launch template or launch configuration with the new instance profile, and perform an instance refresh. For information about updating a launch template, see [Modify a launch template (manage launch template versions)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html) in the *Amazon Elastic Compute Cloud User Guide*. For more information, see [Use an instance refresh to update instances in an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html). For more information about using IAM roles with Auto Scaling groups, see [IAM role for applications that run on Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/us-iam-role.html) instances in the * Amazon EC2 Auto Scaling User Guide*. ### The IAM role associated with the Amazon EC2 instance has a service admin policy Service access policies provide Amazon EC2 instances with broad permissions to AWS services and resources. These policies typically include permissions that are not required for instance functionality. Providing an IAM identity with an administrative access policy on an Amazon EC2 instance instead of the minimum set of permissions the role attached to your instance profile needs can increase the scope of an attack if an instance is compromised. Following standard security principles, we recommend that you grant least privileges, which means that you grant only the permissions required to perform a task. **Review and identify administrative policies** In the IAM dashboard, find the role with the role name. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements with `"Effect": "Allow", "Action": "*"`, and `"Resource": "*"`. **Implement least privilege access** Replace service admin policies with those that grant only the specific permissions required for the instance to function. For more information on security best practices for IAM roles, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in Security best practices in the *AWS Identity and Access Management User Guide*. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see [Findings for external and unused access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the *AWS Identity and Access Management User Guide*. Alternatively, you can create a new IAM role to avoid impacting other applications that are using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. For information about replacing an IAM role for an instance, see [Attach an IAM role to an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/attach-iam-role.html) in the *Amazon Elastic Compute Cloud User Guide* **Secure configuration considerations** If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: **Secure configuration considerations** If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + **Multi-factor authentication (MFA)** – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see [Require multi-factor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) in the *AWS Identity and Access Management User Guide*. + **IAM conditions** – Setting up condition elements allows you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see [Use conditions in IAM policies to further restrict access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *AWS Identity and Access Management User Guide*. + **Permissions boundaries** – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *AWS Identity and Access Management User Guide*. **Apply updates to instances in Auto Scaling group** For Amazon EC2 instances in an AWS auto scaling group, update the launch template or launch configuration with the new instance profile, and perform an instance refresh. For information about updating a launch template, see [Modify a launch template (manage launch template versions)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html) in the *Amazon Elastic Compute Cloud User Guide*. For more information, see [Use an instance refresh to update instances in an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html). For more information about using IAM roles with Auto Scaling groups, see [IAM role for applications that run on Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/us-iam-role.html) instances in the * Amazon EC2 Auto Scaling User Guide*. ### The Amazon EC2 instance has a security group or network ACL that allows SSH or RDP access Remote access protocols like SSH and RDP allow users to connect to and manage Amazon EC2 instances from external locations. When security groups permit unrestricted access to these protocols from the internet, they increase the attack surface of your Amazon EC2 instances by allowing internet access to your instance. Following standard security principles, AWS recommends you limit remote access to specific, trusted IP addresses or ranges. 1. **Modify security group rules** Restrict access to your Amazon EC2 instances to specific trusted IP addresses. Limit SSH and RDP access to specific trusted IP addresses, or use CIDR notation to specify IP ranges (e.g., 198.168.1.0/24). To modify security group rules, see [Configure security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) in the *Amazon Elastic Compute Cloud User Guide*. ### The Amazon EC2 instance has an open security group Security groups act as virtual firewalls for your Amazon EC2 instances to control inbound and outbound traffic. Open security groups, which allow unrestricted access from any IP address, may expose your instances to unauthorized access. Following standard security principles, AWS recommends restricting security group access to specific IP addresses and ports. **Review security group rules and assess current configuration** Evaluate which ports are open and accessible from broad IP ranges, such as `(0.0.0.0/0 or ::/0)`. For instructions on viewing security group details, see [DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) in the *Porting Assistant for .NET API Reference*. **Modify security group rules** Modify your security group rules to restrict access to specific trusted IP addresses or ranges. When updating your security group rules, consider separating access requirements for different network segments by creating rules for each required source IP range or restricting access to specific ports. To modify security group rules, see [Configure security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) in the *Amazon EC2 User Guide*. ## Reachability traits for EC2 instances Here are reachability traits for EC2 instances and suggested remediation steps. ### The EC2 instance is reachable over the internet Amazon EC2 instances with ports that are reachable from the internet through an internet gateway (including instances behind Application Load Balancers or Classic Load Balancers), a VPC peering connection, or a VPN virtual gateway may expose your instance to the internet. Following standard security principles, we recommend implementing least-privilege network access controls by restricting inbound traffic to only necessary sources and ports. **Modify or remove security group rules** In the **Resources** tab, open the resource for the Amazon EC2 Security Group. Review whether internet access is required for the instance to function. Modify or remove inbound security group rules that allow unrestricted access (`0.0.0.0/0` or `::/0`). Implement more restrictive rules based on specific IP ranges or security groups. If limited public access is necessary, restrict access to specific ports and protocols required for the instance's function. For instructions on managing security group rules, see [Configure security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) in the *Amazon EC2 User Guide*. **Update network ACLs** Review and modify network access control lists (ACLs) associated with the instance's subnet. Verify that the ACL settings align with the security group changes and don't unintentionally allow public access. For instructions on modifying network ACLs, see [Work with network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/nacl-tasks.html) in the *Amazon VPC User Guide*. **Alternative access methods** Consider the following options for alternative access methods: + **Use NAT Gateway for outbound internet connectivity** – For instances in private subnets that require access to the internet (e.g., to download updates), consider using a NAT Gateway instead of assigning a public IP address. A NAT Gateway allows instances in private subnets to initiate outbound connections to the internet while preventing inbound connections from the internet. + **Use Systems Manager Session Manager** – Session Manager provides secure shell access to your Amazon EC2 instances without the need for inbound ports, managing SSH keys, or maintaining bastion hosts. + **Use WAF and Elastic Load Balancing or Application Load Balancer** – For instances that are running web applications, consider using an LB combined with AWS Web Application Firewall (WAF). LBs can be configured to allow your instances to run in private subnets while the LB runs in a public subnet and handles internet traffic. Adding a WAF to your load balancer provides additional protection against web exploits and bots. ## Vulnerability traits for EC2 instances Here are vulnerability traits for EC2 instances and suggested remediation steps. ### EC2 instance has network-exploitable software vulnerabilities with a high likelihood of exploitation Software packages that are installed on EC2 instances can be exposed to Common Vulnerabilities and Exposures (CVEs). Critical CVEs pose significant security risks to your AWS environment. Unauthorized principals can exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Critical vulnerabilities with high exploitation likelihood represent immediate security threats, as exploit code may already be publicly available and actively used by attackers or automated scanning tools. We recommend patching these vulnerabilities to protect your instance. **Update affected instances** Review the **References** section in the **Vulnerability** tab of the trait. Vendor documentation may include specific remediation guidance. Follow the appropriate remediation using these general guidelines: Use Systems Manager Patch Manager to apply patches for both operating systems and applications. Patch Manager helps you select and deploy operating system and software patches automatically on large groups of instances. If you don't have Patch Manager configured, manually update the operating system on each affected instance. Update the affected applications to their latest secure versions following the vendor’s recommended procedures. To manage application updates across multiple instances, consider using Systems Manager State Manager to keep your software in a consistent state. If updates aren't available, consider removing or disabling the vulnerable application until a patch is released or other mitigations, such as restricting network access to the application or disabling vulnerable features. Follow the specific remediation advice provided in the Amazon Inspector finding. This could involve changing security group rules, modifying instance configurations, or adjusting application settings. Check if the instance is part of Auto Scaling Group. AMI-replacement patching is done on immutable infrastructures by updating the AMI ID that is configured to deploy new Amazon EC2 instances in an Auto Scaling group. If you are using a custom/golden AMI, create an instance with the new AMI, and then customize the instance and create a new golden AMI For more information, see [AMI updates patching (using patched AMIs for Auto Scaling groups)](https://docs.aws.amazon.com/managedservices/latest/userguide/patching-method-immutable.html). **Future considerations** To prevent future occurrences, consider implementing a vulnerability management program. Amazon Inspector can be configured to automatically scan for CVEs on your instances. Amazon Inspector can also be integrated with Security Hub for automatic remediations. Consider implementing a regular patching schedule using Systems Manager Maintenance Windows to minimize disruption to your instances. ### The Amazon EC2 instance has software vulnerabilities Software packages that are installed on Amazon EC2 instances can be exposed to Common Vulnerabilities and Exposures (CVEs). Noncritical CVEs represent security weaknesses with lower severity or exploitability compared to critical CVEs. While these vulnerabilities pose less immediate risk, attackers can still exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Following security best practices, AWS recommends patching these vulnerabilities to protect your instance from attack. **Update affected instances** Use AWS Systems Manager Patch Manager to apply patches for operating systems. Patch Manager helps you select and deploy operating system and software patches automatically on large groups of instances. If you don't have Patch Manager configured, manually update the operating system on each affected instance. Update the affected applications to their latest secure versions following the vendor’s recommended procedures. To manage application updates across multiple instances, consider using AWS Systems Manager State Manager to keep your software in a consistent state. If updates aren't available, consider removing or disabling the vulnerable application until a patch is released or other mitigations, such as restricting network access to the application or disabling vulnerable features. Follow the specific remediation advice provided in the Amazon Inspector finding. This could involve changing security group rules, modifying instance configurations, or adjusting application setting. Check if the instance is part of Auto Scaling Group. AMI-replacement patching is done on immutable infrastructures by updating the AMI ID that is configured to deploy new Amazon EC2 instances in an Auto Scaling group. If you are using a custom/golden AMI, create an instance with the new AMI, and then customize the instance and create a new golden AMI For more information, see [AMI updates patching (using patched AMIs for Auto Scaling groups)](https://docs.aws.amazon.com/managedservices/latest/userguide/patching-method-immutable.html). **Future considerations** To prevent future occurrences, consider implementing a vulnerability management program. Amazon Inspector can be configured to automatically scan for CVEs on your instances. Amazon Inspector can also be integrated with Security Hub for automatic remediations. Consider implementing a regular patching schedule using Systems Manager Maintenance Windows to minimize disruption to your instances. ### The EC2 instance has an End-Of-Life operating system The EC2 instance runs an end-of-life operating system that is no longer supported or maintained by the original developer. This exposes the instance to security vulnerabilities and potential attacks. When operating systems reach end-of-life, vendors typically stop releasing new security advisories. Existing security advisories may also be removed from vendor feeds. As a result, Amazon Inspector could potentially stop generating findings for known CVEs, creating further gaps in security coverage. See [Discontinued operating systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#formerly-supported-os) in the *Amazon Inspector User Guide* for information about operating systems that have reached end of life that can be detected by Amazon Inspector. **Update to a supported operating system version** We recommend updating to a supported version of the operating system. In the exposure finding, open the resource to access the affected resource. Before updating the operating system version on your instance, review available versions in [Supported Operating Systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-os) in the *Amazon Inspector User Guide* for a list of currently supported OS versions. ### The EC2 instance has malicious software packages Malicious packages are software components that contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious packages pose an active and critical threat to your instance, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious packages to protect your instance from potential attacks. **Remove malicious packages** Review the malicious package details in the **References** section of the **Vulnerability** tab of the trait to understand the threat. Remove the identified malicious packages using the appropriate package manager. See [Package management tool](https://docs.aws.amazon.com/linux/al2023/ug/package-management.html) in the *Amazon Linux 2023 User Guide* for an example. After removing the malicious packages, consider performing a scan to ensure that all packages that may have been installed by the malicious code have been removed. For more information, see [Starting On-demand malware scan in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection-getting-started-on-demand-scan.html) in the **. ### The EC2 instance has malicious files Malicious files contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious files pose an active and critical threat to your instance, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious files to protect your instance from potential attacks. **Remove malicious files** To identify the specific Amazon Elastic Block Store (Amazon EBS) volume that has malicious files, review the **Resources** section of the trait's finding details. Once you have identified the volume with the malicious file, remove the identified malicious files. After removing the malicious files, consider performing a scan to ensure that all files that may have been installed by the malicious file have been removed. For more information, see [Starting On-demand malware scan in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection-getting-started-on-demand-scan.html) in the **. # Remediating exposures for Amazon ECS services AWS Security Hub can generate exposure findings for Amazon Elastic Container Service (Amazon ECS) services. The Amazon ECS service involved in an exposure finding and its identifying information are listed in the **Resource** section of the finding details. You can retrieve these resource details on the Security Hub console or programmatically with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for Amazon ECS services](#ecs-service-misconfiguration) + [The Amazon ECS service uses a task definition that allows containers to access the root file systems](#root-access-to-filesystem) + [The Amazon ECS service uses a task definition configured to share a host's process namespace](#exposed-namespace) + [The Amazon ECS service uses a task definition configured with cleartext credentials in the environment variables](#cleartext-credentials-present) + [The Amazon ECS service has an open security group](#open-security-group) + [The Amazon ECS service has public IP addresses](#public-ip-assigned) + [The Amazon ECS service uses a task definition that is configured with host networking mode enabled](#host-networking-mode-enabled) + [The IAM role associated with the Amazon ECS service has an administrative access policy](#administrative-access-policy) + [The IAM Role associated with the ECS service has a Service Admin Policy](#service-admin-policy) + [Vulnerability traits for Amazon ECS services](#vulnerability) + [The Amazon ECS service has a container with network-exploitable software vulnerabilities with a high likelihood of exploitation](#high-priority-vulnerability) + [The Amazon ECS service has a container with software vulnerabilities](#low-priority-vulnerability) + [The Amazon ECS service has a container with an End-Of-Life operating system](#end-of-life-operating-system-detected) + [The Amazon ECS service has a container with malicious software packages](#malicious-package) ## Misconfiguration traits for Amazon ECS services Here are misconfiguration traits for Amazon ECS services and suggested remediation steps. ### The Amazon ECS service uses a task definition that allows containers to access the root file systems Amazon ECS containers with access to the host root filesystem can potentially read, modify, or execute critical files on the host system. This configuration increases the risk that a compromised container could be used to access or modify resources outside its intended scope, potentially exposing sensitive data on the host filesystem. Following standard security principles, AWS recommends that you grant least privileges, which means that you grant only the permissions required to perform a task. **Review and modify containers with host filesystem access** In the exposure finding, identify the task definition ARN. Open the task definition in the Amazon ECS console. Look for the volumes section in the task definition that defines host path mappings. Review the task definition to determine if the host filesystem access is required for container functionality. If host filesystem access is not required, create a new task definition revision and remove any volume definitions that use host paths. If host filesystem access is required, consider configuring the container to use a read-only file system to prevent unauthorized modifications. ### The Amazon ECS service uses a task definition configured to share a host's process namespace Amazon ECS containers running with exposed namespaces can potentially access host system resources and other container namespaces. This configuration could allow a compromised container to escape its isolation boundary, which could lead to accessing processes, network interfaces, or other resources outside of its intended scope. A process ID (PID) namespace provides separation between processes. It prevents system processes from being visible, and allows PIDs to be reused, including PID 1. If the host's PID namespace is shared with containers, it would allow containers to see all of the processes on the host system. This reduces the benefit of process level isolation between the host and the containers. These factors could lead to unauthorized access to processes on the host itself, including the ability to manipulate and terminate them. Following standard security principles, AWS recommends maintaining proper namespace isolation for containers. **Update task definitions with exposed namespaces** Open the **Resources** tab of the exposure, identify the task definition with the exposed namespace. Open the task definition in the Amazon ECS console. Look for the pidMode settings with a value of host, which would share the process ID namespaces with the host. Remove the pidMode: host settings from your task definitions to ensure containers run with proper namespace isolation. ### The Amazon ECS service uses a task definition configured with cleartext credentials in the environment variables Amazon ECS containers with cleartext credentials in environment variables expose sensitive authentication information that could be compromised if an attacker gains access to the task definition, container environment, or container logs. This creates a significant security risk, as leaked credentials could be used to access other AWS services or resources. **Replace cleartext credentials** In the exposure finding, identify the task definition with cleartext credentials. Open the task definition in the Amazon ECS console. Look for environment variables in the container definition that contain sensitive values such as AWS access keys, database passwords, or API tokens. Consider the following alternatives to pass credentials: + Instead of using AWS access keys, use IAM task execution roles and task roles to grant permissions to your containers. + Store credentials as secrets in AWS Secrets Manager and reference them in your task definition. **Update task definitions** Create a new revision of your task definition that securely handles credentials. Then update your Amazon ECS service to use the new task definition revision. ### The Amazon ECS service has an open security group Security groups act as virtual firewalls for your Amazon ECS tasks to control inbound and outbound traffic. Open security groups, which allow unrestricted access from any IP address, may expose your containers to unauthorized access, increasing the risk of exposure to automated scanning tools and targeted attacks. Following standard security principles, AWS recommends restricting security group access to specific IP addresses and ports. **Review security group rules and assess current configuration** Open the resource for the Amazon ECS Security Group. Evaluate which ports are open and accessible from broad IP ranges, such as `(0.0.0.0/0 or ::/0)`. **Modify security group rules** Modify your security group rules to restrict access to specific trusted IP addresses or ranges. When updating your security group rules, consider separating access requirements for different network segments by creating rules for each required source IP range or restricting access to specific ports. **Modify security group rules** Consider the following options for alternative access methods: + Session Manager provides secure shell access to your Amazon EC2 instances without the need for inbound ports, managing SSH keys, or maintaining bastion hosts. + NACLs provide an additional layer of security at the subnet level. Unlike security groups, NACLs are stateless and require both inbound and outbound rules to be explicitly defined. ### The Amazon ECS service has public IP addresses Amazon ECS services with public IP addresses assigned to their tasks are directly accessible from the internet. While this may be necessary for services that need to be publicly available, it increases the attack surface and potential for unauthorized access. **Identify services with public IP addresses** In the exposure finding, identify the Amazon ECS service that has public IP addresses assigned to its tasks. Look for the `assignPublicIp` setting with a value of `ENABLED` in the service configuration. **Update task definitions** Create a new revision of your task definition that disables public IP addresses. Then update your Amazon ECS service to use the new task definition revision. **Implement private network access patterns** For instances that are running web applications, consider using a Load Balancer (LB). LBs can be configured to allow your instances to run in private subnets while the LB runs in a public subnet and handles internet traffic. ### The Amazon ECS service uses a task definition that is configured with host networking mode enabled Amazon ECS containers running with host networking mode share the network namespace with the host, allowing direct access to the host's network interfaces, ports, and routing tables. This configuration bypasses the network isolation provided by containers, potentially exposing services running on the container directly to external networks and allowing containers to modify host network settings. Following standard security principles, AWS recommends maintaining proper network isolation for containers. **Disable host networking mode** In the exposure finding, identify the task definition with host networking mode. Open the task definition in the Amazon ECS console. Look for the networkMode setting with a value of host in the task definition. Consider the following options to disable host networking mode: + The `awsvpc` network mode provides the strongest level of network isolation by giving each task its own elastic network interface. + The `bridge` network mode provides isolation while allowing port mappings to expose specific container ports to the host. **Update task definitions** Create a new revision of your task definition with the updated network mode configuration. Then update your Amazon ECS service to use the new task definition revision. ### The IAM role associated with the Amazon ECS service has an administrative access policy IAM roles with administrative access policies attached to Amazon ECS tasks provide broad permissions that exceed what is typically required for container operation. This configuration increases the risk that a compromised container could be used to access or modify resources throughout your AWS environment. Following standard security principles, AWS recommends implementing least privilege access by granting only the permissions required for a task to function. **Review and identify administrative policies** In the **Resource ID**, identify the IAM role name. Go to the IAM dashboard and select the identified role. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for `AdministratorAccess`. Otherwise, in the policy document, look for statements that have the statements `"Effect": "Allow", "Action": "*", and "Resource": "*"` together. **Implement least privilege access** Replace administrative policies with those that grant only the specific permissions required for the instance to function. To identify unnecessary permissions, you can use IAM Access Analyzer to understand how to modify your policy based on access history. Alternatively, you can create a new IAM role to avoid impacting other applications that are using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. **Secure configuration considerations** If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. + Setting up condition elements allow you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. **Update task definitions** Create a new revision of your task definition that references the new or updated IAM roles. Then update your Amazon ECS service to use the new task definition revision. ### The IAM Role associated with the ECS service has a Service Admin Policy Service admin policies provide Amazon ECS tasks and services with permissions to perform all actions within specific AWS services. These policies typically include permissions that are required for Amazon ECS task functionality. Providing an IAM role with a service admin policy for Amazon ECS tasks, instead of the minimum set of permissions needed, can increase the scope of an attack if a container is compromised. Following standard security principles, AWS recommends that you grant least privileges, which means granting only the permissions required to perform a task. **Review and identify administrative policies** In the **Resource ID**, identify the Amazon ECS task role and execution role names. Go to the [IAM dashboard](https://console.aws.amazon.com/iam/home/#roles) and select the identified roles. Review the permissions policies attached to these IAM roles. Look for policy statements that grant full access to services (e.g., `"s3": "*", "ecr": "*"`). For instructions on editing IAM policies, see [Edit IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-policy-details) in the *IAM User Guide*. **Implement least privilege access** Replace service admin policies with those that grant only the specific permissions required for Amazon ECS tasks to function. To identify unnecessary permissions, you can use IAM Access Analyzer to understand how to modify your policy based on access history. Alternatively, you can create a new IAM role to avoid impacting other applications that are using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. **Secure configuration considerations** If service-level administrative permissions are necessary for Amazon ECS tasks, consider implementing these additional security controls: + **IAM conditions** – Set up condition elements to restrict when and how administrative permissions can be used based on factors like VPC endpoints or specific Amazon ECS clusters. For more information, see [Use conditions in IAM policies to further restrict access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *IAM User Guide*. + **Permission boundaries** – Establish maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *IAM User Guide*. **Update task definitions** Create a new revision of your task definition that references the new or updated IAM roles. Then update your Amazon ECS service to use the new task definition revision. ## Vulnerability traits for Amazon ECS services Here are vulnerability traits for Amazon ECS and suggested remediation steps. ### The Amazon ECS service has a container with network-exploitable software vulnerabilities with a high likelihood of exploitation 1. **Understand the exposure** Package vulnerability findings identify software packages in your AWS environment that are exposed to Common Vulnerabilities and Exposures (CVEs). Attackers can exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. ECR container images can have package vulnerability findings. 1. **Remediate the exposure** 1. **Update package version** Review the package vulnerability finding for your ECR container image. Update the package version as suggested by Amazon Inspector. For more information, see [Viewing details for your Amazon Inspector findings](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-details.html) in the *Amazon Inspector User Guide*. The **Remediation** section of the finding details in the Amazon Inspector console tells you which commands you can run to update the package. 1. **Update base container images** Rebuild and update base container images regularly to keep your containers up to date. When rebuilding an image, don't include unnecessary components to reduce the attack surface. For instructions on rebuilding a container image, see [Rebuild your images often](https://docs.docker.com/build/building/best-practices/#rebuild-your-images-often). ### The Amazon ECS service has a container with software vulnerabilities Software packages that are installed on Amazon ECS containers can be exposed to Common Vulnerabilities and Exposures (CVEs). Low priority vulnerabilities represent security weaknesses with lower severity or exploitability compared to high priority vulnerabilities. While these vulnerabilities pose less immediate risk, attackers can still exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. **Update affected container images** Review the **References** section in the **Vulnerability** tab of the trait. Vendor documentation may include specific remediation guidance. Apply the appropriate remediation by following these general guidelines: + Update your container images to use patched versions of the affected packages. + Update the affected dependencies in your application to their latest secure versions. After updating your container image, push it to your container registry and update your Amazon ECS task definition to use the new image. **Future considerations** To further strengthen the security posture of your container images, consider following Amazon ECS task and container security best practices. Amazon Inspector can be configured to automatically scan for CVEs on your containers. Amazon Inspector can also be integrated with Security Hub for automatic remediations. Consider implementing a regular patching schedule using Systems Manager Maintenance Windows to minimize disruption to your containers. ### The Amazon ECS service has a container with an End-Of-Life operating system The Amazon ECS container relies on an end-of-life operating system that is no longer supported or maintained by the original developer. This exposes the container to security vulnerabilities and potential attacks. When operating systems reach end-of-life, vendors typically stop releasing new security advisories. Existing security advisories may also be removed from vendor feeds. As a result, Amazon Inspector could potentially stop generating findings for known CVEs, creating further gaps in security coverage. See [Discontinued operating systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#formerly-supported-os) in the *Amazon Inspector User Guide* for information about operating systems that have reached end of life that can be detected by Amazon Inspector. **Update to a supported operating system version** We recommend updating to a supported version of the operating system. In the exposure finding, open the resource to access the affected resource. Before updating the operating system version in your container image, review available versions in [Supported Operating Systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-os) in the *Amazon Inspector User Guide* for a list of currently supported OS versions. After updating your container image, push it to your container registry and update your Amazon ECS task definition to use the new image. ### The Amazon ECS service has a container with malicious software packages Malicious packages are software components that contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious packages pose an active and critical threat to your Amazon ECS container images, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious packages to protect your containers from potential attacks. **Remove malicious packages** Review the malicious package details in the **References** section of the **Vulnerability** tab of the trait to understand the threat. Remove the identified malicious packages from your container images then rebuild them. For more information, see [ContainerDependency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html) in the *AWS Amazon ECS API Reference*. After updating your container image, push it to your container registry and update your Amazon ECS task definition to use the new image. For more information, see [Updating an Amazon ECS task definition using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the *AWS Amazon ECS Developer Guide*. # Remediating exposures for Amazon EKS clusters AWS Security Hub can generate exposure findings for Amazon Elastic Kubernetes Service (Amazon EKS) clusters. The Amazon EKS cluster involved in an exposure finding and its identifying information are listed in the **Resource** section of the finding details. You can retrieve these resource details on the Security Hub console or programmatically with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for Amazon EKS clusters](#eks-cluster-misconfiguration) + [The Amazon EKS cluster allows public access](#internet-reachable) + [The Amazon EKS cluster uses an unsupported Kubernetes version](#unsupported-kubernetes-version) + [The Amazon EKS cluster uses unencrypted Kubernetes secrets](#unencrypted-kubernetes-secrets) + [Vulnerability traits for Amazon EKS clusters](#vulnerability) + [The Amazon EKS cluster has a container with network-exploitable software vulnerabilities with a high likelihood of exploitation](#high-priority-vulnerability) + [The Amazon EKS cluster has a container with software vulnerabilities](#low-priority-vulnerability) + [The Amazon EKS cluster has a container with an End-Of-Life operating system](#end-of-life-operating-system-detected) + [The Amazon EKS cluster has a container with malicious software packages](#malicious-package) + [The EKS cluster has malicious files](#malicious-file) ## Misconfiguration traits for Amazon EKS clusters Here are misconfiguration traits for Amazon EKS clusters and suggested remediation steps. ### The Amazon EKS cluster allows public access The Amazon EKS cluster endpoint is the endpoint that you use to communicate with your cluster’s Kubernetes API server. By default, this endpoint is public to the internet. Public endpoints increase your attack surface area and the risk of unauthorized access to your Kubernetes API server, potentially allowing attackers to access or modify cluster resources or access sensitive data. Following security best practices, AWS recommends restricting access to your EKS cluster endpoint to only necessary IP ranges. **Modify endpoint access** In the exposure finding, open the resource. This will open the affected Amazon EKS cluster. You can configure your cluster to use private access, public access, or both. With private access, Kubernetes API requests that originate within your cluster’s VPC use the private VPC endpoint. With public access, Kubernetes API requests that originate from outside your cluster’s VPC use the public endpoint. **Modify or remove public access to the cluster** To modify endpoint access for an existing cluster, see [Modifying cluster endpoint access](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access) in the *Amazon Elastic Kubernetes Service User Guide*. Implement more restrictive rules based on specific IP ranges or security groups. If limited public access is necessary, restrict access to specific CIDR block ranges or use prefix lists. ### The Amazon EKS cluster uses an unsupported Kubernetes version Amazon EKS supports each Kubernetes version for a limited period of time. Running clusters with unsupported Kubernetes versions can expose your environment to security vulnerabilities, as CVE patches will stop being released for outdated versions. Unsupported versions may contain known security vulnerabilities that can be exploited by attackers and lack security features that may be available in newer versions. Following security best practices, AWS recommends keeping your Kubernetes version updated. **Update Kubernetes version** In the exposure finding, open the resource. This will open the affected Amazon EKS cluster. Before updating your cluster, review [Available versions on standard support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-deprecation) in the *Amazon Elastic Kubernetes Service User Guide* for a list of currently supported Kubernetes versions. ### The Amazon EKS cluster uses unencrypted Kubernetes secrets Kubernetes secrets are, by default, stored unencrypted in the API server’s underlying data store (etcd). Anyone with API access or with access to etcd can retrieve or modify a secret. To prevent this, you should encrypt Kubernetes secrets at rest. If Kubernetes Secrets are unencrypted, they are vulnerable to unauthorized access if etcd is compromised. Since secrets often contain sensitive information like passwords and API tokens, their exposure could lead to unauthorized access to other applications and data. Following security best practices, AWS recommends encrypting all sensitive information stored in Kubernetes secrets. **Encrypt Kubernetes secrets** Amazon EKS supports the encryption of Kubernetes secrets using KMS keys through envelope encryption. To enable encryption of Kubernetes secrets for your EKS cluster, see [Encrypt Kubernetes secrets with KMS on existing clusters](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html) in the *Amazon EKS User Guide*. ## Vulnerability traits for Amazon EKS clusters Here are the vulnerability traits for Amazon EKS clusters. ### The Amazon EKS cluster has a container with network-exploitable software vulnerabilities with a high likelihood of exploitation Software packages that are installed on EKS clusters can be exposed to Common Vulnerabilities and Exposures (CVEs). Critical CVEs pose significant security risks to your AWS environment. Unauthorized users can exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Critical vulnerabilities with high exploitation likelihood represent immediate security threats, as exploit code may already be publicly available and actively used by attackers or automated scanning tools. Following security best practices, AWS recommends patching these vulnerabilities to protect your instance from attack. **Update affected instances** Update your container images to newer versions that include security fixes for the identified vulnerabilities. This typically involves rebuilding your container images with updated base images or dependencies, then deploying the new images to your Amazon EKS cluster. ### The Amazon EKS cluster has a container with software vulnerabilities Software packages that are installed on Amazon EKS clusters can be exposed to Common Vulnerabilities and Exposures (CVEs). Noncritical CVEs represent security weaknesses with lower severity or exploitability compared to critical CVEs. While these vulnerabilities pose less immediate risk, attackers can still exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Following security best practices, AWS recommends patching these vulnerabilities to protect your instance from attack. **Update affected instances** Update your container images to newer versions that include security fixes for the identified vulnerabilities. This typically involves rebuilding your container images with updated base images or dependencies, then deploying the new images to your Amazon EKS cluster. ### The Amazon EKS cluster has a container with an End-Of-Life operating system The Amazon EKS container image relies on an end-of-life operating system that is no longer supported or maintained by the original developer. This exposes the container to security vulnerabilities and potential attacks. When operating systems reach end-of-life, vendors typically stop releasing new security advisories. Existing security advisories may also be removed from vendor feeds. As a result, Amazon Inspector could potentially stop generating findings for known CVEs, creating further gaps in security coverage. See [Discontinued operating systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#formerly-supported-os) in the *Amazon Inspector User Guide* for information about operating systems that have reached end of life that can be detected by Amazon Inspector. **Update to a supported operating system version** We recommend updating to a supported version of the operating system. In the exposure finding, open the resource to access the affected resource. Before updating the operating system version in your container image, review available versions in [Supported Operating Systems](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-os) in the *Amazon Inspector User Guide* for a list of currently supported OS versions. After updating your container image, rebuild and redeploy your containers to the Amazon EKS cluster. ### The Amazon EKS cluster has a container with malicious software packages Malicious packages are software components that contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious packages pose an active and critical threat to your Amazon EKS cluster, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious packages to protect your cluster from potential attacks. **Remove malicious packages** Review the malicious package details in the **References** section of the **Vulnerability** tab of the trait to understand the threat. Remove the identified malicious packages from your container images. Then, delete the pods with the compromised image. Update your Kubernetes deployments to use the updated container images. Then, deploy your changes and redeploy your pods. ### The EKS cluster has malicious files Malicious files contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious files pose an active and critical threat to your cluster, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious files to protect your cluster from potential attacks. **Remove malicious files** To identify the specific Amazon Elastic Block Store (Amazon EBS) volume that has malicious files, review the **Resources** section of the trait's finding details. Once you have identified the volume with the malicious file, remove the identified malicious files. After removing the malicious files, consider performing a scan to ensure that all files that may have been installed by the malicious file have been removed. For more information, see [Starting On-demand malware scan in GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection-getting-started-on-demand-scan.html) in the **. # Remediating exposures for IAM users AWS Security Hub can generate exposure findings for AWS Identity and Access Management (IAM) users. On the Security Hub console, the IAM user involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. IAM best practices recommend that you create IAM roles or use federation with an identity provider to access AWS using temporary credentials instead of creating individual IAM users. If that's an option for your organization and use case, we recommend switching to roles or federation instead of using IAM users. For more information, see [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) in the *IAM User Guide*. **Contents** + [Misconfiguration traits for IAM users](#iam-user-misconfiguration) + [The IAM user has a policy with administrative access](#administrative-access-policy) + [The IAM user does not have MFA enabled](#user-mfa-disabled) + [The IAM user has a policy with administrative access to an AWS service](#service-admin-policy) + [The AWS account for the IAM user has weak password policies](#weak-password-policies) + [The IAM user has unused credentials](#unused-credentials) + [The IAM user has unrotated access keys](#unrotated-access-keys) + [The IAM user has a policy that allows unrestricted access to KMS key decryption](#unrestricted-kms-decryption-allowed) ## Misconfiguration traits for IAM users Here are misconfiguration traits for IAM users and suggested remediation steps. ### The IAM user has a policy with administrative access IAM policies grant a set of privileges to IAM users when accessing resources. Administrative policies provide IAM users with broad permissions to AWS services and resources. Providing full administrative privileges, instead of the minimum set of permissions that the user needs, can increase the scope of an attack if credentials are compromised. Following standard security principles, AWS recommends that you grant least privileges, which means that you grant only the permissions required to perform a task. 1. **Review and identify administrative policies** – In the **Resource ID**, identify the IAM role name. Go to the IAM dashboard and select the identified role. Review the permissions policy attached to the IAM user. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements that have the statements `"Effect":` `"Allow"` with `"Action": "*"` over `"Resource": "*"`. 1. **Implement least privilege access** – Replace service administrative policies with those that grant only the specific permissions required for the user to function. For more information on security best practices for IAM policies, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *AWS Identity and Access Management User Guide*. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see [Findings for external and unused access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the *AWS Identity and Access Management User Guide*. 1. **Secure configuration considerations** – If service administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + **Multi-factor authentication (MFA)** – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see [Require multi-factor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) in the *AWS Identity and Access Management User Guide*. + **IAM conditions** – Setting up condition elements allow you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see [Use conditions in IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) to further restrict access in the *AWS Identity and Access Management User Guide*. + **Permission boundaries** – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *AWS Identity and Access Management User Guide*. ### The IAM user does not have MFA enabled Multi-factor authentication (MFA) adds an extra layer of protection on top of a user name and password. When MFA is enabled and an IAM user signs in to an AWS website, they are prompted for their user name, password, and an authentication code from their AWS MFA device. The authenticating principal must possess a device that emits a time-sensitive key and must have knowledge of a credential. Without MFA, if a user’s password is compromised, an attacker gains full access to the user’s AWS permissions. Following standard security principles, AWS recommends enabling MFA for all accounts and users that have AWS Management Console access. **Review MFA types** AWS supports the following [MFA types](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html#id_credentials_mfa-types): + Passkeys and security keys + Virtual authenticator applications + Hardware TOTP tokens Although authentication with a physical device typically provides more stringent security protection, using any type of MFA is more secure than having MFA disabled. **Enable MFA** To enable the MFA type that suits your requirements, see [AWS multi-factor authentication in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*. Follow the steps for the specific MFA type you want to implement. For organizations managing many users, you may want to enforce MFA usage by requiring MFA to access sensitive resources. ### The IAM user has a policy with administrative access to an AWS service Service admin policies provide IAM users with permissions to perform all actions within a specific AWS service. These policies typically include permissions that are not required for users to perform their job functions. Providing an IAM user with service administrator privileges, instead of the minimum set of permissions needed, increases the scope of an attack if credentials are compromised. Following standard security principles, AWS recommends that you grant least privileges, which means that you grant only the permissions required to perform a task. **Review and identify service admin policies** In the **Resource ID**, identify the IAM role name. Go to the IAM dashboard and select the identified role. Review the permissions policy attached to the IAM user. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements that have the statements "`Effect": "Allow" with "Action": "*" over "Resource": "*"`. **Implement least privilege access** Replace service administrative policies with those that grant only the specific permissions required for the user to function. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. **Secure configuration considerations** If service administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate exposure: + MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. + Use condition elements to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. + Use permission boundaries to establish the maximum permissions a role can have, providing guardrails for roles with administrative access. ### The AWS account for the IAM user has weak password policies Password policies help protect against unauthorized access by enforcing minimum complexity requirements for IAM user passwords. Without strong password policies, there’s an increased risk that user accounts could be compromised through password guessing or brute force attacks. Following standard security principles, AWS recommends implementing a strong password policy to ensure users create complex passwords that are difficult to guess. **Configure a strong password policy** Go to the IAM dashboard and navigate to Account settings. Review the current password policy settings for your account, including minimum length, character types required, and password expiration settings. At a minimum, AWS recommends following these best practices when setting your password policy: + Require at least one uppercase character. + Require at least one lowercase character. + Require at least one symbol. + Require at least one number. + Require at least eight characters. **Additional security considerations** Consider these additional security measures in addition to a strong password policy: + MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. + Setting up condition elements to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. ### The IAM user has unused credentials Unused credentials, including passwords and access keys that have remained inactive for 90 days or more pose a security risk to your AWS environment. These unused credentials create potential attack vectors for attackers and increase your organization’s overall attack surface. Following security best practices, AWS recommends deactivating or removing credentials that haven’t been used in 90 days or more to reduce your attack surface. **Deactivate or remove unused credentials** In the exposure finding, open the resource. This will open the user details window. Before taking action on unused credentials, assess the potential impact on your environment. Removing credentials without proper assessment could disrupt background processes, scheduled jobs, and more. Consider a brief deactivation period before permanent removal to verify the impact of removing the unused credentials. Take the appropriate action based on the credential type: + For unused console passwords, consider first changing the password and temporarily deactivating it. If no issues arise, proceed with permanent deactivation or deletion. + For unused access keys, consider first deactivating the key. After confirming no systems are affected, proceed with permanent deactivation or deletion. + For unused users, consider temporarily deactivating the user by attaching a restrictive policy before full deletion. ### The IAM user has unrotated access keys Access keys consist of an access key ID and a secret access key that enable programmatic access to AWS resources. When access keys remain unchanged for extended periods of time, they increase the risk of unauthorized access if they are compromised. Following security best practices, AWS recommends rotating access keys every 90 days to minimize the window of opportunity for attackers to use compromised credentials. **Rotate access keys** In the exposure finding, open the resource. This will open the user details window. To rotate access keys, see [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) in the *IAM User Guide*. ### The IAM user has a policy that allows unrestricted access to KMS key decryption AWS KMS enables you to create and manage cryptographic keys that are used to protect your data. IAM policies that allow unrestricted AWS KMS decryption permissions (e.g., `kms:Decrypt` or `kms:ReEncryptFrom`) on all KMS keys can lead to unauthorized data access if an IAM user’s credentials are compromised. If an attacker gains access to these credentials, they could potentially decrypt any encrypted data in your environment, which could include sensitive data. Following security best practices, AWS recommends implementing least privilege by limiting AWS KMS decryption permissions to only specific keys that users need for their job functions. **Implement least-privilege access** In the exposure finding, open the resource. This will open the IAM Policy window. Look for permissions in KMS that allow kms:Decrypt or `kms:ReEncryptFrom` or `KMS:*` with a resource specification of `"*"`. Update the policy to restrict AWS KMS decryption permissions to only the specific keys needed. Modify the policy to replace the `"*"` resource with the specific ARNs of required AWS KMS keys. **Secure configuration considerations** Consider adding conditions to further restrict when these permissions can be used. For example, you can limit decryption operations to specific VPC endpoints or source IP ranges. You can also configure key policies to further restrict who can use specific KMS keys. # Remediating exposures for Lambda functions AWS Security Hub can generate exposure findings for AWS Lambda (Lambda) functions. On the Security Hub console, the Lambda function involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for Lambda functions](#lambda-function-misconfiguration) + [Lambda function is deployed outside of an Amazon VPC](#deployed-outside-vpc) + [The IAM Role associated with the Lambda function has an Administrative access policy](#administrative-access-policy) + [The IAM Role associated with the Lambda function has a policy with administrative access to an AWS Service](#service-admin-policy) + [The Lambda function is accessible through API Gateway without authorization](#api-gateway-no-authorization) + [Reachability traits for Lambda functions](#lambda-function-reachability) + [The Lambda function can be publicly invoked](#publicly-invocable) + [Vulnerability traits for Lambda functions](#lambda-function-vulnerability) + [The Lambda function has network-exploitable software vulnerabilities](#high-priority-vulnerability) + [The Lambda function has software vulnerabilities](#low-priority-vulnerability) + [The Lambda function has malicious software packages](#malicious-package) + [The Lambda function has code vulnerabilities](#code-vulnerability) ## Misconfiguration traits for Lambda functions Here are misconfiguration traits for Lambda functions and suggested remediation steps. ### Lambda function is deployed outside of an Amazon VPC Lambda functions by default are deployed with access to the public internet. This default configuration gives Lambda functions the ability to reach AWS service endpoints and external APIs, but it also exposes them to potential security risks. Functions with internet access could be used to exfiltrate data, communicate with unauthorized servers, or become entry points for external actors if compromised. Amazon VPC provides network isolation by restricting your Lambda functions to communicate only with resources within your defined private network. Following standard security principles, we recommend deploying Lambda functions within a VPC to improve security through network isolation. **Attach function to VPC** In the exposure finding, open the resource with the hyperlink. This will open the Lambda function window. To secure your Lambda function by restricting its network access, attach it to a VPC that has the appropriate network controls in place. Before attaching your function to a VPC, plan for any AWS service access it may need, as functions in private subnets without NAT gateways or VPC endpoints won't be able to reach AWS service APIs. For information about how to attach a Lambda function to an Amazon VPC in your account, see [Attaching Lambda functions to an Amazon VPC in your AWS account](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#configuration-vpc-attaching). Consider using VPC endpoints for service connectivity without internet access if your function requires to access AWS services from within a private subnet. Configure a NAT Gateway if you require outbound internet connectivity from private subnets. ### The IAM Role associated with the Lambda function has an Administrative access policy Administrative access policies provide Lambda functions with broad permissions to AWS services and resources. These policies typically include permissions that are not required for functionality. Providing an IAM identity with an administrative access policy on a Lambda function, instead of the minimum set of permissions that the execution role needs, can increase the scope of an attack if the function is compromised. Following standard security principles, AWS recommends that you grant least privileges, which means that you grant only the permissions required to perform a task. 1. **Review and identify administrative policies** In the exposure finding, identify the role name. Go to the IAM dashboard and find the role with the role name identified previously. Review the permissions policy attached to the IAM role. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements that have the statements `"Effect": "Allow", "Action": "*"` and `"Resource": "*"` together. 1. **Implement least privilege access** Replace administrative policies with those that grant only the specific permissions required for the function to operate. For more information on security best practices for IAM roles, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *AWS Identity and Access Management User Guide*. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see [Findings for external and unused access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the *AWS Identity and Access Management User Guide*. Alternatively, you can create a new IAM role to avoid impacting other Lambda functions using the existing role. In this scenario, create a new IAM role. Then associate the new role with the instance. For information about replacing an IAM role for a function, see [Update a function’s execution role](https://docs.aws.amazon.com/lambda/latest/dg/permissions-executionrole-update.html#update-execution-role) in the *AWS Lambda Developer Guide*. 1. **Secure configuration considerations** If administrative access permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + **Multi-factor authentication (MFA)** – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see [Require multi-factor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) in the *AWS Identity and Access Management User Guide*. + **IAM conditions** – Setting up condition elements allows you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see [Use conditions in IAM policies to further restrict access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *IAM User Guide*. + **Permission boundaries** – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *AWS Identity and Access Management User Guide*. ### The IAM Role associated with the Lambda function has a policy with administrative access to an AWS Service Service admin policies allow Lambda functions to perform all actions within a specific AWS service. These policies typically grant more permissions than necessary for a function's operation. If a Lambda function with a service admin policy is compromised, an attacker could use those permissions to potentially access or modify sensitive data or services within your AWS environment. Following standard security principles, we recommend that you grant least privileges, which means that you grant only the permissions required to perform a task. 1. **Review and identify administrative policies** In the exposure finding, identify the role name in the ARN. Go to the IAM dashboard, and find the role name. Review the permissions policy attached to the role. If the policy is an AWS managed policy, look for `AdministratorAccess` or `IAMFullAccess`. Otherwise, in the policy document, look for statements that have the statements `"Effect": "Allow", "Action": "*"` and `"Resource": "*"` . 1. **Implement least privilege access** Replace administrative policies with those that grant only the specific permissions required for the function to operate. For more information, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *AWS Identity and Access Management User Guide*. To identify unnecessary permissions, you can use the IAM Access Analyzer to understand how to modify your policy based on access history. For more information, see [Findings for external and unused access](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) in the *AWS Identity and Access Management User Guide*. Alternatively, you can create a new IAM role to avoid impacting other Lambda functions that are using the existing role. In this scenario, create a new IAM role, then associate the new IAM role with the instance. For instructions on replacing an IAM role for a function, see [Update a function’s execution role](https://docs.aws.amazon.com/lambda/latest/dg/permissions-executionrole-update.html#update-execution-role) in the *AWS Lambda Developer Guide*. 1. **Secure configuration considerations** If service-level administrative permissions are necessary for the instance, consider implementing these additional security controls to mitigate risk: + **Multi-factor authentication (MFA)** – MFA adds an additional security layer by requiring an additional form of authentication. This helps prevent unauthorized access even if credentials are compromised. For more information, see [Require multi-factor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) in the *AWS Identity and Access Management User Guide*. + **IAM conditions** – Setting up condition elements allows you to restrict when and how administrative permissions can be used based on factors like source IP or MFA age. For more information, see [Use conditions in IAM policies to further restrict access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-policy-conditions) in the *AWS Identity and Access Management User Guide*. + **Permissions boundaries** – Permission boundaries establish the maximum permissions a role can have, providing guardrails for roles with administrative access. For more information, see [Use permissions boundaries to delegate permissions management](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-permissions-boundaries) in the *AWS Identity and Access Management User Guide*. ### The Lambda function is accessible through API Gateway without authorization API Gateway methods without authorization allow any caller with access to the API Gateway to invoke the integrated Lambda function without identity verification. This configuration creates security risks, as callers can invoke the Lambda function without proper authorization, potentially leading to abuse of function capabilities, resource consumption, access to sensitive data, or unauthorized operations. While API Gateway may have network-level access controls, the lack of method-level authorization could allow free invocation of the function by any caller with network access to the API Gateway. Following security best practices, AWS recommends implementing appropriate authorization mechanisms for API Gateway methods that integrate with Lambda functions. **Configure API Gateway authentication** In the **Resources** tab of the exposure, click on the **Open resource** hyperlink to access the API Gateway method. Review the current authorization configuration and implement appropriate authentication mechanisms. API Gateway supports several authentication options including AWS IAM, Amazon Cognito User Pools, Lambda authorizers, and API keys. Choose the authentication method that best fits your security requirements and use case. For detailed instructions on configuring authentication, see [Controlling and managing access to a REST API in API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html) in the *API Gateway Developer Guide*. ## Reachability traits for Lambda functions Here are reachability traits for Lambda functions and suggested remediation steps. ### The Lambda function can be publicly invoked Lambda resource-based policies determine who can invoke your functions. A function with a resource policy that includes "\$1" as the principal (or no principal at all) allows any authenticated AWS users to invoke it. This creates significant risk, especially for functions that process sensitive data, modify resources, or have elevated permissions. Unauthorized users could exploit this configuration to perform unwanted operations, potentially exposing data, manipulating resources, or abusing function capabilities. Following security best practices, we recommend restricting Lambda function access to only authorized principals. **Modify the function's resource-based policy** In the **Resources** tab of the exposure, open the resource with the hyperlink. This will open the Lambda function window. Restrict access to your Lambda function by specifying only authorized AWS account IDs or specific IAM principals (users, roles, or services) in the resource-based policy. You can only modify resource-based policies programmatically. ## Vulnerability traits for Lambda functions Here are vulnerability traits for Lambda functions and suggested remediation steps. ### The Lambda function has network-exploitable software vulnerabilities Software packages used in Lambda function code can contain Common Vulnerabilities and Exposures (CVEs) that have a high chance of being exploited. Critical CVEs pose significant security risks to your AWS environment. Attackers can exploit these unpatched vulnerabilities to compromise the confidentiality, integrity, or availability of data, or to access other systems. Critical vulnerabilities with high exploitation likelihood represent immediate security threats, as exploit code may already be publicly available and actively used by attackers or automated scanning tools. Following security best practices, we recommend patching these vulnerabilities to protect your function from attack. **Update affected functions** Review the **References** section in the **Vulnerability** tab for the trait. Vendor documentation may include specific remediation guidance. Update the vulnerable libraries to their latest secure versions following the vendor recommended procedures. Typically, the remediation workflow depends on whether you deployed the Lambda package by uploading a zip file or by creating a Lambda function with a container image. After updating the libraries, update the Lambda function code to use the fixed version. Afterwards, deploy the updated version. ### The Lambda function has software vulnerabilities Lambda functions often use third-party libraries and dependencies that may contain security vulnerabilities with lower severity or exploitability compared to critical CVEs. While these non-critical vulnerabilities might not be as immediately exploitable, they still represent security weaknesses that could be chained together with other vulnerabilities to compromise your function. Over time, new exploit techniques might also emerge that elevate the risk of these vulnerabilities. Following standard security principles, we recommend patching these vulnerabilities to maintain a secure environment. **** Review the **References** section in the **Vulnerability** tab for the trait. Vendor documentation may include specific remediation guidance. Update the vulnerable libraries to their latest secure versions following the vendor recommended procedures. Typically, the remediation workflow depends on whether you deployed the Lambda package by uploading a zip file or by creating a Lambda function with a container image. After updating the libraries, update the Lambda function code to use the fixed version. Afterwards, deploy the updated version. ### The Lambda function has malicious software packages Malicious packages are software components that contain harmful code designed to compromise the confidentiality, integrity, and availability of your systems and data. Malicious packages pose an active and critical threat to your Lambda function, as attackers can execute malicious code automatically without exploiting a vulnerability. Following security best practices, AWS recommends removing malicious packages to protect your Lambda function from potential attacks. **Remove malicious packages** Review the malicious package details in the **References** section of the **Vulnerability** tab of the trait to understand the threat. Remove the identified malicious packages from your function code and dependencies. For functions using layers, check if the malicious packages are installed in any layers and remove them. Update your deployment package or container image to exclude the malicious packages, then deploy the updated version. For instructions, see [Deploying Lambda functions as .zip file archives](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html) for .zip file archives or [Create a Lambda function using a container image](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html) for container images. ### The Lambda function has code vulnerabilities Lambda function application code contains security vulnerabilities that could be exploited by threat actors. Code vulnerabilities include data leaks, injection flaws, missing encryption, and weak cryptography that are identified through automated code analysis. These vulnerabilities pose security risks to your AWS environment, as attackers can exploit them to compromise the confidentiality, integrity, or availability of data, or to access other systems. Code vulnerabilities represent security weaknesses that could be chained together with other attack vectors to compromise your function. Following security best practices, AWS recommends addressing these code vulnerabilities to protect your function from attack. **Update affected functions** Review the **References** section in the **Vulnerability** tab of the trait. Amazon Inspector findings may include specific remediation guidance and code snippets showing the vulnerable code locations. Address the identified security issues in your function code using the provided plug-and-play code blocks or by implementing secure coding practices. Always review code remediation suggestions before adopting them, as you might need to edit them to ensure your code performs as intended. After fixing the vulnerabilities, update the Lambda function code to use the corrected version. For instructions, see [Updating function code](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html#configuration-function-update) in the *AWS Lambda Developer Guide*. Afterwards, deploy the updated version. For instructions, see [Deploying Lambda functions as .zip file archives](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html) for .zip file archives or [Create a Lambda function using a container image](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html) for container images. For more information about Amazon Inspector code scanning, see [Amazon Inspector Lambda code scanning](https://docs.aws.amazon.com/inspector/latest/user/scanning_resources_lambda_code.html) in the *Amazon Inspector User Guide*. # Remediating exposures for Amazon RDS instances and clusters AWS Security Hub can generate exposure findings for Amazon RDS instances and clusters. On the Security Hub console, the Amazon RDS instance or cluster involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for Amazon RDS instances and clusters](#rds-instance-cluster-misconfiguration) + [The Amazon RDS DB instance is configured with public access](#public-access-configured) + [The Amazon RDS DB cluster has a snapshot that's shared publicly](#publicly-available-rds-cluster-snapshot) + [The Amazon RDS DB instance has a snapshot that's shared publicly](#publicly-available-rds-database-snapshot) + [The Amazon RDS DB instance has a snapshot that is not encrypted at rest](#unencrypted-rds-database-snapshot) + [The Amazon RDS DB cluster has a snapshot that is not encrypted at rest](#unencrypted-rds-cluster-snapshot) + [The Amazon RDS DB instance has an open security group](#open-security-group) + [The Amazon RDS DB instance has IAM database authentication disabled](#rds-instance-iam-authentication-disabled) + [The Amazon RDS DB instance uses the default admin username](#rds-instance-default-admin-name-used) + [The Amazon RDS DB cluster uses the default admin username](#rds-cluster-misconfiguration-db-cluster-uses-default-admin-username) + [The Amazon RDS DB instance has automatic minor version upgrades disabled](#rds-instance-minor-version-upgrades-disabled) + [The Amazon RDS DB instance has automated backups disabled](#rds-instance-backups-disabled) + [The Amazon RDS DB instance has deletion protection disabled](#rds-instance-deletion-protection-disabled) + [The Amazon RDS DB cluster has deletion protection disabled](#rds-cluster-misconfiguration-db-cluster-deletion-protection-disabled) + [The Amazon RDS DB instance uses the default port for the database engine](#rds-instance-default-port-in-use) + [The Amazon RDS DB instance is not covered by a backup plan](#rds-instance-not-in-backup-plan) ## Misconfiguration traits for Amazon RDS instances and clusters The following describes the misconfiguration traits and remediation steps for Amazon RDS instances and clusters. ### The Amazon RDS DB instance is configured with public access Amazon RDS instances with public access are potentially accessible over the internet through their endpoints. While public access is sometimes necessary for instance functionality, this configuration can be used as a potential attack vector for unauthorized users to attempt to access your database. Publicly accessible databases can be exposed to port scanning, brute force attacks, and exploitation attempts. Following standard security principles, we recommend that you limit public exposure of your database resources. 1. **Modify public access settings** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. Evaluate whether the DB instance requires public accessibility based on your application architecture. For more information, see [Setting up public or private access in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/gettingstartedguide/security-public-private.html). ### The Amazon RDS DB cluster has a snapshot that's shared publicly Public snapshots can be accessed by any AWS account, potentially exposing sensitive data to unauthorized users. Any AWS account has permission to copy these public snapshots and create DB instances from them, which could lead to data breaches or unauthorized data access. Following security best practices, we recommend restricting access to your Amazon RDS snapshots to only trusted AWS accounts and organizations. **1. Configure an Amazon RDS snapshot for private access** In the exposure finding, open the resource through the hyperlink. For information about how to modify snapshot sharing settings, see [Sharing a snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-share-snapshot.html#aurora-share-snapshot.Sharing) in the *Amazon Aurora User Guide.* For information about how to stop sharing snapshots, see [Stopping snapshot sharing](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/share-snapshot-stop.html) in the *Amazon Aurora User Guide.*. ### The Amazon RDS DB instance has a snapshot that's shared publicly Public snapshots can be accessed by any AWS account, potentially exposing sensitive data to unauthorized users. Any AWS account has permission to copy these public snapshots and create DB instances from them, which could lead to data breaches or unauthorized data access. Following security best practices, we recommend restricting access to your Amazon RDS snapshots to only trusted AWS accounts and organizations. **Configure an Amazon RDS snapshot for private access** In the exposure finding, open the resource through the hyperlink. For information about how to modify snapshot sharing settings, see [Sharing a DB snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html) in the *Amazon RDS User Guide.* For information about how to stop sharing snapshots, see [Stop sharing a DB snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html#USER_ShareSnapshot.Sharing.StopSharing) in the *Amazon RDS User Guide.*. ### The Amazon RDS DB instance has a snapshot that is not encrypted at rest Unencrypted Amazon RDS DB instance snapshots may expose sensitive data if unauthorized access to the storage layer is obtained. Without encryption, data in snapshots could potentially be exposed through unauthorized access. This creates a risk of data breaches and compliance violations. Following security best practices, we recommend encrypting all database resources and their backups to maintain data confidentiality. **** In the exposure finding, open the resource with the hyperlink. This will open the affected snapshot. You cannot directly encrypt an existing unencrypted snapshot. Instead, create an encrypted copy of the unencrypted snapshot. For detailed instructions, see [DB cluster snapshot copying and Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-copy-snapshot.html) in the *Amazon Aurora User Guide.*.. ### The Amazon RDS DB cluster has a snapshot that is not encrypted at rest Unencrypted Amazon RDS DB cluster snapshots may expose sensitive data if unauthorized access to the storage layer is obtained. Without encryption, data in snapshots could potentially be exposed through unauthorized access. This creates a risk of data breaches and compliance violations. Following security best practices, we recommend encrypting all database resources and their backups to maintain data confidentiality. **1. Create an encrypted copy of the snapshot** In the exposure finding, open the resource with the hyperlink. This will open the affected snapshot. You cannot directly encrypt an existing unencrypted snapshot. Instead, create an encrypted copy of the unencrypted snapshot. For detailed instructions, see [DB cluster snapshot copying and Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-copy-snapshot.html) in the *Amazon Aurora User Guide.*.. ### The Amazon RDS DB instance has an open security group Security groups act as virtual firewalls for your Amazon RDS instances to control inbound and outbound traffic. Open security groups, which allow unrestricted access from any IP address, may expose your database instances to unauthorized access and potential attacks. Following standard security principles, we recommend restricting security group access to specific IP addresses and ports to maintain the principle of least privilege. **Review security group rules and assess current configuration** In the exposure finding, open the resource for the DB instance Security Group. Evaluate which ports are open and accessible from broad IP ranges, such as `(0.0.0.0/0 or ::/0)`. For information about viewing security group details, see [DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) in the *Amazon Elastic Compute Cloud API Reference*. **Modify security group rules** Modify your security group rules to restrict access to specific trusted IP addresses or ranges. When updating your security group rules, consider separating access requirements for different network segments by creating rules for each required source IP range or restricting access to specific ports. To modify security group rules, see [Configure security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) in the *Amazon EC2 User Guide*. To modify the default port of an existing Amazon RDS database instance, see [Modifying the DB cluster by using the console, CLI, and API]() in the *Amazon Aurora User Guide*. ### The Amazon RDS DB instance has IAM database authentication disabled IAM database authentication allows you to authenticate to your Amazon RDS database using IAM credentials instead of database passwords. This provides several security benefits, such as centralized access management, temporary credentials, and elimination of storing database passwords in application code. IAM database authentication allows authentication to database instances with an authentication token instead of a password. As a result, network traffic to and from the database instance is encrypted using SSL. Without IAM authentication, databases typically rely on password-based authentication, which can lead to password reuse and weak passwords. Following security best practices, we recommend enabling IAM database authentication. **Enable IAM database authentication** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. You can enable IAM database authentication in the Database options. For more information, see [Enabling and disabling IAM database authentication ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html)in the *Amazon RDS User Guide*. After enabling IAM authentication, update your DB instances to use IAM authentication instead of password based authentication. ### The Amazon RDS DB instance uses the default admin username Using default usernames (e.g., “admin”, “root”) for DB instances increases security risk as these are widely known and commonly targeted in brute force attacks. Default usernames are predictable and make it easier for unauthorized users to attempt to gain access to your database. With default usernames, attackers only need to obtain passwords rather than needing both to gain access to your database. Following security best practices, we recommend using unique administrator usernames for your database instance to enhance security through obscurity and reduce the risk of unauthorized access attempts. **Configure a unique administrator username** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. Consider what backup frequency, retention period, and lifecycle rules are best for your applications. ### The Amazon RDS DB cluster uses the default admin username Using default usernames (e.g., “admin”, “root”) for DB instances increases security risk as these are widely known and commonly targeted in brute force attacks. Default usernames are predictable and make it easier for unauthorized users to attempt to gain access to your database. With default usernames, attackers only need to obtain passwords rather than needing both to gain access to your database. Following security best practices, we recommend using unique administrator usernames for your database instance to enhance security through obscurity and reduce the risk of unauthorized access attempts. **Configure a unique administrator username** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. You cannot change the administrator username of an existing Amazon RDS DB instance. To create a unique administrator name, you need to create a new DB instance with a custom username and migrate your data. ### The Amazon RDS DB instance has automatic minor version upgrades disabled Automatic minor version upgrades ensure that your Amazon RDS instances automatically receive minor engine version upgrades when they become available. These upgrades often include important security patches and bug fixes that help maintain the security and stability of your database. Your database is at risk of running with known security vulnerabilities that have been fixed in newer minor versions. Without automatic updates, database instances can accumulate security vulnerabilities as new CVEs are discovered. Following security best practices, we recommend enabling automatic minor version upgrades for all Amazon RDS instances. **Enable automatic minor version upgrades** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. You can view automatic minor upgrade settings in the **Maintenance & backups** tab. For more information, see [Automatic minor version upgrades for Amazon RDS for MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html). You can also configure your maintenance window to occur during periods of low database activity. ### The Amazon RDS DB instance has automated backups disabled Automated backups provide point-in-time recovery for your Amazon RDS instances, allowing you to restore your database to any point within your retention period. When automated backups are disabled, you risk losing data in case of malicious deletion, data corruption, or other data loss scenarios. In the event of malicious activity like ransomware attacks, database table deletion, or corruption, the ability to restore to a point in time before the incident reduces the time required to recover from an incident. Following security best practices, we recommend enabling automated backups with an appropriate retention period for all [production databases](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.Enabling.html). ### The Amazon RDS DB instance has deletion protection disabled Database deletion protection is a feature that helps prevent the deletion of your database instances. When deletion protection is disabled, your database can be deleted by any user with sufficient permissions, potentially resulting in data loss or application downtime. Attackers can delete your database, leading to service disruption, data loss, and increased recovery time. Following security best practices, we recommend enabling deletion protection for your RDS DB instances to prevent malicious deletion. **Enable delete protection for your Amazon RDS DB cluster** In the exposure finding, open the resource with the hyperlink. This will open the affected DB cluster. ### The Amazon RDS DB cluster has deletion protection disabled Database deletion protection is a feature that helps prevent the deletion of your database instances. When deletion protection is disabled, your database can be deleted by any user with sufficient permissions, potentially resulting in data loss or application downtime. Attackers can delete your database, leading to service disruption, data loss, and increased recovery time. Following security best practices, we recommend enabling deletion protection for your RDS DB clusters to prevent malicious deletion. **Enable delete protection for your Amazon RDS DB cluster** In the exposure finding, open the resource with the hyperlink. This will open the affected DB cluster. ### The Amazon RDS DB instance uses the default port for the database engine Amazon RDS instances that use default ports for database engines may face increased security risks, as these default ports are widely known and are often targeted by automated scanning tools. Modifying your DB instance to use non-default ports adds an additional layer of security through obscurity, making it more difficult for unauthorized users to perform automated or targeted attacks on your database. Default ports are commonly scanned for by unauthorized persons, and may cause your DB instance to be targeted. Following security best practices, we recommend changing the default port to a custom port to reduce the risk of automated or targeted attacks. **** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. **Update application connection strings** After changing the port, update all applications and services that connect to your Amazon RDS instance to use the new port number. ### The Amazon RDS DB instance is not covered by a backup plan AWS Backup is a fully managed backup service that centralizes and automates the backup of data across AWS services. If your DB instance is not covered by a backup plan, you risk losing data in case of malicious deletion, data corruption, or other data loss scenarios. In the event of malicious activity like ransomware attacks, database table deletion, or corruption, the ability to restore to a point in time before the incident reduces the time required to recover from an incident. Following security best practices, we recommend including your Amazon RDS instances in a backup plan to ensure data protection. **Create and assign a backup plan for your DB instance** In the exposure finding, open the resource with the hyperlink. This will open the affected DB instance. Consider what backup frequency, retention period, and lifecycle rules are best for your applications. # Remediating exposures for Amazon S3 buckets AWS Security Hub can generate exposure findings for Amazon Simple Storage Service (S3) buckets. On the Security Hub console, the Amazon S3 bucket involved in an exposure finding and its identifying information are listed in the **Resources** section of the finding details. Programmatically, you can retrieve resource details with the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html) operation of the Security Hub CSPM API. After identifying the resource involved in an exposure finding, you can delete the resource if you don't need it. Deleting a nonessential resource can reduce your exposure profile and AWS costs. If the resource is essential, follow these recommended remediation steps to help mitigate the risk. The remediation topics are divided based on the type of trait. A single exposure finding contains issues identified in multiple remediation topics. Conversely, you can address an exposure finding and bring down its severity level by addressing just one remediation topic. Your approach to risk remediation depends on your organizational requirements and workloads. **Note** The remediation guidance provided in this topic might require additional consultation in other AWS resources. **Contents** + [Misconfiguration traits for Amazon S3 buckets](#misconfiguration) + [The Amazon S3 bucket has versioning disabled](#versioning-disabled) + [The Amazon S3 bucket has Object Lock disabled](#object-lock-disabled) + [Amazon S3 bucket is not encrypted at rest with AWS KMS keys](#sse-kms-not-used) + [Multi-factor authentication (MFA) delete is disabled on a versioned Amazon S3 bucket](#mfa-delete-disabled) + [The Amazon S3 bucket allows principals from other AWS accounts to modify bucket permissions](#external-aws-access-allowed) + [Reachability traits for Amazon S3 buckets](#reachability) + [The Amazon S3 bucket has public read access](#public-read-allowed) + [The Amazon S3 bucket has public write access](#public-write-allowed) + [Sensitive data traits for Amazon S3 buckets](#sensitive-data) + [Sensitive data traits for Amazon S3 buckets](#sensitive-data-present) ## Misconfiguration traits for Amazon S3 buckets Here are misconfiguration traits for Amazon S3 buckets and suggested remediation steps. ### The Amazon S3 bucket has versioning disabled Amazon S3 Versioning helps you keep multiple variants of an object in the same bucket. When versioning is disabled, Amazon S3 stores only the most recent version of each object, meaning that if objects are accidentally or maliciously deleted or overwritten, they cannot be recovered. Versioning-enabled buckets provide protection against accidental deletion, application failures, and security incidents like ransomware attacks, where unauthorized modification or deletion of data could occur. Following security best practices, we recommend enabling versioning for buckets containing important data that would be difficult or impossible to recreate if lost. 1. **Enable versioning** – To enable Amazon S3 Versioning on a bucket, see [Enabling versioning on buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html) in the *Amazon Simple Storage Service User Guide*. When enabling versioning, consider implementing lifecycle rules to manage storage, as versioning will maintain multiple copies of objects. ### The Amazon S3 bucket has Object Lock disabled Amazon S3 Object Lock provides a write-once-read-many (WORM) model for Amazon S3 objects, preventing them from being deleted or overwritten for a fixed period or indefinitely. When Object Lock is disabled, your objects could be vulnerable to accidental or malicious deletion, modification, or encryption by ransomware. Object Lock is especially important for compliance with regulatory requirements that demand immutable data storage and for protection against sophisticated threats like ransomware that may attempt to encrypt your data. By enabling Object Lock, you can enforce retention policies as an added layer of data protection and create an immutable backup strategy for your critical data. Following security best practices, we recommend you enable Object Lock to prevent malicious modification of your objects. 1. Note that Object Lock can only be enabled when creating a new bucket, so you will need to create a new bucket with Object Lock enabled. For large migrations, consider using Batch Operations to copy objects to the new bucket. Before you lock any objects, you must also enable Amazon S3 Versioning and Object Lock on a bucket. Since Object Lock can only be enabled on new buckets, you’ll need to migrate existing data to a new bucket with Object Lock enabled. **Configure Amazon S3 Object Lock** – For information about how to configure Object Lock on a bucket, see [Configuring Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html) in the *Amazon Simple Storage Service User Guide*. After setting up Object Lock, choose an appropriate retention mode according to your environment. ### Amazon S3 bucket is not encrypted at rest with AWS KMS keys Amazon S3 applies server-side encryption with Amazon S3 managed keys as the default level of encryption for all new buckets. While Amazon S3 managed keys provides strong encryption protection, it doesn't offer the same level of access control and audit capabilities as AWS Key Management Service keys. When using KMS keys, access to objects requires permissions to both the Amazon S3 bucket and the KMS key that encrypted the object. This is particularly important for sensitive data where you need granular control over who can access the encrypted objects and comprehensive audit logging of encryption key usage. Following security best practices, we recommend using KMS keys to encrypt buckets containing sensitive data or for environments with strict compliance requirements. 1. **Configure Amazon S3 bucket key** To configure a bucket to use an Amazon S3 bucket key for new objects, see [Configuring your bucket to use an Amazon S3 Bucket Key with SSE-KMS for new objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-bucket-key.html) in the *Amazon Simple Storage Service User Guide*. For information about how to encrypt an existing object, see [Encrypting objects with Amazon S3 Batch Operations](https://aws.amazon.com/blogs/storage/encrypting-objects-with-amazon-s3-batch-operations/) in the AWS Storage Blog. When implementing AWS KMS encryption, consider the following: + **Key management** – Decide on whether to use an AWS managed key or a customer managed key (CMK). CMKs offer customers full control over the lifecycle and usage of their keys. For more information on the difference between these two types of keys, see [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt) in the *AWS Key Management Service Developer Guide*. + **Key rotation** – For additional security measures, enable automatic key rotation for your KMS keys. For more information, see [Enable automatic key rotation]() in the *AWS Key Management Service Developer Guide*. ### Multi-factor authentication (MFA) delete is disabled on a versioned Amazon S3 bucket Multi-factor authentication (MFA) delete provides an additional layer of security for your Amazon S3 bucket. It requires multi-factor authentication for destructive Amazon S3 operations. When MFA delete is disabled, users with appropriate permissions can permanently delete object versions or suspend versioning on your bucket without additional authentication challenges. Enabling MFA delete helps protect against unauthorized or accidental deletion of your data, providing enhanced protection against ransomware attacks, insider threats, and operational errors. MFA delete is particularly valuable for buckets containing critical or compliance-sensitive data that must be protected from unauthorized deletion. Following security best practices, we recommend enabling MFA for your Amazon S3 buckets. 1. **Review MFA types** AWS supports the following [MFA types](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html#id_credentials_mfa-types). Although authentication with a physical device typically provides more stringent security protection, using any type of MFA is more secure than having MFA disabled. 1. **Enforce MFA at the resource policy level** Use the `aws:MultiFactorAuthAge` condition key in a bucket policy to require MFA for sensitive operations. For more information, see see [ Requiring MFA](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-MFA) in the *Amazon Simple Storage Service User Guide*. 1. **Enable MFA** To enable MFA delete, first, ensure that versioning is enabled on your Amazon S3 bucket. MFA delete is only supported on buckets that have versioning enabled. For information about how to enable Amazon S3 versioning, see [Enabling versioning on buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html) in the *Amazon Simple Storage Service User Guide*. MFA delete cannot be enabled through the Amazon S3 console. You must use the Amazon S3 API or the AWS CLI. For more information, see [Configuring MFA delete](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html) in the *Amazon Simple Storage Service User Guide*. ### The Amazon S3 bucket allows principals from other AWS accounts to modify bucket permissions Amazon S3 bucket policies control access to buckets and objects. When bucket policies allow principals from other AWS accounts to modify bucket permissions, unauthorized users can reconfigure your bucket. If external principal credentials are compromised, unauthorized users can gain control over your bucket, leading to data breaches or service disruptions. Following standard security principles, AWS recommends that you restrict permission management actions to trusted principals only. 1. **Review and identify bucket policies** In the exposure, identify the Amazon S3 bucket in the ARN field. In the Amazon S3 console, select the bucket, and navigate to the **Permissions** tab to review the bucket policy. Review the permissions policy attached to the bucket. Look for policy statements that grant actions like `s3:PutBucketPolicy, s3:PutBucketAcl, s3:DeleteBucketPolicy, s3:* ` or policy statements that allow access to principals outside your account, as denoted in the principal statement. 1. **Modify the bucket policy** Modify the bucket policy to remove or restrict actions granted to other AWS accounts: + Remove policy statements that grant external accounts permission management actions. + If cross-account access is required, replace broad permissions `(s3:*)` with specific actions that don't include bucket permission management. For information about modifying a bucket policy, see [Adding a bucket policy by using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) in the *Amazon Simple Storage Service User Guide*. ## Reachability traits for Amazon S3 buckets Here are reachability traits for Amazon S3 buckets and suggested remediation steps. ### The Amazon S3 bucket has public read access Amazon S3 buckets with public read access allow anyone on the internet to view the contents of your bucket. While this may be necessary for publicly accessible websites or shared resources, it can create security risks if the bucket contains sensitive data. Public read access can lead to unauthorized viewing and downloading, which can lead to data breaches if sensitive data is stored in those buckets. Following standard security principles, AWS recommends restricting access to Amazon S3 buckets to necessary users and systems. 1. **Block public access at the bucket level** Amazon S3 provides Block Public Access settings that can be configured at both the bucket and account levels to prevent public access regardless of bucket policies or ACLs. For more information, see [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) in the *Amazon Simple Storage Service User Guide*. After blocking public access, review your bucket access control configuration to make sure it aligns with your access requirements. Then review your Amazon S3 bucket policy to explicitly define who can access your bucket. For examples of bucket policies see [Examples of Amazon S3 bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) in the *Amazon Simple Storage Service User Guide*. 1. **Alternative access methods** If public read access is required, consider these more secure alternatives: + **CloudFront** – Use CloudFront with an Origin Access Identity (OAI) or Origin Access Control (OAC) to allow read access from a private Amazon S3 bucket. This alternative restricts direct access to your Amazon S3 bucket while allowing content to be publicly accessible through CloudFront. For more information, see [Restricting access to an Amazon S3 origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) in the *Amazon CloudFront Developer Guide*. + **Presigned URLs** – Use presigned URLs for temporary access to specific objects. For more information, see [Sharing objects with presigned URLs](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) in the *Amazon CloudFront Developer Guide*. ### The Amazon S3 bucket has public write access Amazon S3 buckets with public write access allow anyone on the internet to upload, modify, or delete objects in your bucket. This creates significant security risks, including the potential for someone to upload malicious files, modify existing files, and delete data. Public write access creates security vulnerabilities that can be exploited by attackers. Following standard security principles, AWS recommends restricting write access to your Amazon S3 buckets to only necessary users and systems. 1. **Block public access at the account and bucket level** Amazon S3 provides block public access settings that can be configured at both the bucket and account levels to prevent public access regardless of bucket policies or ACLs. For more information, see [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) in the *Amazon Simple Storage Service User Guide*. 1. **Modify bucket policies** For a more granular approach to remove public write access, review the bucket policy. You can look for `s3:PutObject`, `s3:DeleteObject`, or `s3:*`. For more information on managing bucket policies, see [Bucket policies for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) in the *Amazon Simple Storage Service User Guide*. 1. **Alternative access methods** If public read access is required, consider these more secure alternatives: + **CloudFront** – Use CloudFront with an Origin Access Identity (OAI) or Origin Access Control (OAC) to allow read access from a private Amazon S3 bucket. This alternative restricts direct access to your Amazon S3 bucket while allowing content to be publicly accessible through CloudFront. For more information, see [Restricting access to an Amazon S3 origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) in the *Amazon CloudFront Developer Guide*. + **Presigned URLs** – Use presigned URLs for temporary access to specific objects. For more information, see [Sharing objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) in the *Amazon Simple Storage Service User Guide*. ## Sensitive data traits for Amazon S3 buckets Here are the sensitive data traits for Amazon S3 buckets and suggested remediation steps. ### Sensitive data traits for Amazon S3 buckets When Macie identifies sensitive data in your Amazon S3 buckets, it indicates potential security and compliance exposures that require immediate attention. Sensitive data can include: + Credentials + Personally identifiable information + Financial information + Confidential content requiring protection If sensitive data is exposed through misconfiguration or unauthorized access, it could lead to compliance violations, data breaches, identity theft, or financial loss. Following security best practices, AWS recommends proper classification of data and continuous monitoring of sensitive data in your Amazon S3 buckets. **Implement controls for sensitive data** In the exposure finding, choose the **Open resource **. Review the type of sensitive data detected and its location in the bucket. For help interpreting Macie findings, see [Types of Macie findings](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) in the *Amazon Macie User Guide*. Based on the type of sensitive data discovered, implement the appropriate security controls: + **Restrict access to the bucket** – Review bucket permissions to make sure they follow the principle of least privilege. Use IAM policies, bucket policies, and ACLs to restrict access. For more information, see [Identity and Access Management for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-iam.html) in the *Amazon Simple Storage Service User Guide*. + **Enable server-side encryption** – Enable server-side encryption with KMS keys keys for additional protection. For more information, see [Using server-side encryption with AWS KMS keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) in the *Amazon Simple Storage Service User Guide*. + **Use AWS Glue DataBrew** – Use Glue DataBrew for data preparation and cleaning. For more information, see[What is AWS Glue DataBrew](https://docs.aws.amazon.com/databrew/latest/dg/what-is.html) in the *AWS Glue DataBrew Developer Guide*. # Automations in Security Hub Security Hub includes features that automatically modify and take action on findings based on your specifications. Security Hub currently supports the following types of automations: + **Automation rules** – Automatically update and suppress findings, as well as send findings to ticketing tools, in near real time based on defined criteria. + **Automated response and remediation** – Create custom Amazon EventBridge rules that define automatic actions to take against specific findings and insights. Automation rules are helpful when you want to automatically update finding fields in the Open Cybersecurity Schema Framework (OCSF). For example, you can use an automation rule to update the severity level of findings for resources with a specific tag. Using the automation rule eliminates the need to manually update the severity level of each finding related to the specific tag. You can configure automation rules to create tickets in tools like Jira Cloud and ServiceNow when findings match specific attributes. This allows findings to be created into tickets as soon as they are sent to Security Hub or created in Security Hub. EventBridge rules are helpful when you want to take actions outside of Security Hub CSPM with regards to specific findings or send specific findings to third-party tools for remediation or additional investigation. The rules can be used to trigger supported actions, such as invoking an AWS Lambda function or notifying an Amazon Simple Notification Service (Amazon SNS) topic about a specific finding. Automation rules take effect before EventBridge rules are applied. That is, automation rules are triggered and update a finding before EventBridge receives the finding. EventBridge rules then apply to the updated finding. # Automation rules in Security Hub With Security Hub, you can automate tasks like updating finding details and creating tickets for third-party integrations. ## Automation rules and AWS Regions Automation rules can be created in one AWS Region and then applied in all configured AWS Regions. When using region aggregation, you can only create rules in the home region. When creating rules in the home region, any rule you define is applied to all linked regions, unless your rule criteria excludes a specific linked region. You must create an automation rule for any region that's not a linked region. ## Rule actions and criteria Automation rules in Security Hub use criteria to reference OCSF attributes in Security Hub findings. For example, the filters supported for the `Criteria` parameter in [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateAutomationRuleV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateAutomationRuleV2.html) match the filters supported for the `Criteria` parameter in [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_GetFindingsV2.html). This means filters used in automation rules can be used to get findings. Security Hub supports the following OCSF fields for automation rule criteria. | OCSF field | Console filter value | Filter operators | Field type | | --- | --- | --- | --- | | activity\$1name | Activity name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | class\$1name | Finding class name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | cloud.account.uid | Account ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | cloud.provider | Cloud provider | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | cloud.region | Region | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | comment | Comment | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | compliance.assessments.category | Assessment category | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | compliance.assessments.name | Assessment name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | compliance.control | Security control ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | compliance.standards | Applicable standards | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | compliance.status | Compliance status | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.desc | Finding description | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.related\$1events.product.uid | Related findings product ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.related\$1events.title | Related findings title | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.related\$1events.uid | Related findings ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.src\$1url | Source URL | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.types | Finding type | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.uid | Provider ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | metadata.product.feature.uid | Generator ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | metadata.product.name | Product name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | metadata.product.uid | Product ARN | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | metadata.product.vendor\$1name | Company name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | metadata.uid | Finding ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | remediation.desc | Recommendation text | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | remediation.references | Recommendation URL | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | resources.cloud\$1partition | Resource partition | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | resources.name | Resource name | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | resources.region | Resource region | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | resources.type | Resource type | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | resources.uid | Resource ID | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | severity | Severity | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | status | Status | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | vulnerabilities.fix\$1coverage | Software vulnerabilities coverage | EQUALS, PREFIX, NOT\$1CONTAINS, NOT\$1EQUALS, PREFIX\$1NOT\$1EQUALS | String | | finding\$1info.first\$1seen\$1time\$1dt | First observed at | Start, End, DateRange | Date (formatted as 2022-12-01T21:47:39.269Z) | | finding\$1info.last\$1seen\$1time\$1dt | Last observed at | Start, End, DateRange | Date (formatted as 2022-12-01T21:47:39.269Z) | | finding\$1info.modified\$1time\$1dt | Updated at | Start, End, DateRange | Date (formatted as 2022-12-01T21:47:39.269Z) | | compliance.assessments.meets\$1criteria | Compliance assessment meets criteria | True, False | Boolean | | vulnerabilities.is\$1exploit\$1available | Software vulnerabilities with exploit available | True, False | Boolean | | vulnerabilities.is\$1fix\$1available | Software vulnerabilities with fix available | True, False | Boolean | | activity\$1id | Activity ID | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | compliance.status\$1id | Compliance status ID | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | confidence\$1score | Confidence | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | severity\$1id | Severity ID | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | status\$1id | Status ID | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | finding\$1info.related\$1events\$1count | Related findings count | Eq (equal-to), Gte (greater-than-equal), Lte (less-than-equal) | Number | | resources.tags | Resource tags | EQUALS | Map | For criteria labeled as string fields, using different filter operators on the same field affects the evaluation logic. For more information, see [StringFilter](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_StringFilter.html) in the *Security Hub API Reference*. Each criterion supports a maximum number of values that can be used to filter matching findings. For the limits of each criterion, see [OcsfFindingFilters](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_OcsfFindingFilters.html) in the *Security Hub API Reference* **OCSF fields that can be updated** The following are the OCSF fields that can be updated using automation rules. + `Comment` + `SeverityId` + `StatusId` ## How automation rules evaluate findings An automation rule evaluates new and updated findings that Security Hub generates or ingests after you create the rule. Automation rules evaluate original, provider-supplied findings. Providers can supply new findings and update existing findings through their integration with Security Hub. Rules aren't triggered when you update finding fields after rule creation through the `BatchUpdateFindingsV2` operation. If you create an automation rule and make a `BatchUpdateFindingsV2` update that both affect the same finding field, the last update sets the value for that field. Take the following example: You use `BatchUpdateFindingsV2` to update the `Status` field of a finding from `New` to `In Process`. If you call `GetFindingsV2`, the `Status` field now has a value of `In Process`. You create an automation rule that changes the `Status` field of the finding from `New` to `Suppressed` (recall that rules ignore updates made with `BatchUpdateFindingsV2`). The finding provider updates the finding and changes the `Status` field to `New`. If you call `GetFindingsV2`, the `Status` field now has a value of `Suppressed` because the automation rule was applied, and the rule was the last action taken on the finding. When you create or edit a rule on the Security Hub console, the console displays a preview of findings that match the rule criteria. Whereas automation rules evaluate original findings sent by the finding provider, the console preview reflects findings in their final state as they would be shown in a response to the `GetFindingsV2` API operation (that is, after rule actions or other updates are applied to the finding). ## How automation rules are ordered Each automation rule is assigned a rule order. This determines the order in which Security Hub applies your automation rules, and becomes important when multiple rules relate to the same finding or finding field. When multiple rule actions relate to the same finding or finding field, the rule with the highest numerical value for rule order applies last and has the ultimate effect. When you create a rule in the Security Hub console, Security Hub automatically assigns rule order based on the order of rule creation. The first rule you create will have a rule order of 1. When more than one rule exists each subsequently created rule will have the next highest available numerical value for rule order. When you create a rule through [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateAutomationRuleV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateAutomationRuleV2.html) API or AWS CLI, Security Hub applies the rule with the lowest numerical value for `RuleOrder` first. It then applies subsequent rules in ascending order. If multiple findings have the same `RuleOrder`, Security Hub applies a rule with an earlier value for the `UpdatedAt` field first (that is, the rule that was most recently edited applies last). You can modify rule order at any time. **Example of rule order**: **Rule A (rule order is `1`)**: + Rule A criteria + `ProductName` = `Security Hub CSPM` + `Resources.Type` is `S3 Bucket` + `Compliance.Status` = `FAILED` + `RecordState` is `NEW` + `Workflow.Status` = `ACTIVE` + Rule A actions + Update `Confidence` to `95` + Update `Severity` to `CRITICAL` + Update `Comment` to `This needs attention` **Rule B (rule order is `2`)**: + Rule B criteria + `AwsAccountId` = `123456789012` + Rule B actions + Update `Severity` to `INFORMATIONAL` First, Rule A actions apply to Security Hub findings that match Rule A criteria. Then, Rule B actions apply to Security Hub findings with the specified account ID. In this example, since Rule B applies last, the end value of `Severity` in findings from the specified account ID is `INFORMATIONAL`. Based on the Rule A action, the end value of `Confidence` in matched findings is `95`. ## Third-party integrations You can use automation rules to create tickets for integrations with Jira Cloud and ServiceNow ITSM. For more information, see [Creating a rule for a third-party integration](https://docs.aws.amazon.com/securityhub/latest/userguide/securithub-v2-automation-rules-create.html#integration). ## Scenarios where automation rules do not work The following are scenarios where automation rules do not work. + The standalone account becomes a member of an organization with a delegated admin + The organization management account removes the delegated admin and sets a new delegated admin + The aggregator configuration for the delegated admin or standalone account changes when an unlinked region is made a linked region During these scenarios, a member of an organization can manage automation rules with list, get, and delete operations in the AWS CLI or APIs. When an unlinked region is made a linked region, the delegated admin or standalone account can manage resources in a linked region with list, get, and delete operations. # Creating automation rules in Security Hub This topic describes how to create automation rules. You can use automation rules to update details for a finding or create a ticket for a third-party integration. You must create automation rules individually and in the AWS Region where you want them applied. However, if you create an automation rule in an aggregation region, it will be applied in all regions. Otherwise, if you create an automation rule in a non-linked region, it will be applied just in that region. ## Creating a rule that updates finding details The following procedure describes how to create a rule that updates finding details. 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Choose **Create rule**. 1. Under **Details**, enter a name for your automation rule. 1. (Optional) Enter a description for your automation rule. 1. Under **Actions**, choose **Update findings details**. You can search for criteria and add criteria in the search bar. To check if any findings match your criteria, choose **Preview matching findings**. 1. Under **Update finding details**, choose at least one finding detail to update when a finding matches your criteria. You can choose **Severity**, **Status**, or **Comment**. 1. Under **Rule settings**, select **Enabled** or **Disabled**. If you select **Enabled**, the automation rule is enabled and will process new findings. If you select **Disabled**, the automation rule is disabled and will not process any findings. 1. (Optional) Under **Tags**, choose **Add new tag** to enter a key-value pair to be applied to your automation rule. 1. Choose **Create rule**. ## Creating a rule for a third-party integration The following procedure describes how to create a rule that creates a ticket for a third-party integration. For information about the integrations Security Hub CSPM supports, see [Third-party integrations for Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-adv-catalog-integrations.html). 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Choose **Create rule**. 1. Under **Details**, enter a name for your automation rule. 1. (Optional) Enter a description for your automation rule. 1. Under **Actions**, choose **Create ticket**. You can search for criteria and add criteria in the search bar. To check if any findings match your criteria, choose **Preview matching findings**. 1. Under **Create a ticket**, choose an IT ticketing integration from the dropdown, and then choose **Add integration**. 1. Under **Rule settings**, select **Enabled** or **Disabled**. If you select **Enabled**, the automation rule is enabled and will process new findings. If you select **Disabled**, the automation rule is disabled and will not process any findings. 1. (Optional) Under **Tags**, choose **Add new tag** to enter a key-value pair to be applied to your automation rule. 1. Choose **Create rule**. # Viewing details for automation rules in Security Hub This topic describes how to view details for automation rules. You can view the following details for an automation rule: + Name and description + Actions and criteria + Rule status and existing findings + Tags **To view details for an automation rule** 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. This screen shows all of your created automation rules. 1. Select the automation rule you want to view. Choose **View details**. Alternatively, you can choose the name of the automation rule you want to view. # Updating the rule order in Security Hub This topic describes how to update the rule order for automation rules in the console. If you want to edit the criteria for an automation rule, see [Editing automation rules in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securithub-v2-automation-rules-edit.html). You cannot update the rule order for one automation rule without updating the rule order for every automation rule. For example, you have four automation rules: Rule A (1), Rule B (2), Rule C (3), and Rule D (4). You want Rule D to be applied first. To do this, you change its number from 4 to 1. As a result, Rule A gets 2, Rule B gets 3, and Rule C gets 4. **To update the rule order for your automation rules** 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Select the automation rule you want to edit. Under **Order**, choose the pencil icon next to the order number. Use the arrows to determine the new order number. Choose the **✓** icon to confirm. Choose the **X** icon to cancel. Alternatively, you can choose **Change order** to move the automation rule down, up, or to the top of the list. # Disabling automation rules in Security Hub This topic describes how to disable automation rules. When you disable automation rules, Security Hub stops applying them. You can disable automation rules any time and in the AWS Region where you created them. **To disable a rule** 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Select the automation rule you want to disable. Under **Status**, choose the pencil icon next to **Enabled**. Choose the dropdown, and then choose **Disabled**. Choose the **✓** icon to confirm. Choose the **X** icon to cancel. You can also choose **Disable** from the **Actions** dropdown. # Enabling an automation rule in Security Hub This topic describes how to enable automation rules. When you enable automation rules, Security Hub resumes applying them. You can enable automation rules any time and in the AWS Region where you created them. **To enable a rule** 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Select the automation rule you want to enable. Under **Status**, choose the pencil icon next to **Disabled**. Choose the dropdown, and then choose **Enabled**. Choose the **✓** icon to confirm. Choose the **X** icon to cancel. You can also choose **Enable** from the **Actions** dropdown. # Duplicating automation rules in Security Hub This topic describes how to duplicate automation rules. Duplicating automation rules can help you save time if you want to avoid creating them from scratch. When you duplicate automation rules, you can update details, actions, rule settings, and tags. You can edit automation rules in the AWS Region where you created them. **To duplicate a rule** 1. Sign in to your AWS account, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **Management**, and choose **Automations**. 1. Select the automation rule that you want to duplicate. Then choose **Actions**, and then choose **Duplicate**. 1. Make and review your changes, and then choose **Create rule**. # Editing automation rules in Security Hub This topic describes how to edit automation rules. You can edit automation rules in the AWS Region where you created them. You can edit the following for automation rules: + Name and description + Actions + Rule settings You cannot edit tags for automation rules. **To edit a rule** 1. Sign in to your AWS account. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, under **Management**, choose **Automations**. 1. Select the automation rule that you want to edit. Choose **Actions**, and then choose **Edit**. 1. Make and review your edits. 1. Choose **Save changes**. # Deleting automation rules in Security Hub This topic describes how to delete automation rules. You can delete automation rules in the AWS Region where you created them. **To delete a rule** 1. Sign in to your AWS account, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **Management**, and then choose **Automations**. 1. Select the automation rule that you want to delete. Choose **Actions**, and then choose **Delete**. 1. Choose **Delete**. # Automation rules in EventBridge You can use automation rules in Amazon EventBridge to respond to Security Hub findings. Security Hub sends findings to EventBridge as events in near real time. You can write basic rules that indicate what automated actions to take when an events match the rules. Actions that can be automatically triggered include the following: + Configuring an API destination in EventBridge. + Invoking Amazon EC2 run commands + Invoking Lambda functions + Invoking Step Functions state machines + Notifying an Amazon SNS topic or an Amazon SQS queue + Relaying events to Kinesis Data Streams + Sending a finding to a third-party ticketing, chat, SIEM, or incident response and management tool + [Sending an event to an EventBridge bus in another AWS account](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus-example-policy-cross-account-custom-bus-source.html) Security Hub sends new findings and updated findings to EventBridge as events. Then you configure EventBridge rules to respond to each Security Hub event. For more information, see [What is EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) in the *EventBridge User Guide*. **Note** If you have EventBridge rules defined for findings in Security Hub CSPM, the rules could overlap with rules defined for Security Hub. To avoid sending duplicate findings, evaluate the rules you have defined for Security Hub CSPM to determine if they overlap with rules you are have defined for Security Hub. Where applicable disable any Security Hub CSPM rules that are replaced by Security Hub rules. **Note** As a best practice, make sure users with permission to access EventBridge use AWS Identity and Access Management policies that grant the minimum required permissions. For more information, see [EventBridge and AWS Identity and Access Management](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-iam.html) in the *EventBridge User Guide*. # EventBridge event types Security Hub uses the following Amazon EventBridge event types to integrate with EventBridge. On the EventBridge dashboard for Security Hub, **All Events** includes all of these event types. ## Findings Imported V2 Security Hub automatically sends all new findings and all updates to existing findings to EventBridge as **Findings Imported V2** events. Each **Findings Imported V2** event contains a single finding. Every finding that's imported and every finding updated through a [https://docs.aws.amazon.com/](https://docs.aws.amazon.com/) request triggers a **Findings Imported V2** event. For administrator accounts, the event feed in EventBridge includes events for findings from both their account and from their member accounts. In an aggregation Region, the event feed includes events for findings from the aggregation Region and the linked Regions. Cross-Region findings are included in the event feed in near real time. You can define rules in EventBridge that automatically route findings to a remediation workflow, third-party tool, or [other supported EventBridge target](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). The rules can include filters that only apply the rule if the finding has specific attribute values. You use this method to automatically send all findings, or all findings that have specific characteristics, to a response or remediation workflow. **Note** Security Hub and Security Hub CSPM both send findings to EventBridge under the source of `aws.securityhub`. Ensure that your EventBridge rules use the detail-type that is specific to Security Hub in order to avoid duplicate notifications related to Security Hub CSPM findings. # EventBridge event formats The **Findings Imported V2** event type uses the following event format. **Example** This format is used when Security Hub sends an event to EventBridge. ``` { "version":"0", "id":"CWE-event-id", "detail-type":"Findings Imported V2", "source":"aws.securityhub", "account":"111122223333", "time":"2019-04-11T21:52:17Z", "region":"us-west-2", "resources":[ "e51603d1054aad9d9f498d82d6e81acf4cf6bc88140e8ad2273123c73b81084" ], "detail":{ "findings": [{ }] } } ``` Each event sends a single finding. `` is the content in JSON of the finding sent by the event. For a complete list of finding attributes, see [OCSF findings in Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-adv-ocsf-findings.html). # Configuring rules for EventBridge You can create a rule in Amazon EventBridge that defines an action to take when a **Findings Imported V2** event is received. **Findings Imported V2** events are triggered by updates through [https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_BatchUpdateFindingsV2.html](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_BatchUpdateFindingsV2.html). Each rule contains an event pattern, which identifies the events that trigger the rule. The event pattern always contains the event source (`aws.securityhub`) and the event type (**Findings Imported V2**). The event pattern can also specify filters to identify the findings that the rule applies to. The event rule then identifies the rule targets. The targets are the actions to take when EventBridge receives a **Findings Imported V2** event and the finding matches the filters. The instructions provided here use the EventBridge console. When you use the console, EventBridge automatically creates the required resource-based policy that enables EventBridge to write to Amazon CloudWatch Logs. You can also use the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutRule.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutRule.html) operation of the EventBridge API. However, if you use the EventBridge API, then you must create the resource-based policy. For information about the required policy, see [CloudWatch Logs permissions](https://docs.aws.amazon.com/eventbridge/latest/userguide/resource-based-policies-eventbridge.html#cloudwatchlogs-permissions) in the *Amazon EventBridge User Guide*. ## Format of the event pattern The format of the event pattern for **Findings Imported V2** events is as follows: ``` { "source": [ "aws.securityhub" ], "detail-type": [ "Findings Imported V2" ], "detail": { "findings": { } } } ``` + `source` identifies Security Hub as the service that generates the event. + `detail-type` identifies the type of event. + `detail` is optional and provides the filter values for the event pattern. If the event pattern does not contain a `detail` field, then all findings trigger the rule. You can filter the findings based on any finding attribute. For each attribute, you provide a comma-separated array of one or more values. ``` "": [ "", ""] ``` If you provide more than one value for an attribute, then those values are joined by `OR`. A finding matches the filter for an individual attribute if the finding has any of the listed values. For example, if you provide both `INFORMATIONAL` and `LOW` as values for `Severity.Label`, then the finding matches if it has a severity label of either `INFORMATIONAL` or `LOW`. The attributes are joined by `AND`. A finding matches if it matches the filter criteria for all of the provided attributes. When you provide an attribute value, it must reflect the location of that attribute within the AWS Open Cybersecurity Schema Framework (OCSF) structure. In the following example, the event pattern provides filter values for `ProductArn` and `Severity.Label`, so a finding matches if it is generated by Amazon Inspector and it has a severity label of either `INFORMATIONAL` or `LOW`. ``` { "source": [ "aws.securityhub" ], "detail-type": [ "Findings Imported V2" ], "detail": { "findings": { "ProductArn": ["arn:aws:securityhub:us-east-1::product/aws/inspector"], "Severity": { "Label": ["INFORMATIONAL", "LOW"] } } } } ``` ## Creating an event rule You can use a predefined event pattern or a custom event pattern to create a rule in EventBridge. If you select a predefined pattern, EventBridge automatically fills in `source` and `detail-type`. EventBridge also provides fields to specify filter values for the following finding attributes: + `cloud.account.uid` + `compliance.status` + `metadata.product.name` + `resources.uid` + `severity` + `status` **To create an EventBridge rule (console)** 1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/). 1. Using the following values, create an EventBridge rule that monitors finding events: + For **Rule type**, choose **Rule with an event pattern**. + Choose how to build the event pattern. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-cwe-event-rules.html) + For **Target types**, choose **AWS service**, and for **Select a target**, choose a target such as an Amazon SNS topic or AWS Lambda function. The target is triggered when an event is received that matches the event pattern defined in the rule. For details about creating rules, see [Creating Amazon EventBridge rules that react to events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) in the *Amazon EventBridge User Guide*. **Note** If you have EventBridge rules defined for findings in Security Hub CSPM, the rules could overlap with rules defined for Security Hub. To avoid sending duplicate findings, evaluate the rules you have defined for Security Hub CSPM to determine if they overlap with rules you are have defined for Security Hub. Where applicable disable any Security Hub CSPM rules that are replaced by Security Hub rules. # Third-party integrations for Security Hub You can enhance your security posture with third-party integrations for AWS Security Hub. With this feature you can enable integrations that consume findings from Security Hub, allowing you to incorporate your operational, investigation, and response tools with Security Hub. Currently Security Hub supports integration with Jira Cloud and ServiceNow. **Topics** + [Integrations for AWS Security Hub Jira Cloud](jiracloud.md) + [Integrations for ServiceNow](servicenow.md) + [KMS key policies for Security Hub ticketing integrations](securityhub-v2-integrations-key-policy.md) + [Testing configured ticketing integrations](securityhub-v2-test-ticket-integration.md) # Integrations for AWS Security Hub Jira Cloud This topic describes how to integrate with Jira Cloud. Before completing any of the procedures in this topic, you must purchase a Jira Cloud subscription plan. For information about subscription plans, see [Pricing](https://www.atlassian.com/software/jira/pricing) on the Atlassian website. This integration allows you to send Security Hub findings to Jira Cloud, manually or automatically, so you can manage them as part of your operational workflows. For example, you can assign ownership to issues that need investigation and remediation. For accounts in an organization, only the delegated administrator can configure an integration. The delegated administrator can manually use the create ticket feature for any member account findings. Additionally, the delegated administrator can use [automation rules](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-v2-automation-rules.html) to automatically create tickets for any findings associated with member accounts. When defining an automation rule, the delegated administrator can set criteria, which can include all member accounts or specific member accounts. For information about setting a delegated administrator, see [Setting a delegated administrator account in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-v2-set-da.html). For accounts not in an organization, all aspects of this feature are available. ## Prerequisites Prior to connecting Security Hub with your Jira Cloud environment you must ensure that the following configuration steps are done in your Jira environment. + Install the AWS Security Hub for Jira cloud app. + Have at least one software development project that is company managed. + Assign the AWS app to the software development projects you want to receive findings from Security Hub. Steps for each of these prerequisites are listed below. ### 1. Install the AWS Security Hub for Jira Cloud app Security Hub has an app to support its integration with Jira. This app installs custom fields and a custom issue type which allows Security Hub b to populate specific attributes about Security Hub findings. 1. Sign in to your Atlassian site as the administrator. 1. Choose **Settings**, and choose **Apps**. 1. If directed to the marketplace page, choose **Find new apps**. If directed to the apps page, choose **Explore apps**, and then search for *AWS Security Hub for Jira Cloud*. Then choose **Get it now**. ### 2. Create a project or verify existing projects This step is required if you haven't created a project. For information about how to create a project, see [Create a new project](https://support.atlassian.com/jira-software-cloud/docs/create-a-new-project/) in the Jira Cloud Support documentation. **Requirements for creating a project** Make sure to do the following when creating a new project. + Choose **Software development** for the project template. + Choose **Company-managed** for the project type. **Requirements for existing projects** Any existing projects in your Jira environment, which will be integrated with Security Hub, must be a project type of **Company-managed**. ### 3. Add your projects to the AWS Security Hub for Jira Cloud app In order for Security Hub to be able to successfully send findings to your Jira environment each project that you want to use with Security Hub must be associated with the AWS Security Hub for Jira Cloud app. Associating a Jira project with the app ensures that the necessary custom fields for are associated with the project and can be populated when Security Hub sends findings to the project. 1. Sign in to your Atlassian site as the administrator. 1. Choose **Settings**, and choose **Apps**. 1. From the list of apps, choose **AWS Security Hub for Jira Cloud**. 1. Choose the **Connector settings** tab. 1. Under **Projects enabled**, choose **Add Jira Project**. 1. From the dropdown, choose **Add all**, or select a project. Repeat this part of the step if you want to add more than one project, but not all projects. 1. Choose **Save**. You can verify which projects have been successfully installed from the **Installation Manager** tab. You can also verify configurations for fields, screens, statuses, and workflows from the **Installation Manager** tab. For additional information regarding Jira Cloud, see [Jira Cloud resources](https://support.atlassian.com/jira-software-cloud/resources/) on the Atlassian website. ## Recommendations **Creating a dedicated system account for your Jira environment** Security Hub’s integration with Jira Cloud uses an OAuth connection that is associated with a specific user within your Jira instance. Creating a dedicated system account to use for your Security Hub OAuth connection is recommended for your connection for the following reasons: + A dedicated system user ensures that the connection is not associated with an employee who’s permissions to the Jira environment could change over time, impacting the ability for Security Hub to integrate with your Jira environment. + Each issue that Security Hub creates in Jira will show a created by that is the username that was used to create the OAuth connection. Using a system account for the OAuth connection will result in this system account showing as the ticket creator, helping to provide visibility that the finding was created through the Security Hub integration and not manually by another Jira user. ## Configure an integration between Security Hub and Jira Cloud The following procedure needs to be completed for each of your Jira Cloud projects that you want to send Security Hub findings to. **Note** When you create a Jira Cloud connector, you are redirected from the current AWS Region to `"https://3rdp.oauth.console.api.aws"`, so you can complete the connector registration. Afterwards, you are returned to the AWS Region where the connector is being created. **To configure an integration for Jira Cloud** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, choose **Management**, and then choose **Integrations**. 1. Choose **Add Jira Cloud**. 1. For **Details**, enter a unique and descriptive name for your integration, and determine whether to enter an optional description for your integration. 1. For **Encryptions** choose how you want to encrypt your integration credentials within Security Hub. + **Use AWS owned key** - With this option a Security Hub owned service key will be used to encrypt your integration credential data within Security Hub. + **Choose a different KMS key (advanced)** - With this option you choose an AWS KMS key that you have created which you want to be used for encrypting your integration credential data within Security Hub. For information about how to create an AWS KMS key, see [Create a AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the * AWS Key Management Service Developer Guide*. If you choose to use your own key you must add policy statements to the KMS key that allow Security Hub access to the key. See [AWS KMS key policies for Security Hub ticketing integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-integrations-key-policy.html) for details on the necessary policies. **Note** You cannot change these settings once you complete this configuration. However, If you choose **Customized key**, you can edit your customized key policy at any time. 1. (Optional) For **Tags**, create and add a tag to your integration. You can add up to 50 tags. 1. For **Authorizations**, choose **Create connector and authorize**. A pop-up appears where you choose **Allow** to complete the authorization. After you complete the authorization, a check box appears letting you know the authorization was successful. 1. For **Configurations**, enter the Jira Cloud project ID. 1. Choose **Complete configuration**. After you complete the configuration, you can view your configured integrations in the **Configured integrations** tab. Once you have configured your integration with Jira you can test the connection to confirm that everything is configured properly in your Jira environment and in Security Hub. See the [ Testing configured ticketing integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-test-ticket-integration.html) for more details. ## Additional Jira integration details **Rate limit considerations** Jira enforces API rate limits to maintain service stability and ensure fair usage across their platform. When using the AWS Security Hub integration with Jira, these rate limits may impact the processing of Security Hub findings, particularly in environments generating high volumes of findings. This can result in delayed ticket creation, and in scenarios with extremely high finding volumes, some findings may not be processed into Jira tickets at all. To optimize your integration, consider implementing filters on Automation rules in Security Hub to prioritize ticketing on most important findings, monitoring your Jira API usage through their admin console, and planning your workflow based on your Jira license tier's specific rate limits. For business-critical implementations, contact your Jira administrator to review your rate limit allocations. For detailed information about Jira API rate limits, refer to the [Rate limiting](http://developer.atlassian.com/cloud/jira/platform/rate-limiting/) documentation on the Atlassian Developers Guide website. **Authentication and security** Jira API authentication requires proper OAuth 2.0 configuration for secure access. Ensure your application follows Atlassian's security best practices for API integration. Resources: + Jira Rest APi v3: [https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/](https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/) + Implementing OAuth 2.0 (3LO): [https://developer.atlassian.com/cloud/oauth/getting-started/implementing-oauth-3lo/](https://developer.atlassian.com/cloud/oauth/getting-started/implementing-oauth-3lo/) + Administer Jira Cloud apps: [https://support.atlassian.com/jira-cloud-administration/resources/](https://support.atlassian.com/jira-cloud-administration/resources/) + Manage Jira permissions: [https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/](https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/) # Creating a ticket for a Jira Cloud integration After you create an integration with Jira Cloud, you can create a ticket for a finding. **Note** A finding will always be associated with a single ticket through its entire lifecycle. All subsequent updates to a finding after initial creation will be sent to the same ticket. If a connector associated with an automation rule is changed, the updated connector will only be used for new and incoming findings that match the rule criteria. **To create a ticket for a finding** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, under **Inventory**, choose **Findings**. 1. Choose a finding. In the finding, choose **Create ticket**. 1. For **Integration**, open the dropdown menu, and choose an integration. This integration is the integration you previously created when you configured the Jira Cloud project. Choose the integration where you want findings sent. 1. Choose **Create**. # Viewing a ticket for a Jira Cloud integration After you create a ticket for a finding, you can open the ticket on your Jira Cloud instance. **To view a finding on your Jira Cloud instance** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, under **Inventory**, choose **Findings**. 1. Choose the finding where you created the ticket. 1. In the finding, choose the ticket ID to view the ticket on your Jira Cloud instance or **View JSON**. # Integrations for ServiceNow This topic describes how to access the Security Hub console to configure an integration for ServiceNow ITSM. Before completing any of the procedures in this topic, you must have a subscription to ServiceNow ITSM before you can add this integration. For more information, see [the pricing page](https://www.servicenow.com/lpgp/pricing-itsm.html) on the ServiceNow website. For accounts in an organization, only the delegated administrator can configure an integration. The delegated administrator can manually use the create ticket feature for any member account findings. Additionally, the delegated administrator can use [automation rules](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-v2-automation-rules.html) to automatically create tickets for any findings associated with member accounts. When defining an automation rule, the delegated administrator can set criteria, which can include all member accounts or specific member accounts. For information about setting a delegated administrator, see [Setting a delegated administrator account in Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-v2-set-da.html). For accounts not in an organization, all aspects of this feature are available. ## Prerequisites - configure ServiceNow environment You must complete the following prerequisites before configuring an integration for ServiceNow ITSM. Otherwise, your integration between ServiceNow ITSM and Security Hub will not work. ### 1. Install Security Hubfindings integration for IT Service Management (ITSM) The following procedure describes how to install Security Hub plugin. 1. Sign into your ServiceNow ITSM instance, and then open the application navigator. 1. Navigate to the [ServiceNow Store](https://store.servicenow.com/store). 1. Search for *Security Hub findings integration for IT Service Management (ITSM)*, and then choose **Get** to install the application. **Note** In the settings for the Security Hub application, choose which action to take when new Security Hub findings are sent to your ServiceNow ITSM environment. You can choose **Do nothing**, **Create incident**, **Create problem**, or **Create both (incident/problem)**. ### 2. Configure the Client Credentials grant type for inbound OAuth requests You must configure this grant type for inbound OAuth requests. For more information, see [Client Credentials grant type for Inbound OAuth is supported](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1645212) in the ServiceNow Support webpage. ### 3. Create an OAuth application If you already created an OAuth application, you can skip this prerequisite. For information about creating an OAuth application, see [Setting up OAuth](https://www.servicenow.com/docs/csh?topicname=client-credentials.html&version=latest). ## Prerequisites - configure AWS Secrets Manager To use Security Hub's integration with ServiceNow, the credentials for your ServiceNow OAuth application must be stored in Secrets Manager. Storing your credentials in Secrets Manager allows you to have control and visibility into the use of the credentials while also allowing Security Hub to use the credentials to integrate with your ServiceNow instance. To store your credentials in Secrets Manager, you must use a customer managed AWS KMS key to protect the secrets. This AWS KMS key allows you to protect the secrets while stored at rest and also allows a policy to be attached to the key which gives Security Hub permissions to access the key that is protecting the secret. Use the following steps to configure Secrets Manager for your ServiceNow credentials. ### Step 1: Attach a policy to your AWS KMS key To successfully configure your ServiceNow integration, you must first give Security Hub permissions to use the AWS KMS key that will be associated with your ServiceNow credentials in Secrets Manager. **To modify the AWS KMS key policy for Security Hub to access your ServiceNow credentials** 1. Open the AWS KMS console at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). 1. To change the AWS Region, use the Region selector in the upper-right corner of the page. 1. Select an existing AWS KMS key or perform the steps to [Create a new key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS KMS Developer Guide*. 1. In the **Key policy** section, choose **Edit**. 1. If **Switch to policy view** is displayed, choose it to display the Key policy, and then choose **Edit**. 1. Copy the following policy block to your AWS KMS key policy, to grant Security Hub permission to use your key. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::your-account-id:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow Security Hub connector service to decrypt secrets", "Effect": "Allow", "Principal": { "Service": "connector.securityhub.amazonaws.com" }, "Action": "kms:Decrypt", "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager.your-region.amazonaws.com" }, "StringLike": { "kms:EncryptionContext:SecretARN": "arn:aws:secretsmanager:your-region:your-account-id:secret:ServiceNow*" } } } ] } ``` 1. Edit the policy by replacing the following values in the policy example: + Replace *your-account-id* with your AWS account ID. + Replace *your-region* with your AWS region (for example, `us-east-1`). 1. If you added the policy statement before the final statement, add a comma before adding this statement. Make sure that the JSON syntax of your AWS KMS key policy is valid. 1. Choose **Save**. 1. (Optional) Copy the key ARN to a notepad for use in the later steps. ### Step 2: Create the secret in Secrets Manager Create a secret in Secrets Manager that will store your ServiceNow credentials. Security Hub will access this secret when interacting with your ServiceNow environment. Follow the steps [To create a secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) in the *AWS Secrets Manager User Guide*. After you create your secret, copy the Secret ARN as you will need this when creating your Security Hub connector. When creating the secret, ensure you configure the following: **Secret type** Other type of secret **Key/value pairs (Plaintext format)** ``` { "ClientId": "your-servicenow-client-id", "ClientSecret": "your-servicenow-client-secret" } ``` The field names must be exactly `ClientId` and `ClientSecret` (case-sensitive). Security Hub requires these exact names to retrieve the credentials. **Encryption key** Use the AWS KMS key you configured in Step 1 **Resource policy** Use the following resource policy: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "connector.securityhub.amazonaws.com" }, "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:your-region:your-account-id:secret:ServiceNow*", "Condition": { "StringEquals": { "aws:SourceAccount": "your-account-id", "aws:SourceArn": "arn:aws:securityhub:your-region:your-account-id:*" } } } ] } ``` Now that your secret is configured, you can create a Security Hub connector using the CreateConnectorV2 API or AWS Console. You'll need to provide: + **InstanceName**: Your ServiceNow instance URL (for example, `your-instance.service-now.com`) + **SecretArn**: The ARN of the secret you created in this procedure ## Configure an integration for ServiceNow ITSM Security Hub can create incidents or problems automatically in ServiceNow ITSM. **To configure an integration for ServiceNow ITSM** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, choose **Management**, and then choose **Integrations**. 1. Under **ServiceNow ITSM**, choose **Add integration**. 1. For **Details**, enter a name for your integration, and determine whether to enter an optional description for your integration. 1. For **Encryptions** choose how you want to encrypt your integration credentials within Security Hub. + **Use AWS owned key** - With this option a Security Hub owned service key will be used to encrypt your integration credential data within Security Hub. + **Choose a different KMS key (advanced)** - With this option you choose an AWS KMS key that you have created which you want to be used for encrypting your integration credential data within Security Hub. For information about how to create an AWS KMS key, see [Create a AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the * AWS Key Management Service Developer Guide*. If you choose to use your own key you must add policy statements to the KMS key that allow Security Hub access to the key. See [AWS KMS key policies for Security Hub ticketing integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-integrations-key-policy.html) for details on the necessary policies. **Note** You cannot change these settings once you complete this configuration. However, If you choose **Customized key**, you can edit your customized key policy at any time. 1. For **Credentials**, enter your ServiceNow ITSM URL, and the ARN of your AWS Secrets Manager secret that was generated in the prerequisites section. 1. For **Tags**, determine whether to create and add an optional tag to your integration. 1. Choose **Add integration**. After you complete the configuration, you can view your configured integrations in the **Configured integrations** tab. Once you have configured your integration with ServiceNow you can test the connection to confirm that everything is configured properly in your ServiceNow environment and in Security Hub. See the [ Testing configured ticketing integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-test-ticket-integration.html) for more details. # Creating a ticket for a ServiceNow ITSM integration After you create an integration with ServiceNow ITSM, you can create a ticket for a finding. **Note** A finding will always be associated with a single ticket through its entire lifecycle. All subsequent updates to a finding after initial creation will be sent to the same ticket. If a connector associated with an automation rule is changed, the updated connector will only be used for new and incoming findings that match the rule criteria. **To create a ticket for a finding** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, under **Inventory**, choose **Findings**. 1. Choose a finding. In the finding, choose **Create ticket**. 1. For **Integration**, open the dropdown menu, and choose an integration. 1. Choose **Create**. # Viewing a ticket for a ServiceNow ITSM integration After you create a ticket for a finding, you can open the ticket on your ServiceNow ITSM instance. **To view a finding on your ServiceNow ITSM instance** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1](https://console.aws.amazon.com/securityhub/v2/home?region=us-east-1). 1. From the navigation pane, under **Inventory**, choose **Findings**. 1. Choose the finding where you created the ticket. 1. In the finding, choose the ticket ID to view the ticket on your ServiceNow ITSM instance or **View JSON**. # KMS key policies for Security Hub ticketing integrations When using customer-managed KMS keys with Security Hub ticketing integrations, additional policies need to be added to the KMS key to allow Security Hub to interact with the key. Additionally, policies need to be added which allow the principal who is adding the key to the Security Hub connector permissions to access the key. ## Security Hub permissions policy The following policy outlines the permissions that Security Hub needs to be able to access and use the KMS key that is associated with your Jira and ServiceNow connectors. This policy needs to be added to each KMS key that is associated with a Security Hub connector. The policy contains the following permissions: + Permits Security Hub to protect, temporary access or refresh tokens used to communicate with your ticketing integrations, using the key. The permissions are restricted to operations related to specific Security Hub connectors through the condition block that checks the source ARN and encryption context. + Permits Security Hub to read metadata about the KMS key by allowing the `DescribeKey` operation. This permission is necessary for Security Hub to verify the key's status and configuration. The access is limited to specific Security Hub connectors through the source ARN condition. ``` { "Sid": "Allow Security Hub access to the customer managed key", "Effect": "Allow", "Principal": { "Service": "connector.securityhub.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "kms:ReEncrypt*" ], "Resource": "*", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:securityhub:Region:AccountId:connectorv2/*" }, "StringLike": { "kms:EncryptionContext:aws:securityhub:connectorV2Arn": "arn:aws:securityhub:Region:AccountId:connectorv2/*", "kms:EncryptionContext:aws:securityhub:providerName": "CloudProviderName" } } }, { "Sid": "Allow Security Hub read access to the customer managed key", "Effect": "Allow", "Principal": { "Service": "connector.securityhub.amazonaws.com" }, "Action": [ "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:securityhub:Region:AccountId:connectorv2/*" } } } ``` Edit the policy by replacing the following values in the policy example: + Replace *CloudProviderName* with `JIRA_CLOUD` or `SERVICENOW` + Replace *AccountId* with the account ID where you are creating the Security Hub connector. + Replace *Region* with your AWS region (for example, `us-east-1`). ## IAM principal access for Security Hub operations Any principal that will be assigning customer-managed KMS keys to a Security Hub connector needs to have permissions to perform key operations (describe, generate, decrypt, re-encrypt, and list aliases) for the key being added to the connector. This applies to the [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateConnectorV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateConnectorV2.html) and [https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateTicketV2.html](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_CreateTicketV2.html) APIs. The following policy statement should be included as part of the policy for any principal that will be interacting with these APIs. ``` { "Sid": "Allow permissions to access key through Security Hub", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountId:role/RoleName" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "kms:ReEncrypt*" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": [ "securityhub.Region.amazonaws.com" ] }, "StringLike": { "kms:EncryptionContext:aws:securityhub:providerName": "CloudProviderName" } } }, { "Sid": "Allow read permissions to access key through Security Hub", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountId:role/RoleName" }, "Action": [ "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": [ "securityhub.Region.amazonaws.com" ] } } } ``` Edit the policy by replacing the following values in the policy example: + Replace *RoleName* with the name of the IAM role that's making calls to Security Hub. + Replace *CloudProviderName* with `JIRA_CLOUD` or `SERVICENOW`. + Replace *AccountId* with the account ID where you are creating the Security Hub connector. + Replace *Region* with your AWS region (for example, `us-east-1`). # Testing configured ticketing integrations For configured Jira and ServiceNow integrations you can test the connection to ensure that all the configuration in Security Hub and in your Jira or ServiceNow environment is complete. The test ticket feature will create a ticket with a title of `TESTING Test CreateTicketV2 Finding`. The test ticket is populated with sample data such as Account ID and region of the account where the test is performed, sample resource details, and sample AWS Finding JSON. ## Testing integrations using the console Use the following steps to test your integration: 1. In the Security Hub navigation panel choose **Integrations**. 1. In the **Configured integrations** tab chose the integration that you want to test. 1. In the overview page for your integration choose **Create test ticket**. 1. If the test was successful a success message along with a link to the test ticket will be displayed. If the test was not successful an error for the test will be displayed. Based on the error message address the configuration issues in Security Hub or in your Jira or Service Now environment. **Note** The test ticket feature intended to help verify end to end functionality for the setup of a new connection or when you make changes to an existing connection. This feature will create a new ticket in your Jira or Service Now environment every time it is used and is not intended to be used for regular verification of your connection. ## Testing with the AWS CLI To test your integration using the AWS CLI, use the `create-ticket-v2` command with the `--mode DRYRUN` parameter: ``` aws securityhub create-ticket-v2 \ --mode DRYRUN \ --region \ --connector-id \ --finding-metadata-uid "TEST_FINDING" ``` **Example** The following example shows how to test an integration: ``` aws securityhub create-ticket-v2 \ --mode DRYRUN \ --region us-east-1 \ --connector-id "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \ --finding-metadata-uid "TEST_FINDING" ``` **Successful Response** A successful response returns the following: ``` { "TicketId": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6", "TicketSrcUrl": "https://your-instance.service-now.com/nav_to.do?uri=x_aws_se_0_finding.do?sys_id=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6" } ``` The `TicketSrcUrl` in the response provides a direct link to view the test ticket in your Jira or ServiceNow environment. If the test fails, an error message will be displayed indicating the configuration issue that needs to be addressed. ## Troubleshooting Jira cloud integration errors When testing your integration to Jira Cloud from Security Hub the following error messages may be returned. These error messages can provide insight on where the configuration issue with the connector could be and how to resolve. **Jira Cloud integration error messages** | Error | Error Message | Likely cause and resolution | | --- | --- | --- | | ConflictException | Cannot find jira project | **Likely cause:** Project on the connector is incorrect, or credentials/permissions issue preventing us from accessing the project. **Likely resolution:** Add the correct project to the connector or re-authenticate to Jira with the correct credentials. | | ConflictException | Security Hub issue type not found | **Likely cause:** App installation issue or issue type is not associated with the project. **Likely resolution:** Perform the pre-requisite step to install the Jira app into your Jira environment and associate the app with the project. | # Disabling Security Hub ## Disabling Security Hub for a single account If your account is not part of an organization, you can disable Security Hub in the Security Hub console at any time or use [DisableSecurityHubV2 API](https://docs.aws.amazon.com/securityhub/1.0/APIReference/API_DisableSecurityHubV2.html). When you disable Security Hub, it stops ingesting findings from detection engines, you also lose access to existing findings, integrations and configurations. **To disable Security Hub** 1. Sign in to your AWS account with your credentials, and open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **General**. 1. In Security Hub, choose **Disable**. In the pop-up window, enter **Disable**, and choose **Disable**. ## Disabling Security Hub across an organization If you are the delegated administrator for an AWS Organization, you have two options for disabling Security Hub across member accounts. ### Option 1: Disabling Security Hub with detection engines You can leverage the **Security Hub (essential and additional capabilities)** deployment and policy from the policy catalog in your delegated administrator account to disable Security Hub along with Amazon Inspector for specific organizational units, accounts, or regions. **To disable Security Hub and Amazon Inspector across member accounts using a policy** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. Choose **Security Hub (essential and additional capabilities)** from the Configuration catalog. 1. On the **Configure Security Hub** page in the **Details** section, enter a name and description for the policy (for example, "Security Hub Disablement Policy"). 1. In the **Account selection** section, select one of the following options. Choose **All organizational units and accounts** if you want to apply the disablement to all organizational units and accounts. Choose **Specific organizational units and accounts** if you want to apply the disablement to specific organizational units and accounts. If you choose this option, use the search bar or organizational structure tree to specify the target organizational units and accounts. 1. In the **Regions** section, choose **Disable all Regions** to disable Security Hub in all Regions. Optionally choose whether to automatically disable new Regions. Choose **Specify Regions** to choose which specific Regions you want to disable. 1. (Optional) For **Advanced settings**, refer to the guidance from AWS Organizations. 1. (Optional) For **Resource tags**, add tags as key-value pairs to help you easily identify the configuration. 1. Choose **Next**. 1. Review your changes, and then choose **Apply**. Your target accounts are configured based on the policy. The configuration status of your policy will display at the top of the Policies page. **Disabling Amazon GuardDuty and AWS Security Hub CSPM** For GuardDuty and Security Hub CSPM capabilities, you must manually disable the capabilities from the respective delegated administrator accounts. GuardDuty and Security Hub CSPM use deployments (one-time actions) rather than policies, so disablement must be performed manually from their respective consoles. ### Option 2: Disabling Security Hub only If you have an existing Security Hub policy and want to disable Security Hub only, without affecting Amazon Inspector, GuardDuty, or Security Hub CSPM, follow these steps. **To disable Security Hub only across member accounts** 1. Sign in using your AWS account with your delegated administrator credentials. Open the Security Hub console at [https://console.aws.amazon.com/securityhub/v2/home](https://console.aws.amazon.com/securityhub/v2/home). 1. From the navigation pane, choose **Management**, and then choose **Configurations**. 1. Choose any of your **Security Hub policies** from the **Configured policies**. 1. Click **Edit policy** and in the **Account selection** section, select one of the following options. Choose **All organizational units and accounts** if you want to apply the disablement to all organizational units and accounts. Choose **Specific organizational units and accounts** if you want to apply the disablement to specific organizational units and accounts. If you choose this option, use the search bar or organizational structure tree to specify the target organizational units and accounts. 1. In the **Regions** section, choose **Disable all Regions** to disable Security Hub in all Regions. Optionally choose whether to automatically disable new Regions. Choose **Specify Regions** to choose which specific Regions you want to disable. 1. (Optional) For **Advanced settings**, refer to the guidance from AWS Organizations. 1. (Optional) For **Resource tags**, add tags as key-value pairs to help you easily identify the configuration. 1. Choose **Next**. 1. Review your changes, and then choose **Apply**. Your target accounts are configured based on the policy. The configuration status of your policy will display at the top of the Configurations page. **Impact on other security services** Disabling Security Hub through an Security Hub policy has **no impact** on Security Hub CSPM, GuardDuty, and Amazon Inspector configurations. If you need to disable Amazon Inspector only across member accounts, you can use the **Vulnerability management** policy from the Security Hub configuration catalog. Navigate to the Security Hub Configuration page, choose **Vulnerability management from Amazon Inspector**, and create a disable policy following steps similar to the Security Hub disable procedure above. # Security in AWS Security Hub Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Security Hub, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). + **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using Security Hub. The following topics show you how to configure Security Hub to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your Security Hub resources. **Topics** + [Data protection in AWS Security Hub](sh-data-protection.md) + [AWS Identity and Access Management for Security Hub](sh-security-iam.md) + [Compliance validation for AWS Security Hub](sh-securityhub-compliance.md) + [Resilience in AWS Security Hub](sh-disaster-recovery-resiliency.md) + [Infrastructure security in AWS Security Hub](sh-infrastructure-security.md) + [AWS Security Hub and interface VPC endpoints (AWS PrivateLink)](sh-security-vpc-endpoints.md) # Data protection in AWS Security Hub The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Security Hub. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Security Hub or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. Security Hub is a multi-tenant service offering. To help protect your data, Security Hub encrypts data at rest and data in transit between component services. # Opting out of using your data for service improvement **Note** This documentation page is only applicable to the enhanced AWS Security Hub launched on December 2, 2025. If you are a customer of the original AWS Security Hub (now AWS Security Hub CSPM), the data usage described below will apply only after you have enabled the enhanced AWS Security Hub. You can choose to opt out of having your data (defined as "Security Hub Content" in the Security Hub service terms) used to develop and improve AWS Security Hub and other AWS security services by using the AWS Organizations opt-out policy. You can choose to opt out even if Security Hub doesn't currently collect any such Content. For more information about how to opt out, see [AI services opt-out policies](orgs_manage_policies_ai-opt-out.html) in the *AWS Organizations User Guide*. **Note** For you to use the opt-out policy, your AWS accounts must be centrally managed by AWS Organizations. If you haven't already created an organization for your AWS accounts, see [Creating and managing an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html) in the *AWS Organizations User Guide*. Opting out has the following effects: + Security Hub will delete the Content that it collected and stored for service improvement purposes prior to your opt out (if any). + After you opt out, Security Hub will no longer collect or store this Content for service improvement purposes. The following section explains how Security Hub will handle your content for service improvement. ## AWS Security Hub data usage Currently, AWS Security Hub does not collect or store any Security Hub Content for service improvement purposes. However, in the future, Security Hub may collect and use third-party security findings that you aggregate in Security Hub and other forms of Security Hub Content (that Security Hub receives from you or upstream services for purposes of providing Security Hub capabilities) to improve Security Hub and other AWS security service capabilities. Your trust, privacy, and the security of your Content are our highest priority. If Security Hub begins collecting Security Hub Content for service improvement purposes in the future, this page will be updated to reflect those changes and provide details about what data is collected and how it is used. You can opt out of this Security Hub Content collection at any time using the AWS Organizations opt-out policy described above. For more information about AWS data privacy practices, see [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). ## References For similar opt-out procedures in other AWS security services, see: + [Opting out of using your data for service improvement ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-opting-out-using-data.html)in the *Amazon GuardDuty User Guide*. + [Opting out of using your data for service improvement ](https://docs.aws.amazon.com/security-lake/latest/userguide/opting-out-of-using-your-data.html)in the *Amazon Security Lake User Guide*. # AWS Identity and Access Management for Security Hub AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Security Hub resources. IAM is an AWS service that you can use with no additional charge. **Topics** + [Audience](#security_iam_audience) + [Authenticating with identities](#security_iam_authentication) + [Managing access using policies](#security_iam_access-manage) + [How Security Hub works with IAM](sh_security_iam_service-with-iam.md) + [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md) + [Service-linked roles for AWS Security Hub](sh-using-service-linked-roles.md) + [AWS managed policies for Security Hub](sh-security-iam-awsmanpol.md) + [Troubleshooting AWS Security Hub identity and access](sh-security_iam_troubleshoot.md) ## Audience How you use AWS Identity and Access Management (IAM) differs based on your role: + **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting AWS Security Hub identity and access](sh-security_iam_troubleshoot.md)) + **Service administrator** - determine user access and submit permission requests (see [How Security Hub works with IAM](sh_security_iam_service-with-iam.md)) + **IAM administrator** - write policies to manage access (see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md)) ## Authenticating with identities Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role. You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*. For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*. ### AWS account root user When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. ### Federated identity As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials. A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials. For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*. ### IAM users and groups An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*. An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*. ### IAM roles An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*. IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. ## Managing access using policies You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*. Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**. By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation. ### Identity-based policies Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*. ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy. ### Other policy types AWS supports additional policy types that can set the maximum permissions granted by more common policy types: + **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*. + **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*. + **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*. + **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*. ### Multiple policy types When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*. # How Security Hub works with IAM Before you use AWS Identity and Access Management (IAM) to manage access to AWS Security Hub, learn which IAM features are available to use with Security Hub. **IAM features you can use with AWS Security Hub** | IAM feature | Security Hub support | | --- | --- | | [Identity-based policies](#sh_security_iam_service-with-iam-id-based-policies) | Yes | | [Resource-based policies](#sh_security_iam_service-with-iam-resource-based-policies) | No | | [Policy actions](#sh_security_iam_service-with-iam-id-based-policies-actions) | Yes | | [Policy resources](#sh_security_iam_service-with-iam-id-based-policies-resources) | No | | [Policy condition keys](#sh_security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes | | [Access control lists (ACLs)](#sh_security_iam_service-with-iam-acls) | No | | [Attribute-based access control (ABAC) – tags in policies](#sh_security_iam_service-with-iam-tags) | Yes | | [Temporary credentials](#sh_security_iam_service-with-iam-roles-tempcreds) | Yes | | [Forward access sessions (FAS)](#sh_security_iam_service-with-iam-principal-permissions) | Yes | | [Service roles](#sh_security_iam_service-with-iam-roles-service) | No | | [Service-linked roles](#sh_security_iam_service-with-iam-roles-service-linked) | Yes | For a high-level view of how Security Hub and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Identity-based policies for Security Hub **Supports identity-based policies:** Yes Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. Security Hub supports identity-based policies. For more information, see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md). ## Resource-based policies for Security Hub **Supports resource-based policies:** No Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. Security Hub does not support resource-based policies. You can't attach an IAM policy directly to a Security Hub resource. ## Policy actions for Security Hub **Supports policy actions:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation. Policy actions in Security Hub use the following prefix before the action: ``` securityhub: ``` For example, to grant a user permission to enable Security Hub, which is an action that corresponds to the `EnableSecurityHubV2` operation of the Security Hub API, include the `securityhub:EnableSecurityHubV2` action in their policy. Policy statements must include either an `Action` or `NotAction` element. Security Hub defines its own set of actions that describe tasks that you can perform with this service. ``` "Action": "securityhub:EnableSecurityHubV2" ``` To specify multiple actions in a single statement, separate them with commas. For example: ``` "Action": [ "securityhub:EnableSecurityHubV2", "securityhub:CreateAutomationRuleV2" ``` You can also specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Get`, include the following action: ``` "Action": "securityhub:Get*" ``` However, as a best practice, you should create policies that follow the principle of least privilege. In other words, you should create policies that include only the permissions that are required to perform a specific task. For a list of Security Hub actions, see [Actions Defined by AWS Security Hub](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecurityhub.html#awssecurityhub-actions-as-permissions) in the *Service Authorization Reference*. For examples of policies that specify Security Hub actions, see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md). ## Policy resources for Security Hub **Supports policy resources:** No Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources. ``` "Resource": "*" ``` Security Hub defines the following resource types: + Hub + Product + Finding aggregator, also referred to as a *cross-Region aggregator* + Automation rule You can specify these types of resources in policies by using ARNs. For a list of Security Hub resource types and the ARN syntax for each one, see [Resources Defined by AWS Security Hub](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecurityhub.html#awssecurityhub-resources-for-iam-policies) in the *Service Authorization Reference*. To learn which actions you can specify for each type of resource, see [Actions Defined by AWS Security Hub](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecurityhub.html#awssecurityhub-actions-as-permissions) in the *Service Authorization Reference*. For examples of policies that specify resources, see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md). ## Policy condition keys for Security Hub **Supports service-specific policy condition keys:** Yes Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**. The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. For a list of Security Hub condition keys, see [Condition Keys for AWS Security Hub](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecurityhub.html#awssecurityhub-policy-keys) in the *Service Authorization Reference*. To learn which actions and resources you can use a condition key with, see [Actions Defined by AWS Security Hub](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecurityhub.html#awssecurityhub-actions-as-permissions). For examples of policies that use condition keys, see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md). ## Access control lists (ACLs) in Security Hub **Supports ACLs:** No Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format. Security Hub doesn't support ACLs, which means you can't attach an ACL to a Security Hub resource. ## Attribute-based access control (ABAC) with Security Hub **Supports ABAC (tags in policies):** Yes Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**. For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*. You can attach tags to Security Hub resources. You can also control access to resources by providing tag information in the `Condition` element of a policy. For information about tagging Security Hub resources, see [Tagging Security Hub resources](tagging-resources.md). For an example of an identity-based policy that controls access to a resource based on tags, see [Identity-based policy examples for AWS Security Hub CSPM](sh_security_iam_id-based-policy-examples.md). ## Using temporary credentials with Security Hub **Supports temporary credentials:** Yes Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). Security Hub supports the use of temporary credentials. ## Forward access sessions for Security Hub **Supports forward access sessions (FAS):** Yes Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). For example, Security Hub makes FAS requests to downstream AWS services when you integrate Security Hub with AWS Organizations and when you designate the delegated Security Hub administrator account for an organization in Organizations. For other tasks, Security Hub uses a service-linked role to perform actions on your behalf. For details about this role, see [Service-linked roles for AWS Security Hub](sh-using-service-linked-roles.md). ## Service roles for Security Hub Security Hub doesn't assume or use service roles. To perform actions on your behalf, Security Hub uses a service-linked role. For details about this role, see [Service-linked roles for AWS Security Hub](sh-using-service-linked-roles.md). **Warning** Changing the permissions for a service role may create operational issues with your use of Security Hub. Edit service roles only when Security Hub provides guidance to do so. ## Service-linked roles for Security Hub **Supports service-linked roles:** Yes A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. Security Hub uses a service-linked role to perform actions on your behalf. For details about this role, see [Service-linked roles for AWS Security Hub](sh-using-service-linked-roles.md). # Identity-based policy examples for AWS Security Hub CSPM By default, users and roles don't have permission to create or modify Security Hub CSPM resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the users or groups that require those permissions. To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating Policies on the JSON Tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*. **Topics** + [Policy best practices](#sh_security_iam_service-with-iam-policy-best-practices) + [Using the Security Hub CSPM console](#sh_security_iam_id-based-policy-examples-console) + [Example: Allow users to view their own permissions](#sh_security_iam_id-based-policy-examples-view-own-permissions) + [Example: Allow users to view findings](#sh_security_iam_id-based-policy-examples-view-findings) + [Example: Allow users to create and manage automation rules](#sh_security_iam_id-based-policy-examples-create-automation-rule) ## Policy best practices Identity-based policies determine whether someone can create, access, or delete Security Hub resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations: + **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. + **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. + **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*. + **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*. + **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*. For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. ## Using the Security Hub CSPM console To access the AWS Security Hub CSPM console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Security Hub CSPM resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy. You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform. To ensure that those users and roles can use the Security Hub CSPM console, also attach the following AWS managed policy to the entity. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "securityhub:*", "Resource": "*" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringLike": { "iam:AWSServiceName": "securityhub.amazonaws.com" } } } ] } ``` ------ ## Example: Allow users to view their own permissions This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Example: Allow users to view findings This example shows how you might create an IAM policy that allows a user to view Security Hub CSPM findings. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReviewFindings", "Effect": "Allow", "Action": [ "securityhub:GetFindingsV2" ], "Resource": "*" } ] } ``` ## Example: Allow users to create and manage automation rules This example shows how you might create an IAM policy that allows a user to create, view, update, and delete Security Hub CSPM automation rules. For this IAM policy to work, the user must be a Security Hub CSPM administrator. To limit permissions— for example, to allow a user to only view automation rules—you can remove the create, update, and delete permissions. ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CreateAndUpdateAutomationRules", "Effect": "Allow", "Action": [ "securityhub:CreateAutomationRuleV2", ], "Resource": "*" }, { "Sid": "ViewAutomationRules", "Effect": "Allow", "Action": [ "securityhub:ListAutomationRulesV2", "securityhub:GetAutomationRuleV2" ], "Resource": "*" }, { "Sid": "DeleteAutomationRules", "Effect": "Allow", "Action": [ "securityhub:DeleteAutomationRuleV2" ], "Resource": "*" } ] } ``` # Service-linked roles for AWS Security Hub AWS Security Hub uses an AWS Identity and Access Management (IAM) [service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) named `AWSServiceRoleForSecurityHubV2`. This service-linked role is an IAM role that's linked directly to Security Hub. It's predefined by Security Hub, and it includes all the permissions that Security Hub requires to call other AWS services and monitor AWS resources on your behalf. Security Hub uses this service-linked role in all the AWS Regions where Security Hub is available. A service-linked role makes setting up Security Hub easier because you don't have to manually add the necessary permissions. Security Hub defines the permissions of its service-linked role, and unless defined otherwise, only Security Hub can assume the role. The defined permissions include the trust policy and the permissions policy, and you can't attach that permissions policy to any other IAM entity. To review the details of the service-linked role, you can use the Security Hub console. In the navigation pane, choose **General** under **Settings**. Then, in the **Service permissions** section, choose **View service permissions**. You can delete the Security Hub service-linked role only after you disable Security Hub in all the Regions where it's enabled. This protects your Security Hub resources because you can't inadvertently remove permissions to access them. For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide* and locate the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to review the service-linked role documentation for that service. **Topics** + [Service-linked role permissions for Security Hub](#sh-slr-permissions) + [Creating a service-linked role for Security Hub](#sh-create-slr) + [Editing a service-linked role for Security Hub](#sh-edit-slr) + [Deleting a service-linked role for Security Hub](#sh-delete-slr) ## Service-linked role permissions for Security Hub Security Hub uses the service-linked role named `AWSServiceRoleForSecurityHubV2`. It's a service-linked role required for AWS Security Hub to access your resources. This service-linked role allows Security Hub to perform tasks such as receive findings from other AWS services and configure the requisite AWS Config infrastructure to run security checks for controls. The `AWSServiceRoleForSecurityHubV2` service-linked role trusts the `securityhub.amazonaws.com` service to assume the role. The `AWSServiceRoleForSecurityHubV2` service-linked role uses the managed policy [`AWSSecurityHubServiceRolePolicy`](security-iam-awsmanpol.md#security-iam-awsmanpol-awssecurityhubservicerolepolicy). You must grant permissions to allow an IAM identity (such as a role, group, or user) to create, edit, or delete a service-linked role. For the `AWSServiceRoleForSecurityHubV2` service-linked role to be successfully created, the IAM identity that you use to access Security Hub must have the required permissions. To grant the required permissions, attach the following policy to the IAM identity. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "securityhub:*", "Resource": "*" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringLike": { "iam:AWSServiceName": "securityhub.amazonaws.com" } } } ] } ``` ------ ## Creating a service-linked role for Security Hub The `AWSServiceRoleForSecurityHubV2` service-linked role is created automatically when you enable Security Hub for the first time or you enable Security Hub in a Region where you didn't previously enable it. You can also create the `AWSServiceRoleForSecurityHubV2` service-linked role manually by using the IAM console, the IAM CLI, or the IAM API. For more information about creating the role manually, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. **Important** The service-linked role that's created for a Security Hub administrator account doesn't apply to associated Security Hub member accounts. ## Editing a service-linked role for Security Hub Security Hub doesn't allow you to edit the `AWSServiceRoleForSecurityHubV2` service-linked role. After you create a service-linked role, you can't change the name of the role because various entities might reference the role. However, you can edit the description of the role by using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Deleting a service-linked role for Security Hub If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete the role. That way, you don't have an unused entity that isn't actively monitored or maintained. When you disable Security Hub, Security Hub doesn't automatically delete the `AWSServiceRoleForSecurityHubV2` service-linked role for you. If you enable Security Hub again, the service can then start using the existing service-linked role again. If you no longer need to use Security Hub, you can manually delete the service-linked role. **Important** Before you delete the `AWSServiceRoleForSecurityHubV2` service-linked role, you must first disable Security Hub in all the Regions where it's enabled. For more information, see [Disabling Security Hub](securityhub-v2-disable.md). If Security Hub isn't disabled when you try to delete the service-linked role, the deletion fails. To delete the `AWSServiceRoleForSecurityHubV2` service-linked role, you can use the IAM console, the IAM CLI, or the IAM API. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. # AWS managed policies for Security Hub An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: AWSSecurityHubFullAccess You can attach the `AWSSecurityHubFullAccess` policy to your IAM identities. This policy grants administrative permissions that allow a principal full access to all Security Hub actions. This policy must be attached to a principal before they enable Security Hub manually for their account. For example, principals with these permissions can both view and update the status of findings. They can also configure custom insights, enable integrations, and enable and disable standards and controls. Principals for an administrator account can also manage member accounts. **Permissions details** This policy includes the following permissions: + `securityhub` – Allows principals full access to all Security Hub actions. + `guardduty` – Allows principals to get information about account status in Amazon GuardDuty. + `iam` – Allows principals to create a service-linked role for Security Hub. + `inspector` – Allows principals to get information about account status in Amazon Inspector. + `pricing` – Allows principals to get a price list of AWS services and products. To review the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubFullAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSSecurityHubReadOnlyAccess You can attach the `AWSSecurityHubReadOnlyAccess` policy to your IAM identities. This policy grants read-only permissions that allow users to view information in Security Hub. Principals with this policy attached cannot make any updates in Security Hub. For example, principals with these permissions can view the list of findings associated with their account, but cannot change the status of a finding. They can view the results of insights, but cannot create or configure custom insights. They cannot configure controls or product integrations. **Permissions details** This policy includes the following permissions: + `securityhub` – Allows users to perform actions that return a list of items or details about an item. This includes API operations that start with `Get`, `List`, or `Describe`. To review the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubReadOnlyAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSSecurityHubOrganizationsAccess You can attach the `AWSSecurityHubOrganizationsAccess` policy to your IAM identities. This policy grants administrative permissions to enable and manage Security Hub for an organization in AWS Organizations. The permissions for this policy allow the organization management account to designate the delegated administrator account for Security Hub. They also allow the delegated administrator account to enable organization accounts as member accounts. This policy only provides permissions for AWS Organizations. The organization management account and delegated administrator account also require permissions for associated actions. These permissions can be granted using the `AWSSecurityHubFullAccess` managed policy. **Permissions details** This policy includes the following permissions: + `organizations:ListAccounts` – Allows principals to retrieve the list of accounts that are part of an organization. + `organizations:DescribeOrganization` – Allows principals to retrieve information about the organization. + `organizations:ListRoots` – Allows principals to list the root of an organization. + `organizations:ListDelegatedAdministrators` – Allows principals to list the delegated administrator of an organization. + `organizations:ListAWSServiceAccessForOrganization` – Allows principals to list the AWS services that an organization uses. + `organizations:ListOrganizationalUnitsForParent` – Allows principals to list the child organizational units (OU) of a parent OU. + `organizations:ListAccountsForParent` – Allows principals to list the child accounts of a parent OU. + `organizations:ListParents` – Lists the root or organizational units (OUs) that serve as the immediate parent of the specified child OU or account. + `organizations:DescribeAccount` – Allows principals to retrieve information about an account in the organization. + `organizations:DescribeOrganizationalUnit` – Allows principals to retrieve information about an OU in the organization. + `organizations:ListPolicies` – Retrieves the list of all policies in an organization of a specified type. + `organizations:ListPoliciesForTarget` – Lists the policies that are directly attached to the specified target root, organizational unit (OU), or account. + `organizations:ListTargetsForPolicy` – Lists all the roots, organizational units (OUs), and accounts that the specified policy is attached to. + `organizations:EnableAWSServiceAccess` – Allows principals to enable the integration with Organizations. + `organizations:RegisterDelegatedAdministrator` – Allows principals to designate the delegated administrator account. + `organizations:DeregisterDelegatedAdministrator` – Allows principals to remove the delegated administrator account. + `organizations:DescribePolicy` – Retrieves information about a policy. + `organizations:DescribeEffectivePolicy` – Returns the contents of the effective policy for specified policy type and account. + `organizations:CreatePolicy` – Creates a policy of a specified type that you can attach to a root, an organizational unit (OU), or an individual AWS account. + `organizations:UpdatePolicy` – Updates an existing policy with a new name, description, or content. + `organizations:DeletePolicy` – Deletes the specified policy from your organization. + `organizations:AttachPolicy` – Attaches a policy to a root, an organizational unit (OU), or an individual account. + `organizations:DetachPolicy` – Detaches a policy from a target root, organizational unit (OU), or account. + `organizations:EnablePolicyType` – Enables a policy type in a root. + `organizations:DisablePolicyType` – Disables an organizational policy type in a root. + `organizations:TagResource` – Adds one or more tags to a specified resource. + `organizations:UntagResource` – Removes any tags with the specified keys from a specified resource. + `organizations:ListTagsForResource` – Lists tags that are attached to a specified resource. To review the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubOrganizationsAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubOrganizationsAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSSecurityHubV2ServiceRolePolicy **Note** Security Hub is in preview release and subject to change. This policy allows Security Hub to manage AWS Config rules and Security Hub resources for your organization and on your behalf. This policy is attached to a service-linked role that allows the service to perform actions on your behalf. You cannot attach this policy to your IAM identities. For more information, see [Service-linked roles for AWS Security Hub](sh-using-service-linked-roles.md). **Permissions details** This policy includes the following permissions: + `config` – Manage service-linked configuration recorders for Security Hub resources. + `iam` – Create the service-linked role for AWS Config. + `organizations` – Retrieve account and organizational unit (OU) information for an organization. + `securityhub` – Manage the Security Hub configuration. + `tag` – Retrieve information about resource tags. To review the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubV2ServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecurityHubV2ServiceRolePolicy.html) in the *AWS Managed Policy Reference Guide*. ## Security Hub updates to AWS managed policies The following table provides details about updates to AWS managed policies for AWS Security Hub since this service began tracking these changes. For automatic alerts about updates to the policies, subscribe to the RSS feed on the [Security Hub document history](doc-history.md) page. | Change | Description | Date | | --- | --- | --- | | [AWSSecurityHubOrganizationsAccess](#sh-security-iam-awsmanpol-awssecurityhuborganizationsaccess) – Updated policy | Security Hub updated the policy to add permissions to describe resource policies to support Security Hub features. Security Hub is in preview release and subject to change. | November 12, 2025 | | [AWSSecurityHubFullAccess](#sh-security-iam-awsmanpol-awssecurityhubfullaccess) – Updated policy | Security Hub updated the policy to add capabilities around managing GuardDuty, Amazon Inspector, and account management to support Security Hub features. Security Hub is in preview release and subject to change. | November 17, 2025 | | [AWSSecurityHubV2ServiceRolePolicy](#sh-security-iam-awsmanpol-awssecurityhubv2servicerolepolicy) – Updated policy | Security Hub updated the policy to add metering capabilities for Amazon Elastic Container Registry, AWS Lambda, Amazon CloudWatch, and AWS Identity and Access Management to support Security Hub features. The update also added support for global AWS Config recorders. Security Hub is in preview release and subject to change. | November 5, 2025 | | [AWSSecurityHubOrganizationsAccess](#sh-security-iam-awsmanpol-awssecurityhuborganizationsaccess) – Update to an existing policy | Security Hub added new permissions to the policy. The permissions allow the organization management to enable and manage Security Hub and Security Hub CSPM for an organization. | June 17, 2025 | | [AWSSecurityHubFullAccess](#sh-security-iam-awsmanpol-awssecurityhubfullaccess) – Update to an existing policy | Security Hub CSPM added new permissions that allow principals to create a service-linked role for Security Hub. | June 17, 2025 | | [AWSSecurityHubV2ServiceRolePolicy](#sh-security-iam-awsmanpol-awssecurityhubv2servicerolepolicy) – New policy | Security Hub added a new policy to allow Security Hub to manage AWS Config rules and Security Hub resources for a customer's organization and on the customer's behalf. Security Hub is in preview release and subject to change. | June 17, 2025 | | [AWSSecurityHubFullAccess ](#sh-security-iam-awsmanpol-awssecurityhubfullaccess) – Update to an existing policy | Security Hub CSPM updated the policy to get pricing details for AWS services and products. | April 24, 2024 | | [AWSSecurityHubReadOnlyAccess ](#sh-security-iam-awsmanpol-awssecurityhubreadonlyaccess) – Update to an existing policy | Security Hub CSPM updated this managed policy by adding a Sid field. | February 22, 2024 | | [AWSSecurityHubFullAccess ](#sh-security-iam-awsmanpol-awssecurityhubfullaccess) – Update to an existing policy | Security Hub CSPM updated the policy so it can determine if Amazon GuardDuty and Amazon Inspector are enabled in an account. This helps customers bring together security-related information from multiple AWS services. | November 16, 2023 | | [AWSSecurityHubOrganizationsAccess ](#sh-security-iam-awsmanpol-awssecurityhuborganizationsaccess) – Update to an existing policy | Security Hub CSPM updated the policy to grant additional permissions to allow read-only access to AWS Organizations delegated administrator functionality. This includes details like the root, organizational units (OUs), accounts, organizational structure, and service access. | November 16, 2023 | | [AWSSecurityHubOrganizationsAccess ](#sh-security-iam-awsmanpol-awssecurityhuborganizationsaccess) – New policy | Security Hub CSPM added a new policy that grants permissions that are needed for the Security Hub CSPM integration with Organizations. | March 15, 2021 | | Security Hub CSPM started tracking changes | Security Hub CSPM started tracking changes for its AWS managed policies. | March 15, 2021 | # Troubleshooting AWS Security Hub identity and access Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Security Hub and IAM. **Topics** + [I am not authorized to perform an action in Security Hub](#sh-security_iam_troubleshoot-no-permissions) + [I am not authorized to perform iam:PassRole](#sh-security_iam_troubleshoot-passrole) + [I want programmatic access to Security Hub](#sh-security_iam_troubleshoot-access-keys) + [I'm an administrator and want to allow others to access Security Hub](#sh-security_iam_troubleshoot-admin-delegate) + [I want to allow people outside my AWS account to access my Security Hub resources](#sh-security_iam_troubleshoot-cross-account-access) ## I am not authorized to perform an action in Security Hub If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your sign-in credentials. The following example error occurs when the user `mateojackson` tries to use the console to view details about a *widget* but does not have `securityhub:GetWidget` permissions. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: securityhub:GetWidget on resource: my-example-widget ``` In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `securityhub:GetWidget` action. ## I am not authorized to perform iam:PassRole If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Security Hub. Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service. The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in Security Hub. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action. If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials. ## I want programmatic access to Security Hub Users need programmatic access if they want to interact with AWS outside of the AWS Management Console. The way to grant programmatic access depends on the type of user that's accessing AWS. To grant users programmatic access, choose one of the following options. **** | Which user needs programmatic access? | To | By | | --- | --- | --- | | IAM | (Recommended) Use console credentials as temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/sh-security_iam_troubleshoot.html) | | Workforce identity (Users managed in IAM Identity Center) | Use temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/sh-security_iam_troubleshoot.html) | | IAM | Use temporary credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions in [Using temporary credentials with AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) in the IAM User Guide. | | IAM | (Not recommended)Use long-term credentials to sign programmatic requests to the AWS CLI, AWS SDKs, or AWS APIs. | Following the instructions for the interface that you want to use. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/sh-security_iam_troubleshoot.html) | ## I'm an administrator and want to allow others to access Security Hub To provide access, add permissions to your users, groups, or roles: + Users and groups in AWS IAM Identity Center: Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*. + Users managed in IAM through an identity provider: Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. + IAM users: + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. ## I want to allow people outside my AWS account to access my Security Hub resources You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources. To learn more, consult the following: + To learn whether Security Hub supports these features, see [How Security Hub works with IAM](security_iam_service-with-iam.md). + To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*. + To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*. + To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*. + To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*. # Compliance validation for AWS Security Hub To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/). # Resilience in AWS Security Hub The AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). # Infrastructure security in AWS Security Hub As a managed service, AWS Security Hub is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*. You use AWS published API calls to access Security Hub through the network. Clients must support the following: + Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3. + Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes. # AWS Security Hub and interface VPC endpoints (AWS PrivateLink) You can establish a private connection between your VPC and AWS Security Hub by creating an *interface VPC endpoint*. Interface endpoints are powered by [AWS PrivateLink](https://aws.amazon.com/privatelink), a technology that enables you to privately access Security Hub APIs without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC don't need public IP addresses to communicate with Security Hub APIs. Traffic between your VPC and Security Hub does not leave the Amazon network. Each interface endpoint is represented by one or more [Elastic Network Interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) in your subnets. For more information, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html) in the *Amazon Virtual Private Cloud Guide*. ## Considerations for Security Hub VPC endpoints Before you set up an interface VPC endpoint for Security Hub, ensure that you review the prerequisites and other information in the [Amazon Virtual Private Cloud Guide](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html). Security Hub supports making calls to all of its API actions from your VPC. ## Creating an interface VPC endpoint for Security Hub You can create a VPC endpoint for the Security Hub service using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) in the *Amazon Virtual Private Cloud Guide*. Create a VPC endpoint for Security Hub using the following service name: `com.amazonaws.region.securityhub` Where *region* is the Region code for the applicable AWS Region. If you enable private DNS for the endpoint, you can make API requests to Security Hub using its default DNS name for the Region, for example, `securityhub.us-east-1.amazonaws.com` for the US East (N. Virginia) Region. ## Creating a VPC endpoint policy for Security Hub You can attach an endpoint policy to your VPC endpoint that controls access to Security Hub. The policy specifies the following information: + The principal that can perform actions. + The actions that can be performed. + The resources on which actions can be performed. For more information, see [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *Amazon Virtual Private Cloud Guide*. **Example: VPC endpoint policy for Security Hub actions** The following is an example of an endpoint policy for Security Hub. When attached to an endpoint, this policy grants access to the listed Security Hub actions for all principals on all resources. ``` { "Statement":[ { "Principal":"*", "Effect":"Allow", "Action":[ "securityhub:getFindings", "securityhub:getEnabledStandards", "securityhub:getInsights" ], "Resource":"*" } ] } ``` ## Shared subnets You can't create, describe, modify, or delete VPC endpoints in subnets that are shared with you. However, you can use the VPC endpoints in subnets that are shared with you. For information about VPC sharing, see [Share your VPC subnets with other accounts](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) in the *Amazon Virtual Private Cloud Guide*. # Logging Security Hub API calls with CloudTrail is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Security Hub. CloudTrail captures API calls for Security Hub as events. The captured calls include calls from the Security Hub console and code calls to the Security Hub API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for Security Hub. If you don't configure a trail, you can still view the most recent events on the CloudTrail console in **Event history**. Using the information that CloudTrail collects, you can determine the request that was made to Security Hub, the IP address that the request was made from, who made the request, when it was made, and additional details. To learn more about CloudTrail, including how to configure and enable it, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). ## Security Hub information in CloudTrail CloudTrail is enabled on your AWS account when you create the account. When supported event activity occurs in Security Hub, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your account. For more information, see [Viewing events with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html). For an ongoing record of events in your account, including events for Security Hub, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail on the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following: + [Overview for creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations) + [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html) + [Receiving CloudTrail log files from multiple regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) Security Hub supports logging all of the Security Hub API actions as events in CloudTrail logs. To view a list of Security Hub operations, see the [Security Hub API Reference](https://docs.aws.amazon.com/securityhub/1.0/APIReference/Welcome.html). When activity for the following actions is logged to CloudTrail, the value for `responseElements` is set to `null`. This ensures that sensitive information isn't included in CloudTrail logs. + `GetFindingsV2` Every event or log entry contains information about who generated the request. The identity information helps you determine the following: + Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials + Whether the request was made with temporary security credentials for a role or federated user + Whether the request was made by another AWS service For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html). ## Example: Security Hub log file entries A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order. The following example shows a CloudTrail log entry that demonstrates the `CreateAutomationRuleV2` action. In this example, an automation rule called `TestAutomationRule` is created. The `Severity` and `Account ID` attributes are specified as the **Criteria**. When the rule is matched the `Severity` is updated to **High**. For more information about automation rules, see [Automation rules in Security Hub](securityhub-v2-automation-rules.md). ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:Admin", "arn": "arn:aws:sts::555555555555:assumed-role/Admin", "accountId": "555555555555", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "aarn:aws:iam::555555555555:role/Admin", "accountId": "555555555555", "userName": "Admin" }, "attributes": { "creationDate": "2025-11-15T18:49:13Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-11-15T18:51:17Z", "eventSource": "securityhub.amazonaws.com", "eventName": "CreateAutomationRuleV2", "awsRegion": "us-west-2", "sourceIPAddress": "205.251.233.50", "userAgent": "aws-cli/1.11.76 Python/2.7.10 Darwin/17.7.0 botocore/1.5.39", "requestParameters": { "Description": "Test Automation Rule", "Actions": [ { "Type": "FINDING_FIELDS_UPDATE", "FindingFieldsUpdate": { "SeverityId": 4 } } ], "RuleStatus": "ENABLED", "Criteria": { "OcsfFindingCriteria": { "CompositeFilters": [ { "Operator": "OR", "StringFilters": [ { "FieldName": "severity", "Filter": { "Value": "Medium", "Comparison": "EQUALS" } } ] }, { "Operator": "OR", "StringFilters": [ { "FieldName": "cloud.account.uid", "Filter": { "Value": "111122223333", "Comparison": "EQUALS" } } ] } ], "CompositeOperator": "AND" } }, "ClientToken": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "RuleOrder": 61, "RuleName": "TestAutomationRule", "Tags": {} }, "responseElements": { "RuleArn": "arn:aws:securityhub:us-west-2:555555555555:automation-rulev2/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "RuleId": "c8bc6f90-29e9-4eb7-919f-b145e44eb8ec" }, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "555555555555", "eventCategory": "Management" } ```