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.
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.
- Use IBM Java 8 SR7 or later.
- For Windows: Your CAS agent must be at 11.5.0.258 or later.
- For UNIX: Your CAS agent must be at 11.5.4.0_r115045 or later.
Alternatively, you can continue to use CAS without updating the agents, but you must disable FIPS mode. For more information about disabling FIPS mode for CAS, see Secure connection without authentication (without FIPS mode)
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 cas.server.config.properties 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
- 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).
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.
- $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.
- /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
- $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
identifying_string=comma-separated list of files
user_profile_files=.*db2.*=.profile
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:user_profile_files=.*db2.*=.profile|.*mysql.*=.profile