@cyberstrike-io/cyberstrike 1.1.9 → 1.1.10-beta.1

package/skill/CIS_benchmarks/AWS/CIS_AWS_Compute_Services_Benchmark_v1.1.0/cis-aws-compute-2.7/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: cis-aws-compute-2.7
+description: "Ensure Default EC2 Security groups are not being used"
+category: cis-compute
+version: "1.1.0"
+author: cyberstrike-official
+tags: [cis, aws, compute, ec2, security-groups, default, network-security]
+cis_id: "2.7"
+cis_benchmark: "CIS AWS Compute Services Benchmark v1.1.0"
+tech_stack: [aws]
+cwe_ids: []
+chains_with: [cis-aws-compute-2.8]
+prerequisites: []
+severity_boost: {}
+---
+
+# Ensure Default EC2 Security groups are not being used
+
+## Description
+
+When an EC2 instance is launched a specified custom security group should be assigned to the instance.
+
+## Rationale
+
+When an EC2 Instance is launched the default security group is automatically assigned. In error a lot of instances are launched in this way, and if the default security group is configured to allow unrestricted access, it will increase the attack footprint allowing the opportunity for malicious activity.
+
+## Impact
+
+Instances using the default security group must be migrated to custom security groups. This may require updating application configurations and testing connectivity.
+
+## Audit Procedure
+
+### Using AWS CLI
+
+1. Run the describe-instances command:
+
+```bash
+aws ec2 describe-instances --region us-east-1 --output json --filters "Name=instance.group-name,Values=default" --query "Reservations[*].Instances[*].{Instance:InstanceId}"
+```
+
+2. The command output should return an empty list if the default security group is not being used.
+3. If there is a list of instance IDs then the default security group is currently attached to those EC2 instances.
+4. Refer to the remediation below using list of EC2 Instance ids captured.
+
+NOTE Repeat the audit process for all other regions used.
+
+### Using AWS Console
+
+1. Login to EC2 using https://console.aws.amazon.com/ec2/
+2. On the left Click `INSTANCES`, click `Instances`.
+3. On the EC2 Instances page, click inside the attributes filter box.
+4. Click the Security Group Name from the dropdown list.
+5. Type `default` for the attribute value. (This filter will detect the EC2 instances currently associated with the default security group)
+6. Refer to the remediation below using list of EC2 Instance ids captured.
+
+NOTE Repeat the audit process for all other regions used.
+
+## Expected Result
+
+The CLI command should return an empty list, indicating no EC2 instances are using the default security group.
+
+## Remediation
+
+### Using AWS CLI
+
+No specific CLI remediation command is provided for this control. Use the console method below to remove inbound rules from default security groups.
+
+### Using AWS Console
+
+1. Login to EC2 using https://console.aws.amazon.com/ec2/
+2. On the left Click `Network & Security`, click `Security Groups`.
+3. Select `Security Groups`.
+4. Click on the `default Security Group` you want to review.
+5. Click `Actions, View details`.
+6. Select the `Inbound rules` tab.
+7. Click on `Edit inbound rules`.
+8. Click on `Delete` for all the rules listed.
+9. Once there are no rules listed click on 'Save rules'.
+10. Repeat steps no. 3 - 8 for any other default security groups listed.
+
+## Default Value
+
+AWS automatically creates a default security group for each VPC. The default security group allows all inbound traffic from other instances in the same security group and all outbound traffic.
+
+## References
+
+1. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-security-groups.html
+2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/default-custom-security-groups.html#default-security-group
+
+## CIS Controls
+
+| Controls Version | Control                                               | IG 1 | IG 2 | IG 3 |
+| ---------------- | ----------------------------------------------------- | ---- | ---- | ---- |
+| v8               | 3.3 Configure Data Access Control Lists               | x    | x    | x    |
+| v7               | 14.6 Protect Information through Access Control Lists | x    | x    | x    |
+
+## Profile
+
+Level 1 | Manual

package/skill/CIS_benchmarks/AWS/CIS_AWS_Compute_Services_Benchmark_v1.1.0/cis-aws-compute-2.8/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: cis-aws-compute-2.8
+description: "Ensure the Use of IMDSv2 is Enforced on All Existing Instances"
+category: cis-compute
+version: "1.1.0"
+author: cyberstrike-official
+tags: [cis, aws, compute, ec2, imdsv2, metadata, ssrf, instance-metadata]
+cis_id: "2.8"
+cis_benchmark: "CIS AWS Compute Services Benchmark v1.1.0"
+tech_stack: [aws]
+cwe_ids: []
+chains_with: [cis-aws-compute-2.7, cis-aws-compute-2.13]
+prerequisites: []
+severity_boost: {}
+---
+
+# Ensure the Use of IMDSv2 is Enforced on All Existing Instances
+
+## Description
+
+Ensure the Instance Metadata Service Version 2 (IMDSv2) method is enabled on all running instances.
+
+## Rationale
+
+The IMDSv2 method uses session-based controls to help protect access and control of Amazon Elastic Compute Cloud (Amazon EC2) instance metadata. With IMDSv2, controls can be implemented to restrict changes to instance metadata.
+
+## Impact
+
+Once you enforce IMDSv2, then IMDSv1 no longer works, and applications that use IMDSv1 might not function correctly. Before enforcing IMDSv2, verify that any applications that use Amazon EC2 metadata are upgraded to a version that supports IMDSv2.
+
+## Audit Procedure
+
+### Using AWS CLI
+
+1. Run the describe-instances command:
+
+```bash
+aws ec2 describe-instances --region us-east-1 --output text --filter "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].{Instance:InstanceId}"
+```
+
+2. The output should look like this:
+
+```
+i-1234567abcdefghi0
+i-1234567abcdefghi0
+i-1234567abcdefghi0
+```
+
+The list above contains all the instances that have the metadata version set to optional which means either IMDSv1 or IMDSv2 can be used. Refer to the remediation below.
+
+Repeat steps 1 - 2 for the other AWS regions.
+
+### Using AWS Console
+
+1. At this time the instance metadata setting for existing instances can only be reviewed and confirmed using AWS CLI.
+
+## Expected Result
+
+The CLI command should return an empty list, indicating all instances have http-tokens set to `required` (enforcing IMDSv2). Any instances listed are using optional mode allowing IMDSv1.
+
+## Remediation
+
+### Using AWS CLI
+
+1. Run the modify-instance-metadata-options command using the list of Instances collected in the audit:
+
+```bash
+aws ec2 modify-instance-metadata-options --instance-id i-1234567abcdefghi0 --http-tokens required --http-endpoint enabled
+```
+
+2. The output should show the information for the instance and the metadata changes:
+
+```json
+{
+  "InstanceId": "i-1234567abcdefghi0",
+  "InstanceMetadataOptions": {
+    "State": "pending",
+    "HttpTokens": "required",
+    "HttpPutResponseHopLimit": 1,
+    "HttpEndpoint": "enabled"
+  }
+}
+```
+
+3. Repeat for the other instances and regions collected during the audit.
+
+### Using AWS Console
+
+1. At this time the instance metadata setting for existing instances can only be changed using AWS CLI.
+
+## Default Value
+
+By default, new EC2 instances may allow both IMDSv1 and IMDSv2 (http-tokens set to optional) depending on region and account settings.
+
+## References
+
+1. https://aws.amazon.com/premiumsupport/knowledge-center/ssm-ec2-enforce-imdsv2/
+2. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
+3. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html
+4. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html#configure_instance_details_step
+5. https://docs.aws.amazon.com/config/latest/developerguide/ec2-imdsv2-check.html
+6. https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-enforce-ec2-imdsv2.html
+
+## CIS Controls
+
+| Controls Version | Control                                               | IG 1 | IG 2 | IG 3 |
+| ---------------- | ----------------------------------------------------- | ---- | ---- | ---- |
+| v8               | 3.3 Configure Data Access Control Lists               | x    | x    | x    |
+| v7               | 14.6 Protect Information through Access Control Lists | x    | x    | x    |
+
+## Profile
+
+Level 2 | Manual

package/skill/CIS_benchmarks/AWS/CIS_AWS_Compute_Services_Benchmark_v1.1.0/cis-aws-compute-2.9/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: cis-aws-compute-2.9
+description: "Ensure use of AWS Systems Manager to manage EC2 instances"
+category: cis-compute
+version: "1.1.0"
+author: cyberstrike-official
+tags: [cis, aws, compute, ec2, systems-manager, ssm, inventory, management]
+cis_id: "2.9"
+cis_benchmark: "CIS AWS Compute Services Benchmark v1.1.0"
+tech_stack: [aws]
+cwe_ids: []
+chains_with: [cis-aws-compute-2.6, cis-aws-compute-2.5]
+prerequisites: []
+severity_boost: {}
+---
+
+# Ensure use of AWS Systems Manager to manage EC2 instances
+
+## Description
+
+An inventory and management of Amazon Elastic Compute Cloud (Amazon EC2) instances is made possible with AWS Systems Manager.
+
+## Rationale
+
+Use AWS Systems Manager to provide detailed system configurations, operating system patch levels, services name and type, software installations, application name, publisher and version, and other details about your environment.
+
+## Impact
+
+Setting up Systems Manager requires creating IAM users, groups, roles, and instance profiles. This adds administrative overhead but provides centralized management of EC2 instances.
+
+## Audit Procedure
+
+### Using AWS CLI
+
+No specific CLI audit command is provided for this control. Use the console method below.
+
+### Using AWS Console
+
+1. Login to EC2 using https://console.aws.amazon.com/systems-manager/
+2. On the left Click `Node Management`, click `Inventory`.
+3. On the Dashboard confirm that all of your Instances are listed as part of your inventory.
+
+If any instances are missing or AWS Systems Manager is not configured, refer to the remediation below.
+
+## Expected Result
+
+All EC2 instances should appear in the AWS Systems Manager Inventory dashboard.
+
+## Remediation
+
+### Using AWS CLI
+
+No specific CLI remediation command is provided for this control. Use the console method below.
+
+### Using AWS Console
+
+These directions already assume your AWS account is setup. They will walk you through how to create non-Admin IAM users and groups for System Manager.
+
+**1. Create a user group:**
+
+a. Login to IAM using https://console.aws.amazon.com/iam/
+b. On the left Click `Access management`, click `User groups`, and then click `Create Group`.
+c. On the `Create user group` page, enter a name for the group.
+d. Select and add the users required to the Group.
+e. Attach permissions policies by selecting `ResourceGroupsandTagEditorFullAccess` policy.
+f. Then for Full access to Systems Manager console, click the `AmazonSSMFullAccess` policy.
+
+- OR
+  g. For access to view Systems Manager data, and not create or update resources, click the `AmazonSSMReadOnlyAccess` policy.
+  h. For access to the Built-In Insights and Dashboard by CloudWatch pages in the Systems Manager console, add these policies:
+- AWSHealthFullAccess
+- AWSConfigUserAccess
+- CloudWatchReadOnlyAccess
+  i. Click `Create group`.
+
+**2. Create users and assign permissions:**
+
+a. Login to IAM using https://console.aws.amazon.com/iam/
+b. On the left Click `Access management`, click `Users`, and then click `Add users`.
+c. `User name`, enter the name that the user will use to sign in to AWS Systems Manager.
+d. To allow the user access to development tools, select the check box next to Access key - Programmatic access.
+e. To allow user access to the AWS Management Console, select the check box next to AWS Management Console access.
+f. Click `Next: Permissions`.
+g. To Set permissions, click `Add user to group`.
+h. In the `group list`, click the group you created in step 1.
+i. Then click `Next: Tags`.
+j. (Optional) Add one or more tags.
+k. Click `Next: Review` to see the list of group memberships.
+l. Click `Create user`.
+
+**3. To add permissions for an existing user:**
+
+a. In the IAM console, click `Users`.
+b. Click the name of the user to add to a group.
+c. Then click `Add permission`.
+d. For `Add user to group`, select the box next to the group to add the user to.
+e. Add any other available permission policies to assign to the user.
+f. Click `Next: Review`.
+g. Click `Add permissions`.
+
+**4. Create an IAM instance profile for Systems Manager:**
+
+a. Login to the IAM console at https://console.aws.amazon.com/iam/
+b. In the left, click `Roles`, and then click `Create role`.
+c. Under `Select type of trusted entity`, click `AWS service`.
+d. Click `EC2`, and then click `Next: Permissions`.
+e. On the `Attach permissions policies` page, locate `AmazonSSMManagedInstanceCore`. Select the box next to it.
+f. Click `Next: Tags`.
+g. Add one or more tag-key value pairs.
+h. Click `Next: Review`.
+i. For `Role name`, enter a name for your new instance profile.
+j. For `Role description`, enter a description for this instance profile.
+k. Click `Create role`.
+
+**Note:** If you plan to join instances to an Active Directory managed by AWS Directory Service, search for AmazonSSMDirectoryServiceAccess and select the box next to its name. If you plan to use EventBridge or CloudWatch Logs, search for CloudWatchAgentServerPolicy and select the box next to its name.
+
+**5. Attach the Systems Manager instance profile to an existing instance:**
+
+a. Login to the EC2 console at https://console.aws.amazon.com/ec2/
+b. In the left pane, under `Instances`, click `Instances`.
+c. Select the instance from the list.
+d. In the `Actions menu`, click `Security, Modify IAM role`.
+e. Select the instance profile you created in Step 4.
+f. Click `Save`.
+
+**6. Attach an IAM instance profile to an Amazon EC2 instance at launch:**
+
+a. Login to the EC2 console at https://console.aws.amazon.com/ec2/
+b. Select or confirm the `AWS Region` for the instance.
+c. Click `Launch Instance`.
+d. Locate the AMI for the instance type you want to create, and then click `Select`.
+e. Select the type of instance to launch, then click `Next: Configure Instance Details`.
+f. On the `Configure Instance Details` page, in the `IAM role` dropdown list, select the instance profile you created in Step 4.
+g. For other options on the page, make selections that meet your requirements for the instance.
+h. Complete the `wizard`.
+
+If you create other instances that you want to configure using Systems Manager, specify the instance profile for each instance.
+
+## Default Value
+
+AWS Systems Manager is not configured by default for EC2 instances. It must be explicitly set up.
+
+## References
+
+1. https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html
+
+## CIS Controls
+
+| Controls Version | Control                                                        | IG 1 | IG 2 | IG 3 |
+| ---------------- | -------------------------------------------------------------- | ---- | ---- | ---- |
+| v8               | 1.1 Establish and Maintain Detailed Enterprise Asset Inventory | x    | x    | x    |
+| v7               | 1.4 Maintain Detailed Asset Inventory                          | x    | x    | x    |
+
+## Profile
+
+Level 2 | Manual

package/skill/CIS_benchmarks/AWS/CIS_AWS_Compute_Services_Benchmark_v1.1.0/cis-aws-compute-3.1/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: cis-aws-compute-3.1
+description: "Ensure Amazon ECS task definitions using 'host' network mode do not allow privileged or root user access to the host"
+category: cis-compute
+version: "1.1.0"
+author: cyberstrike-official
+tags: [cis, aws, compute, ecs, containers, task-definitions, networking, privilege-escalation, host-network]
+cis_id: "3.1"
+cis_benchmark: "CIS AWS Compute Services Benchmark v1.1.0"
+tech_stack: [aws]
+cwe_ids: []
+chains_with: [cis-aws-compute-3.3, cis-aws-compute-3.4]
+prerequisites: []
+severity_boost: {}
+---
+
+# Ensure Amazon ECS task definitions using 'host' network mode do not allow privileged or root user access to the host
+
+## Description
+
+Ensure that Amazon ECS task definitions using `host` network mode do not allow privileged or root user access. This protects the host container instance from unauthorized access and privilege escalation.
+
+Note: This recommendation assumes that only the latest active revision of a task definition is in use. If older revisions are in use, apply the audit and remediation procedures to those revisions as needed.
+
+## Rationale
+
+Combining host networking mode with privileged or root user access significantly increases the risk of container breakout, where a compromised container can gain control of the host system.
+
+## Impact
+
+There may be some administrative effort required to ensure Amazon ECS applications function as expected without privileged or root user access.
+
+## Audit Procedure
+
+### Using AWS Console
+
+1. Login to the ECS console using https://console.aws.amazon.com/ecs/.
+2. In the left panel, click `Task definitions`.
+3. Click the name of a task definition.
+4. Click on the latest active revision of the task definition.
+5. If `Network mode` is set to `host`, click `JSON`.
+6. For each element under `containerDefinitions`, ensure that `privileged` is set to `false` or is absent, and ensure that `user` is not set to `root` or is absent.
+7. Repeat steps 1-6 for each task definition.
+
+### Using AWS CLI
+
+Run the following command to list task definitions:
+
+```
+aws ecs list-task-definitions
+```
+
+For the latest revision of a task definition, run the following command:
+
+```
+aws ecs describe-task-definition --task-definition <task-definition-arn>
+```
+
+If `networkMode` is set to `host`, ensure that for each element under `containerDefinitions`, `privileged` is set to `false` or is absent, and ensure that `user` is not set to `root` or is absent.
+Repeat for each task definition.
+
+## Expected Result
+
+For task definitions using `host` network mode, `privileged` should be `false` or absent, and `user` should not be `root` or should be absent in all `containerDefinitions`.
+
+## Remediation
+
+### Using AWS Console
+
+1. Login to the ECS console using https://console.aws.amazon.com/ecs/.
+2. In the left panel, click `Task definitions`.
+3. Click the name of a task definition.
+4. Click on the latest active revision of the task definition.
+5. Click `Create new revision`.
+6. Click `Create new revision with JSON`.
+7. For each element under `containerDefinitions`, set `privileged` to `false`, or remove `"privileged": true`.
+8. For each element under `containerDefinitions`, set `user` to an appropriate non-root user, or remove `"user": "root"`.
+9. Click `Create`.
+10. Repeat steps 1-9 for each task definition requiring remediation.
+
+Note: When a task definition is updated, running tasks launched from the previous task definition remain unchanged. Updating a running task requires redeploying it with the new task definition.
+
+### Using AWS CLI
+
+No specific CLI remediation provided. Use the console steps above or register a new task definition revision with corrected settings using `aws ecs register-task-definition`.
+
+## Default Value
+
+When creating a task definition with `host` network mode, the `privileged` and `user` parameters are unset by default.
+
+## References
+
+1. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html
+2. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
+3. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/describe-task-definition.html
+
+## Additional Information
+
+- AWS recommends using the `awsvpc` network mode unless you have a specific need to use a different network mode.
+- The `privileged` parameter is not supported for Windows containers or tasks using the Fargate launch type.
+
+## CIS Controls
+
+| Controls Version | Control                                                                   | IG 1 | IG 2 | IG 3 |
+| ---------------- | ------------------------------------------------------------------------- | ---- | ---- | ---- |
+| v8               | 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts | x    | x    | x    |
+| v7               | 4.3 Ensure the Use of Dedicated Administrative Accounts                   | x    | x    | x    |
+
+## Profile
+
+Level 1 | Automated

package/skill/CIS_benchmarks/AWS/CIS_AWS_Compute_Services_Benchmark_v1.1.0/cis-aws-compute-3.10/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: cis-aws-compute-3.10
+description: "Ensure Amazon ECS services are tagged"
+category: cis-compute
+version: "1.1.0"
+author: cyberstrike-official
+tags: [cis, aws, compute, ecs, containers, services, tagging, asset-management, compliance]
+cis_id: "3.10"
+cis_benchmark: "CIS AWS Compute Services Benchmark v1.1.0"
+tech_stack: [aws]
+cwe_ids: []
+chains_with: [cis-aws-compute-3.11, cis-aws-compute-3.12]
+prerequisites: []
+severity_boost: {}
+---
+
+# Ensure Amazon ECS services are tagged
+
+## Description
+
+Ensure all Amazon ECS services have resource tags to facilitate asset management, tracking, and compliance.
+
+## Rationale
+
+Consistent tagging supports compliance and helps identify unauthorized or misconfigured resources.
+
+## Impact
+
+There is minimal administrative overhead associated with implementing and maintaining resource tags.
+
+## Audit Procedure
+
+### Using AWS Console
+
+1. Login to the ECS console using https://console.aws.amazon.com/ecs/.
+2. In the left panel, click `Clusters`.
+3. Click the name of a cluster.
+4. Under `Services`, click the name of a service.
+5. Click `Tags`.
+6. Ensure at least one tag is listed that does not begin with `aws:`. Tags prefixed with `aws:` are AWS-managed.
+7. Repeat steps 1-6 for each ECS cluster and service.
+
+### Using AWS CLI
+
+Run the following command to list clusters:
+
+```
+aws ecs list-clusters
+```
+
+Run the following command to list services in a cluster:
+
+```
+aws ecs list-services --cluster <cluster-arn>
+```
+
+Run the following command to view the tags for a service:
+
+```
+aws ecs list-tags-for-resource --resource-arn <service-arn>
+```
+
+Ensure that tags are returned that do not begin with `aws:`. Tags prefixed with `aws:` are AWS-managed.
+Repeat for each cluster and service.
+
+## Expected Result
+
+All ECS services should have at least one user-defined tag (not prefixed with `aws:`).
+
+## Remediation
+
+### Using AWS Console
+
+1. Login to the ECS console using https://console.aws.amazon.com/ecs/.
+2. In the left panel, click `Clusters`.
+3. Click the name of a cluster.
+4. Under `Services`, click the name of a service.
+5. Click `Tags`.
+6. Click `Manage tags`.
+7. Click `Add tag`.
+8. Provide a `Key` and optional `Value` for the tag.
+9. Click `Save`.
+10. Repeat steps 1-9 for each ECS cluster and service requiring remediation.
+
+### Using AWS CLI
+
+Use the `aws ecs tag-resource` command to add tags to a service:
+
+```
+aws ecs tag-resource --resource-arn <service-arn> --tags key=<TagKey>,value=<TagValue>
+```
+
+## Default Value
+
+By default, Amazon ECS services are not tagged.
+
+## References
+
+1. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html
+2. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/list-clusters.html
+3. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/list-services.html
+4. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/list-tags-for-resource.html
+
+## CIS Controls
+
+| Controls Version | Control                                                        | IG 1 | IG 2 | IG 3 |
+| ---------------- | -------------------------------------------------------------- | ---- | ---- | ---- |
+| v8               | 1.1 Establish and Maintain Detailed Enterprise Asset Inventory | x    | x    | x    |
+| v7               | 1.4 Maintain Detailed Asset Inventory                          | x    | x    | x    |
+
+## Profile
+
+Level 1 | Automated