AWS Introduction
AWS Pricing
AWS Threats
AWS Misconfigurations
- Getting Started with AWS Audit
- Permissions required for Misconfigurations Detection
- API Gateway Audit
- Cloudformation Audit
- CloudFront Audit
- CloudTrail Audit
- Cloudwatch Audit
- DynamoDB Audit
- EC2 Audit
- Elastic Search Audit
- ELB Audit
- IAM Audit
- KMS Audit
- Kubernetes Audit
- Lambda Audit
- RDS Audit
- Redshift Audit
- Route53 Audit
- S3 Audit
- Security Groups Audit
- SES Audit
- SNS Audit
- IAM Deep Dive
- App Sync Audit
- Code Build Audit
- Open Search Audit
- Shield Audit
- SQS Audit
SSM Document Should Not Be Public
More Info:
Ensure SSM Documents are not public
Risk Level
High
Address
Security
Compliance Standards
HITRUST,SEBI,RBI_MD_ITF,RBI_UCB
Triage and Remediation
Remediation
To remediate the issue of SSM document being public in AWS EC2 using the AWS console, follow these steps:
-
Login to AWS Console: Go to the AWS Management Console and login with your credentials.
-
Navigate to Systems Manager (SSM): Go to the AWS Systems Manager service by typing “Systems Manager” in the search bar and selecting it from the dropdown.
-
Access SSM Documents: In the Systems Manager console, navigate to the left-hand menu and click on “Documents” under the “Shared Resources” section.
-
Identify Public SSM Documents: Look through the list of SSM documents to identify the ones that are marked as public. These will have a permission setting indicating that they are public.
-
Change Document Permissions:
- Select the public SSM document by clicking on it.
- Click on the “Edit” button to modify the document permissions.
- In the document permissions settings, change the visibility from public to private.
- Save the changes.
-
Verify Changes: After changing the permissions, verify that the SSM document is no longer public by checking the permissions settings.
-
Monitor for Compliance: Regularly monitor the SSM documents to ensure that they are not set to public in the future.
By following these steps, you can remediate the issue of SSM documents being public in AWS EC2 using the AWS console.
To remediate the issue of an SSM Document being public in AWS EC2 using AWS CLI, follow these steps:
-
Identify the public SSM Documents: Run the following AWS CLI command to list all public SSM Documents:
aws ssm list-documents --filters Key=Owner,Values=Public
-
Update the SSM Document to be private: You will need to update the SSM Document to be private. You can do this by running the following AWS CLI command:
aws ssm modify-document-permission --name "DOCUMENT_NAME" --permission-type "PRIVATE"
Replace
DOCUMENT_NAME
with the name of the public SSM Document that you want to make private. -
Verify the SSM Document is now private: To confirm that the SSM Document is now private, you can run the following AWS CLI command:
aws ssm describe-document --name "DOCUMENT_NAME"
Replace
DOCUMENT_NAME
with the name of the SSM Document you updated.
By following these steps, you can successfully remediate the issue of an SSM Document being public in AWS EC2 using AWS CLI.
To remediate the misconfiguration of having an SSM Document public for AWS EC2 instances using Python, you can follow these steps:
Remove the “All” option from the document permissions
response = ssm_client.modify_document_permission( Name=document_name, PermissionType=‘Share’, AccountIds=[], SharedDocumentVersion=None ) print(f”Permissions updated for SSM document ''.“)
def main():
Specify the name of the SSM document to remediate
document_name = ‘your-ssm-document-name’
Remediate SSM document permissions
remediate_ssm_document_permission(document_name)
if name == “main”: main()
Replace `'your-ssm-document-name'` with the name of the SSM document you want to remediate. This script removes the "All" option from the document permissions to ensure it is not shared with all accounts. Adjust the script as needed to fit your environment and document permissions.
### Triage and Remediation
<Tabs>
<Tab title='Remediation'>
<AccordionGroup>
<Accordion title='Using Console' defaultOpen='true'>
To remediate the misconfiguration of FSx not having a backup plan for AWS EC2 using the AWS Management Console, follow these steps:
1. **Sign in to the AWS Management Console**: Go to https://aws.amazon.com/ and sign in to the AWS Management Console using your credentials.
2. **Navigate to Amazon FSx service**: Click on the "Services" dropdown menu at the top of the console, then select "FSx" under the "Storage" category.
3. **Select the FSx file system**: In the FSx console, select the FSx file system that you want to create a backup plan for by clicking on its name.
4. **Create a Backup Plan**:
- In the left-hand navigation pane, click on "Backup" and then click on the "Backup plans" tab.
- Click on the "Create backup plan" button.
- Enter a name for the backup plan and configure the backup settings according to your requirements. This includes defining the backup frequency, retention period, and any lifecycle policies.
- Review the backup plan settings and click on the "Create" button to create the backup plan.
5. **Assign the Backup Plan to the FSx file system**:
- After creating the backup plan, go back to the FSx file system details page.
- Click on the "Backup" tab and then click on the "Associate backup plan" button.
- Select the backup plan that you just created from the dropdown menu and click on the "Associate" button to assign the backup plan to the FSx file system.
6. **Verify Backup Plan**:
- Once the backup plan is associated with the FSx file system, verify that the backup plan is active and running as expected.
- Monitor the backup status and ensure that backups are being taken according to the defined schedule.
By following these steps, you will successfully remediate the misconfiguration of FSx not having a backup plan for your AWS EC2 instances using the AWS Management Console.
#
</Accordion>
<Accordion title='Using CLI'>
To remediate the misconfiguration of not having a backup plan for FSx on AWS EC2 using AWS CLI, you can follow these steps:
1. **Install and Configure AWS CLI:**
If you haven't already installed and configured the AWS CLI, you can do so by following the instructions provided in the AWS documentation: [Installing the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) and [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).
2. **Enable Backup for FSx File Systems:**
You can enable backup for your FSx file systems using the AWS CLI by running the following command:
aws fsx update-file-system —file-system-id fs-1234567890abcdef0 —backup-id backup-0abcdef1234567890 —windows-configuration AutomaticBackupRetentionDays=30,ThroughputCapacity=8
Replace `fs-1234567890abcdef0` with the ID of your FSx file system and `backup-0abcdef1234567890` with the ID of the backup you want to associate with the file system. You can adjust the `AutomaticBackupRetentionDays` and `ThroughputCapacity` values as needed.
3. **Verify Backup Configuration:**
To ensure that backup has been successfully enabled for your FSx file system, you can run the following command:
aws fsx describe-file-systems —file-system-ids fs-1234567890abcdef0
This command will provide detailed information about your FSx file system, including its backup configuration.
4. **Automate Backup Scheduling (Optional):**
If you want to automate the scheduling of backups for your FSx file system, you can create a backup policy using the AWS CLI. Here is an example command to create a backup policy:
aws fsx create-backup-policy —file-system-id fs-1234567890abcdef0 —daily-backup-start-time 01:00:00 —automatic-backup-retention-days 30
This command will create a backup policy for the specified file system that triggers a daily backup at 01:00:00 UTC and retains the backups for 30 days.
By following these steps, you can remediate the misconfiguration of not having a backup plan for FSx on AWS EC2 using the AWS CLI.
</Accordion>
<Accordion title='Using Python'>
To remediate the misconfiguration of not having a backup plan for FSx in AWS, you can create a backup plan using Python Boto3 library. Here are the step-by-step instructions to remediate this issue:
1. Install Boto3 library:
```bash
pip install boto3
-
Configure AWS credentials: Ensure that you have configured your AWS credentials either by setting environment variables or using AWS CLI
aws configure
command. -
Use the following Python script to create a backup plan for FSx in AWS EC2:
import boto3
def remediate_efs_resources_backup_plan(file_system_arns, backup_vault_name):
# Initialize AWS Backup client
backup_client = boto3.client('backup')
# Create a backup plan for the specified EFS file systems
response = backup_client.create_backup_plan(
BackupPlan={
'BackupPlanName': 'YourBackupPlanName',
'BackupPlanRule': {
'RuleName': 'DefaultRule',
'TargetBackupVaultName': backup_vault_name,
'ScheduleExpression': 'cron(0 0 * * ? *)', # Example: Daily backup at midnight
'StartWindowMinutes': 60,
'CompletionWindowMinutes': 60,
},
'AdvancedBackupSettings': [
{
'BackupOptions': {
'WindowsVSS': False,
'BackupMode': 'FULL',
'FileSystemLifecycle': 'SYSTEM'
},
'ResourceType': 'EFS'
}
]
}
)
print("Backup plan created successfully.")
def main():
# Specify the ARNs of the EFS file systems to protect
file_system_arns = ['your-file-system-arn1', 'your-file-system-arn2']
# Specify the name of the backup vault
backup_vault_name = 'your-backup-vault-name'
# Remediate EFS resources by creating a backup plan
remediate_efs_resources_backup_plan(file_system_arns, backup_vault_name)
if __name__ == "__main__":
main()
Replace 'your-file-system-arn1', 'your-file-system-arn2'
with the ARNs of the EFS file systems you want to protect, and 'your-backup-vault-name'
with the name of the backup vault where backups will be stored. This script creates a backup plan for the specified EFS file systems, ensuring they are protected by backups according to the specified schedule and retention policy. Adjust the backup plan settings as needed.