3 Reasons Why Database Security is Undervalued

Some of the most valuable data in cyberspace resides in databases. Yet—especially among SMBs—database security tends to be misunderstood, undervalued and inadequate.

If your business has critical databases, have you protected all their diverse attack surfaces? Where are your most dangerous gaps and how can you quickly and cost-effectively close them? What does a holistic database protection program look like?

To share a database expert’s view on top database security risks and how to address them, Robert Buda, President at Buda Consulting, joined the latest episode of The Virtual CISO Podcast. The show’s host is Pivot Point Security CISO and Managing Partner, John Verry.

Like money in the bank

When you walk into a bank, where is the biggest lock? On the vault. Which makes sense because the vault holds the bank’s most critical assets—the stuff with monetary value—whose compromise would have the biggest business impact.

Analogously, many orgs should put the most cybersecurity around their most critical data assets, many of which reside in databases. Yet database security tends to be, as John frames it, “exceptionally undervalued.”

Here are the top 3 reasons Bob has observed for why this illogical situation is so widespread.

One: We view a database as like a bank vault

Bob relates that many people view databases the way they view safes in banks: “That safe is a box and it’s got a front door and we put our valuables in it and close that front door and spin the lock. And there’s a perception that other than that front door, there’s no way into that safe. We take it for granted that the manufacturer of the safe has sealed all the seams. There’s no back door. There’s only one attack surface, and it’s that front door.”

“If we think of databases as like safes, we have that same impression—but it really is very different than that,” Bob cautions. “There are a lot of back doors in a database. So, if all we do is secure the front door, we’ve left ourselves wide open.”

In other words, those outside the database realm tend to view databases too simplistically, without full appreciation for how interconnected they are with the rest of our IT.

Two: We underestimate the risk from both intentional and unintentional insider threats

Bob shares another common view that results in misjudging database security risk: underestimating the likelihood and the potential impact of insider threats to your sensitive data. That includes everything from a rogue admin to a successful phishing attack.

“Most of those [insider] threats wouldn’t make it to the database if you’ve already secured the perimeter,” emphasizes Bob. “In other words, we are relying too much on that perimeter security. We’re thinking all the threats are outside that wall.”

Three: We overestimate our perimeter security

John cites the basic logic of risk management: “If we have a risk that is undertreated, fundamentally there are two reasons why that would happen. Either we don’t understand the risk, or we’ve deemed the risk to be acceptable.”

But when it comes to databases, the problem is usually a lack of understanding of the risk versus the knowing acceptance of a risk.

“It’s hard to know the risk until you do a risk assessment,” asserts Bob. “So, it’s a chicken and egg problem. Another problem for some companies, even when they know there’s risk, is that mitigating those risks can be phenomenally expensive and very, very time-consuming. One case that comes to mind is a bank that we did some work for a while back that had over 10,000 SQL databases across their portfolio. And doing a full security assessment on 10,000 databases is just a monumental task.”

Nevertheless, a risk that can put you out of business is a risk that you need to treat. What is the impact if the risk is realized versus the cost to mitigate it? Have you explored the best use of technology/automation to bring down mitigation costs? Can you evolve your business processes to reduce the rate at which risk is accumulating?

For example, in that bank’s environment of 10,000 proliferating databases, controls and policies around the creation of new databases could be effective at reducing risk. Another approach could be database consolidation to reduce the overall attack surface by decreasing the number of databases.

What’s next?

To listen to the full show with Bob Buda and John Verry, click here.

Can zero trust architecture help with protecting databases from insider threats? This blog post explains: Zero Trust Prevents Data Breaches, Not Intrusions