Risk
6/25/2010
03:50 PM
Connect Directly
RSS
E-Mail
50%
50%

Tech Insight: Three Steps To Better Database Security

Protecting your most sensitive data could involve discovery and auditing, as well as security

If you were a cybercriminal attacking your organization, which data would you target first? In most enterprises, the most voluminous, valuable, and marketable data is found in one common app: the database.

Of course, there are millions of database out there, and most attackers aren't too choosy. They'll go after the ones that are the least secure. How fast do you have to be when a bear is chasing you? Faster than the guy running next to you. Keeping your database secure means taking three basic steps to ensure yours isn't the slow-footed one.

The first hurdle is finding the database servers themselves. The most common place to find them is in the data center, where they're more likely to be documented -- and, hopefully, secured. But database servers can show up in other parts of the enterprise, including research and development labs, test environments, and embedded systems.

Finding those database servers and enumerating the information they store is the first step in developing a strategy for managing risk and securing your most sensitive data. It's not uncommon for test environments to mirror production servers -- to the point of storing the same sensitive information. R&D will often set up servers without any help or knowledge from IT, so it's not uncommon to find servers there that contain sensitive research.

A good example of embedded systems gone bad is Shawn Merdinger's presentation, "We Don't Need No Stinking Badges," (PDF and video) which describes electronic door access control systems (EDAC) and several vulnerabilities he discovered in S2 Security's NetBox. The NetBox includes an extremely old version of MySQL listening on its default port -- and contains "everything from reports to user information, customized features, facility diagrams, and more."

Once you've discovered the sensitive database servers, step two is to lock them down. There are three key elements to this step: firewalls, patching, and Web applications. Database servers do not need to be accessible by every workstation in the company. There could be exceptions, but it's unlikely. Take the time to properly firewall the database server to allow it only to communicate with necessary systems. And remember defense in-depth -- apply rules at the network, host, and application level.

Properly restricting access to the database server will certainly reduce the attack surface, but it does not negate the need to patch. There have been many studies that indicate database administrators do not patch their systems regularly. In security, it's better to be a secure exception to the rule than be vulnerable to a threat that was patched months ago. Set up a test environment, patch it, confirm that it works -- and then patch the production environment.

Web applications bring a whole new dimension to the database security problem. The need to put data online --and support it with a database back end -- has caused the exposure of millions and millions of sensitive records. SQL injection was the top application security risk in the recent OWASP Top 10 for 2010 -- and with good reason. An SQL injection attack can allow an attacker to read, modify, and delete data from a database using nothing more than a Web browser.

If your Web applications are backed by databases, then you need to implement secure coding within your development life cycle and perform vulnerability assessments of your Web apps any time new code is introduced.

New attacks and vulnerabilities are being exposed every day. New tools are being developed regularly, too, such as Poet, which was released recently at Black Hat Europe. Take the time to secure your Web apps before you become a statistic in the next breach report.

Last, but certainly not least, turn on your auditing capabilities. Many enterprises disable these capabilities in an effort to improve database server performance. If performance is a major concern for your organization, then consider a database activity monitoring solution that will provide you with auditing and much more. Turning auditing off will make it harder to investigate possible breaches -- and could impact your compliance efforts.

Ultimately, database security -- like all security -- is about risk mitigation, not elimination. You can't eliminate all of the risks, but you can reduce them to a level that works for you and your organization.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-1927
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly quote strings, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "$(" command-substitution sequences, a different vulnerability than CVE-2014-1928....

CVE-2014-1928
Published: 2014-10-25
The shell_quote function in python-gnupg 0.3.5 does not properly escape characters, which allows context-dependent attackers to execute arbitrary code via shell metacharacters in unspecified vectors, as demonstrated using "\" (backslash) characters to form multi-command sequences, a different vulner...

CVE-2014-1929
Published: 2014-10-25
python-gnupg 0.3.5 and 0.3.6 allows context-dependent attackers to have an unspecified impact via vectors related to "option injection through positional arguments." NOTE: this vulnerability exists because of an incomplete fix for CVE-2013-7323.

CVE-2014-3409
Published: 2014-10-25
The Ethernet Connectivity Fault Management (CFM) handling feature in Cisco IOS 12.2(33)SRE9a and earlier and IOS XE 3.13S and earlier allows remote attackers to cause a denial of service (device reload) via malformed CFM packets, aka Bug ID CSCuq93406.

CVE-2014-3636
Published: 2014-10-25
D-Bus 1.3.0 through 1.6.x before 1.6.24 and 1.8.x before 1.8.8 allows local users to (1) cause a denial of service (prevention of new connections and connection drop) by queuing the maximum number of file descriptors or (2) cause a denial of service (disconnect) via multiple messages that combine to...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.