Auditing Databases with Nessus

As a companion to another post on hardening network devices and creating baseline configurations, I wanted to look at another area where standardizing configurations can pay off in a big way. While there is plenty of fertile ground out there, I decided to focus on some specific aspects of databases. As I started reviewing recent research, I noticed a couple of interesting things from the world of finance that likely aren’t radically different from most environments. Findings in both the Verizon 2017 Data Breach Investigations Report (DBIR) and the SecurityScorecard 2016 Financial Industry Cybersecurity Research Report bear out that there are a number of challenges for security pros across financial institutions.

Background

According to the SecurityScorecard report, the majority of U.S. Commercial Banks surveyed scored a “C” or lower for network security, while several scored below a “C” for application security. These results  indicate that paths into networks are open for attackers to leverage. This isn’t an isolated issue in the finance sector, the DBIR also shows similar findings across the board, from manufacturing to retail and public administration/government.

Given these findings, security pros must be focused on keeping data where it belongs and ensuring that it’s available only to those who need it. Even if a particular environment is scoring high on both the network and application security realms, there is still the ever-present need to conform to compliance standards and security frameworks.

In most environments, the ultimate resting place of data, specifically financial data, health records and confidential trade secrets, is often any number of databases. This makes the security posture of the database itself the last line of defense for protecting data and customer information. There are literally hundreds of aspects to securing a typical database but there are two that I’m going to focus on here.

From a compliance and security framework perspective, most of the well-known standards  agree on a number of things, like enforcing baseline configurations and encrypting stored data.

While these are just two places that the standards overlap, they do cover a couple of the more effective controls that we can leverage.

By creating and enforcing a standard hardened configuration for databases, we can reduce the overall attack surface and make the required ports and interfaces as secure as possible. So even if our network allows a number of paths to our data, we can close off many of them and make sure the paths stay unavailable.

By layering encryption on top of the baseline, we help fulfill the other side of the equation. Since we always have to think in terms of risk and effects, we need to consider what happens if our configuration fails and the data finds its way out. By protecting data with high-quality encryption, we make the data as useless as possible to a cyber criminal.

It’s important that all of these controls be implemented, working and monitored on a regular basis.    

Tenable Solutions

Tenable provides a wide range of compliance and audit files for the most widely used commercial database platforms, like Microsoft SQL Server, Oracle Server and IBM DB2, along with MySQL, PostgreSQL and MongoDB

Most of these platforms are covered by multiple audit files based on CIS Benchmarks or Defense Information Systems Agency (DISA) Secure Technical Implementation Guides (STIG).

These audit files provide a good foundation of industry best practice configuration settings and also include checks to validate many aspects of the encryption strategies in place.

Recent Additions

Tenable has also recently released support for Sybase ASE along with an accompanying audit file based on the CIS Sybase ASE 15.0 v1.1.0 benchmark.

Sybase ASE scans can be initiated from both the Advanced Scan or Policy Compliance Scan templates. The database credentials page has been updated to add Sybase ASE as a database type for selection. Support for both plain text and RSA authentication is available.

Wrap-Up

Limiting the paths that data can move in and out of your database infrastructure is a great first step in reducing your available attack surface. You should couple this with encrypting sensitive data to ensure that if any data leaves the network, it’s of as little value as possible. Even if our environment is getting straight A’s, the normal lifecycle of a network is always conspiring to introduce variations which might result in new or reopened paths appearing. Building and maintaining these end-of-the-line safeguards will continue to pay dividends.