Dangerous Defaults # 2 - MSK choose Uptime or Data Integrity

Written by

Albert Heinle

We have a series of articles looking at common misconfigurations and dangerous defaults we’ve seen in the wild.

Misconfigured security settings can be disastrous for a company, and they are very common. More common than they need to be.

A security misconfiguration occurs when security settings are either:

Not implemented, or
Deployed with errors.

The configuration settings create security gaps that expose the application and its data to a cyberattack and possible breach.

These errors can happen at any level of the your infrastructure:

IaaS or PaaS
IaC
Container
Application
Development frameworks
Custom code

Many of these misconfigurations happen because developers or system administrators do not change the default configuration of the device or application during installation. This is problematic because many automated attacks start by testing whether a target system uses the default settings.

Next up!

AWS MSK trades uptime for data integrity

We have talked about this before. The default configuration for Amazon Managed Streaming for Apache Kafka (AWS MSK) includes configuration parameters that optimize for having increased cluster availability. The default Amazon MSK setting for unclean.leader.election.enable is true. This setting has a preference availability, i.e., message loss is acceptable and high availability is more important.

This configuration parameter is often set by default to false to allow for data durability. This setting is key when message loss is unacceptable.

It is important to have this parameter flagged for identification because it changes the availability of data.

Example Terraform file for MSK


resource "aws_vpc" "vpc" {
  cidr_block = "192.168.0.0/22"
}

data "aws_availability_zones" "azs" {
  state = "available"
}

resource "aws_subnet" "subnet_az1" {
  availability_zone = data.aws_availability_zones.azs.names[0]
  cidr_block        = "192.168.0.0/24"
  vpc_id            = aws_vpc.vpc.id
}

resource "aws_subnet" "subnet_az2" {
  availability_zone = data.aws_availability_zones.azs.names[1]
  cidr_block        = "192.168.1.0/24"
  vpc_id            = aws_vpc.vpc.id
}

resource "aws_subnet" "subnet_az3" {
  availability_zone = data.aws_availability_zones.azs.names[2]
  cidr_block        = "192.168.2.0/24"
  vpc_id            = aws_vpc.vpc.id
}

resource "aws_security_group" "sg" {
  vpc_id = aws_vpc.vpc.id
}

resource "aws_kms_key" "kms" {
  description = "example"
}

resource "aws_cloudwatch_log_group" "test" {
  name = "msk_broker_logs"
}

resource "aws_s3_bucket" "bucket" {
  bucket = "msk-broker-logs-bucket"
}

resource "aws_s3_bucket_acl" "bucket_acl" {
  bucket = aws_s3_bucket.bucket.id
  acl    = "private"
}

data "aws_iam_policy_document" "assume_role" {
  statement {
    effect = "Allow"

    principals {
      type        = "Service"
      identifiers = ["firehose.amazonaws.com"]
    }

    actions = ["sts:AssumeRole"]
  }
}

resource "aws_iam_role" "firehose_role" {
  name               = "firehose_test_role"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json
}

resource "aws_kinesis_firehose_delivery_stream" "test_stream" {
  name        = "terraform-kinesis-firehose-msk-broker-logs-stream"
  destination = "extended_s3"

  extended_s3_configuration {
    role_arn   = aws_iam_role.firehose_role.arn
    bucket_arn = aws_s3_bucket.bucket.arn
  }

  tags = {
    LogDeliveryEnabled = "placeholder"
  }

  lifecycle {
    ignore_changes = [
      tags["LogDeliveryEnabled"],
    ]
  }
}

resource "aws_msk_cluster" "example" {
  cluster_name           = "example"
  kafka_version          = "3.2.0"
  number_of_broker_nodes = 3

  broker_node_group_info {
    instance_type = "kafka.m5.large"
    client_subnets = [
      aws_subnet.subnet_az1.id,
      aws_subnet.subnet_az2.id,
      aws_subnet.subnet_az3.id,
    ]
    storage_info {
      ebs_storage_info {
        volume_size = 1000
      }
    }
    security_groups = [aws_security_group.sg.id]
  }

  encryption_info {
    encryption_at_rest_kms_key_arn = aws_kms_key.kms.arn
  }

  open_monitoring {
    prometheus {
      jmx_exporter {
        enabled_in_broker = true
      }
      node_exporter {
        enabled_in_broker = true
      }
    }
  }

  logging_info {
    broker_logs {
      cloudwatch_logs {
        enabled   = true
        log_group = aws_cloudwatch_log_group.test.name
      }
      firehose {
        enabled         = true
        delivery_stream = aws_kinesis_firehose_delivery_stream.test_stream.name
      }
      s3 {
        enabled = true
        bucket  = aws_s3_bucket.bucket.id
        prefix  = "logs/msk-"
      }
    }
  }

  tags = {
    foo = "bar"
  }
}

output "zookeeper_connect_string" {
  value = aws_msk_cluster.example.zookeeper_connect_string
}

output "bootstrap_brokers_tls" {
  description = "TLS connection host:port pairs"
  value       = aws_msk_cluster.example.bootstrap_brokers_tls
}

Test Environment

CoGuard CLI version 0.2.14
KICS version 1.7.7-alpine (Docker)
Snyk version 1.1203.0

All tests were done on the above file using macOS and linux versions.

Summary Results

Severity	CoGuard	Snyk	KICS
Total	9	8	23
High	3		5
Medium	2	1	5
Low	4	7	2
INFO			11
Unique Rules	8	8	15

Do more results equal a better code scanner?

There are a few similarities and differences in the results across the three scanners. There is significant variance between the distribution of HIGH vs MEDIUM vs LOW priority vulnerabilities. For a number of reported software vulnerabilities we can compare the results using a CVSS calculator and fill in all of the parameters identified. In the configuration space (or the misconfiguration space), the ranking is a judgment decision for the author of the policy. It becomes critical to understand how violations are scored. We have not been able to find the scoring methodologies for KICS and Snyk with regards to configurations. At CoGuard, we publish our decision guidelines on the user-dashboard (although we allow changes to the sorting and ranking depending on the compliance framework or custom rule set that a specific user has selected).

Generally, it is a tradeoff between “information” and “information overload”. This is quite common in the LOW/INFO items to be able to generate notifications of configurations and warnings. The challenge is to not overwhelm development teams with unnecessary information and CVE fatigue. This is compounded when many of the results essentially double the raised warnings for each file. Many development teams see a large number of results, and estimate the fix as a large effort and the efforts may be deprioritized in triage. What matters is to capture configuration risk, misconfigurations and security vulnerabilities and to prompt the teams to make informed choices and prioritization.

At CoGuard we’re focused on clearly identifying HIGH (and very often MEDIUM) issues, and trying to reduce CVE fatigue/noise. The CoGuard Severity Levels are:

‍

Each of the scanners uses a different approach for identifying and ranking issues. Using scanners for IaC, containers and application configurations is a starting point. This is a starting point for remediating misconfigurations and exploitable security vulnerabilities.

Synk and KICS do not identify the unclean.leader.election.enable parameters, because the setting is a valid setting. But it is a setting that has changed version to version of Kafka, and is different in the Amazon MSK from the default Apache settings. CoGuard raises this as an alert. The question here is what is the correct approach? Not flagging because it is a valid configuration, or raising an issue because the configuration has impacts on availability and data integrity.

CoGuard Results


$ coguard folder ./

          XXXXXXXXXXXK
      xXXXXXXXXXXXXXXXXXXl
    XXXXX.            ;XXXXO       .XXXXXXXXXX     oXXXX        XXXXc       xXXXX'       'XXXXXXXXXXXXO     XXXXXXXXXXX;
  lXXXx    lXXXXXXXX,    0XXX;   cXXXXXXXXXXXXXX.  oXXXX        XXXXc      :XXXXXX       'XXXXXXXXXXXXXXX.  XXXXXXXXXXXXXX'
 dXXX.  .XXXXXx  0XXXXX    ...  dXXXX'      cXXXX. oXXXX        XXXXc     .XXXXXXX0      'XXXX'      OXXXX  XXXXo     .XXXXk
;XXX   xXXX    do   .XXXc      'XXXX,              oXXXX        XXXXc     XXXX.oXXXd     'XXXX'      ,XXXX. XXXXd       XXXXd
0XXl  ;XXk     ,,     KXX.     lXXXX               oXXXX        XXXXc    OXXXl  0XXX:    'XXXX'     .XXXXk  XXXXd       lXXXX
XXX:  oXX: cll.  ,ll: oXX;     oXXXX    .XXXXXXXXo oXXXX        XXXXc   oXXXO   .XXXX.   'XXXXXXXXXXXXXX;   XXXXd       lXXXX
OXXo  ;XXO     do     KXX.     cXXXX.   .XXXXXXXXo oXXXX        XXXXc  ;XXXX     :XXXX   'XXXXXXXXXXXXl     XXXXd       xXXX0
;XXX.  oXXX    ,,   .XXX:      .XXXXo        XXXXo lXXXX       .XXXX: .XXXXXXXXXXXXXXXO  'XXXX'   .XXXXd    XXXXd      ,XXXX;
 oXXX.   XXXXXX:lXXXXXK   ;XXX: .XXXXX.      XXXXo  XXXXX     .XXXX0  XXXXx        XXXXo 'XXXX'    .XXXX0   XXXXd    .XXXXX,
  cXXXO    ;XXXXXXXX.    XXXX'    xXXXXXXXXXXXXXX.   kXXXXXXXXXXXXd  kXXXX         ,XXXX:'XXXX'      XXXXK  XXXXXXXXXXXXXl
    KXXXX;            lXXXXx         'XXXXXXX           cXXXXXX;    lXXXX,          dXXXXlXXXX'       KXXXX XXXXXXXXK
      oXXXXXXXXXXXXXXXXXX:
          OXXXXXXXXXXd
    
SCANNING FOLDER blog-example-msk
Found file /AWS-MSK-example.tf
Found configuration files for terraform in non-standard location.
SCANNING OF blog-example-msk COMPLETED
Scan result: 9 checks failed, 3 High/2 Medium/4 Low (🔧 4 candidates for auto-remediation)
 X Severity 5: terraform_aws_s3_bucket_encryption_resource_always_associated (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  Data stored on S3 buckets can be encrypted at rest. It is
               recommended to always have these encrypted. In Terraform, for
               every `aws_s3_bucket` definition, one needs to define a
               `aws_s3_bucket_server_side_encryption_configuration` definition
               which contains a rule to apply server side encryption. This rule
               checks if every S3 bucket has indeed such a definition. It is to
               be remarked that there is also a deprecated possibility to define
               a `server_side_encryption_configuration` block inside the
               `aws_s3_bucket` resource. This should be avoided and transformed
               into an external resource of type
               `aws_s3_bucket_server_side_encryption_configuration`.
               Remediation: For every resource of type `aws_s3_bucket`, ensure
               that there is an associated
               `aws_s3_bucket_server_side_encryption_configuration` resource
               defined. Inside this resource, under the `rule` section, there
               needs to be the `apply_server_side_encryption_by_default` block
               present.   Source: https://registry.terraform.io/providers/hashic
               orp/aws/latest/docs/resources/s3_bucket_server_side_encryption_co
               nfiguration
🔧  X Severity 5: terraform_aws_msk_always_authenticate (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  In MSK, one needs to always enforce that users need to
               authenticate.  Remediation: For every resource of type
               `aws_msk_cluster`, ensure that the `client_authentication` block
               exists and does not have an `unauthenticated` key inside.
               Source: https://registry.terraform.io/providers/hashicorp/aws/lat
               est/docs/resources/msk_cluster
🔧  X Severity 4: terraform_aws_msk_use_custom_configuration (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  In MSK, one can customize the configuration of the Kafka
               brokers. Since some defaults are generally not recommended, a
               custom configuration should be made.  Remediation: For every
               resource of type `aws_msk_cluster`, ensure that the
               `configuration_info` reference exists.   Source: https://registry
               .terraform.io/providers/hashicorp/aws/latest/docs/resources/msk_c
               luster
 X Severity 3: terraform_aws_s3_bucket_logging_configuration_not_empty (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  Logging access to any resources is a vital pillar for security.
               Hence, it is important that every S3 Bucket resource is set up
               with a proper logging configuration.  Remediation: For every
               resource of type `aws_s3_bucket`, ensure that either a `logging`
               configuration block exists (deprecated), or that a resource of
               type `aws_s3_bucket_logging` exists referencing this bucket.
               Source: https://registry.terraform.io/providers/hashicorp/aws/lat
               est/docs/resources/s3_bucket, https://registry.terraform.io/provi
               ders/hashicorp/aws/latest/docs/resources/s3_bucket_logging
🔧  X Severity 3: terraform_aws_cloudwatch_use_custom_key (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  CloudWatch encrypts data by default using a default encryption
               key. However, in order to be able to enforce key rotation, it is
               recommended to use a custom key.  Remediation: For every resource
               of type `aws_cloudwatch_log_group`, ensure that the `kms_key_id`
               is set to a specific value.   Source: https://registry.terraform.
               io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_log_g
               roup
 X Severity 2: terraform_aws_s3_bucket_versioning_enabled (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  S3 Buckets allow for versioning of objects stored. This is
               generally recommended, since it allows to access different
               versions of objects stored in S3.  Remediation: For every
               resource of type `aws_s3_bucket`, ensure that a resource of type
               `aws_s3_bucket_versioning` exists referencing this bucket, which
               has in its `versioning_configuration` block the `status` set to
               `Enabled`.   Source: https://registry.terraform.io/providers/hash
               icorp/aws/latest/docs/resources/s3_bucket_versioning
 X Severity 1: terraform_aws_s3_bucket_object_lock_config_resource_enabled (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  If there is a resource of `type
               aws_s3_bucket_object_lock_configuration`, ensure that its
               internal key `object_lock_enabled` is set to `Enabled`, or
               `object_lock_enabled` is set to enabled in the `aws_s3_bucket`
               resource itself.  Remediation: For every resource of type
               `aws_s3_bucket_object_lock_configuration`, ensure that either the
               `object_lock_enabled` key inside this configuration is set, or
               that the associated s3_bucket has `object_lock_enabled` set to
               enabled.   Source: https://registry.terraform.io/providers/hashic
               orp/aws/latest/docs/resources/s3_bucket_object_lock_configuration
               , https://registry.terraform.io/providers/hashicorp/aws/latest/do
               cs/resources/s3_bucket
 X Severity 1: terraform_aws_no_unused_security_groups (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  When defining a security group for EC2-instances, we also expect
               it to be used.  Remediation: For every resource of type
               `aws_security_group`, ensure that it is referenced at least in
               one `aws_instance` resource under `security_groups` or
               `vpc_security_group_ids`.   Source: https://registry.terraform.io
               /providers/hashicorp/aws/latest/docs/resources/instance
🔧  X Severity 1: terraform_aws_cloudwatch_set_retention_period (affected files: ./AWS-MSK-example.tf for service terraform)
Documentation:  By default, CloudWatch keeps logs indefinitely, and hence is
               causing potentially unnecessary storage costs.  Remediation: For
               every resource of type `aws_cloudwatch_log_group`, ensure that
               the `retention_in_days` key is set to anything else but 0
               (default).   Source: https://registry.terraform.io/providers/hash
               icorp/aws/latest/docs/resources/cloudwatch_log_group
Scan result: 9 checks failed, 3 High/2 Medium/4 Low (🔧 4 candidates for auto-remediation)

Snyk Results


$ snyk iac test --report --org=927c4fe6-f615-45ae-97f8-954e44413e8d

Snyk Infrastructure as Code

✔ Test completed.

Issues

Low Severity Issues: 7

  [Low] CloudWatch log group not encrypted with managed key
  Info:    Log group is not encrypted with customer managed key. Scope of use of
           the key cannot be controlled via KMS/IAM policies
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-AWS-415
  Path:    resource > aws_cloudwatch_log_group[test] > kms_key_id
  File:    AWS-MSK-example.tf
  Resolve: Set `kms_key_id` attribute with customer managed key id

  [Low] S3 bucket versioning disabled
  Info:    S3 bucket versioning is disabled. Changes or deletion of objects will
           not be reversible
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-124
  Path:    resource > aws_s3_bucket[bucket] > versioning > enabled
  File:    AWS-MSK-example.tf
  Resolve: For AWS provider < v4.0.0, set `versioning.enabled` attribute to
           `true`. For AWS provider >= v4.0.0, add aws_s3_bucket_versioning
           resource.

  [Low] S3 bucket MFA delete control disabled
  Info:    S3 bucket will not enforce MFA login on delete requests. Object could
           be deleted without stronger MFA authorization
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-127
  Path:    resource > aws_s3_bucket[bucket] > versioning > mfa_delete
  File:    AWS-MSK-example.tf
  Resolve: Follow instructions in `https://docs.aws.amazon.com/AmazonS3/latest/u
           serguide/MultiFactorAuthenticationDelete.html` to manually configure
           the MFA setting. For AWS provider < v4.0.0 set
           `versioning.mfa_delete` attribute to `true` in aws_s3_bucket
           resource. For AWS provider >= v4.0.0 set
           'versioning_configuration.mfa_delete` attribute to `Enabled`. The
           terraform change is required to reflect the setting in the state file

  [Low] CloudWatch Log group retention period not set
  Info:    Amazon CloudWatch log group does not specify retention period. Logs
           will be kept indefinitely and incur AWS costs
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-134
  Path:    resource > aws_cloudwatch_log_group[test] > retention_in_days
  File:    AWS-MSK-example.tf
  Resolve: Set `retention_in_days` attribute to required value, e.g. set `365`

  [Low] KMS key does not have key rotation enabled
  Info:    That your encryption keys are not being rotated by AWS. That data is
           being encrypted with a key which is valid for a longer period of
           time, resulting in a greater exposure window should that key be
           leaked
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-14
  Path:    input > resource > aws_kms_key[kms] > enable_key_rotation
  File:    AWS-MSK-example.tf
  Resolve: Set `enable_key_rotation` attribute to `true`

  [Low] S3 server access logging is disabled
  Info:    The s3 access logs will not be collected. There will be no audit
           trail of access to s3 objects
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-45
  Path:    input > resource > aws_s3_bucket[bucket] > logging
  File:    AWS-MSK-example.tf
  Resolve: For AWS provider < v4.0.0, add `logging` block attribute. For AWS
           provider >= v4.0.0, add aws_s3_bucket_logging resource.

  [Low] Security group description is missing
  Info:    The description field is missing in the security group. Increases the
           security management overhead
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-TF-56
  Path:    resource > aws_security_group[sg] > description
  File:    AWS-MSK-example.tf
  Resolve: Set `description` attribute to meaningful statement

Medium Severity Issues: 1

  [Medium] Kinesis data stream is not encrypted at rest
  Info:    Data stream is not encrypted at rest. Sensitive data processed by the
           stream may be readable in the kinesis storage layer
  Rule:    https://security.snyk.io/rules/cloud/SNYK-CC-AWS-450
  Path:    resource > aws_kinesis_firehose_delivery_stream[test_stream] >
           server_side_encryption
  File:    AWS-MSK-example.tf
  Resolve: Set `server_side_encryption.enabled` attribute to `true`

-------------------------------------------------------

Test Summary

  Organization: d-U5bKD53qopZ7jyVZGLXF3N
  Project name: blog-example-msk

✔ Files without issues: 0
✗ Files with issues: 1
  Ignored issues: 0
  Total issues: 8 [ 0 critical, 0 high, 1 medium, 7 low ]

-------------------------------------------------------

Report Complete

KICS Results

$ docker run -t -v ~/src/blog-example-msk:/path checkmarx/kics:latest scan -p /path/AWS-MSK-example.tf -o "/path/"

                   .0MO.                                    
                   OMMMx                                    
                   ;NMX;                                    
                    ...           ...              ....     
WMMMd     cWMMM0.  KMMMO      ;xKWMMMMNOc.     ,xXMMMMMWXkc.
WMMMd   .0MMMN:    KMMMO    :XMMMMMMMMMMMWl   xMMMMMWMMMMMMl
WMMMd  lWMMMO.     KMMMO   xMMMMKc...'lXMk   ,MMMMx   .;dXx 
WMMMd.0MMMX;       KMMMO  cMMMMd        '    'MMMMNl'       
WMMMNWMMMMl        KMMMO  0MMMN               oMMMMMMMXkl.  
WMMMMMMMMMMo       KMMMO  0MMMX                .ckKWMMMMMM0.
WMMMMWokMMMMk      KMMMO  oMMMMc              .     .:OMMMM0
WMMMK.  dMMMM0.    KMMMO   KMMMMx'    ,kNc   :WOc.    .NMMMX
WMMMd    cWMMMX.   KMMMO    kMMMMMWXNMMMMMd .WMMMMWKO0NMMMMl
WMMMd     ,NMMMN,  KMMMO     'xNMMMMMMMNx,   .l0WMMMMMMMWk, 
xkkk:      ,kkkkx  okkkl        ;xKXKx;          ;dOKKkc    


Scanning with Keeping Infrastructure as Code Secure v1.7.9


Preparing Scan Assets: Done                                                                                                                           
Executing queries: [---------------------------------------------------] 100.00%

Files scanned: 1
Parsed files: 1
Queries loaded: 1045
Queries failed to execute: 0

------------------------------------

Security Group Rule Without Description, Severity: INFO, Results: 1
Description: It's considered a best practice for AWS Security Group to have a description
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/cb3f5ed6-0d18-40de-a93d-b3538db31e8c

	[1]: ../../path/AWS-MSK-example.tf:27

		026: 
		027: resource "aws_security_group" "sg" {
		028:   vpc_id = aws_vpc.vpc.id


Resource Not Using Tags, Severity: INFO, Results: 9
Description: AWS services resource tags are an essential part of managing components. As a best practice, the field 'tags' should have additional tags defined other than 'Name'
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e38a8e0a-b88b-4902-b3fe-b0fcb17d5c10

	[1]: ../../path/AWS-MSK-example.tf:35

		034: 
		035: resource "aws_cloudwatch_log_group" "test" {
		036:   name = "msk_broker_logs"


	[2]: ../../path/AWS-MSK-example.tf:39

		038: 
		039: resource "aws_s3_bucket" "bucket" {
		040:   bucket = "msk-broker-logs-bucket"


	[3]: ../../path/AWS-MSK-example.tf:9

		008: 
		009: resource "aws_subnet" "subnet_az1" {
		010:   availability_zone = data.aws_availability_zones.azs.names[0]


	[4]: ../../path/AWS-MSK-example.tf:15

		014: 
		015: resource "aws_subnet" "subnet_az2" {
		016:   availability_zone = data.aws_availability_zones.azs.names[1]


	[5]: ../../path/AWS-MSK-example.tf:21

		020: 
		021: resource "aws_subnet" "subnet_az3" {
		022:   availability_zone = data.aws_availability_zones.azs.names[2]


	[6]: ../../path/AWS-MSK-example.tf:1

		001: resource "aws_vpc" "vpc" {
		002:   cidr_block = "192.168.0.0/22"
		003: }


	[7]: ../../path/AWS-MSK-example.tf:61

		060: 
		061: resource "aws_iam_role" "firehose_role" {
		062:   name               = "firehose_test_role"


	[8]: ../../path/AWS-MSK-example.tf:31

		030: 
		031: resource "aws_kms_key" "kms" {
		032:   description = "example"


	[9]: ../../path/AWS-MSK-example.tf:27

		026: 
		027: resource "aws_security_group" "sg" {
		028:   vpc_id = aws_vpc.vpc.id


Output Without Description, Severity: INFO, Results: 1
Description: All outputs should contain a valid description.
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/common/59312e8a-a64e-41e7-a252-618533dd1ea8

	[1]: ../../path/AWS-MSK-example.tf:144

		143: 
		144: output "zookeeper_connect_string" {
		145:   value = aws_msk_cluster.example.zookeeper_connect_string


VPC FlowLogs Disabled, Severity: LOW, Results: 1
Description: Every VPC resource should have an associated Flow Log
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/f83121ea-03da-434f-9277-9cd247ab3047

	[1]: ../../path/AWS-MSK-example.tf:1

		001: resource "aws_vpc" "vpc" {
		002:   cidr_block = "192.168.0.0/22"
		003: }


IAM Access Analyzer Not Enabled, Severity: LOW, Results: 1
Description: IAM Access Analyzer should be enabled and configured to continuously monitor resource permissions
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/e592a0c5-5bdb-414c-9066-5dba7cdea370

	[1]: ../../path/AWS-MSK-example.tf:1

		001: resource "aws_vpc" "vpc" {
		002:   cidr_block = "192.168.0.0/22"
		003: }


VPC Without Network Firewall, Severity: MEDIUM, Results: 1
Description: VPC should have a Network Firewall associated
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/fd632aaf-b8a1-424d-a4d1-0de22fd3247a

	[1]: ../../path/AWS-MSK-example.tf:1

		001: resource "aws_vpc" "vpc" {
		002:   cidr_block = "192.168.0.0/22"
		003: }


S3 Bucket Without Versioning, Severity: MEDIUM, Results: 1
Description: S3 bucket should have versioning enabled
Platform: Terraform
Learn more about this vulnerability: https://docs.kics.io/latest/queries/terraform-queries/aws/568a4d22-3517-44a6-a7ad-6a7eed88722c

	[1]: ../../path/AWS-MSK-example.tf:39

		038: 
		039: resource "aws_s3_bucket" "bucket" {
		040:   bucket = "msk-broker-logs-bucket"


Shield Advanced Not In Use, Severity: LOW, Results: 1
Description: AWS Shield Advanced should be used for Amazon Route 53 hosted zone, AWS Global Accelerator accelerator, Elastic IP Address, Elastic Load Balancing, and Amazon CloudFront Distribution to protect these resources against robust DDoS attacks
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/ad7444cf-817a-4765-a79e-2145f7981faf

	[1]: ../../path/AWS-CloudFormation-Example.yml:15

		014: 
		015:   OpenVPNElasticIP:
		016:     Type: AWS::EC2::EIP


IAM Access Analyzer Not Enabled, Severity: LOW, Results: 1
Description: IAM Access Analyzer should be enabled and configured to continuously monitor resource permissions
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/8d29754a-2a18-460d-a1ba-9509f8d359da

	[1]: ../../path/AWS-CloudFormation-Example.yml:4

		003: 
		004: Resources:
		005:   MyVPC:


VPC Without Network Firewall, Severity: MEDIUM, Results: 1
Description: VPC should have a Network Firewall associated
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/3e293410-d5b8-411f-85fd-7d26294f20c9

	[1]: ../../path/AWS-CloudFormation-Example.yml:5

		004: Resources:
		005:   MyVPC:
		006:     Type: AWS::EC2::VPC


Instance With No VPC, Severity: MEDIUM, Results: 2
Description: EC2 Instances should be configured under a VPC network. AWS VPCs provide the controls to facilitate a formal process for approving and testing all network connections and changes to the firewall and router configurations.
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/8a6d36cd-0bc6-42b7-92c4-67acc8576861

	[1]: ../../path/AWS-CloudFormation-Example.yml:66

		065:     Type: AWS::EC2::Instance
		066:     Properties:
		067:       InstanceType: g4dn.xlarge  # GPU-optimized instance type


	[2]: ../../path/AWS-CloudFormation-Example.yml:46

		045:     Type: AWS::EC2::Instance
		046:     Properties:
		047:       InstanceType: t2.micro  # Adjust the instance type as needed


EC2 Instance Has No IAM Role, Severity: MEDIUM, Results: 2
Description: Check if an EC2 instance refers to an IAM profile, which represents an IAM Role.
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/f914357d-8386-4d56-9ba6-456e5723f9a6

	[1]: ../../path/AWS-CloudFormation-Example.yml:66

		065:     Type: AWS::EC2::Instance
		066:     Properties:
		067:       InstanceType: g4dn.xlarge  # GPU-optimized instance type


	[2]: ../../path/AWS-CloudFormation-Example.yml:46

		045:     Type: AWS::EC2::Instance
		046:     Properties:
		047:       InstanceType: t2.micro  # Adjust the instance type as needed


EBS Volume Without KmsKeyId, Severity: MEDIUM, Results: 2
Description: EBS Volume should specify a KmsKeyId value
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/b7063015-6c31-4658-a8e7-14f98f37fd42

	[1]: ../../path/AWS-CloudFormation-Example.yml:84

		083:     Type: AWS::EC2::Volume
		084:     Properties:
		085:       AvailabilityZone: !GetAtt OpenVPNInstance.AvailabilityZone


	[2]: ../../path/AWS-CloudFormation-Example.yml:78

		077:     Type: AWS::EC2::Volume
		078:     Properties:
		079:       AvailabilityZone: !GetAtt GPUInstance.AvailabilityZone


EBS Volume Not Attached To Instances, Severity: MEDIUM, Results: 1
Description: EBS Volumes that are unattached to instances may contain sensitive data
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/1819ac03-542b-4026-976b-f37addd59f3b

	[1]: ../../path/AWS-CloudFormation-Example.yml:82

		081: 
		082:   OpenVPNVolume:
		083:     Type: AWS::EC2::Volume


EBS Volume Encryption Disabled, Severity: MEDIUM, Results: 2
Description: EBS volumes should be encrypted
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/80b7ac3f-d2b7-4577-9b10-df7913497162

	[1]: ../../path/AWS-CloudFormation-Example.yml:84

		083:     Type: AWS::EC2::Volume
		084:     Properties:
		085:       AvailabilityZone: !GetAtt OpenVPNInstance.AvailabilityZone


	[2]: ../../path/AWS-CloudFormation-Example.yml:78

		077:     Type: AWS::EC2::Volume
		078:     Properties:
		079:       AvailabilityZone: !GetAtt GPUInstance.AvailabilityZone


Unrestricted Security Group Ingress, Severity: HIGH, Results: 2
Description: AWS Security Group Ingress CIDR should not be open to the world
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/4a1e6b34-1008-4e61-a5f2-1f7c276f8d14

	[1]: ../../path/AWS-CloudFormation-Example.yml:31

		030:           ToPort: 22
		031:           CidrIp: 0.0.0.0/0 # Adjust this to restrict source IPs if necessary
		032: 


	[2]: ../../path/AWS-CloudFormation-Example.yml:27

		026:           ToPort: 1194
		027:           CidrIp: 0.0.0.0/0  # Adjust this to restrict source IPs if necessary
		028:         - IpProtocol: tcp


Unknown Port Exposed To Internet, Severity: HIGH, Results: 1
Description: AWS Security Group should not have an unknown port exposed to the entire Internet
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/829ce3b8-065c-41a3-ad57-e0accfea82d2

	[1]: ../../path/AWS-CloudFormation-Example.yml:24

		023:       SecurityGroupIngress:
		024:         - IpProtocol: udp
		025:           FromPort: 1194


Security Groups With Exposed Admin Ports, Severity: HIGH, Results: 1
Description: Security Groups should not have ports open in (20, 21, 22, 23, 115, 137, 138, 139, 2049, 3389)
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/cdbb0467-2957-4a77-9992-7b55b29df7b7

	[1]: ../../path/AWS-CloudFormation-Example.yml:23

		022:       VpcId: !Ref MyVPC
		023:       SecurityGroupIngress:
		024:         - IpProtocol: udp


Security Group With Unrestricted Access To SSH, Severity: HIGH, Results: 1
Description: 'SSH' (TCP:22) should not be public in AWS Security Group
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/6e856af2-62d7-4ba2-adc1-73b62cef9cc1

	[1]: ../../path/AWS-CloudFormation-Example.yml:23

		022:       VpcId: !Ref MyVPC
		023:       SecurityGroupIngress:
		024:         - IpProtocol: udp


HTTP Port Open To Internet, Severity: HIGH, Results: 1
Description: The HTTP port is open to the internet in a Security Group
Platform: CloudFormation
Learn more about this vulnerability: https://docs.kics.io/latest/queries/cloudformation-queries/aws/ddfc4eaa-af23-409f-b96c-bf5c45dc4daa

	[1]: ../../path/AWS-CloudFormation-Example.yml:29

		028:         - IpProtocol: tcp
		029:           FromPort: 22  # SSH
		030:           ToPort: 22



Results Summary:
HIGH: 6
MEDIUM: 10
LOW: 4
INFO: 6
TOTAL: 26

Results saved to file /path/results.json
Generating Reports: Done                                                                                                                              
Scan duration: 12.241437548s

Conclusion

The role of static analyzer is to detect:

security vulnerabilities,
performance issues,
non-compliance with standards,
And the use of out of date programming constructs.

This is the problem where dangerous defaults come in. The moment a resource is defined it should be evaluated against the above criteria. In the situation described above, CoGuard flags the lack of a cleanliness of leader election configuration because it has a direct impact on changes in expectation about availability and data integrity. There are additional default configurations in Amazon MSK that may or may not function as intended. At CoGuard, we recognize when defaults are not set and we’ll remind you to set the values to something you think is good. And we’ll scan the configurations for ya!

This is an interesting moment where the knowledge base of the CoGuard team in the different areas of IaC became beneficial. We support native Kafka configurations, and when we saw the MSK service of AWS, we were interested in how Kafka settings were set there. In this way, we could mark errors to the users.

Especially with the unclean leader election, it is important that a user would be aware of the potential issues of AWS’s default decision. Even if the user opts to ignore the issue, they were at latest made aware of that. And this is the whole point of Linters and scanners: Inform your user-base of anything that may be relevant to them, without being too noisy.

What this example also has shown is the same issue discussed about platforms as a service (PaaS). There is a shared responsibility model between the user and the service. Just because you are using AWS MSK is NOT a guarantee that everything is done right (though it might be correct) automatically (out of the box). Always look out for ways to figure out the configuration, and scan it.

Get started for free

At CoGuard, we believe that static analysis is an incredibly useful tool for developers, operations and security teams. As teams adopt cloud native applications, security and configuration requires new insights across cloud configurations, containers, applications and firewalls. You can get started for free today.

pip3 install coguard-cli
coguard folder ./

Photo by Robert Linder on Unsplash

Dangerous Defaults