Risk
10/7/2012
01:42 PM
Tim Wilson
Tim Wilson
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Eight Steps To Securing Small Databases

Just because your database is in a workgroup or a small business doesn't mean the data isn't valuable. Here are some low-costs steps to keeping it secure

[Excerpted from "Eight Steps To Securing Small Databases," a new report posted this week on Dark Reading's Database Security Tech Center.]

When we talk about database security, we usually begin by talking about mammoth databases maintained by large enterprises. But It can be argued that the biggest database challenges of all are those faced by small and midsize companies struggling to just get basic security in place.

In SMBs, the database administrators bear much of the responsibility for security. Most wear at least three hats: administrator, architect and security expert. Security is woven into the normal operational cycles, and it competes with all other requirements.

The good news is that many security and automation tools are available to help DBAs get their jobs done. The bad news is that these products and services often cost more than smaller companies' budgets will allow for. Indeed, for SMB DBAs, there is always too much to do and not enough money to do it with, so these folks must be creative when looking for solutions.

Under these resource-constricted conditions, how do you approach database security? With small databases dotting your company landscape, which take priority? When you can't afford the latest and greatest tools, where do you focus your efforts? SMBs and workgroups need database security strategies and tools that don't require big budgets or skilled, dedicated security staff.

SMBs looking to tightly secure the data in their care will need to spend a good amount of time planning how they will allocate scarce resources. This means leveraging everything at their disposal, including the security tools included with the products they own, as well as whatever they can leverage from the community at large. Once a plan is in place, these organizations should look at automating as much as possible.

Your goal is to get the basic security systems installed and self-sufficient so you can spend your time on more time-sensitive and critical matters. Your security program will include a number of defensive security measures for the database (such as vulnerability assessment, configuration management and patching systems), controls over data access (including identity management and encryption systems) and -- resources permitting -- detective controls (such as auditing and monitoring system).

The first step in any security program is to do an inventory of what you need to secure, including a list of the servers, databases and sensitive data under your control. You'll need to understand where these resources are deployed on your network and how users access them to do their jobs. This can be tricky for companies that have databases -- including small databases -- distributed across many locations, but this understanding is critical.

Now that you know what systems need to be secured, and what requirements you areresponsible for, how will you secure these databases? It's at this phase of the process that we need to assess risks and requirements and figure out how to address them. Some issues are (relatively) simple, such as patching and reconfiguring a database when a vulnerability has been discovered. Some issues are more complex, such as HIPAA compliance and validating use of information.

The most critical factor in securing your network on a budget is successfully using what you have. Most DBAs are not even fully aware of the tools that come bundled with their databases. Some are not aware that other groups, or even their predecessors, may have acquired tools but never put them into production. Shelfware does not help you get secure, so take an inventory of what you have and put it to use.

For a detailed description of these initial steps -- and for an in-depth description of five additional steps toward securing small databases -- download the free database security report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web