fix(queries): better interpreter for gcp queries

[cx-andre-pereira]

Closes #

Reason for Proposed Changes

• The current query implementations use a regex to determine whether a filter is valid or not. This was not the best approach, as the filter could not appear defined exactly as defined in the CIS_Google_Cloud_Platform_Foundation_Benchmark_v4.0.0.

Proposed Changes

• All the three queries, does the same verifications:

  • There is at least one"google_logging_metric" resource in the project and none contain the correct filter.
  • There is at least one "google_monitoring_alert_policy" resource in the project and none contain the filter/reference a logging metric that contains the correct filter.
  • There is at least one "google_monitoring_alert_policy" resource that contains the filter but none of them declare "notification_channels".

• The queries Beta - Logs And Alerts Missing Project Ownership Assignement And Changes and Beta - Logs And Alerts Missing Audit Configuration Changes are using a really similar approach each one to handle the filter field, taking into account the following filters present in the respective CIS Benchmark page:

  • Query Beta - Logs And Alerts Missing Project Ownershio Assignement And Changes
    
  • Query Beta - Logs And Alerts Missing Audit Configuration Changes:

    protoPayload.methodName="SetIamPolicy" AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
    

• Both of them have at the beginning of the query the patterns that the queries are covering. The filter field is analysed using the single_match helper function that firstly removes the white spaces from the filter and then lowers all the characters within. After that, the filter does the verification that is has to do using the is_valid_filter helper function.

• On the Beta - Logs And Alerts Missing Project Ownershio Assignement And Changes, this helper functions returns true if the service name is valid (defined to cloudresourcemanager.googleapis.com), if (ProjectOwnership OR projectOwnerInvitee), if (action="REMOVE" AND role="roles/owner") is present and if (action="ADD" AND role="roles/owner"). All these verifications take into account that the conditions can change places and the cases when a NOT is used in the filter.

• For the query Beta - Logs And Alerts Missing Audit Configuration Changes is more simple, as it firstly only checks if the following cases happen:

  • methodName defined to SetIamPolicy AND auditConfigDeltas="*"
  • auditConfigDeltas="*" AND methodName="SetIamPolicy"
  • Cases when the De Morgan law happen - NOT(NOT A OR NOT B) == A AND B.

• The query Beta - Logs And Alerts Missing Custom Role Changes took a different approach regarding the way it handles the filter field.

• It uses the single_match helper function that firstly processes the filter by splitting it into an array with each element beginning with AND or OR operations, and then it checks if the field filter uses an improper filter using the is_improper_filter helper function.

• This is_impproper_filter helper function firstly checks if the resource.type is not defined to iam.role using the correct_resource_type helper function, and then, if the resource type is correctly defined, it checks the other methodNames using the contains_method helper function.

• That contains_method helper function firstly checks if there are not NOT statements in the methodNames being tackled by this query, and then it gathers a list of methodNames in the filters and checks if all of the four methodNames(CreateRole, DeleteRole, UpdateRole and UndeleteRole) are defined.

• If all the method names aren't defined, it checks if a wildcard(protoPayload.nethodName="*") for the methodName is present in the filter.

I submit this contribution under the Apache-2.0 license.

[github-actions]

KICS version: v2.1.18

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-miguel-dasilva]

Since the 3 queries rely basically on the same logic to check the Log query, align them as much as possible to make them easier to maintain in the future. Add some function to rego libraries if you believe that can be achieved.

[cx-miguel-dasilva]

Great Work!