This section describes Oracle Enterprise Manager Cloud Control's (Cloud Control) Compliance features include the ability to monitor certain elements of your targets in real time to watch for configuration changes or actions that may result in configuration changes.
These features include Operating System level file change monitoring, process starts and stops, Operating System user logins and logouts, Oracle database changes and more.
The real-time monitoring for these features takes place from the Cloud Control agent. Some of these monitoring capabilities require specific setup steps depending on the type of monitoring you will do and what Operating System is being monitored.
This chapter outlines the specific requirements and pre-requisites that exist to use the Compliance Real-time Monitoring features. For details on how to use Real-time monitoring from Cloud Control, see the chapter Compliance Management in this document. This chapter covers the following topics:
Real-time monitoring is configured through the Cloud Control Server. Users with the EM_COMPLIANCE_DESIGNER role create Compliance Standard Rules that are of type ”Real-time Monitoring Rule.” These rules are then associated with Compliance Standards and these standards are subsequently associated with one or more targets.
After the Compliance Standard to target association is complete, the set of monitoring rules are sent to the agent to enable real-time monitoring. All monitoring for Real-time monitoring occurs on the agents and all observed action data is sent from the agent to the Cloud Control server for reporting and data management.
The Real-time monitoring features are built into the Cloud Control agent. There are some specific resource considerations if you use the Real-time monitoring features. The following sections describe issues you should consider when using Real-time monitoring features.
An optional setting when monitoring for file changes in real time is to make an archive copy of the file on the agent. When monitoring first begins, a copy of the file at that time is made and stored into a private directory in the ORACLE_HOME directory of the agent. Then, any subsequent changes to that file will result in additional copies of the file being archived in that same directory. This feature allows you to later perform a file diff from the user interface or to issue a job to roll back a file to a previous version.
This feature however will use disk space to make copies of the file. Care should be taken to ensure that this feature is only enabled for files that are critical. During rule creation, the user can specify how many copies of a file to save. The default is five historic versions. This can also be adjusted to tune potential resource consumption.
Select the checkbox in the Ignore Events Prior to Rule field to ignore all previous Oracle database change events when the Oracle database monitoring module runs the first time.
The Operating System File level monitoring can monitor many types of changes to files, but can also monitor reads to files. If you have a Rule to monitor a facet that has file patterns that are read frequently, this may result in a very large number of observations. You can reduce the number of observations by ensuring that your Rule includes a filter on either time or a user that you want to ensure does not read the file.
For instance, monitoring the /etc/passwd file for reads for All users will result in many observations being created. However, if you only monitor the /etc/passwd file by a specific user, you can create a user filter for this specific user during rule creation. You will then only receive an observation when that specific user attempts to read the file.
It is important to remember that facets are created to specify files that are very important to monitor for security/compliance purposes. For instance, monitoring all modifies to a log file that change every few seconds will result in reporting many file changes making it harder for you to identify the critical file changes you care about. Instead, in this case, it may be appropriate to create a rule to monitor the log file for all changes, but filter only when the log change is made by a non-application user. This would only capture the log file change if a regular user attempted to change or tamper with the log rather than when the log is simply being updated by an application.
Database sizing considerations for Real-time monitoring depend on several factors. The most important factor is the number of observations expected in a month. The second factor is the number of months data will be retained in the repository. Repository retention rates are explained in the Enterprise Manager Administration Guide.
In general, each observation consumes roughly 1.5KB of space in the database. This is a guideline and this number can vary depending on many factors for each installation.
For example, if a customer expected a total of 10 million Real-time observations per month across all targets and wanted to retain the data for 12 months, then the database size required for this would be roughly 180GB.
10,000,000 Observations x 12 Months x 1500 Bytes = 180,000,000,000 Bytes
This size represents Real-time monitoring data only and does not include database storage needs for other areas of Cloud Control.
The number of observations to expect per month can vary from environment to environment and can also depend on what types of monitoring are configured. You may be required to tune the expected size over time after Rules and Facets have been enabled for some time and configured to fit the organizations requirements. You can easily find your observations usage over a month by selecting Compliance from the Enterprise menu, then choosing Browse By Systems UI Report from the Real-time Observations page to select your systems and see the related counts of observations for each system over a period of time.
Many of the real-time monitoring capabilities require monitoring credentials that maintain the ability to launch monitoring programs with root privileges. These processes that Real-time monitoring uses begin with the prefix nmxc. Low-level monitoring uses operating system APIs that are not available to regular users.
Before starting to use the Real-time monitoring features on a target host for the first time, the following settings must be configured from the Enterprise Manager Console.
Ensure that the agent's root.sh script is run after agent installation.
After installing the agent, the root.sh script must be run as the root user. This script must be run before configuring the rest of these credential steps.
Configure Privilege Delegation.
Privilege Delegation settings are found from the Setup menu by choosing Security, then Privilege Delegation. On this page you can either set privilege delegation for each host manually or you can create a Privilege Delegation Setting Template.
Privilege delegation for each host that will have real-time monitoring must have SUDO setting enabled with the appropriate SUDO command filled in (for example, /usr/local/bin/sudo).
Configure Monitoring Credentials.
Monitoring Credential settings are found from the Setup menu. Choose Security then Monitoring Credentials. From this page, select the Host target type and click Manage Monitoring Credentials.
For each entry with the credential ”Host Credentials For Real-time Configuration Change Monitoring”, select the entry and click Set Credentials. You will be asked for a credential set to use. Ensure you also add ”root” to the Run As entry. If ”Run As” is not visible, then the privilege delegation was not set properly in the previous step.
To set monitoring credentials in bulk on multiple hosts at once, you can use EMCLI. For more information on using EMCLI to set monitoring credentials, see the section, Managing Credentials Using EMCLI in the Security chapter of Oracle Enterprise Manager Administration. Likewise, for more information about configuring monitoring credentials in Cloud Control, the Security chapter of Oracle Enterprise Manager Administration.
The following sections describe how to prepare Linux hosts for monitoring.
Before using Real-time file monitoring for Linux, a loadable kernel module must be installed on the host. This loadable kernel module provides you with the most efficient way of monitoring the host. This loadable kernel module is referred to as the File Audit Module, or Audit Module for short.
Acquiring the Kernel Module
The kernel audit module is available from http://oss.oracle.com/projects/fileauditmodule. There are two ways to get the file audit kernel module:
Prebuilt .ko files for which Oracle has already prebuilt, you can use this in your environment. You can look for the Prebuilt kernel modules under the Downloads link. To find the matching prebuilt version, run the uname -r command on the host being monitored and compare that version to the version of the prebuilt modules. The complete version string must match perfectly. For 32-bit machines, the post-fix of the .ko file name will be .ko. For 64-bit machines, the post-fix of the .ko file name will be .k64.ko.
Build your own kernel module. To build your own kernel module, you can download the following RPM from the Downloads link:
Fileauditmodule-emversion-revision-noarch.rpm
You should always retrieve the latest revision available at the time you are installing this module. The emversion field must match the version of Cloud Control agent and server you are using.
Install this RPM on the host you want to monitor as root. The installation of this RPM depends on the kernel-devel package matching your running kernel also existing on the host. This kernel-devel package comes with the same media as the Linux installers.
In addition to installing this package, you must ensure that the version of gcc available on your host matches the version with which the kernel was built. To do this, view the /proc/version file to see what gcc version the kernel was built with and then run the command gcc –v to see what version of gcc is being used. These two versions should match.
Also check that the file /boot/System.map-{version} exists where {version} must match the kernel version you see when you run the uname -r command. This file contains system symbols that are required to decode the kernel symbols we are monitoring for real-time changes. Without this file, real-time file monitoring will not function. This file is standard on all default Linux installations.
After installing this package and checking prerequisites successfully, go to the directory where the package contents were installed (defaults to /opt/fileauditmodule) and run the following script:
compmod.sh
This will build the kernel module file (.ko, .k64, or .o extension depending on the OS version) and place it in the /opt/fileauditmodule directory.
If the audit module file is not created, check the make.log and build.log files for any errors in building the module.
If all of your hosts have the exact same kernel version as shown using the command uname –r, then you only need to compile the module on one machine. You can then copy the .ko, .k64, or .o file to the other servers without having to build on that specific host.
Deploying the Kernel Module
Once you have either the prebuilt .ko file or a .ko file that exists from building it from the source RPM, the .ko file must be located in the proper directory. The default location for this file is in the bin folder under the agent home directory. You can also place the file in any location on the host and change the nmxc.properties file under the AGENT_INST/sysman/config directory of the agent home. The property nmxcf.kernel_module_dir specifies the absolute path to the .ko directory.
Install Kernel Module Job
In addition to manually placing the .KO file on the agent, there is a Cloud Control job named Real-time Monitoring Kernel Module Installation. This job is configured with a list of Linux hosts on which you can install the kernel module. It will search in a directory locally on the Cloud Control server disk for prebuilt .ko files or the source RPM file. If it finds a matching prebuilt .ko file, it will send this to the matching agents; otherwise it will send the RPM to the agent and install and compile it resulting in a new .KO file.
Prior to using this job, files from OSS.ORACLE.COM must be manually retrieved by the user and placed into the
%ORACLE_HOME%/gccompliance/fileauditmodule/resources/linux directory. This directory already exists on the server with a README file indicating this is the location to place these files. The files that must be placed here are either prebuilt .KO files or the source RPM file. If you have built your own .KO files in your environment, you can also place those .KO files into this directory on the server and deploy it to other hosts in your environment.
Special Considerations for Enterprise Linux 5 and Greater
For Enterprise Linux 5 and greater, the kernel audit module is not required. The monitoring will use the built-in audit subsystem if a kernel module is not detected at startup time. However, the functionality of the audit subsystem is not as robust as the capability that the kernel audit module can provide.
You will lose the functionality that provides the granularity of what type of change there has been to a file, whether it was a create action or a modify action. Without the kernel module, all changes to a file will appear as a modify action. Additionally, monitoring a directory that does not exist yet or a directory that may exist now and gets removed later may be disrupted since the underlying Linux audit subsystem does not handle these cases.
It is recommended that you use the kernel audit module even with the newer versions of Linux, if possible.
You may detect a problem with the kernel module in a few different ways:
You may have noticed that you do not receive real-time file changes on the Enterprise Manager console for file changes that you know should occur.
In the Compliance Standard Target Associations or Real-time Observations page on the user interface, you may see an agent warning indicating a kernel module problem.
When examining the nmxcf.log file under AGENT_INST/sysman/logs, you may see errors indicating that the kernel module could not be loaded or used for various reasons.
If you encounter any of these issues, most likely there was a problem with compiling or inserting the Linux kernel module at run time.
You can confirm whether the auditmodule was loaded properly by running the following command.
grep -i auditmodule /proc/modules
If you do not receive any output, then the auditmodule is not loaded and the agent will not perform real time file monitoring.
If the audit module file was generated properly and it does not show up in the module list above, you can attempt to manually load the module to see if there are any errors. Use the following command where you replace {audit module file name} with the entire name of the .ko file that was created from compmod.sh:
insmod {audit module file name}
If you experience no errors during this command, you can check the module list again by using the grep command above. If the audit module now appears, then the file monitoring capability should work. An agent restart is necessary; however there still may be a problem with the file monitoring process finding the .ko file which you will experience again next time your host is rebooted.
One additional step to debug any issues with the file monitoring process is to try to run it manually. To do this, follow these steps:
Get the process ID of the agent TMMain process:
ps –eaf |grep TMMain
Execute the nmxcf process using the following command replacing the values in {} with the proper path elements or the process ID from the previous command:
sudo {agent_home}/core/{agent_version}/bin/nmxcf -e {agent_home}/agent_inst/ -m {agent_home}/agent_inst/sysman/emd/state/fetchlet_state/CCCDataFetchlet –w {process id of TMMAIN}
Running the nmxcf process this way will not work in the long term since it will not start up again when the agent is restarted, but this can help in trying to debug any issues as to why the process cannot start.
If the module still is not able to load and if you need to contact Oracle support about the issue, please be sure to include the following information with your support ticket:
Output of the command: uname -a
Output of the command: grep –i auditmodule /proc/modules
Output of the command: rpm –q –a |grep –i kernel-devel
The make.log and build.log files from the /opt/fileauditmodule directory where you ran compmod.sh if you built your own .ko file
The files AGENT_INST/sysman/log/nmxc*.log
Any warnings or errors you received when trying to start nmxcf manually.
This information will help Oracle Support to determine if the real time file monitoring audit module of the agent can be built on your environment.
Warning:
Be careful when using the Linux OS command rmmod which is used to unload a kernel module. If the nmxcf binary is running and you use rmmod, there is a chance that a kernel panic can arise by trying to unload a kernel module in use. The use of rmmod in Linux should be done carefully no matter which module you are unloading.The Real-time monitoring features support Windows 2003 and 2008 Server along with Windows XP. The Real-time monitoring modules for Windows rely on various capabilities of the operating system to collect all of the information on actions. One part of this is to capture the user that made changes from the Windows Event Log. If you do not configure Windows to capture users that make changes, the agent will not capture this information. However it will still capture that a change occurred and when it occurred.
To configure the event log to work with real time monitoring, perform the following steps:
From Windows Explorer, select the directory that is being monitored by a Real-time Monitoring Rule, right-click and select Properties.
Go to the Security tab.
Click Advanced.
Select the Auditing tab.
Click Add. (In Microsoft XP, double-click the Auditing Entries window).
Select the Name Everyone, then click OK. You can also choose specific users if you are only monitoring for changes by specific users in Configuration Change Console rules. The rules filter the results by user as well, so even if you enable audit for everyone, only users that you want to monitor changes of in your rules will be captured.
Select the following options (Successful and/or Failed) from the Access window. For Windows XP and Windows 2003:
Create Files/Write Data
Create Folders/Append Data
Delete Files Subfolders and Files
Delete
For Windows 2008 and Windows 7:
Create Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Files Subfolders and Files
Delete
Change Permissions
Take Ownership
Click OK to exit.
Repeat steps 1 through 7 for all other monitored directories and/or files.
From the Start menu, select Settings, then Control Panel, then Administrative Tools , then Local Security Policy, then Local Policies, then Audit Policy. Double-click and turn on the following policies (Success and/or Failure):
Audit account logon events
Audit logon events
Audit object access
Close the Local Security Settings screen.
From the Start menu, select Settings, then Control Panel, then Administrative Tools, and finally Event Viewer.
Select System Log, then click Action from the menu bar and select Properties.
From the System Log Properties panel, on the General tab, set the Maximum log size to at least 5120 KB (5 megabytes) and select Overwrite Events as Needed. Note that the log size depends on the number of events generated in the system during a two-minute reporting interval. The log size must be large enough to accommodate those events. If you extend the monitoring time for file events because you expect the change rate to be lower, you need to ensure that the audit log in Windows is large enough to capture the events.
Click Apply then OK to exit.
If Windows auditing is not configured properly, you will see warnings on the Compliance Standard Target Association page on the Cloud Control user interface. This is the same page where you associated your Real-time Monitoring compliance Standards to your targets.
To verify that the host records login and logout events, follow these steps:
Log out of the host and then log back into the host.
From Start, select Settings, then Control Panel, then Administrative Tools, and finally Event Viewer.
Select Security Log and choose Filter from the View menu. Select Security for the Event Source and Logon/Logoff for the Category fields.
Click OK.
The Event Viewer should have the activity recorded as Event 528.
As mentioned earlier, the agent will send warnings to the server when audit settings are not set properly. It, however, can only do this if the windows feature SUBINACL is installed. If this feature is not installed on the host, a warning will be sent to the server saying that the agent cannot detect whether audit settings are correct. This warning will be visible from the Compliance Standard Associate Targets page.
You can specify the absolute path to the directory that contain subinacl by setting the following property in the AGENT_INST/sysman/config/nmxc.properties file:
nmxcf.subinacl_dir=
SubInACL is available for download from Microsoft's Web site.
Real-time monitoring on Solaris systems utilizes the Solaris audit system which is part of the Solaris Basic Security Model (BSM). BSM auditing allows system administrators to monitor events and to detect user account logins and logouts as well as file changes.
Verify that BSM auditing is enabled by running the following command with root privilege:
/usr/sbin/auditconfig –getcond
You should see the following output:
audit condition = auditing
If the output is different from the above, it means the BSM auditing needs to be enabled through different methods in different Solaris releases.
You can enable BSM auditing using the steps below for each of the following environments.
To enable BSM auditing, you can use the following command with root privilege:
/etc/security/bsmconv
See the Solaris BSM Auditing manuals for additional details on setting up BSM auditing.
If auditing is already enabled on the server, simply verify that the audit system configuration matches the configurations detailed below.
The audit file can be configured to include specific events. The /etc/security/audit_control file controls which events will be included in the audit file. This section summarizes the configuration; for further details, refer to the Sun Product Online Documentation site.
For monitoring entity types OS FILE (file changes) and OS USER (user logins/logouts), the flags line in the file /etc/security/audit_control should be set as follows:
flags: +fw,+fc,+fd,+fm,+fr,+lo
This configuration enables success/fail auditing for file writes (fw), file creates (fc), file deletes (fd), file attribute modifies (fm), file reads (fr) and login/logout events (lo); where '+' means to only log successful events.
If you are interested in logging the failed events as well, remove the "+" sign before each event in the flag.
Note:
Installing BSM on an existing host has the requirement that the host is rebooted.Auditing Users: The audit_user file controls which users are being audited. The settings in this file are for specific users and override the settings in the audit_control file, which applies to all users.
Audit Logs and Disk Space: The audit_control file uses entries to control where the audit logs are stored and the maximum amount of disk space used by the audit system. The minimum requirement for file monitoring is approximately 10 minutes worth of data stored on the hard drive or the configured reporting interval time.
Auditing is enabled by default on Solaris 11, but only user login/logout events are monitored by default. For monitoring both the OS File change events and OS USER logins/logout events, you can execute the following command with root privilege:
/usr/sbin/auditconfig -setflags fw,fd,fc,fm,fr,lo
The configuration flags have the same meaning as defined in the last section.
Note:
This configuration will not affect the existing sessions in which users already log into the host, so you must terminate all the existing sessions and then re-login or simply reboot the machine to ensure this change takes effect.As the bsmconv command has been removed on Solaris 11, you can use the following command to enable the auditing feature, if needed:
audit -s
Cloud Control Real-time Monitoring only reads the audit logs; it does not delete the logs. This might flood the system with log files and prevent it from logging additional events. To manage and delete old audit events while maintaining minimum monitoring requirements, follow these steps:
The auditing policy can be set to automatically drop new events (keeping only a count of the dropped events) rather than suspending all processes by running the following command:
# auditconfig -setpolicy cnt
Run the following command to force the audit daemon to close the current audit log file and use a new log file:
/usr/sbin/audit -n
Run the following command to merge all existing closed auditing log files into a single file with an extension of .trash and then delete the files:
/usr/sbin/auditreduce -D trash
Create a cron job to periodically run the commands in Step 2 and 3 above. The frequency at which these two commands are run can be adjusted based on the anticipated event volume and the amount of disk space allocated to auditing. The only requirement is that the time between the audit -s command and the auditreduce - D trash command is at least 15 minutes or twice the reporting interval if that is changed.
Real-time monitoring on AIX systems utilizes the underlying AIX audit subsystem provided by the OS. IBM AIX 5.3 and 6.1 are the only currently supported versions.
Before using Real-time monitoring on AIX 5.3 hosts, ensure that you are using AIX 5.3 5300-08 service pack or higher. This maintenance package is available from IBM.
The AIX auditing subsystem allows an administrator to record security-relevant information, such as User Logins, Logouts, and file changes, for analysis against existing security policies and detection of security violations.
Setting up auditing involves modification of the existing auditing configuration files. To set up auditing, follow these steps:
Log into the AIX machine as the root user.
Open a terminal window and change directory to /etc/security/audit
Open the config file in vi.
Locate the following sections, and update or add the listed values:
start: binmode = off streammode = on stream: cmds = /etc/security/audit/cccstream classes: … filewatch = PROC_Create,PROC_Delete,FILE_Open,FILE_Write,FILE_Close,FILE_ Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Fchmod,FILE_Fchown,FS_Chdir,FS_Fchdir,FS_Chroot,FS_Mkdir,FS_Rmdir,FILE_Symlink,FILE_Dupfd,FILE_Mknod,FILE_Utimes users: root = filewatch default = filewatch
Note:
In this case default refers to all users that are not root. Further note that the last line of the config file should be a blank line.Note:
Each parameter (binmode, streammode, filewatch, root, and default) must have a tab in front of them. You can verify that the audit system has used all variables properly by using the audit query command. Make sure the filewatch property appears in the output.Save your modifications and exit vi.
In the same directory (/etc/security/audit/) open the file streamcmds in vi.
Clear all text from the file. The default configuration for this file is not necessary, as the File Monitoring agent module (nmxcf process) will operate as a direct audit reader. Clearing the file helps to reduce CPU usage and improve overall auditing performance.
Save the file and exit vi.
At the terminal prompt, enter the following command to initialize Auditing at system startup:
mkitab "audit:2:once:/usr/sbin/audit start"
At the prompt, restart audit using the command /usr/sbin/audit shutdown and /usr/sbin/audit start or directly reboot the host to make the auditing effective.
At the prompt, use the command audit query to view the configuration the audit system is using. Ensure that the properties are set correctly and that the required settings for filewatch are set.
The OS User monitoring module relies on the following system log files:
/etc/security/failedlogin
/var/adm/wtmp
/var/adm/sulog
Be sure the log files exist before running the OS User monitoring module on an AIX host. If any of the log files is missing, refer to the AIX System documentation for more information about how to generate it.
This section describes the steps involved in setting up auditing within an Oracle database. If you are going to monitor an Oracle database with any of the Oracle entity types, you will need to perform these steps before events will be captured.
Before configuring auditing it is suggested you review the Auditing Database Use section of the Oracle Database Administrator's Guide. This document provides an overview of Oracle's auditing functionality, as well as basic concepts and guidelines for auditing configurations. Note that this document does not cover all details of configuring and fine tuning the Oracle audit system. Instead, this document serves as an example of the basic steps involved to configure the Oracle audit system to enable Real-time monitoring through Real-time monitoring rules.
When you create a Real-time Monitoring Compliance Standard Rule to monitor an Oracle instance target, the agent will read the audit trail to perform its monitoring.
Real-time monitoring for Oracle entity types requires the audit trail to be stored in the database as opposed to a file. To verify if a setting is correct, follow these steps:
In Cloud Control, go to the target home page for the Oracle Database target for which you want to enable Real-time Monitoring.
From the Administration menu, select Initialization Parameters.
Log in to the database as a sys user, connecting as SYSDBA.
Find the parameter audit_trail and ensure it is set to DB. If not, this parameter needs to be changed in the Oracle Database.
This change will require a restart of the database.
Through SQL plus, an Oracle DBA can use audit and noaudit statements to configure audit options for the database. The audit statement allows you to set audit options at three levels:
Table 47-1 Audit Options Table
| Level | Effect |
|---|---|
|
Statement |
Audits specific SQL statements or groups of statements that affect a particular type of database object. For example, AUDIT TABLE audits the CREATE TABLE, TRUNCATE TABLE, COMMENT ON TABLE, and DELETE [FROM] TABLE statements. |
|
Privilege |
Audits SQL statements that are executed under the umbrella of a specified system privilege. For Example, AUDIT CREATE ANY TRIGGER audits statements issued using the CREATE ANY TRIGGER system privilege. |
|
Object |
Audits specific statements on specific objects, such as ALTER TABLE on the employee table |
To use the audit statement to set statement and privilege auditing options a DBA must be assigned AUDIT SYSTEM privileges. To use the audit statement to set object audit options, the DBA must own the object to be audited or be assigned the AUDIT ANY privilege within Oracle. Privilege assignments are covered in the following section.
Audit statements that set statement and privilege audit options can also include a BY clause to supply a list of specific users or application proxies to audit, and thus limit the scope of the statement and privilege audit options.
Some examples of audit statements can be seen below. Feel free to use these as a basis for the audit settings you specify within your database. Once all audit settings are in place you can create application policies, using the Oracle (SQL Trace) agent module with which to monitor the Oracle database instance.
Statement Audit Options (User sessions)
The following statement audits user sessions of users Bill and Lori.
AUDIT SESSION BY scott, lori;
Privilege Audit Options
The following statement audits all successful and unsuccessful uses of the DELETE ANY TABLE system privilege:
AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
Object Audit Options
The following statement audits all successful SELECT, INSERT, and DELETE statements on the dept table owned by user jward:
AUDIT SELECT, INSERT, DELETE ON jward.dept BY ACCESS WHENEVER SUCCESSFUL;
Example Oracle Audit Monitor Configurations
The following command audits all basic statements. Extra statements are not audited.
Audit all by access;
The following statement audits all extra statements:
audit ALTER SEQUENCE, ALTER TABLE, DELETE TABLE, EXECUTE PROCEDURE, GRANT DIRECTORY, GRANT PROCEDURE, GRANT SEQUENCE, GRANT TABLE, GRANT TYPE, INSERT TABLE, LOCK TABLE, UPDATE TABLE by access;
The following command displays audit settings for statements:
SELECT * FROM DBA_STMT_AUDIT_OPTS;
Once you have specified your audit configuration you can then create real-time monitoring rules from the Cloud Control Server that uses the Oracle Database entity types.
This section explains how to install and configure integration with a Change Management Server and to be able to determine whether changes that occur are authorized automatically.
Remedy ARS 7.1 is a supported Change Management system for automatic reconciliation of observations. The following steps outline how to setup Remedy and also configure the integration with Cloud Control.
Follow these steps to install and customize Remedy ARS 7.1.
Install Remedy ARS 7.1. Ensure the following components are all installed and properly licensed:
ARS 7.1.00 Patch 011
Midtier 7.1.00 Patch 011
Flashboard Server 7.0.03
Assignment Engine 7.1
Asset Management 7.0.03*
CMDB 2.1.00 Patch 4
CMDB Extension Loader
Approval Server 7.1
Change Management Server 7.0.03 Patch 008*
Problem Management Server 7.0.03*
Incident Management Server 7.0.0*3
User Client
Administrator Client
These packages all come with the IT Service Management Pack. Oracle provides example customizations for the Remedy under ITSM 7.0.03 Patch 008 environment. For different versions, the customizations may need to be adjusted to account for changes in the version of Remedy.
Install the Cloud Control EMCLI_Client on the same host on which Remedy is installed. This will need to be able to communicate to your Cloud Control Server.
Log in to the Enterprise Manager console.
Choose Setup, then select Command Line Interface from the My Preferences menu.
Click Download the EM CLI kit to your workstation and download the jar to your Remedy server.
Follow the steps given on the page to install the EMCLI client on the Remedy server.
Get the latest version of the Change Request Management connector self-update package. Also acquire the latest version of the example Remedy ARS customizations for Cloud Control version 12c.
These definition files provide a guideline of customizations that must be made in your environment for the integration. These customization files assume a fresh install of Remedy ARS. When integrating with a production instance of Remedy, care should be taken to make sure these customizations are compatible with any previous customizations that have been made to the Remedy instance.
ActiveLinks _Customization.def
Forms_Customization.def
Menus_Customization.def
Webservices_Customization.def
To get these definition files, in the Enterprise Manager Self Update user interface, export the connector. The definition files are inside this connector package.
Install the four definition files (.DEF) files in the running Remedy environment by completing these steps:
Log into the Remedy Administrator tool.
Select the Remedy instance from the hierarchy on the left.
From the Tools menu, select Import Definitions, then select From Definition File...
Select the definition file to import from the list above.
Check the box labeled Replace Objects on the Destination Server.
Choose the drop down option Replace With New Type.
Click Import.
You should not encounter any errors during this process. At the end of import there should be an Import Complete message.
When done, repeat for the rest of the customization files.
Customize Web Services.
Log into Remedy Administrator tool.
Select Webservices, then select the webservice EMCCC_GetCR. Right click, then select Open.
Select the WSDL tab.
In the input on top, modify the midtier_server and servername values in the WSDL Handler URL.
If midtier is on localhost, you can enter localhost right after http://.
If the midtier uses port 80, you can omit the port, otherwise include the port after the server name.
For the servername after "public/", enter the name of the Remedy server.
Click View.
You should see an XML representing the webservice WSDL file for the webservice.
If you see an error, check the midtier_server name, port, or servername. Also, you can try adding/removing the domain part of the servername. Another possible issue occurs when the midtier password set in Remedy's System > General > Serverinfo > Connection Settings may not be set correctly. Be sure to check this also if the WSDL XML is not returned.
If you see the XML content after clicking View, then close this window and save the changes.
Repeat all above steps with the webservices EMCCC_PublishCSData and EMCCC_UpdateChangeRequest.
Customize Active Links.
Log in to Remedy Administrator tool.
Select active links and then select the active link EMCCCC_ApprovedCR. Right click, then select Open.
Click the If Action tab.
Click the Current Action Run Process at the end of the list of actions.
In the Command Line field, change the path to emcli.bat to match that of where you installed the emcli on the local host.
Create a user in Remedy that will be used for creating requests that will be used for automatic observation reconciliation:
Log in to BMC Remedy User Client as an administrative user.
Click Application Administration Console on the User Client Home Page.
Click Create for each step 1 through 4 in this wizard.
When adding the person, add the support group under the Support Groups tab.
Under the Support Groups Tab, select sub tab Support Group Functional Roles.
Add Support groups with functional role of Infrastructure Change Management. Without this, you will not be able to create change requests as the Infrastructure Change Manager fields support group will not have values.
Go to AR System Administrator Console.
On the left side bar, select Application, then Users/Groups/Roles, then Select Users.
This will load the user search page. Click Search at the top right.
Double-click the newly created user above to bring up the user form.
Click the down arrow next to "Group List" field and select Infrastructure Change Master.
Repeat the previous step and add the following Groups to this user as well.
Infrastructure Change Submit
Infrastructure Change User
Infrastructure Change Viewer
Save the changes to this user by clicking the Save button in the upper right hand corner of the window.
Follow these steps to add the connector to Cloud Control.
Add the Change Management Connector to Cloud Control.
Log into Enterprise Manager as an Administrative user that has privileges to create a connector.
From the Setup menu, select Provisioning and Patching, then choose Software Library.
Click Actions, then select Administration.
Click Add.
Provide a name, such as "self update swlib".
Provide a location where the swlib files will be located on the Cloud Control server. This can be anywhere, but must be a path that the Cloud Control user can access. You must put the full absolute path in this input.
This process will take several minutes to complete.
Locate the connector self-update package file.
The connectors jar can be downloaded from the Cloud Control store to EM@Customer using the Self Update console, and can be exported to any local directory using the export functionality of Self Update.
Run: emcli import_update -file=<full path>/connector.zip –omslocal (where connector.zip is an example name of the self update package)
If you have errors with the previous step, make sure the user you run emcli as has permissions to access this directory and file. Also, be sure you are using absolute path for the -file switch.
When successful, you will receive the following message:
Operation completed successfully. Update has been uploaded to Cloud Control. Please use the Self Update Home to manage this update.
Log into the Enterprise Manager console.
From the Setup menu, select Extensibility, then select Self Update.
Find the type "Management Connector" and click the link "1" under "Downloaded Updates" for this entry.
Select the Connector from the table and click Apply.
Create a Change Management Connector instance.
Log in into Enterprise Manager console.
From the Setup menu, select Extensibility, then select Management Connectors.
Select "Remedy Change Management Connector" from the drop-down after "Create Connector", then click Go.
Provide a name and description for the connector. This name is used to choose the connector when creating a Real-time Monitoring Compliance Standard Rule.
After returning to the management connector listing page, select the newly added row, then click Configure.
Under the Web Service End Points label, change the [servername] and [port] to match that of your Remedy instance Web Services. The values you put here will be similar to what you configured in the Web Services step earlier in these instructions.
Enter the Remedy username and password you are using for the connector integration.
Enter the locale ('en', for example).
Enter the time zone offset of the remedy server from UTC, ('-08:00', for example).
Enter the Change ID to use as a test. This should be a valid Change Request ID currently existing in Remedy that is used to test the connectivity between Cloud Control and Remedy.
Once Remedy is customized and the Cloud Control connector is configured, to utilize the automatic reconciliation features you need to create Real-time Monitoring Rules that are configured to use automatic reconciliation. Use the following steps:
Create a Real-time monitoring Rule:
Follow the normal steps to create a Real-time monitoring Rule.
On the Settings page, choose Authorized Observations Automatically using Change Request Management System. This configures Cloud Control to use this change request from Remedy for reconciliation of Real-time Observations that are detected.
Select the connector from the drop-down.
Click to annotate change requests with authorized observations check box.
Continue to save the rule after this. The Real-time Monitoring Rule can be used like any other Real-time Monitoring rule. The integration with a new Change Management server will not begin until at least one Real-time Monitoring Standard with a rule using Automatic Reconciliation is associated to a target. Create a Compliance Standard, add this rule to the Compliance Standard, and associate this compliance standard to one or more targets.
The configuration of rules is discussed in more detail in the Compliance Management section.
Now that integration is set up and Real-time monitoring rules have been created, Change Requests can be created by Remedy users in the Remedy interface. These Change Requests will be compared to observations that occur to automatically determine if these observations are from actions that were authorized by change requests or not.
To make this correlation, some new fields that have been added to the Change Request form must be filled out by the change request filer. Not all fields are required; correlation only occurs on the fields that are present in the Change Request.
For instance, the following fields have been added to the Change Request form under the Oracle Enterprise Manager Integration tab:
Connector: Choose the Cloud Control connector this Change Request will use to integrate with Cloud Control.
Hostname: the hostname(s) this change request is for. These are the hosts that this change request is specifying someone needs to make changes to. An empty value in this field indicates that all hosts will be correlated to this change request.
Target User List: the user name(s) this change request is for based on target users. These are the target users you expect to log in to the target to make a change. An empty value in this field means that all users on the target will be correlated to this change request.
Target Type: the target type this change request is against. An empty value in this field means that any target type will be correlated to this change request.
Target: The target this change request is specifically for. An empty value in this field indicates that any target will be correlated to this change request.
Facet: The facet this change request is specifically for. An empty value in this field indicates that all facets on the above target type and target will be correlated for this change request.
When creating a change request that you want to use to authorize changes detected by Real-time monitoring rules, follow these steps in addition to whatever requirements your organization implements for creation of Change Requests:
Under the Dates tab of the Change Request form, fill out the Scheduled Start date and Scheduled End Date. These are the date ranges the request is valid for reconciliation. If an action occurs outside this time, it is marked as unauthorized by the Real-time Monitoring feature.
Select the Oracle Enterprise Manager Integration tab.
Select the Cloud Control connector from the drop-down list.
Optionally select values for the five reconciliation criteria as described above: Hostname, Target User List, Target type, Target and Facet. The last three -- Target Type, Target, and Facet -- will be Choice lists based on content in Real-time Monitoring Rules that have been created in Cloud Control that belong to Compliance Standards which are associated to targets. You can add multiple values separated by commas.
Note:
This form can be customized in Remedy to look differently. The example form elements from the customizations loaded earlier are only examples.Change the auditable status to True. This configures Remedy to allow Cloud Control to use this change request for reconciliation of Real-time Observations that are detected.
Save the change request.
A popup displays, notifying you that active links will send the content to Cloud Control. You will see a DOS command window open and then close.
After creating a change request that references a target and/or facet that is being monitored by Real-time Monitoring rules, any observations that happen against that rule will be correlated to all open and matching change requests.
When the observation arrives at the Cloud Control server, all open change requests that were active (based on Scheduled Start/Stop time) and have matching correlation criteria from the Cloud Control Integration tab will be evaluated. If any change request exists that matches the criteria of the observation, this observation will be marked with an ”authorized” audit status. If the annotation check box was checked in the Rule configuration, details of these authorized observations will be put into a table in the Enterprise Manager Integration tab of the Remedy Change Request.
If no open change requests can be correlated to the observation and the rule was configured to use automatic reconciliation, then this observation is set to an Unauthorized audit status. The Observation bundle to which this observation belonged will be in violation and results in a Cloud Control event being created. This event can further be used through creation of a Cloud Control Event Rule.
An observations audit status can be seen whenever looking at observation details either by selecting Compliance, then Real-time Observations, then Observation Search, or either of the Browse By screens. A user with the proper role can also override the audit status for individual observations from these pages.
Any bundles that are in violation because they contain unauthorized observations will be reflected as violations in the Compliance Results page. These violations cause the compliance score skew lower. If these violations are cleared, the score becomes higher; however, the history of these audit status changes will be retained for the given observation.
The following views exist to allow access to Real-time Monitoring data.
View: mgmt$ccc_all_observations
Description: This view returns all observations that have occurred. Any query against this view should ensure that filtering is done on appropriate fields with action_time being the first to take advantage of partitions.
Fields:
| Field | Description |
|---|---|
| OBSERVATION_ID | Unique ID given to the observation when detected by the agent |
| BUNDLE_ID | Bundle to which this observation belongs based on rule bundle settings |
| TARGET | Target this observation was found against |
| TARGET_TYPE | Type of the target |
| ENTITY_TYPE | Entity type of the entity that had an action against it |
| ACTION | Action that was observed |
| ACTION_TIME | Time the action occurred |
| USER_TYPE | Type of user that performed the action (for example, OS user versus DB user) |
| USER_PERFORMING_ACTION | Name of the user that performed the action |
| ORIGINAL_USER_NAME | Previous user name in the case of a SU/SUDO action (only applicable to some entity types) |
| AFFECTED_ENTITY_NAME | Name of the entity that was affected by this action (file name, and so on) |
| AFFECTED_ENTITY_PREVIOUS_NAME | Name of the entity prior to the action. For instance for file rename actions, this would be the old file name. |
| SOURCE_HOST_IP | Source IP of a connection when an action comes from another host (only applicable to some entity types) |
| ACTION_PROCESS_ID | PID of the process that performed the action (only applicable to some entity types) |
| ACTION_PROCESS_NAME | Name of the process that performed the action (only applicable to some entity types) |
| ACTION_PARENT_PROCESS_ID | PID of the parent process of the process that performed the action (only applicable to some entity types) |
| ACTION_PARENT_PROCESS_NAME | Name of the parent process of the process that performed the action (only applicable to some entity types) |
| ENTITY_PREVIOUS_VALUE | Previous value of the entity (only applicable to some entity types) |
| ENTITY_NEW_VALUE | New value of the entity (only applicable to some entity types) |
| FILE_ENTITY_PREVIOUS_MD5_HASH | Previous MD5 hash value of the entity (only applicable to some entity types) |
| FILE_ENTITY_NEW_MD5_HASH | New MD5 hash value of the entity (only applicable to some entity types |
| AUDIT_STATUS | Current audit status of the observation (unaudited, authorized, unauthorized, and so on) |
| AUDIT_STATUS_SET_DATE | Date the most recent audit status was set |
| AUDIT_STATUS_SET_BY_USER | User who set the most recent audit status |
View: mgmt$ccc_all_obs_bundles
Description: This view returns a summary of all observations bundles. Any query against this view should ensure that filtering is done on appropriate fields with bundle_start_time being the first to take advantage of partitions.
Fields:
| Field | Description |
|---|---|
| BUNDLE_ID | Bundle to which this observation belongs based on rule bundle settings |
| TARGET | Target this observation was found against |
| TARGET_TYPE | Type of the target |
| RULE_NAME | Name of the Real-time Monitoring Compliance Standard Rule |
| ENTITY_TYPE | Entity type of the entity that had an action against it |
| USER_PERFORMING_ACTION | Name of the user that performed the action |
| BUNDLE_IN_VIOLATION | Boolean value if the bundle currently is in violation. This means at least one observation in the bundle is unauthorized. True indicates the bundle is in violation. |
| BUNDLE_START_TIME | Date of the first observation in this bundle |
| BUNDLE_CLOSE_TIME | Date when this bundle was closed |
| BUNDLE_CLOSE_REASON | Explanation of why this bundle was closed |
| DISTINCT_OBS_COUNT | Total number of observations in this bundle |
| AUTHORIZED_OBS_COUNT | Number of observations in this bundle that are currently authorized |
| UNAUTHORIZED_OBS_COUNT | Number of observations in this bundle that are currently unauthorized |
| UNAUTH_CLEARED_OBS_COUNT | Number of observations in this bundle that are currently cleared (that were at one point unauthorized) |
| UNAUDITED_OBS_COUNT | Number of observations in this bundle that are currently unaudited. They have not been evaluated manually or with Change Management integration to determine audit status. |
View: mgmt$ccc_all_violations
Description: This view returns all real-time monitoring violations caused by an observation bundle having at least one unauthorized observation in it.
Fields:
| Field | Description |
|---|---|
| ROOT_CS_ID | Root Compliance Standard GUID. This is used for internal representation of the violation context. |
| RQS_ID | Runtime compliance standard GUID. This is used for internal representation of the violation context. |
| RULE_ID | Rule GUID. Internal ID of the rule having a violation. |
| TARGET_ID | Target GUID. Internal ID of the target having a violation. |
| ROOT_TARGET_ID | Root Target GUID. Internal ID of target hierarchy. |
| RULE_TYPE | Type of rule (Repository, Weblogic Server Signature, Real-time Monitoring) |
| SEVERITY | Severity Level of the rule (Info, Warning, Critical) |
| BUNDLE_ID | Internal ID of the Observation Bundle that is in violation. This observation bundle has one or more unauthorized observations in it |
| BUNDLE_START_TIME | Time the Observation Bundle started |
| BUNDLE_CLOSE_TIME | Time the Observation Bundle closed |
| TARGET_TYPE | Target Type of the Observation Bundle and all observations inside that bundle. |
| ENTITY_TYPE | Entity Type of the Observation Bundle and all observations inside that bundle. |
| USER_NAME | User name that performed the actions in this bundle |
| AUTHORIZED_OBS_COUNT | Number of Authorized observations in the observation bundle involved in this violation. |
| UNAUTHORIZED_OBS_COUNT | Number of Unauthorized observations in the observation bundle involved in this violation. |
| UNAUDITED_OBS_COUNT | Number of unaudited observations in the observation bundle involved in this violation. |
| RULE_NAME | Rule Name this violation is against. |
| COMPLIANCE_STANDARD_NAME | Compliance Standard Name this violation is against. |
| TARGET | Target Name this violation is against. |
View: mgmt$compliant_targets
Description: This view returns all evaluation and violation details for all targets. This is the same data that is shown in the Compliance Summary dashboard regions for targets.
Fields:
| Field | Description |
|---|---|
| TARGET_ID | Internal representation of the Target |
| TARGET_NAME | Name of the Target |
| TARGET_TYPE | Target Type of the Target |
| TARTGET_TYPE_INAME | Internal representation of the Target Type |
| CRIT_EVALS | Number of Critical-level Evaluations |
| WARN_EVALS | Number of Warning-level Evaluations |
| COMPLIANT_EVALS | Number of Compliant Evaluations |
| CRIT_VIOLATIONS | Number of Critical-level Violations |
| WARN_VIOLATIONS | Number of Warning-level Violations |
| MWARN_VIOLATIONS | Number of Minor Warning-level Violations |
| COMPLIANCE_SCORE | Current Compliance Score for the target |
View: mgmt$compliance_summary
Description: This view returns all evaluation and violation details for Compliance Standards and Frameworks. This is the same data that is shown in the Compliance Summary dashboard regions for Standards and Frameworks.
Fields:
| Field | Description |
|---|---|
| ELEMENT_NAME | Display name of the Compliance Standard or Compliance Framework |
| ELEMENT_ID | Internal ID of the compliance standard or compliance framework |
| FRAMEWORK_ID | Internal ID of the Compliance Framework |
| CRIT_EVALS | Number of Critical-level Evaluations |
| WARN_EVALS | Number of Warning-level Evaluations |
| COMPLIANT_EVALS | Number of Compliant Evaluations |
| CRIT_VIOLATIONS | Number of Critical-level Violations |
| WARN_VIOLATIONS | Number of Warning-level Violations |
| MWARN_VIOLATIONS | Number of Minor Warning-level Violations |
| COMPLIANCE_SCORE | Current compliance score for the standard or framework |
| NON_COMPLIANT_SCORE | Current non-compliant score for the standard or framework |
| ELEMENT_TYPE | Type of element (1=Compliance Standard, 4=Compliance Framework) |
| AUTHOR | Author of the standard or framework |
| VERSION | Version of the standard or framework |
| ELEMENT_INAME | Internal representation of the standard or framework |
View: mgmt$compliance_trend
Description: This view returns the last 31 days compliance trend information for compliance frameworks and standards. This is the same data that is shown in the Compliance Summary dashboard trend regions for Standards and Frameworks.
Fields:
| Field | Description |
|---|---|
| ELEMENT_ID | Internal ID representation of the standard or framework |
| FRAMEWORK_ID | Internal ID representation of the compliance framework |
| ELEMENT_NAME | Display name of the Compliance Standard or Compliance Framework |
| ELEMENT_INAME | Internal representation of the standard or framework |
| AVG_COMPLIANCE_SCORE | Average compliance score over last 31 days |
| DAILY_AVG_VIOLATIONS | Average number of violations per day over last 31 days |
| SNAPSHOT_TS | The snapshot timestamp |
| TOTAL_EVALS | Total evaluations over last 31 days |
| ELEMENT_TYPE | Type of element (1=Compliance Standard, 4=Compliance Framework) |
Real-time Monitoring features use partitioning and data retention configuration.
The following are the tables along with their default retention periods. When changing any retention periods, all tables related to Real-time monitoring must be changed to the same value to ensure that data is consistent across various features.
Note:
For more information about modifying data retention values, see the chapter "Maintaining and Troubleshooting the Management Repository" in the book Oracle Enterprise Manager Administration.| Table Name | Default Retention Period | Description |
|---|---|---|
| EM_CCC_WATCHDOG_ALERTS | 366 Days | This table stores warnings from the agents when we detect that monitoring was not active. |
| EM_CCC_HISTORY_JOBEXEC | 366 Days | This table stores history of all Enterprise Manager Jobs that are run as part of the Real-time Monitoring functionality. |
| EM_CCC_OBSERVATION | 366 Days | This table stores each individual observation of a user action (for example, each file change, login/logout, process start/stop, each database object change, and so on. |
| EM_CCC_OBSGROUP | 366 Days | This table stores information about how a single observation is related to a bundle based on the bundle settings set in the Real-time Monitoring Rule's user interface. |
| EM_CCC_OBS_GROUP_MAP | 366 Days | This table stores the relationship between each single observation bundle and the target, rule, and standard that was monitoring for that observed action. |
| EM_CCC_HISTORY_OBS_STATUS | 366 Days | This table stores the state change history for audit status (unaudited, unauthorized, authorized) for each observation. |
| EM_CCC_HA_OBS | 366 Days | This table stores analytic summaries of counts of observations by hour and other attributes for reporting. |
| EM_CCC_HA_OBSGROUP | 366 Days | This table stores analytic summaries of counts of observations bundles by hour and other attributes for reporting. |
| EM_CCC_FILEOBS_DIFF | 366 Days | This table stores past file comparison for OS File based observations. |
| EM_CCC_AUTHOBS_CR_MAP | 366 Days | This table stores the mapping between Change Management Request System change requests that were used to authorize an observation. |
| EM_CCC_CMPUBACTION | 366 | This table stores requests to publish data from EM server to an integrated Change Management Server using the connector. |
| EM_CCC_CMPUBACTION_DETAIL | 366 | This table stores additional details for requests to publish data from EM server to an integrated Change Management Server using the connector. |
The following tables display the various platforms that support Real-time monitoring. For all tables, an X indicates support for the listed action and NS indicates "Not Supported".
The following Operating System platform combinations are not supported at this time:
Microsoft Windows -- IA64
Any Linux -- IA64, PA-RISC, POWER
The following table displays the platforms that support OS User Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
| Actions to Monitor | Oracle/Redhat Linux | Windows | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1 and R2) | ||||||
| X86 32 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 Bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | |
|
Telnet Login (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
Telnet Logout (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
Telnet Login (failed) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSH Login (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSH Logout (Successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SSH Login (failed) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
Console Login (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Console Logout (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Console Login (failed) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTP Login (successful) |
NS |
NS |
NS |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
FTP Logout (successful) |
NS |
NS |
NS |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
FTP Login (failed) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SU Login (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SU Logout (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SU Login (failed) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO (successful) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO (failed) |
X |
X |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDP Login (Successful) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
RDP Logout (Successful) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
RDP Login (failed) |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
| Actions to Monitor | SUSE Linux | Solaris | AIX | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| V10 | V11 | V9 | V10 | V11 | V 5.3 | V 6.1 | |||||
| X86 32 bit | X86 32 bit | X86 64 bit | X86 64 bit | Sparc | X86 64 bit | Sparc | X86 64 | Sparc | POWER | POWER | |
|
Telnet Login (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Telnet Logout (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Telnet Login (failed) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSH Login (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSH Logout (Successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SSH Login (failed) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Console Login (successful) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
Console Logout (successful) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
Console Login (failed) |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
NS |
NS |
|
FTP Login (successful) |
X |
NS |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTP Logout (successful) |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
X |
X |
|
FTP Login (failed) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SU Login (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SU Logout (successful) |
NS |
X |
X |
NS |
NS |
NS |
NS |
X |
X |
NS |
NS |
|
SU Login (failed) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
SUDO (successful) |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
SUDO (failed) |
X |
X |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDP Login (Successful) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDP Logout (Successful) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
RDP Login (failed) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
The following table displays the platforms that support OS User Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-4 OS Process Monitoring
| Actions to Monitor | Oracle/Redhat Linux | Windows | Solaris | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1 and R2) | V9 | V10 | V11 | |||||||||
| X86 32 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 Bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 64 bit | Sparc | X86 64 bit | Sparc | X86-64 bit | Sparc | |
|
Process Start (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
Process Stop (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
For Linux v5, there are two possible ways monitoring can occur. Some actions to monitor below will work only on one or the other method. The two methods are to use the Loadable Kernel Module. Actions that are detectable ONLY with this method are annotated with ”(KO)”. The other option is to not use the loadable kernel module, which will result in using the Linux built-in audited method. The actions that can only be monitored using this method are annotated with ”(non-KO)”. The actions that have no annotation other than the check mark can be monitored using either approach.
Note:
Monitoring remote file systems on Unix-based platforms is not supported. Likewise, monitoring remote file systems on Windows platforms is also not supported.When restoring a file from the Recycle Bin on the Microsoft Windows operating system, capturing the user that made the change is not available since that feature is not available from the Operating System.
When using the audited monitoring method on Linux operating systems, not the Oracle kernel audit module method, directory creations are reported as file creation. Additionally, file create activity will be reported as a file modification instead of create. These are limitations of using the audited method of monitoring. If you use the Oracle kernel audit module approach for OS file monitoring on Linux, these limitations will not exist.
An X indicates support for the listed action and NS indicates "Not Supported".
| Actions to Monitor | Linux | Windows | Solaris | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V4 | V5 | V6 | XP | 2003 Server | 2008 Server (R1 and R2) | V9 | V10 | V11 | |||||||||
| X86 32 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 Bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 64 bit | Sparc | X86 64 bit | Sparc | X86 64 bit | Sparc | |
|
File Read (successful) |
X |
X (KO) |
X (KO) |
X (KO) |
X (KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Delete (Successful) |
X |
X |
X |
X (KO) |
X (KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Rename (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Create (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Content Modified (successful) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Modified without content change |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Modified (failed) |
NS |
X (Non-KO) |
NS |
X (Non-KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
|
File Permission Change (successful) |
NS |
X (non-KO) |
X (non-KO) |
X (KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Ownership Change (successful) |
NS |
X (non-KO) |
X (non-KO) |
X (KO) |
X |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File content modified (successful) Archive File |
NS |
X (non-KO) |
X (non-KO) |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
File Read (failed) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Delete (failed) |
NS |
X (Non-KO) |
X (Non-KO) |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Rename (failed) |
NS |
X (Non-KO) |
X (Non-KO) |
X (non-KO) |
X (non-KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Create (failed) |
NS |
X (non-KO) |
X (non-KO) |
X (non-KO) |
X (non-KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Permission Change (Failed |
NS |
X (Non-KO) |
X (Non-KO) |
NS |
X (non-KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
|
File Ownership Change (failed) |
NS |
X (Non-KO) |
X (Non-KO) |
NS |
X (non-KO) |
NS |
NS |
NS |
NS |
NS |
NS |
X |
X |
X |
X |
X |
X |
Table 47-7 OS File Monitoring (continued)
| Actions to Monitor | SUSE Linux | AIX | |||
|---|---|---|---|---|---|
| V10 | V11 | V5.3 | V6.1 | ||
| X86 32 bit | X86 32 bit | X86 64 bit | POWER | POWER | |
|
File Read (successful) |
X |
X (KO) |
X (KO) |
X |
X |
|
File Delete (Successful) |
X |
X (KO) |
X (KO) |
X |
X |
|
File Rename (successful) |
X |
X |
X |
X |
X |
|
File Create (successful) |
X |
X |
X |
X |
X |
|
File Content Modified (successful) |
X |
X |
X |
X |
X |
|
File Modified without content change (successful) |
X |
X |
X |
X |
X |
|
File Modified (failed) |
NS |
NS |
NS |
X |
X |
|
File Permission Change (successful) |
X |
X (KO) |
X |
X |
X |
|
File Ownership Change (successful) |
X |
X (KO) |
X |
X |
X |
|
File content modified (successful) Archive File |
X |
X |
X |
X |
X |
|
File Read (failed) |
NS |
NS |
NS |
X |
X |
|
File Delete (failed) |
NS |
NS |
NS |
X |
X |
|
File Rename (failed) |
NS |
X (Non-KO) |
X (Non-KO) |
X |
X |
|
File Create (failed) |
NS |
NS |
X (Non-KO) |
X |
X |
|
File Permission Change (Failed |
NS |
X (Non-KO) |
X (Non-KO) |
X |
X |
|
File Ownership Change (failed) |
NS |
X (Non-KO) |
X (Non-KO) |
X |
X |
The following table displays the platforms that support OS Windows Registry Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-8 OS Windows Registry Monitoring
| Actions to Monitor | Windows | |||||
|---|---|---|---|---|---|---|
| XP | 2003 Server | 2008 Server (R1 and R2) | ||||
| X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | X86 32 bit | X86 64 bit | |
|
Create Key (successful) |
X |
NS |
X |
X |
X |
X |
|
Delete Key (successful) |
X |
NS |
X |
X |
X |
X |
|
Create Value (successful) |
X |
NS |
X |
X |
X |
X |
|
Modify Value (successful) |
X |
NS |
X |
X |
X |
X |
|
Delete Value (successful) |
X |
NS |
X |
X |
X |
X |
|
Create Key (failed) |
X |
NS |
X |
NS |
NS |
NS |
|
Create Value (failed) |
X |
NS |
X |
NS |
NS |
NS |
|
Modify Value (failed) |
X |
NS |
X |
NS |
NS |
NS |
|
Delete value (failed) |
X |
NS |
X |
X |
X |
X |
The following table displays the platforms that support OS Windows Active Directory User Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support OS Windows Active Directory Computer Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support OS Windows Active Directory Group Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-11 OS Windows Active Directory Group Monitoring
| Actions to Monitor | Windows | |||
|---|---|---|---|---|
| 2003 Server | 2008 Server (R1 and R2) | |||
| X86 32 bit | X86 64 Bit | X86 32 bit | X86 64 bit | |
|
Group Create (successful) |
X |
X |
X |
X |
|
Group Delete (successful) |
X |
X |
X |
X |
|
Group Attribute Modify (successful) |
X |
X |
X |
X |
|
Group Member Add (successful) |
X |
X |
X |
X |
|
Group Member Delete (successful) |
X |
X |
X |
X |
The following table displays the platforms that support Oracle Database Table Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-12 Oracle Database Table Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Insert (successful) |
X |
X |
X |
X |
|
Select (successful) |
X |
X |
X |
X |
|
Update (successful) |
X |
X |
X |
X |
|
Delete (successful) |
X |
X |
X |
X |
|
Create (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Truncate (successful) |
X |
X |
X |
X |
|
Alter (successful) |
X |
X |
X |
X |
|
Comment (successful) |
X |
X |
X |
X |
|
Rename (successful) |
X |
X |
X |
X |
|
Lock (successful) |
X |
X |
X |
X |
|
Grant (successful) |
X |
X |
X |
X |
|
Revoke (successful) |
X |
X |
X |
X |
|
Audit (successful) |
X |
X |
X |
X |
|
NOAUDIT usage |
X |
X |
X |
X |
|
Flashback (successful) |
X |
X |
X |
|
The following table displays the platforms that support Oracle Database View Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-13 Oracle Database View Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Insert (successful) |
X |
X |
X |
X |
|
Select (successful) |
X |
X |
X |
X |
|
Update (successful) |
X |
X |
X |
X |
|
Delete (successful) |
X |
X |
X |
X |
|
Create (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Comment (successful) |
X |
X |
X |
X |
|
Rename (successful) |
X |
X |
X |
X |
|
Lock (successful) |
X |
X |
X |
X |
|
Grant (successful) |
X |
X |
X |
X |
|
Revoke (successful) |
X |
X |
X |
X |
|
Audit (successful) |
X |
X |
X |
X |
|
NOAUDIT usage |
X |
X |
X |
X |
|
Flashback (successful) |
X |
X |
X |
|
The following table displays the platforms that support Oracle Database Materialized View Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-14 Oracle Database Materialized View Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Insert (successful) |
X |
X |
X |
X |
|
Select (successful) |
X |
X |
X |
X |
|
Update (successful) |
X |
X |
X |
X |
|
Delete (successful) |
X |
X |
X |
X |
|
Create (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Alter (successful) |
X |
X |
X |
X |
|
Comment (successful) |
X |
X |
X |
X |
|
Lock (successful) |
X |
X |
X |
X |
|
Grant (successful) |
X |
X |
X |
X |
|
Revoke (successful) |
X |
X |
X |
X |
|
Audit (successful) |
X |
X |
X |
X |
|
NOAUDIT usage |
X |
X |
X |
X |
The following table displays the platforms that support Oracle Database Index Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Sequence Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-16 Oracle Database Sequence Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Create (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Alter (successful) |
X |
X |
X |
X |
|
Select (successful) |
X |
X |
X |
X |
|
Grant (successful) |
X |
X |
X |
X |
|
Revoke (successful) |
X |
X |
X |
X |
|
Audit (successful) |
X |
X |
X |
X |
|
NOAUDIT usage |
X |
X |
X |
X |
The following table displays the platforms that support Oracle Database Procedure Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Function Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Package Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Library Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Trigger Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Tablespace Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Cluster Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Link Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Dimension Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Profile Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Public Link Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Public Synonym Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Synonym Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database Type Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-30 Oracle Database Type Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Create (successful) |
X |
X |
X |
X |
|
Create Type Body (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Alter (successful) |
X |
X |
X |
X |
|
Drop Type Body (successful) |
X |
X |
X |
X |
|
Grant (successful) |
X |
X |
X |
X |
|
Revoke (successful) |
X |
X |
X |
X |
|
Audit (successful) |
X |
X |
X |
X |
|
NOAUDIT usage |
X |
X |
X |
X |
The following table displays the platforms that support Oracle Database Role Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
The following table displays the platforms that support Oracle Database User Monitoring. An X indicates support for the listed action and NS indicates "Not Supported".
Table 47-32 Oracle Database User Monitoring
| Actions to Monitor | Oracle Database | |||
|---|---|---|---|---|
| 9i | 10g | 11g | 12g | |
|
Create (successful) |
X |
X |
X |
X |
|
Logon (successful) |
X |
X |
X |
X |
|
Drop (successful) |
X |
X |
X |
X |
|
Alter (successful) |
X |
X |
X |
X |
|
Logoff |
X |
X |
X |
X |
|
Grant Role (successful) |
X |
X |
X |
X |
|
Revoke Role (successful) |
X |
X |
X |
X |
|
System Grant (successful) |
X |
X |
X |
X |
|
System Revoke (successful) |
X |
X |
X |
X |