Data Security in the SaaS Age: Rethinking Data Security

Posted under: Research and Analysis

Securosis has a long history of following and publishing on data security. Rich was the lead analyst on DLP about a zillion years ago during his time with Gartner. And when Securosis first got going (even before Mike joined), it was on the back of data security advisory and research. Then we got distracted by this cloud thing, and we haven’t gone back to refresh our research, given some minor shifts in how data is used and stored with SaaS driving the front office and IaaS/PaaS upending the data center (yes that was sarcasm). We described a lot of our thinking of the early stages of this transition in Tidal Forces 1 and Tidal Forces 3, and it seems (miraculously) a lot of what we expected 3 years ago has come to pass.

But data security remains elusive. You can think of it as a holy grail of sorts. We’ve been espousing the idea of “data-centric security” for years, focusing on protecting the data, which then allows you to worry less about securing devices, networks, and associated infrastructure. As with most big ideas, it seemed like a good idea at the time.

In practice, data-centric security has been underwhelming as having security policy and protection travel along with the data, as data spreads to every SaaS service you know about (and a bunch you don’t know about), was too much. How did Digital Rights Management work at scale? Right.

The industry scaled back expectations and started to rely on techniques like tactical encryption, mostly using built-in capabilities (FDE for structured data, and embedded encryption for file systems). Providing a path of least resistance to both achieve compliance requirements, as well as “feel” the data was protected. Though to be clear, this was mostly security theater, as compromising the application still provided unfettered access to the data.

Other techniques, like masking and tokenization, also provided at least a “means” to shield the sensitive data from interlopers. New tactics like test data generation tools also provide an option to ensure that developers don’t inadvertently expose production data. But even with all of these techniques, most organizations still struggle with protecting their data. And it’s not getting easier.

The Data Breach Triangle

Back in 2009, we introduced a concept called The Data Breach Triangle, which gave us a simple construct to enumerate a few different ways to stop a data breach. You need to break one of the legs of the triangle.

  • Data: The equivalent of fuel – information to steal or misuse.
  • Exploit: The combination of a vulnerability or an exploit path to allow an attacker unapproved access to the data.
  • Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive.

Most of the modern-day security industry focused on stopping the exploit, either by impacting the ability to deliver the exploit – firewall/IPS or preventing the compromise of the device – endpoint protection. There also were attempts to stop the egress of sensitive data via outbound filters/FW/web proxy or DLP.

As described above, attempts to either protect or shield the data have been hard to achieve at scale. So what do we get? Consistent breaches. Normalized breaches. To the point that an organization losing tens of millions of identities no longer even registers as news.

SaaS exacerbates the issue

Protecting data continues to get more complicated. SaaS has won. As we described in Tidal Forces, SaaS is the new front office. If anything, the remote work phenomenon driven by the inability to congregate in offices safely will accelerate this trend.

Protecting data was hard enough when we knew where it was. I used to joke how unsettling it was back in 1990 when my company outsourced the mainframe, and it was now in Dallas, as opposed to in our building in Arlington, VA. At least all of our data was in one place. Now, most organizations have dozens (or hundreds) of different organizations controlling critical corporate data. Yeah, the problem isn’t getting easier.

Rethinking Data Security

What we’ve been doing hasn’t worked. Not at scale anyway. We’ve got to take a step back and stop trying to solve yesterday’s problem. Protecting data by encrypting it, masking it, tokenizing it, or putting a heavy usage policy around it wasn’t the answer, for many reasons. The technology industry has rethought applications and the creation, usage, and storage of data. Thus, we security people need to rethink data security for this new SaaS reality. We must both rethink the expectations of what data security means, as well as the potential solutions. That’s what we’ll do in this blog series Data Security for the SaaS Age.

We haven’t been publishing as much research over the past few years, so it probably makes sense to revisit our Totally Transparent Research methodology. We’ll post all of the research to the blog, and you can weigh in and let us know that we are full of crap or that we are missing something rather important. Comments on this post are good or reach out via email or Twitter.

Once we have the entire series posted and have gathered feedback from folks far smarter than us, we package up the research as a paper and license it to a company to educate its customers. In this case, we plan to license the paper to AppOmni (thanks to them), although they can decide not to license it at the end of the process – for any reason. This approach allows us to write our research without worrying about anyone providing undue influence. If they don’t like the paper, they don’t license it. Simple.

In the next post, we focus on the solution, which isn’t a product or a service; rather it’s a process. We update the Data Security Lifecycle for modern times, highlighting the need for a systematic approach to identifying critical data and governing the use of that data in the various SaaS applications in use.

– Mike Rothman
(0) Comments
Subscribe to our daily email digest

*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: