Chat now with support
Chat with Support

InTrust 11.6 - Real-Time Monitoring Guide

Real-Time Monitoring Overview

The real-time monitoring service constantly listens for new events. This enables you to stay up to date on the state of critical objects in your network. This feature also provides automated response to events that occur in the network.

You activate a real-time monitoring policy that prescribes what monitoring rules must be applied to what InTrust sites. A monitoring rule specifies, in particular:

  • The audit trail (event log, Syslog and so on) to be monitored
    These are known to rules as data sources
  • Conditions against which event records must be evaluated
    These are the rule matching parameters
  • What to do when the rule is matched
    Whether to generate an alert, send a notification, or perform a response action

For example, the “InTrust: Tracking log monitoring” policy is intended for monitoring of critical events from all the InTrust servers in the organization, and prescribes to process them using the “InTrust Log Monitoring” rule group.

The agent tracks audit trails on the target computer, looking for new events. If an event matches the conditions specified by a monitoring rule, then (in accordance with the rule settings), the following takes place:

  • An alert is generated
  • A response action is performed
  • People in charge get notified of the occurrence and can take measures to resolve the issue

Alerts can be stored in the alert database, and authorized users can view and resolve them via Monitoring Console. In addition, you can configure reporting jobs to create reports on the alerts data.

Alerting and notification provide feedback on real-time monitoring. Each of these actions is initiated when specific events are detected.


Alerting is a service that generates alerts. An alert is a signal that InTrust has detected a condition described by a rule. Alerts can be stored in an InTrust alert database. You can view the stored alerts with InTrust Real-Time Monitoring Console.

To view an alert, an account must be a member of Security group for both the rule group containing the rule that triggers the alert and for the site that the rule monitors. This is because rules, through policies, are bound to sites.

  • To specify Security group members for a site, open the site’s properties dialog box and click the Security tab.
  • As for the rules, you must specify Security group members for the entire rule group. To do so, open the rule group’s properties dialog box and select the Security tab.

You must also configure the following:

  • Alert database
  • Settings for the corresponding rules

An alert database is created automatically during InTrust setup. This database is used by default for storing alert records.

To use another alert database

  1. In InTrust Manager, double-click Configuration | Data Stores.
  2. Right-click Databases and select New from the shortcut menu to create the new alert database with the New Database Wizard.
  3. Double-click Configuration | InTrust Servers.
  4. Right-click the InTrust server you need, and select Properties.
  5. Select the Alert Database tab.
  6. Click the button next to the name of the alert database to open the Select Storage dialog box.
  7. In the dialog box, select the database you need.

To access a rule’s alert-related settings, open the properties dialog box of the corresponding rule, and select the Alert tab. For details, see the Understanding Rules topic.


Notification means creating messages (for example, email messages) and sending these messages to specified recipients. Notification is activated when specified events are detected during real-time monitoring. In addition to fixed text, messages can contain data included dynamically as messages are created.

To configure real-time notification, you should define the following:

  1. Settings for the corresponding policies (see Understanding Real-Time Monitoring Policies for details)
  2. Individual recipients or notification groups
  3. Notification methods
  4. Outgoing SMTP server (only required for email messages)
  5. Settings for the corresponding rules

Note: Associate your recipient objects with people who are qualified to receive notifications about incidents.

Messages can be addressed to individual recipients or to notification groups into which recipients are organized. For detailed information about notification groups, see Notification Groups below.

Before you select email as the policy's notification method, ensure that an outgoing SMTP server is specified for the InTrust server that performs real-time monitoring.

To assign an SMTP server

  1. Double-click Configuration | InTrust Servers in the treeview.
  2. Right-click the server and select Properties.
  3. Select the Notification Parameters tab. Specify the outgoing SMTP server in the corresponding edit box.

For notification-related settings of the rule, open rule properties and go to the Notifications tab.

Message Templates

Real-time notification messages are based on templates. To create a template, open a rule’s properties dialog box, click the Notifications tab, and click Add. To edit an existing template, highlight it and click Properties.

Data from the live network can be included in notification messages. To achieve this, use special keywords in message templates to represent the values in audit trail fields.

You can insert keywords in the subject and in the body of the template. Use variable names delimited by two “%” signs, for example %EventID%. These variable names are substituted with values retrieved from audit trails when notification messages are generated. The rest of the message text that you specify is left unchanged.

Notification Groups

Notification groups list personnel who can receive notification messages when monitoring process is going on.

To create a notification group

  1. Double-click Configuration | Notifications | Notification Groups.
  2. Right-click Notification Groups and select New Notification Group from the shortcut menu to start the New Notification Group Wizard.

A notification group is populated with recipient accounts.

To configure a new recipient

  1. Double-click Configuration | Notifications.
  2. Right-click Recipients and select New Operator from the shortcut menu. A new recipient is created.
  3. On the General tab of the properties dialog box, specify the address of the recipient.
  4. Go to the Member of tab and specify what notification groups the recipient belongs to.

To populate an existing notification group

  1. Open the notification group’s properties dialog box.
  2. Click the Members tab, and select the member recipients.

Understanding Rules

Rules are grouped settings that control event analysis and response to events. The content of alerts and notification messages is also defined by rules. Rules can be activated and deactivated according to schedule.

Rule settings define conditions that are evaluated as regular audit trail checks take place. The process of condition evaluation is called matching. If a rule is matched, real-time monitoring can notify a recipient, generate an alert and/or perform response actions.

Note: Matching can be performed on the server side or on the agent side. If the agent does the matching, this helps to reduce traffic between the server and the agent. However, when you need to analyze data coming from multiple site objects (for example, failed logons from several domain controllers), you should perform matching on the server side.

Monitoring rules are logically united into rule groups. If you need a new rule, you can create it within existing group, or create a new group and then create a new rule in it.

To create a rule group, in InTrust Manager, right-click Real–Time Monitoring | Rules and select New Group.

To create a rule, right–click a group of rules, select New Rule and follow the New Rule Wizard.

The rule settings you have to specify when creating or modifying a rule are discussed below in this topic and in the following topics:

To access the settings, right–click a rule and select Properties.

Types of Rules

When you create a rule using the New Rule Wizard, you are offered the following rule type choices:

  • Single event
  • Correlated events
  • Events threshold
  • Missing event
  • Paired missing event
  • Custom rule

These options define how detection of the necessary events works. The following table helps decide which rule type works best for you in which circumstances:

Rule type Matching occurs when...

Use such rules when…

Single event A single event with specified data is detected. A single event indicates a situation that needs resolution and interference.
Correlated events The InTrust agent detects a custom pattern among the audit data that it processes. You need to detect a very specific situation, and define it in terms of event data that comes about around the same time.
Events threshold The number of events with specified data exceeds the threshold value you define. The threshold value is the number of events within the specified amount of time. You want to detect situations when similar actions are done in rapid succession. For example, such event patterns often indicate automated brute-force activity.
Missing event An event with specified data is expected, but fails to occur within the period of time you define. You expect specific events within a particular timeframe or on a regular basis. Failure to detect such an event means that something you expected did not occur.
Paired missing event A specific event occurs, and another specific event is expected after it, but the second event fails to occur within the specified time interval.

You need to watch out for situations where actions that are normally two-part fail to get to the second stage.

Custom rule The rule's underlying script evaluates to true.

You want to detect a situation that cannot be defined using any of the previous rule types. For details about using custom rules, see Customization Kit.

The “Correlated events” rule type is complex, and it is explained in more detail in the following section.

Rules that Correlate Events

Rules of the “Correlated events” type are the most advanced rules you can configure without having to write script code. With these rules, you can do the following in real time:

  • Look at data from any available audit trails with the same data source type
  • Find and compare specific data in specific event fields
  • If necessary, expect this data in specific order

The following sections explain how to create or configure such a rule with the New Rule Wizard.

Defining Events

On the Specify Events step, define all events to be checked. An event is defined by its event ID and, optionally, a set of field values that must be found in it.

All the events you need must be in the Events list on this step. You can do the following with the list:

  • Add event definitions from the Event Viewer snap-in
  • Add custom-defined events by explicitly specifying the properties they must have
  • Remove event definitions
  • Edit existing event definitions
  • Change the expected order of events or select to capture them in any order

To use Event Viewer

  1. Click Add | From Event Viewer on the Specify Events step.
  2. In the Event Viewer snap-in, right-click a suitable event and select All Tasks | Add to InTrust rule.
  3. In the Add Events to InTrust Rule dialog box that opens, select which fields in the event definition must have the same values as the fields in your example event.

To add a custom event definition

  1. Click Add | Custom Event on the Specify Events step.
  2. In the New/Edit Event dialog box that opens, provide information about the expected event:
    • Data source (the audit trail that the event comes from)
    • Values of specific event fields
    • Name of the event definition

To edit any event definition in the Events list (whether added through Event Viewer or manually), select its entry and click Edit. This opens the New/Edit Event dialog box for the selected event definition.

Setting the Order of Events

On the Specify Events step, you can also tell InTrust to expect the events in a specific order or in any order. To set a particular order, use the arrow buttons next to the Events list, which move selected entries up and down the list.

The Any order option controls whether this order is taken into account. If it is selected, the events in the list can come in any order. If the option is not selected, the listed events are expected strictly in top-to-bottom order.

Configuring Dependencies

On the Specify Event Field Dependencies step, define the relationships between the values of different fields in different events—whether one should be the same as another, not the same, greater, less, and so on.


An important option that affects whether or not the rule is matched is the This event can be included in multiple alerts check box in the New/Edit Event dialog box. If this option is enabled for an event, the event's fields are compared to fields in incoming events until the timeframe expires, and the comparison does not stop if a match is found. If the option is disabled, and a match is found, the event is not considered any more until the same event occurs again.

Configuring the Time Interval

On the Select Timeframe step, specify the time interval within which this entire state must occur.


The predefined “Windows/AD Security | Detecting Common Attacks | Gaining Administrative Rights | Suspicious activity under temporary administrative membership” rule is of the “Correlated Events” type. If you want to analyze what makes up such a rule, you can use it as an example. For that, open the properties of the rule and, on the Matching tab, click Edit.

Here is the summary of this rule as it appears in the Edit Rule Matching Parameters Wizard:

You chose to correlate the events:

User Added to Local Group (Windows Security Log, Event ID = 636, ...)

User Logged On (Windows Security Log, Event ID = 528, ...)

User Removed from Local Group (Windows Security Log, Event ID = 637, ...)


User Added to Local Group.String10 = User Logged On.String1

User Added to Local Group.String11 = User Logged On.String2

User Logged On.String1 = User Removed from Local Group.String10

User Logged On.String2 = User Removed from Local Group.String11

This happens within

30 minutes

This information reflects the following:

  1. The three Security log events added on the Specify Events step.
  2. The correspondence between events as defined on the Specify Event Field Dependencies step.
  3. The 30-minute timeframe set on the Select timeframe step.

The following settings are omitted from the summary, but are important for the rule:

  1. In the “User Removed from Local Group” and “User Added to Local Group” events, the rule looks at insertion string 3 to make sure it is “Administrators”. This is the local group whose membership is watched.
  2. The Any order option is disabled for the rule, so the events are caught in the order that they occur.
  3. The This event can be included in multiple alerts option is disabled for all three events.

Rule Activity Time

This is the period or periods when the rule is in effect. Select the General tab and click Configure Activity Time to bring up the corresponding dialog box.

To configure rule activity time

  1. Click a cell and drag the cursor to select an area.
  2. Click Activate to activate the rule at the times specified by the selected area.
  3. Click Deactivate to deactivate the rule during the selected period.

Enabling the Rule

To enable the rule, in its properties dialog box click on the General tab and select Enable.

Note: Predefined rules are all disabled by default. To activate real-time monitoring, enable the rules you need and the policies they are associated with.

Data Sources

Data sources specify the audit trails that provide the event data. You can configure this setting on the Data Sources tab of the rule’s properties.

It is recommended that you use only one data source per rule to avoid event filtering issues.


Matching conditions define what events to look for. As you create a rule, the New Rule Wizard offers you several templates on which matching will be based. You can use any of the following:

  • Single Event
  • Correlated Events
  • Events Threshold
  • Missing Event
  • Paired Missing Event
  • Custom

Also, you can configure an event filter, and specify values for matching parameters.

The rule’s matching settings are displayed on the Matching tab:

  • Parameters to be used when matching is performed
  • Agent-side or server-side matching

You may need to configure matching parameters for certain rules, for example, handling unauthorized administrative actions. For instance, you can examine the “Group member added by unauthorized personnel” rule from the “Windows/AD Security | Administrative activity | Account management” rule group. Here you have to define authorized users and groups. These are users and groups who are allowed to perform administrative actions—so, for them the rule should make exceptions: no match will be registered when an authorized user or member of an authorized group performs the action that the rule watches out for.

Click Edit to edit the parameter values. You can also edit matching parameters for the entire rule in XML by clicking Advanced.

Note:This option is intended only for advanced users. It can be used to change any aspect of rule matching. Also, this is the only way to configure matching conditions for a rule based on the “Custom” template.

As you can see, both parameters in this example are lists, but they are specified differently:

  • When specifying authorized users in this rule, you can supply wildcards, as well as for any other rule parameter defined with the tag containing wi. For example, specifying *\admin is acceptable in a list of authorized users.
  • On the contrary, authorized group names in this rule must not contain wildcards, and neither must any other rule parameter defined with the tag containing member_of. So, if you need to include groups with uniform names from multiple domains, you can supply just the name, as in admins, or the following: .\admins.

Note:When specifying parameters, note that quotation mark or backslash character must be preceded by the backslash escape character, for example: \"c:\\windows\\\"

Self Service Tools
Knowledge Base
Notifications & Alerts
Product Support
Software Downloads
Technical Documentation
User Forums
Video Tutorials
RSS Feed
Contact Us
Licensing Assistance
Technical Support
View All
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating