#TRUSTED 3253ee1aa3271fb4b0df011885b453ef06a255a89c597fb9adf287b232be3e8bfed367cd4d9ba24f122c59d2cce4bc03c277e20fd2adcbc736beef5721530a8384284fdc7cb28702cababf0b463401b6d9db8e0860bbe8922395e52cba4026645b306dbc60aff289765eb20eb63cd21c99fbe66d78c0c8ce21cd830d41a228784e64d42aa5f844b946ce58035c8d7b1934c3fc9710e5e8db1c146337ed1b3bfe4f3aaf47ab9172f3db54546710f2be51f156b1ab29b7f610a8ad83a6a6f92fc011464f8c4a4a9e4e5c2f3a8f1a4c7d79f973c65f31f17fd40fb77822d2f192bf8d7279d64027bb021f447b591e393e7a37ed871e309d1c02c7e2dd56ade5f4c49d5a301a9cf27780c5c98fdee1a6666271228eb9e27d37ae93e2c0cdbb33b659061bb3c18c48ec1720a80d7dbaf314fe41b97996d28d34cb5393d5feba474335b9eeefa0c37987f7a7c039575846d05a441e92c9a90ce9a88e44341b5fe3a20c0f157d73ec4e74f8e41a8963318acc8793df3bb3e1702aa8020676bebc4431d0bbbeefe621dff26d1951f0661b6f6cdfd64d8b4c4bc5ad073875b62ad760bb042260c4f8f64ac08e7120587bdf95ba9e08ea8c0ae8dcd4999aebbbef10b27d7f076016d579b42643bbfa8f1b336ef889efd8f059127dc7b8cd4b1cc15c78a80ea9dc7c89477f02ba9be0c0817fbeb4ce21bab35160a5a1be5af25c22fffcc5e3
#TRUST-RSA-SHA256 82b31364ddd53a008a04de074a0a1c352226140106e8f5e19d61a2d60a08c8ac79f0ae2c865404be4adfd02acb7752a68fa842cf71f9fd0245a2d882071f49182cbc0cc1adb7a14802b11807dd0982139a894144e2ac8f02260ae4763f52fbd9c8aa46862aaf31f2c7caaf05cab49b3cfdb7a71b360021abc6a33e9eb05ff40dbf2e519a2cd83cf913ad5b2e79b74c688ef90da739e74531bfb2d6fa0dd65ca5ffeb94f03bf8c632aacf6011392dc9338e5d5eb98ae849a26105c45df3ce250de757597caa000b49a54823ad76fae34e558b184be5e2751bdd1b05ed81354182efd936229575e9cd72b01e11ba532186508fa242e32c62bf60147b3b255359b5d58dbf5de26073ac8357daa3e438bfe66dcfa3c995b7d350095f0cac1732db0e88f9f5ae9b301460db576fb52b044171c9ed4fa4991850e4c25f526840f087976bc7df198543dba9f862b3bbc8b7827f930d8a1dc3b5108ca846f5ac8f27f25fc50b893aa09595fa7cf68840eed39a75237e783ef7c9eee607b405e6db7deac4afe4cdac50a75742fa5d660f58293394e1d166e584e39b6ee56b6f9204204d8e70676172ca334d952f0114a53030f118546802709d5ea51f2263444f279731ff285d6c20447aae053c2ab28e83d9a2ba159a0b2a7dc054520b3f4dd40d7ce3d5ce7f5e63026eeb0aaf8a23081278cff0763dfc4f8fbb5bf6ae4162841039b308
#
# This script is Copyright (C) 2004-2023 and is owned by Tenable, Inc. or an Affiliate thereof.
#
# This script is released under the Tenable Subscription License and
# may not be used from within scripts released under another license
# without authorization from Tenable, Inc.
#
# See the following licenses for details:
#
# http://static.tenable.com/prod_docs/Nessus_6_SLA_and_Subscription_Agreement.pdf
#
# @PROFESSIONALFEED@
# $Revision: 1.0 $
# $Date: 2023/01/04 $
#
# Description : This document implements the security configuration as recommended by the
#               CIS Google Cloud Platform Benchmark
#
#<ui_metadata>
#<display_name>CIS Google Cloud Platform v1.3.0 L1</display_name>
#<spec>
#  <type>CIS</type>
#  <name>Google Cloud Platform v1.3.0 L1</name>
#  <version>1.3.0</version>
#  <link>https://workbench.cisecurity.org/files/3817</link>
#</spec>
#<labels>gcp</labels>
#<benchmark_refs>CSCv6,CSCv7,CSCv8,LEVEL,CCE</benchmark_refs>
#<variables>
#  <variable>
#    <name>ORGANIZATION_DOMAIN</name>
#    <default>@myorganization.com</default>
#    <description>Organization Domain</description>
#    <info>Domain name of your organization.</info>
#    <value_type>STRING</value_type>
#  </variable>
#  <variable>
#    <name>POSTGRES_LOG_HOSTNAME</name>
#    <default>on</default>
#    <description>PostgreSQL flag log_hostname</description>
#    <info>Controls the logging of hostnames in addition to the IP addresses logged.</info>
#    <value_type>STRING</value_type>
#  </variable>
#  <variable>
#    <name>SQLSERVER_USER_CONNECTIONS</name>
#    <default>(null|[0-9]+)</default>
#    <description>SQL Server flag user connections</description>
#    <info>Specifies the maximum number of simultaneous user connections that are allowed on an instance of SQL Server.</info>
#    <value_type>STRING</value_type>
#  </variable>
#</variables>
#</ui_metadata>

<check_type:"GCP">

<custom_item>
  type           : REST_API
  description    : "1.1 Ensure that Corporate Login Credentials are Used"
  info           : "Use corporate login credentials instead of personal accounts, such as Gmail accounts.

Rationale:

It is recommended fully-managed corporate Google accounts be used for increased visibility, auditing, and controlling access to Cloud Platform resources. Email accounts based outside of the user's organization, such as personal accounts, should not be used for business purposes.

Impact:

There will be increased overhead as maintaining accounts will now be required. For smaller organizations, this will not be an issue, but will balloon with size."
  solution       : "Follow the documentation and setup corporate login accounts.
Prevention:
To ensure that no email addresses outside the organization can be granted IAM permissions to its Google Cloud projects, folders or organization, turn on the Organization Policy for Domain Restricted Sharing. Learn more at: https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains

Default Value:

By default, no email addresses outside the organization's domain have access to its Google Cloud deployments, but any user email account can be added to the IAM policy for Google Cloud Platform projects, folders, or organizations."
  reference      : "800-171|3.1.1,800-53|AC-2(1),CN-L3|7.1.3.2(d),CSCv7|16.2,CSCv8|5.6,CSF|PR.AC-1,CSF|PR.AC-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2(1),LEVEL|1M,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listProjectIAM"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.bindings[] | .role as $role | .members[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Role: \($role), Member: \(.)\""
  regex          : "Member: user:"
  expect         : "Member: user:.*@ORGANIZATION_DOMAIN@"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "1.2 Ensure that Multi-Factor Authentication is 'Enabled' for All Non-Service Accounts"
  info        : "Setup multi-factor authentication for Google Cloud Platform accounts.

Rationale:

Multi-factor authentication requires more than one mechanism to authenticate a user. This secures user logins from attackers exploiting stolen or weak credentials.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:
For each Google Cloud Platform project:

Identify non-service accounts.

Setup multi-factor authentication for each account.

Default Value:

By default, multi-factor authentication is not set."
  reference   : "800-171|3.5.3,800-53|IA-2(1),800-53|IA-2(2),CN-L3|7.1.2.7(b),CN-L3|7.1.3.1(a),CN-L3|7.1.3.1(e),CN-L3|8.1.4.1(a),CN-L3|8.1.4.2(a),CN-L3|8.5.4.1(a),CSCv7|16.3,CSCv8|6.3,CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-2(1),ITSG-33|IA-2(2),LEVEL|1M,NESA|T5.4.2,NIAv2|AM2,NIAv2|AM8,NIAv2|AM14b,NIAv2|AM36,NIAv2|VL3c,QCSC-v1|5.2.2,QCSC-v1|13.2,SWIFT-CSCv1|1.2,TBA-FIISB|35.1,TBA-FIISB|36.1"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "1.4 Ensure That There Are Only GCP-Managed Service Account Keys for Each Service Account"
  info           : "User managed service accounts should not have user-managed keys.

Rationale:

Anyone who has access to the keys will be able to access resources through the service account. GCP-managed keys are used by Cloud Platform services such as App Engine and Compute Engine. These keys cannot be downloaded. Google will keep the keys and automatically rotate them on an approximately weekly basis. User-managed keys are created, downloadable, and managed by users. They expire 10 years from creation.

For user-managed keys, the user has to take ownership of key management activities which include:

Key storage

Key distribution

Key revocation

Key rotation

Protecting the keys from unauthorized users

Key recovery

Even with key owner precautions, keys can be easily leaked by common development malpractices like checking keys into the source code or leaving them in the Downloads directory, or accidentally leaving them on support blogs/channels.

It is recommended to prevent user-managed service account keys.

Impact:

Deleting user-managed Service Account Keys may break communication with the applications using the corresponding keys."
  solution       : "From Console:

Go to the IAM page in the GCP Console using https://console.cloud.google.com/iam-admin/iam

In the left navigation pane, click Service accounts. All service accounts and their corresponding keys are listed.

Click the service account.

Click the edit and delete the keys.

From Command Line:
To delete a user managed Service Account Key,

gcloud iam service-accounts keys delete --iam-account=<user-managed-service-account-EMAIL> <KEY-ID>

Prevention:
You can disable service account key creation through the Disable service account key creation Organization policy by visiting https://console.cloud.google.com/iam-admin/orgpolicies/iam-disableServiceAccountKeyCreation. Learn more at: https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts
In addition, if you do not need to have service accounts in your project, you can also prevent the creation of service accounts through the Disable service account creation Organization policy: https://console.cloud.google.com/iam-admin/orgpolicies/iam-disableServiceAccountCreation.

Default Value:

By default, there are no user-managed keys created for user-managed service accounts."
  reference      : "800-171|3.5.2,800-53|IA-5,CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5,LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listIamServiceAccountKeys"
  json_transform : ".projects[].value.accounts[].value.keys[] | select(.keyType == \"USER_MANAGED\") | \"Type: \(.keyType), Name: \(.name)\""
  regex          : "Type: USER_MANAGED"
  not_expect     : "Name: .*\.iam\.gserviceaccount\.com/keys/"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "1.5 Ensure That Service Account Has No Admin Privileges"
  info           : "A service account is a special Google account that belongs to an application or a VM, instead of to an individual end-user. The application uses the service account to call the service's Google API so that users aren't directly involved. It's recommended not to use admin access for ServiceAccount.

Rationale:

Service accounts represent service-level security of the Resources (application or a VM) which can be determined by the roles assigned to it. Enrolling ServiceAccount with Admin rights gives full access to an assigned application or a VM. A ServiceAccount Access holder can perform critical actions like delete, update change settings, etc. without user intervention. For this reason, it's recommended that service accounts not have Admin rights.

Impact:

Removing *Admin or *adminorEditororOwner' role assignments from service accounts may break functionality that uses impacted service accounts. Required role(s) should be assigned to impacted service accounts in order to restore broken functionalities."
  solution       : "From Console:

Go to IAM & admin/IAM using https://console.cloud.google.com/iam-admin/iam

Go to the Members

Identify User-Managed user created service account with roles containing *Admin or *admin or role matching Editor or role matching Owner

Click the Delete bin icon to remove the role from the member (service account in this case)

From Command Line:
gcloud projects get-iam-policy PROJECT_ID --format json > iam.json

Using a text editor, Remove Role which contains roles/*Admin or roles/*admin or matched roles/editor or matches 'roles/owner'. Add a role to the bindings array that defines the group members and the role for those members.

For example, to grant the role roles/appengine.appViewer to the ServiceAccount which is roles/editor, you would change the example shown below as follows:

{
'bindings': [
{
   'members': [
     'serviceAccount:our-project-123@appspot.gserviceaccount.com',
    ],
    'role': 'roles/appengine.appViewer'
},
{
    'members': [
     'user:email1@gmail.com'
    ],
    'role': 'roles/owner'
   },
{
    'members': [
      'serviceAccount:our-project-123@appspot.gserviceaccount.com',
      'serviceAccount:123456789012-compute@developer.gserviceaccount.com'
    ],
    'role': 'roles/editor'
}
],
'etag': 'BwUjMhCsNvY='
}

Update the project's IAM policy:
gcloud projects set-iam-policy PROJECT_ID iam.json

Default Value:

User Managed (and not user-created) default service accounts have the Editor (roles/editor) role assigned to them to support GCP services they offer.

By default, there are no roles assigned to User Managed User created service accounts."
  reference      : "800-171|3.1.5,800-171|3.1.6,800-53|AC-6(2),800-53|AC-6(5),CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.10.6(a),CSCv7|4.3,CSCv8|5.4,CSF|PR.AC-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.3,ITSG-33|AC-6(2),ITSG-33|AC-6(5),LEVEL|1A,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.6.1,NIAv2|AM1,NIAv2|AM23f,NIAv2|AM32,NIAv2|AM33,NIAv2|SS13c,NIAv2|SS15c,NIAv2|VL3a,QCSC-v1|5.2.2,QCSC-v1|6.2,SWIFT-CSCv1|1.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listProjectIAM"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.bindings[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Member: \(.members[]), Role: \(.role)\""
  regex          : "Member: serviceAccount:.*\.iam\.gserviceaccount\.com"
  not_expect     : "Role: roles/.*(admin|editor|owner)"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "1.6 Ensure That IAM Users Are Not Assigned the Service Account User or Service Account Token Creator Roles at Project Level"
  info           : "It is recommended to assign the Service Account User (iam.serviceAccountUser) and Service Account Token Creator (iam.serviceAccountTokenCreator) roles to a user for a specific service account rather than assigning the role to a user at project level.

Rationale:

A service account is a special Google account that belongs to an application or a virtual machine (VM), instead of to an individual end-user. Application/VM-Instance uses the service account to call the service's Google API so that users aren't directly involved. In addition to being an identity, a service account is a resource that has IAM policies attached to it. These policies determine who can use the service account.

Users with IAM roles to update the App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts have access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance/Service account.

Based on business needs, there could be multiple user-managed service accounts configured for a project. Granting the iam.serviceAccountUser or iam.serviceAccountTokenCreator roles to a user for a project gives the user access to all service accounts in the project, including service accounts that may be created in the future. This can result in elevation of privileges by using service accounts and corresponding Compute Engine instances.

In order to implement least privileges best practices, IAM users should not be assigned the Service Account User or Service Account Token Creator roles at the project level. Instead, these roles should be assigned to a user for a specific service account, giving that user access to the service account. The Service Account User allows a user to bind a service account to a long-running job service, whereas the Service Account Token Creator role allows a user to directly impersonate (or assert) the identity of a service account.

Impact:

After revoking Service Account User or Service Account Token Creator roles at the project level from all impacted user account(s), these roles should be assigned to a user(s) for specific service account(s) according to business needs."
  solution       : "From Console:

Go to the IAM page in the GCP Console by visiting: https://console.cloud.google.com/iam-admin/iam.

Click on the filter table text bar. Type Role: Service Account User

Click the Delete Bin icon in front of the role Service Account User for every user listed as a result of a filter.

Click on the filter table text bar. Type Role: Service Account Token Creator

Click the Delete Bin icon in front of the role Service Account Token Creator for every user listed as a result of a filter.

From Command Line:

Using a text editor, remove the bindings with the roles/iam.serviceAccountUser or roles/iam.serviceAccountTokenCreator.

For example, you can use the iam.json file shown below as follows:

{
'bindings': [
{
   'members': [
     'serviceAccount:our-project-123@appspot.gserviceaccount.com',
    ],
    'role': 'roles/appengine.appViewer'
},
{
    'members': [
     'user:email1@gmail.com'
    ],
    'role': 'roles/owner'
   },
{
    'members': [
      'serviceAccount:our-project-123@appspot.gserviceaccount.com',
      'serviceAccount:123456789012-compute@developer.gserviceaccount.com'
    ],
    'role': 'roles/editor'
}
],
'etag': 'BwUjMhCsNvY='
    }

Update the project's IAM policy:

gcloud projects set-iam-policy PROJECT_ID iam.json

Default Value:

By default, users do not have the Service Account User or Service Account Token Creator role assigned at project level."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listProjectIAM"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.bindings[] | .role as $role | .members[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Role: \($role), Member: \(.)\""
  regex          : "Member: user"
  not_expect     : "Role: roles/iam.(serviceAccountUser|serviceAccountTokenCreator)"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "1.7 Ensure User-Managed/External Keys for Service Accounts Are Rotated Every 90 Days or Fewer"
  info           : "Service Account keys consist of a key ID (Private_key_Id) and Private key, which are used to sign programmatic requests users make to Google cloud services accessible to that particular service account. It is recommended that all Service Account keys are regularly rotated.

Rationale:

Rotating Service Account keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used. Service Account keys should be rotated to ensure that data cannot be accessed with an old key that might have been lost, cracked, or stolen.

Each service account is associated with a key pair managed by Google Cloud Platform (GCP). It is used for service-to-service authentication within GCP. Google rotates the keys daily.

GCP provides the option to create one or more user-managed (also called external key pairs) key pairs for use from outside GCP (for example, for use with Application Default Credentials). When a new key pair is created, the user is required to download the private key (which is not retained by Google). With external keys, users are responsible for keeping the private key secure and other management operations such as key rotation. External keys can be managed by the IAM API, gcloud command-line tool, or the Service Accounts page in the Google Cloud Platform Console. GCP facilitates up to 10 external service account keys per service account to facilitate key rotation.

Impact:

Rotating service account keys will break communication for dependent applications. Dependent applications need to be configured manually with the new key ID displayed in the Service account keys section and the private key downloaded by the user."
  solution       : "From Console:
Delete any external (user-managed) Service Account Key older than 90 days:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

In the Section Service Account Keys, for every external (user-managed) service account key where creation date is greater than or equal to the past 90 days, click Delete Bin Icon to Delete Service Account key

Create a new external (user-managed) Service Account Key for a Service Account:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

Click Create Credentials and Select Service Account Key.

Choose the service account in the drop-down list for which an External (user-managed) Service Account key needs to be created.

Select the desired key type format among JSON or P12.

Click Create. It will download the private key. Keep it safe.

Click Close if prompted.

The site will redirect to the APIs & Services\Credentials page. Make a note of the new ID displayed in the Service account keys section.

Default Value:

GCP does not provide an automation option for External (user-managed) Service key rotation."
  reference      : "800-171|3.5.2,800-53|IA-5f.,CN-L3|8.1.4.1(a),CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5f.,LEVEL|1A,NESA|T5.5.3,QCSC-v1|5.2.2,QCSC-v1|13.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listIamServiceAccountKeys"
  json_transform : ".projects[].value.accounts[].value.keys[] | select(.keyType == \"USER_MANAGED\") | \"Type: \(.keyType), Name: \(.name), Valid After Time: \(.validAfterTime), Valid After Days: \(.validAfterTime | iso_8601_days_ago)\""
  regex          : "Type: USER_MANAGED"
  not_expect     : "Valid After Days: (9[1-9]|[1-9][0-9]{2,})"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "1.9 Ensure That Cloud KMS Cryptokeys Are Not Anonymously or Publicly Accessible"
  info           : "It is recommended that the IAM policy on Cloud KMS cryptokeys should restrict anonymous and/or public access.

Rationale:

Granting permissions to allUsers or allAuthenticatedUsers allows anyone to access the dataset. Such access might not be desirable if sensitive data is stored at the location. In this case, ensure that anonymous and/or public access to a Cloud KMS cryptokey is not allowed.

Impact:

Removing the binding for allUsers and allAuthenticatedUsers members denies accessing cryptokeys to anonymous or public users."
  solution       : "From Command Line:

List all Cloud KMS Cryptokeys.

gcloud kms keys list --keyring=[key_ring_name] --location=global --format=json | jq '.[].name'

Remove IAM policy binding for a KMS key to remove access to allUsers and allAuthenticatedUsers using the below command.

gcloud kms keys remove-iam-policy-binding [key_name] --keyring=[key_ring_name] --location=global --member='allAuthenticatedUsers' --role='[role]'

gcloud kms keys remove-iam-policy-binding [key_name] --keyring=[key_ring_name] --location=global --member='allUsers' --role='[role]'

Default Value:

By default Cloud KMS does not allow access to allUsers or allAuthenticatedUsers."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "getKmsKeysIamPolicy"
  json_transform : ".projects[].value.locations[] | select(.value.keyRings != null) | .value.keyRings[].value.cryptoKeys[] | .name as $name | .value.bindings[] | \"Key: \($name), Member: \(.members[]), Role: \(.role)\""
  regex          : "Member: "
  not_expect     : "Member: (allUsers|allAuthenticatedUsers)"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "1.10 Ensure KMS Encryption Keys Are Rotated Within a Period of 90 Days"
  info           : "Google Cloud Key Management Service stores cryptographic keys in a hierarchical structure designed for useful and elegant access control management.

The format for the rotation schedule depends on the client library that is used. For the gcloud command-line tool, the next rotation time must be in ISO or RFC3339 format, and the rotation period must be in the form INTEGER[UNIT], where units can be one of seconds (s), minutes (m), hours (h) or days (d).

Rationale:

Set a key rotation period and starting time. A key can be created with a specified rotation period, which is the time between when new key versions are generated automatically. A key can also be created with a specified next rotation time. A key is a named object representing a cryptographic key used for a specific purpose. The key material, the actual bits used for encryption, can change over time as new key versions are created.

A key is used to protect some corpus of data. A collection of files could be encrypted with the same key and people with decrypt permissions on that key would be able to decrypt those files. Therefore, it's necessary to make sure the rotation period is set to a specific time.

Impact:

After a successful key rotation, the older key version is required in order to decrypt the data encrypted by that previous key version."
  solution       : "From Console:

Go to Cryptographic Keys by visiting: https://console.cloud.google.com/security/kms.

Click on the specific key ring

From the list of keys, choose the specific key and Click on Right side pop up the blade (3 dots).

Click on Edit rotation period.

On the pop-up window, Select a new rotation period in days which should be less than 90 and then choose Starting on date (date from which the rotation period begins).

From Command Line:

Update and schedule rotation by ROTATION_PERIOD and NEXT_ROTATION_TIME for each key:

gcloud kms keys update new --keyring=KEY_RING --location=LOCATION --next-rotation-time=NEXT_ROTATION_TIME --rotation-period=ROTATION_PERIOD

Default Value:

By default, KMS encryption keys are rotated every 90 days."
  reference      : "800-171|3.5.2,800-171|3.13.16,800-53|IA-5(1),800-53|SC-28,800-53|SC-28(1),CN-L3|8.1.4.7(b),CN-L3|8.1.4.8(b),CSCv7|14.8,CSCv8|3.11,CSF|PR.AC-1,CSF|PR.DS-1,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(a)(2)(iv),HIPAA|164.312(d),HIPAA|164.312(e)(2)(ii),ITSG-33|IA-5(1),ITSG-33|SC-28,ITSG-33|SC-28(1),ITSG-33|SC-28a.,LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1,TBA-FIISB|28.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "getKmsKeys"
  json_transform : ".projects[].value.locations[] | select(.value.keyRings != null) | .value.keyRings[].value.cryptoKeys[] | \"Key: \(.name), Rotation Period: \(.rotationPeriod)\""
  regex          : "Rotation Period:"
  expect         : "Rotation Period: (([1-9][0-9]{0,4}|1[0-1][0-9]{4}|12[0-8][0-9]{3}|129[0-5][0-9]{2}|129600)m|([1-9][0-9]{0,5}|[1-6][0-9]{6}|7[0-6][0-9]{5}||77[0-6][0-9]{4}|777[0-5][0-9]{3}|7776000)s|([1-9][0-9]{0,2}|[1-2][0-9][0-9][0-9]|2[0-1][0-9][0-9]|21[0-5][0-9]|2160)h|([1-8][0-9]?|90)d)"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "1.13 Ensure API Keys Are Restricted To Use by Only Specified Hosts and Apps"
  info        : "Unrestricted keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. It is recommended to restrict API key usage to trusted hosts, HTTP referrers and apps.

Rationale:

Security risks involved in using API-Keys appear below:

API keys are simple encrypted strings

API keys do not identify the user or the application making the API request

API keys are typically accessible to clients, making it easy to discover and steal an API key

In light of these potential risks, Google recommends using the standard authentication flow instead of API keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API.

In order to reduce attack vectors, API-Keys can be restricted only to trusted hosts, HTTP referrers and applications.

Impact:

Setting Application Restrictions may break existing application functioning, if not done carefully.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

In the section API Keys, Click the API Key Name. The API Key properties display on a new page.

In the Key restrictions section, set the application restrictions to any of HTTP referrers, IP addresses, Android apps, iOS apps.

Click Save.

Repeat steps 2,3,4 for every unrestricted API key.
Note: Do not set HTTP referrers to wild-cards (* or *.[TLD] or .[TLD]/) allowing access to any/wide HTTP referrer(s)
Do not set IP addresses and referrer to any host (0.0.0.0 or 0.0.0.0/0 or ::0)

Default Value:

By default, Application Restrictions are set to None."
  reference   : "800-171|3.1.1,800-53|AC-2,CN-L3|7.1.3.2(d),CSCv7|16,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2,LEVEL|1M,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<report type:"WARNING">
  description : "1.14 Ensure API Keys Are Restricted to Only APIs That Application Needs Access"
  info        : "API keys are always at risk because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. It is recommended to restrict API keys to use (call) only APIs required by an application.

Rationale:

Security risks involved in using API-Keys are below:

API keys are simple encrypted strings

API keys do not identify the user or the application making the API request

API keys are typically accessible to clients, making it easy to discover and steal an API key

In light of these potential risks, Google recommends using the standard authentication flow instead of API-Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API.

In order to reduce attack surfaces by providing least privileges, API-Keys can be restricted to use (call) only APIs required by an application.

Impact:

Setting API restrictions may break existing application functioning, if not done carefully.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

In the section API Keys, Click the API Key Name. The API Key properties display on a new page.

In the Key restrictions section go to API restrictions.

Click the Select API drop-down to choose an API.

Click Save.

Repeat steps 2,3,4,5 for every unrestricted API key

Note: Do not set API restrictions to Google Cloud APIs, as this option allows access to all services offered by Google cloud.

Default Value:

By default, API restrictions are set to None."
  reference   : "800-171|3.1.1,800-53|AC-2,CN-L3|7.1.3.2(d),CSCv7|16,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2,LEVEL|1M,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<report type:"WARNING">
  description : "1.15 Ensure API Keys Are Rotated Every 90 Days"
  info        : "It is recommended to rotate API keys every 90 days.

Rationale:

Security risks involved in using API-Keys are listed below:

API keys are simple encrypted strings

API keys do not identify the user or the application making the API request

API keys are typically accessible to clients, making it easy to discover and steal an API key

Because of these potential risks, Google recommends using the standard authentication flow instead of API Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API.

Once a key is stolen, it has no expiration, meaning it may be used indefinitely unless the project owner revokes or regenerates the key. Rotating API keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used.

API keys should be rotated to ensure that data cannot be accessed with an old key that might have been lost, cracked, or stolen.

Impact:

Regenerating Key may break existing client connectivity as the client will try to connect with older API keys they have stored on devices.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:

Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials

In the section API Keys, Click the API Key Name. The API Key properties display on a new page.

Click REGENERATE KEY to rotate API key.

Click Save.

Repeat steps 2,3,4 for every API key that has not been rotated in the last 90 days.

Note: Do not set HTTP referrers to wild-cards (* or *.[TLD] or .[TLD]/) allowing access to any/wide HTTP referrer(s)
Do not set IP addresses and referrer to any host (0.0.0.0 or 0.0.0.0/0 or ::0)"
  reference   : "800-171|3.1.1,800-53|AC-2,CN-L3|7.1.3.2(d),CSCv7|16,CSF|DE.CM-1,CSF|DE.CM-3,CSF|PR.AC-1,CSF|PR.AC-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ITSG-33|AC-2,LEVEL|1M,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "1.16 Ensure Essential Contacts is Configured for Organization"
  info           : "It is recommended that Essential Contacts is configured to designate email addresses for Google Cloud services to notify of important technical or security information.

Rationale:

Many Google Cloud services, such as Cloud Billing, send out notifications to share important information with Google Cloud users. By default, these notifications are sent to members with certain Identity and Access Management (IAM) roles. With Essential Contacts, you can customize who receives notifications by providing your own list of contacts.

Impact:

There is no charge for Essential Contacts.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:

Go to Essential Contacts by visiting https://console.cloud.google.com/iam-admin/essential-contacts

Make sure the organization appears in the resource selector at the top of the page. The resource selector tells you what project, folder, or organization you are currently managing contacts for.

Click +Add contact

In the Email and Confirm Email fields, enter the email address of the contact.

From the Notification categories drop-down menu, select the notification categories that you want the contact to receive communications for.

Click Save

From Command Line:

To add an organization Essential Contacts run a command:

gcloud essential-contacts create --email='<EMAIL>' \
  --notification-categories='<NOTIFICATION_CATEGORIES>' \
  --organization=<ORGANIZATION_ID>

Default Value:

By default, there are no Essential Contacts configured.

In the absence of an Essential Contact, the following IAM roles are used to identify users to notify for the following categories:

Legal: roles/billing.admin

Security: roles/resourcemanager.organizationAdmin

Suspension: roles/owner

Technical: roles/owner

Technical Incidents: roles/owner"
  reference      : "800-171|3.6.1,800-171|3.6.2,800-53|IR-6,800-53|IR-6(3),CSCv7|19.5,CSCv8|17.2,CSF|RS.CO-2,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ITSG-33|IR-6,LEVEL|1A,NESA|M1.3.3,QCSC-v1|10.2.1,QCSC-v1|11.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listEssentialContacts"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.contacts[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Email: \(.email), Notification Category Subscriptions: \(.notificationCategorySubscriptions)\""
  regex          : "Email:"
  expect         : "Email: MANUAL_REVIEW"
  severity       : MEDIUM
</custom_item>

<report type:"WARNING">
  description : "1.18 Ensure Secrets are Not Stored in Cloud Functions Environment Variables by Using Secret Manager"
  info        : "Google Cloud Functions allow you to host serverless code that is executed when an event is triggered, without the requiring the management a host operating system. These functions can also store environment variables to be used by the code that may contain authentication or other information that needs to remain confidential.

Rationale:

It is recommended to use the Secret Manager, because environment variables are stored unencrypted, and accessible for all users who have access to the code.

Impact:

There should be no impact on the Cloud Function. There are minor costs after 10,000 requests a month to the Secret Manager API as well for a high use of other functions. Modifying the Cloud Function to use the Secret Manager may prevent it running to completion as its environment variables are

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "Enable Secret Manager API for your Project
From Console

Within the project you wish to enable, select the Navigation hamburger menu in the top left. Hover over 'APIs & Services' to under the heading 'Serverless', then select 'Enabled APIs & Services' in the menu that opens up.

Click the button '+ Enable APIS and Services'

In the Search bar, search for 'Secret Manager API' and select it.

Click the blue box that says 'Enable'.

From Command Line

Within the project you wish to enable the API in, run the following command.

gcloud services enable Secret Manager API

Reviewing Environment Variables That Should Be Migrated to Secret Manager
From Console

Log in to the Google Cloud Web Portal (https://console.cloud.google.com/)

Go to Cloud Functions

Click on a function name from the list

Click on Edit and review the Runtime environment for variables that should be secrets. Leave this list open for the next step.

From Command Line

To view a list of your cloud functions run

cloud functions list

For each cloud function run the following command.

gcloud functions describe <function_name>

Review the settings of the buildEnvironmentVariables and environmentVariables. Keep this information for the next step.

Migrating Environment Variables to Secrets within the Secret Manager
From Console

Go to the Secret Manager page in the Cloud Console.

On the Secret Manager page, click Create Secret.

On the Create secret page, under Name, enter the name of the Environment Variable you are replacing. This will then be the Secret Variable you will reference in your code.

You will also need to add a version. This is the actual value of the variable that will be referenced from the code. To add a secret version when creating the initial secret, in the Secret value field, enter the value from the Environment Variable you are replacing.

Leave the Regions section unchanged.

Click the Create secret button.

Repeat for all Environment Variables

From Command Line

Run the following command with the Environment Variable name you are replacing in the <secret-id>. It is most secure to point this command to a file with the Environment Variable value located in it, as if you entered it via command line it would show up in your shell's command history.

gcloud secrets create <secret-id> --data-file='/path/to/file.txt'

Granting your Runtime's Service Account Access to Secrets
From Console

Within the project containing your runtime login with account that has the 'roles/secretmanager.secretAccessor' permission.

Select the Navigation hamburger menu in the top left. Hover over 'Security' to under the then select 'Secret Manager' in the menu that opens up.

Click the name of a secret listed in this screen.

If it is not already open, click Show Info Panel in this screen to open the panel.
5.In the info panel, click Add principal.
6.In the New principals field, enter the service account your function uses for its identity. (If you need help locating or updating your runtime's service account, please see the 'docs/securing/function-identity#runtime_service_account' reference.)

In the Select a role dropdown, choose Secret Manager and then Secret Manager Secret Accessor.

From Command Line
As of the time of writing, using Google CLI to list Runtime variables is only in beta. Because this is likely to change we are not including it here.
Modifying the Code to use the Secrets in Secret Manager
From Console
This depends heavily on which language your runtime is in. For the sake of the brevity of this recommendation, please see the '/docs/creating-and-accessing-secrets#access' reference
for language specific instructions.
From Command Line
This depends heavily on which language your runtime is in. For the sake of the brevity of this recommendation, please see the' /docs/creating-and-accessing-secrets#access' reference
for language specific instructions.
Deleting the Insecure Environment Variables
Be certain to do this step last. Removing variables from code actively referencing them will prevent it from completing successfully.
From Console

Select the Navigation hamburger menu in the top left. Hover over 'Security' then select 'Secret Manager' in the menu that opens up.

Click the name of a function. Click Edit.

Click Runtime, build and connections settings to expand the advanced configuration options.

Click 'Security'. Hover over the secret you want to remove, then click 'Delete'.

Click Next. Click Deploy. The latest version of the runtime will now reference the secrets in Secret Manager.

From Command Line

gcloud functions deploy <Function name>--remove-env-vars <env vars>

If you need to find the env vars to remove, they are from the step where 'gcloud functions describe <function_name>' was run.

Default Value:

By default Secret Manager is not enabled."
  reference   : "800-171|3.5.2,800-171|3.13.16,800-53|IA-5(1),800-53|SC-28,800-53|SC-28(1),CN-L3|8.1.4.7(b),CN-L3|8.1.4.8(b),CSCv7|14.8,CSCv7|16.4,CSCv8|3.11,CSF|PR.AC-1,CSF|PR.DS-1,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(a)(2)(iv),HIPAA|164.312(d),HIPAA|164.312(e)(2)(ii),ITSG-33|IA-5(1),ITSG-33|SC-28,ITSG-33|SC-28(1),ITSG-33|SC-28a.,LEVEL|1M,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|4.1,TBA-FIISB|28.1"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "2.1 Ensure That Cloud Audit Logging Is Configured Properly Across All Services and All Users From a Project - allServices"
  info           : "It is recommended that Cloud Audit Logging is configured to track all admin activities and read, write access to user data.

Rationale:

Cloud Audit Logging maintains two audit logs for each project, folder, and organization: Admin Activity and Data Access.

Admin Activity logs contain log entries for API calls or other administrative actions that modify the configuration or metadata of resources. Admin Activity audit logs are enabled for all services and cannot be configured.

Data Access audit logs record API calls that create, modify, or read user-provided data. These are disabled by default and should be enabled.

There are three kinds of Data Access audit log information:

Admin read: Records operations that read metadata or configuration information. Admin Activity audit logs record writes of metadata and configuration information that cannot be disabled.

Data read: Records operations that read user-provided data.

Data write: Records operations that write user-provided data.

It is recommended to have an effective default audit config configured in such a way that:

logtype is set to DATA_READ (to log user activity tracking) and DATA_WRITES (to log changes/tampering to user data).

audit config is enabled for all the services supported by the Data Access audit logs feature.

Logs should be captured for all users, i.e., there are no exempted users in any of the audit config sections. This will ensure overriding the audit config will not contradict the requirement.

Impact:

There is no charge for Admin Activity audit logs. Enabling the Data Access audit logs might result in your project being charged for the additional logs usage."
  solution       : "From Console:

Go to Audit Logs by visiting https://console.cloud.google.com/iam-admin/audit.

Follow the steps at https://cloud.google.com/logging/docs/audit/configure-data-access to enable audit logs for all Google Cloud services. Ensure that no exemptions are allowed.

From Command Line:

To read the project's IAM policy and store it in a file run a command:

gcloud projects get-iam-policy PROJECT_ID > /tmp/project_policy.yaml

Alternatively, the policy can be set at the organization or folder level. If setting the policy at the organization level, it is not necessary to also set it for each folder or project.

gcloud organizations get-iam-policy ORGANIZATION_ID > /tmp/org_policy.yaml
gcloud resource-manager folders get-iam-policy FOLDER_ID > /tmp/folder_policy.yaml

Edit policy in /tmp/policy.yaml, adding or changing only the audit logs configuration to:
Note: Admin Activity Logs are enabled by default, and cannot be disabled. So they are not listed in these configuration changes.

auditConfigs:
- auditLogConfigs:
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices

Note: exemptedMembers: is not set as audit logging should be enabled for all the users

To write new IAM policy run command:

gcloud organizations set-iam-policy ORGANIZATION_ID /tmp/org_policy.yaml
gcloud resource-manager folders set-iam-policy FOLDER_ID /tmp/folder_policy.yaml
gcloud projects set-iam-policy PROJECT_ID /tmp/project_policy.yaml

If the preceding command reports a conflict with another change, then repeat these steps, starting with the first step.

Default Value:

Admin Activity logs are always enabled. They cannot be disabled. Data Access audit logs are disabled by default because they can be quite large."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-6,800-53|AU-6(1),800-53|AU-7,800-53|AU-7(1),800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv7|6.7,CSCv8|8.2,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7,ITSG-33|AU-7(1),ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.2.5,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listProjectIAM"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | if (.value.auditConfigs | length) > 0 then .value.auditConfigs[] else {\"service\": \"allServices\"} end | \"Project Number: \($projectNumber), Project ID: \($projectId), Service: \(.service), Log Types: \(.auditLogConfigs | map(.logType) | sort | join(\",\"))\""
  regex          : "Service: allServices"
  expect         : "Log Types: ADMIN_READ,DATA_READ,DATA_WRITE"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.1 Ensure That Cloud Audit Logging Is Configured Properly Across All Services and All Users From a Project - exemptedMembers"
  info           : "It is recommended that Cloud Audit Logging is configured to track all admin activities and read, write access to user data.

Rationale:

Cloud Audit Logging maintains two audit logs for each project, folder, and organization: Admin Activity and Data Access.

Admin Activity logs contain log entries for API calls or other administrative actions that modify the configuration or metadata of resources. Admin Activity audit logs are enabled for all services and cannot be configured.

Data Access audit logs record API calls that create, modify, or read user-provided data. These are disabled by default and should be enabled.

There are three kinds of Data Access audit log information:

Admin read: Records operations that read metadata or configuration information. Admin Activity audit logs record writes of metadata and configuration information that cannot be disabled.

Data read: Records operations that read user-provided data.

Data write: Records operations that write user-provided data.

It is recommended to have an effective default audit config configured in such a way that:

logtype is set to DATA_READ (to log user activity tracking) and DATA_WRITES (to log changes/tampering to user data).

audit config is enabled for all the services supported by the Data Access audit logs feature.

Logs should be captured for all users, i.e., there are no exempted users in any of the audit config sections. This will ensure overriding the audit config will not contradict the requirement.

Impact:

There is no charge for Admin Activity audit logs. Enabling the Data Access audit logs might result in your project being charged for the additional logs usage."
  solution       : "From Console:

Go to Audit Logs by visiting https://console.cloud.google.com/iam-admin/audit.

Follow the steps at https://cloud.google.com/logging/docs/audit/configure-data-access to enable audit logs for all Google Cloud services. Ensure that no exemptions are allowed.

From Command Line:

To read the project's IAM policy and store it in a file run a command:

gcloud projects get-iam-policy PROJECT_ID > /tmp/project_policy.yaml

Alternatively, the policy can be set at the organization or folder level. If setting the policy at the organization level, it is not necessary to also set it for each folder or project.

gcloud organizations get-iam-policy ORGANIZATION_ID > /tmp/org_policy.yaml
gcloud resource-manager folders get-iam-policy FOLDER_ID > /tmp/folder_policy.yaml

Edit policy in /tmp/policy.yaml, adding or changing only the audit logs configuration to:
Note: Admin Activity Logs are enabled by default, and cannot be disabled. So they are not listed in these configuration changes.

auditConfigs:
- auditLogConfigs:
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices

Note: exemptedMembers: is not set as audit logging should be enabled for all the users

To write new IAM policy run command:

gcloud organizations set-iam-policy ORGANIZATION_ID /tmp/org_policy.yaml
gcloud resource-manager folders set-iam-policy FOLDER_ID /tmp/folder_policy.yaml
gcloud projects set-iam-policy PROJECT_ID /tmp/project_policy.yaml

If the preceding command reports a conflict with another change, then repeat these steps, starting with the first step.

Default Value:

Admin Activity logs are always enabled. They cannot be disabled. Data Access audit logs are disabled by default because they can be quite large."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-6,800-53|AU-6(1),800-53|AU-7,800-53|AU-7(1),800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv7|6.7,CSCv8|8.2,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7,ITSG-33|AU-7(1),ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.2.5,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listProjectIAM"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.auditConfigs[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Service: \(.service), Audit Log Configs: \(.auditLogConfigs[])\""
  regex          : "exemptedMembers"
  not_expect     : "exemptedMembers"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.2 Ensure That Sinks Are Configured for All Log Entries"
  info           : "It is recommended to create a sink that will export copies of all the log entries. This can help aggregate logs from multiple projects and export them to a Security Information and Event Management (SIEM).

Rationale:

Log entries are held in Cloud Logging. To aggregate logs, export them to a SIEM. To keep them longer, it is recommended to set up a log sink. Exporting involves writing a filter that selects the log entries to export, and choosing a destination in Cloud Storage, BigQuery, or Cloud Pub/Sub. The filter and destination are held in an object called a sink. To ensure all log entries are exported to sinks, ensure that there is no filter configured for a sink. Sinks can be created in projects, organizations, folders, and billing accounts.

Impact:

There are no costs or limitations in Cloud Logging for exporting logs, but the export destinations charge for storing or transmitting the log data."
  solution       : "From Console:

Go to Logs Router by visiting https://console.cloud.google.com/logs/router.

Click on the arrow symbol with CREATE SINK text.

Fill out the fields for Sink details.

Choose Cloud Logging bucket in the Select sink destination drop down menu.

Choose a log bucket in the next drop down menu.

If an inclusion filter is not provided for this sink, all ingested logs will be routed to the destination provided above. This may result in higher than expected resource usage.

Click Create Sink.

For more information, see https://cloud.google.com/logging/docs/export/configure_export_v2#dest-create.
From Command Line:
To create a sink to export all log entries in a Google Cloud Storage bucket:

gcloud logging sinks create <sink-name> storage.googleapis.com/DESTINATION_BUCKET_NAME

Sinks can be created for a folder or organization, which will include all projects.

gcloud logging sinks create <sink-name> storage.googleapis.com/DESTINATION_BUCKET_NAME --include-children --folder=FOLDER_ID | --organization=ORGANIZATION_ID

Note:

A sink created by the command-line above will export logs in storage buckets. However, sinks can be configured to export logs into BigQuery, or Cloud Pub/Sub, or Custom Destination.

While creating a sink, the sink option --log-filter is not used to ensure the sink exports all log entries.

A sink can be created at a folder or organization level that collects the logs of all the projects underneath bypassing the option --include-children in the gcloud command.

Default Value:

By default, there are no sinks configured."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-4,800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv7|6.4,CSCv8|8.2,CSCv8|8.3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.DS-4,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-4,ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.3.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingSinks"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Sinks: \([.value.sinks[] | {name, filter}])\""
  expect         : "\"filter\":null"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.4 Ensure Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes - metric"
  info           : "In order to prevent unnecessary project ownership assignments to users/service-accounts and further misuses of projects and resources, all roles/Owner assignments should be monitored.

Members (users/Service-Accounts) with a role assignment to primitive role roles/Owner are project owners.

The project owner has all the privileges on the project the role belongs to. These are summarized below:

- All viewer permissions on all GCP Services within the project

- Permissions for actions that modify the state of all GCP services within the project

- Manage roles and permissions for a project and all resources within the project

- Set up billing for a project

Granting the owner role to a member (user/Service-Account) will allow that member to modify the Identity and Access Management (IAM) policy. Therefore, grant the owner role only if the member has a legitimate purpose to manage the IAM policy. This is because the project IAM policy contains sensitive access control data. Having a minimal set of users allowed to manage IAM policy will simplify any auditing that may be necessary.

Rationale:

Project ownership has the highest level of privileges on a project. To avoid misuse of project resources, the project ownership assignment/change actions mentioned above should be monitored and alerted to concerned recipients.

- Sending project ownership invites

- Acceptance/Rejection of project ownership invite by user

- Adding 'role\Owner' to a user/service-account

- Removing a user/Service account from 'role\Owner'

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

(protoPayload.serviceName='cloudresourcemanager.googleapis.com')
AND (ProjectOwnership OR projectOwnerInvitee)
OR (protoPayload.serviceData.policyDelta.bindingDeltas.action='REMOVE'
AND protoPayload.serviceData.policyDelta.bindingDeltas.role='roles/owner')
OR (protoPayload.serviceData.policyDelta.bindingDeltas.action='ADD'
AND protoPayload.serviceData.policyDelta.bindingDeltas.role='roles/owner')

Click Submit Filter. The logs display based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and the Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create the display prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the desired metric and select Create alert from Metric. A new page opens.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create a prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for Command Usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create prescribed Alert Policy

Use the command: gcloud alpha monitoring policies create

Reference for Command Usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv8|8.2,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"\(protoPayload\.serviceName[\s]*=[\s]*\\\"cloudresourcemanager\.googleapis\.com\\\"\).*AND.*\(ProjectOwnership.*OR.*projectOwnerInvitee\).*OR.*\(protoPayload\.serviceData\.policyDelta\.bindingDeltas\.action[\s]*=[\s]*\\\"REMOVE\\\".*AND.*protoPayload\.serviceData\.policyDelta\.bindingDeltas\.role[\s]*=[\s]*\\\"roles/owner\\\"\).*OR.*\(protoPayload\.serviceData\.policyDelta\.bindingDeltas\.action[\s]*=[\s]*\\\"ADD\\\".*AND.*protoPayload\.serviceData\.policyDelta\.bindingDeltas\.role[\s]*=[\s]*\\\"roles/owner\\\"\)\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.4 Ensure Log Metric Filter and Alerts Exist for Project Ownership Assignments/Changes - alert"
  info           : "In order to prevent unnecessary project ownership assignments to users/service-accounts and further misuses of projects and resources, all roles/Owner assignments should be monitored.

Members (users/Service-Accounts) with a role assignment to primitive role roles/Owner are project owners.

The project owner has all the privileges on the project the role belongs to. These are summarized below:

- All viewer permissions on all GCP Services within the project

- Permissions for actions that modify the state of all GCP services within the project

- Manage roles and permissions for a project and all resources within the project

- Set up billing for a project

Granting the owner role to a member (user/Service-Account) will allow that member to modify the Identity and Access Management (IAM) policy. Therefore, grant the owner role only if the member has a legitimate purpose to manage the IAM policy. This is because the project IAM policy contains sensitive access control data. Having a minimal set of users allowed to manage IAM policy will simplify any auditing that may be necessary.

Rationale:

Project ownership has the highest level of privileges on a project. To avoid misuse of project resources, the project ownership assignment/change actions mentioned above should be monitored and alerted to concerned recipients.

- Sending project ownership invites

- Acceptance/Rejection of project ownership invite by user

- Adding 'role\Owner' to a user/service-account

- Removing a user/Service account from 'role\Owner'

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

(protoPayload.serviceName='cloudresourcemanager.googleapis.com')
AND (ProjectOwnership OR projectOwnerInvitee)
OR (protoPayload.serviceData.policyDelta.bindingDeltas.action='REMOVE'
AND protoPayload.serviceData.policyDelta.bindingDeltas.role='roles/owner')
OR (protoPayload.serviceData.policyDelta.bindingDeltas.action='ADD'
AND protoPayload.serviceData.policyDelta.bindingDeltas.role='roles/owner')

Click Submit Filter. The logs display based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and the Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create the display prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the desired metric and select Create alert from Metric. A new page opens.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create a prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for Command Usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create prescribed Alert Policy

Use the command: gcloud alpha monitoring policies create

Reference for Command Usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv8|8.2,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.5 Ensure That the Log Metric Filter and Alerts Exist for Audit Configuration Changes - metric"
  info           : "Google Cloud Platform (GCP) services write audit log entries to the Admin Activity and Data Access logs to help answer the questions of, 'who did what, where, and when?' within GCP projects.

Cloud audit logging records information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by GCP services. Cloud audit logging provides a history of GCP API calls for an account, including API calls made via the console, SDKs, command-line tools, and other GCP services.

Rationale:

Admin activity and data access logs produced by cloud audit logging enable security analysis, resource change tracking, and compliance auditing.

Configuring the metric filter and alerts for audit configuration changes ensures the recommended state of audit configuration is maintained so that all activities in the project are audit-able at any point in time.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

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

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This will ensure that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create a prescribed Alert Policy:

Identify the new metric the user just created, under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page opens.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create a prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create prescribed Alert Policy

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"protoPayload\.methodName[\s]*=[\s]*\\\"SetIamPolicy\\\".*AND.*protoPayload\.serviceData\.policyDelta\.auditConfigDeltas:\*\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.5 Ensure That the Log Metric Filter and Alerts Exist for Audit Configuration Changes - alert"
  info           : "Google Cloud Platform (GCP) services write audit log entries to the Admin Activity and Data Access logs to help answer the questions of, 'who did what, where, and when?' within GCP projects.

Cloud audit logging records information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by GCP services. Cloud audit logging provides a history of GCP API calls for an account, including API calls made via the console, SDKs, command-line tools, and other GCP services.

Rationale:

Admin activity and data access logs produced by cloud audit logging enable security analysis, resource change tracking, and compliance auditing.

Configuring the metric filter and alerts for audit configuration changes ensures the recommended state of audit configuration is maintained so that all activities in the project are audit-able at any point in time.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

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

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This will ensure that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create a prescribed Alert Policy:

Identify the new metric the user just created, under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page opens.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create a prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create prescribed Alert Policy

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.6 Ensure That the Log Metric Filter and Alerts Exist for Custom Role Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for changes to Identity and Access Management (IAM) role creation, deletion and updating activities.

Rationale:

Google Cloud IAM provides predefined roles that give granular access to specific Google Cloud Platform resources and prevent unwanted access to other resources. However, to cater to organization-specific needs, Cloud IAM also provides the ability to create custom roles. Project owners and administrators with the Organization Role Administrator role or the IAM Role Administrator role can create custom roles. Monitoring role creation, deletion and updating activities will help in identifying any over-privileged role at early stages.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type='iam_role'
AND protoPayload.methodName =  'google.iam.admin.v1.CreateRole'
OR protoPayload.methodName='google.iam.admin.v1.DeleteRole'
OR protoPayload.methodName='google.iam.admin.v1.UpdateRole'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create a prescribed Alert Policy:

Identify the new metric that was just created under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed Alert Policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"resource.type[\s]*=[\s]*\\\"iam_role\\\".*AND.*protoPayload\.methodName[\s]*=[\s]*\\\"google\.iam\.admin\.v1\.CreateRole\\\".*OR.*protoPayload\.methodName=\\\"google\.iam\.admin\.v1\.DeleteRole\\\".*OR.*protoPayload\.methodName[\s]*=[\s]*\\\"google\.iam\.admin\.v1\.UpdateRole\\\"\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.6 Ensure That the Log Metric Filter and Alerts Exist for Custom Role Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for changes to Identity and Access Management (IAM) role creation, deletion and updating activities.

Rationale:

Google Cloud IAM provides predefined roles that give granular access to specific Google Cloud Platform resources and prevent unwanted access to other resources. However, to cater to organization-specific needs, Cloud IAM also provides the ability to create custom roles. Project owners and administrators with the Organization Role Administrator role or the IAM Role Administrator role can create custom roles. Monitoring role creation, deletion and updating activities will help in identifying any over-privileged role at early stages.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type='iam_role'
AND protoPayload.methodName =  'google.iam.admin.v1.CreateRole'
OR protoPayload.methodName='google.iam.admin.v1.DeleteRole'
OR protoPayload.methodName='google.iam.admin.v1.UpdateRole'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create a prescribed Alert Policy:

Identify the new metric that was just created under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed Alert Policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.7 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) Network Firewall rule changes.

Rationale:

Monitoring for Create or Update Firewall rule events gives insight to network access changes and may reduce the time it takes to detect suspicious activity.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type='gce_firewall_rule'
AND protoPayload.methodName:'compute.firewalls.patch'
OR protoPayload.methodName:'compute.firewalls.insert'
OR protoPayload.methodName:'compute.firewalls.delete'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create the prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"resource\.type[\s]*=[\s]*\\\"gce_firewall_rule\\\".*AND.*protoPayload\.methodName:\\\"compute\.firewalls\.patch\\\".*OR.*protoPayload\.methodName:\\\"compute\.firewalls\.insert\\\".*OR.*protoPayload\.methodName:\\\"compute\.firewalls\.delete\\\".*\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.7 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Firewall Rule Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) Network Firewall rule changes.

Rationale:

Monitoring for Create or Update Firewall rule events gives insight to network access changes and may reduce the time it takes to detect suspicious activity.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type='gce_firewall_rule'
AND protoPayload.methodName:'compute.firewalls.patch'
OR protoPayload.methodName:'compute.firewalls.insert'
OR protoPayload.methodName:'compute.firewalls.delete'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the advanced logs query.

Click Create Metric.

Create the prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.8 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Route Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) network route changes.

Rationale:

Google Cloud Platform (GCP) routes define the paths network traffic takes from a VM instance to another destination. The other destination can be inside the organization VPC network (such as another VM) or outside of it. Every route consists of a destination and a next hop. Traffic whose destination IP is within the destination range is sent to the next hop for delivery.

Monitoring changes to route tables will help ensure that all VPC traffic flows through an expected path.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed Log Metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter

Clear any text and add:

resource.type='gce_route'
AND (protoPayload.methodName:'compute.routes.delete'
OR protoPayload.methodName:'compute.routes.insert'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed the alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"resource\.type=\\\"gce_route\\\".*AND.*protoPayload\.methodName:\\\"compute\.routes\.delete\\\".*OR.*protoPayload\.methodName:\\\"compute\.routes\.insert\\\".*\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.8 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Route Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) network route changes.

Rationale:

Google Cloud Platform (GCP) routes define the paths network traffic takes from a VM instance to another destination. The other destination can be inside the organization VPC network (such as another VM) or outside of it. Every route consists of a destination and a next hop. Traffic whose destination IP is within the destination range is sent to the next hop for delivery.

Monitoring changes to route tables will help ensure that all VPC traffic flows through an expected path.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed Log Metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter

Clear any text and add:

resource.type='gce_route'
AND (protoPayload.methodName:'compute.routes.delete'
OR protoPayload.methodName:'compute.routes.insert'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page displays.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value ensures that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed the alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.9 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) network changes.

Rationale:

It is possible to have more than one VPC within a project. In addition, it is also possible to create a peer connection between two VPCs enabling network traffic to route between VPCs.

Monitoring changes to a VPC will help ensure VPC traffic flow is not getting impacted.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type=gce_network
AND (protoPayload.methodName:'compute.networks.insert'
OR protoPayload.methodName:'compute.networks.patch'
OR protoPayload.methodName:'compute.networks.delete'
OR protoPayload.methodName:'compute.networks.removePeering'
OR protoPayload.methodName:'compute.networks.addPeering')

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of 0 for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"resource\.type=gce_network.*AND.*protoPayload\.methodName:\\\"compute\.networks\.insert\\\".*OR.*protoPayload\.methodName:\\\"compute\.networks\.patch\\\".*OR.*protoPayload\.methodName:\\\"compute\.networks\.delete\\\".*OR.*protoPayload\.methodName:\\\"compute\.networks\.removePeering\\\".*OR.*protoPayload\.methodName:\\\"compute\.networks\.addPeering\\\".*\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.9 Ensure That the Log Metric Filter and Alerts Exist for VPC Network Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for Virtual Private Cloud (VPC) network changes.

Rationale:

It is possible to have more than one VPC within a project. In addition, it is also possible to create a peer connection between two VPCs enabling network traffic to route between VPCs.

Monitoring changes to a VPC will help ensure VPC traffic flow is not getting impacted.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type=gce_network
AND (protoPayload.methodName:'compute.networks.insert'
OR protoPayload.methodName:'compute.networks.patch'
OR protoPayload.methodName:'compute.networks.delete'
OR protoPayload.methodName:'compute.networks.removePeering'
OR protoPayload.methodName:'compute.networks.addPeering')

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on the right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of 0 for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.10 Ensure That the Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for Cloud Storage Bucket IAM changes.

Rationale:

Monitoring changes to cloud storage bucket permissions may reduce the time needed to detect and correct permissions on sensitive cloud storage buckets and objects inside the bucket.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type=gcs_bucket
AND protoPayload.methodName='storage.setIamPermissions'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"resource\.type[\s]*=[\s]*gcs_bucket.*AND.*protoPayload\.methodName[\s]*=[\s]*\\\"storage\.setIamPermissions\\\"\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.10 Ensure That the Log Metric Filter and Alerts Exist for Cloud Storage IAM Permission Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for Cloud Storage Bucket IAM changes.

Rationale:

Monitoring changes to cloud storage bucket permissions may reduce the time needed to detect and correct permissions on sensitive cloud storage buckets and objects inside the bucket.

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed log metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

resource.type=gcs_bucket
AND protoPayload.methodName='storage.setIamPermissions'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed Alert Policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notifications channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed Log Metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.11 Ensure That the Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes - metric"
  info           : "It is recommended that a metric filter and alarm be established for SQL instance configuration changes.

Rationale:

Monitoring changes to SQL instance configuration changes may reduce the time needed to detect and correct misconfigurations done on the SQL server.

Below are a few of the configurable options which may the impact security posture of an SQL instance:

Enable auto backups and high availability: Misconfiguration may adversely impact business continuity, disaster recovery, and high availability

Authorize networks: Misconfiguration may increase exposure to untrusted networks

Impact:

Enabling of logging may result in your project being charged for the additional logs usage."
  solution       : "From Console:
Create the prescribed Log Metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

protoPayload.methodName='cloudsql.instances.update'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the user's project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed log metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listLoggingMetrics"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Metrics: \([.value.metrics[] | {name, filter}])\""
  expect         : "\"filter\":\"protoPayload\.methodName[\s]*=[\s]*\\\"cloudsql\.instances\.update\\\"\""
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.11 Ensure That the Log Metric Filter and Alerts Exist for SQL Instance Configuration Changes - alert"
  info           : "It is recommended that a metric filter and alarm be established for SQL instance configuration changes.

Rationale:

Monitoring changes to SQL instance configuration changes may reduce the time needed to detect and correct misconfigurations done on the SQL server.

Below are a few of the configurable options which may the impact security posture of an SQL instance:

Enable auto backups and high availability: Misconfiguration may adversely impact business continuity, disaster recovery, and high availability

Authorize networks: Misconfiguration may increase exposure to untrusted networks

Impact:

Enabling of logging may result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:
Create the prescribed Log Metric:

Go to Logging/Logs-based Metrics by visiting https://console.cloud.google.com/logs/metrics and click 'CREATE METRIC'.

Click the down arrow symbol on the Filter Bar at the rightmost corner and select Convert to Advanced Filter.

Clear any text and add:

protoPayload.methodName='cloudsql.instances.update'

Click Submit Filter. Display logs appear based on the filter text entered by the user.

In the Metric Editor menu on right, fill out the name field. Set Units to 1 (default) and Type to Counter. This ensures that the log metric counts the number of log entries matching the user's advanced logs query.

Click Create Metric.

Create the prescribed alert policy:

Identify the newly created metric under the section User-defined Metrics at https://console.cloud.google.com/logs/metrics.

Click the 3-dot icon in the rightmost column for the new metric and select Create alert from Metric. A new page appears.

Fill out the alert policy configuration and click Save. Choose the alerting threshold and configuration that makes sense for the user's organization. For example, a threshold of zero(0) for the most recent value will ensure that a notification is triggered for every owner change in the user's project:

Set 'Aggregator' to 'Count'

Set 'Configuration':

- Condition: above

- Threshold: 0

- For: most recent value

Configure the desired notification channels in the section Notifications.

Name the policy and click Save.

From Command Line:
Create the prescribed log metric:

Use the command: gcloud beta logging metrics create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/beta/logging/metrics/create

Create the prescribed alert policy:

Use the command: gcloud alpha monitoring policies create

Reference for command usage: https://cloud.google.com/sdk/gcloud/reference/alpha/monitoring/policies/create"
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listAlertPolicies"
  json_transform : ".projects[] | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Alert Policies: \([.value.alertPolicies[] | select(.enabled == true) | .conditions[] | {name, \"filter\": .conditionThreshold.filter}])\""
  expect         : "\"filter\":\"metric\.type=\\\"logging\.googleapis\.com/user/"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.12 Ensure That Cloud DNS Logging Is Enabled for All VPC Networks - vpc networks"
  info           : "Cloud DNS logging records the queries from the name servers within your VPC to Stackdriver. Logged queries can come from Compute Engine VMs, GKE containers, or other GCP resources provisioned within the VPC.

Rationale:

Security monitoring and forensics cannot depend solely on IP addresses from VPC flow logs, especially when considering the dynamic IP usage of cloud resources, HTTP virtual host routing, and other technology that can obscure the DNS name used by a client from the IP address. Monitoring of Cloud DNS logs provides visibility to DNS names requested by the clients within the VPC. These logs can be monitored for anomalous domain names, evaluated against threat intelligence, and

Note: For full capture of DNS, firewall must block egress UDP/53 (DNS) and TCP/443 (DNS over HTTPS) to prevent client from using external DNS name server for resolution.

Impact:

Enabling of Cloud DNS logging might result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Command Line:
Add New DNS Policy With Logging Enabled
For each VPC network that needs a DNS policy with logging enabled:

gcloud dns policies create enable-dns-logging --enable-logging --description='Enable DNS Logging' --networks=VPC_NETWORK_NAME

The VPC_NETWORK_NAME can be one or more networks in comma-separated list
Enable Logging for Existing DNS Policy
For each VPC network that has an existing DNS policy that needs logging enabled:

gcloud dns policies update POLICY_NAME --enable-logging --networks=VPC_NETWORK_NAME

The VPC_NETWORK_NAME can be one or more networks in comma-separated list

Default Value:

Cloud DNS logging is disabled by default on each network."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-6,800-53|AU-6(1),800-53|AU-7,800-53|AU-7(1),800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv7|6.7,CSCv7|8.7,CSCv8|8.2,CSCv8|8.6,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7,ITSG-33|AU-7(1),ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.2.5,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeNetworks"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.items[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Network: \(.selfLink)\""
  expect         : "MANUAL REVIEW REQUIRED"
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.12 Ensure That Cloud DNS Logging Is Enabled for All VPC Networks - dns policies"
  info           : "Cloud DNS logging records the queries from the name servers within your VPC to Stackdriver. Logged queries can come from Compute Engine VMs, GKE containers, or other GCP resources provisioned within the VPC.

Rationale:

Security monitoring and forensics cannot depend solely on IP addresses from VPC flow logs, especially when considering the dynamic IP usage of cloud resources, HTTP virtual host routing, and other technology that can obscure the DNS name used by a client from the IP address. Monitoring of Cloud DNS logs provides visibility to DNS names requested by the clients within the VPC. These logs can be monitored for anomalous domain names, evaluated against threat intelligence, and

Note: For full capture of DNS, firewall must block egress UDP/53 (DNS) and TCP/443 (DNS over HTTPS) to prevent client from using external DNS name server for resolution.

Impact:

Enabling of Cloud DNS logging might result in your project being charged for the additional logs usage.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Command Line:
Add New DNS Policy With Logging Enabled
For each VPC network that needs a DNS policy with logging enabled:

gcloud dns policies create enable-dns-logging --enable-logging --description='Enable DNS Logging' --networks=VPC_NETWORK_NAME

The VPC_NETWORK_NAME can be one or more networks in comma-separated list
Enable Logging for Existing DNS Policy
For each VPC network that has an existing DNS policy that needs logging enabled:

gcloud dns policies update POLICY_NAME --enable-logging --networks=VPC_NETWORK_NAME

The VPC_NETWORK_NAME can be one or more networks in comma-separated list

Default Value:

Cloud DNS logging is disabled by default on each network."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-6,800-53|AU-6(1),800-53|AU-7,800-53|AU-7(1),800-53|AU-12,CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(d),CN-L3|8.1.4.3(a),CSCv7|6.2,CSCv7|6.7,CSCv7|8.7,CSCv8|8.2,CSCv8|8.6,CSCv8|8.11,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-6,ITSG-33|AU-6(1),ITSG-33|AU-7,ITSG-33|AU-7(1),ITSG-33|AU-12,LEVEL|1A,NESA|M1.2.2,NESA|M5.2.5,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listDnsPolicies"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.policies[] | .name as $policy | .enableLogging as $enableLogging | .networks[] | \"Project Number: \($projectNumber), Project ID: \($projectId), Policy: \($policy), Enable Logging: \($enableLogging), Network: \(.networkUrl)\""
  regex          : "Enable Logging: true"
  expect         : "MANUAL REVIEW REQUIRED"
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "2.13 Ensure Cloud Asset Inventory Is Enabled"
  info           : "GCP Cloud Asset Inventory is services that provides a historical view of GCP resources and IAM policies through a time-series database. The information recorded includes metadata on Google Cloud resources, metadata on policies set on Google Cloud projects or resources, and runtime information gathered within a Google Cloud resource.

Rationale:

The GCP resources and IAM policies captured by GCP Cloud Asset Inventory enables security analysis, resource change tracking, and compliance auditing.

Impact:

It is recommended GCP Cloud Asset Inventory be enabled for all GCP projects."
  solution       : "From Console:
Enable the Cloud Asset API:

Go to API & Services/Library by visiting https://console.cloud.google.com/apis/library

Search for Cloud Asset API and select the result for Cloud Asset API

Click the ENABLE button.

From Command Line:
Enable the Cloud Asset API:

Enable the Cloud Asset API through the services interface:

gcloud services enable cloudasset.googleapis.com

Default Value:

The Cloud Asset Inventory API is disabled by default in each project."
  reference      : "800-171|3.4.1,800-53|CM-8,800-53|CM-8(1),800-53|PM-5,CN-L3|8.1.10.2(a),CN-L3|8.1.10.2(b),CSCv7|1.4,CSCv7|11.2,CSCv7|16.1,CSCv8|1.1,CSCv8|6.6,CSF|DE.CM-7,CSF|ID.AM-1,CSF|ID.AM-2,CSF|PR.DS-3,GDPR|32.1.b,GDPR|32.1.d,HIPAA|164.306(a)(1),ITSG-33|CM-8,ITSG-33|CM-8(1),LEVEL|1A,LEVEL|2A,NESA|T1.2.1,NESA|T1.2.2,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listServices"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.services[] | select(.config.name == \"cloudasset.googleapis.com\") | \"Project Number: \($projectNumber), Project ID: \($projectId), Service Name: \(.config.name), State: \(.state)\""
  regex          : "State"
  expect         : "State: ENABLED"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "2.14 Ensure 'Access Transparency' is 'Enabled'"
  info        : "GCP Access Transparency provides audit logs for all actions that Google personnel take in your Google Cloud resources.

Rationale:

Controlling access to your information is one of the foundations of information security. Given that Google Employees do have access to your organizations' projects for support reasons, you should have logging in place to view who, when, and why your information is being accessed.

Impact:

To use Access Transparency your organization will need to have at one of the following support level: Premium, Enterprise, Platinum, or Gold. There will be subscription costs associated with support, as well as increased storage costs for storing the logs. You will also not be able to turn Access Transparency off yourself, and you will need to submit a service request to Google Cloud Support.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "Add privileges to enable Access Transparency

From the Google Cloud Home, within the project you wish to check, click on the Navigation hamburger menu in the top left. Hover over the 'IAM and Admin'. Select IAM in the top of the column that opens.

Click the blue button the says +add at the top of the screen.

In the principals field, select a user or group by typing in their associated email address.

Click on the role field to expand it. In the filter field enter Access Transparency Admin and select it.

Click save.

Verify that the Google Cloud project is associated with a billing account

From the Google Cloud Home, click on the Navigation hamburger menu in the top left. Select Billing.

If you see This project is not associated with a billing account you will need to enter billing information or switch to a project with a billing account.

Enable Access Transparency

From the Google Cloud Home, click on the Navigation hamburger menu in the top left. Hover over the IAM & Admin Menu. Select settings in the middle of the column that opens.

Click the blue button labeled Enable Access Transparency for Organization

Default Value:

By default Access Transparency is not enabled."
  reference   : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-2,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(a),CN-L3|8.1.4.3(b),CSCv7|6.2,CSCv7|6.3,CSCv8|8.2,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1M,NESA|M1.2.2,NESA|M5.5.1,NESA|T3.6.2,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "3.2 Ensure Legacy Networks Do Not Exist for Older Projects"
  info           : "In order to prevent use of legacy networks, a project should not have a legacy network configured. As of now, Legacy Networks are gradually being phased out, and you can no longer create projects with them. This recommendation is to check older projects to ensure that they are not using Legacy Networks.

Rationale:

Legacy networks have a single network IPv4 prefix range and a single gateway IP address for the whole network. The network is global in scope and spans all cloud regions. Subnetworks cannot be created in a legacy network and are unable to switch from legacy to auto or custom subnet networks. Legacy networks can have an impact for high network traffic projects and are subject to a single point of contention or failure.

Impact:

None."
  solution       : "For each Google Cloud Platform project,

Follow the documentation and create a non-legacy network suitable for the organization's requirements.

Follow the documentation and delete the networks in the legacy mode.

Default Value:

By default, networks are not created in the legacy mode."
  reference      : "800-171|3.1.16,800-171|3.1.17,800-171|3.4.1,800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|AC-18,800-53|AC-18(1),800-53|AC-18(3),800-53|CM-2,800-53|CM-6,800-53|CM-7,800-53|CM-7(1),800-53|CM-9,CSCv7|11.1,CSCv8|4.2,CSF|DE.AE-1,CSF|PR.DS-7,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ITSG-33|AC-18,ITSG-33|AC-18(1),ITSG-33|AC-18(3),ITSG-33|CM-2,ITSG-33|CM-6,ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|CM-9,LEVEL|1A,NESA|T1.2.1,NESA|T1.2.2,NESA|T3.2.5,NESA|T5.4.2,NESA|T7.5.1,NESA|T7.5.3,NESA|T7.6.1,NESA|T7.6.2,NESA|T7.6.3,NIAv2|NS33,NIAv2|NS34,NIAv2|NS38,NIAv2|SS15a,NIAv2|SS16,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeNetworks"
  json_transform : ".projects[].value.items[] | \"Network: \(.selfLink), IPv4 Range: \(.IPv4Range)\""
  regex          : "IPv4 Range"
  expect         : "IPv4 Range: null"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "3.3 Ensure That DNSSEC Is Enabled for Cloud DNS"
  info           : "Cloud Domain Name System (DNS) is a fast, reliable and cost-effective domain name system that powers millions of domains on the internet. Domain Name System Security Extensions (DNSSEC) in Cloud DNS enables domain owners to take easy steps to protect their domains against DNS hijacking and man-in-the-middle and other attacks.

Rationale:

Domain Name System Security Extensions (DNSSEC) adds security to the DNS protocol by enabling DNS responses to be validated. Having a trustworthy DNS that translates a domain name like www.example.com into its associated IP address is an increasingly important building block of today's web-based applications. Attackers can hijack this process of domain/IP lookup and redirect users to a malicious site through DNS hijacking and man-in-the-middle attacks. DNSSEC helps mitigate the risk of such attacks by cryptographically signing DNS records. As a result, it prevents attackers from issuing fake DNS responses that may misdirect browsers to nefarious websites."
  solution       : "From Console:

Go to Cloud DNS by visiting https://console.cloud.google.com/net-services/dns/zones.

For each zone of Type Public, set DNSSEC to On.

From Command Line:
Use the below command to enable DNSSEC for Cloud DNS Zone Name.

gcloud dns managed-zones update ZONE_NAME --dnssec-state on

Default Value:

By default DNSSEC is not enabled."
  reference      : "800-171|3.1.16,800-171|3.1.17,800-171|3.4.1,800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|AC-18,800-53|AC-18(1),800-53|AC-18(3),800-53|CM-2,800-53|CM-6,800-53|CM-7,800-53|CM-7(1),800-53|CM-9,CSCv7|11.1,CSCv8|4.2,CSF|DE.AE-1,CSF|PR.DS-7,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ITSG-33|AC-18,ITSG-33|AC-18(1),ITSG-33|AC-18(3),ITSG-33|CM-2,ITSG-33|CM-6,ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|CM-9,LEVEL|1A,NESA|T1.2.1,NESA|T1.2.2,NESA|T3.2.5,NESA|T5.4.2,NESA|T7.5.1,NESA|T7.5.3,NESA|T7.6.1,NESA|T7.6.2,NESA|T7.6.3,NIAv2|NS33,NIAv2|NS34,NIAv2|NS38,NIAv2|SS15a,NIAv2|SS16,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listDnsManagedZones"
  json_transform : ".projects[] | .projectNumber as $projectNumber | .projectId as $projectId | .value.managedZones[] | select(.visibility == \"public\") | \"Project Number: \($projectNumber), Project ID: \($projectId), DNS Name: \(.dnsName), DNSSEC: \(.dnssecConfig.state)\""
  regex          : "DNSSEC:"
  expect         : "DNSSEC: on"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "3.4 Ensure That RSASHA1 Is Not Used for the Key-Signing Key in Cloud DNS DNSSEC"
  info        : "NOTE: Currently, the SHA1 algorithm has been removed from general use by Google, and, if being used, needs to be whitelisted on a project basis by Google and will also, therefore, require a Google Cloud support contract.

DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms. The algorithm used for key signing should be a recommended one and it should be strong.

Rationale:

Domain Name System Security Extensions (DNSSEC) algorithm numbers in this registry may be used in CERT RRs. Zonesigning (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.

The algorithm used for key signing should be a recommended one and it should be strong. When enabling DNSSEC for a managed zone, or creating a managed zone with DNSSEC, the user can select the DNSSEC signing algorithms and the denial-of-existence type. Changing the DNSSEC settings is only effective for a managed zone if DNSSEC is not already enabled. If there is a need to change the settings for a managed zone where it has been enabled, turn DNSSEC off and then re-enable it with different settings.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "If it is necessary to change the settings for a managed zone where it has been enabled, NSSEC must be turned off and re-enabled with different settings. To turn off DNSSEC, run the following command:

gcloud dns managed-zones update ZONE_NAME --dnssec-state off

To update key-signing for a reported managed DNS Zone, run the following command:

gcloud dns managed-zones update ZONE_NAME --dnssec-state on --ksk-algorithm KSK_ALGORITHM --ksk-key-length KSK_KEY_LENGTH --zsk-algorithm ZSK_ALGORITHM --zsk-key-length ZSK_KEY_LENGTH --denial-of-existence DENIAL_OF_EXISTENCE

Supported algorithm options and key lengths are as follows.

Algorithm                        KSK Length               ZSK Length
---------                        ----------               ----------
RSASHA1                          1024,2048                1024,2048
RSASHA256                        1024,2048                1024,2048
RSASHA512                        1024,2048                1024,2048
ECDSAP256SHA256                  256                      256
ECDSAP384SHA384                  384                      384"
  reference   : "800-171|3.1.16,800-171|3.1.17,800-171|3.4.1,800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|AC-18,800-53|AC-18(1),800-53|AC-18(3),800-53|CM-2,800-53|CM-6,800-53|CM-7,800-53|CM-7(1),800-53|CM-9,CSCv7|11.1,CSCv8|4.2,CSF|DE.AE-1,CSF|PR.DS-7,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ITSG-33|AC-18,ITSG-33|AC-18(1),ITSG-33|AC-18(3),ITSG-33|CM-2,ITSG-33|CM-6,ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|CM-9,LEVEL|1M,NESA|T1.2.1,NESA|T1.2.2,NESA|T3.2.5,NESA|T5.4.2,NESA|T7.5.1,NESA|T7.5.3,NESA|T7.6.1,NESA|T7.6.2,NESA|T7.6.3,NIAv2|NS33,NIAv2|NS34,NIAv2|NS38,NIAv2|SS15a,NIAv2|SS16,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,SWIFT-CSCv1|2.3"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<report type:"WARNING">
  description : "3.5 Ensure That RSASHA1 Is Not Used for the Zone-Signing Key in Cloud DNS DNSSEC"
  info        : "NOTE: Currently, the SHA1 algorithm has been removed from general use by Google, and, if being used, needs to be whitelisted on a project basis by Google and will also, therefore, require a Google Cloud support contract.

DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms. The algorithm used for key signing should be a recommended one and it should be strong.

Rationale:

DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.

The algorithm used for key signing should be a recommended one and it should be strong. When enabling DNSSEC for a managed zone, or creating a managed zone with DNSSEC, the DNSSEC signing algorithms and the denial-of-existence type can be selected. Changing the DNSSEC settings is only effective for a managed zone if DNSSEC is not already enabled. If the need exists to change the settings for a managed zone where it has been enabled, turn DNSSEC off and then re-enable it with different settings.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "If the need exists to change the settings for a managed zone where it has been enabled, DNSSEC must be turned off and then re-enabled with different settings. To turn off DNSSEC, run following command:

gcloud dns managed-zones update ZONE_NAME --dnssec-state off

To update zone-signing for a reported managed DNS Zone, run the following command:

gcloud dns managed-zones update ZONE_NAME --dnssec-state on --ksk-algorithm KSK_ALGORITHM --ksk-key-length KSK_KEY_LENGTH --zsk-algorithm ZSK_ALGORITHM --zsk-key-length ZSK_KEY_LENGTH --denial-of-existence DENIAL_OF_EXISTENCE

Supported algorithm options and key lengths are as follows.

Algorithm                 KSK Length            ZSK Length
---------                 ----------            ----------
RSASHA1                   1024,2048             1024,2048
RSASHA256                 1024,2048             1024,2048
RSASHA512                 1024,2048             1024,2048
ECDSAP256SHA256           256                   384
ECDSAP384SHA384           384                   384"
  reference   : "800-171|3.1.16,800-171|3.1.17,800-171|3.4.1,800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|AC-18,800-53|AC-18(1),800-53|AC-18(3),800-53|CM-2,800-53|CM-6,800-53|CM-7,800-53|CM-7(1),800-53|CM-9,CSCv7|11.1,CSCv8|4.2,CSF|DE.AE-1,CSF|PR.DS-7,CSF|PR.IP-1,CSF|PR.PT-3,CSF|PR.PT-4,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ITSG-33|AC-18,ITSG-33|AC-18(1),ITSG-33|AC-18(3),ITSG-33|CM-2,ITSG-33|CM-6,ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|CM-9,LEVEL|1M,NESA|T1.2.1,NESA|T1.2.2,NESA|T3.2.5,NESA|T5.4.2,NESA|T7.5.1,NESA|T7.5.3,NESA|T7.6.1,NESA|T7.6.2,NESA|T7.6.3,NIAv2|NS33,NIAv2|NS34,NIAv2|NS38,NIAv2|SS15a,NIAv2|SS16,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,SWIFT-CSCv1|2.3"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "3.8 Ensure that VPC Flow Logs is Enabled for Every Subnet in a VPC Network"
  info           : "Flow Logs is a feature that enables users to capture information about the IP traffic going to and from network interfaces in the organization's VPC Subnets. Once a flow log is created, the user can view and retrieve its data in Stackdriver Logging. It is recommended that Flow Logs be enabled for every business-critical VPC subnet.

Rationale:

VPC networks and subnetworks not reserved for internal HTTP(S) load balancing provide logically isolated and secure network partitions where GCP resources can be launched. When Flow Logs are enabled for a subnet, VMs within that subnet start reporting on all Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) flows. Each VM samples the TCP and UDP flows it sees, inbound and outbound, whether the flow is to or from another VM, a host in the on-premises datacenter, a Google service, or a host on the Internet. If two GCP VMs are communicating, and both are in subnets that have VPC Flow Logs enabled, both VMs report the flows.

Flow Logs supports the following use cases:

Network monitoring

Understanding network usage and optimizing network traffic expenses

Network forensics

Real-time security analysis

Flow Logs provide visibility into network traffic for each VM inside the subnet and can be used to detect anomalous traffic or provide insight during security workflows.

The Flow Logs must be configured such that all network traffic is logged, the interval of logging is granular to provide detailed information on the connections, no logs are filtered, and metadata to facilitate investigations are included.

Note: Subnets reserved for use by internal HTTP(S) load balancers do not support VPC flow logs.

Impact:

Standard pricing for Stackdriver Logging, BigQuery, or Cloud Pub/Sub applies. VPC Flow Logs generation will be charged starting in GA as described in reference: https://cloud.google.com/vpc/"
  solution       : "From Console:

Go to the VPC network GCP Console visiting https://console.cloud.google.com/networking/networks/list

Click the name of a subnet, The Subnet details page displays.

Click the EDIT button.

Set Flow Logs to On.

Expand the Configure Logs section.

Set Aggregation Interval to 5 SEC.

Check the box beside Include metadata.

Set Sample rate to 100.

Click Save.

Note: It is not possible to configure a Log filter from the console.
From Command Line:
To enable VPC Flow Logs for a network subnet, run the following command:

gcloud compute networks subnets update [SUBNET_NAME] --region [REGION] --enable-flow-logs --logging-aggregation-interval=interval-5-sec --logging-flow-sampling=1 --logging-metadata=include-all

Default Value:

By default, Flow Logs is set to Off when a new VPC network subnet is created."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-171|3.14.6,800-171|3.14.7,800-53|AU-2,800-53|AU-7,800-53|AU-12,800-53|SI-4,800-53|SI-4(4),CN-L3|7.1.2.2(c),CN-L3|7.1.2.3(c),CN-L3|7.1.3.5(a),CN-L3|8.1.4.3(a),CN-L3|8.1.10.5(b),CN-L3|8.1.10.6(f),CSCv7|6.2,CSCv7|12.8,CSCv8|8.2,CSCv8|13.6,CSF|DE.AE-1,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.AE-4,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-5,CSF|DE.CM-6,CSF|DE.CM-7,CSF|DE.DP-2,CSF|DE.DP-3,CSF|DE.DP-4,CSF|DE.DP-5,CSF|ID.RA-1,CSF|PR.DS-5,CSF|PR.IP-8,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-2,ITSG-33|AU-7,ITSG-33|AU-12,ITSG-33|SI-4,ITSG-33|SI-4(4),LEVEL|1A,NESA|M1.2.2,NESA|M5.5.1,NIAv2|AM7,NIAv2|AM11a,NIAv2|AM11b,NIAv2|AM11c,NIAv2|AM11d,NIAv2|AM11e,NIAv2|NS32,NIAv2|SS30,NIAv2|VL8,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4,SWIFT-CSCv1|6.5"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeSubnetworks"
  json_transform : ".projects[].value.items[].subnetworks[] | \"Subnet: \(.selfLink), Enable Flow Logs: \(.enableFlowLogs), Aggregation Interval: \(.logConfig.aggregationInterval), Include Metadata: \(.logConfig.metadata), Sample Rate: \(.logConfig.flowSampling)\""
  regex          : "Enable Flow Logs:"
  expect         : "Enable Flow Logs: true, Aggregation Interval: INTERVAL_5_SEC, Include Metadata: INCLUDE_ALL_METADATA, Sample Rate: 1"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "3.9 Ensure No HTTPS or SSL Proxy Load Balancers Permit SSL Policies With Weak Cipher Suites"
  info        : "Secure Sockets Layer (SSL) policies determine what port Transport Layer Security (TLS) features clients are permitted to use when connecting to load balancers. To prevent usage of insecure features, SSL policies should use (a) at least TLS 1.2 with the MODERN profile; or (b) the RESTRICTED profile, because it effectively requires clients to use TLS 1.2 regardless of the chosen minimum TLS version; or (3) a CUSTOM profile that does not support any of the following features:

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Rationale:

Load balancers are used to efficiently distribute traffic across multiple servers. Both SSL proxy and HTTPS load balancers are external load balancers, meaning they distribute traffic from the Internet to a GCP network. GCP customers can configure load balancer SSL policies with a minimum TLS version (1.0, 1.1, or 1.2) that clients can use to establish a connection, along with a profile (Compatible, Modern, Restricted, or Custom) that specifies permissible cipher suites. To comply with users using outdated protocols, GCP load balancers can be configured to permit insecure cipher suites. In fact, the GCP default SSL policy uses a minimum TLS version of 1.0 and a Compatible profile, which allows the widest range of insecure cipher suites. As a result, it is easy for customers to configure a load balancer without even knowing that they are permitting outdated cipher suites.

Impact:

Creating more secure SSL policies can prevent clients using older TLS versions from establishing a connection.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:
If the TargetSSLProxy or TargetHttpsProxy does not have an SSL policy configured, create a new SSL policy. Otherwise, modify the existing insecure policy.

Navigate to the SSL Policies page by visiting: https://console.cloud.google.com/net-security/sslpolicies

Click on the name of the insecure policy to go to its SSL policy details page.

Click EDIT.

Set Minimum TLS version to TLS 1.2.

Set Profile to Modern or Restricted.

Alternatively, if teh user selects the profile Custom, make sure that the following features are disabled:

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

From Command Line:

For each insecure SSL policy, update it to use secure cyphers:

gcloud compute ssl-policies update NAME [--profile COMPATIBLE|MODERN|RESTRICTED|CUSTOM] --min-tls-version 1.2 [--custom-features FEATURES]

If the target proxy has a GCP default SSL policy, use the following command corresponding to the proxy type to update it.

gcloud compute target-ssl-proxies update TARGET_SSL_PROXY_NAME --ssl-policy SSL_POLICY_NAME
gcloud compute target-https-proxies update TARGET_HTTPS_POLICY_NAME --ssl-policy SSL_POLICY_NAME

Default Value:

The GCP default SSL policy is the least secure setting: Min TLS 1.0 and Compatible profile"
  reference   : "800-171|3.1.13,800-171|3.5.2,800-171|3.13.8,800-53|AC-17(2),800-53|IA-5,800-53|IA-5(1),800-53|SC-8,800-53|SC-8(1),CN-L3|7.1.2.7(g),CN-L3|7.1.3.1(d),CN-L3|8.1.2.2(a),CN-L3|8.1.2.2(b),CN-L3|8.1.4.1(c),CN-L3|8.1.4.7(a),CN-L3|8.1.4.8(a),CN-L3|8.2.4.5(c),CN-L3|8.2.4.5(d),CN-L3|8.5.2.2,CSCv7|14.4,CSCv8|3.10,CSF|PR.AC-1,CSF|PR.AC-3,CSF|PR.DS-2,CSF|PR.DS-5,CSF|PR.PT-4,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),HIPAA|164.312(e)(1),HIPAA|164.312(e)(2)(i),ISO/IEC-27001|A.6.2.2,ISO/IEC-27001|A.10.1.1,ISO/IEC-27001|A.13.2.3,ITSG-33|AC-17(2),ITSG-33|IA-5,ITSG-33|IA-5(1),ITSG-33|SC-8,ITSG-33|SC-8(1),ITSG-33|SC-8a.,LEVEL|1M,NESA|T4.3.1,NESA|T4.3.2,NESA|T4.5.1,NESA|T4.5.2,NESA|T5.2.3,NESA|T5.4.2,NESA|T7.3.3,NESA|T7.4.1,NIAv2|AM37,NIAv2|IE8,NIAv2|IE9,NIAv2|IE12,NIAv2|NS5d,NIAv2|NS6b,NIAv2|NS29,NIAv2|SS24,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|2.1,SWIFT-CSCv1|2.6,SWIFT-CSCv1|4.1,TBA-FIISB|29.1"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "4.1 Ensure That Instances Are Not Configured To Use the Default Service Account"
  info           : "It is recommended to configure your instance to not use the default Compute Engine service account because it has the Editor role on the project.

Rationale:

The default Compute Engine service account has the Editor role on the project, which allows read and write access to most Google Cloud Services. To defend against privilege escalations if your VM is compromised and prevent an attacker from gaining access to all of your project, it is recommended to not use the default Compute Engine service account. Instead, you should create a new service account and assigning only the permissions needed by your instance.

The default Compute Engine service account is named [PROJECT_NUMBER]-compute@developer.gserviceaccount.com."
  solution       : "From Console:

Go to the VM instances page by visiting: https://console.cloud.google.com/compute/instances.

Click on the instance name to go to its VM instance details page.

Click STOP and then click EDIT.

Under the section API and identity management, select a service account other than the default Compute Engine service account. You may first need to create a new service account.

Click Save and then click START.

From Command Line:

Stop the instance:

gcloud compute instances stop <INSTANCE_NAME>

Update the instance:

gcloud compute instances set-service-account <INSTANCE_NAME> --service-account=<SERVICE_ACCOUNT>

Restart the instance:

gcloud compute instances start <INSTANCE_NAME>

Default Value:

By default, Compute instances are configured to use the default Compute Engine service account."
  reference      : "800-171|3.5.2,800-53|IA-5,CSCv7|4.7,CSCv8|4.7,CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5,LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | \"Instance: \(.selfLink), Service Account: \(.serviceAccounts[].email)\""
  regex          : "Service Account:"
  not_expect     : "Service Account: .*-compute@developer.gserviceaccount.com"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.2 Ensure That Instances Are Not Configured To Use the Default Service Account With Full Access to All Cloud APIs"
  info           : "To support principle of least privileges and prevent potential privilege escalation it is recommended that instances are not assigned to default service account Compute Engine default service account with Scope Allow full access to all Cloud APIs.

Rationale:

Along with ability to optionally create, manage and use user managed custom service accounts, Google Compute Engine provides default service account Compute Engine default service account for an instances to access necessary cloud services. Project Editor role is assigned to Compute Engine default service account hence, This service account has almost all capabilities over all cloud services except billing. However, when Compute Engine default service account assigned to an instance it can operate in 3 scopes.

1. Allow default access: Allows only minimum access required to run an Instance (Least Privileges)

2. Allow full access to all Cloud APIs: Allow full access to all the cloud APIs/Services (Too much access)

3. Set access for each API: Allows Instance administrator to choose only those APIs that are needed to perform specific business functionality expected by instance

When an instance is configured with Compute Engine default service account with Scope Allow full access to all Cloud APIs, based on IAM roles assigned to the user(s) accessing Instance, it may allow user to perform cloud operations/API calls that user is not supposed to perform leading to successful privilege escalation.

Impact:

In order to change service account or scope for an instance, it needs to be stopped."
  solution       : "From Console:

Go to the VM instances page by visiting: https://console.cloud.google.com/compute/instances.

Click on the impacted VM instance.

If the instance is not stopped, click the Stop button. Wait for the instance to be stopped.

Next, click the Edit button.

Scroll down to the Service Account section.

Select a different service account or ensure that Allow full access to all Cloud APIs is not selected.

Click the Save button to save your changes and then click START.

From Command Line:

Stop the instance:

gcloud compute instances stop <INSTANCE_NAME>

Update the instance:

gcloud compute instances set-service-account <INSTANCE_NAME> --service-account=<SERVICE_ACCOUNT> --scopes [SCOPE1, SCOPE2...]

Restart the instance:

gcloud compute instances start <INSTANCE_NAME>

Default Value:

While creating an VM instance, default service account is used with scope Allow default access."
  reference      : "800-171|3.5.2,800-53|IA-5,CSCv7|4.7,CSCv8|4.7,CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5,LEVEL|1A,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | \"Instance: \(.selfLink), Service Account: \(.serviceAccounts[].email), Scope: \(.serviceAccounts[].scopes[])\""
  regex          : "Service Account:"
  not_expect     : "Service Account: .*-compute@developer.gserviceaccount.com, Scope: https://www.googleapis.com/auth/cloud-platform"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.3 Ensure 'Block Project-Wide SSH Keys' Is Enabled for VM Instances"
  info           : "It is recommended to use Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.

Rationale:

Project-wide SSH keys are stored in Compute/Project-meta-data. Project wide SSH keys can be used to login into all the instances within project. Using project-wide SSH keys eases the SSH key management but if compromised, poses the security risk which can impact all the instances within project. It is recommended to use Instance specific SSH keys which can limit the attack surface if the SSH keys are compromised.

Impact:

Users already having Project-wide ssh key pairs and using third party SSH clients will lose access to the impacted Instances. For Project users using gcloud or GCP Console based SSH option, no manual key creation and distribution is required and will be handled by GCE (Google Compute Engine) itself. To access Instance using third party SSH clients Instance specific SSH key pairs need to be created and distributed to the required users."
  solution       : "From Console:

Go to the VM instances page by visiting: https://console.cloud.google.com/compute/instances. It will list all the instances in your project.

Click on the name of the Impacted instance

Click Edit in the toolbar

Under SSH Keys, go to the Block project-wide SSH keys checkbox

To block users with project-wide SSH keys from connecting to this instance, select Block project-wide SSH keys

Click Save at the bottom of the page

Repeat steps for every impacted Instance

From Command Line:
To block project-wide public SSH keys, set the metadata value to TRUE:

gcloud compute instances add-metadata <INSTANCE_NAME> --metadata block-project-ssh-keys=TRUE

Default Value:

By Default Block Project-wide SSH keys is not enabled."
  reference      : "800-171|3.1.13,800-171|3.5.2,800-171|3.13.8,800-53|AC-17(2),800-53|IA-5,800-53|IA-5(1),800-53|SC-8,800-53|SC-8(1),CN-L3|7.1.2.7(g),CN-L3|7.1.3.1(d),CN-L3|8.1.2.2(a),CN-L3|8.1.2.2(b),CN-L3|8.1.4.1(c),CN-L3|8.1.4.7(a),CN-L3|8.1.4.8(a),CN-L3|8.2.4.5(c),CN-L3|8.2.4.5(d),CN-L3|8.5.2.2,CSCv7|4.4,CSCv7|16.5,CSCv8|3.10,CSCv8|5.2,CSF|PR.AC-1,CSF|PR.AC-3,CSF|PR.DS-2,CSF|PR.DS-5,CSF|PR.PT-4,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),HIPAA|164.312(e)(1),HIPAA|164.312(e)(2)(i),ISO/IEC-27001|A.6.2.2,ISO/IEC-27001|A.10.1.1,ISO/IEC-27001|A.13.2.3,ITSG-33|AC-17(2),ITSG-33|IA-5,ITSG-33|IA-5(1),ITSG-33|SC-8,ITSG-33|SC-8(1),ITSG-33|SC-8a.,LEVEL|1A,NESA|T4.3.1,NESA|T4.3.2,NESA|T4.5.1,NESA|T4.5.2,NESA|T5.2.3,NESA|T5.4.2,NESA|T7.3.3,NESA|T7.4.1,NIAv2|AM37,NIAv2|IE8,NIAv2|IE9,NIAv2|IE12,NIAv2|NS5d,NIAv2|NS6b,NIAv2|NS29,NIAv2|SS24,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|2.1,SWIFT-CSCv1|2.6,SWIFT-CSCv1|4.1,TBA-FIISB|29.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | [.metadata.items[] | select(.key == \"block-project-ssh-keys\").value] as $value | \"Instance: \(.selfLink), Block Project SSH Keys: \($value[0])\""
  regex          : "Block Project SSH Keys:"
  expect         : "Block Project SSH Keys: true"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.4 Ensure Oslogin Is Enabled for a Project - project"
  info           : "Enabling OS login binds SSH certificates to IAM users and facilitates effective SSH certificate management.

Rationale:

Enabling osLogin ensures that SSH keys used to connect to instances are mapped with IAM users. Revoking access to IAM user will revoke all the SSH keys associated with that particular user. It facilitates centralized and automated SSH key pair management which is useful in handling cases like response to compromised SSH key pairs and/or revocation of external/third-party/Vendor users.

Impact:

Enabling OS Login on project disables metadata-based SSH key configurations on all instances from a project. Disabling OS Login restores SSH keys that you have configured in project or instance meta-data."
  solution       : "From Console:

Go to the VM compute metadata page by visiting: https://console.cloud.google.com/compute/metadata.

Click Edit.

Add a metadata entry where the key is enable-oslogin and the value is TRUE.

Click Save to apply the changes.

For every instances that overrides the project setting, go to the VM Instances page at https://console.cloud.google.com/compute/instances.

Click the name of the instance on which you want to remove the metadata value.

At the top of the instance details page, click Edit to edit the instance settings.

Under Custom metadata, remove any entry with key enable-oslogin and the value is FALSE

At the bottom of the instance details page, click Save to apply your changes to the instance.

From Command Line:

Configure oslogin on the project:

gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE

Remove instance metadata that overrides the project setting.

gcloud compute instances remove-metadata <INSTANCE_NAME> --keys=enable-oslogin

Optionally, you can enable two factor authentication for OS login. For more information, see: https://cloud.google.com/compute/docs/oslogin/setup-two-factor-authentication.

Default Value:

By default, parameter enable-oslogin is not set, which is equivalent to setting it to FALSE."
  reference      : "800-171|3.1.1,800-53|AC-2(1),800-53|AC-3,CN-L3|7.1.3.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|16.2,CSCv8|5.6,CSCv8|6.7,CSF|PR.AC-1,CSF|PR.AC-4,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-2(1),ITSG-33|AC-3,LEVEL|1A,NESA|T4.2.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM3,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2,TBA-FIISB|31.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeProjectInfo"
  json_transform : ".projects[] | [.commonInstanceMetadata.items[] | select(.key == \"enable-oslogin\").value] as $value | \"Project Number: \(.projectNumber), Project ID: \(.projectId), Enable OS Login: \($value[0])\""
  regex          : "Enable OS Login:"
  expect         : "Enable OS Login: true"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.4 Ensure Oslogin Is Enabled for a Project - instances"
  info           : "Enabling OS login binds SSH certificates to IAM users and facilitates effective SSH certificate management.

Rationale:

Enabling osLogin ensures that SSH keys used to connect to instances are mapped with IAM users. Revoking access to IAM user will revoke all the SSH keys associated with that particular user. It facilitates centralized and automated SSH key pair management which is useful in handling cases like response to compromised SSH key pairs and/or revocation of external/third-party/Vendor users.

Impact:

Enabling OS Login on project disables metadata-based SSH key configurations on all instances from a project. Disabling OS Login restores SSH keys that you have configured in project or instance meta-data."
  solution       : "From Console:

Go to the VM compute metadata page by visiting: https://console.cloud.google.com/compute/metadata.

Click Edit.

Add a metadata entry where the key is enable-oslogin and the value is TRUE.

Click Save to apply the changes.

For every instances that overrides the project setting, go to the VM Instances page at https://console.cloud.google.com/compute/instances.

Click the name of the instance on which you want to remove the metadata value.

At the top of the instance details page, click Edit to edit the instance settings.

Under Custom metadata, remove any entry with key enable-oslogin and the value is FALSE

At the bottom of the instance details page, click Save to apply your changes to the instance.

From Command Line:

Configure oslogin on the project:

gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE

Remove instance metadata that overrides the project setting.

gcloud compute instances remove-metadata <INSTANCE_NAME> --keys=enable-oslogin

Optionally, you can enable two factor authentication for OS login. For more information, see: https://cloud.google.com/compute/docs/oslogin/setup-two-factor-authentication.

Default Value:

By default, parameter enable-oslogin is not set, which is equivalent to setting it to FALSE."
  reference      : "800-171|3.1.1,800-53|AC-2(1),800-53|AC-3,CN-L3|7.1.3.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|16.2,CSCv8|5.6,CSCv8|6.7,CSF|PR.AC-1,CSF|PR.AC-4,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.9.2.1,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-2(1),ITSG-33|AC-3,LEVEL|1A,NESA|T4.2.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM3,NIAv2|AM28,NIAv2|NS5j,NIAv2|SS14e,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|8.2.1,QCSC-v1|13.2,QCSC-v1|15.2,TBA-FIISB|31.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | [.metadata.items[] | select(.key == \"enable-oslogin\").value] as $value | \"Instance: \(.selfLink), Enable OS Login: \($value[0])\""
  regex          : "Enable OS Login:"
  not_expect     : "Enable OS Login: false"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.5 Ensure 'Enable Connecting to Serial Ports' Is Not Enabled for VM Instance"
  info           : "Interacting with a serial port is often referred to as the serial console, which is similar to using a terminal window, in that input and output is entirely in text mode and there is no graphical interface or mouse support.

If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. Therefore interactive serial console support should be disabled.

Rationale:

A virtual machine instance has four virtual serial ports. Interacting with a serial port is similar to using a terminal window, in that input and output is entirely in text mode and there is no graphical interface or mouse support. The instance's operating system, BIOS, and other system-level entities often write output to the serial ports, and can accept input such as commands or answers to prompts. Typically, these system-level entities use the first serial port (port 1) and serial port 1 is often referred to as the serial console.

The interactive serial console does not support IP-based access restrictions such as IP whitelists. If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address. This allows anybody to connect to that instance if they know the correct SSH key, username, project ID, zone, and instance name.

Therefore interactive serial console support should be disabled."
  solution       : "From Console:

Login to Google Cloud console

Go to Computer Engine

Go to VM instances

Click on the Specific VM

Click EDIT

Unselect Enable connecting to serial ports below Remote access block.

Click Save

From Command Line:
Use the below command to disable

gcloud compute instances add-metadata <INSTANCE_NAME> --zone=<ZONE> --metadata=serial-port-enable=false

or

gcloud compute instances add-metadata <INSTANCE_NAME> --zone=<ZONE> --metadata=serial-port-enable=0

Prevention:
You can prevent VMs from having serial port access enable by Disable VM serial port access organization policy:

https://console.cloud.google.com/iam-admin/orgpolicies/compute-disableSerialPortAccess.

Default Value:

By default, connecting to serial ports is not enabled."
  reference      : "800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|CM-6,800-53|CM-7,CSCv7|9.2,CSCv8|4.8,CSF|PR.IP-1,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|CM-6,ITSG-33|CM-7,LEVEL|1A,NIAv2|SS15a,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | [.metadata.items[] | select(.key == \"serial-port-enable\").value] as $value | \"Instance: \(.selfLink), Serial Port Enable: \($value[0])\""
  regex          : "Serial Port Enable:"
  expect         : "Serial Port Enable: (0|false)"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "4.6 Ensure That IP Forwarding Is Not Enabled on Instances"
  info           : "Compute Engine instance cannot forward a packet unless the source IP address of the packet matches the IP address of the instance. Similarly, GCP won't deliver a packet whose destination IP address is different than the IP address of the instance receiving the packet. However, both capabilities are required if you want to use instances to help route packets.

Forwarding of data packets should be disabled to prevent data loss or information disclosure.

Rationale:

Compute Engine instance cannot forward a packet unless the source IP address of the packet matches the IP address of the instance. Similarly, GCP won't deliver a packet whose destination IP address is different than the IP address of the instance receiving the packet. However, both capabilities are required if you want to use instances to help route packets. To enable this source and destination IP check, disable the canIpForward field, which allows an instance to send and receive packets with non-matching destination or source IPs.

Impact:

Deleting instance(s) acting as routers/packet forwarders may break the network connectivity."
  solution       : "You only edit the canIpForward setting at instance creation time. Therefore, you need to delete the instance and create a new one where canIpForward is set to false.
From Console:

Go to the VM Instances page by visiting: https://pantheon.corp.google.com/compute/instances.

Select the VM Instance you want to remediate.

Click the Delete button.

On the 'VM Instances' page, click 'CREATE INSTANCE'.

Create a new instance with the desired configuration. By default, the instance is configured to not allow IP forwarding.

From Command Line:

Delete the instance:

gcloud compute instances delete INSTANCE_NAME

Create a new instance to replace it, with IP forwarding set to Off

gcloud compute instances create

Default Value:

By default, instances are not configured to allow IP forwarding."
  reference      : "800-171|3.13.1,800-171|3.13.5,800-171|3.13.6,800-53|CA-9,800-53|SC-7,800-53|SC-7(5),CN-L3|7.1.2.2(c),CN-L3|8.1.10.6(j),CSCv7|11.1,CSCv7|11.2,CSCv8|4.4,CSCv8|4.5,CSF|DE.CM-1,CSF|ID.AM-3,CSF|PR.AC-5,CSF|PR.DS-5,CSF|PR.PT-4,GDPR|32.1.b,GDPR|32.1.d,GDPR|32.2,HIPAA|164.306(a)(1),ISO/IEC-27001|A.13.1.3,ITSG-33|SC-7,ITSG-33|SC-7(5),LEVEL|1A,NESA|T4.5.4,NIAv2|GS1,NIAv2|GS2a,NIAv2|GS2b,NIAv2|GS7b,NIAv2|NS25,QCSC-v1|4.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,SWIFT-CSCv1|2.1,TBA-FIISB|43.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listComputeInstances"
  json_transform : ".projects[].value.items[] | select(.value.items | length > 0) | .value.items[] | \"Instance: \(.selfLink), Can IP Forward: \(.canIpForward)\""
  regex          : "Can IP Forward:"
  not_expect     : "Can IP Forward: true"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "5.1 Ensure That Cloud Storage Bucket Is Not Anonymously or Publicly Accessible"
  info           : "It is recommended that IAM policy on Cloud Storage bucket does not allows anonymous or public access.

Rationale:

Allowing anonymous or public access grants permissions to anyone to access bucket content. Such access might not be desired if you are storing any sensitive data. Hence, ensure that anonymous or public access to a bucket is not allowed.

Impact:

No storage buckets would be publicly accessible. You would have to explicitly administer bucket access."
  solution       : "From Console:

Go to Storage browser by visiting https://console.cloud.google.com/storage/browser.

Click on the bucket name to go to its Bucket details page.

Click on the Permissions tab.

Click Delete button in front of allUsers and allAuthenticatedUsers to remove that particular role assignment.

From Command Line:
Remove allUsers and allAuthenticatedUsers access.

gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME

Prevention:
You can prevent Storage buckets from becoming publicly accessible by setting up the Domain restricted sharing organization policy at: https://console.cloud.google.com/iam-admin/orgpolicies/iam-allowedPolicyMemberDomains .

Default Value:

By Default, Storage buckets are not publicly shared."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|12.4,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listBucketsIam"
  json_transform : ".projects[].value.items[] | .selfLink as $selfLink | .value.bindings[] | \"Bucket: \($selfLink), Role: \(.role), Member: \(.members[])\""
  regex          : "Member:"
  not_expect     : "Member: (allUsers|allAuthenticatedUsers)"
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.1.1 Ensure That a MySQL Database Instance Does Not Allow Anyone To Connect With Administrative Privileges"
  info           : "It is recommended to set a password for the administrative user (root by default) to prevent unauthorized access to the SQL database instances.

This recommendation is applicable only for MySQL Instances. PostgreSQL does not offer any setting for No Password from the cloud console.

Rationale:

At the time of MySQL Instance creation, not providing an administrative password allows anyone to connect to the SQL database instance with administrative privileges. The root password should be set to ensure only authorized users have these privileges.

Impact:

Connection strings for administrative clients need to be reconfigured to use a password.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Platform Console using https://console.cloud.google.com/sql/

Select the instance to open its Overview page.

Select Access Control > Users.

Click the More actions icon for the user to be updated.

Select Change password, specify a New password, and click OK.

From Command Line:

Set a password to a MySql instance:

gcloud sql users set-password root --host=<host> --instance=<instance_name> --prompt-for-password

A prompt will appear, requiring the user to enter a password:

Instance Password:

With a successful password configured, the following message should be seen:

Updating Cloud SQL user...done.

Default Value:

From the Google Cloud Platform Console, the Create Instance workflow enforces the rule to enter the root password unless the option No Password is selected explicitly."
  reference      : "800-171|3.5.2,800-53|IA-5,CSCv7|4.2,CSCv8|4.7,CSF|PR.AC-1,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),ITSG-33|IA-5,LEVEL|1M,NESA|T5.2.3,QCSC-v1|5.2.2,QCSC-v1|13.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), IP Addresses: \(.ipAddresses[])\""
  regex          : "Database Version: MYSQL"
  expect         : "MANUAL REVIEW REQUIRED"
  match_all      : YES
  severity       : MEDIUM
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.1.2 Ensure 'Skip_show_database' Database Flag for Cloud SQL MySQL Instance Is Set to 'On'"
  info           : "It is recommended to set skip_show_database database flag for Cloud SQL Mysql instance to on

Rationale:

'skip_show_database' database flag prevents people from using the SHOW DATABASES statement if they do not have the SHOW DATABASES privilege. This can improve security if you have concerns about users being able to see databases belonging to other users. Its effect depends on the SHOW DATABASES privilege: If the variable value is ON, the SHOW DATABASES statement is permitted only to users who have the SHOW DATABASES privilege, and the statement displays all database names. If the value is OFF, SHOW DATABASES is permitted to all users, but displays the names of only those databases for which the user has the SHOW DATABASES or other privilege. This recommendation is applicable to Mysql database instances."
  solution       : "Using Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the Mysql instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag skip_show_database from the drop-down menu, and set its value to on.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

Using Command Line:

List all Cloud SQL database Instances

gcloud sql instances list

Configure the skip_show_database database flag for every Cloud SQL Mysql database instance using the below command.

gcloud sql instances patch INSTANCE_NAME --database-flags skip_show_database=on

Note :

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=')."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"skip_show_database\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Show Skip Database: \($value[0])\""
  regex          : "Database Version: MYSQL"
  expect         : "Show Skip Database: on"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.1.3 Ensure That the 'Local_infile' Database Flag for a Cloud SQL MySQL Instance Is Set to 'Off'"
  info           : "It is recommended to set the local_infile database flag for a Cloud SQL MySQL instance to off.

Rationale:

The local_infile flag controls the server-side LOCAL capability for LOAD DATA statements. Depending on the local_infile setting, the server refuses or permits local data loading by clients that have LOCAL enabled on the client side.

To explicitly cause the server to refuse LOAD DATA LOCAL statements (regardless of how client programs and libraries are configured at build time or runtime), start mysqld with local_infile disabled. local_infile can also be set at runtime.

Due to security issues associated with the local_infile flag, it is recommended to disable it. This recommendation is applicable to MySQL database instances.

Impact:

Disabling local_infile makes the server refuse local data loading by clients that have LOCAL enabled on the client side."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the MySQL instance where the database flag needs to be enabled.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag local_infile from the drop-down menu, and set its value to off.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

List all Cloud SQL database instances using the following command:

gcloud sql instances list

Configure the local_infile database flag for every Cloud SQL Mysql database instance using the below command:

gcloud sql instances patch INSTANCE_NAME --database-flags local_infile=off

Note :

This command will overwrite all database flags that were previously set. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default local_infile is on."
  reference      : "800-171|3.4.2,800-53|CM-6b.,CN-L3|8.1.10.6(d),CSF|PR.IP-1,GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|CM-6b.,LEVEL|1A,NESA|T3.2.1,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"local_infile\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Local Infile: \($value[0])\""
  regex          : "Database Version: MYSQL"
  expect         : "Local Infile: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.2.2 Ensure That the 'Log_connections' Database Flag for Cloud SQL PostgreSQL Instance Is Set to 'On'"
  info           : "Enabling the log_connections setting causes each attempted connection to the server to be logged, along with successful completion of client authentication. This parameter cannot be changed after the session starts.

Rationale:

PostgreSQL does not log attempted connections by default. Enabling the log_connections setting will create log entries for each attempted connection as well as successful completion of client authentication which can be useful in troubleshooting issues and to determine any unusual connection attempts to the server. This recommendation is applicable to PostgreSQL database instances.

Impact:

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase. Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance for which you want to enable the database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_connections from the drop-down menu and set the value as on.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

Configure the log_connections database flag for every Cloud SQL PosgreSQL database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_connections=on

Note:
This command will overwrite all previously set database flags. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_connections is off."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"log_connections\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Log Connections: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "Log Connections: on"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.2.3 Ensure That the 'Log_disconnections' Database Flag for Cloud SQL PostgreSQL Instance Is Set to 'On'"
  info           : "Enabling the log_disconnections setting logs the end of each session, including the session duration.

Rationale:

PostgreSQL does not log session details such as duration and session end by default. Enabling the log_disconnections setting will create log entries at the end of each session which can be useful in troubleshooting issues and determine any unusual activity across a time period. The log_disconnections and log_connections work hand in hand and generally, the pair would be enabled/disabled together. This recommendation is applicable to PostgreSQL database instances.

Impact:

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase. Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance where the database flag needs to be enabled.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_disconnections from the drop-down menu and set the value as on.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

Configure the log_disconnections database flag for every Cloud SQL PosgreSQL database instance using the below command:

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_disconnections=on

Note: This command will overwrite all previously setdatabase flags. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_disconnections is off."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"log_disconnections\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Log Disconnections: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "Log Disconnections: on"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "6.2.4 Ensure 'Log_statement' Database Flag for Cloud SQL PostgreSQL Instance Is Set Appropriately"
  info        : "The value of log_statement flag determined the SQL statements that are logged. Valid values are:

none

ddl

mod

all

The value ddl logs all data definition statements. The value mod logs all ddl statements, plus data-modifying statements.

The statements are logged after a basic parsing is done and statement type is determined, thus this does not logs statements with errors. When using extended query protocol, logging occurs after an Execute message is received and values of the Bind parameters are included.

A value of 'ddl' is recommended unless otherwise directed by your organization's logging policy.

Rationale:

Auditing helps in forensic analysis. If log_statement is not set to the correct value, too many statements may be logged leading to issues in finding the relevant information from the logs, or too few statements may be logged with relevant information missing from the logs. Setting log_statement to align with your organization's security and logging policies facilitates later auditing and review of database activities. This recommendation is applicable to PostgreSQL database instances.

Impact:

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase. Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance for which you want to enable the database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_statement from the drop-down menu and set appropriate value.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the log_statement database flag for every Cloud SQL PosgreSQL database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_statement=<ddl|mod|all|none>

Note: This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=')."
  reference   : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1M,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "6.2.5 Ensure 'Log_hostname' Database Flag for Cloud SQL PostgreSQL Instance Is Set to 'on'"
  info           : "PostgreSQL logs only the IP address of the connecting hosts. The log_hostname flag controls the logging of hostnames in addition to the IP addresses logged. The performance hit is dependent on the configuration of the environment and the host name resolution setup. This parameter can only be set in the postgresql.conf file or on the server command line.

Rationale:

Logging hostnames allows for the association of hostname to IP address at the time of connection. This information can aid with incident response efforts particularly in an environment that utilized dynamic IP addresses. Logging hostnames may incur overhead on server performance as for each statement logged, DNS resolution will be required to convert IP address to hostname. Depending on the setup, this may be non-negligible. This recommendation is applicable to PostgreSQL database instances.

Impact:

Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance for which you want to enable the database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_hostname from the drop-down menu and the value to On.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the log_hostname database flag for every Cloud SQL PosgreSQL database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_hostname=on

Note: This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_hostname is off."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"log_hostname\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Log Hostname: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "Log Hostname: @POSTGRES_LOG_HOSTNAME@"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.2.9 Ensure That 'cloudsql.enable_pgaudit' Database Flag for each Cloud Sql Postgresql Instance Is Set to 'on' For Centralized Logging"
  info           : "Ensure cloudsql.enable_pgaudit database flag for Cloud SQL PostgreSQL instance is set to on to allow for centralized logging.

Rationale:

As numerous other recommendations in this section consist of turning on flags for logging purposes, your organization will need a way to manage these logs. You may have a solution already in place. If you do not, consider installing and enabling the open source pgaudit extension within PostgreSQL and enabling its corresponding flag of cloudsql.enable_pgaudit. This flag and installing the extension enables database auditing in PostgreSQL through the open-source pgAudit extension. This extension provides detailed session and object logging to comply with government, financial, & ISO standards and provides auditing capabilities to mitigate threats by monitoring security events on the instance. Enabling the flag and settings later in this recommendation will send these logs to Google Logs Explorer so that you can access them in a central location. to This recommendation is applicable only to PostgreSQL database instances.

Impact:

Enabling the pgAudit extension can lead to increased data storage requirements and to ensure durability of pgAudit log records in the event of unexpected storage issues, it is recommended to enable the Enable automatic storage increases setting on the instance. Enabling flags via the command line will also overwrite all existing flags, so you should apply all needed flags in the CLI command. Also flags may require a restart of the server to be implemented or will break existing functionality so update your servers at a time of low usage."
  solution       : "Initialize the pgAudit flag

From Console:

Go to https://console.cloud.google.com/sql/instances.

Select the instance to open its Overview page.

Click Edit.

Scroll down and expand Flags.

To set a flag that has not been set on the instance before, click Add item.

Enter cloudsql.enable_pgaudit for the flag name and set the flag to on.

Click Done.

Click Save to update the configuration.

Confirm your changes under Flags on the Overview page.

From Command Line:
Run the below command by providing <INSTANCE_NAME> to enable cloudsql.enable_pgaudit flag.

gcloud sql instances patch <INSTANCE_NAME> --database-flags=cloudsql.enable_pgaudit=on

Note: RESTART is required to get this configuration in effect.

Creating the extension

Connect to the the server running PostgreSQL or through a SQL client of your choice.

If SSHing to the server in the command line open the PostgreSQL shell by typing psql

Run the following command as a superuser.

CREATE EXTENSION pgaudit;

Updating the previously created pgaudit.log flag for your Logging Needs

From Console:
Note: there are multiple options here. This command will enable logging for all databases on a server. Please see the customizing database audit logging reference for more flag options.

Go to https://console.cloud.google.com/sql/instances.

Select the instance to open its Overview page.

Click Edit.

Scroll down and expand Flags.

To set a flag that has not been set on the instance before, click Add item.

Enter pgaudit.log=all for the flag name and set the flag to on.

Click Done.

Click Save to update the configuration.

Confirm your changes under Flags on the Overview page.

From Command Line:
Run the command

gcloud sql instances patch <INSTANCE_NAME> --database-flags \
  cloudsql.enable_pgaudit=on,pgaudit.log=all

Determine if logs are being sent to Logs Explorer

From the Google Console home page, open the hamburger menu in the top left.

In the menu that pops open, scroll down to Logs Explorer under Operations.

In the query box, paste the following and search

resource.type='cloudsql_database'
logName='projects//logs/cloudaudit.googleapis.com%2Fdata_access'
protoPayload.request.@type='type.googleapis.com/google.cloud.sql.audit.v1.PgAuditEntry'

If it returns any log sources, they are correctly setup.

Default Value:

By default cloudsql.enable_pgaudit database flag is set to off and the extension is not enabled."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.5,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-6(3),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|7.1.3.3(d),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv7|6.5,CSCv8|8.5,CSCv8|8.9,CSF|DE.AE-2,CSF|DE.AE-3,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|DE.DP-4,CSF|PR.PT-1,CSF|RS.AN-1,CSF|RS.AN-3,CSF|RS.CO-2,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-6(3),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|M5.2.5,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|5.2.3,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"cloudsql.enable_pgaudit\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), CloudSQL Enable PG Audit: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "CloudSQL Enable PG Audit: on"
  match_all      : YES
</custom_item>

<report type:"WARNING">
  description : "6.2.6 Ensure That the 'Log_min_messages' Database Flag for Cloud SQL PostgreSQL Instance Is Set to at least 'Warning'"
  info        : "The log_min_messages flag defines the minimum message severity level that is considered as an error statement. Messages for error statements are logged with the SQL statement. Valid values include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels mentioned above. ERROR is considered the best practice setting. Changes should only be made in accordance with the organization's logging policy.

Rationale:

Auditing helps in troubleshooting operational problems and also permits forensic analysis. If log_min_error_statement is not set to the correct value, messages may not be classified as error messages appropriately. An organization will need to decide their own threshold for logging log_min_messages flag.

This recommendation is applicable to PostgreSQL database instances.

Impact:

Setting the threshold too low will might result in increased log storage size and length making it difficult to find actual errors. Setting the threshold to 'Warning' will log messages most needed error messages. Higher severity levels may cause errors needed to troubleshoot to not be logged.

Note: To effectively turn off logging failing statements, set this parameter to PANIC.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance."
  solution    : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances

Select the PostgreSQL instance for which you want to enable the database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_min_messages from the drop-down menu and set appropriate value.

Click Save to save the changes.

Confirm the changes under Flags on the Overview page.

From Command Line:

Configure the log_min_messages database flag for every Cloud SQL PosgreSQL database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_min_messages=<DEBUG5|DEBUG4|DEBUG3|DEBUG2|DEBUG1|INFO|NOTICE|WARNING|ERROR|LOG|FATAL|PANIC>

Note: This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_min_error_statement is ERROR."
  reference   : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1M,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also    : "https://workbench.cisecurity.org/files/3817"
</report>

<custom_item>
  type           : REST_API
  description    : "6.2.7 Ensure 'Log_min_error_statement' Database Flag for Cloud SQL PostgreSQL Instance Is Set to 'Error' or Stricter"
  info           : "The log_min_error_statement flag defines the minimum message severity level that are considered as an error statement. Messages for error statements are logged with the SQL statement. Valid values include DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. Each severity level includes the subsequent levels mentioned above. Ensure a value of ERROR or stricter is set.

Rationale:

Auditing helps in troubleshooting operational problems and also permits forensic analysis. If log_min_error_statement is not set to the correct value, messages may not be classified as error messages appropriately. Considering general log messages as error messages would make is difficult to find actual errors and considering only stricter severity levels as error messages may skip actual errors to log their SQL statements. The log_min_error_statement flag should be set to ERROR or stricter. This recommendation is applicable to PostgreSQL database instances.

Impact:

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase.Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance for which you want to enable the database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_min_error_statement from the drop-down menu and set appropriate value.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the log_min_error_statement database flag for every Cloud SQL PosgreSQL database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_min_error_statement=<DEBUG5|DEBUG4|DEBUG3|DEBUG2|DEBUG1|INFO|NOTICE|WARNING|ERROR>

Note: This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_min_error_statement is ERROR."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"log_min_error_statement\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Log Min Error Statement: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "Log Min Error Statement: (ERROR|LOG|FATAL|PANIC)"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.2.8 Ensure That the 'Log_min_duration_statement' Database Flag for Cloud SQL PostgreSQL Instance Is Set to '-1' (Disabled)"
  info           : "The log_min_duration_statement flag defines the minimum amount of execution time of a statement in milliseconds where the total duration of the statement is logged. Ensure that log_min_duration_statement is disabled, i.e., a value of -1 is set.

Rationale:

Logging SQL statements may include sensitive information that should not be recorded in logs. This recommendation is applicable to PostgreSQL database instances.

Impact:

Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase.Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the PostgreSQL instance where the database flag needs to be enabled.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag log_min_duration_statement from the drop-down menu and set a value of -1.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

List all Cloud SQL database instances using the following command:

gcloud sql instances list

Configure the log_min_duration_statement flag for every Cloud SQL PosgreSQL database instance using the below command:

gcloud sql instances patch <INSTANCE_NAME> --database-flags log_min_duration_statement=-1

Note: This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default log_min_duration_statement is -1."
  reference      : "800-171|3.3.1,800-171|3.3.2,800-171|3.3.6,800-53|AU-3,800-53|AU-3(1),800-53|AU-7,800-53|AU-12,CN-L3|7.1.2.3(a),CN-L3|7.1.2.3(b),CN-L3|7.1.2.3(c),CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|8.1.4.3(b),CSCv7|6.3,CSCv8|8.5,CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,CSF|RS.AN-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(b),ITSG-33|AU-3,ITSG-33|AU-3(1),ITSG-33|AU-7,ITSG-33|AU-12,LEVEL|1A,NESA|T3.6.2,NIAv2|AM34a,NIAv2|AM34b,NIAv2|AM34c,NIAv2|AM34d,NIAv2|AM34e,NIAv2|AM34f,NIAv2|AM34g,QCSC-v1|3.2,QCSC-v1|6.2,QCSC-v1|8.2.1,QCSC-v1|10.2.1,QCSC-v1|11.2,QCSC-v1|13.2,SWIFT-CSCv1|6.4"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"log_min_duration_statement\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Log Min Duration Statement: \($value[0])\""
  regex          : "Database Version: POSTGRES"
  expect         : "Log Min Duration Statement: -1"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.1 Ensure 'external scripts enabled' database flag for Cloud SQL SQL Server instance is set to 'off'"
  info           : "It is recommended to set external scripts enabled database flag for Cloud SQL SQL Server instance to off

Rationale:

external scripts enabled enable the execution of scripts with certain remote language extensions. This property is OFF by default. When Advanced Analytics Services is installed, setup can optionally set this property to true. As the External Scripts Enabled feature allows scripts external to SQL such as files located in an R library to be executed, which could adversely affect the security of the system, hence this should be disabled.This recommendation is applicable to SQL Server database instances.

Impact:

Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag external scripts enabled from the drop-down menu, and set its value to off.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the external scripts enabled database flag for every Cloud SQL SQL Server database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags 'external scripts enabled=off'

Note :

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default external scripts enabled is off"
  reference      : "800-171|3.4.6,800-171|3.4.7,800-53|CM-7,800-53|CM-7(1),800-53|SI-7,800-53|SI-7(1),CN-L3|7.1.3.5(b),CSCv7|2.9,CSCv8|2.7,CSF|PR.DS-6,CSF|PR.IP-1,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(c)(1),HIPAA|164.312(c)(2),HIPAA|164.312(e)(2)(i),ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|SI-7,ITSG-33|SI-7(1),ITSG-33|SI-7a.,LEVEL|1A,NESA|T3.4.1,NESA|T7.3.2,NESA|T7.3.3,NIAv2|SS15a,QCSC-v1|3.2,SWIFT-CSCv1|2.3,SWIFT-CSCv1|6.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"external scripts enabled\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), External Scripts Enabled: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "External Scripts Enabled: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.2 Ensure that the 'cross db ownership chaining' database flag for Cloud SQL SQL Server instance is set to 'off'"
  info           : "It is recommended to set cross db ownership chaining database flag for Cloud SQL SQL Server instance to off.

Rationale:

Use the cross db ownership for chaining option to configure cross-database ownership chaining for an instance of Microsoft SQL Server. This server option allows you to control cross-database ownership chaining at the database level or to allow cross-database ownership chaining for all databases. Enabling cross db ownership is not recommended unless all of the databases hosted by the instance of SQL Server must participate in cross-database ownership chaining and you are aware of the security implications of this setting.This recommendation is applicable to SQL Server database instances.

Impact:

Updating flags may cause the database to restart. This may cause it to unavailable for a short amount of time, so this is best done at a time of low usage. You should also determine if the tables in your databases reference another table without using credentials for that database, as turning off cross database ownership will break this relationship."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag cross db ownership chaining from the drop-down menu, and set its value to off.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

Configure the cross db ownership chaining database flag for every Cloud SQL SQL Server database instance using the below command:

gcloud sql instances patch <INSTANCE_NAME> --database-flags 'cross db ownership chaining=off'

Note:
This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

As you have to manually turn on this flag, the default value for this is 'On'. Though you would have had to design your database schema from the start to include this feature, it often is not enabled."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"cross db ownership chaining\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Cross DB Ownership Chaining: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "Cross DB Ownership Chaining: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.3 Ensure 'user Connections' Database Flag for Cloud Sql Sql Server Instance Is Set to a Non-limiting Value"
  info           : "It is recommended to check the user connections for a Cloud SQL SQL Server instance to ensure that it is not artificially limiting connections.

Rationale:

The user connections option specifies the maximum number of simultaneous user connections that are allowed on an instance of SQL Server. The actual number of user connections allowed also depends on the version of SQL Server that you are using, and also the limits of your application or applications and hardware. SQL Server allows a maximum of 32,767 user connections. Because user connections is by default a self-configuring value, with SQL Server adjusting the maximum number of user connections automatically as needed, up to the maximum value allowable. For example, if only 10 users are logged in, 10 user connection objects are allocated. In most cases, you do not have to change the value for this option. The default is 0, which means that the maximum (32,767) user connections are allowed. However if there is a number defined here that limits connections, SQL Server will not allow anymore above this limit. If the connections are at the limit, any new requests will be dropped, potentially causing lost data or outages for those using the database.

Impact:

Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "Using Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag user connections from the drop-down menu, and set its value to your organization recommended value.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

Using Command Line:

Configure the user connections database flag for every Cloud SQL SQL Server database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags 'user connections=[0-32,767]'

Note :

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default user connections is set to '0' which does not limit the number of connections, giving the server free reign to facilitate a max of 32,767 connections."
  reference      : "800-53|SC-6,CN-L3|7.1.3.7(c),CN-L3|7.1.3.7(d),GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|SC-6,ITSG-33|SC-6a.,LEVEL|1A,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"user connections\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), User Connections: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "User Connections: @SQLSERVER_USER_CONNECTIONS@"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.4 Ensure 'user options' database flag for Cloud SQL SQL Server instance is not configured"
  info           : "It is recommended that, user options database flag for Cloud SQL SQL Server instance should not be configured.

Rationale:

The user options option specifies global defaults for all users. A list of default query processing options is established for the duration of a user's work session. The user options option allows you to change the default values of the SET options (if the server's default settings are not appropriate).

A user can override these defaults by using the SET statement. You can configure user options dynamically for new logins. After you change the setting of user options, new login sessions use the new setting; current login sessions are not affected. This recommendation is applicable to SQL Server database instances.

Impact:

Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

Click the X next user options flag shown

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

List all Cloud SQL database Instances

gcloud sql instances list

Clear the user options database flag for every Cloud SQL SQL Server database instance using either of the below commands.

1.Clearing all flags to their default value

gcloud sql instances patch <INSTANCE_NAME> --clear-database-flags

OR
2. To clear only 'user options' database flag, configure the database flag by overriding the 'user options'. Exclude 'user options' flag and its value, and keep all other flags you want to configure.

gcloud sql instances patch <INSTANCE_NAME> --database-flags [FLAG1=VALUE1,FLAG2=VALUE2]

Note :

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default 'user options' is not configured."
  reference      : "800-171|3.4.1,800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-171|3.13.1,800-171|3.13.2,800-53|CM-1,800-53|CM-2,800-53|CM-6,800-53|CM-7,800-53|CM-7(1),800-53|CM-9,800-53|SA-3,800-53|SA-8,800-53|SA-10,CSCv7|5.1,CSCv8|4.1,CSF|DE.AE-1,CSF|ID.GV-1,CSF|ID.GV-3,CSF|PR.DS-7,CSF|PR.IP-1,CSF|PR.IP-2,CSF|PR.IP-3,CSF|PR.PT-3,GDPR|32.1.b,GDPR|32.4,HIPAA|164.306(a)(1),ITSG-33|CM-1,ITSG-33|CM-2,ITSG-33|CM-6,ITSG-33|CM-7,ITSG-33|CM-7(1),ITSG-33|CM-9,ITSG-33|SA-3,ITSG-33|SA-8,ITSG-33|SA-8a.,ITSG-33|SA-10,LEVEL|1A,NESA|M1.2.2,NESA|T1.2.1,NESA|T1.2.2,NESA|T3.2.5,NESA|T3.4.1,NESA|T4.5.3,NESA|T4.5.4,NESA|T7.2.1,NESA|T7.5.1,NESA|T7.5.3,NESA|T7.6.1,NESA|T7.6.2,NESA|T7.6.3,NESA|T7.6.5,NIAv2|GS8b,NIAv2|SS3,NIAv2|SS15a,NIAv2|SS16,NIAv2|VL2,NIAv2|VL7a,NIAv2|VL7b,QCSC-v1|3.2,QCSC-v1|4.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|7.2,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"user options\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), User Options: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "User Options: null"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.5 Ensure 'remote access' database flag for Cloud SQL SQL Server instance is set to 'off'"
  info           : "It is recommended to set remote access database flag for Cloud SQL SQL Server instance to off.

Rationale:

The remote access option controls the execution of stored procedures from local or remote servers on which instances of SQL Server are running. This default value for this option is 1. This grants permission to run local stored procedures from remote servers or remote stored procedures from the local server. To prevent local stored procedures from being run from a remote server or remote stored procedures from being run on the local server, this must be disabled. The Remote Access option controls the execution of local stored procedures on remote servers or remote stored procedures on local server. 'Remote access' functionality can be abused to launch a Denial-of-Service (DoS) attack on remote servers by off-loading query processing to a target, hence this should be disabled. This recommendation is applicable to SQL Server database instances.

Impact:

Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag remote access from the drop-down menu, and set its value to off.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the remote access database flag for every Cloud SQL SQL Server database instance using the below command

gcloud sql instances patch <INSTANCE_NAME> --database-flags 'remote access=off'

Note :

This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

By default 'remote access' is 'on'."
  reference      : "800-171|3.4.2,800-171|3.4.6,800-171|3.4.7,800-53|CM-6,800-53|CM-7,CSCv7|9.2,CSCv8|4.8,CSF|PR.IP-1,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|CM-6,ITSG-33|CM-7,LEVEL|1A,NIAv2|SS15a,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"remote access\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Remote Access: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "Remote Access: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.6 Ensure '3625 (trace flag)' database flag for all Cloud SQL Server instances is set to 'off'"
  info           : "It is recommended to set 3625 (trace flag) database flag for Cloud SQL SQL Server instance to off.

Rationale:

Microsoft SQL Trace Flags are frequently used to diagnose performance issues or to debug stored procedures or complex computer systems, but they may also be recommended by Microsoft Support to address behavior that is negatively impacting a specific workload. All documented trace flags and those recommended by Microsoft Support are fully supported in a production environment when used as directed. 3625(trace log) Limits the amount of information returned to users who are not members of the sysadmin fixed server role, by masking the parameters of some error messages using '*'. Setting this in a Google Cloud flag for the instance allows for security through obscurity and prevents the disclosure of sensitive information, hence this is recommended to set this flag globally to off to prevent the flag having been left on, or turned on by bad actors. This recommendation is applicable to SQL Server database instances.

Impact:

Changing flags on a database may cause it to be restarted. The best time to do this is at a time where there is low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag 3625 from the drop-down menu, and set its value to off.

Click Save to save your changes.

Confirm your changes under Flags on the Overview page.

From Command Line:

Configure the 3625 database flag for every Cloud SQL SQL Server database instance using the below command.

gcloud sql instances patch <INSTANCE_NAME> --database-flags '3625=off'

Note :
This command will overwrite all database flags previously set. To keep those and add new ones, include the values for all flags you want set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=').

Default Value:

MySQL implementations by default do not have trace flags turned on, as they are used for logging purposes."
  reference      : "800-171|3.4.2,800-53|CM-6b.,CN-L3|8.1.10.6(d),CSF|PR.IP-1,GDPR|32.1.b,HIPAA|164.306(a)(1),ITSG-33|CM-6b.,LEVEL|1A,NESA|T3.2.1,SWIFT-CSCv1|2.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"3625\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), 3625: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "3625: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.3.7 Ensure that the 'contained database authentication' database flag for Cloud SQL on the SQL Server instance is set to 'off'"
  info           : "It is recommended to set contained database authentication database flag for Cloud SQL on the SQL Server instance is set to off.

Rationale:

A contained database includes all database settings and metadata required to define the database and has no configuration dependencies on the instance of the Database Engine where the database is installed. Users can connect to the database without authenticating a login at the Database Engine level. Isolating the database from the Database Engine makes it possible to easily move the database to another instance of SQL Server. Contained databases have some unique threats that should be understood and mitigated by SQL Server Database Engine administrators. Most of the threats are related to the USER WITH PASSWORD authentication process, which moves the authentication boundary from the Database Engine level to the database level, hence this is recommended to disable this flag. This recommendation is applicable to SQL Server database instances.

Impact:

When contained database authentication is off (0) for the instance, contained databases cannot be created, or attached to the Database Engine. Turning on logging will increase the required storage over time. Mismanaged logs may cause your storage costs to increase.Setting custom flags via command line on certain instances will cause all omitted flags to be reset to defaults. This may cause you to lose custom flags and could result in unforeseen complications or instance restarts. Because of this, it is recommended you apply these flags changes during a period of low usage."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the SQL Server instance for which you want to enable to database flag.

Click Edit.

Scroll down to the Flags section.

To set a flag that has not been set on the instance before, click Add item, choose the flag contained database authentication from the drop-down menu, and set its value to off.

Click Save.

Confirm the changes under Flags on the Overview page.

From Command Line:

Configure the contained database authentication database flag for every Cloud SQL SQL Server database instance using the below command:

gcloud sql instances patch <INSTANCE_NAME> --database-flags 'contained database authentication=off'

Note:

This command will overwrite all database flags previously set. To keep those and add new ones, , include the values for all flags to be set on the instance; any flag not specifically included is set to its default value. For flags that do not take a value, specify the flag name followed by an equals sign ('=')."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | [.settings.databaseFlags[] | select(.name == \"contained database authentication\").value] as $value | \"Instance: \(.selfLink), Database Version: \(.databaseVersion), Contained Database Authentication: \($value[0])\""
  regex          : "Database Version: SQLSERVER"
  expect         : "Contained Database Authentication: off"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.4 Ensure That the Cloud SQL Database Instance Requires All Incoming Connections To Use SSL"
  info           : "It is recommended to enforce all incoming connections to SQL database instance to use SSL.

Rationale:

SQL database connections if successfully trapped (MITM); can reveal sensitive data like credentials, database queries, query outputs etc. For security, it is recommended to always use SSL encryption when connecting to your instance. This recommendation is applicable for Postgresql, MySql generation 1, MySql generation 2 and SQL Server 2017 instances.

Impact:

After enforcing SSL connection, existing client will not be able to communicate with SQL server unless configured with appropriate client-certificates to communicate to SQL database instance."
  solution       : "From Console:

Go to https://console.cloud.google.com/sql/instances.

Click on an instance name to see its configuration overview.

In the left-side panel, select Connections.

In the SSL connections section, click Allow only SSL connections.

Under Configure SSL server certificates click Create new certificate.

Under Configure SSL client certificates click Create a client certificate.

Follow the instructions shown to learn how to connect to your instance.

From Command Line:
To enforce SSL encryption for an instance run the command:

gcloud sql instances patch <INSTANCE_NAME> --require-ssl

Note:
RESTART is required for type MySQL Generation 1 Instances (backendType: FIRST_GEN) to get this configuration in effect.

Default Value:

By default parameter settings: ipConfiguration: requireSsl is not set which is equivalent to requireSsl:false."
  reference      : "800-171|3.1.13,800-171|3.5.2,800-171|3.13.8,800-53|AC-17(2),800-53|IA-5,800-53|IA-5(1),800-53|SC-8,800-53|SC-8(1),CN-L3|7.1.2.7(g),CN-L3|7.1.3.1(d),CN-L3|8.1.2.2(a),CN-L3|8.1.2.2(b),CN-L3|8.1.4.1(c),CN-L3|8.1.4.7(a),CN-L3|8.1.4.8(a),CN-L3|8.2.4.5(c),CN-L3|8.2.4.5(d),CN-L3|8.5.2.2,CSCv7|14.4,CSCv7|16.5,CSCv8|3.10,CSF|PR.AC-1,CSF|PR.AC-3,CSF|PR.DS-2,CSF|PR.DS-5,CSF|PR.PT-4,GDPR|32.1.a,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),HIPAA|164.312(a)(2)(i),HIPAA|164.312(d),HIPAA|164.312(e)(1),HIPAA|164.312(e)(2)(i),ISO/IEC-27001|A.6.2.2,ISO/IEC-27001|A.10.1.1,ISO/IEC-27001|A.13.2.3,ITSG-33|AC-17(2),ITSG-33|IA-5,ITSG-33|IA-5(1),ITSG-33|SC-8,ITSG-33|SC-8(1),ITSG-33|SC-8a.,LEVEL|1A,NESA|T4.3.1,NESA|T4.3.2,NESA|T4.5.1,NESA|T4.5.2,NESA|T5.2.3,NESA|T5.4.2,NESA|T7.3.3,NESA|T7.4.1,NIAv2|AM37,NIAv2|IE8,NIAv2|IE9,NIAv2|IE12,NIAv2|NS5d,NIAv2|NS6b,NIAv2|NS29,NIAv2|SS24,QCSC-v1|3.2,QCSC-v1|5.2.1,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|2.1,SWIFT-CSCv1|2.6,SWIFT-CSCv1|4.1,TBA-FIISB|29.1"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | \"Instance: \(.selfLink), Require SSL: \(.settings.ipConfiguration.requireSsl)\""
  regex          : "Require SSL:"
  expect         : "Require SSL: true"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.5 Ensure That Cloud SQL Database Instances Do Not Implicitly Whitelist All Public IP Addresses"
  info           : "Database Server should accept connections only from trusted Network(s)/IP(s) and restrict access from public IP addresses.

Rationale:

To minimize attack surface on a Database server instance, only trusted/known and required IP(s) should be white-listed to connect to it.

An authorized network should not have IPs/networks configured to 0.0.0.0/0 which will allow access to the instance from anywhere in the world. Note that authorized networks apply only to instances with public IPs.

Impact:

The Cloud SQL database instance would not be available to public IP addresses."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Click the instance name to open its Instance details page.

Under the Configuration section click Edit configurations

Under Configuration options expand the Connectivity section.

Click the delete icon for the authorized network 0.0.0.0/0.

Click Save to update the instance.

From Command Line:
Update the authorized network list by dropping off any addresses.

gcloud sql instances patch <INSTANCE_NAME> --authorized-networks=IP_ADDR1,IP_ADDR2...

Prevention:
To prevent new SQL instances from being configured to accept incoming connections from any IP addresses, set up a Restrict Authorized Networks on Cloud SQL instances Organization Policy at: https://console.cloud.google.com/iam-admin/orgpolicies/sql-restrictAuthorizedNetworks.

Default Value:

By default, authorized networks are not configured. Remote connection to Cloud SQL database instance is not possible unless authorized networks are configured."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1A,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | \"Instance: \(.selfLink), Authorized Networks: \(.settings.ipConfiguration.authorizedNetworks[].value)\""
  regex          : "Authorized Networks:"
  not_expect     : "0.0.0.0/0"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "6.7 Ensure That Cloud SQL Database Instances Are Configured With Automated Backups"
  info           : "It is recommended to have all SQL database instances set to enable automated backups.

Rationale:

Backups provide a way to restore a Cloud SQL instance to recover lost data or recover from a problem with that instance. Automated backups need to be set for any instance that contains data that should be protected from loss or damage. This recommendation is applicable for SQL Server, PostgreSql, MySql generation 1 and MySql generation 2 instances.

Impact:

Automated Backups will increase required size of storage and costs associated with it."
  solution       : "From Console:

Go to the Cloud SQL Instances page in the Google Cloud Console by visiting https://console.cloud.google.com/sql/instances.

Select the instance where the backups need to be configured.

Click Edit.

In the Backups section, check 'Enable automated backups', and choose a backup window.

Click Save.

From Command Line:

List all Cloud SQL database instances using the following command:

gcloud sql instances list

Enable Automated backups for every Cloud SQL database instance using the below command:

gcloud sql instances patch <INSTANCE_NAME> --backup-start-time <[HH:MM]>

The backup-start-time parameter is specified in 24-hour time, in the UTC00 time zone, and specifies the start of a 4-hour backup window. Backups can start any time during the backup window.

Default Value:

By default, automated backups are not configured for Cloud SQL instances. Data backup is not possible on any Cloud SQL instance unless Automated Backup is configured."
  reference      : "800-171|3.8.9,800-53|CP-9,800-53|CP-10,CSCv7|10.1,CSCv8|11.2,CSF|PR.IP-4,CSF|RC.RP-1,CSF|RS.RP-1,GDPR|32.1.b,GDPR|32.1.c,HIPAA|164.306(a)(1),HIPAA|164.312(a)(2)(ii),ISO/IEC-27001|A.12.3.1,ITSG-33|CP-9,ITSG-33|CP-10,ITSG-33|CP-10a.,LEVEL|1A,NESA|M5.2.3,NESA|T2.2.4,QCSC-v1|5.2.3,QCSC-v1|10.2.1,QCSC-v1|11.2"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "listSqlInstances"
  json_transform : ".projects[].value.items[] | \"Instance: \(.selfLink), Backup Enabled: \(.settings.backupConfiguration.enabled)\""
  regex          : "Backup Enabled:"
  expect         : "Backup Enabled: true"
  match_all      : YES
</custom_item>

<custom_item>
  type           : REST_API
  description    : "7.1 Ensure That BigQuery Datasets Are Not Anonymously or Publicly Accessible"
  info           : "It is recommended that the IAM policy on BigQuery datasets does not allow anonymous and/or public access.

Rationale:

Granting permissions to allUsers or allAuthenticatedUsers allows anyone to access the dataset. Such access might not be desirable if sensitive data is being stored in the dataset. Therefore, ensure that anonymous and/or public access to a dataset is not allowed.

Impact:

The dataset is not publicly accessible. Explicit modification of IAM privileges would be necessary to make them publicly accessible."
  solution       : "From Console:

Go to BigQuery by visiting: https://console.cloud.google.com/bigquery.

Select the dataset from 'Resources'.

Click SHARING near the right side of the window and select Permissions.

Review each attached role.

Click the delete icon for each member allUsers or allAuthenticatedUsers. On the popup click Remove.

From Command Line:
List the name of all datasets.

bq ls

Retrieve the data set details:

bq show --format=prettyjson PROJECT_ID:DATASET_NAME > PATH_TO_FILE

In the access section of the JSON file, update the dataset information to remove all roles containing allUsers or allAuthenticatedUsers.
Update the dataset:

bq update --source PATH_TO_FILE PROJECT_ID:DATASET_NAME

Prevention:
You can prevent Bigquery dataset from becoming publicly accessible by setting up the Domain restricted sharing organization policy at: https://console.cloud.google.com/iam-admin/orgpolicies/iam-allowedPolicyMemberDomains .

Default Value:

By default, BigQuery datasets are not publicly accessible."
  reference      : "800-171|3.1.1,800-171|3.1.4,800-171|3.1.5,800-171|3.8.1,800-171|3.8.2,800-171|3.8.3,800-53|AC-3,800-53|AC-5,800-53|AC-6,800-53|MP-2,CN-L3|7.1.3.2(b),CN-L3|7.1.3.2(g),CN-L3|8.1.4.2(d),CN-L3|8.1.4.2(f),CN-L3|8.1.4.11(b),CN-L3|8.1.10.2(c),CN-L3|8.1.10.6(a),CN-L3|8.5.3.1,CN-L3|8.5.4.1(a),CSCv7|14.6,CSCv8|3.3,CSF|PR.AC-4,CSF|PR.DS-5,CSF|PR.PT-2,CSF|PR.PT-3,GDPR|32.1.b,HIPAA|164.306(a)(1),HIPAA|164.312(a)(1),ISO/IEC-27001|A.6.1.2,ISO/IEC-27001|A.9.4.1,ISO/IEC-27001|A.9.4.5,ITSG-33|AC-3,ITSG-33|AC-5,ITSG-33|AC-6,ITSG-33|MP-2,ITSG-33|MP-2a.,LEVEL|1M,NESA|T1.3.2,NESA|T1.3.3,NESA|T1.4.1,NESA|T4.2.1,NESA|T5.1.1,NESA|T5.2.2,NESA|T5.4.1,NESA|T5.4.4,NESA|T5.4.5,NESA|T5.5.4,NESA|T5.6.1,NESA|T7.5.2,NESA|T7.5.3,NIAv2|AM1,NIAv2|AM3,NIAv2|AM23f,NIAv2|SS13c,NIAv2|SS15c,NIAv2|SS29,QCSC-v1|3.2,QCSC-v1|5.2.2,QCSC-v1|6.2,QCSC-v1|13.2,SWIFT-CSCv1|5.1,TBA-FIISB|31.1,TBA-FIISB|31.4.2,TBA-FIISB|31.4.3"
  see_also       : "https://workbench.cisecurity.org/files/3817"
  request        : "getBqDataset"
  json_transform : ".projects[].value.datasets[] | .selfLink as $selfLink | .value.access[] | \"Bucket: \($selfLink), Role: \(.role), Special Group: \(.specialGroup)\""
  regex          : "Special Group: (allUsers|allAuthenticatedUsers)"
  not_expect     : "Special Group: (allUsers|allAuthenticatedUsers)"
</custom_item>

</check_type>