This is a warning about AWS Security Hub. Organizations that use AWS Security Hub to monitor and mitigate risks pay too much attention to the visible part of the AWS security iceberg, namely the findings. These organizations tend to overlook or underestimate the invisible part of the iceberg where critical risks are hidden.

Below, I go into the details of my observations and outline possible countermeasures to ensure you are using AWS Security Hub in the right way.

Overwhelming amount of findings

The AWS Security Hub comes with controls for the following standards:

  • CIS AWS Foundations: 48 controls
  • Payment Card Industry Data Security Standard (PCI DSS): 49 controls
  • AWS Foundational Security Best Practices: 162 controls

It is not uncommon that you will end up with hundreds or even thousands of findings after enabling one or multiple standards for multiple AWS accounts with running workloads. Working through a huge list of findings to evaluate, suppress, or fix the issue is demotivating and uses up a lot of energy and attention.

I’ve seen teams spend weeks or months fixing all the findings generated by AWS Security Hub. Don’t get me wrong, fixing the findings will improve overall security. My point is that you may be overlooking important areas where security can be significantly enhanced by spending the same time and money.

A few ideas to avoid getting overwhelmed by the number of findings generated by the AWS Security Hub.

1. Do not enable all security standards at once. For example, start with the CIS AWS Foundations standard.
2. Enable and monitor the AWS Security Hub at the beginning of a project before creating resources in the AWS account.
3. Disable irrelevant or outdated controls. Also, disable controls generating a lot of minor findings.

SecurityHub controls focus on generic risks that are easy to detect. So it is crucial that you ask the question: Which parts of the iceberg are not covered by AWS Security Hub? Let me give you a few examples:

  • Do resource- and identity-based policies follow the least privilege principle.
  • Are the security group rules as strict as possible?
  • Is the ALB publicly accessible by intention?
  • Should objects be protected from being manipulated or deleted by enabling S3 Object Lock?
  • What’s the data classification of the data stored in a database cluster? Is encryption with a customer-managed KMS key required?
  • Does that Lambda function (Node.js) contain a package with a critical vulnerability?

Be aware that the AWS Security Hub does not check all relevant aspects of cloud security. Also, it is impossible to evaluate rules based on context information like the data classification, for example. That does not mean the service is terrible; it is just not possible to go into the details with generic controls.

Some might argue, that other AWS services or 3rd parties could jump in and provide advanced controls. For example, the IAM Access Analyzer compares CloudTrail logs with IAM polices to make suggestions on how to improve the policy. However, the IAM Access Analyzer comes with the same limitation, it does not know about your scenario. Instead, it makes guesses based on incomplete/expensive CloudTrail logs. In my opinion, all those tools try to solve a problem, that cannot be solved without any context information about the scenario.

Some ideas on avoiding blind spots when using the AWS Security Hub.

1. Be aware that the AWS Security Hub does not cover all relevant aspects of cloud security.
2. Ask AWS security specialists to review AWS accounts regularly.
3. Validate whether IAM and network configuration follows the least privilege principle.

Summary

Think of AWS security as an iceberg. The easy-to-find risks look out of the water, and AWS Security Hub will easily detect them. But under the water, the iceberg continues; critical vulnerabilities are hiding there. Therefore, here are a few tips for dealing with the AWS Security Hub.

  1. Avoid generating an overwhelming amount of findings. For example, do not enable all standards and controls at once.
  2. Be aware that the AWS Security Hub does not cover all relevant aspects of cloud security. The generic controls do not guarantee that you are following the least-privilege principle, for example.
  3. Reduce the noise generated by false positives to avoid alert fatigue. Mark findings as SUPPRESSED manually or automatically.