GCP Security Framework For FSIs Technical Paper 1677480212

Security
Framework for
Financial Services
Technical paper
Table of contents
Section 1 Executive Summary
Section 2 Financial Services Sector

Overview
2.1 Cloud adoption
2.2 Concerns and challenges
Section 3 Google Cloud as an Enabler for

Transformation
3.1 Shared responsibility model
3.2 Operational resiliency of Google's
infrastructure
Section 4 Reference Framework

4.1 Introduction
4.2 Google Cloud Structure and Hierarchy
4.2.1 Resource Hierarchy
4.2.2 Organization Policies
4.3 Preventative Controls
4.3.1 Identity and Access Management
4.3.1.1 Identity Federation
4.3.1.2 Identity Management
4.3.1.3 Workload Identity Access Control
4.3.1.1 Access Approval
4.3.1.2 Additional Requirements
4.3.2 Network Security
4.3.2.1 Cloud Load Balancing
4.3.2.2 Hierarchical Firewalls
4.3.2.3 VPC Firewalls
4.3.2.4 Shared VPC
4.3.2.5 VPC Service Perimeter
4.3.2.6 Cloud NAT
4.3.2.7 Web Application Firewall and
DDoS Protection
4.3.2.8 Packet Mirroring, IDS, IPS
4.3.2.9 VPC Flow Logs
4.3.3 Service Security
4.3.3.1 Compute Engine
4.3.3.2 Container Engine
4.3.3.3 Cloud Storage
4.3.3.4 BigQuery
Google Cloud Secure Banking Framework 2

Table of contents
Section 4 Reference Framework
4.3.3.5 Dataflow
4.3.4 Security Monitoring
4.3.4.1 File Integrity Monitoring
4.3.4.2 App Vulnerability Management
4.3.4.3 Patch Management
4.3.5 Data Privacy And Protection
4.3.5.1 Data Loss Prevention
4.3.5.2 Encryption
4.3.5.3 Key Management Service
4.4 Detective Controls
4.4.1 Security Command Center
4.4.1.1 Policy Monitoring
4.4.1.2 Threat Detection
4.4.2 Cloud Logging
4.4.3 Security Information and Event Monitoring
4.4.4 Security Analytics
4.4.5 Asset Inventory
Section 5 Appendix
5.1 Variations from the Google Security
Foundations Guide
5.2 Commonly Used Acronyms
Section 6 Bibliography

Table of Figures
Figure 1: Shared Responsibility Model
Figure 2: Components that Comprise Operational Resiliency in Google Cloud
Figure 3: Demonstration - Resource Hierarchy Structure
Figure 4: Banking.com Resource Hierarchy
Figure 5: Project-level Structure
Figure 6: Comprehensive Preventative Reference Framework
Figure 7: Identity and Access Management
Figure 8: Identity Aware Proxy
Figure 9: Access Approval
Figure 10: banking.com Network Architecture
Figure 11: VPC Service Control Perimeter
Figure 12: Cloud NAT
Figure 13: Cloud Armor
Figure 14: GKE Structure
Figure 15: Shielded GKE Nodes
Figure 16: Access with Authorized Views
Figure 17: Cloud DLP
Figure 18: Banking.com Detective Controls
Figure 19: SCC Ingestion and Alerting
Figure 20: ETD and KTD
Figure 21: Cloud Logging Logical Architecture
Figure 22: SIEM Logical Architecture
Table of tables
Table 1: Security Tools and Dependencies
Table 2: Recommended Organization Policies
Table 3: Additional Policy Controls
Table 4: Default IAM Groups
Table 5: Folder Level Group
Table 6: IAM CIS Benchmarks v1.1.0
Table 7: Hierarchical Firewall Policy
Table 8: VPC Firewall Rules
Table 9: Cloud Armor Security Policies
Table 10: Network CIS Benchmarks v1.1.0
Table 11: Recommended Organization Policies for GCE Instances
Table 12: Security Service CIS Benchmarks v1.1.0
Table 13: De-identification Methods
Table 14: Google Default Data at Rest Encryption
Table 15: ETD Default Rules
Table 16: KTD Detectors
Table 17: Logging CIS Benchmarks v1.1.0
Table 18: Variations from Google Foundations
Table 19: Commonly Used Acronyms

Background:
This is a technical whitepaper, joint-published between Accenture
and Google, that describes best practices, general
recommendations, and security considerations that Financial
Institutions should reflect on when using (or looking to migrate to)
Google Cloud. This paper is not an implementation guide and
should not be used as a prescriptive architecture for financial
institutions.
Disclaimer:
This content is provided for general information purposes and is not
intended to be used in place of consultation with our professional
advisors. This document refers to marks owned by third parties. All
such third-party marks are the property of their respective owners.
No sponsorship, endorsement, or approval of this content by the
owners of such marks is intended, expressed, or implied.
The content contained in this document is correct as of January
2023. This technical paper represents the status quo as of the time
it was written. Google Cloud’s products, security policies, and
systems might change going forward as Google continually
improves protection mechanisms.
This reference framework is for informational purposes only.
Accenture does not intend the information or recommendations in
this guide to constitute as definitive configuration advice. Each
organization is responsible for independently evaluating their own
particular use of the services as appropriate to support its legal,
compliance, security, and functional obligations.

Section 1
Executive
Summary

Executive summary 02 03 04 05 06
Executive Summary
The journey to cloud for financial institutions (FIs) starts with the same goal as other industries
transitioning to the cloud: increase developer velocity and scalability while accelerating time to
value for the end customers.
Cloud and virtualization technologies introduce several benefits to banking and financial services
organizations. The adoption of these technologies allows for (but is not limited to):
1 2
Business agility: Increased efficiency and resiliency:

Realized through improved integration Accomplished through near-instant
between application development and deployments of virtualized or
operations (DevOps) teams to effectively containerized systems (as dictated by
identify and correct/iterate on issues. business growth or client engagement).
3 4
Reduced operating costs: Improved security:

Exemplified by the ability to scale cloud Security can be improved by increasing
workloads (elasticity) in response to overall environment visibility, leveraging
business demands. This is contrasted by native cloud security tooling,
the traditional datacenter environment, automating deployments through
where companies deploy mostly under- continuous integration pipelines, and
utilized systems at significantly higher many other ways.
capital expenditure cost.
While the rewards of transitioning to the cloud are appealing, there can be inherent risk – and due
to the sensitive and high-value nature of the data FIs commonly process and exchange, it is critical
that any significant change to the IT infrastructure is secure by design. Aside from the transaction
data itself, individual client data in the form of personally identifiable information (PII) as well as
sensitive and proprietary records must be protected. Moreover, to ensure that strong security
controls are properly configured and privacy by design frameworks are applied – regulatory
bodies mandate numerous requirements, recurring audits, and certifications of compliancy.

Executive summary 02 03 04 05 06
In addition, there are constant threats in the form of cyber-attacks that target cloud
infrastructure and navigating the shared responsibility model can add an extra level of
complexity. The collection of these elements – security control configuration, regulatory
compliancy, protection against cyber-attacks, and navigating the shared responsibility model
– often makes transitioning to the cloud a daunting and tumultuous process for FIs.
One of the most perennial threats to FIs is the exfiltration (or inadvertent exposure) of data to
malicious or unapproved actors or systems. Data exfiltration is a security breach that involves
sensitive, proprietary, or secure information that carries a significant material loss to a
person, system, or organization. Although organizations are generally improving in the area
of detecting unauthorized access attempts, data breaches are ever evolving; the average
total cost of a data breach in 2020 was $3.86 million1 – accentuating the importance of strong
data exfiltration controls in a cloud environment.
An additional concern for FIs is successfully integrating and deploying security monitoring
controls. A 2020 Data Breach Report from IBM indicated that the average time to detect a
network breach is roughly 280 days.2 Without insights into the activity in a cloud environment –
the overall attack surface is vastly expanded.
This technical paper attempts to address the collection of security concerns by providing a
comprehensive preventative and detective reference framework that indicates how FIs can
secure their Google Cloud environment.
The paper begins by providing an overview of the Banking and Financial Services sector and
outlines current trends in the industry. Then, before discussing the reference framework
itself, the paper describes the methodology for producing the reference framework. The
reference framework builds off the December 2022 Google Security Foundations Guide
sample architecture and includes specific considerations that need to be taken for Google
Cloud services that either store or use sensitive data.
Note: The reference framework described in this technical paper is an illustrative reference
framework, not a one-size-fits-all solution on how a Google Cloud environment should be
architected for a FI. This technical paper should not be used as an implementation guide.
Links to implementation guides will be included at the end of each section or subsection when
applicable.

Section 2
Financial Services
Sector Overview

01 Banking and financial services sector overview 03 04 05 06
Financial Services Sector

Overview
In the outmoded model, FIs relied on traditional IT infrastructure and legacy systems to meet
their technological demands. However, an increasing number of banks have been transitioning
to the cloud to meet regulatory demands for increased transparency, to achieve higher capital
requirements, and garner faster growth and higher margins. By shifting to the cloud, companies
are reshaping their operating models, advancing their products and services, and improving the
overall customer experience. To position themselves to remain competitive (and to transition
effectively to the cloud) FIs should perform the following activities:
Transform operating, Address regulatory Embed proper

delivery, and compliance security controls.
governance models to requirements.
include their cloud
landscape.
Establish processes for

Develop a functioning,
security management,
comprehensive reference
including governance &
architecture that
risk management, security
leverages a secure cloud
monitoring, and incident
foundation.
response.
By performing these activities and adopting an enterprise-wide strategy, FIs can reduce
concerns surrounding cloud adoption while successfully leveraging the cloud. Aside from
adoption strategies, it is equally important that security is taken into consideration as early as
possible during the migration process.

To support adoption, Google Cloud offers a range of native security solutions (and
supports compatibility with third party solutions) to help FIs enable better business
outcomes. Cloud native security solutioning helps FIs be:
Fast: Frictionless: Scalable:

With cloud service With security embedded With automation and self-
provider (CSP) native in existing solutions, healing processes applied
accelerators that enable business processes, and to reduce manual steps and
security capabilities and operational teams.
break the resourcing model
controls to be deployed in
minutes or hours, rather to enable organizations to
than months. scale.
Proactive: Cost effective: Compliant with regulatory

With pre-emptive controls Security can be baked-in frameworks:
established to block from the onset to avoid Security blueprints and
accidental or malicious additional costs incurred templates can centralize
security incidents from from adding security in policy definitions while
happening in the first place. the aftermath. driving automated
execution of deployments
in alignment with
compliance requirements.
2.1 Cloud Adoption

With many attractive incentives for cloud, the mass adoption trends are apparent. Recent trends
indicate that cloud adoption rates are steadily increasing. A 2020 study of the financial services
sector found that 91% of respondents are either actively using the cloud or intend to use it in
the next 6 to 9 months,3 which is double the number from the same study from 2015. This large
uptick is a clear indicator of the importance of cloud for FIs. In addition, external factors, such
as the COVID-19 pandemic, accelerated the demand for digital customer-bank interactions and
a work-from-home employee workforce.
When looking at main reasons on why FIs are adopting the cloud, there are a few primary,
influencing factors:
Compute and Data analytics and data Usage of cloud native

Container storage at scale for storing and technologies which
offering burst processing large allows FIs to adopt shift
capacity as needed. amounts of data. left pipelines and
utilize infrastructure as
code.

2.2 Concerns and Challenges

Although many FIs are already using the cloud in some capacity (or intend to in the future),
many may still be apprehensive when it comes to cloud adoption. The most common concerns
include4
• Technical
cyber/security control
gaps.
• Loss of reputation from

data loss or exfiltration.
• Contractual concerns with

the cloud provider.
• Meeting regulatory
compliance.
• Data privacy concerns.
• Unmet requirements from

internal compliance
functions.
These concerns draw the question: If business demand and adoption rates for cloud are
rapidly increasing, but there are looming security and compliance concerns – how can FIs
securely and confidently migrate to the cloud? Section 3 describes how Google Cloud’s
infrastructure is an effective enabler for cloud migration, and Section 4 describes how to
effectively configure a Google Cloud environment in a secure default state using a
preventative and detective architecture.

Section 3
Google Cloud as
an Enabler for
Transformation

01 02 Google Cloud as an Enabler for Transformation 04 05 06
Google Cloud as an Enabler for

Transformation
Public cloud providers offer companies the ability to scale their capabilities compared to the
traditional on-premise model. Moreover, public clouds offer increased security, centralized
management, and a large variety of on-demand services and resources.
With Google Cloud, the catalog of offerings continues to rapidly grow, and each Google Cloud
service exposes a wide range of customizable configurations and controls that enables
business and security needs. Google embeds best practices in its cloud platform that provides
FIs with a presence of mind when adopting the cloud; FIs can be assured that they are
building on top of a reliable, secured foundation and either optimize the controls or take
advantage of additional service-specific security guidance.
3.1 Shared Responsibility Model

Conventionally, security in public clouds differs intrinsically from customer-owned on-
premises infrastructure. Public clouds provide a delineation of shared responsibility between
the customer and the cloud provider, where customer-owned infrastructure is all self-
managed.
Google Cloud’s product and service offerings range from classic platform as a service (PaaS),
to infrastructure as a service (IaaS), to software as a service (SaaS). At large, the boundaries of
responsibility between the company and the cloud provider change based on the services that
have been selected by the customer.
At a minimum, as a part of their shared responsibility for security, public cloud providers
should enable companies to start with a solid, secured foundation. Providers should
empower customers and make it easy for them to understand and execute their part of the
shared responsibility model. With Google Cloud, there are opportunities for organizations
to have a closer collaboration with Google to address security and risk. Google promotes
shared fate for risk management in the cloud by providing unique tools, detailed
guidance, and best practices to reduce customer risk from day one. Google also has a risk
protection program that can be read about further in the Announcing the Risk Protection
Program: Moving from shared responsibility to shared fate document.

As a cloud provider, the security responsibilities of Google and the security responsibilities of the
FI must be clearly defined. The three types of as-a-service platforms are shown in Figure 1 below.
This model identifies the areas of responsibility of FIs leveraging Google Cloud in IaaS, PaaS, and
SaaS deployments.
Content
Access Policies
Usage
Deployment
Web Application Security
Identity
Operations
Access and Authentication
Network Security
Guest OS, Data & content
Audit Logging
Networking
Storage & Encryption
Hardened Kernel & IPC
Boot
Hardware
ON-PREM IAAS PAAS SAAS

Cloud Provider Responsibility Customer Responsibility
Figure 1: Shared Responsibility Model5
As depicted, there are clear incentives to use the offerings on the cloud as opposed to on-
premises. For IaaS, PaaS, and SaaS deployments – as the responsibility decreases so too does
the overhead cost. The clear delineation also helps companies understand what they are
responsible for and enables a more seamless transition to the cloud.
3.2 Operational Resiliency of

Google’s Infrastructure
Cloud Service Providers (CSPs) work hard to secure their infrastructure and upgrade their
native security features. They innovate to create and release new services at an increasingly
rapid pace.
Google Cloud boasts operational resiliency in its hardware and infrastructure. Operational
resiliency can be defined as the “ability to deliver operations, including critical operations and
core business lines, through a disruption from any hazard.”6

By adopting Google Cloud, financial services firms can strengthen their operational resilience
and address risks in new ways, for two key reasons:7
1. Google Cloud's infrastructure

and operating model is of a
scale and robustness that is
largely commercially and
technically unachievable by
financial service firms.8
2. Google Cloud offers a wide

array of differentiated solutions
and capabilities.
The areas of operational resiliency span across several components. These are depicted in
Figure 2, along with a few bullets that explain how Google Cloud ensures operational resiliency
within these components.
Secure Infrastructure Secure Internet COMMS

• Hardware design and provenance • Google front end service
• Service access management (connection certificates)
• Vendor audits • Multi-layers DoS protections
Secure Services Third Party Risks

• Designed for multi-tenancy • Multi-cloud strategy (creating cloud
• Service identity capabilities within Google´s own
• AuthN (ALTS) and AuthZ datacenters)
Secure Data Pandemics

• Encryption at rest and in transit • Remote access capabilities (Cloud
• KMS and HSM VPN, BeyondCorp, etc.)
• Confidential computing • Cloud Elasticity)
Figure 2: Components that Comprise Operational Resiliency in Google Cloud
For more information on the security of Google Cloud’s infrastructure, refer to the Infrastructure
design for availability and resilience whitepaper.
Section 4 will now delve into the recommended reference framework that can be used for FIs to
confidently migrate to Google Cloud.

Section 4
Reference
Framework

01 02 03 Reference Framework 05 06
Reference Framework
4.1 Introduction
A reference framework is integral for ensuring a cloud environment is properly configured,
governed, and functioning. Since FIs often store sensitive data, this reference framework splits
the Google Cloud environment into two portions: restricted (e.g., customer PII, records,
transaction data, payment card information, etc.) and base. By delineating between the two,
FIs can use the reference framework to determine the level of controls that need to be applied
based on the type of data they are storing or using in their Google Cloud environment.
This technical paper uses banking.com as the sample enterprise that will be referred to through
the remainder of the document for explanatory architectural examples. banking.com is used as
a fictional, demonstrative example, and is not intended to refer to any actual business or entity.
The paper will build off the December 2022 Google Security Foundations Guide sample
architecture and include specific considerations that need to be taken for Google Cloud
services that either store or use the sensitive data. The document will also briefly discuss third
party tooling. For a comparative analysis of the components in the Google Security
Foundations Guide vs. this paper, refer to Appendix Section 5.1
Note: The Google Cloud services covered in this technical paper include Google Compute
Engine, Kubernetes Engine, Cloud Storage, BigQuery, and Cloud Dataflow. The services are
explicitly covered in Section 4.3.3, but the security implications (and the underlying,
foundational components that enable the services) are discussed throughout the entirety of
Section 4. No additional services beyond these are discussed.
To prepare the reference framework, a defense in depth strategy was leveraged. Defense in
depth focuses on comprehensively securing the infrastructure, protecting the data, and
protecting access. It involves the application of multiple countermeasures in a layered or
stepwise manner to achieve security objectives. The methodology involves layering
heterogeneous security technologies in the common attack vectors to ensure that attacks
missed by one technology are caught by another.9 The defense in depth approach includes
(and delineates between) preventative and detective controls to ensure security in the FI’s
Google Cloud environment.
• Preventative controls (Section

4.3) are based on how the
environment is structured, which
security controls are
implemented, and how these
security controls are configured.
• Detective controls (Section 4.4)

are defined as the capabilities that
monitor the activity in the
environment – which protect
against malicious, suspicious, or
anomalous behavior.

Although the Resource Hierarchy and Organization Policies meet the definition of preventative
controls, they discussed separately in Section 4.2.2. These are separated from the other
preventative controls since the Resource Hierarchy and Organizational Policies are the
beginning foundational components when configuring and architecting a Google Cloud
environment and will need to be enabled upon instantiation.
Important: This technical paper is an illustrative reference framework, not a one-size-fits-all

solution on how a Google Cloud environment should be architected for an FI. This technical
paper should not be used as an implementation guide. Links to implementation guides will be
included where relevant.
Note: Many components of a Google Cloud environment will differ depending on the FI and the
FI’s purpose for using Google Cloud. The differences can include elements such as: the current
IT landscape, use of legacy technology, pre-existing cloud environments (i.e., hybrid cloud,
multi-cloud, only on-prem, etc.), and many others. These differences are not only dependencies,
but also driving factors that shape how an FI should effectively adopt cloud usage on Google
Cloud. For discussions on addressing cloud adoption dependencies and planning a migration to
Google Cloud, please refer to the Contact Us section in Appendix Section 5.3.
The following tools are leveraged to secure the banking.com environment.
SECURITY AREA CAPABILITY TOOL LEVERAGED NOTES
Policy and Google Cloud Native

Resource Hierarchy Identity None
Governance Resource Hierarchy
Google Cloud Native

Organization Policies Security Constraints None
Organization Policies
banking.com uses AD,

Google Cloud Directory but the section
Identity Federation Sync (GCDS) with includes links to
Active Directory (AD) information for other,
external IdPs as well
Google Cloud Identity Groups are used for

Identity and Access Identity Management and Access assigning Cloud IAM
Management Management (IAM) roles
Access Control Google Cloud IAM None
Identity Aware
Application Requests None
Proxy/BeyondCorp
Single Sign-On Google Cloud SSO None

Sensitive folders have

Org and Folder different
Firewalls Hierarchical Firewalls
recommended firewall
rules
Sensitive projects have

Project-specific Virtual Private Cloud different
Firewalls (VPC) Firewalls recommended firewall
rules
Virtual Private Cloud

Data Access and
Service Controls (VPC- None
Exfiltration Control
SC)
Network Security Internet Traffic Security Cloud NAT None
Web Application
Cloud Armor None
Firewall
Google Personnel
Access Approvals None
Access Control
Access Auditing Access Transparency None
Depends on the Depends on the Depends on the

Service
Security Service, refer to the Service, refer to the Service, refer to the
corresponding section corresponding section corresponding section
Depends on the
File Integrity
Monitoring Service, refer to the None
section
Security Monitoring Security Command

Center (SCC) Premium
Vulnerability – Security Health
None
Management Analytics (SHA), Web
Security Scanner, and
Endpoint Agents
Data Loss Prevention Cloud DLP None
Data Privacy and

Protection
Encryption at Rest Encrypted by default None

Data in transit
encryption is used to
protect data that is
travelling externally.
Encryption in Transit Encrypted by default
Data movement within
Google is generally
Data Privacy and
Protection authenticated but not
encrypted
Key Management
Cloud KMS None
Service
Encryption Key Customer Managed
None
Management Encryption Keys (CMEK)
Security Command
Pane of Glass Visibility A SIEM is also used
Center (SCC)
Security Command
Center Premium –
Policy Monitoring None
Security Health
Security Command Analytics (SHA)
Center
Security Command
Center Premium –
Threat Detection Event Threat Detection None
(ETD) and Container
Threat Detection (KTD)
Log Ingestion Cloud Logging API None
Log Aggregation Cloud Logging Router None

Cloud Logging
Processing Logs Log Sink, Logs Viewer None
Log Storage and Cloud Storage,

None
Analytics BigQuery
Security Information Security Information

Splunk, ArcSight,
and Event and Event None
LogRhythm, etc.
Management Management (SIEM)
Threat Intelligence Security Analytics Chronicle, Anomali, etc. None
Asset Inventory Asset Inventory Cloud Asset Inventory None
Table 1: Security Tools and Dependencies

4.2 Google Cloud Structure and Hierarchy

When developing a secure framework, it is important to take into consideration the foundational
components of the architecture. As mentioned in Section 4, this technical paper will build off
the December 2022 Google Security Foundations Guide sample architecture and will use
banking.com (instead of example.com) as the sample enterprise for explanatory architectural
examples and diagrams. The banking.com reference architecture described in this document
assumes the same key architectural dependencies for the Organization Structure from Section
4.2.2 in the December 2022 Google Security Foundations Guide, including:
1. A single organization is
used for all environments
and services for
banking.com to manage all
resources and policies in
one place.
2. The folder hierarchy has a single

layer, consisting of bootstrap,
common, production, non-
production, and development
folders to allow for segregation of
policies, privileges, and access.
3. Google Cloud organization

policies are used to augment
the organization's security
posture by allowing FIs to
define resource configuration
constraints that apply
consistently across all projects.
Note: The folder structure can vary depending on the FIs usage of Google Cloud. The areas of
variation will be discussed in Section 4.2.1.
The next two subsections will focus on the resource hierarchy and organizational structure of
the banking.com Google Cloud environment.
4.2.1 Resource Hierarchy

The purpose of the resource hierarchy is to enforce policy and identity governance and to also
provide default zero-trust network segmentation between projects throughout the Google
Cloud environment. By creating a hierarchy of ownership, organizations can set access control
policies, configuration settings, and identity and access management (IAM) settings on
resources.

The banking.com resource hierarchy is comprised of several components, including an

organization node, folders, projects, and resources. Each of these components has a different
function:
1. Organization 2. Folders: Folders are used 3. Projects: Projects are the

node: The as a method of base-level organizing
organization node separating projects into entity. Folders can contain
provides a related groups. Folders multiple projects. A project
resource hierarchy can contain additional is the basis for using
that establishes folders, called nested Google Cloud services. By
structure for folders. Nested folders default – zero trust for IAM,
ownership, can be used to isolate access controls, and
policies, and requirements, networking are enforced
access control. permissions, and between projects.
resources for different
departments and teams.
It is important to note that policies are inherited downwards in the resource hierarchy. For
example, in Figure 3 below, a policy in the Top-Level Folder (TLF) will apply to its underlying
folders and then to the projects. This applies for IAM roles, IAM permissions, and organization
policies.
Important: If you set a new policy lower in the hierarchy, it will override the parent. Essentially,
policies are inherited downwards unless you choose to override it with a new policy further
down the hierarchy.
Google Cloud Platform
• IAM users
• IAM role bindings Org Node
• Organization policies
Inherited
downwards
• IAM users Prod Non-prod Dev

• IAM role bindings Environment Folder Environment Folder Environment Folder
Inherited
downwards
• IAM users
• IAM role bindings Product A Product B
• Organization policies Nested Folder Nested Folder
Inherited
downwards
• IAM users
Shared VPC Host Secrets
• IAM role bindings
Project Project
Application Project
Service Project
Figure 3: Demonstration - Resource Hierarchy Structure

The resource hierarchy structure is ultimately dependent on several factors, including (but not
limited to):
1. The organization 2. The number of 3. Types of 4. The sensitivity

that is leveraging internal teams who workloads being of the
Google Cloud. will be using Google deployed. workloads.
Cloud.
Note: Since the structure of the resource hierarchy will vary from organization to organization,
there is no singular recommended structure. In general, folders should be leveraged to isolate
resources for different departments and teams while projects should be segmented based on
the purpose of the project. Projects should also have one project per application per
environment. Ultimately, however, the ideal resource hierarchy structure will depend on the
organizations requirements and may even change over time.
Note: This technical paper will not cover CICD or resource deployment, and as such, a separate
bootstrap folder that hosts the CICD pipeline is not included in the figure below.
The banking.com resource hierarchy is depicted in Figure 4. Note that each of the environment
folders contain both base and restricted projects. The base project hosts non-sensitive data,
whereas the restricted project contains data, such as PII, that needs additional security
controls.
banking.com
Org Node
Prod Non-prod Dev

Environment Folder Environment Folder Environment Folder Common
Logging
Base Shared VPC Host Base Shared VPC Host Base Shared VPC Host
Cloud Log Sink
Prod spoke project Non-prod spoke project Dev spoke project
Service project(s) Service project(s) Service project(s) Security Command Center

Attached to host Attached to host Attached to host Notifications
Billing
Restricted Shared VPC Host Restricted Shared VPC Host Restricted Shared VPC Host
BigQuery dataset with exports
Prod spoke project Non-prod spoke project Dev spoke project
Base Network Hub

Service project(s) Service project(s) Service project(s)
NVAs for E/W, peered to base
Attached to host Attached to host Attached to host
spokes
Secrets Secrets Secrets Restricted Network Hub

Folder level secrets Folder level secrets Folder level secrets NVAs for E/W, peered to restricted
spokes
Interconnect
Interconnect management
Secrets
Org level secrets
DNS Hub
DNS resolution
Figure 4: Banking.com Resource Hierarchy
Note: There are no underlying folders below the Top-Level Folders (TLFs) in this architecture. As
mentioned above, underlying folders may need to be leveraged by FIs depending on the needs
of their Google Cloud environment. For example, a FI with three business entities that all need
separate dev, prod, and non-prod environments could have a folder structure where an entity
folder is the TLF, and each entity folder contains their own environment folders.

Though policies and IAM bindings are inherited downwards in the resource hierarchy, security
controls are often applied at the project level. Figure 5, below, provides a more granular view of
project level security controls.
Internet
Project
Org IAM Service

Policies Bindings Accounts
Project
VPC Network
VPC Network
VPC FW Cloud
Rules DNS Reg ion 1
Subn et
Reg ion 1 Unauthorized Proj ect
Cloud
NAT GCE GCE
10 .2 40.0 .4 10 .2 40.0 .5
Subn et Cloud
Storage a.b.c.d/x
GCE GCE
10 .2 40.0 .2 10 .2 40.0 .3
BigQuery
a.b.c.d/x
Public APIs
VPC Service Controls
Figure 5: Project-level Structure
At the project and resource level, controls and native services such as VPC Service Controls,
firewall rules, Cloud NAT, network tagging, project-level IAM bindings, service accounts, and
others work to protect FIs infrastructure, applications, and services. In this regard, the project
boundary can be thought of as a trust boundary for resources. Each of these aforementioned
controls and services will be discussed in further detail in their respective sections.
4.2.2 – Organization Policies

Organization policy constraints provide control over the organization’s cloud resources. These
constraints create guardrails that ensure teams do not violate compliance requirements. In this
regard, it is helpful to think of organization policy constraints as a set of configuration
restrictions in the organization.
For FIs, organization policies are important controls for securing the overall Google Cloud
environment. Most of the organization policies applied to banking.com are set at the org level,
however there are some org policies that apply exclusively to projects hosting sensitive data.
For FIs this could be data containing personally identifiable information (PII) or payment card
information (PCI). In the banking.com reference architecture, this applies to the Restricted
Projects. These project specific policies are called out in the Recommended Value column of
Table 2, which outlines the recommended organization policy that should be included in the
banking.com environment.

ORG POLICY DESCRIPTION RECOMMENDED VALUE
This list constraint defines the set of

gcp.resourceLocations locations where location-based restrict to regions of operation
Google Cloud resources can be
created.
This boolean constraint disables

compute.disableNested hardware-accelerated nested
Virtualization true
virtualization for all Compute Engine
VMs.
compute.disableSerial This boolean constraint disables serial true

PortAccess port access to Compute Engine VMs.

compute.disableGuestA Compute Engine API access to the
ttributesAccess true
Guest Attributes of Compute Engine
VMs.

compute.vmExternalIp Compute Engine VM instances that
Access are allowed to use external IP deny all=true
addresses.
This boolean constraint skips the

creation of the default network and
compute.skipDefault
NetworkCreation related resources during Google true
Cloud Platform Project resource
creation.

Compute.restrictLoadBalan load balancer types which can be internal only for sensitive
cerCreationForTypes created for an organization, folder, or projects or folders
project.
This boolean constraint restricts the

compute.restrictXpn set of users that can remove a Shared
ProjectLienRemoval true
VPC project lien without organization-
level permission.
This boolean constraint requires that

all new Compute Engine VM instances
compute.requireShieldedVm use Shielded disk images with Secure true for sensitive projects or
Boot and Integrity Monitoring options folders
enabled.
sql.restrictPublicIp This boolean constraint restricts true

configuring Public IP on Cloud SQL
instances.

This boolean constraint restricts

sql.restrictAuthorized adding Authorized Networks for
Networks true
unproxied database access to Cloud
SQL instances.
iam.allowedPolicy This list constraint defines the set of

MemberDomains members that can be added to Cloud your-cloud-identity-id
IAM policies.
This boolean constraint disables the

iam.disableService Acc creation of service account external true
ountKeyCreation keys.
Identity Providers that can be restrict to your org’s identity

iam.workloadIdentityPoolPro configured for workload
viders provider (unless external
authentication within Cloud IAM, providers need access)
specified by URI/URLs.
This boolean constraint, when true,

prevents the default App Engine and
iam.automaticIamGrant Compute Engine service accounts
sForDefaultServiceAcc that are created in your projects from true
ounts being automatically granted any IAM
role on the project when the accounts
are created.
This boolean constraint requires

storage.uniformBucket buckets to use uniform bucket-level true
LevelAccess access.
This list constraint defines the set of Restrict to intra folder peering
VPC networks that are allowed to be (unless resources need to
compute.restrictVpcPeering peered with the VPC networks communicate in different
belonging to this project, folder, or folders)
organization.
This list constraint defines the set of It is recommended that this

compute.trustedImage projects that can be used for image constraint is set to true for
Projects storage and disk instantiation for sensitive projects that use
Compute Engine. public images.
This is recommended for FIs

This list constraint restricts the set of that need a governance review
Restrict allowed Google services and their APIs that can be and approval process before
Cloud APIs and services enabled on this resource. By default, specific Google Cloud services
all services are allowed. can be used by their
developers.
Table 2: Recommended Organization Policies

In addition to the Organization Policy constraints from the December 2022 Google Security
Foundations Guide, banking.com includes 7 additional organization policies, some of which
only apply to sensitive folders or projects:
1. gcp.resourceLocations: Restricting 2. compute.requireShieldedVm:

resources to the regions of operations Setting this org policy to true ensures
ensures that FIs do not create unnecessary that VMs are instantiated as Shielded
resources and increase spending. VMs which enables Secure Boot.
3. compute.restrictLoadBalancerCreation 4. sql.restrictAuthorizedNetworks: Cloud

ForTypes: Restricting the ability to SQL instances can use CloudSQL proxy
create external load balancers removes for access. Adding an authorized
the possibility of broadly exposing the network can allow a user to bypass the
load balancer to exploitable networks. proxy so long as their traffic is
Setting the constraint to internal only originating from the authorized network.
ensures that external connectivity is
acknowledged for sensitive workloads
when receiving an exemption from the
org policy on a project.
5. iam.workloadIdentityPoolProviders: 6. compute.restrictVpcPeering: To control

Without this org constraint, third which network traffic can cross security
party cloud service identities can boundaries, it is recommended that this
exchange credentials for Google org policy be set to intra folder peering
Cloud service account credentials. (unless resources in a project need to
This should be restricted to the FI’s communicate with a different folder).
identity provider (unless external
providers need access).
7. compute.trustedImageProjects: By
default, instances can be created from
images in any project that shares images
publicly or explicitly with the user. This
creates a allow/deny list of publisher
projects that can be pulled from. Ensuring
that the images are trusted and secure.

In addition to the Organization Policy constraints, the December 2022 Google Security
Foundations Guide includes a section of additional policy controls. It is recommended that
these controls are applied to tighten the FIs cloud security posture. The controls are listed in
Table 3 below.
CONTROL DESCRIPTION MANAGEMENT
Limit session and You can change the session timeout for Google Google Workspace or Cloud
gcloud timeouts Cloud sessions (including the gcloud tool) to Identity Admin Console
durations as low as 1 hour.
Disable Cloud- Google Cloud provides a native Cloud Shell

interface for working with the cloud environment. Admin Console
Shell
You can disable this shell.
You can enable phishing-resistant security keys as Google Workspace or Cloud

a second-factor authentication (2FA) method that Identity Admin Console. If
helps provide protection against automated bots, you're federating identities
Use phishing bulk phishing, and targeted attacks. The keys use from an external system, you
resistant security public key cryptography to verify a user’s identity, might need to configure this in
keys and they use the URL of the login page to help your identity provider or add
make sure that an attacker can’t access a user an additional layer of
account even if the user is tricked into providing a protection on top of your
username and password. existing SSO settings directly
within Cloud Identity.
Access transparency provides you with logs that

Enable access capture the actions that Google personnel take
transparency Contact Google Cloud
when accessing your content. You must be on Support
Gold, Platinum, Enterprise, or Premium support
plans.
Access approval enables you to explicitly approve

Enable access access to your data or configurations on Google Google Cloud Console
approval Cloud before Google Cloud support or
engineering can access the data.
Table 3: Additional Policy Controls
4.3 Preventative Controls

Preventative controls are based on how the environment is structured, which security controls
are implemented, and how the security controls are configured. Preventative controls comprise
a large portion of the security foundation of the banking.com environment.
By integrating proper security controls, FIs can minimize the threat landscape and mitigate the
number of threat vectors.
The preventative controls for banking.com are grouped together and discussed based on their
capabilities. The groupings consist of Identity and Access Management, Network Security,
Service Security, Security Monitoring, and Data Privacy and Protection. Each section will
describe the importance of implementing its respective controls to reduce the overall attack
surface. The sections will also provide links to implementation guides where applicable.

Figure 6 depicts a high-level overview of the comprehensive preventative reference framework

for banking.com. The legend at the top center of the diagram provides details on each of the
arrows and icons.
Note: The services inside of each of the projects in Figure 6 are intentionally trivial. The services
are only included for demonstration, and Section 4.3.3 will delineate between controls for
sensitive vs. non-sensitive projects on a service-by-service level.
On-prem Legend Identity Process

On-prem ingress Internet ingress
DC1
DC1 VPC Peering Secure services
External
On-prem Router DNS Server Outbound

Link local address: banking.com
forwarding VPC Service
e.g., 169.254.10.2
Controls AD Domain AD FS
Inbound User
forwarding banking.com banking.com
Cloud DLP
DNS Peering
Queries for gcp.banking.com

DNS forwarding policy that
Colo Facility 1 Colo Facility 2
enables inbound forwarding Internet
Peering Peering GCDS
Edge Edge Queries for banking.com
DNS forwarding zone

Common Folder
Authentication
Cloud Identity
banking.com
Base Hub Res trict ed Hub DNS Project Billing Project Untrusted
DNS VPC
Base Hub VPC Res trict ed Hub VPC Untrusted VPC
BigQuery Groups
Reg ion Reg ion Exports Reg ion
Private zone:
Common Folder Projcets
“gcp.banking.com.”
Zone Zone Zone
Users
Subnet Subnet Subnet
Authentication
Interconnect Project
Cloud Cloud HTTP(S)
VLAN VLAN WAF Single Sign-on
Router Router DNS Peering LB
Dedicated to
shown for a single
purchasing &
a.b.c.d/24 a.b.c.d/24 project, but a.b.c.d/24
managing
peering would be
interconnect Security Key
established across
connections
all host project’s
private zones
Identity Aware
Proxy
Entity Folder Authorization
Dev Fold er Prod Folder Non-prod Folder
Dev VPC Hos t Res trict ed Dev VPC Prod VPC Host Res trict ed Prod VPC Non-prod VPC Host Res trict ed Non-prod
Cloud Cloud Cloud
Project Hos t Project Project Hos t Project Project VPC Host Project
Identity Identity
VPC Host Projects
Identity
Priv ate Priv ate Priv ate Priv ate Priv ate Priv ate
zone: “.” zone: “.” zone: “.” zone: “.” zone: “.” zone: “.”
Fol der Level Fol der Level Fol der Level

Secr ets Secr ets Secr ets
Shared VPC Shared VPC Shared VPC Shared VPC Shared VPC Shared VPC
Host Host Host Host Host Host
Subnet 1 Subnet 2 Subnet 1 Subnet 2 Subnet 1 Subnet 2 Subnet 1 Subnet 2 Subnet 1 Subnet 1 Subnet 2
a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x
Service Projects
Cloud DLP Da taflow Cloud Storage
Compute Ap plication Compute Ap plication Compute Ap plication Compute Ap plication Compute Ap plication
Project Project Project Project Project Project Project Project Project Project
Cloud KMS BigQuer y Other Stora ge
DLP Project
Figure 6: Comprehensive Preventative Reference Framework
Each of the controls and infrastructure components that are depicted in Figure 6 will be discussed
in the subsequent sections, along with additional information on how they function. This figure is
not prescriptive, but rather shows preventative control elements that contribute to securing a
Google Cloud environment.
4.3.1 Identity and Access Management

Identity and Access Management (IAM) is a framework of policies and technologies for ensuring
that the only proper individuals in an enterprise have appropriate access and privileges to
resources and objects inside of Google Cloud. By leveraging frameworks and technologies to
perform IAM functions – banking.com can effectively organize and manage users and resources
while maintaining oversight of changes to the environment. Having proper IAM procedures and
technologies is integral for safeguarding information and assets from improper access.

IAM attacks can take several forms. In the cloud, some prominent attacks target administrators
and developers. Others involve escalating privileges to the management plane. The Capital
One breach in 2019 involved several components in a cyber kill chain process – one of which
was receiving IAM role access to a storage service in cloud.10 For this reason, it is imperative
that banking.com follows the principle of least privilege, properly uses Cloud Identity, and
leverages multi-factor authentication (MFA) so users only have the amount of access required
to perform their job.
When considering IAM, there are three central components: Identity federation, identity
management, and zero trust. These components are depicted in Figure 7 below and will be
discussed in further detail in the subsequent sections.
On-Prem
External
User AD Domain AD FS
banking.com banking.com
GCDS
Authentication
Cloud Identity
banking.com
Example project
Groups IAM Bindings

Users
IAM
Authentication
Permissions
Authorization
Single Sign-on
Resource
Security Key
Identity Aware
Proxy
Figure 7: Identity and Access Management11
4.3.1.1 Identity Federation

Google Cloud uses Google identities for authentication and access management. However,
maintaining a separate Google identity can introduce unnecessary complications and
management overhead for employees. Identity federation is the recommended solution to
address this. By federating the identities between Google Cloud and the FI’s current identity
management system – on-premises identities and Google identities are automatically associated
with one another. The banking.com architecture uses Active Directory as its on- prem Identity
Provider, but there are Google guides and best practices for other Identity Providers as well
(such as Azure AD).
Federation involves two components: provisioning users in AD and enabling single sign-on (SSO).
When a group or user is created or deleted in AD, there is a synchronization that occurs in Google
Cloud; all provisioning occurs in AD and all credentials are managed in AD as well. The
authentication process for SSO is delegated to AD using the Security Assertion Markup Language
(SAML) protocol. This ensures that all requirements, policies, and authentication processes (e.g.,
MFA) are being enforced for SSO.

An additional recommendation is to enforce log-in challenges for users in the organization.

Many third-party identity providers authenticate users using SSO through SAML. If the
organization is unable to support MFA, consider enabling post-SSO verification. A policy can be
set to enforce additional risk-based authentication challenges and Google 2-Step Verification
during sign-in. With the policy in place, after the SAML assertion is returned from on-prem,
Google will perform an additional check of the validity of a security key associated with the
account attempting to sign-in. The security key is a physical key that can be used to protect your
account during sign-in by making second factor hardware phishing extremely difficult.
To implement identity federation, the FI can use Google Cloud Directory Sync (GCDS) or Active
Directory Federation Services (AD FS). To run a successful synchronization with GCDS, it is
recommended that the FI follow the Google suggested best practices.
In addition to following the GCDS best practices, it is vital to have proper mapping between the
AD environment and the Google Cloud environment. Although the structures of AD and Google
Cloud are like one another, since the structure of the AD environment will vary from organization
to organization, there is no singular recommended structure in Google Cloud.
Instead, the FI should review their existing AD structure (i.e., forests, domains, organizational
units, groups, and users) and perform a mapping exercise to determine which architectural
pattern best fits the company’s requirements. Other recommendations from Section 4.2.1 apply
as well, such as segmenting different departments and teams in the resource hierarchy from
one another.
Note: “During initial setup, the Directory Sync process must be authenticated interactively
using a 3-legged OAuth workflow. [It is] strongly recommend that [the FI] create a dedicated
account for this sync, as opposed to using an employee's admin account, because the sync will
fail if the account performing the sync no longer exists or doesn't have proper privileges.”12
4.3.1.2 – Identity Management

Since identities will be federated through Active Directory using GCDS (as outlined in Section
4.3.1.1), the same identities will be used across all federated systems. To control which users are
synced to Cloud Identity, an attribute is added to the users in AD, and GCDS filters on that
attribute. Like the structure of AD, users are not directly assigned roles and permissions.
Instead, groups are assigned roles and permissions, and users are added to the groups. Group
membership is propagated through AD. The same policies and practices for Identity
Management apply to both the sensitive and non-sensitive projects in the banking.com
architecture.
A user’s access should only be limited to the level needed to accomplish their specific job or
task. If a user needs additional privileges, that user’s access would need to be strictly
controlled and monitored. As much as possible, primitive (or legacy) roles should be avoided
(i.e., roles/owner, roles/editor, and roles/viewer). The legacy roles are overly permissive, and
their usage is not recommended. Instead, users should use predefined roles or custom roles
for more granular access. These roles would be bound to groups in the banking.com
architecture, so it is important to segment groups as much as possible.

The December 2022 Google Security Foundations Guide includes a list of groups that are
created by default in their banking.com foundation – noting that additional groups should be
configured on an as-needed workload-by-workload basis. These are listed in Table 4.
Note: These groups follow the naming conventions that are also outlined in the Google
Security Foundations Guide.
GROUP DESCRIPTION ROLES SCOPE
Org for Billing

Members are authorized to view Billing Account Account Viewer
grp-gcp-billing- the spend on projects. Typical Viewer BigQuery Billing Project for
viewer@banking.com members are part of the finance Data Viewer BigQuery
team. BigQuery User Data Viewer and
BigQuery User
Members can view resource

grp-gcp-platform- information across the Google Viewer Org
viewer@banking.com Cloud organization.
Members are part of the security

grp-gcp-security-re Security Reviewer Org
team responsible for reviewing
viewer@banking.com
cloud security.
grp-gcp-network- Members are part of the

Compute Network Org
viewer@banking.com networking team and review
Viewer
network configurations.
Members are part of an audit team Logs Viewer
grp-gcp-audit- Private Logs
and view audit logs in the logging Logging Project
viewer@banking.com Viewer BigQuery
project.
Data Viewer
grp-gcp-scc- Members can administer Security Center

SCC Project
admin@banking.com Security Command Center. Admin Editor
Global secrets
project
Members are responsible for Secret Manager
grp-gcp-secrets- Prod secrets
putting secrets into Secrets Admin
admin@banking.com Non-Prod
Manager.
projects Dev
Projects
grp-gcp-
businesscode- Groups are created on a per- Service- and
environment- business code or per-environment project-specific Specified Service
codedeveloper@ basis to manage resources within a permissions
banking.com particular project.
Members are responsible for

grp-gcp-platform-
platform operations, and they are N/A N/A
operator@banking.
added into other groups and inherit
com
those permissions.
Members are assigned at the Image User

grp-gcp-image- project level for projects that
user@banking.com contain images that should be Instance Admin Project
shared with other projects Storage Admin
Table 4: Default IAM Groups13

In addition to these, this technical paper recommends that groups that are assigned ownership
to folders in banking.com be given the following baseline roles from Table 5.
Note: This list is non-exhaustive, and deviations may be appropriate depending on the
purpose of the folder and the needs of the folder owners.
GROUP DESCRIPTION ROLES SCOPE
Members should be comprised of Project IAM

grp-gcp-folder- the individuals that should have Admin Top Level or
Project Creator Underlying
owner@banking.com effective management over the Project Deleter folders
projects in the folders. Browser
Table 5: Folder Level Group
Google also has a Policy Intelligence suite that helps enterprises understand and manage their
policies to reduce their risk. Policy Intelligence has a collection of features that provide visibility
and automation in the cloud environment. These features include:
1.Policy Analyzer: 2.Policy Simulator: 3.Recommender: 4.Policy

Policy Analyzer Policy Simulator IAM Recommender Troubleshooter:
analyzes which lets you see how helps FIs enforce Policy
identities, or an IAM policy the principle of least Troubleshooter
principals (users, change might privilege by makes it easier to
service accounts, impact a member's continuously understand why a
groups, and access before you providing a clear user has access to
domains) have what commit to making view of over-scoped a resource or
access to which the change. and unused roles doesn't have
Google Cloud and permissions permission to call
resources. based on a sliding an API.
90-day window.
The Policy Intelligence suite improves security by increasing visibility of the cloud environment
while also making governance and risk management processes easier and more efficient. For
example, the FI could use the Policy Analyzer to audit groups and monitor IAM bindings.
Note: Any administrative operations or privileged identities should have their roles and
permissions monitored for access very carefully.
4.3.1.3 Workload Identity Access Control

To further secure the Google Cloud landscape, Identity Aware Proxy should be leveraged to
enforce access control policies for applications and resources for HTTP requests coming from
the Internet. When an application or resource is protected by IAP, it can only be accessed
through the proxy by by members, also known as users, who have the correct Identity and
Access Management (IAM) role. When a user tries to access an IAP-secured resource, IAP
performs authentication and authorization checks. In addition to IAP, there are network security
controls (load balancers, firewalls, etc.), that will be discussed in Section 4.3.2, that further
enforce security.

Figure 8 depicts how IAP functions for authentication and authorization to GCE instances.
Note: IAP can also be used for App Engine and On-Prem.
On-Prem
External
User
HTTPS Connection
(with TCP Forwarding)
Identity Example project

Aware Proxy
Por t 2 2
GCE
10 .2 40.0 .2
Por t 3389
GCE
Cloud Identity 10 .2 40.0 .3
banking.com
Figure 8: Identity Aware Proxy
For zero-trust, FIs can use BeyondCorp Enterprise which shifts access controls away from the
network perimeter to be context aware for individual users. This enables a secure, work from
any location without VPN, set of access controls. BeyondCorp allows for single sign-on, access
control policies, access proxy, and user and device-based authentication and authorization.
The BeyondCorp principles are:
1. Access to services must not

be determined by the network
from which you connect.
2. Access to services is granted

based on contextual factors
from the user and their
device.
3. Access to services must be

authenticated, authorized,
and encrypted.
The Migrating to BeyondCorp: "Maintaining Productivity while Improving Security" research

paper provides an overview on the BeyondCorp migration processes and its overall security
benefits.

4.3.1.1 – Access Approval

Access approval is used to review and manage Google personnel access for specific services,
projects, or folders in Google Cloud. Access approval enables FIs to require explicit approval
whenever Google support and engineering need to access sensitive content. When access
from Google support and engineering is requested, approval processes record audit logs
which increases overall visibility and security. The audit logs are produced through Access
Transparency, which logs the actions that Google personnel take when accessing customer
content.
Data access control can prevent a rogue user or attacker from accessing sensitive resources,
conducting malicious activity, performing configuration changes, or moving laterally to other
resources.
Access approval should be used when the FI’s resources need to be accessed by Google
personnel. This includes an approval process and an auditing and logging record of the Google
personnel’s interaction with the resource. Figure 9 depicts the access approval structure.
Google Client
Support Ap prover
Project
Explicit
ap proval
Access Approval
Access Cloud Pub/Sub
Approval API
VPC Network Authorized Unauthorized

Access Access
Reg ion 1
Zone
Subnet
GCE GCE
10 .2 40.0 .2 10 .2 40.0 .3
a.b.c.d/x
Figure 9: Access Approval
4.3.1.2 – Additional Requirements

There are some additional requirements for Identity and Access Management from the CIS
Benchmarks v1.1.0, some of which have yet to be mentioned. These are listed in Table 6, along
with their method of prevention below.
ID CIS – GOOGLE CLOUD PREVENTION

BENCHMARK CONTROL
1.0 IDENTITY AND ACCESS MANAGEMENT
Use corporate login credentials instead of

1.1 personal accounts, such as Gmail Covered in Org Policy constraints.
accounts.


BENCHMARK CONTROL
Setup multi-factor authentication for

1.2 Google Cloud Platform accounts. Covered in Identity Federation.
Setup Security Key Enforcement for

1.3 Google Cloud Platform admin accounts. Covered in Identity Federation.
Ensure that there are only Google Cloud-

1.4 managed service account keys for each Covered in Org Policy constraints.
service account.
Do not assign any service account an admin role, or

legacy role such as Owner, or Editor (other than the
Ensure that Service Account has no Terraform deployer service). For Terraform or IaC,
1.5 Admin privileges. the pipeline should be setup before the org policies
are enabled. SCC checks should also be muted for
this Terraform IaC service account.
Ensure that IAM users are not assigned Do not assign any IAM user the roles: Service
the Service Account User or Service Account User, or Service Account Token Creator.
1.6
Account Token Creator roles at project Instead, assign users these roles to the specific
level. service account.
Ensure user-managed, external keys for

Do not allow users to export user-managed keys.
1.7 service accounts are rotated every 90 Covered in Org Policy constraints.
days or less.
Ensure that Separation of duties is Do not grant the same IAM user both roles: Service
Account Admin, and Service Account User.
1.8 enforced while assigning service account
related roles to users.
Do not use legacy roles.
Do not assign the binding allUsers or
Ensure that Cloud KMS cryptokeys are not allAuthenticatedUsers access to cryptokeys.
1.9 anonymously or publicly accessible. Instead grant specific users/groups the binding so
access is not anonymous.
Ensure KMS encryption keys are rotated Set the rotation period of all KMS keys to 90 days
1.10 within a period of 90 days. or less. Covered in the Cloud KMS section.
Ensure that Separation of duties is

1.11 enforced while assigning KMS related Covered in the Cloud KMS section.
roles to users.
Ensure API keys are not created for a Use standard authentication methods instead of
1.12 project. API keys when possible.
Ensure API keys are restricted to use by For every API Key, ensure the section ley
1.13 only specified Hosts and Apps. restrictions parameter application restrictions is
not set to None.


BENCHMARK CONTROL
Ensure API keys are restricted to only APIs For every API Key, ensure the section Key
1.14 that application needs access. restrictions parameter API restrictions is not set to
None.
Ensure API keys are rotated every 90 Monitor your API keys, identifying any API key that
1.15 days. was created more than 90 days in the past, and
regenerating that key.
Table 6: IAM CIS Benchmarks v1.1.0
4.3.2 Network Security

Networking is a core, foundational component in every cloud environment, and network
security plays an important role in securing FI’s data in the cloud. Often, a malicious actor will
use network-delivered attacks to intercept and exfiltrate data or to disrupt the network’s normal
operations (e.g., DDoS, man in the middle, etc.). In the event of a DDoS attack – resources
(such as web gateways, routers, switches, etc.) can be overwhelmed, user and application
access can be prevented, and services may be taken offline – degrading the quality of service.
There are also concerns for Layer 7 (application layer) attacks. Protecting against L7 attacks
involves both L7 policies and firewall rules. Traditional network security, if done wrong, can
expose FI's to data breach risk (i.e., open ports, overly permissive firewall rules, etc.). For
example, SQL injection and cross-site scripting (XSS) attackers can extract sensitive
information, obtain privileged access, modify/delete data, or gain full control of the web
application.
For FIs, securing data is of the utmost importance, and FIs often store some form of sensitive
data (be it transaction data, individual client data in the form of PII, or internal sensitive and
proprietary records). To protect against network-based threats, proper network security
controls and configurations should be deployed.
Google Cloud offers a robust stack of native network security controls to reduce the threat
landscape and minimize risk. To protect resources in the organization’s environment, FIs should
secure their Virtual Private Clouds (VPCs), implement a web application firewall, restrict access,
and implement service-based segmentation.
The framework for resource protection:
1. Secures egress/ingress from the external internet (North/South traffic).

2. Segments within VPCs and secures the intra-VPC traffic between them (East/West
traffic).
3. Secures the VPC through micro-segmentation.
Figure 10 captures the network security controls that will be described in the subsequent
sections.
Note: The banking.com architecture in this technical paper uses an Enterprise-to-Google

Cloud connectivity model through dedicated interconnects.

On-prem Legend
On-prem ingress VPC Service Controls

DC1
DC1
VPC Peering DNS Peering
On-prem Router
External
DNS Server Outbound forwarding
Link local address:
e.g., 169.254.10.2 banking.com Inbound forwarding
Queries for Client’s Google zone

DNS forwarding policy that
enables inbound forwarding
Queries for Client’s DNS

Colo Facility 1 Colo Facility 2 forwarding zone
Peering Peering
Edge Edge
Common Folder
Base Hub Res trict ed Hub
Base Hub VPC Res trict ed Hub VPC
Us-central1 Us-east4
DNS Project
Interconnect Project
Zone Zone
DNS VPC
Subnet Subnet Dedicated to
purchasing and
Private zone: managing
Cloud Cloud interconnect
VLAN VLAN “gcp.banking.com.”
Router Router connections
a.b.c.d/24 a.b.c.d/24
DNS Peering shown for a single

project, but peering would be
established across all host
project’s private zones
Entity Folder
Dev Fold er Non-prod Folder
Dev VPC Hos t Res trict ed Dev VPC Non-prod VPC Host Res trict ed Non-prod
Cloud Cloud
Project Hos t Project Project VPC Host Project
Identity Identity
Priv ate Priv ate Priv ate Priv ate
zone: “.” zone: “.” zone: “.” zone: “.”
VPC Host Projects
Fol der Level Fol der Level

Secr ets Secr ets
Shared VPC Shared VPC Shared VPC Shared VPC
Host Host Host Host
Subnet 1 Subnet 2 Subnet 1 Subnet 2 Subnet 1 Subnet 2 Subnet 1 Subnet 2

a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x a.b.c.d /x
Service Projects
Ap plication Ap plication Ap plication Ap plication Ap plication Ap plication Ap plication Ap plication

Project 1 Project 2 Project 1 Project 2 Project 1 Project 2 Project 1 Project 2
Figure 10: banking.com Network Architecture
4.3.2.1 Cloud Load Balancing

If the deployed workloads require ingress traffic from the internet, external Google Cloud
Load Balancers (GCLBs) should be used. Due to the org policy constraint,
compute.restrictLoadBalancerCreationForTypes (mentioned in Section 4.2.2), if the project is
restricted and sensitive, the org policy constraint will restrict the ability to create external
GCLBs on the project. Therefore, if it is determined that ingress traffic from the internet is a
necessity for the sensitive project, you will need to set a project-level org policy to allow
external GCLBs (effectively overriding the inherited folder’s org policies).
Note: With the hierarchical firewall policy that is described in Section 4.3.2.2, all project’s
firewalls will be exposed to the Health Check IP range. The Health Check IP range has the same
IP range as the external GCLBs. Therefore, it is important that the org policy restricts the ability
to create external GCLBs on sensitive projects. Otherwise, by default, external GCLBs could be
deployed and an external exposure on the external GCLB can be added.

4.3.2.2 Hierarchical Firewalls

Hierarchical firewall policies allow for folder level firewall enforcement. Contrary to the
inheritance mechanism of the organization policies, if a hierarchical firewall policy is placed at
the organization level it will override all resources below it (i.e., the highest level in the hierarchy
is automatically inherited downwards, and a lower, more permissive policy will not override it).
This technical paper recommends a folder level firewall policy, listed in Table 7, that is applied
to each of the banking.com folders.
DESCRIPTION SOURCE PROTOCOL PORT
IP Ranges:
Allowing Health 35.191.0.0/16, 80, 443 (NOTE: sometimes
Checks TCP
209.85.152.0/22, and 8080 is needed as well)
209.85.204.0/22
IAP for TCP IP Range:

forwarding 35.235.240.0/20 TCP 22, 3389
SSH remote FI’s Ips (On-prem

access interconnect or VPN) TCP 22 (SSH)
RDP remote FI’s Ips (On-prem

access interconnect or VPN) TCP 3389 (RDP)
Inner VPC traffic Depends on VPCs CIDR TCP, UDP, ICMP Any
range
Any (Deny-all else) –

Deny-all else priority 65530 Any (Deny-all else) Any (Deny-all else)
Table 7: Hierarchical Firewall Policy
This firewall policy is very restrictive, and exceptions will need to be made. But, by starting in a
restrictive state, teams will be forced to adjust their firewall policies only for exposures deemed,
as necessary. Careful consideration should be given to users or groups that have the Cloud
Identity permissions to create and delete firewall rules.
Note: You can refer to the December 2022 Google Security Foundations Guide for an
overview of hierarchical firewall implementation.
In certain situations, however, it may be more appropriate to set the firewall policy at the VPC
level instead of the folder level through Hierarchical Firewalls. For example, if certain workloads
require a special micro-segmentation configuration from other workloads (since Hierarchical
Firewalls currently do not support network tags).
4.3.2.3 VPC Firewalls

VPCs are used as a network partition to isolate resources and manage networking functionality
for the resources. VPC networks are global, meaning they can span multiple regions without
communicating over the public internet. Therefore, resources can be globally distributed and
be within the same VPC.

VPCs are comprised of an additional partition layer called a subnet, and each subnet is
explicitly associated with a single region. To ensure that resources are as private and as secure
as possible, FIs should manage traffic with firewall rules, centralized network control, and
secure outbound connections.
The firewall rules on a VPC determine which traffic to allow or deny for the resources attached
to the VPC. The rules allow you to specify the type of traffic, such as ports and protocols, and
the source or destination of the traffic, including IP addresses, subnets, tags, and service
accounts. Network tags are used to make firewall rules and traffic routes apply only to specific
VM instances in the project.
Table 9 lists the recommended default firewall rules and network tags for VPCs on all projects.
These firewall rules do not include external, egress rules; if external egress is needed, manual
creation of the firewall rule is required. This will be necessary to enable certain workloads. It is
recommended that the FI uses Firewall Insights to determine firewall rule usage and
configuration issues. The ingress rules also restricts inbound traffic to the external GCLB IP
range (listed as Allowing Health Checks).
As mentioned in the Cloud Load Balancing section, with the policy in Table 8, all project’s
firewalls will be exposed to the Health Check IP range. The Health Check IP range has the same
IP range as the external GCLBs. Therefore, it is important that the org policy restricts the ability
to create external GCLBs on sensitive projects. Otherwise, by default, external GCLBs could be
deployed and an external exposure on the external GCLB can be added. If exposure to the
external GCLBs is required, the org policy constraint will need to be relaxed.
Note: If private VMs or GKE clusters require external egress traffic, refer to Cloud NAT in
Section 4.3.2.6.
DESCRIPTION SOURCE NETWORK TAG PROTOCOL PORT
IP Ranges: 80, 443 (NOTE:

Allowing Health 35.191.0.0/16, allow-health- sometimes 8080 is
Checks 209.85.152.0/22, and checks TCP
209.85.204.0/22 needed as well)
IAP for TCP IP Range:

forwarding 35.235.240.0/20 TCP 22, 3389
SSH remote
access FI’s IPs remote-access TCP 22 (SSH)
RDP remote
access FI’s IPs remote-access TCP 3389 (RDP)
TCP, UDP,
Inner VPC traffic Depends on VPCs CIDR ICMP Any
range
Any (Deny-all else) – Any (Deny-all

Deny-all else priority 65530 else) Any (Deny-all else)
Table 8: VPC Firewall Rules

4.3.2.4 Shared VPC

To create a centralized network, Shared VPCs should be leveraged. Shared VPCs allow an
organization to connect resources from multiple projects to a common network through
internal IPs. Implementing a Shared VPC requires a host project and a Shared VPC network.
The service projects are then attached to the host project.
Note: Resources in service projects can communicate with one another across the project
boundaries.
One key benefit of using shared VPCs is the ability to manage the network controls for a wide
range of projects centrally rather than having each individual project VPC managed separately.
Shared VPC lets organization administrators delegate administrative responsibilities, such as
creating and managing instances, to Service Project Admins while maintaining centralized
control over network resources like subnets, routes, and firewalls.14
For most simple use cases, a single (non-Shared) VPC network provides the networking
functions that are required. Shared VPCs should be used for administration of multiple working
groups. If a Shared VPC is not logical for your use case, but you need to establish
communication between VPCs, VPC Network Peering is the next viable solution. For additional
information on best practices when setting up a VPC, refer to Google’s best practices and
reference architectures for VPC design document.
4.3.2.5 VPC Service Perimeter

VPC Service Controls (VPC-SC) address threats such as data exfiltration, accidental data loss,
and excessive access to data. It provides separate and orthogonal protections that
complement Identity and Access Management controls. Segmenting services through the use
of VPC-SCs enables users to tightly control which entities can access what services in order to
reduce unintentional losses. This ensures that sensitive data can only be accessed from
authorized networks – and restricts access to allowed IP addresses, identities, and trusted
devices. Without proper segmentation, multi-tenant services could be subject to data
exfiltration, access from unauthorized networks, and data loss. In addition, each VPC service
perimeter enables FIs to explicitly define the allowed services that can access that perimeter
and the projects within.
Banking.com uses VPC-SCs to define a service perimeter around the resources that are hosting
sensitive data in restricted projects. If there are projects in different VPC service perimeters
that need access to the sensitive resources, a perimeter bridge can be used to allow
communication across perimeters.
Note: The traffic between perimeters over a perimeter bridge is bi-directional by default. If
needed, the FI can separately control ingress/egress traffic through policies for specific
perimeters. Refer to the Google document VPC Service Controls Ingress and egress rules
for more information on how to set up ingress and egress rules.
Figure 11 depicts how VPC-SCs function in a Google Cloud environment. VPC-SCs provide
segmentation by isolating Google Cloud resources and VPCs across three network paths:
1. Internet to service 2. VPC to service (private) 3. Service to service

VPC-SC enables the ability to lock access to otherwise public Google Cloud service APIs (e.g.,
BigQuery, Google Cloud Storage, etc.) and provides private access only.
The VPC-SC perimeters explicitly enable FIs the ability to allow list both specific google
services and specific application access via their projects.
Internet
Project Project
VPC Network
VPC Network
Reg ion 1
Reg ion 1
Zone
Zone
Subnet
Subnet Unauthorized Proj ect
Cloud GCE GCE

GCE
10 .2 40.0 .2
Storage 10 .2 40.0 .3 10 .2 40.0 .4
a.b.c.d/x
a.b.c.d/x
BigQuery
Public APIs
Figure 11: VPC Service Control Perimeter15

It is also recommended to use Access Levels in conjunction with VPC Service Controls. Access
levels grant controlled access to protected Google Cloud resources in service perimeters from
outside a perimeter. An access level defines a set of attributes that must be met before a request
is honored. Access levels can consider various criteria, such as IP address and user identity. For
a detailed overview of access levels, read the Access Context Manager overview. The Google
document, Allowing access to protected resources from outside a perimeter provides an
overview on the limitations of using access levels, as well as how to create them and how to
manage them.
4.3.2.6 Cloud NAT

Thus far, the recommended network architecture for banking.com restricts access to Google
Cloud resources to connections from an on-premises network (Cloud VPN, Interconnect) or
from Identity Aware Proxy (IAP). Moreover, connections from Google Cloud resources, the
Internet, and other VPCs are managed with VPC firewall rules and VPC-Service Controls.
In banking.com, if a private resource (e.g., GCE, GKE) needs to communicate externally to the
Internet, Cloud NAT will need to be leveraged. Cloud NAT allows GCE instances and GKE
clusters without external IP addresses to send outbound, egress traffic to the Internet, and
receive the response traffic from the destination.
Cloud NAT has gateways that are associated with a subnet within the VPC of a project. The
gateways are configured to apply to the primary IP address range of a subnet. If a subnet does
not have an associated Cloud NAT gateway, VMs within that subnet cannot access the Internet.
Figure 12 depicts a Cloud NAT configuration, including the subnet implications.

Internet
Project
VPC Network
Reg ion 1
Cloud
NAT
Zone
Subnet
GCE GCE
10 .2 40.0 .2 10 .2 40.0 .3
a.b.c.d/x
Figure 12: Cloud NAT16
4.3.2.7 Web Application Firewall and DDoS Protection

A Web Application Firewall (WAF) is the first line of defense between the web application and
internet traffic. Using a WAF can prevent attacks that take advantage of web application
security flaws and DDoS attacks.
In Google Cloud, Cloud Armor protects against DDoS and web-based attacks. Cloud Armor has
security policies that protect applications by regulating which requests are allowed or denied
access to the underlying load balancers. The security policies are comprised of rules such as the
incoming request’s IP address, IP range, or region code. Cloud Armor acts at Google Cloud’s
network edge, either allowing or denying access to the external HTTP(S) GCLB that sits in the
Google point of presence. The security policies are attached to the backend service of the
external HTTP(S) GCLB and must be associated with the backend service.
Table 9 below describes the recommended security policies that are applied to Cloud Armor
instances in banking.com.
Note: There are preconfigured rules that protect against common application layer attacks that
are also included in the table. It is recommended that these rules be carefully evaluated in
detective mode prior to enabling them in block mode. There may be scenarios that lead to
application degradation – hence, careful review and considerations are necessary.
SECURITY POLICY DESCRIPTION FORMAT
To ensure that only internal users from the organization

Allowlist your org’s IP inIpRange(origin.ip,
addresses or address are allowed access to services behind the external
HTTP(S) load balancers, the IP address or address 'your org’s IPs')
blocks
blocks should be restricted to company IPs.
Denylist specific,
suspicious IP Create a denylist of IP ranges that blocks traffic from IP inIpRange(origin.ip,
addresses or address addresses where suspicious activity has been 'suspicious IPs')
blocks identified.

SECURITY POLICY DESCRIPTION FORMAT
Deny traffic from This should be used if a web application is not available origin.region_code ==
outside your region in a specific region. 'XX'
Cross-site scripting Defends against cross-site scripting attacks. xss-<version>

(XSS) policy
SQL injection (SQLi) Defends against SQL injection attacks. sqli-<version>

attacks policy
Local file inclusion

(LFI) attacks policy Defends against local file inclusion attacks lfi-<version>
Remote file inclusion Defends against remote file inclusion attacks rfi-<version>
(RFI) attacks policy
Remote code
execution (RCE) Defends against remote code execution attacks. rce-<version>
attacks policy
Table 9: Cloud Armor Security Policies17
Figure 13 depicts how Cloud armor functions with the global, network edge external HTTP(S) LB.
Internet

Untrusted
Untrusted VPC
Reg ion
Zone
Example Project
Subnet
VPC Network
Cloud HTTP(S)
GCE
Armor LB
10 .2 40.0 .2
a.b.c.d/24
Figure 13: Cloud Armor
4.3.2.8 Packet Mirroring, IDS, IPS

An additional recommended practice (but not demonstrated in banking.com) is to place next
generation stateful firewalls in the networking architecture. For example, Palo Alto Networks VM
series can provide security inspection for all egress and ingress traffic at the perimeter.
Moreover, Google Cloud Packet Mirroring can be used as a part of Google Cloud IDS to detect
network intrusions. The Google Cloud packet mirroring forwards all network traffic from your
Compute Engine VMs or Google Cloud clusters to a designated address. FIs can also use third
party tools like IDS through Palo Alto Networks or Bro/Zeek for additional network security.

4.3.2.9 VPC Flow Logs

“VPC Flow Logs records a sample of network flows sent from and received by VM instances,
including instances used as GKE nodes. These logs can be used for forensics, real-time
security analysis, and expense optimization.” 18 With flow logs, FIs can leverage the real-time
streaming APIs (through Pub/Sub), and integrate with Security Information and Event
Management (SIEM) systems. This can provide real-time monitoring, correlation of events,
analysis, and security alerts.
“VPC Flow Logs samples each VM's TCP, UDP, ICMP, ESP, and GRE flows. Both inbound and
outbound flows are sampled. These flows can be between the VM and another VM, a host in
your on-premises data center, a Google service, or a host on the internet. If a flow is captured
by sampling, VPC Flow Logs generates a log for the flow. Each flow record includes the
information described in the Record format section.”19
It is recommended that flow logs are turned on for each VM instance and GKE node.

There are some additional requirements for Network Security from the CIS Benchmarks v1.1.0,
some of which have yet to be mentioned. These are listed in Table 10 along with their method of
prevention.
ID CIS – GOOGLE CLOUD BENCHMARK CONTROL GOOGLE CLOUD SCF MAPPING
3.0 NETWORK SECURITY

To prevent use of default network, a project should not Go to the VPC networks page,
3.1 have a default network ensure that a network with the name
default is not present.
In order to prevent use of legacy networks, a project Delete the networks in the legacy
3.2 should not have a legacy network mode.
configured.
Go to Cloud DNS in the console, for

Ensure that DNSSEC is enabled for Cloud DNS. each zone of Type Public, set
3.3 DNSSEC to On.
Ensure that RSASHA1 is not used for the key-signing key The algorithm used for key signing
in Cloud DNS DNSSEC. should be a recommended one and
3.4 it should be strong.
Covered by Hierarchical and VPC

Ensure that SSH access is restricted from the internet. firewall rules.
3.5
Covered by Hierarchical and VPC

Ensure that RDP access is restricted from the Internet. firewall rules.
3.6
Ensure that VPC Flow Logs is enabled for every subnet in Set Flow Logs to On.
3.7 a VPC Network.
Ensure no HTTPS or SSL proxy load balancers permit SSL Ensure that each target proxy entry
policies with weak cipher suites. in the Frontend table has an SSL
3.8 Policy configured.
Table 10: Network CIS Benchmarks v1.1.0

After the foundational components of the Google Cloud environment are secured (i.e., the
resource hierarchy, organization policies, identity and access management, and networking), it
is equally important to secure the services inside of the Google Cloud projects that the FI is
leveraging. The services described in the subsequent sections are five of the more commonly
used services in Google Cloud, and include Google Compute Engine (GCE), Kubernetes Engine
(GKE), Cloud Storage, BigQuery, and Dataflow.
Without hardened services, the attack surface of a cloud environment drastically increases.
Often, the beginning stages of the cyber kill chain occurs due to misconfigurations or
vulnerabilities on the services in a cloud environment. To mitigate the risk of security breaches,
services should be secure upon instantiation.
Note: Within Google Cloud, there are a large number of services and APIs that are offered to
customers. The services have varying purposes, and the usage of the services will depend on
the solution that the organization is pursuing. This section is non-exhaustive, and only includes
a subset of Google Cloud services.
4.3.3.1 Compute Engine

Google Compute Engine (GCE) is the Google Cloud service that lets customers create and run
VMs. Depending on how a GCE instance is configured, the default settings applied to the VM
may be considered insecure; misconfigurations of the VM can leave the Google Cloud
environment vulnerable, and virtualization attacks are one of the top cloud computing threats –
underscoring the importance of securing the Google Cloud services. For example, in an
unsecure virtual environment, an attacker can take control of VMs by compromising the
hypervisor layer. Lateral movement between VMs is another concern, which is addressed
through network tagging and micro-segmentation and is discussed in Section 4.3.2.
Important: This technical paper does not delve into two important security controls for GCE
instances: CICD and Operating System (OS) patching. The CICD is an automated deployment
method for services inside of Google Cloud. OS patching is an essential preventative
maintenance that keeps the OS on VMs up-to-date, stable, and safe from malware and other
threats. For information on CICD pipeline deployment, refer to the December 2022 Google
Security Foundations Guide – this technical paper will not cover image-build pipelines or
image deployment.
4.3.3.1.1 Organization Policies

Organization policies are one preventative method for ensuring security on GCE instances.
There are multiple organization policies (discussed in Section 4.2.2) that are specific to GCE
instances and are applied to banking.com. These org policies are included in Table 11 below.
Google Cloud Secure Banking Framework 47 47


compute.disableNested
Virtualization hardware-accelerated nested true
virtualization for all Compute Engine
VMs.
compute.disableSerial This boolean constraint disables serial

PortAccess port access to Compute Engine VMs. true

compute.disableGuestA Compute Engine API access to the true
ttributesAccess Guest Attributes of Compute Engine
VMs.
compute.vmExternalIpA Compute Engine VM instances that deny all=true
ccess are allowed to use external IP
addresses.
This boolean constraint requires that
all new Compute Engine VM instances
compute.requireShieldedVm use Shielded disk images with Secure true
Boot and Integrity Monitoring options
enabled.
This boolean constraint, when true,
prevents the default App Engine and
iam.automaticIamGrant Compute Engine service accounts
sForDefaultServiceAcc true
ounts that are created in your projects from
being automatically granted any IAM
role on the project when the accounts
are created.
This list constraint defines the set of It is recommended that this

compute.trustedImageProje
cts projects that can be used for image constraint is set to true for
storage and disk instantiation for sensitive projects that use
Compute Engine. public images
Table 11: Recommended Organization Policies for GCE Instances
4.3.3.1.2 Shielded and Confidential VMs

By setting the organization policy to true for compute.requireShieldedVm, it will ensure that all
instantiated VMs are shielded by default. The Shielded VMs are hardened with security controls
that mitigate boot/kernel-level malware or rootkits. This is accomplished through the use of
secure boot, virtual trusted platform module (vTPM)-enabled Measured Boot, and integrity
monitoring.
To secure sensitive workloads that use GCE instances in the use cases that require encryption-
in-use protections, it is recommended to use Confidential VMs. Confidential VMs are built on
top of Shielded VMs. Along with the encryption of data in transit and at rest, Confidential VMs
encrypt data while in use. Confidential VMs allows for the sensitive data to remain encrypted in
memory during processing using second-generation AMD EPYC processors. Moreover, Google
does not have access to the encryption keys that are generated for the data memory. The use of
Confidential and Shielded VMs effectively protects against remote attacks, privilege escalations,
and malicious insiders to secure the GCE instances in the Google Cloud environment.
Note: When GCE instances are created, Google Cloud provides an option to select an
encryption key management solution. Recommendations for this are included in Section
4.3.5.2.

4.3.3.1.3 OS Login
It is also important to properly configure the GCE instances. Project wide-SSH keys should be
disabled, and instead, OS Login should be used in tandem with two-factor authentication (2FA).
This is recommended because project wide-SSH keys allows the owner of the key privileged
access to the Linux instances.
4.3.3.1.4 Images
On GCE, images provide the base operating environment for applications to run. The images are
integral for ensuring application deployment can scale quickly and reliably. Images can also be
used to archive application versions for business continuity and disaster recovery.
Images should be provisioned with the most up-to-date patches to reduce the possibility of
vulnerability exploitation. The patches should be applied on a regular basis, and using a
golden standard image. In addition, it may be necessary for teams in the organization to want
to share images between projects. This will require the compute.imageUser,
compute.instanceAdmin, and compute.storageAdmin role. These roles should be associated
with an image user group mentioned in Section 4.3.1.
It is also recommended that FIs use trusted image policies. Trusted image policies restrict your
project members so that they can create boot disks only from images that contain approved
software that meets your policy or security requirements. Trusted images are set using an org
policy constraint.
4.3.3.1.5 Access Control

For access control, it is recommended that the FI review the users who need access to the GCE
instances, then review the pre-defined roles that Google Cloud offers for GCE and assign them
accordingly (e.g., InstanceAdmin, NetworkAdmin, NetworkViewer, etc.). As mentioned in
Section 4.3.1, these users should be assigned to groups as necessary. Note that Compute
scopes should not be used for access control, instead IAM should be leveraged. In addition, the
org policy, iam.automaticIamGrantsForDefaultServiceAccounts, from Section 4.2.2, prevents
the default App Engine and Compute Engine service accounts that are created in projects from
being automatically granted any IAM role. Without the org policy, the Compute Engine service
account is automatically granted roles/editor, which is broad and overly permissive.
Lastly, as recommended in the December 2022 Google Security Foundations Guide, in cases
where the Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) is required by
users or groups, you can create a custom role that has all the permissions of the Compute
Instance Admin (v1) role apart from the compute.instances.setTags permission. Someone with
this custom role can't add or remove tags on VMs; the tags must be added by a controlled
mechanism, depending on workload type.
4.3.3.1.6 Logging
As discussed in Section 4.3.2.9, VPC Flow Logs should be turned on for GCE instances. VPC
Flow Logs provides FIs with real-time visibility into network throughput and performance.
Using Flow Logs, FIs can understand network usage, optimize network traffic expenses, and
can use the logs for security analysis and network forensics.
Flow Logs work for multiple use-cases and traffic patterns, such as VM-to-VM in the same VPC,
VM to external flows, VM-to-VM in a Shared VPC, etc. For more information on VPC Flow Log
traffic patterns, refer to the Traffic pattern examples documentation. For enablement of flow
logs, refer to the Enabling VPC Flow Logs documentation.
Note: Logging through a centralized SIEM is discussed in Section 4.4.3.

4.3.3.2 Container Engine

Google Kubernetes Engine (GKE) is a Google Cloud service that is used for deploying,
managing, and scaling containerized applications. GKE is built on top of multiple GCE instances
and grouped together to form a cluster. Most FIs modern applications will run in the GKE
clusters in a Google Cloud environment.
GKE is structured slightly different from the standard project structure within GCE and has
different networking concepts. A cluster consists of at least one control plane and has multiple
worker machines called nodes. Within the nodes are pods. Pods are the smallest deployable
objects in GKE. Pods contain one or more containers. Figure 14 depicts the logical structure of
GKEs architecture.
Project
VPC Network
Region 1
Subnet
Cluster
Node
Namespace
Pod
GKE
a.b.c.d/24
Figure 14: GKE structure
There are several controls that need to be enabled on a new GKE instance to ensure it is secure,
and Google Cloud makes it simple. Google enables GKE with a few unique security controls
above what's available in raw GKE cluster deployments. The security controls discussed in the
remainder of the section include the following:
1. GKE Networking and Sandbox

2. Workload Identity
3. Managed Base Images
4. Shielded GKE Nodes
5. Encryption (discussed further in Section 4.3.5.3)
6. Logging

Moreover, Google has documentation that lists best practices for GKE instances, including
Hardening your cluster's security, PCI DSS compliance on GKE, and Introducing GKE Autopilot: a
revolution in managed Kubernetes (which describes automation and management for GKE
nodes). Materials in the sections below will pull from concepts discussed in these two documents
to synthesize their contents.
4.3.3.2.1 GKE Networking and Sandbox

In addition to the recommendations from Section 4.3.2, organizations should use network tags on
their GKE instances. Network tags are separated at the node pool level, meaning each node pool
within a cluster receives its own set of tags. By default, each instance will receive a tag that
identifies which cluster the instance is a part of. Additional custom network tags can be applied if
there are certain instances that need exposures other than the default VPC firewall exposures.
GKE also has network policies. Network policies are a method to implement micro-segmentation
and can restrict lateral movement within a cluster. It is recommended to enable network policies
when creating the GKE cluster. Without network policies in place, all pod-to-pod traffic is allowed
by default.
The last element of networking is namespaces. Namespaces can logically segment instances
inside of a GKE node pool. In general, usage of both namespaces and network policies is
important for FIs that need to fully segment instances. A guide on implementing namespaces
can be found here.
4.3.3.2.2 Workload Identity

To secure GKE, it is important to implement strong access control measures with IAM. IAM should
be used to control the permissions and privileges that users and service accounts have on GKE
clusters (e.g., creating clusters, deleting clusters, etc.). Review the users who need access to the
GKE clusters, then review the the pre-defined roles that Google Cloud offers for GKE and assign
them accordingly. GKE also includes an RBAC mechanism by default, which can be used to apply
role bindings.
4.3.3.2.3 Managed Base images

Images should be provisioned with the most up-to-date patches to reduce the possibility of
vulnerability exploitation. The patches should be applied on a regular basis, and through the use
of a golden standard image. It is recommended to start with a container managed base image
(other options include using a distroless or scratch base image). And, while a CI/CD pipeline
should be leveraged for image provisioning, a Container Optimized OS can be used as the default
base image for your GKE instances. To enable images authorized by a specific attestor, and to
ensure that only trusted containers are deployed, Binary Authorization is highly recommended.
When configuring the GKE instance, FIs should enable auto-upgrading nodes, auto-repairing
nodes, and cloud logging and monitoring. For vulnerability scanning, organizations can use
Google Container Analysis Vulnerability Scanning, which will be discussed in further detail in
Section 4.3.4.2. It is also recommended to leverage Container Threat Detection to monitor the
state of container images (refer to Section 4.4.1.2.2).
4.3.3.2.4 Shielded GKE Nodes

For increased node security, it is recommended to use Shielded GKE Nodes. Shielded GKE
Nodes are built on top of Shielded VMs and prevent against node impersonation and
vulnerability exploitation in clusters. Figure 15 depicts how Shielded GKE Nodes function in
Google Cloud.

Nodes
Shielded GKE Nodes Enabled Pod 1

Kubernetes Zonal
Control Plane Cryptographically Container Cluster
Verifies: GKE
• Every node in your cluster is a Zonal Control
virtual machine running in Plane
Google's data center.
• Every node is part of the
API Pod 2
Managed Instance Group (MIG)
Server
provisioned for the cluster.
• The kubelet is being
provisioned a certificate for GKE
the node on which it is
running.
Figure 15: Shielded GKE Nodes
4.3.3.2.5 Encryption
GKE supports customer managed encryption keys (CMEK) so FIs can control the keys
themselves if they choose to (rather than rely on the default encryption). This is important for
FIs since GKE supports encryption key management (EKM) for customers who want to use and
manage their own fully external key management system. Encryption is discussed further in
Section 4.3.5.3.
4.3.3.2.6 Logging
As discussed in Section 4.3.2.9, and like GCE instances, VPC Flow Logs should be turned on
for GKE. VPC Flow Logs provides FIs with real-time visibility into network throughput and
performance. Using Flow Logs, FIs can understand network usage, optimize network traffic
expenses, and can use the logs for security analysis and network forensics.
Flow Logs work for multiple use-cases and traffic patterns in GKE, such as pod to cluster IP flow,
GKE external load balancer flows, GKE ingress flows, and pod to external flows. For more
information on VPC Flow Log traffic patterns for GKE, refer to the second half of the Traffic
pattern examples section in Google’s documentation. For enablement of flow logs, refer to the
Enabling VPC Flow Logs documentation.
Note: Logging through a centralized SIEM is discussed in Section 4.4.3.
4.3.3.3 Cloud Storage

Storage security provides policy-based control over how data can be moved to and from the
cloud, ensuring that only authorized data leaves the company’s environment, and that data
access is limited to authorized parties. Storage buckets can be vulnerable to privilege
escalation through misconfigured bucket access control lists and/or access control policies.
As an example, unsecure and misconfigured storage services were the culprit in several cloud-
based attacks in the past.20 If bucket read/write privileges are acquired, an attacker can list
assets, modify existing content, create new content, induce denial of service (modify objects
to prevent public loading), and exfiltrate the data. This jeopardizes the availability of the
services and the integrity of the data. Since FIs often store sensitive data in the cloud, it is
imperative that they secure their cloud storage instances.

Securing Cloud Storage involves the combination of multiple security controls. The security
controls discussed in the remainder of the section include the following:
1.Cloud Storage 2. Cloud 3. Access 4. Encryption 5. Signed URL

Networking Storage Control
Labels
Note: Since Cloud Storage does not have VPC Flow Logs, no specifics are discussed for the
Logging section – and is subsumed by the content in Section 4.4.2.
4.3.3.3.1 Cloud Storage Networking

The primary networking components that contribute towards securing Cloud Storage instances
have been discussed in Section 4.3.2. However, note that it is recommended to store Cloud
Storage instances in a separate VPC from other resources that should not have access to the
data residing on the Cloud Storage instances.
VPC Service Controls can also be leveraged at the project level to segment and isolate the
Cloud Storage instances from resources on other projects. The VPC Service Controls enable
the customer to limit which projects (and which services in those projects) can access the data
stored on Google Cloud Storage (essentially acting as an allow list of services).
4.3.3.3.2 Cloud Storage Labels

All storage and database resources should have an associated tag using bucket labels to
group Cloud Storage resources together. Bucket labels allows for the proper application of
security for asset policy execution and governance. Labels can also be used as naming
conventions to delineate between the sensitivity of the data being stored or accessed in the
Label group.

Within Cloud Storage, IAM is achieved through the application of permissions and privileges
assigned through groups, users, or service accounts. It is recommended to frequently review
which accounts have access to the Cloud Storage instances. The same recommendation
applies to the initial association of individual accounts to Cloud Storage roles and permissions.
Ensure that these accounts are using pre-defined roles and not legacy roles. For more
information on best practices when setting up IAM on Cloud Storage, refer to the Google
Access Control Best Practices. In addition, for service access, it is recommended to use Cloud
Storage service accounts rather than user accounts with hash-based message authentication
credentials.21
IAM is also accomplished with Organization Policy constraints (as mentioned in Section 4.2.2).
The constraint storage.uniformBucketLevelAccess (UBLA) requires buckets to use uniform
bucket level access. UBLA eliminates the use of individual, object-level IAM access policies –
ensuring that there are no undetected access gaps in the bucket. This is particularly beneficial
for FIs, since they can manage uniform permissions at scale in situations when there is a large
employee force who need access to the data, but the data cannot be exposed outside of the
company.22

Encryption requirements are becoming increasingly stringent through compliance
requirements such as PCI DSS and GDPR, adding complexity to properly encrypting data in the
cloud. Cloud Storage uses Cloud KMS to encrypt stored data. Cloud KMS offers a range of
cryptographic key options and offers encryption management tools for security and
compliance purposes. Encryption will be discussed further in Section 4.3.5.2.
4.3.3.3.5 Signed URL

Signed URL is a feature that allows for customers to generate signed URLs with a limited
lifecycle duration and assign them to clients or external users who are not using Cloud
Identity.23 This is especially pertinent to the banking and financial service sector for external
requests from third parties, contractors, etc. that need access to sensitive data. This can also
be seen as a risk vector since credentials can be encoded in the URL and the URL itself valid for
up to 7 days.
4.3.3.4 BigQuery
BigQuery is an enterprise data warehouse that can store and query massive datasets through
the enablement of SQL queries on Google’s infrastructure. This can be used for analysis of
many types of data (log data, IoT data, financial processing data, etc.). BigQuery is functionally
comprised into three components: storage, ingestion, and querying. Data can be stored
directly on BigQuery, or it can be ingested from a different source (e.g., Cloud Storage
instances, Cloud Dataflow instances, etc.). The data is then queried and analyzed inside of
BigQuery.
Since BigQuery often involves the storage (or ingestion) and analysis of potentially sensitive
data, it is integral to secure the BigQuery instances. The security controls discussed in the
remainder of the section include the following:
1.Column Level 2. Row Level 3. Access 4. Encryption

Security Security Control
Note: Since BigQuery does not have VPC Flow Logs, no specifics are discussed for the
Logging section – and Logging content is subsumed by Section 4.4.2.
4.3.3.4.1 Column Level Security

To provide fine-grained access to sensitive columns in BigQuery, organizations should enforce
Column-level security controls by using policy tags to classify the data in the columns. Policy
tags are used to check whether a user has proper access to the columns before allowing the
column to be queried. The policy tag is assigned to the column (or columns) and is associated
with a group or with specific users. For example, in banking.com, only users in group: sensitive-
data-access can view and query the columns with the policy tag: SENSITIVE. Refer to the Using
policy tags in BigQuery guide for more information on the best practices associated with
column-level security, including an example use-case.
The VPC Service Controls also enable the customer to limit which projects, services, identities,
and the circumstances that can access the data in BigQuery (essentially an allow-list of
services).

4.3.3.4.1 Row Level Security

To filter data and enable IAM based access to rows in a table, FIs should use row-level security
on their BigQuery resources. Row-level security builds upon column-level security and extends
the principle of least privilege by enabling fine-grained access control to a subset of data in a
BigQuery table. This allows for the ability to filter/hide or display certain rows of data depending
on the IAM permissions of the user accessing the data.
There are certain use-cases when row-level security should be leveraged and there are multiple
methods for securing data within rows of a BigQuery instance. For example, FIs can use
authorized views, row-level access policies, or store data in separate tables. The Google
BigQuery documentation includes a section that describes when to use row-level security
compared to the other available alternatives.

By leveraging Cloud Identity, access control can be managed on BigQuery instances. It is
recommended to use pre-defined BigQuery roles rather than legacy roles on the projects that
are hosting your BigQuery instances. Since the data stored on BigQuery is sensitive, the
principle of least privilege is of the utmost importance. Only provide authenticated users the
access they need to perform their job function. Also be sure to separate permissions between
those who can create and manage BigQuery resources versus those who should only be
allowed to query the data.
With column-level security, organizations should use authorized views to ensure that table and
dataset level IAM policies are used to confirm proper access. Figure 16 depicts how authorized
views restricts the access to sensitive data through the principle of least privilege.
Start
YES Does the user have YES

Is the view an authorized The user CAN query the
column level access to
view? columns in view
the underlying table?
NO NO
Does the user have Cloud

IAM access to the The user CANNOT query
underlying table and the columns in the view.
dataset?
NO
The user CANNOT query

the columns in the view.
Figure 16: Access with Authorized Views24
As an example, front office bank clerks can query user account balances but, through column-
level security, may not have access to query the user’s entire wealth portfolio.
BigQuery automatically encrypts all data before it is written to disk. By default, encryption keys
are used to protect organization’s data. BigQuery also supports customer managed encryption
keys (CMEK) so customers can control the keys themselves if they choose to (rather than rely
on the default encryption).

This is important for FIs since BigQuery supports encryption key management (EKM) for
customers who want to use and manage their own fully external key management system.
Encryption will be discussed further in Section 4.3.5.2.
4.3.3.5 Dataflow
Cloud Dataflow is a service that processes datasets and can read, transform, and write data.
After the data has been transformed, the writing occurs in an external sink (sinks can include a
Pub/Sub topic, Cloud Storage, BigQuery, etc.). To deploy Cloud Dataflow, it is recommended
to set up a pipeline. Pipelines can be based off of templates or from SQL. For information and
recommendations on deploying Cloud Dataflow pipelines, refer to the Tips and tricks to get
your Cloud Dataflow pipelines into production guide.
Cloud Dataflow has key features that make its usage practical and appealing for FIs. Cloud
Dataflow is useful for capturing, processing, and analyzing data from systems whose data is in
a format that is not easily analyzed (e.g., websites, mobile apps, IoT devices, etc.). For
example, an FI could use Cloud Dataflow for pulling data from scanned images of contractual
agreements for loans. The security controls discussed in the remainder of the section include
the following:
1. Networking 2. Access Control 3. Encryption
Note: Since Cloud Dataflow does not have VPC Flow Logs, no specifics are discussed for the
Logging section – and Logging content is subsumed by Section 4.4.2.
4.3.3.5.1 Networking
The primary networking components that contribute towards securing Cloud Dataflow
instances have been discussed in Section 4.3.2. However, note that it is recommended to
store Cloud Dataflow instances in a separate VPC from other resources that should not have
access to the data being process by Cloud Dataflow.
VPC Service Controls (discussed in Section 4.3.2.5) should be leveraged to segment and
isolate the Cloud Dataflow instances by their projects from undesired and insecure
connections. Since Cloud Dataflow reads from and writes to a designated sink, it is important
to ensure the resources can communicate with one another – accentuating the importance of
proper network segmentation and architecture design. Refer to the Accessing Google Cloud
resources across multiple Google Cloud projects guide for more information on how to
connect resources in different projects.
4.3.3.5.2. Access Control

By leveraging Cloud Identity, access control can be managed on Cloud Dataflow instances. It
is recommended to use pre-defined Cloud Dataflow roles rather than legacy roles on the
projects that are hosting your Cloud Dataflow instances. Only provide authenticated users the
access the need to perform their job function. Also be sure to separate permissions between
those who can create and manage Cloud Dataflow resources versus those who should only be
allowed to query the data.

When running a Cloud Dataflow pipeline, two service accounts are used to manage the security
and permissions: the dataflow service account and the controller service account. The
permissions on the dataflow service account should not be adjusted. If the dataflow service
account loses permissions on the project, Cloud Dataflow cannot perform management tasks.
By default, the Compute Engine service account is used as the controller service account. It is
recommended that these permissions are reviewed and scoped down to only the necessary
permissions for the job function. Refer to the Security and permissions for pipelines on Google
Cloud guide for more information on these service account’s functions.
Data on Cloud Dataflow is encrypted at rest and in transit. All communication with Google
Cloud sources and sinks is encrypted and is carried over HTTPS. All inter-worker
communication occurs over a private network and is subject to your project's permissions and
firewall rules. Refer to the Data access and security guide for more information on Cloud
Dataflow pipeline data security. Encryption will be discussed further in Section 4.3.2.5.

There are some additional requirements for Service Security from the CIS Benchmarks v1.1.0,
some of which have yet to be mentioned. These are listed in Table 12 along with their method
of prevention.
ID CIS – GOOGLE CLOUD BENCHMARK CONTROL PREVENTION
4.0 VIRTUAL MACHINE SECURITY
Ensure that instances are not configured to use the

4.1 default service account. Covered by Org Policies.
Ensure that instances are not configured to use the

4.2 default service account with full access to all Cloud
APIs Covered by Org Policies.
Ensure "Block Project-wide SSH keys" is enabled for

4.3 VM instances. Covered by Org Policies.
Covered in GCE section. Enable-

4.4 Ensure oslogin is enabled for a Project. oslogin value in metadata set to true.
Ensure Ènable connecting to serial

Ensure 'Enable connecting to serial ports' is not
4.5 enabled for VM Instance ports` below `Remote access block`
is unselected.
Under the Network interfaces section,

4.6 Ensure that IP forwarding is not enabled on Instances ensure that IP forwarding is set to Off
for every network interface.

4.0 VIRTUAL MACHINE SECURITY
Ensure VM disks for critical VMs are encrypted with

4.7 Customer Supplied Encryption Keys (CSEK) Covered in Cloud KMS.
Ensure Compute instances are launched with Shielded

4.8 VM enabled Covered in GCE section.
Ensure that Compute instances do not have public IP

4.9 addresses Covered in GCE section.
Ensure that App Engine applications enforce HTTPS

4.10 connections Relates to the app.yaml file.
5.0 STORAGE SECURITY
Ensure that Cloud Storage bucket is not anonymously

5.1 or publicly accessible Covered by Org Policies.
Ensure that Cloud Storage buckets have uniform

5.2 bucket-level access enabled Covered by Org Policies (UBLA).
7.0 BIGQUERY SECURITY
Ensure that BigQuery datasets are not anonymously or

7.1 publicly accessible. Covered by Org Policies (DRS).
Table 12: Security Service CIS Benchmarks v1.1.0
4.3.4 Security Monitoring

Security Monitoring is integral for scanning environments to determine if any systems or
services have been tampered with or misconfigured. There are two security capabilities that
comprise the Security Monitoring section for preventative controls: file integrity monitoring
and vulnerability management. The detective controls in Section 4.4 will detail the scanning,
logging, auditing, and monitoring processes that take place using these preventative
controls.
4.3.4.1 File Integrity Monitoring

File integrity monitoring (FIM) tests and checks operating system (OS), database, and
application software files to determine whether they have been tampered with or corrupted.
Once inside the cloud environment, attackers can modify critical system data, application
binaries, and system configurations; access sensitive customer data; and modify or delete logs.
For these reasons, it is important to track any changes to the established baseline
configurations of a system or service. FIM can also scan files to indicate any undesired change,
alteration of data, or unauthorized access.

FIs typically have sensitive system information (e.g., binaries, config data, logs, etc.) stored in
files.25 When an attacker compromises these files, it opens the possibilities to data
exfiltration/manipulation or system/application compromise. By leveraging FIM on GCE and GKE
instances, FIs can protect against these types of attacks. In addition, PCI DSS requirements 5.1,
5.2, and 11.5 mandate the use of FIM on any in-scope host – accentuating the importance of
having FIM in Google Cloud. The next sections describe how to enable FIM on Container
instances and Compute Engine instances in Google Cloud.
4.3.4.1.1 Container FIM

It is recommended that FIs implement a solution where all nodes can be scanned by a trusted
agent within the cluster, or, where each node has a scanner that reports up to a single
management endpoint. If Shielded Nodes are used, the OS integrity of the container is
checked by default.
In addition, organizations should lock down containers so only specific, allowed folders have
write-access. This is performed by running the containers as a non-root user and using file
system permissions to prevent write access to all but the working directories within the
container file system. Refer to the Installing antivirus and file integrity monitoring on Container-
Optimized OS guide for more information on FIM with GKE.
4.3.4.1.2 Compute FIM

File integrity monitoring can be performed on GCE by using Shielded VM instances that have
integrity monitoring enabled. On a Shielded VM instance, Compute Engine enables the virtual
Trusted Platform Module (vTPM) and integrity monitoring options by default. If you disable the
vTPM, Compute Engine disables integrity monitoring because integrity monitoring relies on data
gathered by Measured Boot. It is recommended that this feature is not disabled on your GCE
instances when modifying Shielded VMs.
4.3.4.2 App Vulnerability Management

Vulnerability management scans networks and endpoints for potential vulnerabilities as well as
security and compliance risks that may be exploited by attackers. It also allows for visualization
of network and application deployments and can assist with remediation. The impact depends
on the context of the vulnerability, but threats can take the form of privilege escalation, kernel
exploits, token manipulation, and many others.
For vulnerability scanning on App Engine, GKE, and/or GCE web applications – Web Security
Scanner should be used. Using Web Security Scanner, FIs can identify security vulnerabilities
on their services. There are two forms of scanning: managed and custom. Managed scans
should be used to centrally manage vulnerability scanning for all projects Custom scans
should be used for projects that require more granular scanning. Both custom scans and
managed scans are available in the Security Command Center (refer to Section 4.4.1)
after configuring the Web Security Scanners. For additional best practices, refer to the
Overview of Web Security Scanner Best Practices.
For image vulnerabilities, Google provides several security services to help build security into
the CI/CD pipeline. To identify vulnerabilities in your container images, FIs should use Google
Container Analysis Vulnerability Scanning. When a container image is pushed to Google
Container Registry (GCR), vulnerability scanning automatically scans images for known
vulnerabilities and exposures from known CVE sources. Vulnerabilities are assigned severity
levels (critical, high, medium, low, and minimal) based on CVSS scores. For the broader
components of the Google Cloud environment, such as Cloud Monitoring and Logging, Cloud

Storage, Cloud SQL, IAM, etc. – Security Health Analytics should be leveraged. Security
Health Analytics is a built-in service in Security Command Center and will be discussed in
Section 4.4.1.1.
Note: The December 2022 Google Security Foundations Guide’s Section 12.3 describes how
Web Security Scanner can be used in an example deployment.
4.3.4.3 Patch Management

Patch management is important for patching operating systems (OSs) across all GCE
instances. Any long-lasting VMs in an FI’s organization will need to periodically update systems
to protect against vulnerabilities.
Google offers VM Manager as a native solution for patch management. To use the OS patch
management feature, you must set up the OS Config API and install the OS Config agent.
For detailed instructions, see Setting up VM Manager. The OS Config service enables patch
management in your environment while the OS Config agent uses the update mechanism for
each operating system to apply patches.26
Another option is to use a third-party solution such as Qualys. You can refer to the Securing
Google Cloud Platform with Qualys report for an overview on how to integrate Qualys in
Google Cloud.
4.3.5 Data Privacy and Protection

Data privacy and protection is a program or set of programs that ensures that critical and
sensitive data (at rest and in motion) is protected and not compromised or leaked outside the
enterprise. Data privacy is becoming especially pertinent with increasingly stringent
compliance regulations such as PCI DSS, HIPAA, and GDPR. Additionally, guaranteeing the
safety of the organization’s data is extremely critical for the reputation of the company. Within
Google Cloud, FIs should take preventative measures to validate the security of data at all
locations of the infrastructure. The following sections will describe how this is accomplished.
4.3.5.1 Data Loss Prevention

Cloud Data Loss Prevention (DLP) tools discover, classify, and redact sensitive data in the
cloud. DLP protects the data by monitoring, detecting, and blocking sensitive data while in use,
in motion, and at rest. DLP also identifies areas where potential information leakage can occur.
This allows for the prevention of data transfer outside organizational boundaries.
Although organizations are generally improving in the area of detecting unauthorized access
attempts, data breaches are ever evolving. A DLP solution reduces the likelihood of data
breaches, interruptions to workflows, and potential loss of integrity. FIs should deploy Cloud
DLP to mitigate risks associated with personal information exposure, IP exfiltration, data
visibility, and non-compliance.
Cloud DLP works by de-identifying sensitive data (such as PII) with techniques like redaction,
masking, tokenization, and other methods. The sensitive data is separated from the non-
sensitive data based on predefined information types (referred to as infoTypes). The
infoTypes include fields such as: PHONE_NUMBER, US_SOCIAL_SECURITY_NUMBER,
CREDIT_CARD_NUMBER, etc. A full list of the built in infoTypes can be found here. In
addition, custom infoType detectors can be set. It is recommended that FIs use Cloud DLP
on any datasets that contain sensitive information to reduce chances of exposure.

For example, if banking.com receives information in Google Cloud containing names, credit
card numbers, etc. from clients, DLP can de-identify the data that should not be exposed to
certain systems. Choosing the proper de-identification technique depends on the type of data
being de-identified. It is recommended that the FI examine the type of data they are storing in
Google Cloud and determine which components should be de-identified. Based on the type of
data (and the business purpose), certain de-identification methods should be used (e.g.,
bucketing, tokenization, replacement, masking, redaction). Table 13 lists these de-
identification methods along with the level that they hide sensitive values.
DE-IDENTIFICATION METHOD INFORMATION ABOUT THE DATA
Redaction Completely hidden by opaque rectangle
Masking Completely hidden by masking characters
Replacement Replaced with other information (e.g., corresponding infoType)
Tokenization or Encrypts sensitive information with a KMS key and replaces it with a
Pseudonymization hash or token by CryptoReplaceFfxFpeConfig or
CryptoDeterministicConfig infoType transformations
Can categorize data values based on custom ranges (e.g., Global

Bucketing Google Cloud Practice Lead Executive)
Table 13: De-identification Methods
There are various use cases for using Cloud DLP – two of which are captured in Figure 17 below.
The left portion of the diagram shows de-identification and re-identification of PII. The depicted
solution creates an automated data pipeline to de-identify any sensitive data the FI may have
stored in Cloud Storage.
The right portion of the diagram shows automating the classification of data in Cloud Storage.
The depicted solution uses a data quarantine and classification system using Cloud Storage
triggers in Cloud Functions and Cloud DLP.
Example Project Example Project
Quara ntine Classificat ion 0 Classificat ion 1
Da ta
de-identif ication Da ta valida tion
Uploa ds files t o GCS
Cloud Storage Da taflow BigQuer y

Cloud Storage Cloud Storage Cloud Storage
User
Detects changes to GCS
Da ta re-identif ication
Perf or ms conf igurat ion File is moved to the pr oper classification bucket
management (key and
DL P templa te)
Cloud DLP Other Stora ge Da taflow
Secur it y
Admins
Cloud
Functions
Cloud DLP
Cloud KMS Pub/Sub
Figure 17: Cloud DLP Use-Cases

4.3.5.2 Encryption
Encryption is the process of encoding information so that only authorized users and accounts
can decipher the ciphertext into plaintext and access the information. Using encryption, private
and sensitive data is protected, and the overall security of data transfer and storage is
improved. In general, there are two forms of data that are encrypted: data at rest and data in
transit. For encryption, no third-party solutions are necessary. Google encrypts data at rest and
in transit by default. However, there are some caveats for data in transit encryption (i.e., times
when data in transit encryption is not performed), which will be discussed in the Data in Transit
section below.
4.3.5.2.1 Data at Rest

Data at rest encryption is used to protect data that is stored on a service, disk, or a form of
backup media. Within Google Cloud, data at rest is encrypted by default; the data is
automatically encrypted prior to being written to a disk in Google Cloud. This data is encrypted
with AES256 with exception to some legacy disks from before 2015 (uses AES128). The data is
also encrypted at rest at the service level above the disks by default.
For more information on the granularity of encryption by product, refer to the Encryption at
rest in Google Cloud document Key management will be discussed in the Section 4.3.5.3.
LAYER OF ENCRYPTION GOOGLE SOLUTION
Application Google Cloud Platform Services
Platform Database and file storage: protected by AES256 or AES128 encryption
Distributed file system: data chunks in storage systems protected by

AES256 encryption with integrity
Infrastructure
Block Storage
Hardware Storage Devices: protected by AES256 or AES128 encryption
Table 14: Google Default Data at Rest Encryption
4.3.5.2.2 Data in Transit

Data in transit encryption is used to protect data in motion. When data moves outside of the
physical boundaries not controlled by Google (i.e., to the internet or to an external IP address),
that data is encrypted and authenticated. Data movement within Google is generally
authenticated but not encrypted.27 When the data is in transit – Google encrypts it before
transmission, authenticates the endpoints, and decrypts the data upon arrival. TLS encryption
is an example of this process.
For requests entering from the internet or external IPs to Google Cloud services, Google’s front
end terminates traffic for incoming HTTP(S), TCP, and TLS proxy traffic; provides DDoS attack
countermeasures; and routes and load balances traffic to the cloud services. For more
information on encryption in transit in Google Cloud, refer to the Google documentation.

4.3.5.3 Key Management Service

Cloud Key Management Service (KMS) is how encryption keys are managed in Google Cloud. In
general, KMS is used to create and control the keys that digitally sign and encrypt the data.
Google’s Cloud KMS solution makes it easy for FIs to create and manage cryptographic keys
while controlling the key usage across the organization. Moreover, a KMS solution is important
for ensuring regulatory compliance and mitigates data exposure and exfiltration.
In addition to Cloud KMS, secrets can be managed with Secret Manager. Secret Manager stores
API keys, passwords, certificates, and other sensitive data. The data is stored in a single source
of truth, and all access to the data is audited and logged. In general, combining the usage of
Cloud KMS and Secret Manager is recommended to secure FIs Google Cloud environment.
It is also recommended that FIs use customer-managed encryption keys (CMEK) to encrypt
service’s data at rest using KMS keys that are self-owned and managed. The data cannot be
decrypted without access to the key. It is important to note that CMEK does not necessarily
provide more security than the default encryption mechanisms, and also results in additional
cost incurrence. The reason CMEK is recommended in banking.com is since it provides
additional capabilities, such as:28
1. Controlling the key

encryption key (KEK),
which makes it so the
underlying Google
managed data
encryption key (DEK)
cannot decode without
access to the KEK.
2. Protecting data using a key

that meets specific locality or
residency requirements,
including controlling the key
rotation period and the
creation and destructions of
keys.
3. Automatically or manually
protecting the data by
using a stricter encryption
standard than AES-256.
4. The ability to import your own

keys into CMEK.
The list of current Google Cloud services that have CMEK integrations can be found in the Using
Cloud KMS with other products document.
To learn more about how to leverage CMEK, refer to the Google Cloud Key Management Service
deep dive whitepaper.

4.3.5.3.1 KMS Access Control

It is recommended that projects that host keys or secrets have strong access controls. This
technical paper aligns with the recommendations in the December 2022 Google Security
Foundations Guide – including:
1. Designate an organization 2. Use Cloud KMS predefined roles or custom roles

administrator that's granted at the for least privilege and separation of duties. For
organization level, as noted on the example:
Cloud KMS separation of duties page. a. Separate administration
The Organization Admin functions as roles
the administrator for all the (roles/cloudkms.admin
organization’s cryptographic keys. and
Grant other IAM roles at the project roles/cloudkms.importe
level. If you have further concerns r) and usage roles for
about separation of duties, grant IAM keys.
roles at the key ring level or key level. b. Limit the use of roles/cloudkms.admin to
members of the security administration
team and to service accounts that are
responsible for creating key rings and key
objects through tools such as Terraform.
c. For asymmetric keys, grant roles that need
private key access
(roles/cloudkms.cryptoKeyDecrypter and
roles/cloudkms.signer) separately from
roles that don’t need private key access
(roles/cloudkms.publicKeyViewer and
roles/cloudkms.signerVerifier).
d. In general, grant the most limited set of
permissions to the lowest object in the
resource hierarchy.
Note: The December 2022 Google Security Foundations Guide provides additional guidance
on how to configure a KMS and Secret Manager solution, including resource organization,
infrastructure decisions, key lifecycle components, and several other areas.
4.4 Detective controls

Detective controls are based on how the environment is monitored, governed, and managed;
detective controls are involved in the day-to-day security analysis and monitoring of the Google
Cloud environment. The detective controls are built on top of the preventative controls
discussed throughout Section 4.3. By integrating detective controls (and by establishing
processes for the management and monitoring of these detective controls), an organization can
minimize the threat landscape and quickly identify and react to any signs of intrusion or
malicious behavior.

The detective controls for banking.com are grouped together and discussed based on their
capabilities. The groupings consist of Security Command Center, Cloud Logging, Security
Information and Event Management (SIEM), Security Analytics, and Asset Inventory Management.
Each of the controls that contribute to this framework will be discussed in the subsequent
sections, along with a deep dive into how these controls function.
Figure 18 depicts a high-level overview of the collection of the detective controls for
banking.com.
On-prem SIEM Legend
DC1
Log egress through
DC1 NAT gateway
External
SIEM Service
On-prem Router
Link local address: Log egress through
e.g., 169.254.10.2
on-prem
Colo Facility 1 Colo Facility 2

Peering Peering
Edge Edge

Common Folder
Base Hub Res trict ed Hub Logging Project SCC Project
Base Hub VPC Res trict ed Hub VPC

Cloud NAT
Reg ion Reg ion Cloud Pub/Sub
Zone Zone
Logging VPC
Subnet Subnet
Security
Cloud Cloud Dataflow VM Dataflow VM Command Center
VLAN VLAN
Router Router
a.b.c.d/24 a.b.c.d/24
Cloud Pub/ Cloud

Sub Storage
Firewall Logging API Log Router Log Sink SCC

Audit Logs Sources
Logs
Flow Logs Other Logs
Figure 18: Banking.com Detective Controls
4.4.1 Security Command Center

Google Cloud offers a Security Command Center (SCC) which functions as a security findings
dashboard and provides visibility into the organization’s Google Cloud environment. A security
findings dashboard is used to aggregate logs to identify infrastructure misconfigurations,
vulnerabilities, and active threat behavior. SCC then shares the findings with a SIEM tool. In
general, a security findings dashboard improves centralized visibility and control, allows an
organization to identify misconfigurations and compliance violations, and uncovers threats
and anomalies.
The SCC has two tier options: Standard and Premium. The Premium tier includes all the
features from the Standard tier and includes:
1. Event Threat Detection (ETD)

2. Container Threat Detection (KTD)
3. Security Health Analytics (SHA) with compliance monitoring
4. Web Security Scanner (WSS) Managed Scans (standard includes basic WSS)
5. Continuous Exports

It is recommended that organizations subscribe to the Premium tier, since the ETD, KTD, and SHA
are essential detective controls for protecting FI’s Google Cloud environments from risks such as
data exfiltration. In addition, SHA includes monitoring and reporting for compliancy standards
like PCI DSS. When setting up SCC, the default settings should not be changed unless there is a
specific security concern that necessitates changes. For more information on the costs
associated with Premium and Standard tier options, refer to the Google pricing guide.
In terms of functionality, the SCC aggregates findings from various security sources in the
Google Cloud environment. These sources can include SCC’s built-in services (ETD, KTD, SHA,
and Web Security Scanner), third-party partners (e.g., Qualys, Capsule8, etc.), or the
organization’s own security detector sources. SCC also includes detectors for Cloud DLP and
Anomaly Detection.
Note: If your sources include third-party partners, it is recommended that you generate
custom findings through the findings and sources APIs.
The security sources send their findings to SCC where they are displayed on SCC’s dashboard.
However, in order to quickly act on these findings, it is important that organization’s leverage the
built-in Security Command Center Pub/Sub topic to set up alerting and notifications. The SCC
Pub/Sub can also be connected to the SIEM solution, which will be discussed in Section 4.4.3.
Figure 19 depicts the notification and alerting process.
User
SCC Project
SCC API Notifications

SRA Functions Cloud Pub/Sub Feature
Security
Command Center
SCC
Sources
Figure 19: SCC Ingestion and Alerting
For a detailed implementation outline on setting up SCC Alerts and Notifications, refer to
Section 10.1.3 of the December 2022 Google Cloud Security Foundations Guide. The
Foundations Guide also includes examples of successful notification configurations and topic
patterns.
4.4.1.1 Policy Monitoring

Policy monitoring is the action of scanning an infrastructure’s data against pre-defined policies.
The scans can indicate whether there are any deviations from the baseline policies within the
Google Cloud environment. By performing these scans, policy monitoring increases visibility of
the cloud environment, addresses vulnerabilities, and monitors policies and compliance.
Without policy monitoring, there is a lack of auditing history of configuration changes to

resources. This can result in exploitable vulnerabilities and unintentional access.
Moreover, improper settings and configurations can increase risks associated with non-
compliance and potentially expose resources and its underlying data.
The Premium tier of SCC includes Security Health Analytics (SHA), which helps identify
misconfigurations and compliance violations inside of the organization’s Google Cloud
resources. The Vulnerabilities tab of the SCC dashboard summarizes and depicts the
misconfiguration and compliance findings that were identified by SHA – making it easily
actionable and digestible. These findings are presented as a table of recommendations which
are sorted by their severity and mapped to CIS, NIST-800-53, PCI-DSS, and ISO 27001
benchmarks. It is recommended that alerts and notifications are set up for SHA findings.
4.4.1.2. Threat Detection

Threat detection is the process of analyzing and searching resources for threats against multiple
security sources and threat feeds. Threat detection can include bad IPs, netblocks, file and IP
hashes, source and destination ports and IPs, volumetric anomalies, etc. Without insights into
the mechanisms and implications of threats – the overall attack surface of a cloud environment
is expanded. This increases the risk for compromised data and exfiltration. Active threat
detection can reduce the likelihood of data breaches, improve efficiency with anomaly
detection, and provide increased visibility into networks and the overall infrastructure. In Google
Cloud, threat detection is a component of the SCC. It is recommended that organization’s
leverage both threat detection features: Event Threat Detection (ETD) and Container Threat
Detection (KTD). Figure 20 depicts how ETD and KTD logically function in Google Cloud.
Firewall
Audit Logs
Logs
Event Threat
Detection
Security Log Sink

Command Center
Example Project
Pod
Cloud Pub/
Container Functions
Sub
Threat
GKE Detection
Figure 20: ETD and KTD
4.4.1.2.1 Event Threat Detection

Event Threat Detection is service included in the SCC Premium tier. ETD monitors the
organization’s assets and identifies threats from platform logs, network logs, and compute logs.
The threat findings are sent to SCC, and, with SCC Premium’s continuous export feature,
customers can directly send the logs to a Pub/Sub topic from SCC or any other sink (e.g.,
SIEMs, GCS, 3rd party tools, etc.). ETD works by receiving the logs from a detector and analyzes
them against a set of rules. Currently, Event Threat Detection includes the following default
rules:

DISPLAY NAME API NAME LOG SOURCE TYPES DESCRIPTION

Cloud Audit Detection of resources owned by
Logs: BigQueryAudit the protected organization that are
Exfiltration to Metadata data
external table org_exfiltration access logs saved outside of the organization,
Permissions: including copy or transfer
DATA_READ operations.
Cloud Audit
Logs: BigQueryAudit
VPC perimeter vpc_perimeter_viol Metadata data Detection of attempts to access
violation ation access logs BigQuery resources that are
Permissions: protected by VPC Service Controls.
DATA_READ
Malware: bad Cloud DNS Detection of malware based on a

domain malware_bad_domain Logs: Admin connection to, or a lookup of, a
Activity log known bad domain.
VPC flow logs

Firewall Rules Detection of malware based on a
Malware: bad IP malware_bad_ip logs connection to a known bad IP
Cloud NAT address.
logs
Cryptomining: cryptomining_pool_ Detection of cryptomining based

Cloud DNS
pool domain domain Logs: Admin on a connection to, or a lookup
Activity logs of, a known mining domain.
VPC flow logs

Cryptomining: Firewall Rules Detection of cryptomining
pool IP cryptomining_pool_ip logs based on a connection to a
Cloud NAT known mining IP address.
logs
Detection of successful brute

Brute force SSH brute_force_ssh syslog force of SSH on a host.
Detection of outgoing denial of

Outgoing DoS outgoing_dos VPC flow logs service traffic.
Detection of privileges granted to
Identity and Access Management
(IAM) users and service accounts
Persistence: Cloud Audit that are not members of the
IAM Anomalous iam_anomalous_grant Logs: Admin
Grant Activity logs organization. Note: currently, this
finding is only triggered for
Security Command Center users
with a gmail.com email address.
Detection of Identity and Access
Cloud Audit Management (IAM) users accessing
Persistence: iam_anomalous_be Logs: Admin
New Geography Google Cloud from an anomalous
havior_ip_geolocation Activity logs location, based on the geolocation
of the requesting IP address.
Detection of Identity and Access
Persistence: iam_anomalous_be Cloud Audit
Logs: Admin Management (IAM) users
New User Agent havior_user_agent accessing Google Cloud from an
Activity logs
anomalous user agent.
Cloud Audit Logs:
Discovery: Detects when a service account
Resource Manager
Service service_account_se credential is used to investigate the
lf_investigation data access logs
Account Self- roles and permissions associated
Permissions:
Investigation with that same service account.
DATA_READ
Table 15: ETD Default Rules

It is recommended to create custom detection rules in addition to the default rules – should the
FI need additional security analyses. This can be accomplished by storing the log data in
BigQuery, and then running unique or recurring SQL queries that capture your threat models.
To use ETD, logs must be enabled at the organization, folder, or project level. By default, these
logs are turned off. ETD should be used in areas of the environment that need additional security
analysis. Log sources for ETD include the following, along with a link to the enablement guides:
1. SSH logs/syslog
2. VPC flow logs
3. Cloud Audit Logs
a. Admin Activity logs are always written; you can't configure or disable them
b. Data Access logs
4. Cloud DNS logs
5. Firewall Rules logs
6. Cloud NAT logs
For an overview on ETD usage, refer to Google’s Using Event Threat Detection guide.
4.4.1.2.2 Container Threat Detection

Container Threat Detection (KTD) is an included service in the SCC Premium tier. KTD
continuously monitors the state of container images – evaluating all changes and remote
access attempts to detect runtime attacks in near-real time. This includes attacks such as
reverse shell execution, suspicious binary execution, and the linking of suspicious libraries.
KTD works by using a detector to collect low-level behavior in the guest kernel. As depicted in
figure 21 (above), event information is forwarded to detector service and analyzed to
determine whether there are any findings or incidents. If an incident is detected, it is
automatically written to SCC and, optionally, Cloud Logging. KTD contains the following
detectors by default:
DISPLAY DESCRIPTION INPUTS TO DETECTION

NAME
A binary that was not part of the original container The detector looks for a
image was executed. binary being executed
Added Binary that was not part of the
Executed If an added binary is executed by an attacker, it's a original container image
possible sign that an attacker has control of the or was modified from the
workload, and they are executing arbitrary commands. original container image.
A library that was not part of the original container The detector looks for a
image was loaded. library being loaded that
Added Library was not part of the
Loaded If an added library is loaded, it's a possible sign that original container image
an attacker has control of the workload, and they are or was modified from the
executing arbitrary code. original container image.
A process started with stream redirection to a
remote connected socket.
The detector looks for
With a reverse shell, an attacker can communicate from
Reverse Shell `stdin` bound to a
a compromised workload to an attacker-controlled remote socket.
machine. The attacker can then command and control
the workload to perform desired actions, for example, as
part of a botnet
Table 16: KTD Detectors

There are currently no custom detectors for KTD. It is recommended that FIs use KTD on any
containers that have access to sensitive information. For an overview on KTD usage, refer to
Google’s Using Container Threat Detection guide.
4.4.2 Cloud Logging

Logging and auditing are extremely important aspects of security in a cloud environment.
Logging and auditing tools effectively capture and aggregate network activity and system
events that can be examined for correlation/trends and/or inspected for anomalies by a SIEM
solution.
Google Cloud’s solution for logging and auditing is Cloud Logging. Cloud Logging allows
customers to centrally manage, analyze, monitor, and gain insights from log data in real time.
Cloud Logging ingests logs across a wide range of Google products. It is important to note that
the Cloud Logging API allows for the ingestion of custom log data from any source. The Cloud
Logging dashboard lets users analyze all the log data as it arrives in real time.
Log entries are made up of a variety of sources. These can include logs from GCE instances
starting up, new data being uploaded to Cloud Storage, a call made to an ML API, or anything
that an application writes to the standard or error output. After the logs are ingested and
aggregated, they are sent to a Log Sink and Logs Viewer for processing. Logs Viewer allows the
user to examine the log entries whereas the Log Sink can be used to export the logs to Cloud
Storage, BigQuery, or to Pub/Sub for archival, compliance/legal, and analysis purposes. Figure
21 depicts the logical architecture for Cloud Logging.
SIEM
External
SIEM Service
Common Folder
Logging Project
Cloud NAT Log Sink

Logging VPC
Log Router
Dataflow VM
Logging API
Cloud Pub/
Sub
Firewall
Audit Logs
Logs
Cloud
Storage
Figure 21: Cloud Logging Logical Architecture
Note: The time of log retention should be set in accordance with the FIs compliance
requirements.
Within the reference banking.com organization, project logs are centralized in a unified log
sink.

70
Section 9 of the December 2022 Google Cloud Security Foundations Guide provides a
guide on implementation of a Cloud Logging structure, which includes:
1. A standalone logging project named 2. A SCC Alert Center project named

Logging. This project contains Pub/Sub SCC. This project contains the
topics, Cloud Functions and a BigQuery notification Pub/Sub topics from the
instance used for collecting and Security Command Center. It's
processing logs generated by the separate from the logging project so
banking.com organization. that you have a clear separation of
duties between operations teams that
might need general log access and
the security team that needs access
to specific security information and
events.

There are some additional requirements for Logging from the CIS Benchmarks v1.1.0, some of
which have yet to be mentioned. These are listed in Table 18 along with their method of
prevention.
Note: For the “Add a filter text to the Logging/Metrics” prevention methods – refer to the
Google Cloud CIS Benchmarks v1.1.0 for a guide on filter creation.
2.0 LOGGING AND MONITORING
Ensure that Cloud Audit Logging is configured In Audit Logs, ensure that Admin Read,
2.1 properly across all services and all users from a Data Write, and Data Read are enabled for
project all services and no exemptions are
allowed.
2.2 Ensure that sinks are configured for all log entries Covered in Cloud Logging.
2.3 Ensure that retention policies on log buckets are In the Cloud Storage browser, ensure that
configured using Bucket Lock the Retention policy is checked.

2.0 LOGGING AND MONITORING
Ensure log metric filter and alerts exist for project

ownership assignments/changes (monitoring of Add a filter text to the Logging/Metrics.29
2.4
roles/owner)
2.5 Ensure that the log metric filter and alerts exist for
Audit Configuration changes Add a filter text to the Logging/Metrics.
Ensure that the log metric filter and alerts exist for
2.6 Custom Role changes Add a filter text to the Logging/Metrics.
2.7 VPC Network Firewall rule changes Add a filter text to the Logging/Metrics.
2.8 VPC network route changes Add a filter text to the Logging/Metrics.
2.9 VPC network changes Add a filter text to the Logging/Metrics.
2.10 Cloud Storage IAM permission changes Add a filter text to the Logging/Metrics.
2.11 SQL instance configuration changes Add a filter text to the Logging/Metrics.
Table 17: Logging CIS Benchmarks v1.1.0
4.4.3 Security Information and Event Monitoring

Security Information and Event Monitoring (SIEM) aggregates logs from activities and devices
(e.g., system logs and security control alerts, configuration information, asset information,
etc.) and provides threat detection, security monitoring, notifications, and alerts. The SIEM
solution has correlation rules and use-cases that identify a specific sequence of events that
indicate an anomaly that could represent a security threat, vulnerability, or incident.
Without a SIEM solution, an organization will not be alerted during attacks such as brute force
login attempts, file copying to drivers or emails, privilege escalation from the same
workstation, etc. The SIEM solution aggregates and consolidates data and provides a holistic
view of the network and infrastructure. This is a central security solution, and failure to
implement may result in non-compliance and a vastly expanded attack surface.

Figure 22 depicts the SIEM solution for the banking.com architecture (which is the same as
figure 21).
SIEM
External SIEM Service
Common Folder
Logging Project
Cloud NAT Log Sink

Logging VPC
Log Router
Dataflow VM
Logging API
Cloud Pub/
Sub
Firewall
Audit Logs
Logs
Cloud
Storage
Figure 22: SIEM Logical Architecture
In the figure, the logs are sent to a Pub/Sub topic, where they are filtered to a Dataflow instance
before being exported to Splunk. There are multiple ways to send logs to on-premises. Google
recommends sending the logs over Cloud NAT, as described in the Deploying production-ready
log exports to Splunk using the Dataflow guide. Alternatively, the FI can send the logs over an
interconnect connection or VPN.
4.4.4 Security Analytics

Cloud Logging and Security Command Center events can be exported to Chronicle, which is
purpose-built for security threat detection and investigation. Chronicle is built on Google’s
infrastructure, which lets FIs take advantage of Google's scale to reduce time to investigate
and triage potential threats. It correlates data from multiple security sources (including on-
prem systems) and threat feeds, providing a single timeline-based aggregated view of events
and detections. FIs can leverage Chronicle’s detection rules or use real-time search and
custom rules to create your own detections. In this way, Chronicle brings modern threat
detection to enterprises.
Refer to the Modern detection for modern threats: Changing the game on today’s threat actors
for more details on Chronicle and its benefits. Chronicle is recommended for use if FIs are
looking for an additional layer of security to help identify threats in their Google Cloud
environment.
Note: At the time of writing this paper, Chronicle should not be considered as a replacement
for a SIEM solution.

4.4.5 Asset Inventory

It is imperative that an organization maintain oversight of their cloud resources. In Google
Cloud, Security Command Center has a feature called Cloud Asset Inventory that performs
this. At large, Cloud Asset Inventory Services (CAIS) is the source of truth for asset inventory
and configuration states in Google Cloud. CAIS provides real time notifications for each
configuration change to each asset in a Google Cloud environment. In this way, CAIS gives FIs
centralized visibility into their Google Cloud assets across their organization.
Note: For a list of asset types covered by CAIS, refer to the Supported Asset Types
documentation.
Security Command Center uses CAIS as its reference for asset inventory. CAIS enables FIs to
view their assets in one place and view historical discovery scans to identify new, modified, or
deleted assets – while Security Command Center gives enterprises consolidated visibility into
their Google Cloud assets across their organization. For example, with CAIS, enterprises can
quickly understand:
1. The number of 2. Which resources 3. Where sensitive 4. How firewalls

projects in the are deployed data is located rules are
organization configured
CAIS also monitors for configuration changes. If a configuration or state change triggers a policy
violation, FIs can either review detected results in SCC Premium or build their own custom policy
violation detections using Cloud Functions. For example, if external Gmail accounts are being
granted IAM permissions to banking.com projects, Cloud Functions can check and alert on the
changes. If the Cloud Function detects that the policy has been violated, the Cloud Function
reverts the change and sends a custom finding to the Security Command Center.

Section 5
Appendix
75

01 02 03 04 Appendix 06
Appendix
Accenture is a global professional services company with leading capabilities in digital, cloud
and security. Combining unmatched experience and specialized skills across more than 40
industries, we offer Strategy and Consulting, Interactive, Technology and Operations services
— all powered by the world’s largest network of Advanced Technology and Intelligent Operations
centers. Our, 710,000 people deliver on the promise of technology and human ingenuity every
day, serving clients in more than 120 countries. We embrace the power of change to create value
and shared success for our clients, people, shareholders, partners and communities. Visit us at
www.accenture.com.
Copyright © 2022 Accenture. All rights reserved. Accenture and its logo are registered
trademarks of Accenture
5.1 Variations from the Google

Security Foundations Guide
The table below lists the sections that include variations from the Google Security Foundations
Guide.
SECTION ADDED COMPONENTS
7 additional org policies:

• gcp.resourceLocations
• compute.restrictLoadBalancerCreationForTypes
Section 4.2.2 – • compute.requireShieldedVm
Organization • sql.restrictAuthorizedNetworks
Policies • iam.workloadIdentityPoolProviders
• compute.restrictVpcPeering
• compute.trustedImageProjects
Section 4.3.1.1 –
Identity Inclusion of Azure AD for IdP federation instead of limiting to AD
Federation
Section 4.3.1.2 – 2 additional default groups:

Identity • grp-gcp-image-user@banking.com
Management • folder owners
Section 4.3.1.1 – Inclusion of Access approval for when resources need to be accessed by
Access Google support personnel.
Approval
Section 4.3.1.2 – Additional compliance requirements from CIS Benchmarks v1.1.0 for IAM.
Additional
Requirements
Section 4.3.2.1 – Information on how the compute.restrictLoadBalancerCreationForTypes

Cloud Load constraint affects functionality and the hierarchical/VPC firewalls.
Balancing
Section 4.3.2.2 –
Hierarchical Added additional rules for SSH/RDP remote access, Web Server access,
Firewalls and Inner VPC traffic.

01 02 03 04 Appendix 06
SECTION ADDED COMPONENTS
Section 4.3.2.4 – Added additional rules for SSH/RDP remote access, Web Server access,
VPC Firewalls and Inner VPC traffic.
Inclusion of specific details on Cloud NAT. Cloud NAT should be used on the
Section 4.3.2.6 projects hosting sensitive data for private resources that need egress traffic
– Cloud NAT to the Internet.
Section 4.3.2.7 – Inclusion of Cloud Armor security policies for protection of web applications
Cloud Armor
Section 4.3.2.8 –
Additional Additional compliance requirements from CIS Benchmarks v1.1.0 for
Requirements Networking.
Section 4.3.3 – Inclusion of security controls for a sub-set of commonly used services inside
Service of Google Cloud.
Security
Section 4.3.3.6
– Additional Additional compliance requirements from CIS Benchmarks v1.1.0 for Services.
Requirements
Section 4.3.4.1 – Inclusion of methods for addressing the PCI DSS requirement of FIM on
File Integrity endpoints.
Monitoring
Section 4.3.5.1 –
Data Loss Inclusion of Cloud DLP for de-identification of sensitive data on resources.
Prevention
Section 4.4.1.2.1
Event Threat Detection default rules and enablement. TBD – example of
– Event Threat custom rules.
Detection
Section 4.4.1.2.2
– Container Container Threat Detection detectors.
Threat Detection
Section 4.4.2.1 –
Additional Additional compliance requirements from CIS Benchmarks v1.1.0 for
Requirements Logging. TBD – Adding all required Logging/Metric filters to the main section.
Table 19: Variations from Google Foundations

01 02 03 04 Appendix 06
5.2 Commonly Used Acronyms

ACRONYM DEFINITION
2FA Two-Factor Authentication
AD Active Directory
AD FS Active Directory Federation Services
CMEK Customer Managed Encryption Keys
CSEK Customer Supplied Encryption Keys
CSP Cloud Service Provider
DDoS Distributed Denial of Service
DLP Data Loss Prevention
DRS Domain Restricted Sharing
ETD Event Threat Detection
FI Financial Institution
FIM File Integrity Monitoring
GCDS Google Cloud Directory Sync
GCE Google Compute Engine
GCLB Google Cloud Load Balancer
Google Cloud Google Cloud Platform
GCR Google Container Registry
GKE Google Kubernetes Engine
IaaS Infrastructure as a Service
IAM Identity and Access Management
IAP Identity Aware Proxy

01 02 03 04 Appendix 06
ACRONYM DEFINITION
IP Internet Protocol
KMS Key Management Service
KTD Container Threat Detection
MFA Multi-Factory Authentication
NAT Network Address Translation
OS Operating System
PaaS Platform as a Service
PCI Payment Card Industry
PII Personally-Identifiable Information
SaaS Software as a Service
SAML Security Assertion Markup Language
SCC Security Command Center
SHA Security Health Analytics
SIEM Security Information and Event Management
SSO Single Sign-On
TLF Top-Level Folder
UBLA Uniform Bucket Level Access
VM Virtual Machine
VPC Virtual Private Cloud
VPC-SC Virtual Private Cloud Service Controls
VPN Virtual Private Network
vTPM virtual Trusted Platform Module
WAF Web Application Firewall
XSS Cross-Site Scripting

Table 19: Commonly Used Acronyms

Section 6
Bibliography

01 02 03 04 05 Bibliography
Bibliography
1 IBM Security. (2020). Cost of a Data Breach Report 2020.
https://www.ibm.com/security/digital-assets/cost-data- breach-report/#/
2 Ibid.
3 Cloud Security Alliance. (2020). Cloud Usage in the Financial Services Sector.
4 Ibid.
5 Google Cloud. (2021, December). Google Cloud security foundations
guide. https://services.google.com/fh/files/misc/google-cloud-
security-foundations-guide.pdf
6 Sound Practices to Strengthen Operational Resilience”, FRB, OCC, FDIC
7 Godfrey, N., Hannigan, D., Knott, D., & Abel, J. (2021). Strengthening Operational Resilience
in Financial Services by Migrating to Google Cloud. Google Cloud.
https://services.google.com/fh/files/misc/google_cloud_operational_resilience_fin_serv.pdf
8 “Third-party dependencies in cloud services”, Financial Stability Board
9 NIST. (n.d.). Defense-In-Depth. Computer Security Resource Center.
https://csrc.nist.gov/glossary/term/defense_in_depth#:~:text=4%20under%20Defense%2Din
%2DDepth,technology%20 are%20caught%20by%20another
10 Stella, J. (2019, August 1). A Technical Analysis of the Capital One Cloud
Misconfiguration Breach. Fugue. https://www.fugue.co/blog/a-technical-analysis-of-
the-capital-one-cloud-misconfiguration-breach
11 Google Cloud. (2021, December). Google Cloud security foundations
guide. https://services.google.com/fh/files/misc/google-cloud-
security-foundations-guide.pdf
12 Ibid.
13 Ibid.
14 Google Cloud. (2021, June 16). Shared VPC overview. Shared
VPC Overview. https://cloud.google.com/vpc/docs/shared-vpc
15 Khattar, M. (2020, July 11). Mitigating Data Exfiltration Risks in
GCP using VPC Service Controls. Medium.
https://medium.com/google-cloud/mitigating-data-exfiltration-
risks-in-gcp-using-vpc-service-controls-part-1-82e2b440197
16 Verdejo, D. (2018, October 15). High availability NAT gateway at
Google Cloud Platform with Cloud NAT. Medium.
https://medium.com/bluekiri/high-availability-nat-gateway-at-
google-cloud-platform-with-cloud-nat-8a792b1c4cc4
17 Google. (n.d.). Google Cloud Armor custom rules language reference. Google Cloud.
18 Google Cloud. (2021, August 10). Using VPC Flow Logs. Google Cloud.
https://cloud.google.com/vpc/docs/using-flow-logs
19 Google Cloud. (2021, August 10). VPC Flow Logs overview. Google Cloud.
https://cloud.google.com/vpc/docs/flow-logs
20 UpGuard Team. (2019, June 27). Data Warehouse: How a Vendor for Half the Fortune 100
Exposed a Terabyte of Backups. UpGuard. https://www.upguard.com/breaches/attunity-
data-leak

01 02 03 04 05 Bibliography
21 Chakraborty, S. (2020, June 8). 5 ways to enhance your cloud storage security and data
protection. Google Cloud. https://cloud.google.com/blog/products/storage-data-
transfer/5-ways-to-enhance-your-cloud-storage-security-and-data-protection
22 Ibid.
23 Ibid.
24 Google. (2022). Introduction to column-level security. Google Cloud.
https://cloud.google.com/bigquery/docs/column-level-security-intro
25 Google Cloud. (2021, December 19). Installing antivirus and file integrity monitoring on
Container-Optimized OS. Google Cloud.
https://cloud.google.com/architecture/installing-antivirus-and-file-integrity-monitoring-
on-container-optimized-os
26 https://cloud.google.com/compute/docs/os-patch-management
27 Vergadia, P. (2020, October 30). Understanding Data Encryption in Google Cloud.
Medium. https://medium.com/google-cloud/understanding-data-encryption-in-google-
cloud-c36d9095fb38
28 Google Cloud. (2021, December 19). Customer-managed encryption keys (CMEK). Google
Cloud. https://cloud.google.com/kms/docs/cmek#cmek
29 CIS Benchmarks v1.1.0. (2020, March 11). CIS Google Cloud Platform Foundation
Benchmark.

Accenture is a global professional services company with leading capabilities
in digital, cloud and security. Combining unmatched experience and
specialized skills across more than 40 industries, we offer Strategy and
Consulting, Interactive, Technology and Operations services — all powered by
the world’s largest network of Advanced Technology and Intelligent
Operations centers. Our 710,000 people deliver on the promise of technology
and human ingenuity every day, serving clients in more than 120 countries. We
embrace the power of change to create value and shared success for our
clients, people, shareholders, partners and communities. Visit us at
www.accenture.com.
Copyright © 2022 Accenture. All rights reserved. Accenture and its logo are
trademarks of Accenture.
This document is produced by consultants at Accenture as general guidance.

It is not intended to provide specific advice on your circumstances. If you
require advice or further details on any matters referred to, please contact
your Accenture representative.
This document makes descriptive reference to trademarks that may be owned

by others. The use of such trademarks herein is not an assertion of ownership
of such trademarks by Accenture and is not intended to represent or imply the
existence of an association between Accenture and the lawful owners of such
trademarks. No sponsorship, endorsement, or approval of this content by the
owners of such trademarks is intended, expressed, or implied.
Google Cloud Secure Banking Framework

GCP Security Framework For FSIs Technical Paper 1677480212

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GCP Security Framework For FSIs Technical Paper 1677480212

Uploaded by

Copyright:

Available Formats

Security

Section 2 Financial Services Sector

Section 3 Google Cloud as an Enabler for

Section 4 Reference Framework

Google Cloud Secure Banking Framework 2

Google Cloud Secure Banking Framework 3

Google Cloud Secure Banking Framework 4

Google Cloud Secure Banking Framework 5

Google Cloud Secure Banking Framework 6

Business agility: Increased efficiency and resiliency:

Reduced operating costs: Improved security:

Google Cloud Secure Banking Framework 7

Google Cloud Secure Banking Framework 88

Google Cloud Secure Banking Framework 9

Financial Services Sector

Transform operating, Address regulatory Embed proper

Establish processes for

Google Cloud Secure Banking Framework 1010

Fast: Frictionless: Scalable:

Proactive: Cost effective: Compliant with regulatory

2.1 Cloud Adoption

Compute and Data analytics and data Usage of cloud native

Google Cloud Secure Banking Framework 11

2.2 Concerns and Challenges

• Loss of reputation from

• Contractual concerns with

• Data privacy concerns.

• Unmet requirements from

Google Cloud Secure Banking Framework 12

Google Cloud Secure Banking Framework 13

Google Cloud as an Enabler for

3.1 Shared Responsibility Model

Google Cloud Secure Banking Framework 14

Web Application Security

Access and Authentication

Guest OS, Data & content

Storage & Encryption

Hardened Kernel & IPC

ON-PREM IAAS PAAS SAAS

Figure 1: Shared Responsibility Model5

3.2 Operational Resiliency of

Google Cloud Secure Banking Framework 15

1. Google Cloud's infrastructure

2. Google Cloud offers a wide

Secure Infrastructure Secure Internet COMMS

Secure Services Third Party Risks

Secure Data Pandemics

Figure 2: Components that Comprise Operational Resiliency in Google Cloud

Google Cloud Secure Banking Framework 16

Google Cloud Secure Banking Framework 17

• Preventative controls (Section

• Detective controls (Section 4.4)

Google Cloud Secure Banking Framework 18

Important: This technical paper is an illustrative reference framework, not a one-size-fits-all

The following tools are leveraged to secure the banking.com environment.

SECURITY AREA CAPABILITY TOOL LEVERAGED NOTES

Policy and Google Cloud Native

Google Cloud Native

banking.com uses AD,

Google Cloud Identity Groups are used for

Access Control Google Cloud IAM None

Single Sign-On Google Cloud SSO None

Google Cloud Secure Banking Framework 19