Database Example Audit Items
Nessus can be configured to log into the following database types and determine local security policy compliance:
- SQL Server
- Oracle
- MySQL
- PostgreSQL
- DB2
- Informix/DRDA
- MongoDB
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.
Database Example
The following example determines if the potentially dangerous xp_cmdshell stored procedure is enabled.
<custom_item>
type: SQL_POLICY
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'"
sql_types: POLICY_INTEGER
sql_expect: "0"
</custom_item>