Strengthening Your AWS Security Posture with CIS Controls and Benchmarks
You have secured your AWS environments (at least you think you have), but you have some doubts, and the reality is that a security compromise would be disastrous to both your company as well as your career. So how do you improve your security posture?
Thankfully, there is no shortage of compliance frameworks to help you strengthen your defenses. Some are mandated based upon your industry and the classification of data you process, and some are completely optional. This article will explain why I believe you should consider leveraging the Center for Internet Security (CIS) to strengthen your AWS security posture, even if you have mandated compliance requirements.
Why Compliance Matters: A Personal Anecdote
I was exposed to compliance frameworks when PCI v1.0 was first announced. At the time, I was the CTO for a billion dollar retailer, who qualified as a Level 1 merchant (Level 1 is the highest and strictest standard for PCI compliance). Welcome to the world of compliance!
Part of my responsibility as CTO was to oversee security, which meant I was responsible for passing the company's very first PCI assessment. This meant I got to "enjoy" having several assessors onsite probing through every nook and cranny of our broad infrastructure and 500+ stores. Keep in mind that was the first release of PCI, and it was a little wild wild west back then from a security perspective for most companies. Fun!
Despite the anxiety-riddled five years of audits during my tenure (all were successful thankfully), I learned the value of compliance frameworks for security hardening. These frameworks provide a structured set of guidelines, standards, and best practices to help organizations secure their environments, which allows you to measure yourself while you continue on your never ending journey to security nirvana.
"There are only two types of companies: Those that have been hacked and those that will be hacked". – Robert S. Mueller, III, former Director of the FBI
Choosing the Right Framework
What if your organization doesn't have mandated compliance requirements, such as PCI (card holder data), HIPAA (electronic protected health data or ePHI) or FedRAMP (federal data)? Does this mean you won the compliance and security framework lottery and your life is easier than for many of us? Hardly. Or at least it shouldn't be.
Even if you aren't required to comply with mandated security controls, here are reasons why you should still measure yourself against a framework or security baseline:
Avoid financial losses
Ensure business continuity
Safeguard your assets and sensitive data
Prevent damage to your organization's reputation
If you are an AWS security architect or engineer, and want to measure your environment against an industry security framework, which one should you choose? Remember, in the world of cyber security, there is no such thing as too safe! There is nothing wrong with using multiple frameworks.
In my humble opinion, I believe you should consider the Center for Internet Security (CIS), but not necessarily just for its control framework. There is more to CIS than their security controls - more on that later.
A Deep Dive into CIS
CIS is a 501(c)(3) non-profit organization that formed in October 2000 after a small group of business and government leaders met to discuss the increasing threat of cyber-attacks. This meeting was the seed to develop a non-profit community-driven organization with the mission to "help people, businesses, and governments protect themselves against pervasive cyber threats". Access to CIS documents are free for non-commercial use, so as long as you aren't using them to provide professional services to others, you have free use to utilize them to strengthen your company's security posture.
The CIS Critical Security Controls (CIS Controls) are a prioritized and simplified set of best practices that you can use to strengthen your cybersecurity posture. There are 158 CIS Controls in their latest version (v8), and these are consolidated across 18 activities, which are illustrated below:
Within each activity, controls are further subdivided into three "implementation groups" - IG1, IG2, and IG3. IG1 contains controls considered "essential cyber security", or the minimal base set of controls for companies that do not have high value data, and IG2 and IG3 build upon that base with increasingly stricter safeguards. The table above indicates how many controls exist within each implementation group. I mention these implementation groups because AWS allows you to select which group you want to measure yourself against (this will be covered later in the article).
Keep in mind that these controls are designed to be applied across an entire organization, and are not cloud-specific.
In addition to these v8 controls, CIS provides over 100 benchmarks targeting specific vendor products. For AWS, CIS provides these seven different benchmarks:
Amazon Web Services Foundations (2.0.0)
Amazon Web Services Three-tier Web Architecture (1.0.0)
AWS Compute Services (1.0.0)
AWS End User Compute Services (1.1.0)
Amazon Elastic Kubernetes Service (EKS) Benchmark (1.4.0)
Amazon Linux 2 Benchmark (2.0.0)
Amazon Linux 2023 Benchmark (1.0.0)
Unlike the more general controls which tend to be descriptive, these benchmarks are very prescriptive.
Controls vs Benchmarks: Understanding the Difference
To illustrate the difference between a control and a benchmark, here is an example of a CIS control dealing with least privilege:
CIS Control 6.8: Define and maintain role-based access control, through determining and documenting the access rights necessary for each role within the enterprise to successfully carry out its assigned duties. Perform access control reviews of enterprise assets to validate that all privileges are authorized, on a recurring schedule at a minimum annually, or more frequently.
This control is designed to apply to any computing environment, cloud or on-prem, so it is very non-prescriptive. Deciding HOW to implement this control for AWS is left up to you as the reader. In comparison, look at the following CIS AWS benchmark that pertains to least privilege:
CIS AWS Benchmark 1.20: Ensure that IAM Access Analyzer is enabled for all regions
As you can see, the benchmark prescribes HOW to implement the safeguard, whereas the control is about WHAT the control covers.
The contrast between a control (what) and benchmark (how) is blurred by the fact that AWS, via Conformance Packs, has taken general framework controls such as PCI and CIS and decided how the control should be implemented and measured on AWS. Technology implementation aside, the usefulness of AWS benchmarks far outweigh the usefulness of controls (in my humble opinion) when focusing on hardening your AWS environment.
Measuring CIS Compliance on AWS
AWS provides two primary mechanisms for reporting on CIS compliance: Security Hub and Conformance Packs (Audit Manager and Inspector also provide support for CIS controls). Conformance Packs live within AWS Config, and are a packaged collection of individual Config rules that pertain to a common standard or security objective.
The CIS controls and benchmarks supported by AWS are illustrated below:
Notice that it isn't always obvious which items are controls and which are benchmarks. For instance, "Operational Best Practices for CIS AWS v1.4 Level1" and "Operational Best Practices for CIS AWS v1.4 Level2" are benchmarks, which can be identified as such by the version number (v1.4). The next three are Controls, identified by the use of "controls" in the name as well as the version number (v8). The last item, "Operational Best Practices for CIS", which for some reason is referred to as "CIS Top 20" in the AWS online documentation, does not indicate control or benchmark. However, CIS Controls v7 had 20 categories, so I'm assuming it is in fact referencing the now outdated v7 of the CIS controls.
Also note that outside of the Foundations Benchmark, the more specific benchmarks are not yet supported (Linux, EKS, Three-Tier Web Architecture, etc.). Even without AWS integration, these additional benchmarks can prove themselves just as valuable.
Anyone believe the naming conventions here could use some refinement, or is it just me that finds this a little too ambiguous? Hint for AWS: use the actual CIS naming conventions for clarity.
AWS Conformance Packs for CIS
There are six different Conformance Packs available for CIS compliance. But what rules are utilized within each conformance pack? Are you better off selecting all CIS conformance packs with the assumption there is overlap but you want the broadest coverage? You might be tempted to believe that the more conformance packs you utilize, the more you will pay. But AWS has your back in this case - as pointed out in their FAQ for Security Hub: "You are only charged once for each time a control is evaluated against a resource (i.e., for each security check) regardless of how many standards the control is linked to". Thus if the same Config rule is utilized across multiple Conformance Packs, you are only charged once for that rule. However, If you activate all CIS Conformance Packs, the reporting will be a bit wonky in that you have multiple Conformance Packs all reporting against many of the same items. How many times do you need to be told that a finding is non-compliant? If you are interested in Conformance Pack pricing, it can be found here.
If you don't subscribe to the "more is always better" notion, how do you make an informed decision on which CIS Conformance Packs are right for your organization's needs? If you dig within the AWS documentation, you can identify which config rules are utilized for each Conformance Pack by reviewing the contents of each Conformance Pack template. Alternatively, you can access the Conformance Pack YAML files out on GitHub and identify which Config Rules exist in each Conformance Pack. Either way, quickly identifying any overlap across the individual conformance packs can be time consuming. To save you some time, I have tabulated the Config rules utilized by each CIS Conformance Pack. A partial section of the table is listed below:
This table allows you to quickly see the rule coverage across the different CIS Conformance Packs. If this kind of cross reference document exists online somewhere, please comment below and let me know I have successfully recreated the wheel. In the meantime, I will continue desk checking my work before publishing the complete table in a follow up article.
AWS Security Hub for CIS
As described earlier in the article, Conformance Packs provide greater coverage of CIS than Security Hub. Whereas Conformance Packs gave you the option for both controls and benchmarks, Security Hub only provides the foundation benchmarks (v1.2.0 and v1.4.0). So why would you choose Security Hub over Conformance Packs if there is less coverage? I suggest you consider the following snippet of advice from the Security Hub FAQ:
Q: When do I use Security Hub and AWS Config conformance packs? If a compliance standard, such as PCI-DSS, is already present in Security Hub, then the fully-managed Security Hub service is the easiest way to operationalize it. You can investigate findings via the Security Hub integration with Amazon Detective, and you can build automated or semi-automated remediation actions using the Security Hub integration with EventBridge. However, if you want to assemble your own compliance or security standard, which may include security, operational or cost optimization checks, AWS Config conformance packs are the way to go.
So if you wish to compile a custom set of CIS or other compliance checks, Conformance Packs provide you with the necessary flexibility. Conformance Packs also currently give you a greater set of frameworks to choose from, but if what you want exists within Security Hub, keep in mind that this is the path of least resistance.
Wrapping Things Up
If you want to operate your AWS environment securely, whether you utilize other control frameworks today or not, I strongly suggest you investigate CIS controls and their collection of AWS-specific benchmarks. But don't just take my word for it; dive into CIS for AWS and see the difference it can make with your overall AWS security posture.