Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

November policies #980

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@

== AWS SQS queue encryption using default KMS key instead of CMK

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| 45f307ff-288c-4f87-92ec-bee6d0318b27

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/graph_checks/aws/SQSEncryptionCMK.yaml[CKV2_AWS_73]

|Severity
|INFO

|Subtype
|Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

This policy detects whether AWS Simple Queue Service (SQS) queues are encrypted with default AWS-managed keys instead of customer-managed keys (CMKs).

Using a customer-managed key (CMK) is recommended over default AWS-managed keys as CMKs provide enhanced security and greater control. With CMKs, users can define key policies, manage usage permissions, and monitor access controls and key rotations. By ensuring SQS queues use CMKs, organizations can enforce stricter access control and auditing, improving the security of data stored in and transmitted through SQS. In contrast, relying on AWS-managed keys shifts these controls to AWS, potentially broadening access and reducing user oversight.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_sqs_queue
* *Arguments:* kms_master_key_id

Specify the `kms_master_key_id` attribute in your `aws_sqs_queue` resource to ensure AWS SQS uses a Customer Managed Key (CMK) for AWS SQS encryption instead of the default AWS-managed keys. Provide the ARN of the CMK you intend to use for encryption in this attribute.

This example shows how to modify an SQS queue resource in Terraform to use a CMK for encryption.


[source,go]
----
resource "aws_sqs_queue" "example" {
...
+ kms_master_key_id = aws_kms_key.example.arn
...
}
----
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@

== AWS CloudFront web distribution with geo restriction disabled

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| a920a1a2-6856-4eb2-b2db-7aee4ce03f4c

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/CloudFrontGeoRestrictionDisabled.py[CKV_AWS_374]

|Severity
|LOW

|Subtype
|Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

The policy is checking whether AWS CloudFront web distributions have geographic restrictions enabled. This involves setting up geo restrictions to control access based on the geographic location of users attempting to access the content distributed by CloudFront.

Enabling geographic restrictions is important for maintaining control over where your content is accessible. This helps ensure compliance with regional legal and regulatory requirements while enhancing security by blocking access from regions irrelevant to your business or associated with potential malicious activity. By implementing geo restrictions, you can better protect your data and align with regional laws and policies.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_cloudfront_distribution
* *Arguments:* restrictions

Enable geo restriction for your AWS CloudFront distribution by including a restrictions block inside the aws_cloudfront_distribution resource. This block allows you to configure geo restrictions by specifying which countries are allowed or denied access.

This example demonstrates how to enable geo restriction for an AWS CloudFront distribution using Terraform.

[source,go]
----
resource "aws_cloudfront_distribution" "example" {
...
restrictions {
geo_restriction {
restriction_type = "whitelist" # Or "blacklist" depending on your use case
locations = ["US", "CA", "GB"] # Example of allowed countries
}
}
...
}
----

Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@

== AWS S3 bucket has global view ACL permissions enabled

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| 43c42760-5283-4bc4-ac43-a80e58c4139f

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/S3GlobalViewACL.py[CKV_AWS_375]

|Severity
|LOW

|Subtype
|Run,Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

This policy detects whether AWS S3 buckets have global view ACL (Access Control List) permissions enabled. It aims to prevent buckets from being publicly accessible, which could occur if global read permissions are granted through its ACL settings.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_s3_bucket_acl
* *Arguments:* access_control_policy

Set your AWS S3 bucket ACL to private to avoid global view permissions. Do not use settings like public-read, public-read-write, or authenticated-read. Instead, use specific bucket policies and IAM roles to restrict access.

This example demonstrates how to modify your Terraform configuration to ensure the S3 bucket's ACL does not have global view ACL permissions.

[source,go]
----
resource "aws_s3_bucket_acl" "example" {
...
access_control_policy {
grant {
grantee {
type = "Group"
- uri = "http://acs.amazonaws.com/groups/global/AllUsers"
}
permission = "READ_ACP"
}
}
----
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@

== AWS Elastic Load Balancer with listener TLS/SSL is not configured

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| 836a7c8c-34c2-4861-be1e-df2f8cd27aab

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/ELBwListenerNotTLSSSL.py[CKV_AWS_376]

|Severity
|LOW

|Subtype
|Run,Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

This policy detects whether AWS Elastic Load Balancer (ELB) listeners are configured to use TLS/SSL (Transport Layer Security/Secure Sockets Layer) protocols. These protocols safeguard communication by encrypting data exchanged over the network, ensuring that data transmitted between clients and the load balancer remains secure and protected from unauthorized access.

Without TLS/SSL, transmitted data is vulnerable to interception, tampering, or unauthorized access by malicious actors, potentially leading to data breaches and the loss of sensitive information. Enforcing TLS/SSL on ELB listeners is essential to protect the integrity and confidentiality of data in transit, ensuring secure communication channels for applications.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_elb
* *Arguments:* instance_protocol

Specify the instance_protocol as HTTPS or SSL in your aws_elb resource configuration to ensure the AWS Elastic Load Balancer listener uses TLS/SSL.

In this example, the Terraform configuration is modified to set HTTPS or SSL as the protocol for the load balancer listener. This ensures that traffic between clients and the load balancer is encrypted.

[source,go]
----
resource "aws_elb" "example" {
...
listener {
instance_port = 8000
- instance_protocol = "http"
+ instance_protocol = "https"
lb_port = 80
lb_protocol = "http"
}
}
----

Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
== Route 53 domains do not have transfer lock protection

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| TBD

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/Route53TransferLock.py[CKV_AWS_377]

|Severity
|LOW

|Subtype
|Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

This policy detects whether Route 53 domains have transfer lock protection disabled. The transfer lock feature is important because it prevents unauthorized domain transfers to another registrar. When a domain is locked, it cannot be transferred without explicit permission from the domain owner, protecting against accidental or malicious domain hijacking. Without this protection, a domain could be transferred without the owner’s knowledge or approval, leading to potential service disruptions, loss of business, and security risks, especially for domains critical to business operations or brand presence.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_route53domains_registered_domain
* *Arguments:* transfer_lock

Set the `transfer_lock` attribute to `true` for each `aws_route53domains_registered_domain` resource to ensure that your Route 53 domains have transfer lock protection enabled. This security feature prevents unauthorized domain transfers.

In this example, transfer lock protection for an AWS Route 53 domain is enabled using a Terraform configuration.

[source,go]
----
resource "aws_route53domains_registered_domain" "example" {
...
+ transfer_lock = true
...
}
----

Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@

== AWS S3 bucket not configured with secure data transport policy

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| 7b0df373-006a-40d6-9f3d-68e6ea0bdd5d

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/S3SecureDataTransport.py[CKV_AWS_379]

|Severity
|MEDIUM

|Subtype
|Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

To ensure secure data transport, configure your AWS S3 bucket to block public access or explicitly enforce aws:SecureTransport = true in your bucket policy. This ensures that all data transfers to and from the bucket use HTTPS, providing encryption and protecting the data from unauthorized access during transit.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_s3_bucket_acl
* *Arguments:* aws_s3_bucket_public_access_block, access_control_policy

To ensure secure data transport, configure your AWS S3 bucket to block public access or explicitly enforce `aws:SecureTransport = true` in your bucket policy. This ensures that all data transfers to and from the bucket use HTTPS, providing encryption and protecting the data from unauthorized access during transit.

tsmithv11 marked this conversation as resolved.
Show resolved Hide resolved
The following example demonstrates how to configure an AWS S3 bucket policy in Terraform to enforce secure data transport by requiring HTTPS for all data transfers to and from the bucket.

[source,go]
----
resource "aws_s3_bucket_policy" "example" {
...
policy = jsonencode({
...
Statement = [
{
Sid = "DenyInsecureTransport"
Effect = "Allow"
Principal = "*"
Action = "s3:*"
Resource = [
aws_s3_bucket.example.arn
]
Condition = {
Bool = {
"aws:SecureTransport" = "true"
}
}
}
]
})
}
----

Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@

== AWS Transfer Server not using latest Security Policy

=== Policy Details

[width=45%]
[cols="1,1"]
|===
|Prisma Cloud Policy ID
| TBD

|Checkov ID
| https://github.com/bridgecrewio/checkov/blob/main/checkov/terraform/checks/resource/aws/TransferServerLatestPolicy.py[CKV_AWS_380]

|Severity
|LOW

|Subtype
|Build

|Frameworks
|Terraform,TerraformPlan

|===

=== Description

This policy detects whether an AWS Transfer Server is not configured to use the latest security policy, defined as one that is no older than 24 months. Security policies in AWS Transfer specify the encryption algorithms and protocols used during file transfers. Using outdated policies can be risky, as they may rely on deprecated or weaker encryption methods vulnerable to security threats. By ensuring that the latest security policy is applied, organizations can maintain strong encryption standards, enhance data protection, and adhere to best practices for secure communication, safeguarding sensitive data from unauthorized access and potential breaches.

=== Fix - Buildtime

*Terraform*

* *Resource:* aws_transfer_server
* *Arguments:* security_policy_name

Set your AWS Transfer Server to use the latest security policy to secure data transfers. Associate each `aws_transfer_server` resource with the most recent `security_policy_name` to maintain high security standards.

In this example, the security policy for an AWS Transfer Server is updated to the latest version using Terraform.

[source,go]
----
resource "aws_transfer_server" "example" {
...
+ security_policy_name = "TransferSecurityPolicy-2024-01"
...
}
----

Loading
Loading