Today, we learned that Pfizer suffered a huge data breach because of unsecured cloud storage. The exposed data, including email addresses, home addresses, full names, and other HIPAA related information, was found on a misconfigured Google Cloud storage bucket. It is believed that highly confidential medical information came from automated customer support software that had been stored in the Google database. It is unclear how long this data had been stored or who had access to this information.
It is clear that storing data within the public cloud has become the norm and companies of all sizes are now faced with complex identity and data challenges. We learned from Capital One, and unfortunately now from Pfizer, that even with the biggest teams, budgets, and skillsets, the public cloud is extremely complex. When enterprise organizations are moving at the speed of the cloud and developing at a rapid pace, errors will occur and data can be exposed if you don’t have the appropriate tools.
2020 has had its share of high-profile incidents and, unfortunately, we are adding to this growing list global pharmaceutical giant, Pfizer. The data, which included full names, home addresses and email addresses, contained hundreds of conversations between Pfizer’s automated customer support software and people using its prescription pharmaceutical drugs. This breach comes off the tale of a busy September for healthcare and other organizations.
In September alone, an estimated 100,000 customers of Razer, a purveyor of high-end gaming gear ranging from laptops to apparel, had their private info exposed via a misconfigured Elasticsearch server. And, a misconfigured, Mailfire-owned Elasticsearch server impacting 70 dating and e-commerce sites was found leaking PII and details such as romantic preferences. Also this month, the Wales arm of the NHS announced that personally identifiable information (PII) of Welsh residents who have tested positive for COVID-19 was exposed, by uploading it to a public server. An unsecured server belonging to the popular Town Sports fitness chain has exposed over 600,000 customers and staff members’ personal information.
Here at Sonrai Security, we firmly believe that public cloud will be more secure than enterprise data centers. But, in public cloud, defense in depth is not achieved with multiple layers of network firewalls and similar controls but rather:
Roles and policies with ‘read-data’ access (not to be confused with ‘list’ or ‘describe’) across data stores like google databases might not seem over-privileged, but on specific databases (or any data store that contains SPII) ‘read-data’ access is more sensitive than being able to write to the data store.
With cloud, it is not unusual for users, compute, containers, and serverless functions to have access to critical data along many different permission paths:
And the list goes on and on. The Pfizer issue seems to have leveraged a direct path but given time, an attacker will explore all possible paths to escalate privilege, and this must be modeled by organizations to understand the actual blast radius of any resource, identity, or role. Security architecture teams must be relentlessly hard on DevOps teams creating too many identities that workloads can ‘assume.’
You have tens of thousands of compute instances, thousands of data stores, hundreds of cloud accounts, and countless agile dev teams. To use public cloud the right way, you must verify ‘least privilege’ by observing actual activity to uncover unused trust relationships that could allow escalation. Understanding trust relationships requires more than looking at the roles in isolation. Baselining platform config is important but insufficient. Baselining trust relationships illuminates your blast radius and helps you reduce it.
GCP databases and other data stores continue to be a focus, but this is just the tip of the iceberg. In their defense, Pfizer may have extensive logs and audit data. But, we have seen so many cases within organizations where an audit of object-level access isn't even enabled on databases. Monitor all data access and identity activity with alarms for unusual behaviors. Also, Hashicorp Vault, and many other platform services contain critical data too and must be continuously monitored.
Polling cloud APIs for configuration without understanding access patterns does not give the full-view needed to reduce permission to a least privilege model. Flat compliance checks don’t provide enough information to understand how a workload relates to other resources or how an identity with permission to use a key can then access data in another location. It is nearly impossible to know who or what can access a piece of data without modeling organization service controls policies, decoding and normalizing all of the possible cloud permissions, understanding resources statements, conditions, boundary conditions, group memberships, ACLs, and many more items. Doing a few API calls to regex match strings in JSON might get you past an auditor, but trying to understand how an attacker is going to exploit a workload requires a much deeper understanding of cloud platforms.
With public cloud security, aspirations can be grand. The task is not just about finding mechanisms to ‘secure the cloud’ but to reimagine security so that the result is far superior to a traditional data center and enterprise network. This is definitely possible with the public cloud. Set up appropriately, the public cloud is remarkably well-instrumented. By coupling this visibility with access, privilege modeling, and continuous monitoring, you can achieve the least privilege security model that was not possible before.
Helping organizations better understand and manage cloud IAM policies and associated risks, like a data breach, is some of what Sonrai’s platform can do. Let us know if you would like to see for yourself.