NIST Cybersecurity Framework v1.1¶
Deprecated Framework
This framework has been superseded by NIST Cybersecurity Framework v2.0. Organizations should migrate to version 2.0, which was released in February 2024 with an additional Govern function and enhanced guidance on supply chain risk management.
The National Institute of Standards and Technology (NIST) Cybersecurity Framework version 1.1 provides a policy framework of standards, guidelines, and best practices to manage cybersecurity-related risk. Published in April 2018 by the U.S. Department of Commerce, it organizes cybersecurity activities into five core functions: Identify, Protect, Detect, Respond, and Recover. Originally developed for critical infrastructure, it is widely adopted across all sectors and organization sizes globally.
Terraform Registry Subdomain: nistcsfv11¶
module "..." {
source = "nistcsfv11.compliance.tf/terraform-aws-modules/<module>/aws"
version = "<version>"
}
module "..." {
source = "https://nistcsfv11.compliance.tf/terraform-aws-modules/<module>/aws"
}
Refer to the Terraform Registry Endpoints section for more details.
Implemented Controls¶
The following controls are implemented as part of this framework.
- API Gateway stage should uses SSL certificate
- API Gateway REST API stages should have AWS X-Ray tracing enabled
- API Gateway stage cache encryption at rest should be enabled
- API Gateway stage logging should be enabled
- Backup plan min frequency and min retention check
- CloudFormation stacks should have notifications enabled
- CloudFront distributions should have a default root object configured
- CloudFront distributions should require encryption in transit
- CloudFront distributions access logs should be enabled
- CloudFront distributions should use SNI to serve HTTPS requests
- CloudFront distributions should use custom SSL/TLS certificates
- CloudFront distributions should have AWS WAF enabled
- At least one enabled trail should be present in a region
- CloudTrail trails should be integrated with CloudWatch logs
- CloudTrail trail logs should be encrypted with KMS CMK
- CloudTrail trail log file validation should be enabled
- CloudWatch alarm should have an action configured
- CloudWatch alarm action should be enabled
- Log group retention period should be at least 365 days
- CodeBuild project artifact encryption should be enabled
- CodeBuild project environments should not have privileged mode enabled
- CodeBuild projects should have logging enabled
- CodeBuild project S3 logs should be encrypted
- DynamoDB Accelerator (DAX) clusters should be encrypted at rest
- DMS replication instances should not be publicly accessible
- DynamoDB table should be encrypted with AWS KMS
- DynamoDB table should have encryption enabled
- DynamoDB table point-in-time recovery should be enabled
- Attached EBS volumes should have encryption enabled
- EC2 instance detailed monitoring should be enabled
- EC2 instance should have EBS optimization enabled
- EC2 instances should have IAM profile attached
- EC2 instances should be in a VPC
- EC2 instances should not use key pairs in running state
- EC2 instances should not have a public IP address
- EC2 instances should not use multiple ENIs
- EC2 instances should use IMDSv2
- Paravirtual EC2 instance types should not be used
- EC2 transit gateways should have auto accept shared attachments disabled
- ECR repositories should have image scan on push enabled
- ECR private repositories should have tag immutability configured
- ECS clusters should have container insights enabled
- ECS fargate services should run on the latest fargate platform version
- ECS task definitions should not share the host's process namespace
- EFS access points should enforce a root directory
- EFS access points should enforce a user identity
- EFS file system encryption at rest should be enabled
- EKS clusters endpoint should restrict public access
- EKS clusters should be configured to have kubernetes secrets encrypted using KMS
- ElastiCache Redis cluster automatic backup should be enabled with retention period of 15 days or greater
- ELB application and classic load balancer logging should be enabled
- ELB application load balancer deletion protection should be enabled
- ELB application load balancers should be configured with defensive or strictest desync mitigation mode
- ELB application load balancers should be configured to drop HTTP headers
- Application Load Balancer should be configured to drop invalid http headers
- ELB application and network load balancers should only use SSL or HTTPS listeners
- ELB classic load balancers should have cross-zone load balancing enabled
- ELB classic load balancers should span multiple availability zones
- EMR cluster Kerberos should be enabled
- ES domain encryption at rest should be enabled
- ES domains should be in a VPC
- Elasticsearch domain should send logs to CloudWatch
- Elasticsearch domain node-to-node encryption should be enabled
- IAM password policies for users should have strong configurations
- Kinesis streams should have server side encryption enabled
- KMS CMK rotation should be enabled
- Lambda functions concurrent execution limit configured
- Lambda functions should be configured with a dead-letter queue
- Lambda functions should be in a VPC
- Lambda functions should use latest runtimes
- Log group encryption at rest should be enabled
- The default stateless action for Network Firewall policies should be drop or forward for fragmented packets
- The default stateless action for Network Firewall policies should be drop or forward for full packets
- OpenSearch domains should have audit logging enabled.
- OpenSearch domains should have encryption at rest enabled
- OpenSearch domains should have fine-grained access control enabled
- OpenSearch domains should use HTTPS
- OpenSearch domains should be in a VPC
- OpenSearch domains logs to AWS CloudWatch Logs
- OpenSearch domains node-to-node encryption should be enabled
- RDS Aurora clusters should have backtracking enabled
- RDS clusters should have deletion protection enabled
- IAM authentication should be configured for RDS clusters
- RDS DB clusters should be configured for multiple Availability Zones
- RDS database clusters should use a custom administrator username
- RDS DB instance and cluster enhanced monitoring should be enabled
- RDS DB instance automatic minor version upgrade should be enabled
- RDS DB instance backup should be enabled
- RDS DB instances should have deletion protection enabled
- RDS DB instance encryption at rest should be enabled
- RDS DB instances should have iam authentication enabled
- Database logging should be enabled
- RDS DB instance multiple az should be enabled
- RDS database instances should use a custom administrator username
- RDS DB instances should prohibit public access
- AWS Redshift audit logging should be enabled
- AWS Redshift clusters should have automatic snapshots enabled
- Redshift cluster encryption in transit should be enabled
- Redshift cluster audit logging and encryption should be enabled
- AWS Redshift enhanced VPC routing should be enabled
- AWS Redshift clusters should be encrypted with KMS
- AWS Redshift should have required maintenance settings
- AWS Redshift clusters should not use the default Admin username
- Redshift clusters should not use the default database name
- Redshift clusters should prohibit public access
- S3 buckets access control lists (ACLs) should not be used to manage user access to buckets
- S3 bucket cross-region replication should be enabled
- S3 bucket default encryption should be enabled
- S3 bucket default encryption should be enabled with KMS
- S3 buckets should have event notifications enabled
- S3 buckets should have lifecycle policies configured
- S3 bucket logging should be enabled
- S3 bucket MFA delete should be enabled
- S3 bucket object lock should be enabled
- S3 bucket policy should prohibit public access
- S3 bucket cross-account permissions should be restricted
- S3 buckets should prohibit public read access
- S3 buckets should prohibit public write access
- S3 buckets with versioning enabled should have lifecycle policies configured
- S3 bucket versioning should be enabled
- S3 public access should be blocked at account level
- S3 public access should be blocked at bucket levels
- SageMaker endpoint configuration encryption should be enabled
- SageMaker notebook instances should not have direct internet access
- SageMaker notebook instance encryption should be enabled
- Secrets Manager secrets should be encrypted using CMK
- VPC subnet auto assign public IP should be disabled
Enable/Disable Controls¶
You can customize the Terraform module for the desired compliance requirements by enabling/disabling individual controls.
Examples¶
S3 bucket module with NIST Cybersecurity Framework v1.1 compliance framework controls enabled, and a couple of controls disabled¶
module "..." {
source = "https://nistcsfv11.compliance.tf/terraform-aws-modules/s3-bucket/aws?disable=apigateway_rest_api_stage_use_ssl_certificate,apigateway_rest_api_stage_xray_tracing_enabled"
}