Benchmark: 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion
Description
Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission functions and system support functions among different individuals or roles; conducting system support functions with different individuals (e.g., configuration management, quality assurance and testing, system management, programming, and network security); and ensuring that security personnel administering access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of organizational systems and system components when developing policy on separation of duties.
Usage
Install the mod:
mkdir dashboardscd dashboardspowerpipe mod initpowerpipe mod install github.com/turbot/steampipe-mod-aws-compliance
Start the Powerpipe server:
steampipe service startpowerpipe server
Open http://localhost:9033 in your browser and select 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
Run this benchmark in your terminal:
powerpipe benchmark run aws_compliance.benchmark.nist_800_171_rev_2_3_1_4
Snapshot and share results via Turbot Pipes:
powerpipe benchmark run aws_compliance.benchmark.nist_800_171_rev_2_3_1_4 --share
Controls
- EC2 instances should have IAM profile attached
- ECS task definition container definitions should be checked for host mode
- EMR cluster Kerberos should be enabled
- Ensure IAM policy should not grant full access to service
- IAM groups should have at least one user
- IAM groups, users, and roles should not have any inline policies
- Ensure managed IAM policies should not allow blocked actions on KMS keys
- Ensure inline policies attached to IAM users, roles, and groups should not allow blocked actions on KMS keys
- IAM policy should not have statements with admin access
- IAM policy should be in use
- IAM root user should not have access keys
- IAM users should be in at least one group
- IAM user should not have any inline or attached policies
- IAM user credentials that have not been used in 90 days should be disabled
- IAM authentication should be configured for RDS clusters
- RDS DB instances should have iam authentication enabled
- S3 bucket policy should prohibit public access