Compliance standard framework
BMC Database Automation provides a platform for creating compliance standards for your environment. Similar to Actions, standards are a framework for automating tasks and running scripts on hosts and databases. The framework consists of check and remediation content that manages compliance.
A standard is constructed of a zipped archive containing folders and files specific to an environment. Standards consist of rules (also known as checks) that are made up of an .xml file (that describes the rule) and an executable binary (such as a perl script) that performs the check. For example, for a DISA standard for an Oracle 11g database, the archived contents of the standard contains a perl/ folder which contains script (./perl/runme.pl) and various perl libraries (./perl/libs/*) that enable BMC Database Automation to run the compliance standard. The SCL folder stores all the compliance rules.
The following example illustrates a file representing a simple Action template that contains only one mandatory field: SUITE. This field should contain the name of directory where compliance checks are stored:
Rules are metadata and content that evaluate an object (for example, a database) against a pre-defined test. In a compliance standard, each script has a corresponding .xml file that describes what the rule does.
For example, a DISA standard for an Oracle 11g database might require 64 different checks to comply with that standard. The following example shows the format of the .xml file.
The following table details example rules for a DISA standard for Oracle 11g and their meaning. The name of the rule corresponds to the <name> tag in the xml file, and the description of the rule corresponds to the <description> tag.
Name | Description |
|---|---|
DBMS application object owner accounts | Application object owner accounts should be disabled when not performing installation or maintenance actions. |
DBMS application object ownership | Application objects should be owned by accounts authorized for ownership. |
DBMS demonstration and sample databases | Default demonstration and sample database objects and applications should be removed. |
DBMS access to sensitive data | Access grants to sensitive data should be restricted to authorized user roles. |
Developer DBMS privileges on production databases | Developers should not be assigned excessive privileges on production databases |
Sensitive data access | Access to sensitive data should be restricted to authorized users identified by the InformationOwner |
DBMS default passwords | DBMS default accounts should be assigned custom passwords.If all of the accounts listed show an account status of LOCKED & EXPIRED or LOCKED this is aFinding, but downgrade the severity Category Code to II. |
Oracle _TRACE_FILES_PUBLIC parameter | The Oracle _TRACE_FILES_PUBLIC parameter if present should be set to FALSE. |
Oracle system privilege assignment | Oracle system privileges should not be directly assigned to unauthorized accounts. |
Oracle REMOTE_OS_AUTHENT parameter | The Oracle REMOTE_OS_AUTHENT parameter should be set to FALSE.This finding may be downgraded to a Category II severity code if the following mitigations havebeen implemented: 1) A logon trigger verifies that any connections to accounts identifiedexternally come from a single, specific IP address and kills the connection if determinedotherwise, and 2) To help prevent access by a spoofed IP address, the single connecting systemand the database host are isolated behind a firewall with either Network Address Translation(NAT) implemented and/or the firewall is configured to reject connections from the single sourceIP address originating outside the isolated segment. |
Oracle minimum object auditing | Required object auditing should be configured. |
Oracle RESOURCE_LIMIT parameter | The Oracle RESOURCE_LIMIT parameter should be set to TRUE. |
Where to go from here