A Special Analysis For Dark Reading First of two articles
One of a security professional’s biggest challenges is to keep an organization’s most sensitive data out of harm’s way. When it comes to the huge volumes of information stored in databases, however, that’s no simple task.
Protecting sensitive information means finding and securing it in any location, from corporate headquarters to branch locations to mobile devices. Such data isn’t always easy to locate — it may be stored in a variety of formats, from the small Excel files on a CFO’s laptop to enormous databases that contain critical inventories or customer information.
Frequently, databases hold the “crown jewels” of the organization — the largest and most mission-critical data. This means a database breach can have serious consequences, whether it comes from an employee with authorized access or from a hacker who comes in via vulnerabilities in poorly written Web applications that are linked to the database.
Complying with regulations, like PCI DSS or SOX, has helped many organizations become more aware of their most sensitive data repositories, but it is easy to lose track of what network resources exist when these repositories are spread across multiple office locations. To prevent this sort of oversight, we should look at database security and compliance as a three-stage process: locating your databases, enumerating the data, and securing the critical database servers.
The first stage — locating the databases themselves — can be achieved through a couple of different methods. The easiest, but often less fruitful, method is to consult the documentation. If you’re lucky, then there will be an extensive, searchable repository containing the information you’re looking for. Otherwise, you’ll be digging through a lot of docs. This is where sysadmins and developers can help fill in the missing gaps.
When documentation fails, the best method for locating databases is scanning the network with Nmap to find hosts that are running database services and actively listening for connections. For even better coverage, use Nessus with administrative credentials to audit your hosts for installed and running applications — this will help you find the database servers that are running but not listening on the network.
The second stage to securing your database environment is to enumerate the data contained in the databases you found in the first stage. Not all database servers will need the same level of protection. A test database containing bogus data for use by developers, for example, will obviously not need the same level of defense as a production database server containing customer information and front-ended by a Internet-exposed Web application.
Documentation, developers, and database administrators (DBAs) should provide insight into the database’s contents — but they aren’t always as accessible or helpful as they could be. To get the full picture of what’s in your databases, you may need to look into data discovery products, like Identity Finder, or discovery features included in data leakage prevention (DLP) and database activity monitoring (DAM) tools.
The discovery process will be straightforward — as long as the tool you’re using properly understands how to access the databases in your organization. If you haven’t purchased a product — or if you have a DLP/DAM solution already — then be sure what you choose will work with all of the technologies you discovered in the first stage.
The third stage is to secure the database servers themselves and ensure they comply with corporate configuration policies. Manually checking database server settings is a monotonous, tedious task best-suited for automation. Free and commercial tools are available that make the process easier, so it can be done enterprisewide with little effort.
The most important part of the third stage is to ensure you have a well-defined database security configuration policy; hopefully, this was created and refined well before you started this process. The policy should be based on best practices, while meeting the needs and required security level of your environment.
Next, choose an auditing tool that suits your database environment. The CIS Security Benchmark tool and Nessus vulnerability scanner come with customizable configuration files that can be edited to match your security policies. You can also get configuration files from groups like DISA, which can serve as a basis for your auditing.
Though the CIS tools are free, Nessus is a good upgrade to consider because it can scan for vulnerabilities in the database server and underlying operating system. Also, remember that they don’t both support the same number of database server types, so be sure to confirm the one you’re using can work with all, or at least most, of the software types that run your critical data.
For truly comprehensive database security, you must also consider secure network design, DLP and DAM technologies, secure application development, and proper backup and disaster recovery. However, if you execute these first three stages properly, then you’ll be well on your way to securing your most sensitive database information, and you can add additional security capabilities later.
