Learning from the State of Washington’s Data Breach

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 early 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.” It seems that we as an industry continually learn this lesson and then we do it all over again with every generation of technology and pretend that things are different this time. I’ll state for the record 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 in order to 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 see that 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 the integrator uses 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 a procurement team at one of these companies, make it a requirement for the integrators to have a mature SaaS practice that includes comprehensive security tooling.

AppOmni was built because of our experience as security practitioners in the SaaS industry. We saw the challenges our customers faced managing their SaaS applications. We heard the questions they asked. And we developed a solution. The AppOmni platform provides deep visibility and management around the real-world security challenges in the most important and critical SaaS platforms in the industry.  We’re not just checking security boxes or looking for superficial and generic “vulnerabilities” with no bearing on actual risk. We built AppOmni to stop data breaches in SaaS – and we’re serious about it.

If you’d like to understand your SaaS risk, especially if you’re a government entity like we saw in this recent announcement, please get in touch with us. We can very quickly identify and surface misconfigurations and data leaks and help implement a continuous monitoring solution. We can help you figure out what happened, how to fix it, and how to get things back up and running quickly.

Related Resources