fix(query): fn for API Gateway With CloudWatch Logging Disabled - terraform/aws

[cx-andre-pereira]

Reason for Proposed Changes

• Currently the API Gateway With CloudWatch Logging Disabled terraform query does not account for the access_log_settings.destination_arn field of the aws_api_gateway_stage resource.

• This query is meant to flag whenever "CloudWatch Logs" are not enabled for a aws_api_gateway_stage resource; currently it only checks for a aws_cloudwatch_log_group resource that has a "name" field that references the relevant aws_api_gateway_stage's stage_name . To do this the haveLogs function checks for a specific regex match where given a stage_name like "example" the "name" of the aws_cloudwatch_log_group could be :

  • name = "API-Gateway-Execution-Logs_${aws_api_gateway_rest_api.example.id}/${example}"

• This is shown in the negative1 test with "var.stage_name" as the stage_name. The "name" also references an aws_api_gateway_rest_api resource but that is irrelevant for the purposes of this query.

• The missing case is associated with the access_log_settings.destination_arn field from the aws_api_gateway_stage since this field's purpose is to define where to send access logs as per the documentation. This is a glaring flaw and the field must be accounted for.

Proposed Changes

• Fixed a typo in the original message, and altered said message to be more informative (original message stated "not undefined" when it should say "undefined").

• Fixed a logic error unrelated to the False Positive that caused the scan of a folder to not give results that scanning an individual file would, this was due to the fact that the auxiliary function was scanning through all "documents" in the generated payload.

• Added new helper functions and a "master" helper function get_results that will define the flagging order. I decided that, in case a sample does not have a valid "stage_name" or a valid "destination_arn", it is the "destination_arn" that will be flagged since it is a resource that exists solely to properly reference a aws_cloudwatch_log_group, while the stage_name will flag simply because no aws_cloudwatch_log_group resource properly referenced it and not because it is totally invalid.

• Added 2 different resultvalues depending on the reason for the query flagging. This results are given by the does_not_have_valid_stage_name policy that is very much alike the original query logic and the new does_not_have_valid_destination_arn for the missing case. Note that the "destination_arn" must also respect a specific regex pattern as such :

  • regexPattern := sprintf("aws_cloudwatch_log_group.%s.arn", [name])

• Where the "name" is the literal name of the aws_cloudwatch_log_group not its "name" field.

• Added tests for the new case :

  • negative3 has a valid destination_arn
  • negative4 has a null destination_arn but a valid stage_name
  • negative5 has a valid destination_arn and stage_name
  • positive2 has an invalid destination_arn and stage_name
  • positive3 has a null destination_arn and stage_name
  • positive4 has no access_log_settings field and an invalid stage_name.

• A test case for the access_log_settings field without the destination_arn was not added since the destination_arn is a required for said field.

Note : From my research modules cannot replace this resource since even using modules that can provide similar functions like api-gateway, they cannot define the aws_api_gateway_stage to aws_cloudwatch_log_group interaction that causes this query to flag by themselves.

I submit this contribution under the Apache-2.0 license.

[github-actions]

KICS version: v2.1.13

Category Results CRITICAL 0 HIGH 0 MEDIUM 0 LOW 0 INFO 0 TRACE 0 TOTAL 0	Metric Values Files scanned 1 Files parsed 1 Files failed to scan 0 Total executed queries 47 Queries failed to execute 0 Execution time 0

[cx-artur-ribeiro]

Just a quick fix to the message but apart from that everything looks good :)

[cx-artur-ribeiro]

LGTM

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
20838717	Triggered	Generic Password	a12d5a1	assets/queries/azureResourceManager/sql_server_database_with_alerts_disabled/test/negative7.bicep	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}