Payment Card Industry (PCI) on GCP: part 2

We continue our previous blog post about PCI DSS compliance on GCP with more PCI requirements examples:

PCI Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Cloud Security Command Center helps security teams gather data, identify threats, and respond to threats before they result in business damage or loss. It offers deep insight into application and data risk so that you can quickly mitigate threats to your cloud resources and evaluate overall health. With Cloud Security Command Center, you can view and monitor an inventory of your cloud assets, scan storage systems for sensitive data, detect common web vulnerabilities, and review access rights to your critical resources, all from a single, centralized dashboard. It can help you comply with several requirements, including sections 5 and 6.6.

GCP Cloud Security Command Center

PCI Requirement 6: Develop and maintain secure systems and applications

PCI Requirement 6.2 talks about ensuring all systems are patched with the latest security patches within one month of release. Having a robust image pipeline can help with this, but creating the new images with the patches and depreating images that aren’t patched, so that old and obsolete images aren’t used inadvertently.

  • Use image families to make sure your automation and users use the latest image
  • Use state flags to mark images as DEPRECATED, OBSOLETE, DELETED
GCP PCI Image life cycle

PCI Requirement 7: Restrict access to cardholder data by business need to know

PCI Requirements:

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.1.1 Define access needs for each role, including: 

• System components and data resources that each role needs to access for their job function 

• Level of privilege required (for example, user, administrator, etc.) for accessing resources.

7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.

7.1.3 Assign access based on individual personnel’s job classification and function.

7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed. 

This access control system(s) must include the following:

7.2.1 Coverage of all system components.

7.2.2 Assignment of privileges to individuals based on job classification and function.

7.2.3 Default “deny all” setting.

Once access needs for each job function are defined, custom roles can be created provide granular control over the exact permissions to access system components and data resources

  • Create groups based on job functions, and assign custom roles to those groups
  • Job function groups can be nested in job classification groups
  • Custom roles can be defined at the organizational level

Review available permissions and their purpose through the
API Explorer (search for product)

Combine predefined roles

Combine permissions

PCI Requirement 7: continuing…

Understanding IAM core principles is key to implementing separation of duties and least privilege for PCI compliance as defined in requirement 7

  • User are typically humans – think AD/LDAP users
  • Service accounts are typically “robot accounts” assigned to a service with only the permissions that service/robot needs to do its job
  • Groups are a collection of users 
  • IAM roles are a set of permissions 

Read from top to bottom

  • Users can be part of groups
  • Service accounts can be part of groups
  • Users and groups can be granted rights to service accounts via IAM roles
  • Through the IAM roles, they can be granted access to resources
  • Service Accounts are also resources – grant service account user role to allow user to run operations as the service account

PCI Requirement 8: Identify and authenticate access to system components

Requirement 8 covers identity and authentication management, and GCP can help customers implement this in both GCP, and in the customer’s own applications.

  • Cloud Identity provides identity and authentication to GCP.
  • Customers can leverage Cloud Identity-Aware Proxy (Cloud IAP) and other Google tools to implement identity and authentication on their applications.
  • Google websites and properties use robust public key technologies to encrypt data in transit: 2048-bit RSA or P-256 ECDSA SSL certificates issued by a trusted authority (currently the Google Internet Authority G2).

PCI Requirements:

8.1 Define and implement policies and procedures to ensure proper user identification management for non consumer users and administrators on all system components as follows:

8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

8.1.3 Immediately revoke access for any terminated users.

8.1.4 Remove/disable inactive user accounts within 90 days.

8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows: 

• Enabled only during the time period needed and disabled when not in use. 

• Monitored when in use.

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: 

• Something you know, such as a password or passphrase 

• Something you have, such as a token device or smart card 

• Something you are, such as a biometric.

8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

8.2.3 Passwords/passphrases must meet the following: 

• Require a minimum length of at least seven characters. 

• Contain both numeric and alphabetic characters. 

Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.

8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication. 

Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.

8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.

PCI Requirement 9: Track and monitor all access to network resources and cardholder data

PCI Requirement 9 talks about tracking and monitoring all access to network resources and cardholder data. There are multiple logging options available in GCP to help you achieve this. 

Stackdriver Logging collects data from many sources including Google Cloud Platform, VM instances running Stackdriver Logging agent (FluentD agent), and user applications.

Effective log entries contain answers the following questions:

  • Who or what acted?
  • Where did they do it?
  • When did they do it?

Audit logs available for most GCP resources and services

Audit logs generate two types of logs:

  • Admin Activity 
  • Data Access
GCP PCI Log Collection

Contact our GCP Security experts for a FREE GCP Security consultation, today!

Payment Card Industry (PCI) on GCP

GCP adheres to the PCI DSS requirements set forth for a level 1 Service Provider. GCP is required to be compliant with PCI DSS and all applicable requirements that directly apply to a service provider.

As of Nov 11, 2020 here is the list of 93 GCP services that ARE in scope for PCI DSS:

Access Approval
Access Context Manager
Access Transparency
Apigee Edge
AI Platform Data Labeling
AI Platform Notebooks
AI Platform Training and Prediction
App Engine
AutoML Natural Language
AutoML Tables
AutoML Translation
AutoML Video
AutoML Vision
BigQuery
BigQuery Data Transfer Service
Cloud Asset Inventory
Cloud Bigtable
Cloud Billing API
Cloud Build
Cloud CDN
Cloud Composer
Cloud Console
Cloud Console App
Cloud Data Fusion
Cloud Data Loss Prevention
Cloud Deployment Manager
Cloud DNS
Cloud Endpoints
Cloud Filestore
Cloud Functions
Cloud Healthcare
Cloud HSM
Cloud Interconnect
Cloud Key Management Service
Cloud Life Sciences (formerly Google Genomics)
Cloud Load Balancing
Cloud NAT (Network Address Translation)
Cloud Natural Language API
Cloud Router
Cloud Run (fully managed)
Cloud Run for Anthos
Cloud SDK
Cloud Shell
Cloud Source Repositories
Cloud Spanner
Cloud SQL
Cloud Storage
Cloud Translation
Cloud Vision
Cloud VPN
Compute Engine
Container Registry
Data Catalog
Dataflow
Datalab
Dataproc
Datastore
Dialogflow
Event Threat Detection
Firestore
GCP Marketplace
GKE Hub
Google Cloud Armor
Google Cloud Identity-Aware Proxy
Google Kubernetes Engine
Identity and Access Management (IAM)
Identity Platform
IoT Core
Managed Service for Microsoft Active Directory (AD)
Memorystore
Network Service Tiers
Orbitera
Persistent Disk
Pub/Sub
Resource Manager API
Security Command Center
Service Consumer Management
Service Control
Service Management
Speech-to-Text
Stackdriver Debugger
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Trace
Storage Transfer Service
Talent Solution
Text-to-Speech
Traffic Director
Transfer Appliance
Video Intelligence API
Virtual Private Cloud (VPC)
VPC Service Controls
Web Security Scanner

PCI examples on GCP:

PCI Requirement 1: Install and maintain a firewall configuration to protect cardholder data

GCP PCI

PCI Requirement 2: Do not use vendor-supplied defaults

The PCI DSS contains a set of rules that describe how to set up machines that are part of a payment-processing architecture. These rules can be implemented in several ways, but Packer from Hashicorp offers an easy process to automate baking images.

Baking images helps meet requirements (and others)

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. 

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. 

2.2.2  Enable only necessary services, protocols, daemons, etc., as required for the function of the system. 

2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Image baking

  • Base image – OS or hardened image from CIS with unnecessary packages removed
  • Core – packages and libraries needed for all instances (security, monitoring, language specific packages)
  • Application – application code

PCI Requirement 3: Protect stored cardholder data

PCI Requirement 3 talks about encryption at rest, there are multiple options on GCP to accomplish is
Google encrypts data at-rest by default with no configuration required by customers. In some cases, customers may want additional control over encryption for many reasons. For that reason, Google has two additional key management options. In the middle option, customers may choose to utilize customer-managed encryption keys (CMEK) using Google Cloud Key Management Service (KMS). You can define access controls to encryption keys, establish rotation policies, and gather additional logging into encryption/decryption activities. In both the default and customer-managed case, Google remains the root-of-trust for encryption/decryption activities. On the right-hand side, customers may choose to use customer-supplied encryption keys (CSEK) in some Google services, such as Google Cloud Storage, in which Google is no longer in the root of trust. Using CSEK comes with the added risk of data loss, as Google can not help you decrypt data if you lose encryption keys. Furthermore, customers do not have to choose one key management option only. You can make use of the default encryption for most of your workload, meets regulatory requirements, and add some additional control for select applications

GCP PCI Example 2

Data Loss Prevention API can be used to sanitize PCI data

Requirement 3.4 stipulates that a PAN must be unreadable anywhere it is stored. While Google automatically offers encryption at rest, it doesn’t automatically perform the one-way hashes, truncation, or tokenization that the rules also require. Use GCS with DLP for truncation or tokenization or use KMS for strong cryptography with managed keys.

GCP PCI DLP

PCI Requirement 4: Encrypt transmission of cardholder data across open, public networks

PCI requirement 4 talks about encryption transmission of cardholder data across open, public networks.

By default, any data sent to a data cloud service is encrypted by default using TLS from the user to the frontend (using BoringSSL) 

Once inside Google, what happens to your data? 

  • Google encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries not controlled by Google or on behalf of Google.
  • Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.

You can also take advantage of HTTPS load balancing to encrypt incoming customer traffic. Istio can be used to secure traffic between VMs. Cloud VPC can be used to establish a secure VPN tunnel between on-premises environment and payment-processing environment.

GCP PCI Encryption

Contact our GCP Security experts for a FREE GCP Security consultation, today!

Auditing the security of your GCP environment

There are plenty of tools out there that can perform a security audit for your environment, but none of them are using Google’s security best practices.

We are trying to change that by providing a simple, customizable approach to performing a security audit for all the projects that your organization has.

From the customer side, all you need to do is to provide us with an export of your cloud inventory assets and then we will apply all the Google’s security best practices as documented under the Cloud Foundation Toolkit project. The end result will be a very comprehensive security report which will identify the security areas that need your attention.

The topics covered under this security audit:

  1. Resource management
    • GCP org hierarchy
    • Environments & resource isolation
    • Resource provisioning
    • Organization policies
  2. Identity, Authentication, and Authorization
    • User & group management
    • Administrative roles
    • Authentication
    • Assigning IAM roles
    • Service Accounts
  3. Network security
    • VPC architecture
    • Firewall rules
    • Network logging
    • VPC Service Controls
    • DDoS and WAF
    • Identity Aware Proxy
  4. VM security
    • VM identities
    • Remote access
    • Image management
  5. GKE security
    • GKE cluster provisioning
    • Secure cluster default configurations
  6. Data security
    • Encryption key management
    • Cloud Storage security
    • BigQuery security
    • CloudSQL security
    • Data Loss Prevention
  1. Security Operations
    • Logging
    • Monitoring
    • Policy scanning

Here is a sample of the summary of those recommendations :

Recommendations organized by Priority
SectionHighMedLowTotal
Cloud Resource Management2005
Identity, Authentication, and Authorization4509
Network Security310014
Virtual Machine Security3205
GKE Security25313
Data Security92011
Security Operations0202

Part of our security report will include specific security recommendations for the areas that are marked as High Priority for you.

Here is an example of such specific security recommendations:

Use an organizational structure that is based on your business structure that is usually grouped by Cloud IAM permissions and Organization policy inheritance
Use folders to apply Cloud IAM permissions and organization policies will be applied. For example, folder structure can reflect environments such as development and production, where more restrictive policies and limited Cloud IAM access is granted to the production environments.

Avoid extensive use of folder level IAM permissions, but instead, apply permissions at a project or resource level.

If you are interested to learn more, signup for your FREE trial of our Google Cloud Platform (GCP) security audit service, today!