In most environments, the ultimate resting place of data, specifically financial data, health records and confidential trade secrets, that often subject to to regulatory compliance, 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. On top of specialized database security scanner or vulnerability scanner, Nessus Pro can help to perform the task in the following way.
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.
|CIS Critical Security Controls v6||3.1 Establish standard secure configurations
13.2 Deploy approved hard drive encryption
|PCI-DSS v3.2||2.2 Develop configuration standards for all system components
3.4 Render PAN unreadable anywhere it is stored
|NIST 800-53||CM-2 Baseline Configuration
SC-28 Protection of Information at Rest
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.
Nessus Pro 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, Sybase ASE 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.
For example, 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.
The result of carry out database audit and recommendation always result in 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.
Database Example Audit Items
Nessus can be configured to log into the following database types and determine local security policy compliance:
- SQL Server
In general, Tenable recommends running a database compliance scan with a user with SYSDBA privileges for Oracle, sa or an account with sysadmin server role for MS-SQL, and DB2 instance user account for DB2. Scanning as users with these roles ensures completeness of the report, as some system or hidden tables and parameters can only be accessed by an account with such privileges.
For MongoDB, a NoSQL database, Tenable recommends running a database compliance scan with the database user for the associated database. Note that for Oracle, in most cases a user assigned the DBA role will perform most of the checks in Tenable audits, but some checks will report errors because of insufficient access privileges. This same argument is applicable to other databases as well; a lesser privilege account could be used for database auditing but the downside is a complete report cannot be ensured.
Database audits are normally comprised of select statements that retrieve security-related details from your database such as the existence or status of insecure stored procedures.
The following example determines if the potentially dangerous xp_cmdshell stored procedure is enabled.
description: “xp_cmdshell option”
info: “The xp_cmdshell extended stored procedures allows execution of host
executables outside the controls of database access permissions and may be
exploited by malicious users.”
info: “Checking that the xp_cmdshell stored procedure is set to ‘0’”
sql_request: “select value_in_use from sys.configurations where name = ‘xp_cmdshell'”