Skip to content
Merged
Show file tree
Hide file tree
Changes from 11 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion cis_v140/docs/cis_v140_2_3_1.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ Databases that hold sensitive and critical data, it is highly recommended to imp
4. Click on **Actions** button placed at the top right and select **Take Snapshot**.
5. On the Take Snapshot page, enter a database name of which want to take snapshot in the Snapshot Name field and click Take Snapshot.
6. Select the newly created snapshot and click the **Copy** from the dashboard top menu.
7. On the Make Copy of DB Snapshot page, perform the following:
7. On the Make Copy of DB Snapshot page, perform the following:
1. In the New DB Snapshot Identifier field, Enter a name for the `new snapshot`.
2. Check `Copy Tags`, New snapshot must have the same tags as the source snapshot.
3. Select Yes from the **Enable Encryption** dropdown list to enable encryption, Can choose to use the AWS default encryption key or custom key from Master Key dropdown list.
Expand Down
23 changes: 23 additions & 0 deletions cis_v600/cis.pp
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
locals {
cis_v600_common_tags = merge(local.aws_compliance_common_tags, {
cis = "true"
cis_version = "v6.0.0"
})
}

benchmark "cis_v600" {
title = "AWS CIS v6.0.0"
description = "The CIS Amazon Web Services Foundations Benchmark provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings."
documentation = file("./cis_v600/docs/cis_overview.md")
children = [
benchmark.cis_v600_2,
benchmark.cis_v600_3,
benchmark.cis_v600_4,
benchmark.cis_v600_5,
benchmark.cis_v600_6
]

tags = merge(local.cis_v600_common_tags, {
type = "Benchmark"
})
}
81 changes: 81 additions & 0 deletions cis_v600/docs/cis_overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
To obtain the latest version of the official guide, please visit http://benchmarks.cisecurity.org.

## Overview

All CIS BenchmarksTM focus on technical configuration settings used to maintain and/or increase the security of the addressed technology, and they should be used in conjunction with other essential cyber hygiene tasks like:

- Monitoring the base operating system and applications for vulnerabilities and quickly updating with the latest security patches.
- End-point protection (Antivirus software, Endpoint Detection and Response (EDR), etc.).
- Logging and monitoring user and system activity.

In the end, the CIS BenchmarksTM are designed to be a key component of a comprehensive cybersecurity program.

### Important Usage Information

All CIS BenchmarksTM are available free for non-commercial use from the [CIS Website](https://www.cisecurity.org/cis-benchmarks). They can be used to manually assess and remediate systems and applications. In lieu of manual assessment and remediation, there are several tools available to assist with assessment:
- [CIS Configuration Assessment Tool (CIS-CAT® Pro Assessor)](https://www.cisecurity.org/cybersecurity-tools/cis-cat-pro)
- [CIS BenchmarksTM Certified 3rd Party Tooling](https://www.cisecurity.org/cis-securesuite/members/vendors)

These tools make the hardening process much more scalable for large numbers of systems and applications.

### NOTE:
Some tooling focuses only on the CIS BenchmarksTM Recommendations that can be fully automated (skipping ones marked Manual). It is important that ALL Recommendations (Automated and Manual) be addressed, since all are important for properly securing systems and are typically in scope for audits.

In addition, CIS has developed CIS [Build Kits](https://www.cisecurity.org/cis-securesuite/cis-securesuite-build-kit-content) for some common technologies to assist in applying CIS BenchmarksTM Recommendations.

When remediating systems (changing configuration settings on deployed systems as per the CIS BenchmarksTM Recommendations), please approach this with caution and test thoroughly.

The following is a reasonable remediation approach to follow:

1. NEVER deploy a CIS Build Kit, or any internally developed remediation method, to production systems without proper testing.
2. Proper testing consists of the following:
- Understand the configuration (including installed applications) of the targeted systems.
- Read the Impact section of the given Recommendation to help determine if there might be an issue with the targeted systems.
- Test the configuration changes on representative lab system(s). This way if there is some issue it can be resolved prior to deploying to any production systems.
- When confident, initially deploy to a small sub-set of users and monitor closely for issues. This way if there is some issue it can be resolved prior to deploying more broadly.
- When confident, iteratively deploy to additional groups and monitor closely for issues until deployment is complete. This way if there is some issue it can be resolved prior to continuing deployment.

### NOTE:
CIS and the CIS BenchmarksTM development communities in CIS WorkBench do their best to test and have high confidence in the Recommendations, but they cannot test potential conflicts with all possible system deployments. Known potential issues identified during CIS BenchmarksTM development are documented in the Impact section of each Recommendation.

By using CIS and/or CIS BenchmarksTM Certified tools, and being careful with remediation deployment, it is possible to harden large numbers of deployed systems in a cost effective, efficient, and safe manner.

### NOTE:
As previously stated, the PDF versions of the CIS BenchmarksTM are available for free, non-commercial use on the [CIS Website](https://www.cisecurity.org/cis-benchmarks). All other formats of the CIS BenchmarksTM (MS Word, Excel, and [Build Kits](https://www.cisecurity.org/cis-securesuite/cis-securesuite-build-kit-content)) are available for CIS [SecureSuite®](https://www.cisecurity.org/cis-securesuite) members.

CIS-CAT® Pro is also available to CIS [SecureSuite®](https://www.cisecurity.org/cis-securesuite) members.

### Target Technology Details

This document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. Some of the specific Amazon Web Services in scope for this document include:

- AWS Identity and Access Management (IAM)
- IAM Access Analyzer
- AWS Config
- AWS CloudTrail
- AWS CloudWatch
- AWS Simple Notification Service (SNS)
- AWS Simple Storage Service (S3)
- Elastic Compute Cloud (EC2)
- Relational Database Service (RDS)
- AWS VPC

## Profiles Definitions

The following configuration profiles are defined by this Benchmark:

### Level 1

Items in this profile intend to:
- be practical and prudent;
- provide security focused best practice hardening of a technology; and
- limit impact to the utility of the technology beyond acceptable means.

### Level 2

This profile extends the "Level 1" profile. Items in this profile exhibit one or more
of the following characteristics:
- are intended for environments or use cases where security is more critical than manageability and usability
- acts as defense in depth measure
- may impact the utility or performance of the technology
- may include additional licensing, cost, or addition of third party software
3 changes: 3 additions & 0 deletions cis_v600/docs/cis_v600_2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
## Overview

This section contains recommendations for configuring identity and access management related options.
42 changes: 42 additions & 0 deletions cis_v600/docs/cis_v600_2_1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
## Description

Ensure contact email and telephone details for AWS accounts are current and map to more than one individual in your organization.

An AWS account supports a number of contact details, and AWS will use these to contact the account owner if activity judged to be in breach of the Acceptable Use Policy or indicative of a likely security compromise is observed by the AWS Abuse team. Contact details should not be for a single individual, as circumstances may arise where that individual is unavailable. Email contact details should point to a mail alias which forwards email to multiple individuals within the organization; where feasible, phone contact details should point to a PABX hunt group or other call-forwarding system.

## Remediation

This activity can only be performed via the AWS Console, with a user who has permission to read and write Billing information (aws-portal:*Billing).

### From Console:

1. Sign in to the AWS Management Console and open the `Billing and Cost Management` console at https://console.aws.amazon.com/billing/home#/.
2. On the navigation bar, choose your account name, and then choose Account.
3. On the `Account Settings` page, next to `Account Settings`, choose `Edit`.
4. Next to the field that you need to update, choose `Edit`.
5. After you have entered your changes, choose `Save changes`.
6. After you have made your changes, choose `Done`.
7. To edit your contact information, under `Contact Information`, choose `Edit`.
8. For the fields that you want to change, type your updated information, and then choose `Update`.

### From Command Line:

1. Run the following command:

```bash
aws account put-contact-information --contact-information '{
"AddressLine1": "<AddressLine 1>",
"AddressLine2": "<AddressLine 2>",
"City": "<City>",
"CompanyName": "<Company Name>",
"CountryCode": "<Country Code>",
"FullName": "<Full Name>",
"PhoneNumber": "<Phone Number>",
"PostalCode": "<Postal Code>",
"StateOrRegion": "<State or Region>"
}'
```

### Default Value:

By default, AWS account contact information (email and telephone) is set to the values provided at account creation. These usually reference a single individual rather than a shared alias or group contact.
49 changes: 49 additions & 0 deletions cis_v600/docs/cis_v600_2_10.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
## Description

AWS console defaults to no check boxes selected when creating a new IAM user. When creating the IAM User credentials you have to determine what type of access they require.

Programmatic access: The IAM user might need to make API calls, use the AWS CLI, or use the Tools for Windows PowerShell. In that case, create an access key (access key ID and a secret access key) for that user.

AWS Management Console access: If the user needs to access the AWS Management Console, create a password for the user.

## Remediation

Perform the following to delete access keys that do not pass the audit:

### From Console:

1. Login to the AWS Management Console:
2. Click `Services`.
3. Click `IAM`.
4. Click on `Users`
5. Click on `Security Credentials`.
6. As an Administrator
- Click on the X (Delete) for keys that were created at the same time as the user profile but have not been used.
7. As an IAM User
- Click on the X (Delete) for keys that were created at the same time as the user profile but have not been used.

### From Command Line:

```bash
for user in $(aws iam list-users --query 'Users[*].UserName' --output text);
do
# Get user creation date
user_create_date=$(aws iam get-user --user-name "$user" --query
'User.CreateDate' --output text)
# Get access keys
access_keys=$(aws iam list-access-keys --user-name "$user" --query
'AccessKeyMetadata' --output json)
# Only print if access keys exist
if [ "$access_keys" != "[]" ]; then
aws iam list-access-keys --user-name "$user" \
--query "AccessKeyMetadata[*].{UserName:'$user',
UserCreateDate:'$user_create_date', AccessKeyId:AccessKeyId,
AccessKeyCreateDate:CreateDate}" \
--output table
fi
done
```

### Default Value:

By default, when creating a new IAM user, AWS does not enable programmatic access or create access keys unless explicitly selected during user setup.
36 changes: 36 additions & 0 deletions cis_v600/docs/cis_v600_2_11.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
## Description

AWS IAM users can access AWS resources using different types of credentials, such as passwords or access keys. It is recommended that all credentials that have been unused for 45 days or more be deactivated or removed.

## Remediation

### From Console:

Perform the following to manage Unused Password (IAM user console access)

1. Login to the AWS Management Console:
2. Click `Services`.
3. Click `IAM`.
4. Click on `Users`.
5. Click on `Security Credentials`.
6. Select user whose `Console last sign-in` is greater than 45 days.
7. Click `Security credentials`.
8. In section `Sign-in credentials, Console password` click `Manage`.
9. Under Console Access select `Disable`.
10. Click `Apply`.

Perform the following to deactivate Access Keys:

1. Login to the AWS Management Console:
2. Click `Services`.
3. Click `IAM`.
4. Click on `Users`.
5. Click on `Security Credentials`.
6. Select any access keys that are over 45 days old and that have been used and
- Click on Make Inactive
7. Select any access keys that are over 45 days old and that have not been used and
- Click the X to Delete

### Default Value:

By default, AWS does not automatically disable or remove IAM user credentials based on age or last use. Console passwords and access keys remain active until manually deactivated or deleted.
41 changes: 41 additions & 0 deletions cis_v600/docs/cis_v600_2_12.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
## Description

Access keys are long-term credentials for an IAM user or the AWS account 'root' user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK)

## Remediation

### From Console:

1. Sign in to the AWS Management Console and navigate to IAM dashboard at https://console.aws.amazon.com/iam/.
2. In the left navigation panel, choose `Users`.
3. Click on the IAM user name that you want to examine.
4. On the IAM user configuration page, select `Security Credentials` tab.
5. In `Access Keys` section, choose one access key that is less than 90 days old. This should be the only active key used by this IAM user to access AWS resources programmatically. Test your application(s) to make sure that the chosen access key is working.
6. In the same `Access Keys` section, identify your non-operational access keys (other than the chosen one) and deactivate it by clicking the `Make Inactive` link.
7. If you receive the `Change Key Status` confirmation box, click `Deactivate` to switch off the selected key.
8. Repeat steps 3-7 for each IAM user in your AWS account.

### From Command Line:

1. Using the IAM user and access key information provided in the Audit CLI, choose one access key that is less than 90 days old. This should be the only active key used by this IAM user to access AWS resources programmatically. Test your application(s) to make sure that the chosen access key is working.
2. Run the `update-access-key` command below using the IAM user name and the non-operational access key IDs to deactivate the unnecessary key(s). Refer to the Audit section to identify the unnecessary access key ID for the selected IAM user.

**Note**: - the command does not return any output:

```bash
aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>
```

3. To confirm that the selected access key pair has been successfully deactivated run the list-access-keys audit command again for that IAM User:

```bash
aws iam list-access-keys --user-name <user-name>
```

- The command output should expose the metadata for each access key associated with the IAM user. If the non-operational key pair(s) Status is set to Inactive, the key has been successfully deactivated and the IAM user access configuration adheres now to this recommendation.

4. Repeat steps 1-3 for each IAM user in your AWS account.

### Default Value:

By default, an IAM user can have up to two active access keys at the same time. AWS does not restrict a user to a single active key unless explicitly managed.
40 changes: 40 additions & 0 deletions cis_v600/docs/cis_v600_2_13.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
## Description

Access keys consist of an access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. AWS users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services. It is recommended that all access keys be rotated regularly.

## Remediation

Perform the following to rotate access keys:

### From Console:

1. Go to the Management Console (https://console.aws.amazon.com/iam).
2. Click on `Users`.
3. Click on `Security Credentials`.
4. As an Administrator.
- Click on `Make Inactive` for keys that have not been rotated in 90 Days
5. As an IAM User
- Click on `Make Inactive` or `Delete` for keys which have not been rotated or used in 90 Days
6. Click on `Create Access Key`.
7. Update programmatic calls with new Access Key credentials.

### From Command Line:

1. While the first access key is still active, create a second access key, which is active by default. Run the following command:
2. aws iam create-access-key --user-name `<iam_user>`
At this point, the user has two active access keys.
3. Update all applications and tools to use the new access key.
4. Determine whether the first access key is still in use by using this command:
5. aws iam get-access-key-last-used --access-key-id `<iam_access_key_id>`
6. One approach is to wait several days and then check the old access key for any use before proceeding.

Even if step 3 indicates no use of the old key, it is recommended that you do not immediately delete the first access key. Instead, change the state of the first access key to Inactive using this command:

5. Use only the new access key to confirm that your applications are working. Any applications and tools that still use the original access key will stop working at this point because they no longer have access to AWS resources. If you find such an application or tool, you can switch its state back to Active to reenable the
first access key. Then return to step 2 and update this application to use the new key.
6. After you wait some period of time to ensure that all applications and tools have been updated, you can delete the first access key with this command:
7. aws iam delete-access-key --user-name <iam_user> --access-key-id <iam_access_key_id>

### Default Value:

By default, AWS does not enforce access key rotation. Access keys remain valid until they are manually deactivated or deleted.
Loading