Security Basics: Database Security

This post is one in a series of blog posts on the fundamentals of an information security program. You can see the complete list of posts in this series here.

---

Don’t Forget about the DatabaseThe bike wheel is often used as the basis of a metaphor when explaining dependencies. The rim and tire are at the outer facing edge, the spokes offer a means of support to the rim, and the hub is at the center holding everything together. This assembly is known to all, simple to understand, and usually contains all of the components needed to communicate complex scenarios at a high level. For these reasons it is also ideal for use when explaining most application environments. In this situation, the application (tire) resides on the servers (rim), is supported by the network (spokes), and communicates back to the database (hub). Yet, although the database is central to all environments and is vital to its operation, it is often overlooked when it comes to security.

Here are some ways application security is sometimes failed by bad database security:

Change the tire, but leave the screws off.
Application patching has become, or at least should be, the norm for organizations. Major vendors such as Microsoft, Oracle, Apple, Adobe, and others release patches for their software products on a set, periodic basis, and typically provide “one-off’s” when critical vulnerabilities surface. The provided patches get tested and applied in an effort to help protect the respective organizations from compromise. This practice should be embraced by operational staff, and should be a key priority. However, merely applying software patches and not also protecting internal assets like databases via other means is equivalent to changing a tire and leaving the screws off: the immediate threat has been addressed, but the potential for the entire environment to come undone still exists.

An organization’s approach to security needs to be holistic. If assets like databases are not sufficiently protected at all levels (e.g. access control, network, infrastructure, etc.), then the potential for the pilfering and/or corruption of data is high and needs to be addressed immediately. Such breaches have made headlines recently across several different industries. Provided below are just a few examples of those that have happened in the past month or so:
http://www.scmagazine.com/researcher-claims-to-have-found-leaked-sanriotown-database/article/460909/
http://www.scmagazine.com/sanders-staffer-took-advantage-of-voter-database-glitch-that-exposed-clintons-data/article/460634/
http://www.scmagazine.com/hong-kong-based-toymakers-breach-impacts-nearly-five-million/article/456597/

Tighten the screws with the wheel up, and again with it down.
When changing a tire, whether it is a bike or car, it is often best to tighten the screws once while it is still raised, and again when it is down and has weight on it so that they are as tight as possible. This multilayered approach holds true with databases as well. Database platforms provide a myriad of controls and objects that can be used to properly restrict users and services from gaining access to unauthorized information. Controls include, but are not limited to:

• Views
• Schemas
• Granular level permissions
• Row label security
• Federated architectures 

At the bare minimum, two or more of these controls should be used when securing a database. For example, permissions should be assigned to roles in accordance with the “principle of least privilege” (the bare minimum of what is needed to perform a task), and the roles assigned to users or groups. The roles should only grant access to views when possible so users or services do not have the ability to insert, update, or delete data, and be highly restrictive when granted at the cross-schema level. That being said, these controls should only be seen as a single layer and should be supplemented via additional technical and operational controls such as network segmentation, physical file restrictions, and patching, among others. Using this approach an organization can further mitigate the risk of their core data source from being compromised, and allow for the wheel to continue operating unabated. ​

Check the Tire Pressure!A few additional basics of database security:
Ensure any default passwords are changed.
Disable, delete, or rename default accounts and built-in administrative accounts wherever possible.
Choose either database authentication or domain/directory authentication for controlling access to your database; mixing the two is usually a recipe for confusion.
Configure user accounts with the least privileges required for their roles.
Ensure that direct access to the database is blocked from the Internet as well as from internal hosts wherever practical. In most cases, access to the database is mediated by an application and only a web server or application server needs direct access to the database.