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:
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:
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.
You must also configure the following:
An alert database is created automatically during InTrust setup. This database is used by default for storing alert records.
To use another alert database
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:
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
For notification-related settings of the rule, open rule properties and go to the Notifications tab.
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 list personnel who can receive notification messages when monitoring process is going on.
To create a notification group
A notification group is populated with recipient accounts.
To configure a new recipient
To populate an existing notification group
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.
When you create a rule using the New Rule Wizard, you are offered the following rule type choices:
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 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:
The following sections explain how to create or configure such a rule with the New Rule Wizard.
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:
To use Event Viewer
To add a custom 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.
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.
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.
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
This information reflects the following:
The following settings are omitted from the summary, but are important for the rule:
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
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 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:
Also, you can configure an event filter, and specify values for matching parameters.
The rule’s matching settings are displayed on the Matching tab:
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:
Note:When specifying parameters, note that quotation mark or backslash character must be preceded by the backslash escape character, for example: \"c:\\windows\\\"
© 2020 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Términos de uso Privacidad