fix(query): fn for EFS volume with disabled transit encryption--cloudformation/aws

[cx-andre-pereira]

Closes #7093
Reason for Proposed Changes

• The purpose of this query is to check all ECS:Task-Definition resources and guarantee that, within their Volumes.EFSVolumeConfiguration field, TransitEncryption is defined and set to "ENABLED". This will ensure Amazon EFS volume(s) have encryption for data at transit.

• The query and all its test, currently, have syntax errors for the Volumes and EFSVolumeConfiguration fields; put simple the capitalization of character is inconsistent with official documentation which clearly declares the fields with this syntax. There are no analog naming schemes mentioned and these field´s naming is case sensitive.

• While investigation the reason for this seemingly dysfunctional since inception query, it was made clear that it is analog to a terraform query "ECS Task Definition Volume Not Encrypted". In terraform the fields are named in lowercase and the adjustment for CloudFormation was never properly done. There was an attempt but it only updated the transitEncryption to TransitEncryption.

• Furtermore there is currently another CloudFormation query that is doing a very similar scan even though it is unrelated to its name/purpose. The "ECS Cluster Not Encrypted At Rest" query , which got updated recently as of writing (PR), is doing a near identical check except for the fact that it will only check the relevant ECS:Task-Definition resources, if they are referenced by an ECS:Service resource in its TaskDefinition field. The confusion might have sparked from the fact that both queries try to ensure encryption is enabled but the types of encryption are different and are not interchangeable. (At Rest Encryption / In Transit Encryption)

• Both CloudFormation queries are , currently, missing the case for the lack of the EFSVolumeConfiguration field; this case is not missing in the original terraform query.

• Given all this we have :

  • The "EFS Volume With Disabled Transit Encryption" CloudFormation query with incorrect field referencing.
  • The "ECS Cluster Not Encrypted At Rest" query which is doing something similar but condition and unrelated to its name/description.
  • The "ECS Task Definition Volume Not Encrypted" terraform query analog to the CloudFormation query but with considerably different naming.

Proposed Changes

• I started by simply adjusting all mentions of the 2 relevant fields (Volumes and EFSVolumeConfiguration) to the correct nomenclature.

• Additionally i found the test folder to be lacking yaml test files, currently it has exclusively JSON files. I created tests similar to the ones already incorporated written in yaml format whilst also adjusting the field naming.

• Some E2E tests have been updated since the AWS::ECS::TaskDefinition resource from e2e/fixtures/samples/positive.yaml is now flagging as it always should have, due to lack of the EFSVolumeConfiguration field.

• Finally i adjusted the "searchKey" values to pinpoint results more accurately in the same way the "searchLine" was already doing and i implemented the missing case found on the terraform original query. (case of missing "EFSVolumeConfiguration" field)

• I adjusted the terraform's query original name "ECS Task Definition Volume Not Encrypted" to "EFS Volume With Disabled Transit Encryption". This way it will be easy to recognize the 2 queries from each platform as equivalent in the future.

• For the metadata of the queries there were changes made to better adjust various details to current implementation/context (cwe/documentation/severity).

• An initial implementation of the "ECS Cluster Not Encrypted At Rest" was commited , but it was decided the query required further research before moving on with the implementation(fallback commit). That said this initial implementation should be included in a "dangling" PR for future reference. (Draft PR)

Note: all test files from the "ECS Cluster Not Encrypted At Rest" query have been checked to be flagged identically by the adjusted EFS Volume query. The 2 instances that did not get flagged are the case of the TaskDefinition field referencing a resource that does not exist; those , however, did get correctly flagged as "Empty Roles For ECS Cluster Task Definitions" , this seems like the correct flag for this scenario and since the query naming/description of "ECS Cluster Not Encrypted At Rest" was unrelated to the issue to begin with, it seems to be a True Negative for the EFS Volume query.

• PS: After #7638 the case of "Volumes" missing entirely came to light with the QA process and was added to the implementation of "EFS Volume With Disabled Transit Encryption" accordingly along with new tests. With this the E2E tests (31/32/40) also had to be adjusted since they flag for both queries now.
  • Although my initial "ECS Cluster Not Encrypted At Rest" query proposal will not be implemented it was decided the recent changes done to it (#7563 and #7638) will be rolled back by this PR to lower amount of duplicate / False Positive Results given that the query will always flag unjustified no matter what. (will be rolled back to #7510)

I submit this contribution under the Apache-2.0 license.

[cx-artur-ribeiro]

LGTM

[gitguardian]

⚠️ GitGuardian has uncovered 3 secrets 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.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
19562607	Triggered	Generic Password	74da8c2	assets/queries/common/passwords_and_secrets/test/positive53.json	View secret
4266022	Triggered	Generic Password	6e9f38e	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/negative7.yaml	View secret
9419039	Triggered	Username Password	6e9f38e	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/positive6.json	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 secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
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.}

[cx-artur-ribeiro]

LGTM!
I don't know why we had a sample.yaml as a test file but nice revert from your side.