From: Dark Reading
A number of factors contribute to uneven adoption of database security technology in the enterprise — most of them center around complexity
By Ericka Chickowski, Contributing Writer/Dark Reading
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 it’ll 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 didn’t really happen.”
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, today’s 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, that’s 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 that’s difficult to wrap one’s mind around.
“Go to 40 percent of Fortune 500 companies, and you’ll find they’ve 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 they’re simply using DAM in a way it wasn’t intended — essentially hammering the proverbial screw.
“It’s funny, I recently saw people use DAM for failed log-in detection, which is a totally inappropriate reason to buy the tool,” Lane says. “It’s just a bad deployment model for that because there are other cheaper ways to do it.”
3. SIEM And DAM Don’t 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 don’t play well together.
“A lot of organizations have already invested in SIEM, and that’s supposed to be the security tool of choice. So anything that happens should feed back into SIEM,” Lane says. “But, honestly, DAM and SIEM don’t 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 wouldn’t dare turning on blocking mechanisms to prevent access abuse.
“Even though it’s for security, they cannot take the risk that some sensitive information or required information for some system won’t be available,” he says.
The fact is that “DBAs understand and don’t understand” database security, Lane says. They generally get that securing the data is an important part of administering databases — they’ll 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.
“They’re not security experts; they don’t know what the hell a legitimate threat is or to write a policy to do address it,” he says. “And then here’s the UI of this freaking tool, and they’ve 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, they’re 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.
“We’ve talked to a massive bank in the U.S., and this bank told us that now they’ve started year No. 3 in the learning mode process, and they can’t even see when this process will end,” Maman says.
Leave a Reply