Results of security checks - AWS Security Hub

Results of security checks

When it runs checks against the enabled controls for the enabled security standards, AWS Security Hub generates findings. These findings use the AWS Security Finding Format (ASFF).

Control-related information in the ASFF

For findings generated by security checks, the Compliance field in the ASFF contains the control-related findings details. The Compliance field includes the following information.

  • A RelatedRequirements array that contains a list of related requirements for the control.

  • A Status field that contains result of the most recent check that Security Hub ran for a given control. The results of the previous checks are kept in an archived state for 90 days.

  • A StatusReasons object that contains a list of reasons for the value of Compliance.Status. For each reason, StatusReasons includes the reason code and a description.

The following table lists the available reason codes and descriptions.

Reason code





The multi-Region CloudTrail trail does not have a valid metric filter.



Metric filters are not present for the multi-Region CloudTrail trail.



The account does not have a multi-Region CloudTrail trail with the required configuration.



Multi-Region CloudTrail trails are not in the current Region.



No valid alarm actions are present.



CloudWatch alarms do not exist in the account.



AWS Config status is ConfigError

AWS Config access denied.

Verify that AWS Config is enabled and has been granted sufficient permissions.



AWS Config evaluated your resources based on the rule.

The rule did not apply to the AWS resources in its scope, the specified resources were deleted, or the evaluation results were deleted.



AWS Config status is ConfigError

This reason code is used for several different types of evaluation errors.

The description provides the specific reason information.

The type of error can be one of the following.

  • An inability to perform the evaluation because of a lack of permissions. The description provides the specific permission that is missing.

  • A missing or invalid value for a parameter. The description provides the parameter and the requirements for the parameter value.

  • An error reading from an S3 bucket. The description identifies the bucket and provides the specific error.

  • A missing AWS subscription.

  • A general timeout on the evaluation.

  • A suspended account.



AWS Config status is ConfigError

Unable to find the supporting AWS Config rule.

Verify that you have enabled AWS Config.



Security Hub archived this finding because the resource no longer exists.



The finding is in a WARNING state, because the S3 bucket associated with this rule is in a different Region or account.

This rule does not support cross-Region or cross-account checks.

It is recommended that you disable this control in this Region or account. Only run it in the Region or account where the resource is located.



The CloudWatch Logs metric filters do not have a valid Amazon SNS subscription.



The finding is in a WARNING state because the SNS topic associated with this rule is in a different Region or account.

This rule does not support cross-Region or cross-account checks.

It is recommended that you disable this control in this Region or account. Only run it in the Region or account where the resource is located.



The relevant API operation exceeded the allowed rate.

Determining the severity of controls and control findings

The severity assigned to a Security Hub control identifies the importance of the control. It determines the severity label assigned to the control findings.

Severity criteria

The severity of a control is determined based on an assessment of the following criteria:

  • How difficult is it for a threat actor to take advantage of the configuration weakness associated with the control?

    The difficulty is determined by the amount of sophistication or complexity required to use the weakness to carry out a threat scenario.

  • How likely is it that the weakness will lead to a compromise of your AWS accounts or resources?

    A compromise of your AWS accounts or resources means that confidentiality, integrity, or availability of your data or AWS infrastructure is damaged in some way.

    The likelihood of compromise indicates how likely it is that the threat scenario will result in a disruption or breach of your AWS services or resources.

As an example, consider the following configuration weaknesses:

  • IAM user access keys are not rotated every 90 days

  • IAM root access key exists

Both weaknesses are equally difficult for an adversary to take advantage of. In both cases, the adversary can use credential theft or some other method to acquire a user key. They can then use it to access your resources in an unauthorized way.

However, the likelihood of a compromise is much higher if the threat actor acquires the root user access key, because the root key gives them greater access. As a result, the root user key weakness has a higher severity.

The severity does not take into account the criticality of the underlying resource. Criticality is the level of importance of the resources that are associated with the finding. For example, a resource associated with a mission critical application is more critical than one associated with nonproduction testing. To capture resource criticality information, use the Criticality field of the AWS Security Finding Format (ASFF).

The following table maps the difficulty to exploit and the likelihood of compromise to the security labels.

Compromise highly likely

Compromise likely

Compromise unlikely

Compromise highly unlikely

Very easy to exploit





Somewhat easy to exploit





Somewhat difficult to exploit





Very difficult to exploit





Severity definitions

The severity labels are defined as follows.

Critical – The issue should be remediated immediately to avoid it escalating.

For example, an open S3 bucket is considered a critical severity finding. Because so many actors scan for open S3 buckets, data in exposed S3 buckets is likely to be discovered and accessed by others.

In general, resources that are publicly accessible are considered critical security issues. You should treat critical findings with the utmost urgency. You also should consider the criticality of the resource.

High – The issue must be addressed as a near-term priority.

For example, if a default VPC security group is open to inbound and outbound traffic, it is considered high severity. It is somewhat easy for a threat actor to compromise a VPC using this method. It is also likely that the threat actor will be able to disrupt or exfiltrate resources once they are in the VPC.

Security Hub recommends that you treat a high severity finding as a near-term priority. You should take immediate remediation steps. You also should consider the criticality of the resource.

Medium – The issue should be addressed as a mid-term priority.

For example, lack of encryption for data in transit is considered a medium severity finding. It requires a sophisticated man-in-the-middle attack to take advantage of this weakness. In other words, it is somewhat difficult. It is likely that some data will be compromised if the threat scenario is successful.

Security Hub recommends that you investigate the implicated resource at your earliest convenience. You also should consider the criticality of the resource.

Low – The issue does not require action on its own.

For example, failure to collect forensics information is considered low severity. This control can help to prevent future compromises, but the absence of forensics does not lead directly to a compromise.

You do not need to take immediate action on low severity findings, but they can provide context when you correlate them with other issues.

Informational – No configuration weakness was found.

In other words, the status is PASSED.

There is no recommended action. Informational findings help customers to demonstrate that they are in a compliant state.

Determining the overall status of a control from its findings

In the findings generated by security checks, the Compliance.Status field is assigned one of the following values.

  • PASSED. If Compliance.Status is PASSED, then Security Hub automatically sets Workflow.Status to RESOLVED.


  • WARNING – Indicates that the check was completed, but Security Hub cannot determine whether the resource is in a PASSED or FAILED state.

  • NOT_AVAILABLE – Indicates that the check cannot be completed because a server failed, the resource was deleted, or the result of the AWS Config evaluation was NOT_APPLICABLE.

    If the AWS Config evaluation result was NOT_APPLICABLE, then Security Hub automatically archives the finding.

The overall status for each control is based on the value of Compliance.Status for the active findings for that control. The overall status includes the active findings in the master account and the member accounts.

The overall status ignores findings that have a Workflow.Status of SUPPRESSED.

The available values for the overall status are as follows:

  • Passed – Indicates that all findings have a Compliance.Status of PASSED.

  • Failed – Indicates that at least one finding has a Compliance.Status of FAILED.

  • Unknown – Indicates that at least one finding has a Compliance.Status of WARNING or NOT_AVAILABLE. No findings are FAILED.

  • No data – Indicates that there are no findings for the control. For example, a new control has this status until it begins to generate findings. A control also has this status if all of the findings are SUPPRESSED.

Determining the security score for a security standard

On the Security standards page, each enabled standard displays a security score, which is between 0% and 100%.

The security score represents the proportion of Passed controls to enabled controls. The score is displayed as a percentage. For example, if 10 controls are enabled for a standard, and seven of those controls are in a Passed state, then the security score is 70%.

The security score calculation does not include enabled controls that do not have any findings (overall status is No data). For example, a standard has 12 controls enabled. Six of those controls are in a Passed state. Two controls have no data. Because the calculation omits the controls without data, the security score is 60%.

On the Summary page, the Security standards card displays the security scores for each enabled standard. It also displays a consolidated security score that represents the proportion of passed controls to enabled controls across all of the enabled standards.

Rules for updating control findings

If a subsequent check against a given rule generates a new result (for example, the status of "Avoid the use of the root account" changes from FAILED to PASSED), a new finding is generated that contains the most recent result.

If a subsequent check against a given rule generates a result that is identical to the current result, the existing finding is updated. No new finding is generated.

Security Hub automatically archives findings from controls if the associated resource is deleted, the resource does not exist, or the control is disabled. A resource might no longer exist because the associated service is not currently used. The findings are archived automatically based on one of the following criteria:

  • The finding was not updated in three days.

  • The associated AWS Config evaluation returned NOT_APPLICABLE.