Configuration Auditing System (CAS)

The Configuration Auditing System (CAS) tracks and reports changes to the server environment; for example, modified configuration files, environment or registry variables, or other database or operating system components. Auditing includes executable files or scripts that are used by the database management system or the operating system. The data is available on the Guardium® system and can be used for reports and alerts.

Note: The Configuration Auditing System is supported only in English.

CAS Agent

CAS is an agent that is installed on the database server and reports to the Guardium system whenever a monitored entity changes, either in content or in ownership or permissions. CAS shares configuration information with S-TAP®, though each component runs independently of the other. After you install the CAS client on the host, configure the actual change auditing functions from the Guardium portal. For more information about installing CAS, see either Prerequisites, installing, and running CAS on a Windows server or Prerequisites, installing and running CAS on a Linux, UNIX server, depending on your operating system.

CAS Server

The CAS server is a component of Guardium and runs on the Guardium system. It runs as a stand-alone process, independent of the Tomcat application server. It is controlled through systemd.

The CAS server is configured to use only a few of the available processors on the Guardium system. The number of processors that CAS uses is determined by the divide_num_of_processors_by parameter, which is stored in the file. The default value of divide_num_of_processors_by is 2. The number of available processors on the Guardium system is divided by this value. Therefore, even when CAS uses 100% of the CPU on the allocated processors, the remaining processors are available for use by other applications.

Template Set

A CAS template set contains a list of item templates, bundled together, that share a common purpose such as monitoring a particular type of database (Oracle on UNIX, for example). Two types of CAS templates are available:
  • Operating System Only (UNIX or Windows)
  • Database (UNIX-Oracle, Windows-Oracle, UNIX-Db2, Windows-Db2, and so on.)

A database template set is always specific to both the database type and the operating system type.

CAS Template Item

The definition or set of attributes of a monitoring task over a single Monitored Entity. Users can define new CAS tests by creating new CAS templates or users can use predefined CAS templates that can be modified.

A template item is a specific file or file pattern, an environment or registry variable, the output of an OS or SQL script, or the list of logged-in users. The state of any of these items is reflected by raw data, that is, the contents of a file or the value of a registry variable. CAS detects changes by checking the size of the raw data, or computing a checksum of the raw data. For files, CAS can also check for system level changes such as ownership, access permission, and path for a file.

In a federated environment where all units (collectors and aggregators) are managed by one manager, all templates are shared by both collectors and aggregators and you can use CAS data in reporting or vulnerability assessments. When the collector and aggregator (or host where archived data is restored) are not part of the same management cluster the templates are not shared. Therefore, you cannot use CAS data with vulnerability assessments (VA) even when the data is present. To use CAS with VA, export or import definitions to copy the templates from the collector to the aggregator (or restore target).

Note: It is recommend that you do not use CAS to monitor more than 10,000 files per client.

Monitored Entity

The actual entity being monitored, can be A File (its content and properties), Value of an Environment Variable or Windows Registry, Output of an OS command or Script or SQL statement

CAS Instance

Application of a CAS Template Set on a specific Host (creating an Instance of that Template Set and applying it on a specific host)

CAS Configuration

A CAS configuration defines one or more CAS instances, each of which identifies a template set to be used to monitor a set of items on that host.

Default Template Sets

For each operating system and database type supported, Guardium provides a preconfigured, default template sets for monitoring a variety of databases on either Unix or Windows platforms. A default template set is one is used as a starting point for any new template set defined for that template-set type. A template-set type is either an operating system alone (Unix or Windows), or a database management system (DB2®, Informix®, Oracle, and so on.), which is always qualified by an operating system type - for example, UNIX-Oracle, or Windows-Oracle. Many of the preconfigured, default template sets are used within Guardium's Vulnerability Assessments where, for example, known parameters, file locations, and file permissions can be checked.

You cannot modify a Guardium default template set, but you can clone it and modify the cloned version. Each of the Guardium default template sets defines a set of items to be monitored. Make sure that you understand the function and use of each of the items monitored by that default template set and use the ones that are relevant to your environment. After defining a template set of your own, you can designate that template set as the default template set for that template-set type. After that, any new template sets defined for that operating system and database type are defined with your new default template set as a starting point. The Guardium default template set for that type is removed; it remains defined, but is not marked as the default.

Rationale for creating template sets to meet specific database configurations

Although Guardium supplies predefined CAS template sets for each database type, the wide variety of possible database configurations means that you mignt need to tweak the predefined template sets or create new ones to meet all of your needs in a production environment -- particularly concerning database software and data file locations. Plan on creating additional templates if you want CAS to monitor ownership of, permissions on, and changes to your database files.

For example, the predefined CAS template set for Oracle contains these templates, among others:
  • $ORACLE_HOME/oradata/../.*dbf
  • $ORACLE_HOME/oradata/../.*ctl
  • $ORACLE_HOME/oradata/../.*log
  • $ORACLE_HOME/../init.*.ora

As you can see, these file-pattern templates all start with the same root, $ORACLE_HOME (NOTE: This is not necessarily the $ORACLE_HOME environment variable that is defined on your database server. By preference, CAS uses the data source field Database Instance Directory as the value for $ORACLE_HOME).

It is possible that in a production environment your Oracle data files are not in the same directory tree, or even on the same device, as your log files. Furthermore, the Oracle configuration files might be in yet another location.

You might create additional CAS templates using absolute paths to allow CAS to find and monitor all of your Oracle files, for example:
  • /u01/oradata/mydb/*.dbf
  • /u02/oradata/mydb/*.dbf
  • /u03/oradata/mydb/*.dbf
  • /u01/oradata/mydb/*.ctl
  • /u02/oradata/mydb/*.ctl
  • /u03/oradata/mydb/*.ctl
  • /home/oracle11/admin/mydb/bdump/*.log
  • /home/oracle11/product/11.1/db_1/dbs/init*.ora
You can even use additional environment variables that are defined in your Oracle instance account. As an example, if you have variables defined as $ORA_DATA1, $ORA_DATA2 and $ORA_SOFT you can use:
  • $ORA_DATA1/mydb/*.dbf
  • $ORA_DATA2/mydb/*.dbf
  • $ORA_DATA1/mydb/*.ctl
  • $ORA_DATA2/mydb/*.ctl
  • $ORA_SOFT/admin/mydb/bdump/*.log
  • $ORA_SOFT/product/11.1/db_1/dbs/init*.ora

Sourcing files from different locations

CAS templates assume that certain files, such as user profiles, are in specific locations. You can configure CAS to look for these files in other locations that you specify by using a regular expression. To use this feature, add the user_profile_files parameter to the file in the config directory. The format for each entry is
identifying_string=comma-separated list of files
For example, suppose that you want to find .profile files in any Db2 user’s home directory. For this example we assume that the names of all of these home directories include the string "db2." Add this line to the properties file:
If you need to specify more than one pattern, use the bar symbol (|) to separate patterns. If you want to add the profiles of your mysql users to the previous entry, replace the previous example with this: