Generating and updating control findings
AWS Security Hub generates findings by running checks against the rules in security controls. These findings use the AWS Security Finding Format (ASFF). Note
that if the finding size exceeds the maximum of 240 KB, then the Resource.Details
object is removed. For findings for controls that use AWS Config rules, you can view the resource
details on the AWS Config console.
Security Hub normally charges for each security check for a control. However, if multiple controls use the same AWS Config rule, then Security Hub only charges once for each check against the AWS Config rule. It generates separate findings for each control based on the check.
For example, the AWS Config rule iam-password-policy
is used by multiple controls in
the Center for Internet Security (CIS) AWS Foundations Benchmark and by IAM.7 in the AWS Foundational Security Best
Practices (FSBP) standard. Each time Security Hub runs a check against that AWS Config rule, it generates a separate
finding for each related control, but only charges once for the check.
Compliance
details for control findings
For findings generated by security checks of controls, the Compliance field in the AWS Security Finding Format (ASFF) contains the control-related findings details. The Compliance field includes the following information.
RelatedRequirements
-
The list of related requirements for the control. The requirements are from the third-party security framework for the control, such as the Payment Card Industry Data Security Standard.
Status
-
The 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.
StatusReasons
-
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 status reason codes and descriptions. The remediation steps for a reason code depend on which control generated a finding with the reason code. You can see remediation steps for FSBP controls at AWS Foundational Security Best Practices controls.
Reason code |
Compliance.Status |
Description |
---|---|---|
|
|
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 |
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. |
|
|
The compliance status is AWS Config does not provide the reason for the status. Here are some possible reasons for the Not Applicable status:
|
|
AWS Config status is |
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:
|
|
AWS Config status is |
The AWS Config rule is in the process of being created. |
|
|
An unknown error occurred. |
|
FAILED |
Security Hub is unable to perform a check against a custom Lambda runtime. |
|
|
The finding is in a 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. |
|
WARNING |
The finding is in a The SNS topic associated with this rule is owned by a different account. The current account cannot obtain the subscription information. The account that owns the SNS topic must grant to the current account the
|
|
|
The finding is in a 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 SNS topic associated with this rule is invalid. |
|
|
The relevant API operation exceeded the allowed rate. |
ProductFields
details for control findings
The ProductFields
attribute in ASFF includes additional
details about findings generated by security checks of controls.
For findings generated by security checks, ProductFields
includes the following
fields:
StandardsGuideArn
orStandardsArn
-
The ARN of the standard associated with the control.
For the CIS AWS Foundations Benchmark standard, the field is
StandardsGuideArn
.For PCI DSS and AWS Foundational Security Best Practices standards, the field is
StandardsArn
. StandardsGuideSubscriptionArn
orStandardsSubscriptionArn
-
The ARN of the account's subscription to the standard.
For the CIS AWS Foundations Benchmark standard, the field is
StandardsGuideSubscriptionArn
.For the PCI DSS and AWS Foundational Security Best Practices standards, the field is
StandardsSubscriptionArn
. RuleId
orControlId
-
The identifier of the control.
For the CIS AWS Foundations Benchmark standard, the field is
RuleId
.For the PCI DSS and AWS Foundational Security Best Practices standards, the field is
ControlId
. RecommendationUrl
-
The URL to the remediation information for the control.
RelatedAWSResources:0/name
-
The name of the resource associated with the finding.
RelatedAWSResource:0/type
-
The type of resource associated with the control.
StandardsControlArn
-
The ARN of the control.
aws/securityhub/ProductName
-
For control-based findings, the product name is Security Hub.
aws/securityhub/CompanyName
-
For control-based findings, the company name is AWS.
aws/securityhub/annotation
-
A description of the issue uncovered by the control.
aws/securityhub/FindingId
-
The identifier of the finding.
Assigning severity to control findings
The severity assigned to a Security Hub control identifies the importance of the control. The severity of a control 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 that is 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 that is associated with a mission critical application is more critical
than one that is 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 |
Critical |
Critical |
High |
Medium |
Somewhat easy to exploit |
Critical |
High |
Medium |
Medium |
Somewhat difficult to exploit |
High |
Medium |
Medium |
Low |
Very difficult to exploit |
Medium |
Medium |
Low |
Low |
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
,WARNING
, orNOT AVAILABLE
.There is no recommended action. Informational findings help customers to demonstrate that they are in a compliant state.
Rules for updating control findings
A subsequent check against a given rule might generate a new result. For example, the status
of "Avoid the use of the root account" could change from FAILED
to
PASSED
. In that case, 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 is not updated for three to five days (note that this is best effort and not guaranteed).
-
The associated AWS Config evaluation returned
NOT_APPLICABLE
.