What do you think is the state of database security today?

It isn’t good. Pretty bad, actually. Companies have almost no control over their databases. It always amazes me how little visibility organizations have into what’s going on with their data. If you consider the vast number of data breaches that occur all the time, it is pretty clear that the situation is grim. Attackers can only obtain millions of records from a database. That means any significant breach is a database breach. These results are conclusive, definitive proof. Actually, the horrifying reality is that it is only getting worse, so maybe “Bad” is an understatement and I should say “Catastrophic”.

You say the situation is only getting worse, so does that mean database security is deteriorating?

No, breaches are getting worse because the perimeter is penetrated more frequently. Companies protect the perimeter rather than the database. As the perimeter disintegrates, you see more perimeter breaches that turn into database breaches.

Companies rely solely on perimeter protection, and that concept doesn’t work anymore. Actually, it never worked well, but it is getting worse. Since they have no defenses behind the perimeter to protect the data, any penetration turns into a data breach.

Do you think this is a global crisis in every organization, or are these a few isolated cases?

While some organizations undoubtedly fare better, the pervasive nature of breaches scattered across organizations of all sizes and verticals indicates widespread systemic failures. It’s not that organizations aren’t trying; it’s that their efforts are largely ineffective. If existing measures worked, we wouldn’t witness the relentless cascade of breaches we see today.

Beyond the obvious cascade of data breaches, do you see any other red flags?

When I talk to companies, I usually start by asking some questions to see where they’re at. For example, “Do you know which users, programs, and IPs connected to your database in the past week?”. If security people and DBAs don’t know who’s connecting to their database, there is clearly no control. Having a list of who’s been accessing their databases seems like the absolute minimum. I rarely get a proper answer to this question.

The next question is “Who accessed your sensitive data in the past week?”. To answer that, companies need to know the databases and tables that contain sensitive information and who’s been accessing those. Getting an answer to this question is rare. Not knowing who’s accessing sensitive data is, clearly, a big problem. How can you protect something when you don’t even know where it is and who’s using it?

Finally, one of my favorites is “Do you get regular alerts from your database security system?“. A surprising symptom of ineffective security is the absence of false positive alerts. Some people consider a lack of false positives to be a good thing. However, counter-intuitively, zero false positives means you are unlikely to receive alerts when a real security incident occurs. A healthy security system generates occasional false positives. Their absence is a red flag indicating security is too lax and probably wouldn’t trigger an alarm during an actual breach.

Does that mean most companies don’t secure their databases?

No, they obviously implement security measures. They have password policies, encryption, least-privilege, and more. The problem is that the measures they deploy are unable to detect or prevent a breach. Their security measures are not targeting real threats. They don’t target the attack vectors hackers use to penetrate their database. While they have some form of security, it wouldn’t alert them if an attacker got in and exfiltrated all their data. Or even worse, if someone changed something in their data.

That’s interesting. Why do you say changing data is worse than stealing it?

Maybe worse is a matter of perspective. Most people consider data theft to be the worst outcome. However, consider this:

Companies store data for a reason, right? They use it to make decisions and take actions. There’s no point in storing data without a purpose. But what if the data was maliciously modified? It means that decisions and actions based on that data are manipulated. Maybe it’s easier to think about it another way: would you make decisions or take actions based on manipulated information?

Insecure data can be actively misleading. It’s better not to store data than to store it insecurely.

Getting back to the security measures, why do you think they fail? I think everyone is wondering how someone can penetrate a database and steal or manipulate data.

You ask “why they fail”, and I first want to emphasize that whether or not we correctly understand this failure, the reality is that current security measures don’t hold up. Since we constantly have data breaches, it means the “regular” security measures are ineffective. Acknowledging this reality is a vital first step – what we’re doing isn’t working.

But it’s a fair question to try to understand how someone can penetrate a database. It’s the foundation for building a better defense.

Consider the simplest scenario: stolen DBA credentials. Most organizations wouldn’t know if an attacker connected to the database as a DBA. There are no security measures that target a DBA who logs in with a valid user and password. Such logins could be used maliciously by a hacker with stolen credentials or by a DBA abusing their privileges.

Similarly, logging into the database server would allow an attacker to connect to the database without a password. Penetrating the database server is a question of operating system security with multiple attack vectors. To simplify the example, let’s reuse the concept of stolen system administrator credentials. The hacker can leverage such credentials to penetrate the database server and, from there, he doesn’t need a password to connect to the database.

I’m not saying administrator credentials are the primary method for penetrating a database, but these are simple examples that bypass all the common security mechanisms.

I understand DBA accounts are a problem, but are there other attack vectors that don’t rely on DBA accounts?

All database accounts have attack vectors. These vectors often come in three flavors: employee abuse, stolen credentials by an external actor, and software vulnerabilities.

Let’s take, for example, the application account. It could be abused by an employee who knows the password. Alternatively, that password could also be stolen by a hacker. Finally, a bug in the application software could allow an attacker to leverage the application database access to run their own malicious SQL. For example, SQL injection is an exploit of an application flaw.

If you consider standard database security measures, the unfortunate reality is that none of them address any of these attack vectors. Measures such as password policies, encryption, and least-privilege cannot address these real-world threats.

If all database accounts pose a threat, how can companies combat these? Is there a solution?

Absolutely. Advanced database activity control solutions help you address all these threats and more. For example, our solution, Core Audit, does that superbly. The trick is not to look at individual threats but to approach them based on how they deviate from proper database activity behavior.

You must ensure, regardless of the solution you choose, that you achieve effective security. Vendors often try to confuse customers about what’s important and provide them with an irrelevant list of threats. You must apply common sense and validate that the solution can combat real threats relevant to you.

For example, you could use the basic questions I mentioned earlier: who connected, who touched sensitive data, and do you receive a small number of false positive alerts. Alternatively, you can test whether you can detect basic attack vectors like credential theft, privilege abuse, and SQL injection. But the most important thing is that you always feel you are in control over your database, not the other way around. You must always have visibility into what’s going on and reasonable confidence that you’ll know when bad things happen.

You mentioned Database Activity Control, so could you give some examples of how we can combat the threats you mentioned?

Let’s take DBA accounts as an example. There are multiple threats from external actors stealing privileges or from internal abuse of privilege. However, there are two things DBAs don’t usually do: they don’t change data in the database, and they shouldn’t access sensitive information.

By alerting or blocking these types of activity, you can prevent a breach that leverages DBA accounts. That works regardless of who’s abusing them – an external hacker or an internal employee.

If you’re looking at blocking, you can also establish separation of duties where security personnel can temporarily allow particular DBA accounts to bypass these measures. For example, if DBAs need to occasionally fix data.

The point is that if DBA accounts cannot change data or access sensitive data, they cannot be used in a data breach.

That seems like a solution that only works for DBA accounts, but what about the application account?

For the application account, you need to apply different controls that restrict it to the behaviors it normally exhibits.

The first step is to limit connections to the application server and program. You should alert or block connections that don’t originate from the application program or its IP addresses. Restricting the application account to the application software will prevent credential theft and abuse of privilege, as it will only allow the application software to connect.

The second step is to alert on a SQL anomaly. That is a change in the application behavioral profile. Applications always repeat the same SQLs, and you can alert when they issue a different SQL construct. That will detect an exploit of an application bug, like a SQL injection attack.

Application controls differ from DBA controls, but they are just as effective as they prevent the account from doing things it’s not supposed to do.

I see we discussed a couple of isolated examples, but where would you suggest someone should start? What are the first steps to securing a database, and how do you ensure you cover everything?

That’s a great question. The first step is to understand the database you’re securing. It’s impossible to secure something that you don’t know what it is or who does what inside it. Securing something is like solving a puzzle – you first need to take a good look and understand what you’re up against. At least that’s how I always start.

To be more specific, you need to identify which databases contain sensitive data and locate this data inside them. After that, you need to understand who’s accessing those databases, using what programs, and what they do inside.

As you noticed, one of the approaches is to go by database accounts. It’s a good approach because it’s easy to get a list of all the database accounts and divide them into groups based on the type of activity they generate. Well, you also need to validate using your database activity solution that what you think these accounts do is what they actually do.

Once you know the account types and understand their activity profiles, you can design controls that alert on changes in that profile.

I can see you suggest tailoring solutions to each account type, but are there more generic recommendations? Something that doesn’t require diving into the activity profile of each account?

Sure. There are simpler practices that will improve security. Actually, I recommend combining these with the previous approach to further lock down security. I’ll give three examples:

Change control is an important aspect of ensuring the database is in a secure state. Monitoring DDLs allows you to validate that all database changes are part of an approved change control. Using metadata snapshots is another complementary method of ensuring you know what’s happening with your database configuration, objects, users, roles, etc.

Another example is session control. For instance, you can set up anomaly alerts on new users, on users active at irregular times of day, on users connecting from unusual programs or IPs, etc. These types of controls help detect attacks like credential theft.

A more powerful control is an anomaly on sensitive tables. You should know if there’s a new SQL construct touching a sensitive table, or a new user, IP, etc. While these types of controls may require some tuning to reduce the false positives, it is a powerful control that combats most threats.

It seems like there’s a lot of work to secure each database. What if companies have many databases they need to secure?

Excellent question. There are three answers to that. The first is to prioritize. Start with the most critical databases and, over time, secure more and more systems. I’m not a big fan of this approach because it means we leave a lot of data unprotected. It also means that whatever is not in the first pass will probably never get secured because focus will shift elsewhere.

A second answer says to set up basic measures on all the databases and more comprehensive security on the critical ones. We might never get to secure more databases, but at least we have some control over everything. Basic controls will save both money and time, so it’s a nice compromise.

The best answer, in my opinion, is that database security needs to be ingrained into the organization’s DNA. We need to change how we operate because, as I mentioned earlier, there’s no point in storing data without securing it. Insecure data is unreliable, which makes it useless, and it is a liability if it were stolen.

Once data security becomes part of our DNA, performing the steps I mentioned to secure data will be part of building and maintaining a database. I know most people only see it as a distant future, and it is definitely not the reality of most organizations today. But it is something we should aim for.

Talking about the future – where do you see things going?

We can look at the nearer future and the more distant one. The current situation with data breaches is unbearable. There is mounting pressure from customers, legislators, regulators, and more. This pressure will continue to mount as long as data breaches continue. So far, breaches are on the rise, so it’s clear that more attention, focus, and money will pour into stopping them.

On the other side, you see companies that tried everything except what works. They spent a fortune securing their perimeters and every piece of infrastructure except the database. They even tried shifting responsibility to other entities through insurance or outsourcing, but it doesn’t work. The only path left is data-centric security. However, I suspect the security industry will find more ineffective investments before they start protecting their data.

The security industry is a little funny in how it follows trends and fashion. Every year, many companies follow the latest trend. That is not the way to achieve good security, but it is how the market behaves. Sadly, some of these trends created even more breaches through supply chain attacks.

Change will only come when we start protecting the data. Whether due to a new trend or other market forces, I don’t see any other solution, and the pressure will continue to mount until that happens. At the same time, the demand for a solution is already tremendous, and it seems like something will have to give in soon. We’re getting closer and closer to the breaking point.

Once companies realize modern activity control is the only way to secure databases and the data inside them, that’s when the security industry will have a massive shift.

What kind of shift are we talking about?

There are two parts. First, we’ll see a change in training security people. Securing a database is not the same as configuring a firewall or filtering SPAM emails. Security personnel will need a better understanding of database technologies and how to secure them.

I think you’ll also see integration of security into the purchasing and deployment of applications and databases. You see a little of that now, but it’s just scratching the surface. For example, I expect identifying sensitive data will be a required step in all deployments. You won’t have security people scrambling after the fact to figure out what data is inside the application and the database and where it’s stored.

Is this massive shift only about training, education, and ingraining security into the database and application rollout?

No, the long-term view is much bigger than that. Database activity control is just the tip of the iceberg. Nowadays, security is based on three false premises. These premises limit what we believe is possible and what we attempt to achieve.

Perimeter: First is the obsession with protecting the perimeter, thinking that if we can somehow keep the bad guys out, everything will be ok. This premise is already disintegrating, but people cling to it because they don’t know what else to do. We need to protect the perimeter, but that shouldn’t be our main focus.

Prevention: Second is the belief that prevention is better and more important than detection. It’s great to prevent, but prevention cannot be sensitive enough to block everything. There’s a long discussion about false positives and false negatives, with a simple bottom line: Detection is far more powerful at identifying attacks and breaches, and we must invest more heavily in it. Security managers will have to embrace the fact that we cannot rely on automated systems to block everything and keep us safe.

Data Volume: Third and most important is the notion that we can’t handle a lot of data and that we already collect too much. Security is about controlling activity, which is controlling what people do. There’s a lot of activity in information systems, and we shy away from trying to collect and control all of it. Once we accept that it’s possible, the entire security landscape will transform. We won’t have to focus only on exceptions, alerts, and security events. We will control everything.

Will that really be possible? Will we be able to control all the activity?

We are already doing it today. Blue Core Research technologies allow you to control all the database activity. That is available right now. Databases are the busiest systems in the IT landscape, and we have the technologies and methodologies to help you control all the activity in them.

We also adapted these technologies to help you secure Java application activity workloads and web client activity. That future is already here.

Once people realize that controlling the activity is possible and is the only way to secure systems, the entire security industry will shift. We will turn the tables on attackers and be on the winning side of this cat-and-mouse game.

Guadalupe: Thank you for your time and the optimistic outlook towards the future. I hope we win this war and stop this scourge of cyberattacks and data breaches. Do you have any final thoughts you’d like to share?

People must start to realize that information security is about protecting information. Yes, we can protect the network, email, etc., but we must start by protecting the information. If you aren’t controlling activity that accesses your data, you will never be successful at protecting it.