This post was originally published by amol sarwate
In the long saga of systemic PII data breaches, Pfizer is the latest victim. Personally identifiable information, or PII, is any data that could potentially identify a particular person. Examples of PII information include a full name, address, identifiers like driver’s license numbers, bank account numbers, or email addresses. In the 2020 fall season, Razor, a gaming hardware manufacturer, lost thousands of customer PII records. Broadvoice, a VoIP provider also leaked hundreds of customer PII records. And more than a dozen dating websites had PII data of their clients exposed, causing more than just embracement.
Much like how the COVID pandemic indiscriminately affects organizations, PII data breaches can strike anywhere. And also like the pandemic response, diligence and prevention can go a long way toward inoculating your organization against the threat.
The root cause in the majority of PII data breaches is the gross misconfiguration of cloud services. In the case of Pfizer, the breach was the result of a misconfiguration of data stored in the Google Cloud Service (GCP). Preventing such a breach starts with a simple visibility and security audit of cloud infrastructure. In this blog, I will go over some GCP preventative measures to keep your organization safe. While you can implement most of the recommendations manually, I highly recommend an automated tool such as Halo. With the free CSPM offering, automating GCP protection is a no-brainer.
Protecting GCP Against PII Data Breaches
Usually, identity and access come first in a cloud infrastructure security strategy. But given the number of PII data breaches caused by misconfigured cloud storage buckets, I think this is one of the first places to start. Organizations should make sure that there are no anonymous or publicly accessible storage buckets to protect against a breach like the one suffered by Pfizer. You’ll also want to look at your network and compute instances for potential attack vectors.
GCP Cloud Storage
GCP Cloud Storage offers two systems for granting users permission to access buckets and objects: Cloud Identity and Access Management (Cloud IAM) and Access Control Lists (ACLs). These systems act in parallel—in order for a user to access a Cloud Storage resource, only one of the systems must grant the user permission. GCP Cloud IAM allows you to grant a variety of permissions at the bucket and project levels. ACLs are used only by Cloud Storage and have limited permission options, but they allow you to grant permissions on a per-object basis. Ensure that cloud storage buckets have uniform bucket-level access enabled.
Identity and Access Management
The fundamental concepts of identity and access management remain the same in all public clouds, although implementation will differ; GCP is no exception. At a minimum, multi-factor authentication (MFA) and security key enforcement should be enabled for all admin accounts. Service accounts also play a vital role in today’s infrastructure. Only GCP-managed service accounts keys should be associated with service accounts, and service accounts should not have admin privileges. Enforcing separation of duties while assigning service accounts related roles to users also protects against PII data breach. Also, ensure a key rotation policy of 90 days or less for both KMS encryption keys and API keys.
Network
In GCP, a project organizes all your Google Cloud resources. A project consists of a set of users, a set of APIs, billing, authentication, and monitoring settings for those APIs. The default network is typically not a good option, since it is pre-configured, with automatically created firewall rules that do not get audit logged. When configuring your network, ensure restrictions for access to common protocols like SSH, RDP, and enable VPC flow logs. Use strong ciphers for HTTPS or SSL and refrain from using weak RSASHA1 for zone-signing keys in Cloud DNSSEC.
Read more here: www.cloudpassage.com
