For most enterprises, the number of databases are increasing as they migrate to the cloud. Additionally, the number of users, applications, and services that access the databases is surging — leading to increased data exposure and risk. Now, with data breaches reaching new record highs, it’s fair to ask: who owns database security? Does the responsibility fall on the database administrators who work closest with the data, productivity teams (e.g. data, developers) who are seeking additional access, or on the cyber security team who have the experience and mandate to secure the organization?
It’s the right question to ask, as more organizations are becoming aware of this security gap – but the answer looks different than expected. As we will explain below, database security is less about delegating responsibility (though that’s still important) and much more about planning and execution across multiple teams. First, let’s look at why database security doesn’t have a clear owner already.
A Brief History of Database Security
Until quite recently, database security was an afterthought. Databases lived deep inside the corporate network behind multiple other security layers. And the only people accessing databases were the administrators themselves, a small or single-person group in most cases. In this environment, databases didn’t really need security because they were not under much, if any, threat. There were only 157 data breaches in the US in 2005 compared to over 4,100 publicly disclosed data breaches in 2022.
Database security became a much bigger issue with the rise of the cloud. Cloud database security became critical because databases no longer lived exclusively inside corporate networks, and data requests did not originate exclusively from there either, obliterating the inherent security of databases and blurring the lines between authorized users and attackers. Database security wasn’t a foregone conclusion any longer. As it becomes both a bigger priority and a bigger problem – exacerbated greatly by the pandemic – the question of who owns database security grows urgent to answer.
Many companies have never done that before. In an earlier era, DBAs thought little about security, while their counterparts on the security team thought little about data. Database security was no one’s priority in particular because it didn’t need to be. But with data breaches hitting record highs and companies making big bets on their data, database security cannot be ignored, neglected, or unclaimed any longer.
A Different Perspective on Database Security
No single team has all the answers. Security teams who spend little time with databases need to know things like: what data exists, where, who has access, and how is the data being used (e.g. is it being copied, moved, edited, deleted)? On the other side, productivity teams with minimal security expertise need to know about: data risks, emerging threats, data security governance and compliance obligations, and practical defensive measures. The point is that neither of these teams are equipped to own database security independently because both have a key piece of the puzzle.
Fortunately, all parties involved want the same thing: automated least-privilege for data.
Productivity teams want immediate access to the data they need for development and analysis. Data security teams, for their part, want users to only access approved data sets while sensitive, private, or strategic data stays strictly off-limits. The emphasis on least-privilege access underscores how both sides, productivity and security, have unique and complementary roles to play in database security.
Seeing database security as a matter of alignment rather than ownership has a direct impact on database defenses and data breach risks. More data falls under the defensive umbrella where stronger, and more seamless protections are in place. But it’s important to understand that data accessibility and efficiency improve as well once the productivity and security teams collaborate to balance risk, identify data, define policies, and orchestrate controls. In that way, secure databases are also more seamless, streamlined, and systematic – and that benefits everyone.
3 Core Principles of Database Security
With productivity and security teams both on board with database security, the question of “who owns data security” evolves into “what does database security entail?” It has three key components:
- Discovery – Identifying all databases, knowing their contents, knowing which accounts have database access, and mapping the activity so companies have a clear understanding of what database security will need to encompass and what challenges and opportunities it might encounter along the way. Database security depends on defenses and policies applying universally to all data.
- Access – Authenticating all database requests to distinguish between good and bad actors and to keep attacks from reaching the valuable and regulated data inside databases. Then, authorizing only the least privileges necessary based on who is requesting what data. Database security depends on being able to authenticate and authorize requests, both accurately and comprehensively.
- Audit – Tracking database access – who accesses what – for audit purposes. Maintaining a clear audit trail helps to identify security issues preemptively, investigate anomalous activity, and keep on top of data hygiene and governance. Database security depends on having a perfect record of what’s happening inside the databases so that attacks can’t dwell unnoticed.
Every organization decides for itself how to delegate these responsibilities between the productivity and security teams – and what tools either team needs to complete those responsibilities. Consider Cyral: the tool that automates least privilege access, discovery, and auditability for databases across every cloud. See how Cyral owns database security – schedule a demo.
