Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:27 PM

Top Five Reasons Database Security Fails In The Enterprise

Independent Oracle Users Group survey reveals common database security missteps made by enterprises

Though database security best practices have circulated the conference circuit for years now and existing database security tools are now mature, today's typical enterprise is still far behind in shoring up its most sensitive stores of data. In fact, the Independent Oracle Users Group's (IOUG) recently released data security survey findings are enough to open the eyes of anyone who has ever read news reports about embarrassing data breaches and wondered if his company could be breached next time.

Taking a look at the results, it's clear that most organizations today are still running database security by the seats of their pants. The vast majority of organizations do not monitor their databases at all, or do so in an ad hoc fashion. Even more troubling, most enterprises don't even know where their sensitive data resides -- with many administrators admitting in the survey that they are not sure of all of the databases that contain sensitive information.

Based on IOUG's survey of 430 of its members conducted by Unisphere Research, we've identified some of the biggest reasons why breach statistics remain so high. Until organizations get these practices under control, embarrassing data security slips will continue to make the news.

1. Organizations still don't know where sensitive data resides.
Before an enterprise can protect its sensitive data, it has to know where it is. Unfortunately, in today's fast-paced IT environments many administrators are finding it difficult to track sensitive information across numerous databases.

The plain truth is they just don't know which databases contain data such as personally identifiable information (PII) and which do not. The survey found that 48 percent of respondents admitted they were not aware of all of the databases in the organization that contain sensitive information.

Part of the difficulty is the sheer number of databases that organizations run these days. About 35 percent of organizations run between 11 and 100 databases, nearly 40 percent run more than 100 databases, and 13 percent of organizations run more than 1,000 databases.

Further complicating matters is the fact that so much sensitive information creeps outside of production databases. About 37 percent of organizations admitted they use live production data in nonproduction databases. Among those who do, 39 percent said this data contains PII or they weren't sure.

2. Security monitoring remains spotty.
With so many databases to track, organizations must be systematic about how they monitor activity on these data stores if they want to truly gain visibility into who is accessing what information. Yet only one in four organizations have automated tools to monitor database activity on a regular basis, a statistic that has remained largely unchanged since IOUG began surveying database administrators back in 2008.

IOUG found also that while 72 percent of organizations use native auditing tools on at least some of their databases, very few of the administrators actually look at the data generated by these tools. About 11 percent of organizations said they manually monitor databases on a regular basis.

Unsurprisingly, 25 percent of organizations said they have no way to detect whether unauthorized changes are made to the database. Just 30 percent of organizations reported they would be able to detect such changes on most databases. Approximately 46 percent of respondents said they'd be able to detect unauthorized changes on some databases.

However, among those who can detect changes, the response time is slow. Just 12 percent said they'd be able to detect unauthorized changes within an hour, while about 33 percent reported that it would take them up to a day. Approximately 16 percent said it would take them a day or longer, and nearly 40 percent were not sure how long it would take to respond to an unauthorized database change.

1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-13
The package studio-42/elfinder before 2.1.58 are vulnerable to Remote Code Execution (RCE) via execution of PHP code in a .phar file. NOTE: This only applies if the server parses .phar files as PHP.
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.