Five Hurdles That Slow Database Security Adoption

A number of factors contribute to uneven adoption of database security technology in the enterprise -- most of them center around complexity

In spite of a fairly mature product set and boardroom directives to protect sensitive databases, the average enterprise today still has a long way to go before itll apply comprehensive database security technology and processes to all of its critical databases -- let alone all of its corporate databases. Even with compliance mandates slowly boosting the sale of database activity monitoring (DAM) tools at the enterprise level, the technology itself is growing cobwebs within many organizations for two big reasons: cost and complexity.
One of the reasons why adoption across the enterprise is limited really is due to the cost model, says Adrian Lane, analyst and CTO for Securosis. A lot of times the cost of rolling it out across the entire place is just so astronomical in comparison to what the vendor led them to believe it would cost that it didnt really happen.
[Are you governing data without good metrics? See
Governance Without Metrics Is Just Dogma
.]
According to Lane, some financial organizations he has talked to have reported it would cost three to four times the amount they were initially sold to properly roll out their DAM technology.
According to many security professionals, todays database security technologies are too complex to deal with. A recent survey of more than 1,300 IT professionals by GreenSQL asked what major obstacles stood in the way of database security implementation. Tops on the list, named by 31 percent of respondents, was complexity.
So what makes database security so expensive and complicated to deploy? Here are five of the most contributing factors:
1. Scale
When a small or midsize organization has only dozens or even hundreds of database servers to protect, thats something you can live with, says David Maman, co-founder and CTO of GreenSQL. But within the enterprise the scale of database infrastructure mushrooms and creates a scope of protection thats difficult to wrap ones mind around.
Go to 40 percent of Fortune 500 companies, and youll find theyve got more than 10,000 database servers, Maman says. Just thinking about the scope of a project, even if you just take 20 percent of those databases that require activity monitoring and enforcing separation of duties, it can easily cost millions.
2. Mismatched Compliance Deployments
Many of the earliest purchasers of DAM technology bought it hopefully as a quick fix to many of their SOX compliance problems. Compliance continues to drive sales even today, a fact that frequently results in deployments that are very limited in scope across just a small subset of database, are limited in functionality so that just one or two features are regularly used, or both.
Many times organizations have overbought or theyre simply using DAM in a way it wasnt intended -- essentially hammering the proverbial screw.
Its funny, I recently saw people use DAM for failed log-in detection, which is a totally inappropriate reason to buy the tool, Lane says. Its just a bad deployment model for that because there are other cheaper ways to do it.
3. SIEM And DAM Dont Play Well Together
According to Lane, many organizations have spent a lot of time, hired lots of specialists, and invested resources in security regimes that revolve around the almighty security information and event management (SIEM) platform. One minor problem: With a few exceptions, DAM and SIEM generally dont play well together.
A lot of organizations have already invested in SIEM, and thats supposed to be the security tool of choice. So anything that happens should feed back into SIEM, Lane says. But, honestly, DAM and SIEM dont really mesh all that well unless the capabilities are fully integrated.
4. Performance Overshadows Security
According to Maman, even at organizations that do have some sort of monitoring technology in place, IT wouldnt dare turning on blocking mechanisms to prevent access abuse.
Even though its for security, they cannot take the risk that some sensitive information or required information for some system wont be available, he says.
The fact is that DBAs understand and dont understand database security, Lane says. They generally get that securing the data is an important part of administering databases -- theyll even accept agents at a kernel level. But in their minds, security comes second to performance, he says. And it is likely to be back-burnered if it is difficult to administer or write policies for.
Theyre not security experts; they dont know what the hell a legitimate threat is or to write a policy to do address it, he says. And then heres the UI of this freaking tool, and theyve got to come to terms with it.
The complexity of databases makes it such that it creates a fundamental disconnect between performance-focused DBAs and risk-averse security pros with no fundamental knowledge of how databases work. That schism is likely why 20 percent of professionals in the GreenSQL survey said the requirement for dedicated and expert professionals to run database security is their biggest obstacle. Without that kind of expertise, dangerous configurations crop up and security initiatives languish.
Databases are often extremely complex, so it is important for a database administrator to understand the potential security impacts of the multiple configuration options that are available, says Phil Lerner, vice president of technology for Stonesoft. When administrators focus on availability, they often overlook configuration issues that can introduce security vulnerabilities and expose confidential data. Applications and their handling of access and encryption also present a significant risk to back-end databases.
5. Application Complexity
One of the biggest challenges in database security is that these data stores generally have to connect to dynamic application environments to work properly. And many of the hardest security problems revolve around those connections. Take SAP applications, for example.
SAP applications manage database structure in an extremely complex way, Maman says. It creates more than 1,000 tables over sometimes hundreds of different databases and with strange naming. When you look at the database, it takes a long, long time in order for you to understand which rights you can enforce on which table and which source application.
Not only are the relationships between the applications and databases complicated, theyre also changeable. This dynamic nature of enterprise applications makes it difficult for organizations to ever evolve their use of DAM tools beyond learning mode and into more automated blocking.
Weve talked to a massive bank in the U.S., and this bank told us that now theyve started year No. 3 in the learning mode process, and they cant even see when this process will end, Maman says.
Have a comment on this story? Please click Add Your Comment below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ IoT Devices on Average Have 25 Vulnerabilities ◂ Discovered: 23/12/2024 Category: security	▸ DHS-funded SWAMP scans code for bugs. ◂ Discovered: 23/12/2024 Category: security	▸ Debunking Machine Learning in Security. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Five Hurdles That Slow Database Security Adoption