diff --git a/cis_v140/docs/cis_v140_2_3_1.md b/cis_v140/docs/cis_v140_2_3_1.md index f3ea700d..e8cb87ca 100644 --- a/cis_v140/docs/cis_v140_2_3_1.md +++ b/cis_v140/docs/cis_v140_2_3_1.md @@ -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. diff --git a/cis_v600/cis.pp b/cis_v600/cis.pp new file mode 100644 index 00000000..16322397 --- /dev/null +++ b/cis_v600/cis.pp @@ -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" + }) +} diff --git a/cis_v600/docs/cis_overview.md b/cis_v600/docs/cis_overview.md new file mode 100644 index 00000000..78502304 --- /dev/null +++ b/cis_v600/docs/cis_overview.md @@ -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 \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2.md b/cis_v600/docs/cis_v600_2.md new file mode 100644 index 00000000..47ec3e90 --- /dev/null +++ b/cis_v600/docs/cis_v600_2.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring identity and access management related options. diff --git a/cis_v600/docs/cis_v600_2_1.md b/cis_v600/docs/cis_v600_2_1.md new file mode 100644 index 00000000..510a628d --- /dev/null +++ b/cis_v600/docs/cis_v600_2_1.md @@ -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": "", + "AddressLine2": "", + "City": "", + "CompanyName": "", + "CountryCode": "", + "FullName": "", + "PhoneNumber": "", + "PostalCode": "", + "StateOrRegion": "" +}' +``` + +### 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. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_10.md b/cis_v600/docs/cis_v600_2_10.md new file mode 100644 index 00000000..81fdfd64 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_10.md @@ -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. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_11.md b/cis_v600/docs/cis_v600_2_11.md new file mode 100644 index 00000000..0d02eb49 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_11.md @@ -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. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_12.md b/cis_v600/docs/cis_v600_2_12.md new file mode 100644 index 00000000..27ecce48 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_12.md @@ -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 --status Inactive --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 +``` + +- 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. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_13.md b/cis_v600/docs/cis_v600_2_13.md new file mode 100644 index 00000000..26e65f67 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_13.md @@ -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 `` +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 `` +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 --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. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_14.md b/cis_v600/docs/cis_v600_2_14.md new file mode 100644 index 00000000..9f025c89 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_14.md @@ -0,0 +1,70 @@ +## Description + +IAM users are granted access to services, functions, and data through IAM policies. There are four ways to define policies for a user: 1) Edit the user policy directly, also known as an inline or user policy; 2) attach a policy directly to a user; 3) add the user to an IAM group that has an attached policy; 4) add the user to an IAM group that has an inline policy. + +Only the third implementation is recommended. + +## Remediation + +### From Console: + +Perform the following to create an IAM group and assign a policy to it: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. +2. In the navigation pane, click `Groups` and then click `Create New Group.` +3. In the `Group Name` box, type the name of the group and then click `Next Step`. +4. In the list of policies, select the check box for each policy that you want to apply to all members of the group. Then click `Next Step`. +5. Click `Create Group`. + +Perform the following to add a user to a given group: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. +2. In the navigation pane, click `Groups`. +3. Select the group to add a user to. +4. Click `Add Users To Group.` +5. Select the users to be added to the group. +6. Click `Add Users`. + +Perform the following to remove a direct association between a user and policy: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. +2. In the left navigation pane, click on Users. +3. For each user: + - Select the user + - Click on the Permissions tab + - Expand Permissions policies Click X for each policy; then click Detach or Remove (depending on policy type) + +### From Command Line: + +1. Create the IAM user group: + +```bash +aws iam create-group --group-name +``` +2. Attach the policy to the IAM user group: + +```bash +aws iam attach-group-policy --group-name --policy-arn +``` + +3. Perform the following to add a user to a given group: + +```bash +aws iam add-user-to-group --user-name --group-name +``` + +4. Perform the following to remove a direct association between a user and policy: + +```bash +aws iam detach-user-policy --user-name --policy-arn +``` + +5. Delete an inline policy from an IAM user: + +```bash +aws iam delete-user-policy --user-name --policy-name +``` + +### Default Value: + +By default, AWS allows IAM policies to be attached directly to users, groups, or roles. There is no restriction preventing direct user policies unless explicitly enforced by organizational standards. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_15.md b/cis_v600/docs/cis_v600_2_15.md new file mode 100644 index 00000000..9b9542ce --- /dev/null +++ b/cis_v600/docs/cis_v600_2_15.md @@ -0,0 +1,48 @@ +## Description + +IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered standard security advice to grant least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do, and then craft policies for them that allow the users to perform only those tasks, instead of granting full administrative privileges. + +## Remediation + +### From Console: + +Perform the following to detach the policy that has full administrative privileges: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. +2. In the navigation pane, click Policies and then search for the policy name found in the audit step. +3. Select the policy that needs to be deleted. +4. In the policy action menu, select `Detach`. +5. Select all Users, Groups, Roles that have this policy attached. +6. Click `Detach Policy`. +7. Select the newly detached policy and select `Delete`. + +### From Command Line: + +Perform the following to detach the policy that has full administrative privileges as found in the audit step: + +1. Lists all IAM users, groups, and roles that the specified managed policy is attached to. + +```bash +aws iam list-entities-for-policy --policy-arn +``` +2. Detach the policy from all IAM Users: + +```bash +aws iam detach-user-policy --user-name --policy-arn +``` + +3. Detach the policy from all IAM Groups: + +```bash +aws iam detach-group-policy --group-name --policy-arn +``` + +4. Detach the policy from all IAM Roles: + +```bash +aws iam detach-role-policy --role-name --policy-arn +``` + +### Default Value: + +By default, AWS allows the creation and attachment of IAM policies that grant full administrative privileges (i.e., "Effect": "Allow", "Action": "", "Resource": ""). No restriction exists unless enforced through organizational policy or service control policies (SCPs). \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_16.md b/cis_v600/docs/cis_v600_2_16.md new file mode 100644 index 00000000..bf771b62 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_16.md @@ -0,0 +1,44 @@ +## Description + +AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services. Create an IAM Role, with the appropriate policy assigned, to allow authorized users to manage incidents with AWS Support. + +## Remediation + +### From Console: + +1. From `All Services`, click `IAM`. +2. Under `Access Managemen`t, click `Policies`. +3. In the `Policies search field`, search for 'AWSSupportAccess'. +4. Click the policy name 'AWSSupportAccess'. +5. Click the `Entities Attached` menu and click `Attach`. +6. Add the appropriate role or roles and click `Attach policy`. + +### From Command Line: + + +1. Create an IAM role for managing incidents with AWS: + + - Create a trust relationship policy document that allows to manage AWS incidents, and save it locally as /tmp/TrustPolicy.json: + +```bash +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "" + }, + "Action": "sts:AssumeRole" + ] +} +``` + +2. Create the IAM role using the above trust policy: +3. aws iam create-role --role-name --assume-rolepolicy-document file:///tmp/TrustPolicy.json +4. Attach 'AWSSupportAccess' managed policy to the created IAM role: +5. aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AWSSupportAccess --role-name + +### Default Value: + +By default, AWS does not create a dedicated support role. IAM users and roles with sufficient privileges (such as AdministratorAccess) can access the Support Center unless a specific role with the AWSSupportAccess policy is created. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_17.md b/cis_v600/docs/cis_v600_2_17.md new file mode 100644 index 00000000..e4761d44 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_17.md @@ -0,0 +1,44 @@ +## Description + +AWS access from within AWS instances can be done by either encoding AWS keys into AWS API calls or by assigning the instance to a role which has an appropriate permissions policy for the required access. "AWS Access" means accessing the APIs of AWS in order to access AWS resources or manage AWS account resources. + +## Remediation + +### From Console: + +1. Sign in to the AWS Management Console and navigate to the EC2 dashboard at https://console.aws.amazon.com/ec2/. +2. In the left navigation panel, choose `Instances`. +3. Select the EC2 instance you want to modify. +4. Click `Actions`. +5. Click `Security`. +6. Click `Modify IAM role.` +7. Click `Create new IAM role` if a new IAM role is required. +8. Select the IAM role you want to attach to your instance in the `IAM role` dropdown. +9. Click `Update IAM role.` +10. Repeat steps 3 to 9 for each EC2 instance in your AWS account that requires an IAM role to be attached. + +### From Command Line: + +1. Run the describe-instances command to list all EC2 instance IDs in the selected AWS region: + +```bash +aws ec2 describe-instances --region --query 'Reservations[*].Instances[*].InstanceId' +``` + +2. Run the associate-iam-instance-profile command to attach an instance profile (which is attached to an IAM role) to the EC2 instance: + +```bash +aws ec2 associate-iam-instance-profile --region --instance-id --iam-instance-profile Name="Instance-Profile-Name" +``` + +3. Run the describe-instances command again for the recently modified EC2 instance. The command output should return the instance profile ARN and ID: + +```bash +aws ec2 describe-instances --region --instance-id --query 'Reservations[*].Instances[*].IamInstanceProfile' +``` + +4. Repeat steps 2 and 3 for each EC2 instance in your AWS account that requires an IAM role to be attached. + +### Default Value: + +By default, EC2 instances are launched without an IAM role attached. Applications running on the instance must use embedded credentials or manually assigned access keys unless an instance role is explicitly configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_18.md b/cis_v600/docs/cis_v600_2_18.md new file mode 100644 index 00000000..1718bf44 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_18.md @@ -0,0 +1,23 @@ +## Description + +To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS server certificate. You can use AWS Certificate Manager (ACM) or IAM to store and deploy server certificates. Use IAM as a certificate manager only when you must support HTTPS connections in a region that is not supported by ACM. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console. + +## Remediation + +### From Console: + +Removing expired certificates via AWS Management Console is not currently supported. To delete SSL/TLS certificates stored in IAM through the AWS API, use the Command Line Interface (CLI). + +### From Command Line: + +To delete an expired certificate, run the following command by replacing with the name of the certificate to delete: + +```bash +aws iam delete-server-certificate --server-certificate-name +``` + +When the preceding command is successful, it does not return any output. + +### Default Value: + +By default, expired SSL/TLS certificates stored in AWS IAM are not automatically deleted. Certificates remain in IAM until they are manually removed. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_19.md b/cis_v600/docs/cis_v600_2_19.md new file mode 100644 index 00000000..258ed330 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_19.md @@ -0,0 +1,36 @@ +## Description + +Enable the IAM External Access Analyzer regarding all resources in each active AWS region. + +IAM Access Analyzer is a technology introduced at AWS reinvent 2019. After the Analyzer is enabled in IAM, scan results are displayed on the console showing the accessible resources. Scans show resources that other accounts and federated users can access, such as KMS keys and IAM roles. The results allow you to determine whether an unintended user is permitted, making it easier for administrators to monitor least privilege access. Access Analyzer analyzes only the policies that are applied to resources in the same AWS Region. + +## Remediation + +### From Console: + +Perform the following to enable IAM Access Analyzer for IAM policies: + +1. Open the IAM console at https://console.aws.amazon.com/iam/. +2. Choose `Access analyzer.` +3. Choose `Create external access analyzer.` +4. On the `Create analyzer` page, confirm that the Region displayed is the Region where you want to enable Access Analyzer. +5. Optionally enter a name for the analyzer. +6. Optionally add any tags that you want to apply to the analyzer. +7. Choose `Create Analyzer.` +8. Repeat these step for each active region + +### From Command Line: + +Run the following command: + +```bash +aws accessanalyzer list-analyzers --type ORGANIZATION +``` + +Repeat this command for each active region. + +**Note**: The IAM Access Analyzer is successfully configured only when the account you use has the necessary permissions. + +### Default Value: + +By default, IAM External Access Analyzer is not enabled in any region. An analyzer must be explicitly created and activated for each region where monitoring is required. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_2.md b/cis_v600/docs/cis_v600_2_2.md new file mode 100644 index 00000000..8b425f97 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_2.md @@ -0,0 +1,28 @@ +## Description + +AWS provides customers with the option of specifying the contact information for account's security team. It is recommended that this information be provided. + +## Remediation + +Perform the following to establish security contact information: + +### From Console: + +1. Click on your account name at the top right corner of the console. +2. From the drop-down menu Click `My Account`. +3. Scroll down to the `Alternate Contacts` section. +4. Enter contact information in the `Security` section. + +### From Command Line: + +Run the following command with the following input parameters: --email-address, -- name, and --phone-number. + +```bash +aws account put-alternate-contact --alternate-contact-type SECURITY +``` + +**Note**: Consider specifying an internal email distribution list to ensure emails are regularly monitored by more than one individual. + +### Default Value: + +By default, no alternate security contact information is configured for an AWS account. If not specified, only the primary account contact provided at account creation will be used. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_20.md b/cis_v600/docs/cis_v600_2_20.md new file mode 100644 index 00000000..d31c2570 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_20.md @@ -0,0 +1,11 @@ +## Description + +In multi-account environments, IAM user centralization facilitates greater user control. User access beyond the initial account is then provided via role assumption. Centralization of users can be accomplished through federation with an external identity provider or through the use of AWS Organizations. + +## Remediation + +The remediation procedure will vary based on each individual organization's implementation of identity federation and/or AWS Organizations, with the acceptance criteria that no non-service IAM users and non-root accounts are present outside the account providing centralized IAM user management. + +### Default Value: + +By default, AWS accounts are created and managed independently. IAM users are local to each account unless centralized management is explicitly configured through identity federation or AWS Organizations. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_21.md b/cis_v600/docs/cis_v600_2_21.md new file mode 100644 index 00000000..702e8d60 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_21.md @@ -0,0 +1,16 @@ +## Description + +AWS CloudShell is a convenient way of running CLI commands against AWS services; a managed IAM policy ('AWSCloudShellFullAccess') provides full access to CloudShell, which allows file upload and download capability between a user's local system and the CloudShell environment. Within the CloudShell environment, a user has sudo permissions and can access the internet. Therefore, it is feasible to install file transfer software, for example, and move data from CloudShell to external internet servers. + +## Remediation + +### From Console: + +1. Open the IAM console at https://console.aws.amazon.com/iam/. +2. In the left pane, select Policies. +3. Search for and select AWSCloudShellFullAccess. +4. On the Entities attached tab, for each item, check the box and select Detach. + +### Default Value: + +By default, the AWS managed policy AWSCloudShellFullAccess exists but is not attached to any users, groups, or roles. It must be explicitly assigned to grant permissions. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_3.md b/cis_v600/docs/cis_v600_2_3.md new file mode 100644 index 00000000..c679bd71 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_3.md @@ -0,0 +1,21 @@ +## Description + +The 'root' user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the 'root' user account be deleted. + +## Remediation + +Perform the following to delete active 'root' user access keys. + +### From Console: + +1. Sign in to the AWS Management Console as 'root' and open the IAM console at https://console.aws.amazon.com/iam/. +2. Click on at the top right and select My Security Credentials from the drop down list. +3. On the pop out screen Click on `Continue to Security Credentials`. +4. Click on `Access Keys` (Access Key ID and Secret Access Key). +5. If there are active keys, under `Status`, click `Delete` (Note: Deleted keys cannot be recovered). + +**Note**: While a key can be made inactive, this inactive key will still show up in the CLI command from the audit procedure, and may lead to the root user being falsely flagged as being non-compliant. + +### Default Value: + +By default, the AWS root user has no access keys created. Access keys are only present if they have been explicitly generated by the account owner. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_4.md b/cis_v600/docs/cis_v600_2_4.md new file mode 100644 index 00000000..85430109 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_4.md @@ -0,0 +1,29 @@ +## Description + +The 'root' user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. + +**Note**: When virtual MFA is used for 'root' accounts, it is recommended that the device used is NOT a personal device, but rather a dedicated mobile device (tablet or phone) that is kept charged and secured, independent of any individual personal devices ("nonpersonal virtual MFA"). This lessens the risks of losing access to the MFA due to device loss, device trade-in, or if the individual owning the device is no longer employed at the company. + +Where an AWS Organization is using centralized root access, root credentials can be removed from member accounts. In that case it is neither possible nor necessary to configure root MFA in the member account. + +## Remediation + +**Note**: To manage MFA devices for the 'root' AWS account, you must use your 'root' account credentials to sign in to AWS. You cannot manage MFA devices for the 'root' account using other credentials. + +Perform the following to establish MFA for the 'root' user account: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/. +2. Choose `Dashboard` , and under `Security Status` , expand `Activate MFA` on your root account. +3. Choose `Activate MFA`. +4. In the wizard, choose `A virtual MFA` device and then choose Next Step . +5. IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the 'secret configuration key' that is available for manual entry on devices that do not support QR codes. +6. Open your virtual MFA application. (For a list of apps that you can use for hosting virtual MFA devices, see [Virtual MFA Applications](https://aws.amazon.com/iam/features/mfa/?audit=2019q1#Virtual_MFA_Applications).) If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device). +7. Determine whether the MFA app supports QR codes, and then do one of the following: + - Use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to Scan code, and then use the device's camera to scan the code. + - In the Manage MFA Device wizard, choose Show secret key for manual configuration, and then type the secret configuration key into your MFA application. + +When you are finished, the virtual MFA device starts generating one-time passwords. In the Manage MFA Device wizard, in the Authentication Code 1 box, type the one-time password that currently appears in the virtual MFA device. Wait up to 30 seconds for the device to generate a new one-time password. Then type the second one-time password into the Authentication Code 2 box. Choose Assign Virtual MFA. + +### Default Value: + +By default, the AWS root user does not have Multi-Factor Authentication (MFA) enabled. MFA must be explicitly configured after account creation. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_5.md b/cis_v600/docs/cis_v600_2_5.md new file mode 100644 index 00000000..486893d3 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_5.md @@ -0,0 +1,25 @@ +## Description + +The 'root' user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the 'root' user account be protected with a hardware MFA. + +Where an AWS Organization is using centralized root access, root credentials can be removed from member accounts. In that case it is neither possible nor necessary to configure root MFA in the member account. + +## Remediation + +**Note**: To manage MFA devices for the AWS 'root' user account, you must use your 'root' account credentials to sign in to AWS. You cannot manage MFA devices for the 'root' account using other credentials. + +Perform the following to establish a hardware MFA for the 'root' user account: + +1. Open the [AWS Management Console](https://us-west-2.console.aws.amazon.com/console/home?region=us-west-2) and sign in using your root user credentials. +2. On the right side of the navigation bar, choose your account name, and choose `Security credentials`. +3. In the `Multi-Factor Authentication (MFA)` section, choose Assign MFA device. +4. In the wizard, type a `Device nam`e, choose Authenticator app, and then choose Next.IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the secret configuration key that is available for manual entry on devices that do not support QR codes. +5. Open the virtual MFA app on the device.If the virtual MFA app supports multiple virtual MFA devices or accounts, choose the option to create a new virtual MFA device or account. +6. The easiest way to configure the app is to use the app to scan the QR code. If you cannot scan the code, you can type the configuration information manually. The QR code and secret configuration key generated by IAM are tied to your AWS accoun. To use the QR code to configure the virtual MFA device, from the wizard, choose Show QR code. Then follow the app instructions for scanning the code. For example, you might need to choose the camera icon or choose a command like Scan account barcode, and then use the device's camera to scan the QR code. To manual entry secret key on devices, in the `Set up device wizard`, choose `Show secret key`, and then type the secret key into your MFA app. +7. In the wizard, in the `MFA code 1` box, type the one-time password that currently appears in the virtual MFA device. Wait up to 30 seconds for the device to generate a new one-time password. Then type the second one-time password into the` MFA code 2` box. Choose `Add MFA.` + +Remediation for this recommendation is not available through AWS CLI. + +### Default Value: + +By default, the AWS root user does not have a hardware MFA device assigned. MFA must be explicitly configured, and if enabled by default it will be virtual (software-based), not hardware. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_6.md b/cis_v600/docs/cis_v600_2_6.md new file mode 100644 index 00000000..4b07342c --- /dev/null +++ b/cis_v600/docs/cis_v600_2_6.md @@ -0,0 +1,16 @@ +## Description + +With the creation of an AWS account, a 'root user' is created that cannot be disabled or deleted. That user has unrestricted access to and control over all resources in the AWS account. It is highly recommended that the use of this account be avoided for everyday tasks. + +## Remediation + +If you find that the 'root' user account is being used for daily activities, including administrative tasks that do not require the 'root' user: + +1. Change the 'root' user password. +2. Deactivate or delete any access keys associated with the 'root' user + +Remember, anyone who has 'root' user credentials for your AWS account has unrestricted access to and control of all the resources in your account, including billing information. + +### Default Value: + +By default, the AWS root user is created with full administrative privileges and no restrictions. The root account remains permanently enabled and can perform all actions in the account unless explicitly limited by using alternative IAM users and roles. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_7.md b/cis_v600/docs/cis_v600_2_7.md new file mode 100644 index 00000000..c8f52925 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_7.md @@ -0,0 +1,27 @@ +## Description + +Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are at least a given length. It is recommended that the password policy require a minimum password length 14. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### From Console: + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Select Account Settings on the Left Pane. +4. Set "Minimum password length" to 14 or greater. +5. Select "Apply password policy". + +### From Command Line: + +```bash +aws iam update-account-password-policy --minimum-password-length 14 +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. + +### Default Value: + +By default, the AWS IAM account password policy does not enforce any minimum password length. If configured, the default minimum length is 6 characters. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_8.md b/cis_v600/docs/cis_v600_2_8.md new file mode 100644 index 00000000..527d0620 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_8.md @@ -0,0 +1,27 @@ +## Description + +IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords. + +## Remediation + +Perform the following to set the password policy as prescribed: + +### From Console: + +1. Login to AWS Console (with appropriate permissions to View Identity Access Management Account Settings). +2. Go to IAM Service on the AWS Console. +3. Select Account Settings on the Left Pane. +4. Check "Prevent password reuse". +5. Set "Number of passwords to remember" is set to 24. + +### From Command Line: + +```bash +aws iam update-account-password-policy --password-reuse-prevention 24 +``` + +**Note**: All commands starting with "aws iam update-account-password-policy" can be combined into a single command. + +### Default Value: + +By default, the AWS IAM password policy does not prevent password reuse. No password history is remembered unless explicitly configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_2_9.md b/cis_v600/docs/cis_v600_2_9.md new file mode 100644 index 00000000..13d6b3a0 --- /dev/null +++ b/cis_v600/docs/cis_v600_2_9.md @@ -0,0 +1,31 @@ +## Description + +Multi-Factor Authentication (MFA) adds an extra layer of authentication assurance beyond traditional credentials. With MFA enabled, when a user signs in to the AWS Console, they will be prompted for their user name and password as well as for an authentication code from their physical or virtual MFA token. It is recommended that MFA be enabled for all accounts that have a console password. + +## Remediation + +Perform the following to enable MFA: + +### From Console: + +1. Sign in to the AWS Management Console and open the IAM console at 'https://console.aws.amazon.com/iam/'. +2. In the left pane, select `Users`. +3. In the `User Name` list, choose the name of the intended MFA user. +4. Choose the `Security Credentials` tab, and then choose Manage MFA Device. +5. In the `Manage MFA Device wizard`, choose `Virtual MFA` device, and then choose `Continue`. + +IAM generates and displays configuration information for the virtual MFA device, including a QR code graphic. The graphic is a representation of the 'secret configuration key' that is available for manual entry on devices that do not support QR codes. + +6. Open your virtual MFA application. (For a list of apps that you can use for hosting virtual MFA devices, see Virtual MFA Applications at https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications). If the virtual MFA application supports multiple accounts (multiple virtual MFA devices), choose the option to create a new account (a new virtual MFA device). +7. Determine whether the MFA app supports QR codes, and then do one of the following: + - Use the app to scan the QR code. For example, you might choose the camera icon or choose an option similar to Scan code, and then use the device's camera to scan the code. + - In the Manage MFA Device wizard, choose Show secret key for manual configuration, and then type the secret configuration key into your MFA application. + +When you are finished, the virtual MFA device starts generating one-time passwords. + +8. In the Manage MFA Device wizard, in the MFA Code 1 box, type the one-time password that currently appears in the virtual MFA device. Wait up to 30 seconds for the device to generate a new one-time password. Then type the second one-time password into the MFA Code 2 box. +9. Select Assign MFA. + +### Default Value: + +By default, IAM users with a console password do not have Multi-Factor Authentication (MFA) enabled. MFA must be explicitly configured on each user account. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3.md b/cis_v600/docs/cis_v600_3.md new file mode 100644 index 00000000..3c5a8812 --- /dev/null +++ b/cis_v600/docs/cis_v600_3.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Storage. diff --git a/cis_v600/docs/cis_v600_3_1.md b/cis_v600/docs/cis_v600_3_1.md new file mode 100644 index 00000000..4898b80f --- /dev/null +++ b/cis_v600/docs/cis_v600_3_1.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Simple Storage Service (S3) Buckets diff --git a/cis_v600/docs/cis_v600_3_1_1.md b/cis_v600/docs/cis_v600_3_1_1.md new file mode 100644 index 00000000..06b3ffcf --- /dev/null +++ b/cis_v600/docs/cis_v600_3_1_1.md @@ -0,0 +1,124 @@ +## Description + +At the Amazon S3 bucket level, you can configure permissions through a bucket policy, making the objects accessible only through HTTPS. + +By default, Amazon S3 allows both HTTP and HTTPS requests. To ensure that access to Amazon S3 objects is only permitted through HTTPS, you must explicitly deny HTTP requests. Bucket policies that allow HTTPS requests without explicitly denying HTTP requests will not comply with this recommendation. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and open the Amazon S3 console using [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). +2. Select the check box next to the Bucket. +3. Click on `Permissions.` +4. Click `Bucket Policy.` +5. Add either of the following to the existing policy, filling in the required information: + +```json +{ + "Sid": "", + "Effect": "Deny", + "Principal": "*", + "Action": "s3:*", + "Resource": "arn:aws:s3:::/*", + "Condition": { + "Bool": { + "aws:SecureTransport": "false" + } + } +} +``` + +or + +```json +{ + "Sid": "", + "Effect": "Deny", + "Principal": "*", + "Action": "s3:*", + "Resource": [ + "arn:aws:s3:::", + "arn:aws:s3:::/*" + ], + "Condition": { + "NumericLessThan": { + "s3:TlsVersion": "1.2" + } + } +} +``` + +6. Save. +7. Repeat for all the buckets in your AWS account that contain sensitive data. + +### From Console + +Using AWS Policy Generator: + +1. Repeat steps 1-4 above. +2. Click on `Policy Generator` at the bottom of the Bucket Policy Editor. +3. Select Policy Type +4. Add Statements: + - `Effect` = `Deny` + - `Principal` = `*` + - `AWS Service` = `Amazon S3` + - `Actions` = `*` + - `Amazon Resource Name` = `` +5. Generate Policy. +6. Copy the text and add it to the Bucket Policy. + +### From Command Line: + +1. Export the bucket policy to a json file: + +```bash +aws s3api get-bucket-policy --bucket --query Policy --output text > policy.json +``` + +2. Modify the policy.json file by adding either of the following: + +```json +{ + "Sid": "", + "Effect": "Deny", + "Principal": "*", + "Action": "s3:*", + "Resource": "arn:aws:s3:::/*", + "Condition": { + "Bool": { + "aws:SecureTransport": "false" + } + } +} +``` + +or + +```json +{ + "Sid": "", + "Effect": "Deny", + "Principal": "*", + "Action": "s3:*", + "Resource": [ + "arn:aws:s3:::", + "arn:aws:s3:::/*" + ], + "Condition": { + "NumericLessThan": { + "s3:TlsVersion": "1.2" + } + } +} +``` + +3. Apply this modified policy back to the S3 bucket: + +```bash +aws s3api put-bucket-policy --bucket --policy file://policy.json +``` + +### Default Value: + +By default, Amazon S3 accepts both HTTP and HTTPS requests. No bucket policy is applied to deny unencrypted (HTTP) access unless explicitly configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_1_2.md b/cis_v600/docs/cis_v600_3_1_2.md new file mode 100644 index 00000000..33c9a964 --- /dev/null +++ b/cis_v600/docs/cis_v600_3_1_2.md @@ -0,0 +1,26 @@ +## Description + +Once MFA Delete is enabled on your sensitive and classified S3 bucket, it requires the user to provide two forms of authentication. + +Adding MFA delete to an S3 bucket requires additional authentication when you change the version state of your bucket or delete an object version, adding another layer of security in the event your security credentials are compromised or unauthorized access is granted. + +## Remediation + +Perform the steps below to enable MFA delete on an S3 bucket: + +**Note**: + +- You cannot enable MFA Delete using the AWS Management Console; you must use the AWS CLI or API. +- You must use your 'root' account to enable MFA Delete on S3 buckets. + +### From Command line: + +1. Run the s3api `put-bucket-versioning` command: + +```bash +aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode” +``` + +### Default Value: + +By default, S3 bucket versioning is disabled, and MFA Delete is not enabled. Both must be explicitly configured, and MFA Delete can only be enabled using the root account via CLI or API. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_1_3.md b/cis_v600/docs/cis_v600_3_1_3.md new file mode 100644 index 00000000..0b375831 --- /dev/null +++ b/cis_v600/docs/cis_v600_3_1_3.md @@ -0,0 +1,44 @@ +## Description + +Amazon S3 buckets can contain sensitive data that, for security purposes, should be discovered, monitored, classified, and protected. Macie, along with other third-party tools, can automatically provide an inventory of Amazon S3 buckets. + +## Remediation + +Perform the steps below to enable and configure Amazon Macie: + +### From Console: + +1. Log on to the Macie console at https://console.aws.amazon.com/macie/. +2. Click Get `started`. +3. Click `Enable Macie.` + +Set up a repository for sensitive data discovery results: + +1. In the left pane, under Settings, click `Discovery results.` +2. Make sure `Create bucket` is selected. +3. Create a bucket and enter a name for it. The name must be unique across all S3 buckets, and it must start with a lowercase letter or a number. +4. Click `Advanced`. +5. For block all public access, make sure Yes is selected. +6. For KMS encryption, specify the AWS KMS key that you want to use to encrypt the results. The key must be a symmetric customer master key (CMK) that is in the same region as the S3 bucket. +7. Click `Save`. + +Create a job to discover sensitive data: + +1. In the left pane, click `S3 buckets`. Macie displays a list of all the S3 buckets for your account. +2. Check the box for each bucket that you want Macie to analyze as part of the job. +3. Click `Create job.` +4. Click `Quick create.` +5. For the Name and Description step, enter a name and, optionally, a description of the job. +6. Click `Next.` +7. For the Review and create step, click `Submit.` + +Review your findings: + +1. In the left pane, click `Findings`. +2. To view the details of a specific finding, choose any field other than the check box for the finding. + +If you are using a third-party tool to manage and protect your S3 data, follow the vendor documentation for implementing and configuring that tool. + +### Default Value: + +By default, Amazon S3 does not perform data discovery, classification, or monitoring. Services such as Amazon Macie or third-party tools must be explicitly enabled and configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_1_4.md b/cis_v600/docs/cis_v600_3_1_4.md new file mode 100644 index 00000000..01984fbe --- /dev/null +++ b/cis_v600/docs/cis_v600_3_1_4.md @@ -0,0 +1,53 @@ +## Description + +Amazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However, an IAM principal with sufficient S3 permissions can enable public access at the bucket and/or object level. While enabled, Block public access (bucket settings) prevents an individual bucket and its contained objects from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets and their contained objects from becoming publicly accessible across the entire account. + +## Remediation + +If utilizing Block Public Access (bucket settings) + +### From Console: + +1. Login to the AWS Management Console and open the Amazon S3 console using https://console.aws.amazon.com/s3/. +2. Select the check box next to a bucket. +3. Click 'Edit public access settings'. +4. Click 'Block all public access' +5. Repeat for all the buckets in your AWS account that contain sensitive data + +### From Command Line: + +1. List all of the S3 buckets: + +```bash +aws s3 ls +``` + +2. Enable Block Public Access on a specific bucket: + +```bash +aws s3api put-public-access-block --bucket --public-accessblock-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" +``` + +If utilizing Block Public Access (account settings) + +### From Console: + +If the output reads true for the separate configuration settings, then Block Public Access is enabled on the account. + +1. Login to the AWS Management Console and open the Amazon S3 console using https://console.aws.amazon.com/s3/. +2. Click `Block Public Access (account settings).` +3. Click `Edit` to change the block public access settings for all the buckets in your AWS account. +4. Update the settings and click Save. For details about each setting, pause on the `i` icons. +5. When you're asked for confirmation, enter `confirm`. Then click `Confirm` to save your changes. + +### From Command Line: + +To enable Block Public Access for this account, run the following command: + +```bash +aws s3api put-public-access-block --bucket --public-accessblock-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" +``` + +### Default Value: + +By default, new S3 buckets and objects are created with public access disabled, but the Block Public Access settings (at the bucket or account level) are not enforced. They must be explicitly enabled to prevent future public access changes. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_2.md b/cis_v600/docs/cis_v600_3_2.md new file mode 100644 index 00000000..8ce8af42 --- /dev/null +++ b/cis_v600/docs/cis_v600_3_2.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Relational Database Services (RDS) diff --git a/cis_v600/docs/cis_v600_3_2_1.md b/cis_v600/docs/cis_v600_3_2_1.md new file mode 100644 index 00000000..c6a36eac --- /dev/null +++ b/cis_v600/docs/cis_v600_3_2_1.md @@ -0,0 +1,90 @@ +## Description + +Amazon RDS encrypted DB instances use the industry-standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles the authentication of access and the decryption of your data transparently, with minimal impact on performance. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and open the RDS dashboard at https://console.aws.amazon.com/rds/. +2. In the left navigation panel, click on `Databases`. +3. Select the Database instance that needs to be encrypted. +4. Click the `Actions` button placed at the top right and select `Take Snapshot.` +5. On the Take Snapshot page, enter the name of the database for which you want to take a snapshot in the `Snapshot Name` field and click on `Take Snapshot.` +6. Select the newly created snapshot, click the `Action` button placed at the top right, and select `Copy snapshot` from the Action menu. +7. On the Make Copy of DB Snapshot page, perform the following: +- In the New DB Snapshot Identifier field, enter a name for the new snapshot. +- Check Copy Tags. The new snapshot must have the same tags as the source snapshot. +- Select Yes from the Enable Encryption dropdown list to enable encryption. You can choose to use the AWS default encryption key or a custom key from the Master Key dropdown list. +8. Click `Copy Snapshot` to create an encrypted copy of the selected instance's snapshot. +9. Select the new Snapshot Encrypted Copy and click the `Action` button located at the top right. Then, select the `Restore Snapshot` option from the Action menu. This will restore the encrypted snapshot to a new database instance. +10. On the Restore DB Instance page, enter a unique name for the new database instance in the DB Instance Identifier field. +11. Review the instance configuration details and click `Restore DB Instance.` +12. As the new instance provisioning process is completed, you can update the application configuration to refer to the endpoint of the new encrypted database instance. Once the database endpoint is changed at the application level, you can remove the unencrypted instance. + +### From Command Line: + +1. Run the describe-db-instances command to list the names of all RDS database instances in the selected AWS region. The command output should return database instance identifiers: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. Check if the specified RDS instance is encrypted. If it shows false, it means it is not yet encrypted: + +```bash +aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].StorageEncrypted' +``` + +3. Run the create-db-snapshot command to create a snapshot for a selected database instance. The command output will return the new snapshot with name DB Snapshot Name: + +```bash +aws rds create-db-snapshot --region --db-snapshot-identifier --db-instance-identifier +``` + +4. Now run the `list-aliases` command to list the KMS key aliases available in a specified region. The command output should return each `key alias` `currently available`. For our RDS encryption activation process, locate the ID of the AWS default KMS key: + +```bash +aws kms list-aliases --region +``` + +5. Run the copy-db-snapshot command using the default KMS key ID for the RDS instances returned earlier to create an encrypted copy of the database instance snapshot. The command output will return the encrypted instance snapshot configuration: + +```bash +aws rds copy-db-snapshot --region --source-db-snapshotidentifier --target-db-snapshot-identifier --copy-tags --kms-key-id +``` + +6. Run the restore-db-instance-from-db-snapshot command to restore the encrypted snapshot created in the previous step to a new database instance. If successful, the command output should return the configuration of the new encrypted database instance. If using the default VPC for the database network: + +```bash +aws rds restore-db-instance-from-db-snapshot --region --dbinstance-identifier --db-snapshot-identifier +``` +If you created your own VPC and Subnets, you need to create a DB subnet group: + +```bash +aws rds create-db-subnet-group --db-subnet-group-name - +-db-subnet-group-description --subnet-ids +'["","",""]' +``` + +Restore the encrypted snapshot to an RDS database instance using the specified DB subnet group. The new instance will be encrypted using the KMS key specified during the snapshot copy: + +```bash +aws rds restore-db-instance-from-db-snapshot --region --dbsubnet-group-name --db-instance-identifier --db-snapshot-identifier +``` + +7. Run the describe-db-instances command to list all RDS database names available in the selected AWS region. The output will return the database instance identifier names. Select the encrypted database name that we just created, db-name-encrypted: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +8. Run the describe-db-instances command again using the RDS instance identifier returned earlier to determine if the selected database instance is encrypted. The command output should indicate that the encryption status is True: + +```bash +aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].StorageEncrypted' +``` + +### Default Value: + +By default, Amazon RDS instances are created without encryption at rest. Encryption must be explicitly enabled at instance creation or by restoring from an encrypted snapshot. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_2_2.md b/cis_v600/docs/cis_v600_3_2_2.md new file mode 100644 index 00000000..72780ec6 --- /dev/null +++ b/cis_v600/docs/cis_v600_3_2_2.md @@ -0,0 +1,45 @@ +## Description + +Ensure that RDS database instances have the Auto Minor Version Upgrade flag enabled to automatically receive minor engine upgrades during the specified maintenance window. This way, RDS instances can obtain new features, bug fixes, and security patches for their database engines. + +## Remediation + +### From Console: + +1. Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/. +2. In the left navigation panel, click `Databases`. +3. Select the RDS instance that you want to update. +4. Click on the `Modify` button located at the top right side. +5. On the `Modify DB Instance: ` page, In the `Maintenance` section, select `Auto minor version upgrade` and click the `Yes` radio button. +6. At the bottom of the page, click `Continue`, and check `Apply Immediately` to apply the changes immediately, or select `Apply during the next scheduled maintenance window` to avoid any downtime. +7. Review the changes and click `Modify DB Instance.` The instance status should change from available to modifying and back to available. Once the feature is enabled, the `Auto Minor Version Upgrade` status should change to `Yes`. + +### From Command Line: + +1. Run the `describe-db-instances` command to list all RDS database instance names available in the selected AWS region: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. The command output should return each database instance identifier. +3. Run the `modify-db-instance` command to modify the configuration of a selected RDS instance. This command will apply the changes immediately. + +Remove `--apply-immediately` to apply changes during the next scheduled maintenance window and avoid any downtime: + +```bash +aws rds modify-db-instance --region --db-instance-identifier --auto-minor-version-upgrade --apply-immediately +``` + +4. The command output should reveal the new configuration metadata for the RDS instance, including the `AutoMinorVersionUpgrade` parameter value. +5. Run the `describe-db-instances` command to check if the Auto Minor Version Upgrade feature has been successfully enabled: + +```bash +aws rds describe-db-instances --region --db-instance-identifier --query 'DBInstances[*].AutoMinorVersionUpgrade' +``` + +6. The command output should return the feature's current status set to true, indicating that the feature is `enabled`, and that the minor engine upgrades will be applied to the selected RDS instance. + +### Default Value: + +By default, new Amazon RDS instances have the Auto Minor Version Upgrade option enabled, unless explicitly disabled at creation or modification. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_2_3.md b/cis_v600/docs/cis_v600_3_2_3.md new file mode 100644 index 00000000..e3e7b69b --- /dev/null +++ b/cis_v600/docs/cis_v600_3_2_3.md @@ -0,0 +1,47 @@ +## Description + +Ensure and verify that the RDS database instances provisioned in your AWS account restrict unauthorized access in order to minimize security risks. To restrict access to any RDS database instance, you must disable the Publicly Accessible flag for the database and update the VPC security group associated with the instance. + +## Remediation + +### From Console: + +1. Log in to the AWS management console and navigate to the RDS dashboard at https://console.aws.amazon.com/rds/. +2. Under the navigation panel, on the RDS dashboard, click `Databases`. +3. Select the RDS instance that you want to update. +4. Click `Modify` from the dashboard top menu. +5. On the Modify DB Instance panel, under the `Connectivity` section, click on `Additional connectivity configuration` and update the value for `Publicly Accessible` to `Not publicly accessible` to restrict public access. +6. Follow the below steps to update subnet configurations: + - Select the `Connectivity and security` tab, and click the VPC attribute value inside the `Networking` section. + - Select the `Details` tab from the VPC dashboard's bottom panel and click the Route table configuration attribute value. + - On the Route table details page, select the Routes tab from the dashboard's bottom panel and click `Edit routes.` + - On the Edit routes page, update the Destination of Target which is set to `igwxxxxx` and click `Save` routes. +7. On the Modify DB Instance panel, click Continue, and in the Scheduling of modifications section, perform one of the following actions based on your requirements: + - Select `Apply during the next scheduled maintenance window` to apply the changes automatically during the next scheduled maintenance window. + - Select `Apply immediately` to apply the changes right away. With this option, any pending modifications will be asynchronously applied as soon as possible, regardless of the maintenance window setting for this RDS database instance. Note that any changes available in the pending modifications queue are also applied. If any of the pending modifications require downtime, choosing this option can cause unexpected downtime for the application. +8. Repeat steps 3-7 for each RDS instance in the current region. +9. Change the AWS region from the navigation bar to repeat the process for other regions. + +### From Command Line: + +1. Run the `describe-db-instances` command to list all available RDS database identifiers in the selected AWS region: + +```bash +aws rds describe-db-instances --region --query 'DBInstances[*].DBInstanceIdentifier' +``` + +2. The command output should return each database instance identifier. +3. Run the `modify-db-instance` command to modify the configuration of a selected RDS instance, disabling the `Publicly Accessible `flag for that instance. This command uses the `apply-immediately` flag. If you want to avoid any downtime, the `--no-apply-immediately` flag can be used: + +```bash +aws rds modify-db-instance --region --db-instance-identifier --no-publicly-accessible --apply-immediately +``` + +4. The command output should reveal the `PubliclyAccessible` configuration under pending values, to be applied at the specified time. +5. Updating the Internet Gateway destination via the AWS CLI is not currently supported. To update information about the Internet Gateway, please use the AWS Console procedure. +6. Repeat steps 1-5 for each RDS instance provisioned in the current region. +7. Change the AWS region by using the --region filter to repeat the process for other regions. + +### Default Value: + +By default, new Amazon RDS instances are created with the Publicly Accessible setting disabled. However, this option can be explicitly enabled during instance creation or modification. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_2_4.md b/cis_v600/docs/cis_v600_3_2_4.md new file mode 100644 index 00000000..870a5576 --- /dev/null +++ b/cis_v600/docs/cis_v600_3_2_4.md @@ -0,0 +1,40 @@ +## Description + +Amazon RDS offers Multi-AZ deployments that provide enhanced availability and durability for your databases, using synchronous replication to replicate data to a standby instance in a different Availability Zone (AZ). In the event of an infrastructure failure, Amazon RDS automatically fails over to the standby to minimize downtime and ensure business continuity + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and open the RDS dashboard at [AWS RDS Console](https://console.aws.amazon.com/rds#). +2. In the left navigation pane, click on `Databases`. +3. Select the database instance that needs Multi-AZ deployment to be enabled. +4. Click the `Modify` button at the top right. +5. Scroll down to the `Availability & Durability` section. +6. Under` Multi-AZ deployment`, select `Yes` to enable. +7. Review the changes and click `Continue`. +8. On the `Review` page, choose `Apply immediately` to make the change without waiting for the next maintenance window, or Apply during the next `scheduled maintenance window.` +9. Click `Modify DB Instance` to apply the changes. + +### From Command Line: + +1. Run the following command to modify the RDS instance and enable Multi-AZ: + +```bash +aws rds modify-db-instance --region --db-instanceidentifier --multi-az --apply-immediately +``` + +2. Confirm that the Multi-AZ deployment is enabled by running the following command: + +```bash +aws rds describe-db-instances --region --db-instanceidentifier --query 'DBInstances[*] MultiAZ' +``` + +- If the output is True, Multi-AZ is enabled. +- If the output is False, Multi-AZ is not enabled. + +5. Repeat steps 1 and 2 to audit each RDS instance, and change regions to verify in other regions. + +### Default Value: + +By default, Amazon RDS instances are created as Single-AZ deployments. Multi-AZ must be explicitly enabled during instance creation or modification. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_3_3.md b/cis_v600/docs/cis_v600_3_3.md new file mode 100644 index 00000000..4ac1367b --- /dev/null +++ b/cis_v600/docs/cis_v600_3_3.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring Elastic File System (EFS) diff --git a/cis_v600/docs/cis_v600_3_3_1.md b/cis_v600/docs/cis_v600_3_3_1.md new file mode 100644 index 00000000..a2f0571d --- /dev/null +++ b/cis_v600/docs/cis_v600_3_3_1.md @@ -0,0 +1,65 @@ +## Description + +EFS data should be encrypted at rest using AWS KMS (Key Management Service). + +## Remediation + +It is important to note that EFS file system data-at-rest encryption must be turned on when creating the file system. If an EFS file system has been created without data-at-rest encryption enabled, then you must create another EFS file system with the correct configuration and transfer the data. + +Steps to create an EFS file system with data encrypted at rest: + +### From Console: + +1. Login to the AWS Management Console and Navigate to the `Elastic File System (EFS)` dashboard. +2. Select `File Systems` from the left navigation panel. +3. Click the `Create File System` button from the dashboard top menu to start the file system setup process. +4. On the `Configure file system access` configuration page, perform the following actions: + - Choose an appropriate VPC from the VPC dropdown list. + - Within the `Create mount targets` section, check the boxes for all of the Availability Zones (AZs) within the selected VPC. These will be your mount targets. + - Click `Next step` to continue. +5. Perform the following on the `Configure optional settings` page: + - Create `tags` to describe your new file system. + - Choose `performance mode` based on your requirements. + - Check the `Enable encryption` box and choose `aws/elasticfilesystem` from the `Select KMS master key` dropdown list to enable encryption for the new file system, using the default master key provided and managed by AWS KMS. + - Click `Next step` to continue. +6. Review the file system configuration details on the `review and create` page and then click `Create File System` to create your new AWS EFS file system. +7. Copy the data from the old unencrypted EFS file system onto the newly created encrypted file system. +8. Remove the unencrypted file system as soon as your data migration to the newly created encrypted file system is completed. +9. Change the AWS region from the navigation bar and repeat the entire process for the other AWS regions. + +### From CLI: + +1. Run the `describe-file-systems` command to view the configuration information for the selected unencrypted file system identified in the Audit steps: + +```bash +aws efs describe-file-systems --region --file-system-id +``` +2. The command output should return the configuration information. +3. To provision a new AWS EFS file system, you need to generate a universally unique identifier (UUID) to create the token required by the create-filesystem command. To create the required token, you can use a randomly generated UUID from "https://www.uuidgenerator.net". +4. Run the `create-file-system` command using the unique token created at the previous step: + +```bash +aws efs create-file-system --region --creation-token -- performance-mode generalPurpose --encrypted +``` + +5. The command output should return the new file system configuration metadata. +6. Run the `create-mount-target` command using the EFS file system ID returned from step 4 as the identifier and the ID of the Availability Zone (AZ) that will represent the mount target: + +```bash +aws efs create-mount-target --region --file-system-id --subnet-id +``` + +7. The command output should return the new mount target metadata. +8. Now you can mount your file system from an EC2 instance. +9. Copy the data from the old unencrypted EFS file system to the newly created encrypted file system. +10. Remove the unencrypted file system as soon as your data migration to the newly created encrypted file system is completed: + +```bash +aws efs delete-file-system --region --file-system-id +``` + +11.Change the AWS region by updating the --region and repeat the entire process for the other AWS regions. + +## Default Value: + +By default, when creating an EFS file system through the AWS Management Console, encryption at rest is enabled. When creating a file system using the AWS CLI, API, or SDKs, encryption is not enabled by default and must be explicitly specified. diff --git a/cis_v600/docs/cis_v600_4.md b/cis_v600/docs/cis_v600_4.md new file mode 100644 index 00000000..d395df78 --- /dev/null +++ b/cis_v600/docs/cis_v600_4.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS logging features diff --git a/cis_v600/docs/cis_v600_4_1.md b/cis_v600/docs/cis_v600_4_1.md new file mode 100644 index 00000000..3b6e6d90 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_1.md @@ -0,0 +1,43 @@ +## Description + +AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation). + +## Remediation + +Perform the following to enable global (Multi-region) CloudTrail logging: + +### From Console: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/cloudtrail. +2. Click on `Trails` in the left navigation pane. +3. Click `Get Started Now` if it is presented, then: + - Click `Add new trail.` + - Enter a trail name in the `Trail name` box. + - A trail created in the console is a multi-region trail by default. + - Specify an S3 bucket name in the `S3 bucket` box. + - Specify the AWS KMS alias under the `Log file SSE-KMS encryption `section, or create a new key. + - Click `Next`. +4. Ensure the `Management events` check box is selected. +5. Ensure both `Read` and `Write` are checked under API activity. +6. Click `Next`. +7. Review your trail settings and click `Create trail`. + +### From Command Line: + +Create a multi-region trail: + +```bash +aws cloudtrail create-trail --name --bucket-name --is-multi-region-trail +``` + +Enable multi-region on an existing trail: + +```bash +aws cloudtrail update-trail --name --is-multi-region-trail +``` + +**Note**: Creating a CloudTrail trail via the CLI without providing any overriding options configures all read and write Management Events to be logged by default. + +## Default Value: + +By default, CloudTrail is not enabled in any region. diff --git a/cis_v600/docs/cis_v600_4_2.md b/cis_v600/docs/cis_v600_4_2.md new file mode 100644 index 00000000..71ea9a7c --- /dev/null +++ b/cis_v600/docs/cis_v600_4_2.md @@ -0,0 +1,35 @@ +## Description + +CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or remained unchanged after CloudTrail delivered the log. It is recommended that file validation be enabled for all CloudTrails. + +## Remediation + +Perform the following to enable log file validation on a given trail: + +### From Console: + +1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/cloudtrail. +2. Click on `Trails` in the left navigation pane. +3. Click on the target trail. +4. Within the `General details` section, click `edit`. +5. Under `Advanced settings`, check the `enable` box under `Log file validation.` +6. Click `Save changes.` + +### From Command Line: + +Enable log file validation on a trail: + +```bash +aws cloudtrail update-trail --name --enable-log-file-validation +``` + +Note that periodic validation of logs using these digests can be carried out by running the following command: + +```bash +aws cloudtrail validate-logs --trail-arn --start-time + --end-time +``` + +## Default Value: + +By default, CloudTrail log file validation is not enabled. This means that while logs are still delivered to the designated S3 bucket, there is no mechanism in place to verify their integrity. Without validation, it is not possible to detect if log files have been altered, deleted, or tampered with after delivery. diff --git a/cis_v600/docs/cis_v600_4_3.md b/cis_v600/docs/cis_v600_4_3.md new file mode 100644 index 00000000..722f3795 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_3.md @@ -0,0 +1,56 @@ +## Description + +AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration items (AWS resources), relationships between configuration items (AWS resources), and any configuration changes between resources. It is recommended that AWS Config be enabled in all regions. + +## Remediation + +To implement AWS Config configuration: + +### From Console: + +1. Select the region you want to focus on in the top right of the console. +2. Click `Services`. +3. Click `Config`. +4. If a Config Recorder is enabled in this region, navigate to the Settings page from the navigation menu on the left-hand side. If a Config Recorder is not yet enabled in this region, select "Get Started". +5. Select "Record all resources supported in this region". +6. Choose to include global resources (IAM resources). +7. Specify an S3 bucket in the same account or in another managed AWS account. +8. Create an SNS Topic from the same AWS account or another managed AWS account. + +### From Command Line: + +1. Ensure there is an appropriate S3 bucket, SNS topic, and IAM role per the [AWS Config Service prerequisites](https://docs.aws.amazon.com/config/latest/developerguide/gs-cli-prereq.html). +2. Run this command to create a new configuration recorder: + +```bash +aws configservice put-configuration-recorder --configuration-recorder name=,roleARN=arn:aws:iam:::role/ --recording-group allSupported=true,includeGlobalResourceTypes=true +``` + +3. Create a delivery channel configuration file locally which specifies the channel attributes, populated from the prerequisites set up previously + +```json +{ + "name": "", + "s3BucketName": "", + "snsTopicARN": "arn:aws:sns:::", + "configSnapshotDeliveryProperties": { + "deliveryFrequency": "Twelve_Hours" + } +} +``` + +4. Run this command to create a new delivery channel, referencing the json configuration file made in the previous step: + +```bash +aws configservice put-delivery-channel --delivery-channel file://.json +``` + +5. Start the configuration recorder by running the following command: + +```bash +aws configservice start-configuration-recorder --configuration-recorder-name +``` + +## Default Value: + +By default, AWS Config is not enabled in any region. No configuration changes or resource relationships are tracked until a Config Recorder and Delivery Channel are set up, leaving organizations without historical records for security analysis, compliance auditing, or incident investigations. diff --git a/cis_v600/docs/cis_v600_4_4.md b/cis_v600/docs/cis_v600_4_4.md new file mode 100644 index 00000000..76e36431 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_4.md @@ -0,0 +1,53 @@ +## Description + +Server access logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. It is recommended that server access logging be enabled on the CloudTrail S3 bucket. + +## Remediation + +Perform the following to enable server access logging: + +### From Console: + +1. Sign in to the AWS Management Console and open the S3 console at https://console.aws.amazon.com/s3. +2. Under `All Buckets` click on the target S3 bucket. +3. Click on `Properties` in the top right of the console. +4. Under `Server access logging`, click `Edit`. +5. Configure bucket logging: +- Check the `Enabled` box. +- Select a Target Bucket from the list. +- Enter a Target Prefix. +6. Click `Save`. + +### From Command Line: + +1. Get the name of the S3 bucket that CloudTrail is logging to: + +```bash +aws cloudtrail describe-trails --region --query trailList[*].S3BucketName +``` + +2. Copy and add the target bucket name at ``, the prefix for the log file at `` and optionally add an email address in the following template, then save it as `.json`: + +```json +{ + "LoggingEnabled": { + "TargetBucket": "", + "TargetPrefix": "", + "TargetGrants": [ + { + "Grantee": { + "Type": "AmazonCustomerByEmail", + "EmailAddress": "" + }, + "Permission": "FULL_CONTROL" + } + ] + } +} +``` + +3. Run the `put-bucket-logging` command with bucket name and `.json` as input; for more information, refer to [put-bucket-logging:](https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-logging.html) + +## Default Value: + +By default, server access logging is disabled on S3 buckets, including those used for CloudTrail. Without enabling this setting, no record of access requests to the CloudTrail bucket is captured, leaving organizations without visibility into who accessed log files or how they were used. diff --git a/cis_v600/docs/cis_v600_4_5.md b/cis_v600/docs/cis_v600_4_5.md new file mode 100644 index 00000000..6d306de6 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_5.md @@ -0,0 +1,39 @@ +## Description + +AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer-created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS. + +## Remediation + +Perform the following to configure CloudTrail to use SSE-KMS: + +### From Console: + +1. Sign in to the AWS Management Console and open the CloudTrail console at https://console.aws.amazon.com/cloudtrail. +2. In the left navigation pane, choose `Trails`. +3. Click on a trail. +4. Under the `S3` section, click the edit button (pencil icon). +5. Click `Advanced`. +6. Select an existing CMK from the `KMS key Id` drop-down menu. +**Note**: Ensure the CMK is located in the same region as the S3 bucket. +**Note**: You will need to apply a KMS key policy on the selected CMK in order for CloudTrail, as a service, to encrypt and decrypt log files using the CMK provided. View the AWS documentation for editing the selected CMK Key policy. +7. Click `Save`. +8. You will see a notification message stating that you need to have decryption permissions on the specified KMS key to decrypt log files. +9. Click `Yes`. + +### From Command Line: + +Run the following command to specify a KMS key ID to use with a trail: + +```bash +aws cloudtrail update-trail --name --kms-key-id +``` + +Run the following command to attach a key policy to a specified KMS key: + +```bash +aws kms put-key-policy --key-id --policy +``` + +## Default Value: + +By default, CloudTrail logs are not encrypted with a KMS CMK. Logs may be encrypted with SSE-S3, but this does not provide the same level of control or auditing as KMS CMKs. diff --git a/cis_v600/docs/cis_v600_4_6.md b/cis_v600/docs/cis_v600_4_6.md new file mode 100644 index 00000000..dd7c9716 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_6.md @@ -0,0 +1,27 @@ +## Description + +AWS Key Management Service (KMS) allows customers to rotate the backing key, which is key material stored within the KMS that is tied to the key ID of the customercreated customer master key (CMK). The backing key is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all prior backing keys so that decryption of encrypted data can occur transparently. It is recommended that CMK key rotation be enabled for symmetric keys. Key rotation cannot be enabled for any asymmetric CMK. + +## Remediation + +### From Console: + +1. Sign in to the AWS Management Console and open the KMS console at: https://console.aws.amazon.com/kms. +2. In the left navigation pane, click `Customer-managed keys.` +3. Select a key with `Key spec = SYMMETRIC_DEFAULT` that does not have automatic rotation enabled. +4. Select the `Key rotation` tab. +5. Check the `Automatically rotate this KMS key every year` box. +6. Click `Save`. +7. Repeat steps 3–6 for all customer-managed CMKs that do not have automatic rotation enabled. + +### From Command Line: + +1. Run the following command to enable key rotation: + +```bash + aws kms enable-key-rotation --key-id +``` + +## Default Value: + +By default, automatic key rotation is disabled for customer-managed symmetric CMKs. Key rotation must be explicitly enabled after key creation. diff --git a/cis_v600/docs/cis_v600_4_7.md b/cis_v600/docs/cis_v600_4_7.md new file mode 100644 index 00000000..db59f432 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_7.md @@ -0,0 +1,106 @@ +## Description + +VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet "Rejects" for VPCs. + +## Remediation + +Perform the following to enable VPC Flow Logs: + +### From Console: + +1. Sign into the management console. +2. Select `Services`, then select `VPC`. +3. In the left navigation pane, select Your VPCs. +4. Select a VPC. +5. In the right pane, select the `Flow Logs` tab. +6. If no Flow Log exists, click `Create Flow Log.` +7. For Filter, select `Reject`. +8. Enter a `Role` and `Destination Log Group.` +9. Click `Create Log Flow.` +10. Click on `CloudWatch Logs Group.` + +**Note**: Setting the filter to "Reject" will dramatically reduce the accumulation of logging data for this recommendation and provide sufficient information for the purposes of breach detection, research, and remediation. However, during periods of least privilege security group engineering, setting the filter to "All" can be very helpful in discovering existing traffic flows required for the proper operation of an already running environment. + +### From Command Line: + +1. Create a policy document, name it `role_policy_document.json`, and paste the following content: + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "test", + "Effect": "Allow", + "Principal": { + "Service": "vpc-flow-logs.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] +} +``` + +2. Create another policy document, name it iam_policy.json, and paste the following content: + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "logs:CreateLogGroup", + "logs:CreateLogStream", + "logs:DescribeLogGroups", + "logs:DescribeLogStreams", + "logs:PutLogEvents", + "logs:GetLogEvents", + "logs:FilterLogEvents" + ], + "Resource": "*" + } + ] +} +``` + +3. Run the following command to create an IAM role: + +```bash +aws iam create-role --role-name --assume-role-policydocument file: role_policy_document.json +``` + +4. Run the following command to create an IAM policy: + +```bash +aws iam create-policy --policy-name --policy-document file://iam-policy.json +``` + +5. Run the `attach-group-policy` command, using the IAM policy ARN returned from the previous step to attach the policy to the IAM role: + +```bash +aws iam attach-group-policy --policy-arn arn:aws:iam:::policy/ --group-name +``` + +- If the command succeeds, no output is returned. + +6. Run the `describe-vpcs` command to get a list of VPCs in the selected region: + +```bash +aws ec2 describe-vpcs --region +``` + +- The command output should return a list of VPCs in the selected region. + +7. Run the `create-flow-logs` command to create a flow log for a VPC: + +```bash +aws ec2 create-flow-logs --resource-type VPC --resource-ids -- traffic-type REJECT --log-group-name --deliver-logspermission-arn +``` + +8. Repeat step 7 for other VPCs in the selected region. +9. Change the region by updating --region, and repeat the remediation procedure for each region. + +## Default Value: + +By default, VPC Flow Logs are not enabled for any newly created VPCs. Logging must be manually configured on a per-VPC basis. diff --git a/cis_v600/docs/cis_v600_4_8.md b/cis_v600/docs/cis_v600_4_8.md new file mode 100644 index 00000000..9d5b077b --- /dev/null +++ b/cis_v600/docs/cis_v600_4_8.md @@ -0,0 +1,33 @@ +## Description + +S3 object-level API operations, such as GetObject, DeleteObject, and PutObject, are referred to as data events. By default, CloudTrail trails do not log data events, so it is recommended to enable object-level logging for S3 buckets. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and navigate to the S3 dashboard at https://console.aws.amazon.com/s3/. +2. In the left navigation panel, click `buckets`, and then click the name of the S3 bucket you want to examine. +3. Click the `Properties` tab to see the bucket configuration in detail. +4. In the `AWS CloudTrail data events` section, select the trail name for recording activity. You can choose an existing trail or create a new one by clicking the `Configure in CloudTrail` button or navigating to the CloudTrail console. +5. Once the trail is selected, select the Data Events check box. +6. Select `S3` from the `Data event type` drop-down. +7. Select `Log all events` from the `Log selector template` drop-down. +8. Repeat steps 2-7 to enable object-level logging of write events for other S3 buckets. + +### From Command Line: + +1. To enable `object-level` data events logging for S3 buckets within your AWS account, run the `put-event-selectors` command using the name of the trail that you want to reconfigure as identifier: + +```bash +aws cloudtrail put-event-selectors --region --trail-name --event-selectors '[{ "ReadWriteType": "WriteOnly", "IncludeManagementEvents":true, "DataResources": [{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::/"] }] }]' +``` + +2. The command output will be `object-level` event trail configuration. +3. If you want to enable it for all buckets at once, change the Values parameter to `["arn:aws:s3"]` in the previous command. +4. Repeat step 1 for each s3 bucket to update `object-level` logging of write events. +5. Change the AWS region by updating the `--region` command parameter, and perform the process for the other regions. + +## Default Value: + +By default, CloudTrail does not log object-level (data event) API operations for S3 buckets. Data event logging must be explicitly enabled per trail and bucket. diff --git a/cis_v600/docs/cis_v600_4_9.md b/cis_v600/docs/cis_v600_4_9.md new file mode 100644 index 00000000..9cdac9e8 --- /dev/null +++ b/cis_v600/docs/cis_v600_4_9.md @@ -0,0 +1,34 @@ +## Description + +S3 object-level API operations, such as GetObject, DeleteObject, and PutObject, are referred to as data events. By default, CloudTrail trails do not log data events, so it is recommended to enable object-level logging for S3 buckets. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and navigate to S3 dashboard at https://console.aws.amazon.com/s3/. +2. In the left navigation panel, click `buckets` and then click the name of the S3 bucket that you want to examine. +3. Click the `Properties` tab to see the bucket configuration in detail. +4. In the AWS Cloud Trail data events section, select the trail name for recording activity. You can choose an existing trail or create a new one by clicking the Configure in CloudTrail button or navigating to the CloudTrail console. +5. Once the trail is selected, select the `Data Events` check box. +6. Select `S3` from the `Data event type` drop-down. +7. Select `Log all events` from the `Log selector template` drop-down. +8. Repeat steps 2-7 to enable object-level logging of read events for other S3 +buckets. + +### From Command Line: + +1. To enable `object-level` data events logging for S3 buckets within your AWS account, run the `put-event-selectors` command using the name of the trail that you want to reconfigure as identifier: + +```bash +aws cloudtrail put-event-selectors --region --trail-name --event-selectors '[{ "ReadWriteType": "ReadOnly", "IncludeManagementEvents":true, "DataResources": [{ "Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::/"] }] }]' +``` + +2. The command output will be `object-level` event trail configuration. +3. If you want to enable it for all buckets at once, change the Values parameter to ["arn:aws:s3"] in the previous command. +4. Repeat step 1 for each s3 bucket to update `object-level` logging of read events. +5. Change the AWS region by updating the `--region` command parameter, and perform the process for the other regions. + +## Default Value: + +By default, CloudTrail does not log S3 object-level (data) events; only management events are logged unless explicitly enabled. diff --git a/cis_v600/docs/cis_v600_5.md b/cis_v600/docs/cis_v600_5.md new file mode 100644 index 00000000..68953ac4 --- /dev/null +++ b/cis_v600/docs/cis_v600_5.md @@ -0,0 +1,5 @@ +## Overview + +This section contains recommendations for configuring AWS to assist with monitoring and responding to account activities. + +Metric filter-related recommendations in this section are dependent on the `Ensure CloudTrail is enabled in all regions` and Ensure `CloudTrail trails are integrated with CloudWatch Logs` recommendations in the "Logging" section. diff --git a/cis_v600/docs/cis_v600_5_1.md b/cis_v600/docs/cis_v600_5_1.md new file mode 100644 index 00000000..18130337 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_1.md @@ -0,0 +1,40 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for unauthorized API calls. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for unauthorized API calls and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name -- filter-name --metric-transformations metricName=unauthorized_api_calls_metric,metricNamespace=CISBenchmark,metricValue=1 --filter-pattern "{ ($.errorCode="*UnauthorizedOperation") || ($.errorCode ="AccessDenied*") && ($.sourceIPAddress!="delivery.logs.amazonaws.com") && ($.eventName!="HeadBucket") }" +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +3. Create an SNS subscription for the topic created in step 2: + +```bash + aws sns subscribe --topic-arn --protocol --notification-endpoint +``` +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name "unauthorized_api_calls_alarm" --metric-name "unauthorized_api_calls_metric" --statistic Sum --period 300 -- threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace "CISBenchmark" --alarm-actions +``` + +## Default Value: + +By default, no CloudWatch metric filters or alarms exist for unauthorized API calls. diff --git a/cis_v600/docs/cis_v600_5_10.md b/cis_v600/docs/cis_v600_5_10.md new file mode 100644 index 00000000..6c7ee019 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_10.md @@ -0,0 +1,47 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +Security groups are stateful packet filters that control ingress and egress traffic within a VPC. + +It is recommended that a metric filter and alarm be established to detect changes to security groups. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for security groups changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace="CISBenchmark",metricValue=1 --filter-pattern "{ ($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName = AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupEgress) || ($.eventName = CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) || ($.eventName = ModifySecurityGroupRules) }" +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace "CISBenchmark" --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs security group events (e.g., AuthorizeSecurityGroupIngress, DeleteSecurityGroup), but no CloudWatch metric filters or alarms exist. These changes are captured but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_11.md b/cis_v600/docs/cis_v600_5_11.md new file mode 100644 index 00000000..79de0b76 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_11.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets within a VPC. It is recommended that a metric filter and alarm be established for any changes made to NACLs. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for NACL changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = CreateNetworkAcl) || ($.eventName = CreateNetworkAclEntry) || ($.eventName = DeleteNetworkAcl) || ($.eventName = DeleteNetworkAclEntry) || ($.eventName = ReplaceNetworkAclEntry) || ($.eventName = ReplaceNetworkAclAssociation) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs NACL events (e.g., CreateNetworkAcl, ReplaceNetworkAclEntry), but no CloudWatch metric filters or alarms exist. These changes are captured but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_12.md b/cis_v600/docs/cis_v600_5_12.md new file mode 100644 index 00000000..c4bf98f0 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_12.md @@ -0,0 +1,59 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +Network gateways are required to send and receive traffic to a destination outside of a VPC. It is recommended that a metric filter and alarm be established for changes to network gateways. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for network gateways changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = CreateCustomerGateway) || ($.eventName = DeleteCustomerGateway) || ($.eventName = AttachInternetGateway) || ($.eventName = CreateInternetGateway) || ($.eventName = DeleteInternetGateway) || ($.eventName = DetachInternetGateway) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +5. Implement logging and alerting mechanisms: + +```bash +aws sns create-topic --name NetworkGatewayChangesAlerts +``` + +```bash +aws sns subscribe --topic-arn --protocol email --notification-endpoint +``` + +```bash +aws cloudwatch put-metric-alarm --alarm-name NetworkGatewayChangesAlarm --metric-name GatewayChanges --namespace AWS/EC2 --statistic Sum --period 300 --threshold 1 --comparisonoperator GreaterThanOrEqualToThreshold --evaluation-periods 1 --alarmactions +``` + +## Default Value: + +By default, CloudTrail logs gateway events (e.g., CreateInternetGateway, AttachInternetGateway), but no CloudWatch metric filters or alarms exist. These changes are recorded but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_13.md b/cis_v600/docs/cis_v600_5_13.md new file mode 100644 index 00000000..8756e4cb --- /dev/null +++ b/cis_v600/docs/cis_v600_5_13.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. Routing tables are used to route network traffic between subnets and to network gateways. + +It is recommended that a metric filter and alarm be established for changes to route tables. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for route table changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-pattern '{ ($.eventName = CreateRoute) || ($.eventName = CreateRouteTable) || ($.eventName = ReplaceRoute) || ($.eventName = ReplaceRouteTableAssociation) || ($.eventName = DeleteRouteTable) || ($.eventName = DeleteRoute) || ($.eventName = DisassociateRouteTable) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs route table events (e.g., CreateRoute, DeleteRouteTable), but no CloudWatch metric filters or alarms exist. These changes are captured but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_14.md b/cis_v600/docs/cis_v600_5_14.md new file mode 100644 index 00000000..d9bad99e --- /dev/null +++ b/cis_v600/docs/cis_v600_5_14.md @@ -0,0 +1,47 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is possible to have more than one VPC within an account; additionally, it is also possible to create a peer connection between two VPCs, enabling network traffic to route between them. + +It is recommended that a metric filter and alarm be established for changes made to VPCs. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for VPC changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = CreateVpc) || ($.eventName = DeleteVpc) || ($.eventName = ModifyVpcAttribute) || ($.eventName = AcceptVpcPeeringConnection) || ($.eventName = CreateVpcPeeringConnection) || ($.eventName = DeleteVpcPeeringConnection) || ($.eventName = RejectVpcPeeringConnection) || ($.eventName = AttachClassicLinkVpc) || ($.eventName = DetachClassicLinkVpc) || ($.eventName = DisableVpcClassicLink) || ($.eventName = EnableVpcClassicLink) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs VPC events (e.g., CreateVpc, DeleteVpc, CreateVpcPeeringConnection), but no CloudWatch metric filters or alarms exist. These changes are recorded but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_15.md b/cis_v600/docs/cis_v600_5_15.md new file mode 100644 index 00000000..1d78019a --- /dev/null +++ b/cis_v600/docs/cis_v600_5_15.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for changes made to AWS Organizations in the master AWS account. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for AWS Organizations changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = organizations.amazonaws.com) && (($.eventName = AcceptHandshake") || ($.eventName = "AttachPolicy") || ($.eventName = "CreateAccount") || ($.eventName = "CreateOrganizationalUnit") || ($.eventName = "CreatePolicy") || ($.eventName = "DeclineHandshake") || ($.eventName = "DeleteOrganization") || ($.eventName = "DeleteOrganizationalUnit") || ($.eventName = "DeletePolicy") || ($.eventName = "DetachPolicy") || ($.eventName = "DisablePolicyType") || ($.eventName = "EnablePolicyType") || ($.eventName = "InviteAccountToOrganization") || ($.eventName = "LeaveOrganization") || ($.eventName = "MoveAccount") || ($.eventName = "RemoveAccountFromOrganization") || ($.eventName = "UpdatePolicy") || ($.eventName = "UpdateOrganizationalUnit")) } +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs AWS Organizations events (e.g., CreateAccount, AttachPolicy, DeleteOrganization), but no CloudWatch metric filters or alarms exist. These changes are recorded but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_16.md b/cis_v600/docs/cis_v600_5_16.md new file mode 100644 index 00000000..68a82d7b --- /dev/null +++ b/cis_v600/docs/cis_v600_5_16.md @@ -0,0 +1,37 @@ +## Description + +Security Hub collects security data from various AWS accounts, services, and supported third-party partner products, helping you analyze your security trends and identify the highest-priority security issues. When you enable Security Hub, it begins to consume, aggregate, organize, and prioritize findings from the AWS services that you have enabled, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. + +You can also enable integrations with AWS partner security products. + +## Remediation + +To grant the permissions required to enable Security Hub, attach the Security Hub managed policy `AWSSecurityHubFullAccess` to an IAM user, group, or role. + +Enabling Security Hub: + +### From Console: + +1. Use the credentials of the IAM identity to sign in to the Security Hub console. +2. When you open the Security Hub console for the first time, choose `Go to Security Hub.` +3. The `Security standards` section on the welcome page lists supported security +standards. Check the box for a standard to enable it. +4. Choose `Enable Security Hub.` + +### From Command Line: + +1. Run the `enable-security-hub` command, including `--enable-defaultstandards` to enable the default standards: + +```bash +aws securityhub enable-security-hub --enable-default-standards +``` + +2. To enable Security Hub without the default standards, include `--no-enabledefault-standards:` + +```bash +aws securityhub enable-security-hub --no-enable-default-standards +``` + +## Default Value: + +By default, AWS Security Hub is not enabled. It must be manually set up in each region (and requires AWS Config) before findings can be aggregated or standards applied. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_2.md b/cis_v600/docs/cis_v600_5_2.md new file mode 100644 index 00000000..900b2dba --- /dev/null +++ b/cis_v600/docs/cis_v600_5_2.md @@ -0,0 +1,56 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for console logins that are not protected by multi-factor authentication (MFA). + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for AWS Management Console sign-ins without MFA and uses the `` taken from audit step 1. + +```bash +aws logs put-metric-filter --log-group-name --filter-name `` --metric-transformations metricName= ``,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed !="Yes") } +``` + +Or, to reduce false positives in case Single Sign-On (SSO) is used in the organization: + +```bash +aws logs put-metric-filter --log-group-name -- +filter-name `` --metric-transformations +metricName= ``,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern +'{ ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != +"Yes") && ($.userIdentity.type = "IAMUser") && +($.responseElements.ConsoleLogin = "Success") }' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash + aws cloudwatch put-metric-alarm --alarm-name `` --metric-name `` --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, no CloudWatch metric filters or alarms exist for console sign-ins without MFA. diff --git a/cis_v600/docs/cis_v600_5_3.md b/cis_v600/docs/cis_v600_5_3.md new file mode 100644 index 00000000..57e9ba9e --- /dev/null +++ b/cis_v600/docs/cis_v600_5_3.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for 'root' login attempts to detect unauthorized use or attempts to use the root account. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for 'root' account usage and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name `` --filter-name `` --metric-transformations metricName=`` ,metricNamespace='CISBenchmark',metricValue=1 -- filter-pattern '{ $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent"}' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name `` -- metric-name `` --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, no CloudWatch metric filters or alarms exist to monitor root account activity. Root usage is logged in CloudTrail, but proactive monitoring must be configured. diff --git a/cis_v600/docs/cis_v600_5_4.md b/cis_v600/docs/cis_v600_5_4.md new file mode 100644 index 00000000..c930effd --- /dev/null +++ b/cis_v600/docs/cis_v600_5_4.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for changes made to Identity and Access Management (IAM) policies. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for IAM policy changes and the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name `` --filter-name `` --metric-transformations metricName=``,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{($.eventName=DeleteGroupPolicy)||($.eventName=DeleteRolePolicy)||($.eventName=DeleteUserPolicy)||($.eventName=PutGroupPolicy)||($.eventName=PutRolePolicy)||($.eventName=PutUserPolicy)||($.eventName=CreatePolicy)||($.eventName=DeletePolicy)||($.eventName=CreatePolicyVersion)||($.eventName=DeletePolicyVersion)||($.eventName=AttachRolePolicy)||($.eventName=DetachRolePolicy)||($.eventName=AttachUserPolicy)||($.eventName=DetachUserPolicy)||($.eventName=AttachGroupPolicy)||($.eventName=DetachGroupPolicy)}' +``` + +**Note**: You can choose your own metricName and metricNamespace strings. Using the same metricNamespace for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name `` -- metric-name `` --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail records IAM policy change events, but no CloudWatch metric filters or alarms are configured. This means changes (e.g., CreatePolicy, AttachRolePolicy, DeletePolicy) are logged but not actively monitored or alerted on unless you explicitly set up filters and alarms. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_5.md b/cis_v600/docs/cis_v600_5_5.md new file mode 100644 index 00000000..cd8d0694 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_5.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be used to detect changes to CloudTrail's configurations. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for CloudTrail configuration changes and the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern'{ ($.eventName = CreateTrail) || ($.eventName = UpdateTrail) || ($.eventName = DeleteTrail) || ($.eventName = StartLogging) || ($.eventName = StopLogging) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs configuration change events (e.g., CreateTrail, UpdateTrail, DeleteTrail, StartLogging, StopLogging), but no CloudWatch metric filters or alarms are set up. This means changes are recorded in CloudTrail, yet they are not actively monitored or alerted on unless filters and alarms are manually configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_6.md b/cis_v600/docs/cis_v600_5_6.md new file mode 100644 index 00000000..d11c7237 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_6.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for failed console authentication attempts. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for AWS management Console login failures and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs failed console authentication attempts, but no CloudWatch metric filters or alarms are configured. This means failed sign-in events are recorded, yet they are not proactively monitored or alerted on until filters and alarms are explicitly set up. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_7.md b/cis_v600/docs/cis_v600_5_7.md new file mode 100644 index 00000000..011715fd --- /dev/null +++ b/cis_v600/docs/cis_v600_5_7.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for customer-created CMKs that have changed state to disabled or are scheduled for deletion. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for CMKs that have been disabled or scheduled for deletion and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metrictransformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{($.eventSource = kms.amazonaws.com) && (($.eventName=DisableKey)||($.eventName=ScheduleKeyDeletion)) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2; you will need it in step 3 to create the subscription and in step 4 to associate the alarm. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operatorGreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs KMS events (DisableKey, ScheduleKeyDeletion), but no CloudWatch metric filters or alarms are set. These changes are recorded but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_8.md b/cis_v600/docs/cis_v600_5_8.md new file mode 100644 index 00000000..37807b4d --- /dev/null +++ b/cis_v600/docs/cis_v600_5_8.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for changes to S3 bucket policies. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for changes to S3 bucket policies and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = s3.amazonaws.com) && (($.eventName = PutBucketAcl) || ($.eventName = PutBucketPolicy) || ($.eventName = PutBucketCors) || ($.eventName = PutBucketLifecycle) || ($.eventName = PutBucketReplication) || ($.eventName = DeleteBucketPolicy) || ($.eventName = DeleteBucketCors) || ($.eventName = DeleteBucketLifecycle) || ($.eventName = DeleteBucketReplication)) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the `TopicArn` that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs S3 bucket policy changes (e.g., PutBucketPolicy, DeleteBucketPolicy), but no CloudWatch metric filters or alarms exist. These events are recorded but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_5_9.md b/cis_v600/docs/cis_v600_5_9.md new file mode 100644 index 00000000..ddd7d2e5 --- /dev/null +++ b/cis_v600/docs/cis_v600_5_9.md @@ -0,0 +1,45 @@ +## Description + +Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. + +It is recommended that a metric filter and alarm be established for detecting changes to AWS Config's configurations. + +## Remediation + +If you are using CloudTrail trails and CloudWatch, perform the following steps to set up the metric filter, alarm, SNS topic, and subscription: + +1. Create a metric filter based on the provided filter pattern that checks for AWS Configuration changes and uses the `` taken from audit step 1: + +```bash +aws logs put-metric-filter --log-group-name --filter-name --metric-transformations metricName=,metricNamespace='CISBenchmark',metricValue=1 --filter-pattern '{ ($.eventSource = config.amazonaws.com) && (($.eventName=StopConfigurationRecorder)||($.eventName=DeleteDeliveryChannel)||($.eventName=PutDeliveryChannel)||($.eventName=PutConfigurationRecorder)) }' +``` + +**Note**: You can choose your own `metricName` and `metricNamespace` strings. Using the same `metricNamespace` for all Foundations Benchmark metrics will group them together. + +2. Create an SNS topic that the alarm will notify: + +```bash +aws sns create-topic --name +``` + +**Note**: You can execute this command once and then reuse the same topic for all monitoring alarms. + +**Note**: Capture the TopicArn that is displayed when creating the SNS topic in step 2. + +3. Create an SNS subscription for the topic created in step 2: + +```bash +aws sns subscribe --topic-arn --protocol --notification-endpoint +``` + +**Note**: You can execute this command once and then reuse the same subscription for all monitoring alarms. + +4. Create an alarm that is associated with the CloudWatch Logs metric filter created in step 1 and the SNS topic created in step 2: + +```bash +aws cloudwatch put-metric-alarm --alarm-name --metric-name --statistic Sum --period 300 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 1 --namespace 'CISBenchmark' --alarm-actions +``` + +## Default Value: + +By default, CloudTrail logs AWS Config events (e.g., StopConfigurationRecorder, DeleteDeliveryChannel), but no CloudWatch metric filters or alarms exist. These changes are captured but not actively monitored unless configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6.md b/cis_v600/docs/cis_v600_6.md new file mode 100644 index 00000000..d8c77d93 --- /dev/null +++ b/cis_v600/docs/cis_v600_6.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Elastic Compute Cloud (EC2) \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_1.md b/cis_v600/docs/cis_v600_6_1.md new file mode 100644 index 00000000..60ba7a19 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_1.md @@ -0,0 +1,3 @@ +## Overview + +This section contains recommendations for configuring AWS Elastic Compute Cloud (EC2) diff --git a/cis_v600/docs/cis_v600_6_1_1.md b/cis_v600/docs/cis_v600_6_1_1.md new file mode 100644 index 00000000..f392da80 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_1_1.md @@ -0,0 +1,32 @@ +## Description + +Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption at EBS volume creation is supported. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console and open the Amazon EC2 console using https://console.aws.amazon.com/ec2/. +2. Under `Account attributes`, click `Data protection and security.` +3. Under `EBS encryption`, Click `Manage`. +4. Check the `Enable` box to default encryption. +5. Click `Update EBS encryption.` +6. Repeat for each region in which EBS volume encryption is not enabled by default. + +**Note**: EBS volume encryption is configured per region. + +### From Command Line: + +1. Run the following command: + +```bash +aws --region ec2 enable-ebs-encryption-by-default +``` +2. Verify that `"EbsEncryptionByDefault": true`is displayed. +3. Repeat for each region in which EBS volume encryption is not enabled by default. + +**Note**: EBS volume encryption is configured per region. + +## Default Value: + +By default, EBS volume encryption is disabled. It must be manually enabled per region; otherwise, new EBS volumes are created unencrypted. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_1_2.md b/cis_v600/docs/cis_v600_6_1_2.md new file mode 100644 index 00000000..0b4bf364 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_1_2.md @@ -0,0 +1,38 @@ +## Description + +Common Internet File System (CIFS) is a network file-sharing protocol that allows systems to share files over a network. However, unrestricted CIFS access can expose your data to unauthorized users, leading to potential security risks. It is important to restrict CIFS access to only trusted networks and users to prevent unauthorized access and data breaches. + +## Remediation + +### From Console: + +1. Login to the AWS Management Console. +2. Navigate to the EC2 Dashboard and select the Security Groups section under `Network & Security.` +3. Identify the security group that allows unrestricted ingress on port 445. +4. Select the security group and click the `Edit Inbound Rules` button. +5. Locate the rule allowing unrestricted access on port 445 (typically listed as `0.0.0.0/0` or ::`/0`). +6. Modify the rule to restrict access to specific IP ranges or trusted networks only. +7. Save the changes to the security group. + + **Note**: EBS volume encryption is configured per region. + +### From Command Line: + +1. Run the following command to remove or modify the unrestricted rule for CIFS access: + +```bash +aws ec2 revoke-security-group-ingress --region --group-id --protocol tcp --port 445 --cidr 0.0.0.0/0 +``` + + - Optionally, run the authorise-security-group-ingress command to create a new rule, specifying a trusted CIDR range instead of 0.0.0.0/0. +2. Confirm the changes by describing the security group again and ensuring the unrestricted access rule has been removed or appropriately restricted: + +```bash +aws ec2 describe-security-groups --region --group-ids --query "SecurityGroups[*].IpPermissions[?((IpProtocol=='-1') || (FromPort<=\`445\` && ToPort>=\`445\`))].{IpProtocol:IpProtocol,FromPort:FromPort,ToPort:ToPort,CIDRv4:IpRanges[*].CidrIp,CIDRv6:Ipv6Ranges[*].CidrIpv6}" +``` + +3. Repeat the remediation for other security groups and regions as necessary. + +## Default Value: + +By default, security groups can allow unrestricted CIFS access (port 445) if configured, including 0.0.0.0/0 or ::/0. AWS does not automatically restrict this; controls must be set manually to limit access to trusted networks. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_2.md b/cis_v600/docs/cis_v600_6_2.md new file mode 100644 index 00000000..fd485e50 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_2.md @@ -0,0 +1,22 @@ +## Description + +The Network Access Control List (NACL) function provides stateless filtering of ingress and egress network traffic to AWS resources. It is recommended that no NACL allows unrestricted ingress access to remote server administration ports, such as SSH on port 22 and RDP on port 3389, using either the TCP (6), UDP (17), or ALL (-1) protocols. + +## Remediation + +### From Console: + +Perform the following steps to remediate a network ACL: + +1. Login to the AWS VPC Console at https://console.aws.amazon.com/vpc/home. +2. In the left pane, click `Network ACLs.` +3. For each network ACL that needs remediation, perform the following: + - Select the network ACL. + - Click the `Inbound Rules` tab. + - Click `Edit inbound rules.` + - Either (A) update the Source field to a range other than 0.0.0.0/0, or (B) click `Delete` to remove the offending inbound rule. +- Click `Save`. + +## Default Value: + +By default, NACLs start with rules that allow all inbound/ outbound traffic (or deny all if custom), and administrators may configure them to allow 0.0.0.0/0. AWS does not automatically restrict ports like SSH (22) or RDP (3389); controls must be set manually. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_3.md b/cis_v600/docs/cis_v600_6_3.md new file mode 100644 index 00000000..8e5f1d80 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_3.md @@ -0,0 +1,44 @@ +## Description + +Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH on port 22 and RDP on port 3389, using either the TCP (6), UDP (17), or ALL (-1) protocols. + +## Remediation + +### From Console: + +Perform the following to implement the prescribed state: + +1. Login to the AWS VPC Console at https://console.aws.amazon.com/vpc/home. +2. In the left pane, click `Security Groups.` +3. For each security group, perform the following: +- Select the security group. +- Click the `Inbound Rules` tab. +- Click the `Edit inbound rules` button. +- Identify the rules to be edited or removed. +- Either (A) update the Source field to a range other than 0.0.0.0/0, or (B) click `Delete` to remove the offending inbound rule. +- Click `Save` rules. + +### From Command Line: + +1. Check all security groups for insecure inbound rules allowing traffic from +0.0.0.0/0: + +```bash +aws ec2 describe-security-group-rules --query 'SecurityGroupRules[?CidrIpv4 == "0.0.0.0/0" && IsEgress == `false`]' --output json +``` + +2. Delete the insecure rule(s) based on their rule ID: + +```bash +aws ec2 delete-security-group-rules --group-id --security-group-rule-ids +``` + +3. Recreate necessary security group rules: + +```bash +aws ec2 authorize-security-group-ingress --group-id --protocol --port --cidr +``` + +## Default Value: + +By default, security groups may be configured to allow unrestricted ingress (0.0.0.0/0) on ports like SSH (22) or RDP (3389). AWS does not block this automatically; restrictions must be applied manually. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_4.md b/cis_v600/docs/cis_v600_6_4.md new file mode 100644 index 00000000..e6e07d41 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_4.md @@ -0,0 +1,43 @@ +## Description + +Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH on port 22 and RDP on port 3389. + +## Remediation + +### From Console: + +Perform the following to implement the prescribed state: + +1. Login to the AWS VPC Console at https://console.aws.amazon.com/vpc/home. +2. In the left pane, click `Security Groups.` +3. For each security group, perform the following: + - Select the security group. + - Click the `Inbound Rules` tab. + - Click the `Edit inbound rules` button. + - Identify the rules to be edited or removed. + - Either (A) update the Source field to a range other than ::/0, or (B) Click `Delete` to remove the offending inbound rule. + - Click `Save rules.` + +### From Command Line: + +1. Check all security groups for insecure inbound rules that allow traffic from ::/0 . + +```bash +aws ec2 describe-security-group-rules --query 'SecurityGroupRules[?CidrIpv6 == `::/0` && IsEgress == `false`]' --output json +``` + +2. Delete the insecure rule(s) based on the rule ID: + +```bash +aws ec2 delete-security-group-rules --group-id --security-group-rule-ids +``` + +3. Recreate necessary security group rules: + +```bash +aws ec2 authorize-security-group-ingress --group-id --protocol --port --cidr +``` + +## Default Value: + +By default, security groups may allow unrestricted IPv6 ingress (::/0) on ports like SSH (22) or RDP (3389). AWS does not block this automatically; restrictions must be applied manually. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_5.md b/cis_v600/docs/cis_v600_6_5.md new file mode 100644 index 00000000..1d9a9a17 --- /dev/null +++ b/cis_v600/docs/cis_v600_6_5.md @@ -0,0 +1,74 @@ +## Description + +A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If a security group is not specified when an instance is launched, it is automatically assigned to this default security group. Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that the default security group restrict all traffic, both inbound and outbound. + +The default VPC in every region should have its default security group updated to comply with the following: +- No inbound rules. +- No outbound rules. + +Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation. + + **Note**: When implementing this recommendation, VPC flow logging is invaluable in determining the least privilege port access required by systems to work properly, as it can log all packet acceptances and rejections occurring under the current security groups. This dramatically reduces the primary barrier to least privilege engineering by discovering the minimum ports required by systems in the environment. Even if the VPC flow logging recommendation in this benchmark is not adopted as a permanent security measure, it should be used during any period of discovery and engineering for least privileged security groups. + +## Remediation + +Perform the following to implement the prescribed state: + +### Security Group Members + +1. Identify AWS resources that exist within the default security group +2. Create a set of least-privilege security groups for those resources. +3. Place the resources in those security groups, removing the resources noted in step 1 from the default security group + +### From Console: + +1. Login to the AWS VPC Console at https://console.aws.amazon.com/vpc/home. +2. Repeat the following steps for all VPCs, including the default VPC in each AWS region: +3. In the left pane, click `Security Groups.` +4. For each default security group, perform the following: + - Select the `default` security group. + - Click the `Inbound Rules` tab. + - Remove any inbound rules. + - Click the `Outbound Rules` tab. + - Remove any Outbound rules. + +### From Command Line: + +1. List all default security groups in the specified region + +```bash +aws ec2 describe-security-groups --region --query 'SecurityGroups[?GroupName == `default`]' +``` + +2. Check if the inbound rules (IpPermissions) and outbound rules (IpPermissionsEgress) of the default security group are empty. If the rules are not empty, proceed and note down the Security Group ID (GroupId) of the security group with non-empty rules. +3. List the inbound security group rule IDs (SecurityGroupRuleId) + +```bash +aws ec2 describe-security-group-rules --region --query 'SecurityGroupRules[?GroupId == `` && IsEgress == `false`]' +``` + +4. Delete the inbound security group rules based on their rule IDs + +```bash +aws ec2 revoke-security-group-ingress --group-id --security-group-rule-ids +``` + +5. List the outbound security group rule IDs (SecurityGroupRuleId) + +```bash +aws ec2 describe-security-group-rules --region --query 'SecurityGroupRules[?GroupId == `` && IsEgress == `true`]' +``` + +6. Delete the outbound security group rules based on their rule IDs + +```bash +aws ec2 revoke-security-group-egress --group-id --security-group-rule-ids +``` + +### Recommended + +IAM groups allow you to edit the "name" field. After remediating default group rules for all VPCs in all regions, edit this field to add text similar to "DO NOT USE. DO NOT ADD RULES." + +## Default Value: + +By default, each VPC has a “default” security group that allows all outbound traffic and all traffic between resources within the group. No restrictions are enforced unless manually configured. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_6.md b/cis_v600/docs/cis_v600_6_6.md new file mode 100644 index 00000000..66ffc74e --- /dev/null +++ b/cis_v600/docs/cis_v600_6_6.md @@ -0,0 +1,25 @@ +## Description + +Once a VPC peering connection is established, routing tables must be updated to enable any connections between the peered VPCs. These routes can be as specific as desired, even allowing for the peering of a VPC to only a single host on the other side of the connection. + +## Remediation + +Remove and add route table entries to ensure that the least number of subnets or hosts required to accomplish the purpose of peering are routable. + +### From Command Line: + +1. For each `` that contains routes that are non-compliant with your routing policy (granting more access than desired), delete the non-compliant route: + +```bash +aws ec2 delete-route --route-table-id --destination-cidrblock +``` + +2. Create a new compliant route: + +```bash +aws ec2 create-route --route-table-id --destination-cidrblock --vpc-peering-connection-id +``` + +## Default Value: + +By default, AWS allows full routing between peered VPCs once routes are added. There is no automatic restriction to “least access”—administrators must manually scope routes to the minimum required CIDR blocks or hosts. \ No newline at end of file diff --git a/cis_v600/docs/cis_v600_6_7.md b/cis_v600/docs/cis_v600_6_7.md new file mode 100644 index 00000000..329e64cc --- /dev/null +++ b/cis_v600/docs/cis_v600_6_7.md @@ -0,0 +1,37 @@ +## Description + +When enabling the Metadata Service on AWS EC2 instances, users have the option of using either Instance Metadata Service Version 1 (IMDSv1; a request/response method) or Instance Metadata Service Version 2 (IMDSv2; a session-oriented method). + +## Remediation + +### From Console: + +1. Sign in to the AWS Management Console and navigate to the EC2 dashboard at https://console.aws.amazon.com/ec2/. +2. In the left navigation panel, under the `INSTANCES` section, choose `Instances`. +3. Select the EC2 instance that you want to examine. +4. Choose `Actions > Instance Settings > Modify instance metadata options`. +5. Set `Instance metadata service` to `Enable`. +6. Set `IMDSv2` to `Required`. +7. Repeat steps 1-6 to perform the remediation process for other EC2 instances in all applicable AWS region(s). + +### From Command Line: + +1. Run the `describe-instances` command, applying the appropriate filters to list the IDs of all existing EC2 instances currently available in the selected region: + +```bash +aws ec2 describe-instances --region --output table --query "Reservations[*].Instances[*].InstanceId" +``` + +2. The command output should return a table with the requested instance IDs. +3. Run the `modify-instance-metadata-options` command with an instance ID obtained from the previous step to update the Instance Metadata Version: + +```bash +aws ec2 modify-instance-metadata-options --instance-id --http-tokens required --region +``` + +4. Repeat steps 1-3 to perform the remediation process for other EC2 instances in the same AWS region. +5. Change the region by updating `--region` and repeat the process for other regions. + +## Default Value: + +By default, new EC2 instances support both IMDSv1 and IMDSv2. IMDSv1 (less secure) remains enabled unless explicitly restricted, so IMDSv2 must be manually required. \ No newline at end of file diff --git a/cis_v600/section_2.pp b/cis_v600/section_2.pp new file mode 100644 index 00000000..1ba850d5 --- /dev/null +++ b/cis_v600/section_2.pp @@ -0,0 +1,331 @@ +locals { + cis_v600_2_common_tags = merge(local.cis_v600_common_tags, { + cis_section_id = "2" + }) +} + +benchmark "cis_v600_2" { + title = "2 Identity and Access Management" + documentation = file("./cis_v600/docs/cis_v600_2.md") + children = [ + control.cis_v600_2_1, + control.cis_v600_2_2, + control.cis_v600_2_3, + control.cis_v600_2_4, + control.cis_v600_2_5, + control.cis_v600_2_6, + control.cis_v600_2_7, + control.cis_v600_2_8, + control.cis_v600_2_9, + control.cis_v600_2_10, + control.cis_v600_2_11, + control.cis_v600_2_12, + control.cis_v600_2_13, + control.cis_v600_2_14, + control.cis_v600_2_15, + control.cis_v600_2_16, + control.cis_v600_2_17, + control.cis_v600_2_18, + control.cis_v600_2_19, + control.cis_v600_2_20, + control.cis_v600_2_21 + ] + + tags = merge(local.cis_v600_2_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v600_2_1" { + title = "2.1 Maintain current contact details" + description = "Ensure contact email and telephone details for AWS accounts are current and map to more than one individual in your organization." + query = query.manual_control + documentation = file("./cis_v600/docs/cis_v600_2_1.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.1" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_2" { + title = "2.2 Ensure security contact information is registered" + description = "AWS provides customers with the option of specifying the contact information for account's security team. It is recommended that this information be provided." + query = query.account_alternate_contact_security_registered + documentation = file("./cis_v600/docs/cis_v600_2_2.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.2" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_3" { + title = "2.3 Ensure no 'root' user account access key exists" + description = "The 'root' user account is the most privileged user in an AWS account. AWS Access Keys provide programmatic access to a given AWS account. It is recommended that all access keys associated with the 'root' user account be deleted." + query = query.iam_root_user_no_access_keys + documentation = file("./cis_v600/docs/cis_v600_2_3.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_4" { + title = "2.4 Ensure MFA is enabled for the 'root' user account" + description = "The 'root' user account is the most privileged user in an AWS account. Multi-factor Authentication (MFA) adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device." + query = query.iam_root_user_account_console_access_mfa_enabled + documentation = file("./cis_v600/docs/cis_v600_2_4.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_5" { + title = "2.5 Ensure hardware MFA is enabled for the 'root' user account" + description = "The 'root' user account is the most privileged user in an AWS account. MFA adds an extra layer of protection on top of a username and password. With MFA enabled, when a user signs in to an AWS website, they will be prompted for their username and password as well as for an authentication code from their AWS MFA device. For Level 2, it is recommended that the 'root' user account be protected with a hardware MFA." + query = query.iam_root_user_hardware_mfa_enabled + documentation = file("./cis_v600/docs/cis_v600_2_5.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.5" + cis_level = "2" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_6" { + title = "2.6 Eliminate use of the 'root' user for administrative and daily tasks" + description = "With the creation of an AWS account, a 'root user' is created that cannot be disabled ordeleted. That user has unrestricted access to and control over all resources in the AWS account. It is highly recommended that the use of this account be avoided for everyday tasks." + query = query.iam_root_last_used + documentation = file("./cis_v600/docs/cis_v600_2_6.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.6" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_7" { + title = "2.7 Ensure IAM password policy requires minimum length of 14 or greater" + description = "Password policies are, in part, used to enforce password complexity requirements. IAM password policies can be used to ensure passwords are at least a given length. It is recommended that the password policy require a minimum password length 14." + query = query.iam_account_password_policy_min_length_14 + documentation = file("./cis_v600/docs/cis_v600_2_7.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.7" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_8" { + title = "2.8 Ensure IAM password policy prevents password reuse" + description = "IAM password policies can prevent the reuse of a given password by the same user. It is recommended that the password policy prevent the reuse of passwords." + query = query.iam_account_password_policy_reuse_24 + documentation = file("./cis_v600/docs/cis_v600_2_8.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.8" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_9" { + title = "2.9 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password" + description = "Multi-Factor Authentication (MFA) adds an extra layer of authentication assurance beyond traditional credentials. With MFA enabled, when a user signs in to the AWS Console, they will be prompted for their user name and password as well as for an authentication code from their physical or virtual MFA token. It is recommended that MFA be enabled for all accounts that have a console password." + query = query.iam_user_console_access_mfa_enabled + documentation = file("./cis_v600/docs/cis_v600_2_9.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.9" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_10" { + title = "2.10 Do not create access keys during initial setup for IAM users with a console password" + 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" + query = query.iam_user_access_keys_and_password_at_setup + documentation = file("./cis_v600/docs/cis_v600_2_10.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.10" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_11" { + title = "2.11 Ensure credentials unused for 45 days or more are disabled" + 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." + query = query.iam_user_unused_credentials_45 + documentation = file("./cis_v600/docs/cis_v600_2_11.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.11" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_12" { + title = "2.12 Ensure there is only one active access key for any single IAM user" + 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)" + query = query.iam_user_one_active_key + documentation = file("./cis_v600/docs/cis_v600_2_12.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.12" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_13" { + title = "2.13 Ensure access keys are rotated every 90 days or less" + 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 fo" + query = query.iam_user_access_key_age_90 + documentation = file("./cis_v600/docs/cis_v600_2_13.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.13" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_14" { + title = "2.14 Ensure IAM users receive permissions only through groups" + description = "IAM users are granted access to services, functions, and data through IAM policies. There are four ways to define policies for a user: 1) Edit the user policy directly, also known as an inline or user policy; 2) attach a policy directly to a user; 3) add the user to an IAM group that has an attached policy; 4) add the user to an IAM group that has an inline policy." + query = query.iam_user_no_inline_attached_policies + documentation = file("./cis_v600/docs/cis_v600_2_14.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.14" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_15" { + title = "2.15 Ensure IAM policies that allow full \"*:*\" administrative privileges are not attached" + description = "IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended and considered standard security advice to grant least privilege—that is, granting only the permissions required to perform a task. Determine what users need to do, and then craft policies for them that allow the users to perform only those tasks, instead of granting full administrative privileges." + query = query.iam_policy_all_attached_no_star_star + documentation = file("./cis_v600/docs/cis_v600_2_15.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.15" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_16" { + title = "2.16 Ensure a support role has been created to manage incidents with AWS Support" + description = "AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services. Create an IAM Role, with the appropriate policy assigned, to allow authorized users to manage incidents with AWS Support." + query = query.iam_support_role + documentation = file("./cis_v600/docs/cis_v600_2_16.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.16" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_17" { + title = "2.17 Ensure IAM instance roles are used for AWS resource access from instances" + description = "AWS access from within AWS instances can be done by either encoding AWS keys into AWS API calls or by assigning the instance to a role which has an appropriate permissions policy for the required access." + query = query.ec2_instance_using_iam_instance_role + documentation = file("./cis_v600/docs/cis_v600_2_17.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.17" + cis_level = "2" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_18" { + title = "2.18 Ensure that all expired SSL/TLS certificates stored in AWS IAM are removed" + description = "To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS server certificate. You can use AWS Certificate Manager (ACM) or IAM to store and deploy server certificates. Use IAM as a certificate manager only when you must support HTTPS connections in a region that is not supported by ACM. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all regions, but you must obtain your certificate from an external provider for use with AWS. You cannot upload an ACM certificate to IAM. Additionally, you cannot manage your certificates from the IAM Console." + query = query.iam_server_certificate_not_expired + documentation = file("./cis_v600/docs/cis_v600_2_18.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.18" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_19" { + title = "2.19 Ensure that IAM External Access Analyzer is enabled for all regions" + description = "Enable the IAM External Access Analyzer regarding all resources in each active AWS region." + query = query.iam_access_analyzer_enabled + documentation = file("./cis_v600/docs/cis_v600_2_19.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.19" + cis_level = "1" + cis_type = "automated" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_20" { + title = "2.20 Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments" + description = "In multi-account environments, IAM user centralization facilitates greater user control. User access beyond the initial account is then provided via role assumption. Centralization of users can be accomplished through federation with an external identity provider or through the use of AWS Organizations." + query = query.manual_control + documentation = file("./cis_v600/docs/cis_v600_2_20.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.20" + cis_level = "2" + cis_type = "manual" + service = "AWS/IAM" + }) +} + +control "cis_v600_2_21" { + title = "2.21 Ensure access to AWSCloudShellFullAccess is restricted" + description = "AWS CloudShell is a convenient way of running CLI commands against AWS services; a managed IAM policy ('AWSCloudShellFullAccess') provides full access to CloudShell, which allows file upload and download capability between a user's local system and the CloudShell environment. Within the CloudShell environment, a user has sudo permissions and can access the internet. Therefore, it is feasible to install file transfer software, for example, and move data from CloudShell to external internet servers." + query = query.iam_user_group_role_cloudshell_fullaccess_restricted + documentation = file("./cis_v600/docs/cis_v600_2_21.md") + + tags = merge(local.cis_v600_2_common_tags, { + cis_item_id = "2.21" + cis_level = "1" + cis_type = "manual" + service = "AWS/IAM" + }) +} diff --git a/cis_v600/section_3.pp b/cis_v600/section_3.pp new file mode 100644 index 00000000..04a16dfa --- /dev/null +++ b/cis_v600/section_3.pp @@ -0,0 +1,202 @@ +locals { + cis_v600_3_common_tags = merge(local.cis_v600_common_tags, { + cis_section_id = "3" + }) +} + +locals { + cis_v600_3_1_common_tags = merge(local.cis_v600_3_common_tags, { + cis_section_id = "3.1" + }) + cis_v600_3_2_common_tags = merge(local.cis_v600_3_common_tags, { + cis_section_id = "3.2" + }) + cis_v600_3_3_common_tags = merge(local.cis_v600_3_common_tags, { + cis_section_id = "3.3" + }) +} + +benchmark "cis_v600_3" { + title = "3 Storage" + documentation = file("./cis_v600/docs/cis_v600_3.md") + children = [ + benchmark.cis_v600_3_1, + benchmark.cis_v600_3_2, + benchmark.cis_v600_3_3 + ] + + tags = merge(local.cis_v600_3_common_tags, { + type = "Benchmark" + }) +} + +benchmark "cis_v600_3_1" { + title = "3.1 Simple Storage Service (S3)" + documentation = file("./cis_v600/docs/cis_v600_3_1.md") + children = [ + control.cis_v600_3_1_1, + control.cis_v600_3_1_2, + control.cis_v600_3_1_3, + control.cis_v600_3_1_4 + ] + + tags = merge(local.cis_v600_3_1_common_tags, { + service = "AWS/S3" + type = "Benchmark" + }) +} + +benchmark "cis_v600_3_2" { + title = "3.2 Relational Database Service (RDS)" + documentation = file("./cis_v600/docs/cis_v600_3_2.md") + children = [ + control.cis_v600_3_2_1, + control.cis_v600_3_2_2, + control.cis_v600_3_2_3, + control.cis_v600_3_2_4 + ] + + tags = merge(local.cis_v600_3_2_common_tags, { + service = "AWS/RDS" + type = "Benchmark" + }) +} + +benchmark "cis_v600_3_3" { + title = "3.3 Elastic File System (EFS)" + documentation = file("./cis_v600/docs/cis_v600_3_3.md") + children = [ + control.cis_v600_3_3_1 + ] + + tags = merge(local.cis_v600_3_3_common_tags, { + service = "AWS/EFS" + type = "Benchmark" + }) +} + +control "cis_v600_3_1_1" { + title = "3.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests" + description = "At the Amazon S3 bucket level, you can configure permissions through a bucket policy, making the objects accessible only through HTTPS." + query = query.s3_bucket_enforces_ssl + documentation = file("./cis_v600/docs/cis_v600_3_1_1.md") + + tags = merge(local.cis_v600_3_1_common_tags, { + cis_item_id = "3.1.1" + cis_level = "2" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v600_3_1_2" { + title = "3.1.2 Ensure MFA Delete is enabled on S3 buckets" + description = "Once MFA Delete is enabled on your sensitive and classified S3 bucket, it requires the user to provide two forms of authentication." + query = query.s3_bucket_mfa_delete_enabled + documentation = file("./cis_v600/docs/cis_v600_3_1_2.md") + + tags = merge(local.cis_v600_3_1_common_tags, { + cis_item_id = "3.1.2" + cis_level = "2" + cis_type = "manual" + service = "AWS/S3" + }) +} + +control "cis_v600_3_1_3" { + title = "3.1.3 Ensure all data in Amazon S3 has been discovered, classified, and secured when necessary" + description = "Amazon S3 buckets can contain sensitive data that, for security purposes, should be discovered, monitored, classified, and protected. Macie, along with other third-party tools, can automatically provide an inventory of Amazon S3 buckets." + query = query.s3_bucket_protected_by_macie + documentation = file("./cis_v600/docs/cis_v600_3_1_3.md") + + tags = merge(local.cis_v600_3_1_common_tags, { + cis_item_id = "3.1.3" + cis_level = "2" + cis_type = "manual" + service = "AWS/S3" + }) +} + +control "cis_v600_3_1_4" { + title = "3.1.4 Ensure that S3 is configured with 'Block Public Access' enabled" + description = "Amazon S3 provides Block public access (bucket settings) and Block public access (account settings) to help you manage public access to Amazon S3 resources. By default, S3 buckets and objects are created with public access disabled. However, an IAM principal with sufficient S3 permissions can enable public access at the bucket and/or object level. While enabled, Block public access (bucket settings) prevents an individual bucket and its contained objects from becoming publicly accessible. Similarly, Block public access (account settings) prevents all buckets and their contained objects from becoming publicly accessible across the entire account." + query = query.s3_public_access_block_bucket_account + documentation = file("./cis_v600/docs/cis_v600_3_1_4.md") + + tags = merge(local.cis_v600_3_1_common_tags, { + cis_item_id = "3.1.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/S3" + }) +} + +control "cis_v600_3_2_1" { + title = "3.2.1 Ensure that encryption-at-rest is enabled for RDS instances" + description = "Amazon RDS encrypted DB instances use the industry-standard AES-256 encryption algorithm to encrypt your data on the server that hosts your Amazon RDS DB instances. After your data is encrypted, Amazon RDS handles the authentication of access and the decryption of your data transparently, with minimal impact on performance." + query = query.rds_db_instance_encryption_at_rest_enabled + documentation = file("./cis_v600/docs/cis_v600_3_2_1.md") + + tags = merge(local.cis_v600_3_2_common_tags, { + cis_item_id = "3.2.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +control "cis_v600_3_2_2" { + title = "3.2.2 Ensure the Auto Minor Version Upgrade feature is enabled for RDS instances" + description = "Ensure that RDS database instances have the Auto Minor Version Upgrade flag enabled to automatically receive minor engine upgrades during the specified maintenance window. This way, RDS instances can obtain new features, bug fixes, and security patches for their database engines." + query = query.rds_db_instance_automatic_minor_version_upgrade_enabled + documentation = file("./cis_v600/docs/cis_v600_3_2_2.md") + + tags = merge(local.cis_v600_3_2_common_tags, { + cis_item_id = "3.2.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +control "cis_v600_3_2_3" { + title = "3.2.3 Ensure that RDS instances are not publicly accessible" + description = "Ensure and verify that the RDS database instances provisioned in your AWS account restrict unauthorized access in order to minimize security risks. To restrict access to any RDS database instance, you must disable the Publicly Accessible flag for the database and update the VPC security group associated with the instance." + query = query.rds_db_instance_prohibit_public_access + documentation = file("./cis_v600/docs/cis_v600_3_2_3.md") + + tags = merge(local.cis_v600_3_2_common_tags, { + cis_item_id = "3.2.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/RDS" + }) +} + +control "cis_v600_3_2_4" { + title = "3.2.4 Ensure Multi-AZ deployments are used for enhanced availability in Amazon RDS" + description = "Amazon RDS offers Multi-AZ deployments that provide enhanced availability and durability for your databases, using synchronous replication to replicate data to a standby instance in a different Availability Zone (AZ). In the event of an infrastructure failure, Amazon RDS automatically fails over to the standby to minimize downtime and ensure business continuity." + query = query.rds_db_instance_multiple_az_enabled + documentation = file("./cis_v600/docs/cis_v600_3_2_4.md") + + tags = merge(local.cis_v600_3_2_common_tags, { + cis_item_id = "3.2.4" + cis_level = "1" + cis_type = "manual" + service = "AWS/RDS" + }) +} + +control "cis_v600_3_3_1" { + title = "3.3.1 Ensure that encryption is enabled for EFS file systems" + description = "Encryption should be enabled for EFS file systems." + query = query.efs_file_system_encrypt_data_at_rest + documentation = file("./cis_v600/docs/cis_v600_3_3_1.md") + + tags = merge(local.cis_v600_3_3_common_tags, { + cis_item_id = "3.3.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/EFS" + }) +} diff --git a/cis_v600/section_4.pp b/cis_v600/section_4.pp new file mode 100644 index 00000000..b018e6ca --- /dev/null +++ b/cis_v600/section_4.pp @@ -0,0 +1,151 @@ +locals { + cis_v600_4_common_tags = merge(local.cis_v600_common_tags, { + cis_section_id = "4" + }) +} + +benchmark "cis_v600_4" { + title = "4 Logging" + documentation = file("./cis_v600/docs/cis_v600_4.md") + children = [ + control.cis_v600_4_1, + control.cis_v600_4_2, + control.cis_v600_4_3, + control.cis_v600_4_4, + control.cis_v600_4_5, + control.cis_v600_4_6, + control.cis_v600_4_7, + control.cis_v600_4_8, + control.cis_v600_4_9 + ] + + tags = merge(local.cis_v600_4_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v600_4_1" { + title = "4.1 Ensure CloudTrail is enabled in all regions" + description = "AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Console, SDKs, command line tools, and higher-level AWS services (such as CloudFormation)." + query = query.cloudtrail_multi_region_read_write_enabled + documentation = file("./cis_v600/docs/cis_v600_4_1.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.1" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudTrail" + }) +} + +control "cis_v600_4_2" { + title = "4.2 Ensure CloudTrail log file validation is enabled" + description = "CloudTrail log file validation creates a digitally signed digest file containing a hash of each log that CloudTrail writes to S3. These digest files can be used to determine whether a log file was changed, deleted, or remained unchanged after CloudTrail delivered the log. It is recommended that file validation be enabled for all CloudTrails." + query = query.cloudtrail_trail_validation_enabled + documentation = file("./cis_v600/docs/cis_v600_4_2.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.2" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v600_4_3" { + title = "4.3 Ensure AWS Config is enabled in all regions" + description = "AWS Config is a web service that performs configuration management of supported AWS resources within your account and delivers log files to you. The recorded information includes the configuration items (AWS resources), relationships between configuration items (AWS resources), and any configuration changes between resources. It is recommended that AWS Config be enabled in all regions." + query = query.config_enabled_all_regions + documentation = file("./cis_v600/docs/cis_v600_4_3.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.3" + cis_level = "2" + cis_type = "automated" + service = "AWS/Config" + }) +} + +control "cis_v600_4_4" { + title = "4.4 Ensure that server access logging is enabled on the CloudTrail S3 bucket" + description = "Server access logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed. It is recommended that server access logging be enabled on the CloudTrail S3 bucket." + query = query.cloudtrail_s3_logging_enabled + documentation = file("./cis_v600/docs/cis_v600_4_4.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.4" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudTrail" + }) +} + +control "cis_v600_4_5" { + title = "4.5 Ensure CloudTrail logs are encrypted at rest using KMS CMKs" + description = "AWS CloudTrail is a web service that records AWS API calls for an account and makes those logs available to users and resources in accordance with IAM policies. AWS Key Management Service (KMS) is a managed service that helps create and control the encryption keys used to encrypt account data, and uses Hardware Security Modules (HSMs) to protect the security of encryption keys. CloudTrail logs can be configured to leverage server side encryption (SSE) and KMS customer-created master keys (CMK) to further protect CloudTrail logs. It is recommended that CloudTrail be configured to use SSE-KMS." + query = query.cloudtrail_trail_logs_encrypted_with_kms_cmk + documentation = file("./cis_v600/docs/cis_v600_4_5.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.5" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v600_4_6" { + title = "4.6 Ensure rotation for customer-created symmetric CMKs is enabled" + description = "AWS Key Management Service (KMS) allows customers to rotate the backing key, which is key material stored within the KMS that is tied to the key ID of the customercreated customer master key (CMK). The backing key is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all prior backing keys so that decryption of encrypted data can occur transparently. It is recommended that CMK key rotation be enabled for symmetric keys. Key rotation cannot be enabled for any asymmetric CMK." + query = query.kms_cmk_rotation_enabled + documentation = file("./cis_v600/docs/cis_v600_4_6.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.6" + cis_level = "2" + cis_type = "automated" + service = "AWS/KMS" + }) +} + +control "cis_v600_4_7" { + title = "4.7 Ensure VPC flow logging is enabled in all VPCs" + description = "VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs. It is recommended that VPC Flow Logs be enabled for packet Rejects for VPCs." + query = query.vpc_flow_logs_enabled + documentation = file("./cis_v600/docs/cis_v600_4_7.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.7" + cis_level = "2" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v600_4_8" { + title = "4.8 Ensure that object-level logging for write events is enabled for S3 buckets" + description = "S3 object-level API operations, such as GetObject, DeleteObject, and PutObject, are referred to as data events. By default, CloudTrail trails do not log data events, so it is recommended to enable object-level logging for S3 buckets." + query = query.cloudtrail_s3_object_write_events_audit_enabled + documentation = file("./cis_v600/docs/cis_v600_4_8.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.8" + cis_level = "1" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} + +control "cis_v600_4_9" { + title = "4.9 Ensure that object-level logging for read events is enabled for S3 buckets" + description = "S3 object-level API operations, such as GetObject, DeleteObject, and PutObject, are referred to as data events. By default, CloudTrail trails do not log data events, so it is recommended to enable object-level logging for S3 buckets." + query = query.cloudtrail_s3_object_read_events_audit_enabled + documentation = file("./cis_v600/docs/cis_v600_4_9.md") + + tags = merge(local.cis_v600_4_common_tags, { + cis_item_id = "4.9" + cis_level = "2" + cis_type = "automated" + service = "AWS/CloudTrail" + }) +} diff --git a/cis_v600/section_5.pp b/cis_v600/section_5.pp new file mode 100644 index 00000000..10542bc4 --- /dev/null +++ b/cis_v600/section_5.pp @@ -0,0 +1,256 @@ +locals { + cis_v600_5_common_tags = merge(local.cis_v600_common_tags, { + cis_section_id = "5" + }) +} + +benchmark "cis_v600_5" { + title = "5 Monitoring" + documentation = file("./cis_v600/docs/cis_v600_5.md") + children = [ + control.cis_v600_5_1, + control.cis_v600_5_2, + control.cis_v600_5_3, + control.cis_v600_5_4, + control.cis_v600_5_5, + control.cis_v600_5_6, + control.cis_v600_5_7, + control.cis_v600_5_8, + control.cis_v600_5_9, + control.cis_v600_5_10, + control.cis_v600_5_11, + control.cis_v600_5_12, + control.cis_v600_5_13, + control.cis_v600_5_14, + control.cis_v600_5_15, + control.cis_v600_5_16 + ] + + tags = merge(local.cis_v600_5_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v600_5_1" { + title = "5.1 Ensure unauthorized API calls are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_unauthorized_api + documentation = file("./cis_v600/docs/cis_v600_5_1.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.1" + cis_level = "2" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_2" { + title = "5.2 Ensure management console sign-in without MFA is monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_console_login_mfa + documentation = file("./cis_v600/docs/cis_v600_5_2.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.2" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_3" { + title = "5.3 Ensure usage of the 'root' account is monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_root_login + documentation = file("./cis_v600/docs/cis_v600_5_3.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.3" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_4" { + title = "5.4 Ensure IAM policy changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_iam_policy + documentation = file("./cis_v600/docs/cis_v600_5_4.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.4" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_5" { + title = "5.5 Ensure CloudTrail configuration changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_cloudtrail_configuration + documentation = file("./cis_v600/docs/cis_v600_5_5.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.5" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_6" { + title = "5.6 Ensure AWS Management Console authentication failures are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_console_authentication_failure + documentation = file("./cis_v600/docs/cis_v600_5_6.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.6" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_7" { + title = "5.7 Ensure disabling or scheduled deletion of customer created CMKs is monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_disable_or_delete_cmk + documentation = file("./cis_v600/docs/cis_v600_5_7.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.7" + cis_level = "2" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_8" { + title = "5.8 Ensure S3 bucket policy changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_bucket_policy + documentation = file("./cis_v600/docs/cis_v600_5_8.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.8" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_9" { + title = "5.9 Ensure AWS Config configuration changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_config_configuration + documentation = file("./cis_v600/docs/cis_v600_5_9.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.9" + cis_level = "2" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_10" { + title = "5.10 Ensure security group changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_security_group + documentation = file("./cis_v600/docs/cis_v600_5_10.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.10" + cis_level = "2" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_11" { + title = "5.11 Ensure Network Access Control List (NACL) changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms. NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets within a VPC. It is recommended that a metric filter and alarm be established for any changes made to NACLs." + query = query.log_metric_filter_network_acl + documentation = file("./cis_v600/docs/cis_v600_5_11.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.11" + cis_level = "2" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_12" { + title = "5.12 Ensure changes to network gateways are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_network_gateway + documentation = file("./cis_v600/docs/cis_v600_5_12.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.12" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_13" { + title = "5.13 Ensure route table changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_route_table + documentation = file("./cis_v600/docs/cis_v600_5_13.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.13" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_14" { + title = "5.14 Ensure VPC changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_vpc + documentation = file("./cis_v600/docs/cis_v600_5_14.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.14" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_15" { + title = "5.15 Ensure AWS Organizations changes are monitored" + description = "Real-time monitoring of API calls can be achieved by directing CloudTrail Logs to CloudWatch Logs or an external Security Information and Event Management (SIEM) environment, and establishing corresponding metric filters and alarms." + query = query.log_metric_filter_organization + documentation = file("./cis_v600/docs/cis_v600_5_15.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.15" + cis_level = "1" + cis_type = "manual" + service = "AWS/CloudWatch" + }) +} + +control "cis_v600_5_16" { + title = "5.16 Ensure AWS Security Hub is enabled" + description = "Security Hub collects security data from various AWS accounts, services, and supported third-party partner products, helping you analyze your security trends and identify the highest-priority security issues. When you enable Security Hub, it begins to consume, aggregate, organize, and prioritize findings from the AWS services that you have enabled, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. You can also enable integrations with AWS partner security products." + query = query.securityhub_enabled + documentation = file("./cis_v600/docs/cis_v600_5_16.md") + + tags = merge(local.cis_v600_5_common_tags, { + cis_item_id = "5.16" + cis_level = "2" + cis_type = "automated" + service = "AWS/SecurityHub" + }) +} diff --git a/cis_v600/section_6.pp b/cis_v600/section_6.pp new file mode 100644 index 00000000..a7185e38 --- /dev/null +++ b/cis_v600/section_6.pp @@ -0,0 +1,154 @@ +locals { + cis_v600_6_common_tags = merge(local.cis_v600_common_tags, { + cis_section_id = "6" + }) +} + +locals { + cis_v600_6_1_common_tags = merge(local.cis_v600_6_common_tags, { + cis_section_id = "6.1" + }) +} + +benchmark "cis_v600_6" { + title = "6 Networking" + documentation = file("./cis_v600/docs/cis_v600_6.md") + children = [ + benchmark.cis_v600_6_1, + control.cis_v600_6_2, + control.cis_v600_6_3, + control.cis_v600_6_4, + control.cis_v600_6_5, + control.cis_v600_6_6, + control.cis_v600_6_7 + ] + + tags = merge(local.cis_v600_6_common_tags, { + type = "Benchmark" + }) +} + +benchmark "cis_v600_6_1" { + title = "6.1 Elastic Compute Cloud (EC2)" + documentation = file("./cis_v600/docs/cis_v600_6_1.md") + children = [ + control.cis_v600_6_1_1, + control.cis_v600_6_1_2 + ] + + tags = merge(local.cis_v600_6_1_common_tags, { + type = "Benchmark" + }) +} + +control "cis_v600_6_1_1" { + title = "6.1.1 Ensure EBS volume encryption is enabled in all regions" + description = "Elastic Compute Cloud (EC2) supports encryption at rest when using the Elastic Block Store (EBS) service. While disabled by default, forcing encryption at EBS volume creation is supported." + query = query.ebs_encryption_by_default_enabled + documentation = file("./cis_v600/docs/cis_v600_6_1_1.md") + + tags = merge(local.cis_v600_6_1_common_tags, { + cis_item_id = "6.1.1" + cis_level = "1" + cis_type = "automated" + service = "AWS/EC2" + }) +} + +control "cis_v600_6_1_2" { + title = "6.1.2 Ensure CIFS access is restricted to trusted networks to prevent unauthorized access" + description = "CIFS access should be restricted to trusted networks to prevent unauthorized access." + query = query.vpc_security_group_restrict_ingress_cifs_port_all + documentation = file("./cis_v600/docs/cis_v600_6_1_2.md") + + tags = merge(local.cis_v600_6_1_common_tags, { + cis_item_id = "6.1.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/EC2" + }) +} + +control "cis_v600_6_2" { + title = "6.2 Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports" + description = "The Network Access Control List (NACL) function provides stateless filtering of ingress and egress network traffic to AWS resources. It is recommended that no NACL allows unrestricted ingress access to remote server administration ports, such as SSH on port 22 and RDP on port 3389, using either the TCP (6), UDP (17), or ALL (-1) protocols." + query = query.vpc_network_acl_remote_administration + documentation = file("./cis_v600/docs/cis_v600_6_2.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.2" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v600_6_3" { + title = "6.3 Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports" + description = "Security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports." + query = query.vpc_security_group_remote_administration_ipv4 + documentation = file("./cis_v600/docs/cis_v600_6_3.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.3" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v600_6_4" { + title = "6.4 Ensure no security groups allow ingress from ::/0 to remote server administration ports" + description = "Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. It is recommended that no security group allows unrestricted ingress access to remote server administration ports, such as SSH on port 22 and RDP on port 3389" + query = query.vpc_security_group_remote_administration_ipv6 + documentation = file("./cis_v600/docs/cis_v600_6_4.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.4" + cis_level = "1" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v600_6_5" { + title = "6.5 Ensure the default security group of every VPC restricts all traffic" + description = "A VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If a security group is not specified when an instance is launched, it is automatically assigned to this default security group. Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. It is recommended that the default security group restrict all traffic, both inbound and outbound." + query = query.vpc_default_security_group_restricts_all_traffic + documentation = file("./cis_v600/docs/cis_v600_6_5.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.5" + cis_level = "2" + cis_type = "automated" + service = "AWS/VPC" + }) +} + +control "cis_v600_6_6" { + title = "6.6 Ensure routing tables for VPC peering are 'least access'" + description = "Routing tables for VPC peering should be 'least access'." + query = query.manual_control + documentation = file("./cis_v600/docs/cis_v600_6_6.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.6" + cis_level = "2" + cis_type = "manual" + service = "AWS/VPC" + }) +} + +control "cis_v600_6_7" { + title = "6.7 Ensure that the EC2 Metadata Service only allows IMDSv2" + description = "When enabling the Metadata Service on AWS EC2 instances, users have the option of using either Instance Metadata Service Version 1 (IMDSv1; a request/response method) or Instance Metadata Service Version 2 (IMDSv2; a session-oriented method)." + query = query.ec2_instance_uses_imdsv2 + documentation = file("./cis_v600/docs/cis_v600_6_7.md") + + tags = merge(local.cis_v600_6_common_tags, { + cis_item_id = "6.7" + cis_level = "1" + cis_type = "automated" + service = "AWS/EC2" + }) +}