Databases can be affected by changes to the server environment; for example, by changing configuration files, environment or registry variables, or other database or operating system components, including executables or scripts used by the database management system or the operating system. CAS tracks such changes and reports on them. The data is available on the Guardium appliance and can be used for reports and alerts.
CAS is an agent installed on the database server and reports to the Guardium appliance whenever a monitored entity have changed, either in content or in ownership or permissions. You install a CAS client on the database server system, using the same utility that is used to install S-Tap. CAS shares configuration information with S-Tap, though each component runs independently of the other. Once the CAS client has been installed on the host, you configure the actual change auditing functions from the Guardium portal.
A CAS template set contains a list of item templates, bundled together, share a common purpose such as monitoring a particular type of database (Oracle on Unix, for example), and is one of two types:
Operating System Only (Unix or Windows)
Database (Unix-Oracle, Windows-Oracle, Unix-DB2, Windows-DB2, etc.)
A database template set is always specific to both the database type and the operating system type.
The definition or set of attributes of a monitoring task over a single Monitored Entity. Users can define new CAS test to construct new CAS templates or use predefined templates for each OS and each database type; optionally modifying to meet specific database monitoring requirements.
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, i.e. 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.
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
Application of a CAS Template on a specific Host (creating an Instance of that Template Set and applying it on a specific host)
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.
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 that will be 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, etc.), 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. See Vulnerability Assessments for additional information.
The Guardium default template sets all begin with the word Guardium. 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 will be defined using your new default template set as a starting point. The Guardium default template set for that type will not be removed; it will remain defined, but will not be marked as the default.
Each database has a set of defined CAS templates, each of which are describe here for the different monitored database type and available for use in the assessment tests.
Designates an OS script to be executed. Must begin with the variable $SCRIPTS, which refers to the scripts directory beneath the CAS home directory, and identify the script to be executed, e.g., $HOME/ db2_spm_log_path_group_test.sh". The script itself must, of course, reside in the CAS $SCRIPTS directory. Output from the script is stored in the Guardium database to be used by security assessments. This can be either a shell/batch script to be run, or a set of commands that could be entered on the command line. Because of the fickle nature of Java's parsing it is suggested that any but the simplest commands be put into a script rather than run directly. On Unix the script is run in the environment of the OS user entered. Three environment variables will be defined for the run environment which the user could use in writing scripts: $UCAS is the DB username, $PCAS is the DB password, and $ICAS is the DB instance name. For Windows these three values will be appended as the last three arguments to the batch file execution. For example, if you had an OS Script template "%SCRIPTS%\MyScript.bat my-arg1 my-arg2", then %3, %4 and %5 would be the DB username, password, and instance name respectively.
Designates a file to be tracked and monitored by security assessments. The path to the file can be absolute, or relative to the $INSTHOME variable. The value of the $INSTHOME variable is the value you set in the DB Home Directory field of the host configuration screen. This is assumed to name a single file. Environment variables from the OS user environment can be used in the file name and will be expanded. For example, "$HOME/START.sh" will name the startup script in the DB2 user's home directory.
Designates a group of files to be tracked and monitored by security assessments. The path to the files can be absolute, or relative to the $INSTHOME variable. The value of the $INSTHOME variable is the value you set in the DB Home Directory field of the host configuration screen. A ".." in the path indicates one or more directories between the portion of the path above it and the portion of the path below it. A ".+" in the path indicates exactly one directory between the portion of the path above it and the portion of the path below it. For example: "$INSTHOME/sqllib/../db2.*" This is just a short-hand for creating many single file identifications from a single identification string, a file pattern which will match all files in the directory. A file pattern can be viewed as a series of regular expressions separated by /'s. A file is matched if each element of its full path can be matched by one of the regular expressions in order. If an element of the pattern is an environment variable, it is expanded before the match begins. If ".." is one of the elements of the pattern, it will match zero or more directory levels. For example, "/usr/local/../foo" will match "/usr/local/foo" and "/usr/local/gunk/junk/bunk/foo". Using more than one ".." element in a file pattern should not be necessary and is discouraged because it makes the pattern very slow to expand. Because of the confusion with its use in regular expressions "\" cannot be used as a separator as it might be in Windows.
Additionally, the "Guardium Unix/DB2 Assessment: UNIX - DB2" for Unix set includes the following templates:
This test monitors that the SETUID bit on DB2GOVD has been disabled
This test monitors that the SETUID bit on DB2START has been disabled
This test monitors that the SETUID bit on DB2STOP has been disabled
This test monitors file ownership, and changes thereto, of DB2 files.
This test monitors file permissions, and changes thereto, of DB2 files.
Designates an OS script to be executed. Must begin with the variable $SCRIPTS, which refers to the scripts directory beneath the CAS home directory, and identify the script to be executed, e.g., $HOME/ informix_rootpath_owner.sh". The script itself must, of course, reside in the CAS $SCRIPTS directory. Output from the script is stored in the Guardium database to be used by security assessments. This can be either a shell/batch script to be run, or a set of commands that could be entered on the command line. Because of the fickle nature of Java's parsing it is suggested that any but the simplest commands be put into a script rather than run directly. On Unix the script is run in the environment of the OS user entered. Three environment variables will be defined for the run environment which the user could use in writing scripts: $UCAS is the DB username, $PCAS is the DB password, and $ICAS is the DB instance name. For Windows these three values will be appended as the last three arguments to the batch file execution. For example, if you had an OS Script template "%SCRIPTS%\MyScript.bat my-arg1 my-arg2", then %3, %4 and %5 would be the DB username, password, and instance name respectively.
Designates a file to be tracked and monitored by security assessments. The path to the file can be absolute, or relative to the $ INFORMIXDIR variable. The value of the $ INFORMIXDIR variable is the value you set in the DB Home Directory field of the host configuration screen. This is assumed to name a single file. Environment variables from the OS user environment can be used in the file name and will be expanded. For example, "$HOME/START.sh" will name the startup script in the Informix user's home directory.
Additionally, the "Guardium Unix/Informix Assessment" for Unix set includes the following templates:
This test monitors for error in the online.log file
This test monitors file ownership, and changes thereto, of Informix files.
This test monitors file permissions, and changes thereto, of Informix files.
Designates an OS script to be executed. Must begin with the variable $SCRIPTS, which refers to the scripts directory beneath the CAS home directory, and identify the script to be executed, e.g., "$SCRIPTS/oracle_user.sh". The script itself must, of course, reside in the CAS $SCRIPTS directory. Output from the script is stored in the Guardium database to be used by security assessments. (This can be either a shell/batch script to be run, or a set of commands that could be entered on the command line. Because of the fickle nature of Java's parsing it is suggested that any but the simplest commands be put into a script rather than run directly. On Unix the script is run in the environment of the OS user entered. Three environment variables will be defined for the run environment which the user could use in writing scripts: $UCAS is the DB username, $PCAS is the DB password, and $ICAS is the DB instance name. For Windows these three values will be appended as the last three arguments to the batch file execution. For example, if you had an OS Script template "%SCRIPTS%\MyScript.bat my-arg1 my-arg2", then %3, %4 and %5 would be the DB username, password, and instance name respectively. )
Designates a file to be tracked and monitored. The path to the file can be absolute, or relative to the $ORACLE_HOME variable. The value of the $ORACLE_HOME variable is the value you set in the DB Home Directory field of the host configuration screen. (This is assumed to name a single file. Environment variables from the OS user environment can be used in the file name and will be expanded. For example, "$HOME/START.sh" will name the startup script in the Oracle user's home directory.)
Designates a group of files to be tracked and monitored. The path to the files can be absolute, or relative to the $ ORACLE_HOME variable. The value of the $ ORACLE_HOME variable is the value you set in the DB Home Directory field of the host configuration screen. A ".." in the path indicates one or more directories between the portion of the path above it and the portion of the path below it. A ".+" in the path indicates exactly one directory between the portion of the path above it and the portion of the path below it. For example: "$ORACLE_HOME/oradata/../*.dbf" (This is just a short-hand for creating many single file identifications from a single identification string, a file pattern. A file pattern can be viewed as a series of regular expressions separated by /'s. A file is matched if each element of its full path can be matched by one of the regular expressions in order. If an element of the pattern is an environment variable, it is expanded before the match begins. If ".." is one of the elements of the pattern, it will match zero or more directory levels. For example, "/usr/local/../foo" will match "/usr/local/foo" and "/usr/local/gunk/junk/bunk/foo". Using more than one ".." element in a file pattern should not be necessary and is discouraged because it makes the pattern very slow to expand. Because of the confusion with its use in regular expressions "\" cannot be used as a separator as it might be in Windows. The file pattern shown above is not correct because "*.dbf" is not a valid regular expression. It should be ".*dbf".)
Additionally, the default Guardium Unix/Oracle template set includes the following templates:
This test monitors that the listener.ora parameter ADMIN_RESTRICTIONS is set properly.
This test monitors file ownership, and changes thereto, of the Oracle data files, logs, executables, etc. (Exercise: Which of the file-patterns below is actually valid?)
File permissions
This test monitors file permissions, and changes thereto, on the Oracle data files, logs, executables, etc.
This test scans the Oracle log files for occurrences of error strings.
This test checks the existence of the Oracle SPOOLMAIN.LOG.
Designates an OS script to be executed. Output from the script is stored in the Guardium database. This can be either a shell/batch script to be run, or a set of commands that could be entered on the command.
Search Windows registry for specific key value that are required by security assessments test.
Designates an OS script to be executed. Must begin with the variable $SCRIPTS, which refers to the scripts directory beneath the CAS home directory, and identify the script to be executed, e.g., $HOME/sybase_sysdevice_type_test.sh". The script itself must, of course, reside in the CAS $SCRIPTS directory. Output from the script is stored in the Guardium database to be used by security assessments. This can be either a shell/batch script to be run, or a set of commands that could be entered on the command line. Because of the fickle nature of Java's parsing it is suggested that any but the simplest commands be put into a script rather than run directly. On Unix the script is run in the environment of the OS user entered. Three environment variables will be defined for the run environment which the user could use in writing scripts: $UCAS is the DB username, $PCAS is the DB password, and $ICAS is the DB instance name. For Windows these three values will be appended as the last three arguments to the batch file execution. For example, if you had an OS Script template "%SCRIPTS%\MyScript.bat my-arg1 my-arg2", then %3, %4 and %5 would be the DB username, password, and instance name respectively.
Designates a file to be tracked and monitored by security assessments. The path to the file can be absolute, or relative to the $SYBASE variable. The value of the $SYBASE variable is the value you set in the DB Home Directory field of the host configuration screen. This is assumed to name a single file. Environment variables from the OS user environment can be used in the file name and will be expanded. For example, "$HOME/START.sh" will name the startup script in the Sybase user's home directory.
Designates a group of files to be tracked and monitored by security assessments. The path to the files can be absolute, or relative to the $SYBASE variable. The value of the $SYBASE variable is the value you set in the DB Home Directory field of the host configuration screen. A ".." in the path indicates one or more directories between the portion of the path above it and the portion of the path below it. A ".+" in the path indicates exactly one directory between the portion of the path above it and the portion of the path below it. For example: "$SYBASE/../.*dat" This is just a short-hand for creating many single file identifications from a single identification string, a file pattern. A file pattern can be viewed as a series of regular expressions separated by /'s. A file is matched if each element of its full path can be matched by one of the regular expressions in order. If an element of the pattern is an environment variable, it is expanded before the match begins. If ".." is one of the elements of the pattern, it will match zero or more directory levels. For example, "/usr/local/../foo" will match "/usr/local/foo" and "/usr/local/gunk/junk/bunk/foo". Using more than one ".." element in a file pattern should not be necessary and is discouraged because it makes the pattern very slow to expand. Because of the confusion with its use in regular expressions "\" cannot be used as a separator as it might be in Windows.
Additionally, the "Guardium Unix/Sybase Assessment : UNX - SYBASE" set includes the following templates :
This test monitors for errors in Sybase log files.
This test monitors for ownership of sysdevice.
This test monitors file ownership, and changes thereto, of Sybase files.
This test monitors file permissions, and changes thereto, of Sybase files.
Designates an OS script to be executed. Must begin with the variable $SCRIPTS, which refers to the scripts directory beneath the CAS home directory, and identify the script to be executed, e.g., "$SCRIPTS/mysql_mysqld_user.sh". The script itself must, of course, reside in the CAS $SCRIPTS directory. Output from the script is stored in the Guardium database to be used by security assessments.
Designates a file to be tracked and monitored by security assessments. The path to the file can be absolute, or relative to the $MYSQL_HOME variable. The value of the $MYSQL_HOME variable is the value you set in the DB Home Directory field of the host configuration screen.
Designates a group of files to be tracked and monitored by security assessments. The path to the files can be absolute, or relative to the $MYSQL_HOME variable. The value of the $MYSQL_HOME variable is the value you set in the DB Home Directory field of the host configuration screen. A ".." in the path indicates one or more directories between the portion of the path above it and the portion of the path below it. A ".+" in the path indicates exactly one directory between the portion of the path above it and the portion of the path below it. For example: "$MYSQL_HOME/../data/.+/*.MYD"
The default Guardium Unix/MySQL template set includes the following templates supporting the tests indicated (note that some templates support more than one test, while some tests require more than one template):
This test monitors ownership, and changes thereto, of the MySQL data files.
$MYSQL_HOME/../data/.+/*.MYD
$MYSQL_HOME/../data/.+/*.MYI
$MYSQL_HOME/../data/.+/*.frm
This test monitors file permissions, and changes thereto, on the MySQL data files.
$MYSQL_HOME/../data/.+/*.MYD
$MYSQL_HOME/../data/.+/*.MYI
$MYSQL_HOME/../data/.+/*.frm
This test checks that the owner of the running mysqld process is a user other than the OS root user.
$SCRIPTS/mysql_mysqld_user.sh
This test monitors the MySQL error log for occurrences of the string "error".
find $MYSQL_HOME -name *.err -exec grep -i -l error {} \;
This test checks that the owner of the MySQL data directory is the OS User you specified when you configured the CAS host.
$SCRIPTS/mysql_datadir_owner.sh