By Shane Fonyi, UC Health Security Analyst
From Breach to Baseline: How Secure Defaults Changed the Game
Data security has changed dramatically over the last decade. With the rise of attacks powered by large language models (LLMs) and widely available AI tools, focus on data security and defense-in-depth tactics has increased. In the late 2010s, there were several major breaches related to misconfiguration in cloud data storage services like Amazon S3, Google Drive, and Azure Storage Accounts. The most notable exposure was the records of over 14 million Verizon subscribers who had called customer service. These files contained names, phone numbers, and account PINs and were accessed through an easily guessable AWS S3 storage URL maintained by a third-party vendor. Today, these incidents are rarer because cloud providers have tightened default permissions, added safeguards, and more clearly flagged dangerous configurations to users setting up these services.
Changing their services’ default settings was an important step for cloud vendors. How vendors present these menus and options plays an important role in securing the data customers store with these providers. Shifting from a model where secure configurations were optional to one where they are on by default, with warnings before they can be removed, has helped reduce some of the most glaring data security issues. Most people accept the default settings when onboarding to a new service or tool, trusting the vendor offers a sufficient level of security. It’s the same behavior seen with terms and conditions, where a cursory glance is often the best-case scenario. Secure defaults close that gap and go a long way toward raising the baseline security of a platform.
How Cloud Providers Raised the Bar
Over the years, there have been many changes to default settings and user interfaces to increase baseline security for several widely used cloud services. One of the most significant was to AWS S3 storage permissions. In December 2022, Amazon announced that it would begin automatically enabling the Block Public Access setting and disabling access control lists for all new S3 buckets regardless of how they are created. Together, these settings prevent administrators from accidentally exposing a bucket’s contents to the entire internet, which happened in the Verizon breach.
Overriding these defaults now requires acknowledging a warning banner that explains the consequences of the change. AWS also began encrypting all new objects uploaded to S3 by default starting January 5, 2023. New objects are automatically encrypted using either AWS default encryption or customer-provided keys. The default follows best practices and helps address compliance concerns, while customer-provided keys add an extra layer of security by requiring permission to access the keys on top of access to the S3 bucket.
In 2024, both AWS and Azure added multi-factor authentication requirements for administrative access to their respective management portals. This change helps protect organizations from account takeovers caused by weak passwords and phishing. Phishing is an increasingly significant cause of security incidents, according to the 2026 Verizon Data Breach Investigations Report. Finally, in 2024, Google Cloud began applying a default set of organization policies to all new organizations, enforcing constraints on key creation, protocol forwarding, storage bucket access, default editor role grants, and other configurations. These defaults close off some of the most commonly exploited vectors for unauthorized access to a Google Cloud organization.
Why Vigilance Still Matters
These incremental changes have been good for the overall health of the internet and for organizations that use cloud resources. With reports that up to 89% of enterprises use cloud services to host their infrastructure and around 94% use cloud storage for data backup and recovery, it is more important than ever for cloud providers to be proactive in protecting their customers’ data. However, many of these changes are not retroactive, so cloud administrators need to confirm that these settings are enabled in existing environments. According to the Datadog State of Cloud Security Report, roughly 1% of S3 buckets are effectively public. While that number has trended down thanks to the new defaults, an investigation by Rubrik found that about 21% of publicly accessible buckets contained sensitive data such as protected health information (PHI), personally identifiable information (PII), or payment card data (PCI), available to anyone.
As cloud providers continue to enhance their default security baselines, administrators still need to do their due diligence to ensure they have configured their environments with these policies and other best practices. Maintaining an up-to-date inventory of cloud resources helps, and nearly every major cybersecurity framework calls for one. Reviewing cloud storage, organizational, and access settings at a regular cadence can help surface issues and drift from best practices before an incident occurs. Your campus IT department can provide resources, and organizations like the Center for Internet Security (CIS) publish benchmarks at CIS Benchmarks® that administrators can use to align with best practices.
Author
Shane Fonyi
UC Health Security Analyst
Digital Risk and Security
UC Office of the President
Share YOUR Cybersecurity, Privacy, or Digital Risk Story!
Do you have a story, initiative, or project to share for the Cybersecurity Across UC series? Send us information, an outline, a story you have written, or even a published story that is relevant. We’d love to include it in this new series! Submit a UC Tech News blog intake form found here.
Questions? Email us at UCTechNews@ucop.edu.
