Learning from the State of Washington’s Data Breach

This blog was originally published by AppOmni here.

Written by Brian Soby, CTO and Co-Founder of AppOmni.

It's not surprising to hear about another data breach in the news, especially one involving a large SaaS deployment like the State of Washington announced in February 2022. SaaS has greatly accelerated the speed at which companies can move. The largest enterprise SaaS platforms are almost infinitely extensible so a customer can configure these systems to automate and run the most complex of business data flows and processes. But there's no such thing as a free lunch: there’s a necessary level of complexity in SaaS platforms to support that high degree of flexibility. However, SaaS seems to be the one area of technology where there hasn’t been adoption of comprehensive security management platforms to manage and continuously monitor configuration changes.

Many of us at AppOmni, as career security professionals, have handled numerous security incidents while leading internal security teams for the major SaaS providers. We've seen and experienced firsthand that the inevitable result of sensitive data combined with highly complex platforms and insufficient oversight is a never-ending stream of data breaches. Time and time again, the incidents came down to the same problem: customer configuration inadvertently exposing or over sharing data. We'll continue to see data breaches until customers realize that they have a major role to play in keeping these systems secure by having deep and continuous visibility into their SaaS configurations and whether those are consistent with their intent.

It's likely many of us in the cloud and SaaS industry are partly to blame for this situation. After all, we spent years telling customers that the "cloud is secure" and sharing how well we as SaaS vendors managed our platform, quickly applied patches, and had massive teams of expensive application and software engineers constantly reviewing every change and every feature. While all of that is generally true for the major SaaS vendors, it also downplays the critical role of the customer. The customer exclusively owns and is responsible for the configuration that instructs these SaaS platforms what to do, what data to share, and what levels of access to give.

What are the reasons for these misconfigurations?

The vast majority of the incidents I was involved in (both as as a security practitioner at SaaS vendors and as a security consultant) follow two customer configuration themes: "Whoops, we didn't realize we had exposed that," and "Yes, technically we configured the system to expose that data but we didn't think anyone would be able to access it."

The first theme, “We didn’t realize that was exposed,” is very easy to do. There are constant changes and many moving parts in large SaaS applications. That's the trade-off for accelerating your business: things move FAST. Your IT department has teams of people whose job is to constantly reconfigure these platforms to support new business flows. You likely have extensions and packages installed from vendors that are constantly updating and pushing those changes into your SaaS environments. Even your end users have a say in SaaS configuration when they share files or records, and integrate new services (often without the knowledge of IT or security) via OAuth in the context of their own user accounts. Without a comprehensive management program including a configuration management solution that deeply understands these products, there's no rational basis to expect to be secure.

The second theme is something any security team immediately recognizes: someone taking a shortcut that creates a critical dependency on "security through obscurity." Here’s what I describe as "the golden rule of SaaS:" SaaS platforms will do exactly what you configure them to do.

That's it. If you configure your SaaS platforms in accordance with least privilege and reasonable data sharing, it's very likely you're not going to be in the news for a data breach from one of these systems. If you configure them to share your critical data with the world, the SaaS platforms will 100% faithfully execute that configuration and it's only a matter of time before someone who "speaks SaaS" notices and your company is in the headlines. There is no amount of UI-skinning, link hiding, or other security-through-obscurity tactic that will save you here. SaaS platforms are large, complex systems with dozens or hundreds of major feature areas and each one faithfully executes its configuration. We've learned many times before but it bears repeating: security through obscurity will absolutely not work.

What’s the solution?

The solution to both of these situations is the same. Security teams need to be involved early in the SaaS adoption process and have meaningful and deep visibility into how these systems are configured so they can quickly identify both inadvertent exposures and questionable security decisions. If you're a security team that has delegated security to the business units using the SaaS applications, I can tell you from experience that security is very likely not happening because SaaS users don't view security as their job or priority. The problem with that is the security teams likely don’t even have logins to the massive SaaS applications they’re responsible for managing, never mind the months of training required to develop any reasonable level of expertise in each one.

Further complicating the security visibility problem is that these SaaS deployments are often being managed for customers by third-party integrators. While many integrators employ exceptionally talented folks, including some of the sharpest and most knowledgeable SaaS experts I have ever met, they can't escape the problem of complexity that leads to data breaches.

If you're a security team at a company using an integrator for a SaaS project (or even the vendor's own professional services team), ask questions. Ask what they use to continuously monitor the security and configuration of the systems you've hired them to build. Ask how security is integrated into their release process so they know exactly what's about to go out the door. Ask how they detect unwanted changes by end-users or third-party extensions that have been auto-updated. If you're on a procurement team, make it a requirement for the integrators to have a mature SaaS practice that includes comprehensive security tooling.

The experiences I had as a security practitioner, along with that of my colleagues, inspired us to develop a solution to improve SaaS security. We saw the challenges our customers faced managing their SaaS applications. We heard the questions they asked. And we knew there was a better way to manage SaaS security. Don’t just check security boxes or look for superficial and generic "vulnerabilities" with no bearing on actual risk. Implement deep visibility and management to secure your SaaS platforms so your company isn’t the next data breach headline.

About the Author

Brian Soby is the CTO and co-founder of AppOmni. He has more than 20 years of security experience. Brian’s past roles include Partner at FreeFly Security, Director of Product Security at Salesforce, Lead Information Security Engineer at MITRE, and Network Security Engineer at Raytheon.