5 Operations Management

Operations Management relates to the configuration aspects of the Configuration Change Console that relate to your physical infrastructure and how it should be monitored. This is opposed to Policy Management as discussed in Chapter 6, "Policy Management", which relates to your Compliance Policy frameworks, policies and controls. Configuration Change Console enables you to monitor and audit essential application components, detecting and reporting changes to application infrastructure through assigned application policies.Operations Management configuration consists of the following elements:

Note:

If you are integrating with a change management system to detect authorized and unauthorized events, you must perform additional configuration steps, described in Chapter 7, "Integrating With A Change Management Server".

Before defining components, you will need to decide:

When defining components, remember the following:

Steps for Modeling a Business Application

The following table provides a high-level view of the basic steps required to model the components and create applications in the product to resemble a business application that may be running in your IT environment. Detailed procedures are provided later in this chapter.

Table 5-1 Steps for Modeling a Business Application

Step Task Description

1

Create one or more components.

Create your own component or copy one of the predefined components that comes with the product for each part of your business application; for example: the database instance, application server, firewall, messaging bus, critical OS files, database tables containing sensitive data, application server security files are all examples of a component.

2

Choose the rule sets and specify the rules for each component.

You can monitor rule sets such as files, processes, users, and/or internal objects such as database tables. Note that certain rule sets require additional configuration parameters. For each rule set, you specify a number of include/exclude rules that control what is monitored as part of this component.

3

Map the component to managed devices to create component instances.

This step essentially applies the monitoring rules to specific installations of a related component, telling an installed agent what elements to monitor for changes.

4

Create an application to simplify management and reporting.

Logically group component instances by function. The application in this sense would be related to your business application, such as The Finance Application.

5

Define audit actions for component instances or the entire application.

If you are integrating with a change management system, these audit actions are created automatically once you configure the component and outbound ticket template. If you want to specify additional actions such as notifications, you can create additional audit actions or modify the ones that were automatically created.

Understanding Components

The first step in configuring the product to map to your IT organization is to understand the components that make up your applications and model those components. The component serves as a blueprint of the important elements involved in an application used within your environment. These components, once applied to running installations on managed devices, determine what monitoring will be performed by the agents.

Components identify operating system and application rule sets to monitor, such as:

  • Files

  • Processes

  • OS Users

  • Application-specific internal objects

    • Database Objects

    • Active Directory/LDAP objects

    • Other application objects

The Configuration Change Console provides a set of predefined components that include monitoring rules for various operating systems and applications (See Appendix A, "Predefined Component Templates" for a list.) You can use these predefined components as starting points, customizing them to suit your monitoring, compliance, or auditing needs.

You can create a single component and assign it to many instances in your environment. You do not need to specify your rules in multiple components. For instances where there are minor differences in rules, you can override the global settings for the component for a specific instance. You can configure as many components as necessary to model your applications in any of the following ways:

  • Use a Predefined Component to create a Custom Component

  • Add a Custom Component using the Component screen

  • Import a Component created on another server or by creating the XML file manually

Step 1: Creating Components

Use the Components screen to create custom components for the applications you want to monitor.

To get to this screen, navigate to Policy --> Operations Management --> Components.

Several views are available from the Components screen:

  1. Predefined Components - Displays components included with the product. All Predefined Components specify monitoring rules based on the input of industry-leading application specialists. Use them as a basis for custom components that meet your specific audit requirements. You cannot directly assign a predefined component to a device, you must save a predefined component as a custom component before using it.

  2. Device View - Displays a list of devices showing the number of component instances associated with each device. Click the instance number link to see which components are assigned to the device.

  3. Custom Components - Lists user-defined components. Components that were created by copying a predefined component are also shown here as they are also custom components.

Note:

Only Custom components can be assigned to a managed device.

The Component screen provides a centralized entry point that enables access to key configurations. From the Component screen you can:

  • View the predefined components by selecting Predefined Components from the View menu.

  • View custom components by selecting Custom Components from the View menu.

  • View all components you have assigned to a device from the Device View.

  • Make a copy of a predefined component by clicking the component name link when in the predefined components view and saving it as a Custom Component. You can then customize the component to reflect any unique requirements of your environment.

  • Edit the information for an existing component by clicking on the link in the Component Name column to display the Add or Update Component screen.

  • Add custom components by clicking the Add Custom Component button to display the Add or Update Component screen.

  • Define Rule Sets, which identify what types of data you will monitor as part of the component. Click the count link in the Rule Sets column to access the Add or Update Component Rule Sets screen.

  • Create or modify Component Instances by assigning a Component to one or more specific devices. Click the count link in the Instances column to access the Component Instances screen.

  • Define or modify Audit Actions to associate actions to take when an event occurs that is related to the component. Click the count link in the Audit Actions column to access this screen.

  • Assign Controls to a Component. Controls are part of the Compliance Policy area of the product.

Add or Update a Component

The Add or Update Component screen appears when you choose to add or edit a template.

To get to this screen, navigate to Policy --> Operations Management --> Components: Add Custom Component.

  1. Enter the following information:

    • Component Type. The type of component. (For new custom components only.) Select from all currently configured Component Types. Application Types can be created through the Add Application Type link on the Component listing screen that lists components.

    • Component OS. The platform on which the application is running. (For new custom templates only.) Once you create a component, you cannot change the OS because rules are dependent on the OS you chose when creating the component.

    • Name. A unique name that describes the component.

    • Version. The version of the component.

    • Description. An optional, brief description that explains the function of the component.

  2. Click Save As if you are modifying a predefined component to save it with a new name, or Save if you are creating a new component or modifying an existing custom component. You can also use the Save As capability to make a copy of an existing custom component into another custom component.

Importing Components

An alternative to creating a brand new component is to import a component used on another server. For example, you can create and test your components in a development environment, and then export the components using the Export button on the Components screen. You could then import the component by clicking on the Import button on the Components screen in the production environment. Any components configured on a server may be exported by selecting the check box in front of the components name and clicking the Export Selected button. Note that you can export all, or selected components through this method.

To import an Component:

  1. From the Components screen, click the Import button. A pop-up dialog box appears prompting you to choose a file to import.

  2. Browse to the location where the component XML is saved and click Submit.

  3. A dialog box will indicate whether the file is a valid component for importing. Click Continue Import to finish importing the component.

Creating Custom Component Types

Custom Component Types can be created for use in Components through the Component Types screen. Creation of custom Component Types allows an organization to logically group the components used in their environment under classifications used in their organization.

To get to this screen, navigate to Policy --> Operations Management --> Components --> Add Component Type link.

The Component Types screen displays all currently configured Custom Components Types, including the description, creation date and time, and number of components currently using each custom type.

Table 5-2 Tasks on the Component Types Screen

Task Action

View a filtered version of the Components screen, which shows only the Components currently associated with the Component Type.

Click the # of Components count link.

Modify the configured Component Type.

Click the Component Type's Name link.

Add a new Component Type.

Click the Add Component Type button to name a new type and provide a description.

When finished, click Save. The Component Type will now be selectable when filtering or creating Custom Components.

You can delete custom component types that you create, but not while there is a component using the component type. To delete a component type, you must first edit existing components and assign them to different component types first. Also, you cannot delete the Default component type that comes with the product. For component types that you cannot delete the delete option will not be available.

Step 2: Defining Component Rules

Once you have created a component, you need to choose Rule Sets to monitor and define the rules. Each component has a set of rules relating to the rule sets (processes, files, users, and internal objects) related to a component making up your business application. You can include or exclude up to 50 rule patterns per component Rule Set. To deal with larger number of rules per rule set, break your component up into smaller components. If your component is too large, it makes the reporting of events less meaningful.

Add the monitoring rules via the Component screen. To get to this screen, navigate to Policy --> Operations Management --> Components.

For a component:

  • Select the link in the Rule Sets column to choose the Rule Sets and configure the rules for each set.

  • Select the link in the Instances column to assign a Components to a device to create a running Component Instance.

  • Select the Audit Actions link to configure and enable actions to perform when events tied to this component happen; such as notifications, sending SNMP traps, and so on.

The details for each type of rule set are described in the following sections.

General Monitoring Guidelines: Rule Sets

The following headings describe the various rule sets.

  • Files -- Typically, organizations do not monitor files or directories that change during normal operation of the application (such as transaction logs), to prevent collecting unnecessary data. For compliance purposes, only monitor files that have a significant impact on the application's function or performance, such as configuration files or tables that define the operation of an application. Through monitoring file rule sets, you will monitor file changes in real time and be able to capture who made the change and some other attributes of the event. Changes to permissions are also monitored.

  • Processes -- Configuration Change Console agents collect information about when monitored processes start and stop. Select processes that represent compliance control points, or for which a change in state (a process start or stop) represents exceptional activity in the environment. For instance, when the main process that is needed for your finance application stops, this would be an event you would want to know about.

  • Users -- Configuration Change Console agents collect information about when OS users log on and off a machine, through both local, regular system log ons and external log ons such as telnet or ftp access. For this aspect of compliance, you should select users and/or connection methods associated solely with the application being monitored, thus providing a record of user sessions (starts and stops) for the application.

  • Include/Exclude Rules -- Nothing is monitored unless it is first included in monitoring. You can start with a general include (include=*) and then start excluding elements you do not want to monitor, or you can make your inclusion rules more selective.

    The most specific include/exclude rule always takes precedence over a less specific include/exclude.

    If you define two conflicting rules for the same object or the same specific pattern, the include rule takes precedence and will collect the data in this situation.

    The following monitoring rules apply when creating include/exclude rules:

    • Patterns that do not include a wildcard (*) are more specific than patterns with a wildcard for the same entity type. For instance, /program/files/a.txt is more specific than /program/files/a.*

    • Longer (string length) patterns are more specific than shorter patterns for patterns of the same type. For example /program/files/user is more specific than /program/files

    • Pattern types for the database monitor follow a hierarchy of object types such as:

      • tables, views, procedures

      • columns, constraints, indexes

      • attributes

    • Event and resource pattern types are more specific than the both pattern type when the pattern lengths are the same.

For additional details, refer to Appendix C, "Component Internal Rule Set Capability Details".

Selecting Component Rule Sets

The first step in configuring your component rules is specifying what types of data can be monitored for the component. For example, for one application component you may be interested in monitoring changes made to files, while in another you may be interested in process starts and stops as well as changes made within a database.

To add individual rule sets to your components:

  1. Select the Rule Set from the drop-down menu in the Add or Update Component Rule Sets screen. See Add or Update a Component.

  2. Monitoring rules can then be added to the rule set by clicking the Edit Rules link in the rule set heading. If you have integrated the Configuration Change Console server with one or more LDAP or Active Directory servers, you can specify your user include/exclude rules based on these LDAP users or groups instead of entering them manually on this screen. If you include a group in a rule, and if that group in LDAP/AD server changes, that change will automatically be reflected in the component and the agent will be instructed to modify its monitoring requirements.

  3. Monitoring Component Internal Rule Sets.

Some Rule Sets involve a specific type of monitoring, shown in parentheses following the rule set name, for example: Active Directory (Snapshot). These modules often require extra configuration before monitoring can be performed. Such rule sets, once added, will feature an additional Configure link in the rule set header.

There are two classifications of rule sets that can be added to a component; External Rule Sets are rule sets that deal with artifacts outside of an application or at the OS level such as files, processes and OS users. Internal Rule Sets are rule sets that deal with object monitoring inside of an application, such as a table in a database or an object in an Active Directory server.

Only one Internal Rule Set can be added to a component. This is to maintain components that are simple to manage and understand. Making components too detailed renders it harder to track your events back to your compliance frameworks.

There are several classes of internal rule sets available:

  • Snapshot. Used for databases and Microsoft Active Directory. This rule set provides two monitoring functions: snapshot and inventory. The Snapshot portion stores an image of the selected application or database content at regular intervals. As each new snapshot is grabbed it is compared with the previously stored snapshot. A change event is generated if differences are found between the two images. The snapshot rule set provides a lightweight monitoring mechanism for tracking updates, additions, or deletions made to the data associated with the application or database. Note that the Snapshot rule set detects differences only; it will not tell you exactly what item triggered the change event, or the user responsible. Using the Database Inventory screen, you can see when a snapshot had a change since a previous snapshot and you can choose to "diff" two snapshots to identify specific changes.

    In a similar manner, the SQL Inventory portion of the Snapshot runs user defined SQL queries on the monitored database at regular intervals and stores the results of each for later review through the Change Visualization/Database Inventory screen. Note that this rule set does not report information pertaining to the user responsible for detected change events.

  • SQL Audit. Used for supported databases. The SQL audit rule set reports audit trails generated by the built-in auditing functionality of the monitored database. The difference between SQL audit and SQL trace is that the audit module reports events in object type (for example, table, view, process), object name (sales, employee), and operation (select, create, insert), whereas SQL trace simply reports on SQL statements.

  • SQL Trace. Used for supported databases. The SQL Trace rule set logs all SQL statements executed by users of the database, often by utilizing the built-in auditing functionality of the monitored database. The rule set can be configured through a component to capture a specific user's activity, the activity of an application that interacts with the database, and/or search for and capture segments of SQL statements that may be used to alter important data within the database. The rule set generates a detailed forensic data trail that can be used by an administrator to track exactly what query or statement caused a specific change event, the time of its execution, and the user responsible. Note that due to the broad scope of data collected, and the fact this rule set may require the use of a database's internal auditing functionality, use of this rule set may result in reduced database performance.

  • Trace. Used for Active Directory and the Windows Registry. The Trace rule set leverages operating-system specific mechanisms to audit internal events of an associated application. For example, the Windows Registry (Trace) rule set can be used to report all changes made to specified registry keys and values associated with a specific application.

Adding Component Rule Sets

You can add Modules using the Add or Update Component Rule Sets screen.

To get to this screen, navigate to Policy --> Operations Management --> Components: Rule Sets count link.

For each Component:

  • Select the Rule Set from the Add drop-down menu. Click Go to add the rule set to the Component.

    1. File Event

    2. Process Event

    3. User Event

    4. Active Directory (Snapshot)

    5. Active Directory (Trace)

    6. Oracle 8i (Snapshot)

    7. Oracle 8i/9i/10g (SQL Trace)

    8. Oracle 9i/10g (Snapshot)

    9. SQL Server (Snapshot)

    10. SQL Server 2000 (SQL Audit)

    11. SQL Server 2000 (SQL Trace)

    12. Windows Registry (Trace)

    The first three are External Rule Sets and exist at the Operating System level, outside of another system being monitored. The remaining rule sets are Internal Rule Sets and exist to internally monitor other systems.

  • If the selected rule set requires additional setup, a Configure link will display in the rule set header. Click the Configure link to be forwarded to the Update Internal Configuration screen for the rule set. Connection parameters for supported rule sets can be found in Appendix C, "Component Internal Rule Set Capability Details".

  • Click the Edit Rules link to specify the monitoring rules for the application component. You will be forwarded to the appropriate screen for the component type. The individual rule set rule screens are documented in the next section.

Once all rule sets have been configured for the given component, click Done to return to the component listing screen.

Monitoring Files

Configure a Component to monitor specific files or directories.

To get to this screen, navigate to Policy --> Operations Management --> Components.

To monitor files, follow these steps:

  1. In the Components screen, click a component's Rule Sets count link to display the Add or Update Component Rule Sets screen.

  2. From the drop-down Add list, select File Event and click Go.

  3. Click the Edit Rules link for the File Event rule set.

Note:

The Add or Update Component Files screen will initially contain only one field for entering a rule pattern. To add more rules, click the Add Instance link.

When you configure a file for a monitoring policy, you can set the path as relative to a user-specified base path (to save typing when the same base path is used over and over again), or you can specify the absolute path. Using a relative path, when you assign a component to multiple devices, you can add to, or modify, the relative path so that it correlates with the actual directory path used on the device rather than having different components for each device.

You can direct Configuration Change Console to archive a monitored file when it is changed by checking the Archive box for the file. For example, you might archive an essential database configuration file. If detected changes to the file introduce problems, you can restore the previous version of the configuration file. You can also use the console to diff two versions of the file and see exactly what changed. When you send a new configuration to the agent using Update Agents, the agent will take an initial archive copy of the file before any changes occur and then will save another copy each time a change happens.

By default, Configuration Change Console stores up to five versions of a file for each device. You can change this number by navigating to Administration --> Server Configuration --> Archived Files Configuration.

You cannot specify a directory to archive. If the agent cannot find a specific file with the pattern you specified, the archive action will simply be ignored.

Archiving will consume disk space in the directory the agent is stored in, so use this feature carefully.

Enter the following information:

  • Is Relative Path. Select whether you wish to use a specified Default Path for the paths specified as relative. The default path is entered in a field lower on this form.

  • Include/Exclude. Select the appropriate radio button to either monitor the file or exclude the file from being monitored.

  • Files. Enter the file name. A single wildcard (*) is supported anywhere after the final slash. See Appendix C, "Component Internal Rule Set Capability Details" for wildcard support details.

  • Effective File/Directory Path. This field is automatically generated by the system, and is used to display the full directory path including the relative path, if it has been specified in the Default Path field.

  • Description. (optional) Enter a brief note describing the purpose of the rule.

  • Archive. (optional) Select to store a variation of the monitored file when changes occur. The five most recent versions of the file will be stored on the computer where the agent monitoring the file is installed. Archived files can be reviewed on the Archived Files screen, and compared using a file diff method. There is an administrative screen to change the number of archived copies to store for files.

  • Default Path. If you have checked the Is Relative Path box for any of the rules, enter a default absolute path. When you create an instance of a component, you can choose to change this default path at an instance level.

  • User Filtering. Check this box to filter all detected changes by the user rules configured in the same component. For example, if you only wanted to capture file changes for the file rules you specified for the Administrator user, you would add the OS User Rule set to the component with a rule for including the Administrator user. The OS User Rule Set screen has an option to specify that the user rules are used to filter other event types. Then you also check this User Filtering checkbox on the File Rule Set screen to complete the filtering. Only file change events associated with the Administrator user will be captured.

Click Save to save the changes or Cancel to exit the screen without making any changes.

Monitoring Processes

Configure the processes that are meaningful to a component to be monitored as part of the component.

To get to this screen, navigate to Policy --> Operations Management --> Components.

To monitor processes, follow these steps:

  1. In the Components screen, click a component's Rule Sets count link to display the Add or Update Component Rule Sets screen.

  2. From the drop-down Add list, select Process Event and click Go.

  3. Click the Edit Rules link for the Process Event rule set.

Note:

The Add or Update Component Processes screen will initially contain only one field for entering a process pattern. To add more rules, click the Add Instance link.

Enter the following information:

  • Include/Exclude. Select the appropriate radio button to either monitor the process or exclude the process from being monitored. You can create rules such that you include * and then exclude specific processes from being monitored; or you can exclude all processes by excluding * and then including specific processes.

  • Pattern. The process name you want for this rule.

  • Pattern Type. Select whether you want to collect events (starts/stops), resource (CPU) utilization information associated with the specified process, or both. If you want to collect resource usage for processes, you must also ensure that you have configured your Agent schedule templates to include Performance Data. By default, the default schedule group only monitors change event data. See the sections related to Agent Schedule Groups and Agent Schedule Templates for more information.

  • Description. Enter an optional, brief note describing the purpose of the process.

  • User Filtering. Check this box to filter all detected changes by the user rules configured in the same component. For example, if you only wanted to capture process changes (starts and stops) for the process rules you specified for the Administrator user, you would add the OS User Rule set to the component with a rule for including the Administrator user. The OS User Rule Set screen has an option to specify that the user rules are used to filter other event types. Then you also check this User Filtering checkbox on the Process Rule Set screen to complete the filtering. Only process change events associated with the Administrator user will be captured.

Click Save to save the changes or Cancel to exit the screen without making any changes.

Monitoring Operating System Users

Configure a component to monitor specific operating system user login or logout events.

To get to this screen, navigate to Policy --> Operations Management --> Components.

To monitor users, follow these steps:

  1. In the Components screen, click a component's Rule Sets count link to display the Add or Update Component Rule Sets screen.

  2. From the drop-down Add list, select OS User Event and click Go.

  3. Click the Edit Rules link for the OS User Event Rule Set.

Note:

The Add or Update Component OS Users screen will initially contain only one field for entering a user pattern. To add more rules, click the Add Instance link.

Enter the following information:

  • Include/Exclude. Select the appropriate radio button to either monitor the user or connection type or exclude it from being monitored. You can use wildcards to include all users then exclude specific users or vice-versa to exclude all users then include specific users.

  • Pattern. Enter the user name or connection method (for example, ftp, telnet, rdp). A single wildcard (*) is supported in this field. See Appendix C, "Component Internal Rule Set Capability Details" for wildcard support details. Note that, by default, no users are included in monitoring.

  • Pattern Type. Select the appropriate type for the element specified in the Pattern field. Available options include user, for user names, and connect type, for connection methods.

  • Description. Enter an optional, brief note describing the user and why its important to the component.

  • User Filtering. Check this box if this list of users is used to filter events from other rule sets in the component. See the relevant documentation for other rule set types to see how this filtering is used for these rule sets.

Click Save to save the changes or Cancel to exit the screen without making any changes.

If you have integrated the Configuration Change Console server with one or more LDAP or Active Directory servers, you can specify your user include/exclude rules based on these LDAP users or groups instead of entering them manually on this screen. If you include a group in a rule, if that group in LDAP/AD server changes, that change will automatically be reflected in the component and the agent will be instructed to modify its monitoring requirements.

Monitoring Component Internal Rule Sets

Internal rule sets are those rule sets that are added to a component that define internal aspects of an application that should be monitored. Examples of internal rule sets are database table monitoring, Active Directory object monitoring, Windows Registry monitoring, and so on.

The following list covers some of the internal rule sets that are available to components. The available components depend on the release and OS version of the component you are defining:

  • Active Directory (Snapshot)

  • Active Directory (Trace)

  • Oracle 8i (Snapshot)

  • Oracle 8i/9i/10g (SQL Trace)

  • Oracle 9i/10g (Snapshot)

  • SQL Server (Snapshot)

  • SQL Server 2000 (SQL Audit)

  • SQL Server 2000 (SQL Trace)

  • Windows Registry (Trace)

Each internal rule set has one or more ways of performing its monitoring (Snapshot, SQL Audit, SQL Trace, Trace). As discussed earlier in this book, each has its advantages and disadvantages.

A component can have all three external rule sets (file, process, and OS user), but can only have one internal rule set at a time. This is mostly to ensure that component definitions remain specific enough for the reporting and auditing features of the product to be usable.

If the component rule set supports internal monitoring, use the Configure link for the appropriate Rule Sets on the Add or Update Component Rule Sets screen to enable it. Some rule sets require that you specify connection parameters, such as login credentials, in order to access the application being monitored. These parameters are unique to each application and must be configured to properly enable monitoring. For example, an Oracle database requires specific database user permissions and login credentials.

To get to this screen, navigate to Policy --> Operations Management --> Components.

To monitor internal component rule sets, follow these steps:

  1. In the Components screen, click an component's Rule Sets count link to display the Add or Update Component Rule Sets screen.

  2. From the drop-down Add list, select one of the internal rule sets and click Go.

  3. Click the Edit Rules link for the internal rule set.

    Note:

    The Add or Update Component Processes screen will initially contain only one field for entering a rule pattern. To add more rules, click the Add Instance link.

  4. Back in the Add or Update Component Rule Sets screen, click the Configure link in the component rule set header. You will be forwarded to the Update Internal Configuration screen for the component.

    Note:

    Only rule sets that support internal monitoring capabilities will feature the Configure link.

  5. Click the Is Enabled checkbox to enable or disable the rule set and provide any necessary connection parameters for the rule set.

The content of the Update Internal Configuration screen varies depending on the rule set selected for the component and what is being monitored. The screen shown above shows only one example. For a full list of all connection parameter settings required for each rule set see Appendix B, "Operating System Rule Set Capability Details".

Configure Internal Rule Sets

To configure internal rule sets, follow these steps:

  1. Access the Update Internal Configuration screen by navigating to Policy -> Operations Management -> Components -> Rule Sets count link -> Configure link

  2. Enter the following information, if needed by the selected rule set:

  3. Click the Is Enabled box to enable the rule set.

  4. Click Save to save changes or Undo Changes to reset the fields.

Note:

The enabled configuration will not go into effect until you update your agents through the Update Agents screen. The Update Agents screen is accessible through the Update Agents button in the upper right-hand corner of the user interface.

Override Rules and Configuration for Instances

When this screen is accessed through the Component Instance screen none of the fields will be editable. Click the Override button to make edits to the information for the specific Component Instance only. This will not change the base component that other instances are using itself. When overriding, you can change the rules as well as the configuration needed to connect to the other system being monitored.

Internal Rule Sets: Database Snapshot type Rule Sets

To access this screen, navigate to Policy --> Operations Management --> Components.

From the Add or Update Component Rule Sets screen, click the Edit Rules link of a rule set that is for database (snapshot) type monitoring. This link takes you to the Add or Update Component Rule Sets screen. Depending on the agent module selected, you may be presented with the individual SQL Query or Internal Monitoring screens or a hybrid version featuring the functionality of both in the same screen, as is the case with the Oracle Snapshot modules.

For rule set-specific details related to rule configuration, see Appendix B, "Operating System Rule Set Capability Details".

SQL Query Parameters

The SQL Query section of the rule screen lets a user enter a query that will run on a scheduled basis. When this query runs, it compares the output with the output from the previous run. If there is a change between the snapshots, that change is counted as a change event. Also, you can specify to record baseline query so that not only are the intermediate snapshots stored, but you can save a baseline on a regular basis. The Database Inventory screens let you see these baseline/snapshots and see differences between snapshots.

  • Name. The name of the query. This name is used in the reports to identify the query.

  • SQL Query. The fully qualified SQL query for your database. When specifying a SQL query, you must include the full database object name. For example, when entering a query to select all customer data from the HR database schema, you would enter: select * from HR.customer. The query that you enter should not have a semicolon at the end.

    Note:

    This screen does not check the validity of the schemas that you enter in a query. If the schema does not exist in your database structure, your monitoring results will be incomplete. There will be an error in the agent's logs that the table or query could not be executed.

  • Record Baseline. Check the box to record periodic baselines on the server side. The baseline interval is based on the local calendar of the device. The baseline interval is set under the Configure link for the rule set.

Baseline Recording

Baseline recording enables your snapshots to include periodic recording of baseline data on the server side. The baseline interval is driven by the monitored devices local time.

The following types of internal monitoring module rules support baseline recording:

  • Oracle 8i (Snapshot)

  • Oracle 9i/10g (Snapshot)

  • SQL Server (Snapshot)

From the Configure link of the rule set, there is an option for the rule sets listed above that let you choose the baseline. The baseline options are:

Table 5-3 Baseline Rule Options

Option Description

NONE

Do not record a baseline even if rules specify

HOUR

Record baseline every hour on the hour.

DAY

Record baseline every day at midnight of that day.

WEEK

Record baseline every day at midnight of the first day.

MONTH

Record baseline every month at midnight of the first day.

Include/Exclude Parameters

The Include/Exclude section of this rule screen lets a user choose which schema objects they want to monitor. The monitor performed since this is a snapshot type of rule set is to record the state of a schema and then compare it to the next run and treat the difference as a change event.

A snapshot module with this type of rule only monitors structural schema changes, not content changes.

  • Include/Exclude. Select the appropriate radio button to either monitor the object or exclude the object from being monitored.

  • Patterns. Enter the object pattern. The agent will match the full name of the object or attribute specified in the inclusion/exclusion policy. You may use an asterisk as a wildcard to match any strings of a similar format to the object name. Note that you should be careful when using fully qualified names of database objects, as the name must match exactly for monitoring to occur.

  • Pattern Type. Select the appropriate pattern type from the drop-down menu. The pattern types available depend on the application being monitored and the rule set used. The full list of module-specific pattern types can be viewed in the following section.

  • Description. Enter a brief note describing the purpose of the policy.

The fully qualified object name formats for supported databases include:

  • Oracle. <schema>.<tablespace-name>

  • SQL Server. <database name>.<owner>.<tablespace-name>

As noted above, the agent will run the configured queries at the default five minute interval unless otherwise configured in the component. Depending on the type of monitoring selected, the query may be used to simply collect data from the database, as with SQL Trace, or to monitor for changes made to the data stored in the database, as with the Snapshot modules. Keep in mind that Configuration Change Console has a built-in limit of 1000 rows when it comes to data returned by selection queries. Therefore, you will need to focus your queries so as to return only relevant data.

For example, if an overly broad query is used with a Snapshot-based agent module, and a change event occurs in a row beyond the 1000th row returned, the change will not be detected and thus not display in the report screens. Make sure to balance such queries with exception clauses so that only necessary data is returned and thereby ensuring accurate change detection. The limit of 1000 rows can be configured in the Rule Set Configure link from the Rule Sets screen for the component.

Internal Rule Sets: Specific Pattern Types

The available pattern types found on the Add or Update Component Rule Sets screen vary depending on the rule set you are working with.

For additional details, see:

The supported pattern types for rule sets include:

  • Active Directory (Snapshot) - Choose from changes to individual users (user), monitored computers (computer), user or device groups (group), or all of the above (all) configured on the Active Directory or LDAP server.

  • Active Directory (Trace) - Choose from computers (computer), groups (group), and users (user), as configured within Active Directory.

  • Oracle 8i (Snapshot) - See Appendix B, "Operating System Rule Set Capability Details"

  • Oracle 9i/10g (Snapshot) - See Appendix B, "Operating System Rule Set Capability Details"

  • Oracle 8i/9i/10g (SQL Trace) - Choose from changes to users (user), specific machines used to connect to the database (host), operating system user (osuser), terminal (terminal), event (event), or object name (objname) within the database

  • Windows Registry (Trace) - Choose from registry keys (key), registry values (value), or all registry information (all) to include in registry monitoring

  • SQL Server (Snapshot) - See Appendix B, "Operating System Rule Set Capability Details"

  • SQL Server 2000 (SQL Audit) - Choose from changes to users (user), specific machines used to connect to the database (host), specific applications connected to the database (appname), or specific databases (dbname), or object name (objname) within the database

  • SQL Server 2000 (SQLTrace) - Choose from individual users who execute SQL queries (user), specific machines used to connect to the database (host), specific applications connected to the database (appname), or a specific string to look for within an executed SQL query (sqltext). Note that the appname pattern type is case sensitive. Further note that wildcards are not supported by the sqltext pattern type

Patterns Types for Trace and Audit Rule Sets

The following table provides a quick reference for the pattern types supported for Trace and Audit modules:

Table 5-4 Pattern Types for Trace and Audit Rule Sets

Trace Modules Audit Modules

SQL Server 2000

  • sqltext

  • user

  • appname

  • host

SQL Server 2000

  • user

  • host

  • appname

  • objname

  • dbname

Oracle 8i/9i/10g

  • user

  • host

  • terminal

  • osuser

  • objname

  • event

N/A

Active Directory Monitoring

Active Directory rule sets track and report user additions, user permission changes and account deletions as well as device and group changes. The Configuration Change Console agent can be installed on the same device on which the Domain Controller is running for audit level monitoring where the user that makes a change can be captured, or it can monitor the Domain Controller remotely using the snapshot rule set which will detect changes, but not the user that made the change.

Active Directory monitoring reports the following change events for users, groups, and computers:

Table 5-5 Change Events for Users, Groups, and Computers

Event ID Event Description Entity Type Entity Name Event Type

624

A user account was created

user

entityname

added

627

A user password was changed

user attribute

entity.password

modified

628

A user password was set

user.attribute

entity.password

modified

630

A user account was deleted

user

entityname

deleted

631

A global group was created

group

entityname

added

632

A member was added to a global group

group.member

entityname.member-name

added

633

A member was removed from a global group

group.member

entityname.member-name

deleted

634

A global group was deleted

group

entityname

deleted

635

A local group was created

group

entityname

added

636

A member was added to a local group

group.member

entityname.member-name

added

637

A member was removed from a local group

group.member

entityname.member-name

deleted

638

A local group was deleted

group

entityname

deleted

639

A local group account was changed

group.attribute

entityname.-

modified

641

A global group account was changed

group.attribute

entityname.-

modified

642

A user account was changed

user.attribute

entityname.-

modified

645

A computer account was created

computer

entityname

added

646

A computer account was changed

computer

entityname

modified

647

A computer account was deleted

computer

entityname

deleted

*Entity Type = Pattern Type in the Module Rule definition

*Entity Name = Domain Name + "\\" + AccountName

For Active Directory Monitoring, you can include/exclude rules by following some basic guidelines:

  • Rules are based on users, groups, login names, and devices

  • All patterns are case-insensitive, meaning that AbC matches ABC

  • To target specific entities, use a combination of include and exclude rules

  • Do not apply include and exclude rules to the same pattern, except if you use include=* or exclude = *

If you want to exclude specific targets, use include=* and then add some specific exclude rules. Likewise, if you want to include only specific targets, use an exclude=* rule with some rules with explicit exclude patterns.

Step 3: Mapping Components to Managed Devices

After configuring components for your applications, you must specify the devices on which each component is running. A single component can be assigned to one or many devices.

Before mapping components to devices:

  • You must install a Configuration Change Console agent on the device you wish to monitor. Note that certain database rule sets allow remote database access, and therefore can use an agent installed on a device other than that where the database is installed.

  • The component must be configured with rule sets and rules. If your components have no monitoring rules defined, configure or edit their monitoring details from the Components screen by clicking on the count link for Rule Sets.

The Component Instances screen displays all devices to which the component is currently assigned.

To access this screen, navigate to Policy --> Operations Management --> Components: Instances count link.

The name of the device assigned to the component instance is displayed in the Device Name column. The Overridden column displays whether or not the global component rule set rules have been altered for the associated application instance. Clicking the Overridden Status link will forward you to a version of the Component Rule Set screen for this instance only where you can edit the rules and connection settings for the selected instance only. Not all of the rule sets allow modifications at the instance level.

To add or update a component's device assignment, click the Modify Device Assignments button. The Assign New Device screen will display.

The Assign New Device screen displays all currently configured device groups and all their member devices. You can assign a component to an entire device group by checking the box next to the device group name, or expand the device group tree to select individual devices. Once all devices have been selected, click Save to exit the screen. The device group structure is not maintained when choosing a group. If you add or remove a device from a group, it will not impact the component assignment.

Step 4: Assign Controls to a Component

If you have already configured the Policy Management portion of the product as discussed in the next chapter, you can assign Policy controls to your component.

To access this screen, navigate to Policy --> Operations Management Controls --> Control count link.

This screen enables you to change the controls that are assigned to this component. Control assignment is the way that component changes get reported up through the control/policy/framework reporting structure. For instance, to report changes on the top level dashboard, you need to assign components to a control and likewise have that control assigned to a policy.

The subtitle of the screen provides a context for the component. For example:

Component: Finance Application Server 1.0 WINNT

Click on the + to expand the Control Framework and Policy hierarchy to view the list of controls. After each policy name will be a number of selected controls in [ ] behind the policy name.

Clicking on the checkbox on the bottom most level of the hierarchy will select a control to assign to the selected component.

Select the controls to assign to the selected component by using one of these methods:

Clicking the check box for the control which is the deepest level represented in the hierarchy.

Clicking on the policy name (or framework name) to assign all controls under that policy (or control) to the component.

Click the Selection Helper link to select a group of templates based on pattern matching. Note that pattern matching is case sensitive.

After making a new assignment or unassigning a control, returning to the component listing screen will show an updated count of assigned controls to the component.

Step 5: Applications

Grouping component instances into applications allows you to model your real world business applications and make reporting line up with your business. Most large-scale enterprise applications rely on the interaction of multiple application components on multiple servers. For example, a web-based customer service application will likely include a web server, application server, and database, all running on different servers. You can create a component for each of these elements, define instances based on the servers where the applications run, and then create an Application that allows you to easily view change events that affect the application as a whole rather than only looking at the components.

A component instance can be part of multiple applications. This can prove useful for reporting and management purposes. For instance, a firewall may be a component that is used to protect your HR application servers and also your finance application servers at the same time. Any change to this firewall configuration settings may impact both applications at the same time.

To use applications you will need to first create your components, then create component instances by assigning them to devices.

Creating Applications

The Applications screen displays a list of existing applications, the number of component instances that are associated with each group, and the number of Audit Actions currently configured for each application.

Note:

The links under the # of Component Instances column in the Applications screen will display "0" until a Component Instance is added to the group.

To access this screen, navigate to Policy --> Operations Management --> Applications.

To add an application, click the Add Application button. To modify an existing application's information, click the link for the application name. Either action displays the Add or Update Application screen. Enter a name and optional description for the application. Click Save to save the changes. The group will then appear on the Applications screen.

Adding Component Instances to an Application

Once you have created an application, you can add one or many component instances to it.

To access this screen navigate to Policy --> Operations Management --> Applications.

Click the link in the # of Component Instances column for the desired application to display the Assign New Component Instances screen. Select one or more component instances from the available instance tree. Click Save to save the changes or Undo Changes to reset the fields.

Step 6: Defining Application Audit Actions

Audit Actions specify what actions should be taken when an event occurs. The types of events you can specify for an audit action are File, Process, OS User, and Component Internal (database, registry, active directory, for example) changes. These events can trigger email notifications, report generations, SNMP traps, and Change Management Reconciliation.

See Chapter 12, "
Administering Servers and Agents" for information on configuring SNMP notifications.

Change Management Integration: Detecting Authorized/Unauthorized Events

Configuration Change Console integrates with a Change Management server to monitor and categorize events as authorized or unauthorized. The Audit Action compares the change event against tickets and configured CTIs on the Change Management server. If the detected changes match an open ticket for the configured CTI, the change is determined to be authorized, and the corresponding ticket is updated in the Change Management server with the event details. If detected changes do not match any open tickets for the configured CTI, they are determined to be unauthorized. Once a change has been determined to be unauthorized, one of two things may happen, depending on the Change Management server configuration.

  1. A new ticket will be created for each unauthorized change if CT Consolidation is not enabled.

  2. If CT consolidation is enabled, all unauthorized events matching an existing unauthorized ticket's CTI will be appended to the unauthorized ticket. If no matching CTI is found, a new unauthorized ticket will be created using the Default Outbound Ticket information.

The Audit Action provides the final integration point with the Change Management application.

For the integration to work, you must have specified the connection parameters used for your Change Management Application, selected your default Outbound Ticket Configuration, and have assigned categories to individual component instances through the user interface. Refer to Chapter 7, "Integrating With A Change Management Server" for details on configuring this integration.

Defining Audit Policies

When you create a component when a Change Management system is integrated (Change Management integration fully configured through the Change Management Configuration screen), an audit action is generated automatically. Auto-generated actions appear in the Audit Actions screen with the string "AUTO ACTION" appended to the name. These audit actions are incomplete until you assign component instances or applications to them.

If you do not have a Change Management system integrated, you can create audit actions manually by going to the Audit Actions Policy screen.

To access this screen, navigate to Policy --> Operations Management --> Audit Actions.

To add a new Audit Action, click the Add New Audit Action button. To edit an existing action, click the Audit Action's name link. Either way, the Add or Modify Audit Action screen is displayed. Enter the following information:

  • Audit Action Name. Unique name assigned to the audit action. It is helpful to define a consistent naming convention for action names.

  • Description. Optional brief note explaining the function of the action.

  • Component Instances/Application. You must specify either a component Instance or an Application to audit. The defined audit action will only apply to events associated with the selected Component or Application. Select the Component Instance or Application from the available drop-down options. It is possible to have multiple audit actions per component instance or application depending on different needs; for instance you may want to get notifications for file changes, and get SNMP traps sent for process changes for the same component instance.

  • Events to Detect. Select from the following: file, process, OS user or component internal change events.

  • Notify. Select the person to notify for each event that occurs. The person specified must have a primary email address configured to receive notifications. No notification is sent if None is selected.

  • Priority. Priority level for notification escalations. Priority levels are as follows: P1, P2, P3, P4, or P5, with P1 having the highest priority.

  • SNMP Servers. If you have configured an SNMP server to receive traps from the Configuration Change Console server, select an SNMP server where the notification can be sent. You can select more than one SNMP server.

  • Report. Reports can be generated and sent as an attachment with the email notification

  • Ticket Actions. If the Authorized Change option is selected, the Change Management Server will be updated with the details of the authorized events if an authorized event occurs. If the Unauthorized Change option is selected, Configuration Change Console creates a ticket using the Default Outbound Ticket configuration for all unauthorized events detected by the agent. If CT Consolidation is enabled the unauthorized event will be first compared to CTIs of existing unauthorized tickets. If a matching CTI is found, the ticket will be appended with the change event information. If no matching CTI is found, a new unauthorized ticket will be created using the Default Outbound Ticket configuration.

  • Ticket Category. Specify the Default Outbound Ticket configuration to use for unauthorized change events.

Click Save to save your changes.

From the Audit Actions screen, complete the Audit Action by assigning a component instance or application to the policy, by clicking the appropriate count link and then selecting from the displayed instances. You cannot assign an audit action to both a component instance and an application at the same time.