NetIQ Sentinel User Guide

NetIQ® Sentinel™
User Guide
June 2017
Legal Notice
For information about NetIQ legal notices, disclaimers, warranties, export and other use restrictions, U.S. Government
restricted rights, patent policy, and FIPS compliance, see http://www.netiq.com/company/legal/.
Copyright © 2017 NetIQ Corporation. All Rights reserved.
For information about NetIQ trademarks, see http://www.netiq.com/company/legal/. All third-party trademarks are the property
of their respective owners.
Contents
About this Book and the Library
About NetIQ Corporation
9
11
1 Introduction to the Sentinel Interface
13
Dashboards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Threat Response Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Security Health Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Events Overview Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Accessing the Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Sentinel Main Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Sentinel Control Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Solution Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Viewing Events in Real-Time
17
Viewing Events Stored in Traditional Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Creating an Event View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Viewing Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Visualizing Events Indexed in Scalable Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Searching Events
21
Searching Events Indexed in Traditional Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Performing a Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Viewing Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Refining Search Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Saving a Search Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Performing Event Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Searching Events Indexed in Scalable Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Saving Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Managing Searches and Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Configuring Filters
39
Creating Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Building a New Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Selecting an Existing Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Sample Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
View Events of Severity 3 to 5 from a System in China . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Determine if User “Bob Smith” Tried to Log In after His Account was Disabled . . . . . . . . . . . . . . . . 43
View Events from Two Subnets and Share the Filter with Network Administrators . . . . . . . . . . . . . . 44
Find all Events that Include the Words “database” and “service,” and exclude “test” . . . . . . . . . . . . 44
Viewing Events by Using Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Managing Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Correlating Event Data
47
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Contents
3
How Correlation Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Correlation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Correlation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Understanding the Correlation Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Correlation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Correlation Rule Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Creating Correlation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Understanding the Correlated Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Creating a Simple Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Creating a Sequence Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Creating a Composite Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Creating a Sequence Timeout Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Creating a Free-Form Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Creating a Combination Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating Correlation Rules From Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Associating Actions to a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Testing a Correlation Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Sample Correlation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Detecting Critical Events from an Intrusion Detection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Detecting a Spreading Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Detecting an Attack that Came from Outside the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Deploying Rules in the Correlation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Viewing Correlated Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Customizing Correlated Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Managing Correlation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Viewing the Rule Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Editing a Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Deleting a Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Managing the Correlation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Using the Correlation Engine Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Stopping or Starting a Correlation Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Visualizing and Analyzing Alerts
75
Viewing and Triaging Alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Creating an Alert View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Escalating Alerts to an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Analyzing Alert Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating the Alert Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Analyzing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Customizing the Alert Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Unable to View Alerts in the Dashboard and Alert Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7 Analyzing Trends in Data
83
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
How Security Intelligence Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Permissions for Security Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Creating a Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Creating a Dashboard by Using a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Understanding the Dashboard Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Creating Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Configuring Anomaly Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Creating an Anomaly Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4
Contents
Deploying an Anomaly Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Undeploying an Anomaly Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Managing Anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Viewing Anomaly Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Managing Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Viewing a Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Renaming a Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Deleting a Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
The Create Button Is Not Displayed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
The Main Graph and the Time Slider Are Not Synchronized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Both Names for a Renamed Anomaly Are Displayed in the Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Dashboard Date Range Not Updated to in Real Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8 Visualizing and Analyzing Network Flow Data
97
9 Configuring Dynamic Lists
99
Working with Dynamic Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Adding List Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Exporting List Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Deleting Dynamic Lists and List Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10 Leveraging Identity Information
101
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Searching and Viewing User Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Accessing the Identity Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Performing a Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Viewing Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Viewing Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
11 Manually Performing Actions on Events
105
Accessing Event Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Prerequisites for Executing Actions on Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Assigning Actions to Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Configuring Event Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Creating a New Event Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Cloning an Event Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Moving an Event Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Deleting an Event Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12 Configuring Tags
109
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
The Tags Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Creating a Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Managing Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Sorting Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Adding and Removing Tags from Favorites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Viewing and Modifying Tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Performing Text Searches for Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Deleting Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Associating Tags with Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Contents
5
Associating Tags with Event Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Associating Tags with Event Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Associating Tags with Collector Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Associating Tags with Event Sources Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Associating Tags with Collector Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Associating Tags with Report Results and Report Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Viewing Tagged Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
13 Reporting
115
Creating Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Scheduling Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Scheduling Reports across Sentinel Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Saving Reports in the CSV Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Working with Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Rebranding Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
14 Viewing Compliance to Configuration Policies
119
Viewing Secure Configuration Manager Events and Compliance Details. . . . . . . . . . . . . . . . . . . . . . . . . . 119
15 Viewing Change Guardian Events
121
16 Configuring Incidents
123
Accessing Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Creating Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Managing Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Viewing an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Attaching Workflows to Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Adding Attachments to Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Adding Notes to Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Executing Incident Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
E-mailing an Incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Adding an Incident View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
17 Configuring iTRAC Workflows
127
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Accessing the iTRAC Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using the Template Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Default Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Template Builder Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Creating a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Managing Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Viewing or Editing a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Copying a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Deleting a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Start Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Manual Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Decision Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Mail Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Command Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Activity Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
End Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6
Contents
Adding Steps to a Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding a Step from the Step Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding a Step in the Process Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding an Activity Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Adding an End Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Managing Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Copying a Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Modifying a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Editing a Manual Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Editing a Decision Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Editing a Mail Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Editing a Command Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Deleting a Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Unconditional Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Conditional Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating an Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Else Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Timeout Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Alert Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Error Transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Managing Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Incident Command Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Incident Internal Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Incident Composite Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Creating iTRAC Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Managing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Editing an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Exporting an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Importing an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Managing iTRAC Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Adding a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Deleting a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Viewing the Role Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Instantiating a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Automatic Step Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Manual Step Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Display Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Displaying the Status of a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Changing Views in Process Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Starting or Terminating a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
18 Managing Work Items
157
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Understanding the Work Item Summary Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Viewing a Work Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Processing a Work Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Managing Work Items Of Other Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A Search Query Syntax
161
Basic Search Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Case Insensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Contents
7
The Default Search Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Tokenized Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Non-Tokenized Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Wildcards in Search Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Wildcards in Tokenized Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Quoted Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Leading Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
The notnull Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Tags in Search Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Regular Expression Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Range Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
IP Addresses Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
CIDR Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Wildcards in IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
B Correlation Rule Expression Syntax
173
Event Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Event Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Filter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Trigger Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Window Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Gate Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Sequence Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Sequence Timeout Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Distinct Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Flow Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Union Operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Intersection Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Order of Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8
Contents
About this Book and the Library
The User Guide provides conceptual information about Sentinel. This book also provides an overview
of the user interfaces and step-by-step guidance for many tasks.
Intended Audience
This guide is intended for Sentinel administrators and consultants.
Other Information in the Library
The library provides the following information resources:
Installation and Configuration Guide
The Installation and Configuration Guide provides an introduction to NetIQ Sentinel and explains
how to install and configure Sentinel.
Administration Guide
Provides the administration information and tasks required to manage a Sentinel deployment.
About this Book and the Library
9
10
About this Book and the Library
About NetIQ Corporation
We are a global, enterprise software company, with a focus on the three persistent challenges in your
environment: Change, complexity and risk—and how we can help you control them.
Our Viewpoint
Adapting to change and managing complexity and risk are nothing new
In fact, of all the challenges you face, these are perhaps the most prominent variables that deny
you the control you need to securely measure, monitor, and manage your physical, virtual, and
cloud computing environments.
Enabling critical business services, better and faster
We believe that providing as much control as possible to IT organizations is the only way to
enable timelier and cost effective delivery of services. Persistent pressures like change and
complexity will only continue to increase as organizations continue to change and the
technologies needed to manage them become inherently more complex.
Our Philosophy
Selling intelligent solutions, not just software
In order to provide reliable control, we first make sure we understand the real-world scenarios in
which IT organizations like yours operate — day in and day out. That's the only way we can
develop practical, intelligent IT solutions that successfully yield proven, measurable results. And
that's so much more rewarding than simply selling software.
Driving your success is our passion
We place your success at the heart of how we do business. From product inception to
deployment, we understand that you need IT solutions that work well and integrate seamlessly
with your existing investments; you need ongoing support and training post-deployment; and you
need someone that is truly easy to work with — for a change. Ultimately, when you succeed, we
all succeed.
Our Solutions
 Identity & Access Governance
 Access Management
 Security Management
 Systems & Application Management
 Workload Management
 Service Management
About NetIQ Corporation
11
Contacting Sales Support
For questions about products, pricing, and capabilities, contact your local partner. If you cannot
contact your partner, contact our Sales Support team.
Worldwide:
www.netiq.com/about_netiq/officelocations.asp
United States and Canada:
1-888-323-6768
Email:
info@netiq.com
Web Site:
www.netiq.com
Contacting Technical Support
For specific product issues, contact our Technical Support team.
Worldwide:
www.netiq.com/support/contactinfo.asp
North and South America:
1-713-418-5555
Europe, Middle East, and Africa:
+353 (0) 91-782 677
Email:
support@netiq.com
Web Site:
www.netiq.com/support
Contacting Documentation Support
Our goal is to provide documentation that meets your needs. If you have suggestions for
improvements, click the Comment icon in the HTML versions of the documentation posted at
www.netiq.com/documentation and add your feedback. You can also email DocumentationFeedback@netiq.com. We value your input and look forward to hearing from you.
12
About NetIQ Corporation
1
Introduction to the Sentinel Interface
1
Sentinel is a Security Information and Event Management (SIEM) solution that receives information
from many sources throughout an enterprise, standardizes it, prioritizes it, and presents it to you to
make threat, risk, and policy decisions.
There are different tools to help you take advantage of all of the features Sentinel has to offer. You
must have necessary permissions to access these tools.
 “Dashboards” on page 13
 “Sentinel Main Interface” on page 15
 “Sentinel Control Center” on page 15
 “Solution Designer” on page 15
Dashboards
Sentinel provides multiple web-based dashboards to allow users to quickly access the data they need
to do their jobs. Your role and your permissions might not have access to all dashboards.
 “Threat Response Dashboard” on page 13
 “Security Health Dashboard” on page 14
 “Events Overview Dashboard” on page 14
 “Accessing the Dashboards” on page 14
Threat Response Dashboard
For users in the Operator role, the Threat Response dashboard is the main user interface for viewing
and triaging alerts. Any user with permission to manage alerts can also use the Threat Response
dashboard.
NOTE: Users who wish to access the Sentinel Main interface, or do not have permission to view or
manage alerts on the Threat Response dashboard, can click Sentinel Main in the left side navigation.
For more information, see “Sentinel Main Interface” on page 15.
For more information about the Threat Response dashboard and its options, see “Viewing and
Triaging Alerts” on page 75.
Introduction to the Sentinel Interface
13
Security Health Dashboard
The Security Health dashboard provides a high-level overview of the current state of system security,
including information about whether the system is secure or compromised. The data it displays
relates to threats from low-reputation IP addresses, vulnerabilities, and potential exploitation of any
vulnerabilities.
For example, the dashboard can inform you of the following:
 Threats - For example, there are known activities from low-reputation IP addresses or known
attacks to exploit existing vulnerabilities on the network.
 Vulnerabilities - There is no known threat activity, but there are potential vulnerabilities that you
must address to prevent an attack. For example, you might have vulnerabilities in your network
that need to be patched, but those vulnerabilities have not been exploited.
 Incomplete Monitoring or Threat Intelligence - Sentinel is capable of collecting and
correlating a wide variety of information that it then uses to inform you of active threats or
vulnerabilities. The Security Health dashboard informs you if information is not collected or is out
of date, which you should address to prevent blind spots in your security monitoring. For
example, you need to download low-reputation feed data to get an accurate evaluation of
potential threats in your network. You need to scan vulnerabilities in your network, gather IDS/
IPS data, and download Advisor data to detect potential exploits of vulnerabilities in the network.
NOTE: Users who wish to access the Sentinel Main interface can click Sentinel Main in the left side
navigation. For more information, see “Sentinel Main Interface” on page 15.
Events Overview Dashboard
The Events Overview dashboard provides a high-level overview of all incoming events. The widgets
provide information on specific types, such as correlation events, system events, and others.
Accessing the Dashboards
If you are in Sentinel Main, click My Sentinel.
To access the dashboards through a browser:
1 Launch a supported web browser.
2 Specify the following URL:
https://IP_AddressOrDNS_Sentinel_server:8443
Where IP_AddressOrDNS_Sentinel_server is the IP address or DNS name of the Sentinel
server and 8443 is the default port for the Sentinel server.
3 Log in as a user with permissions to access the dashboards.
The first time you log in, Sentinel takes you to Manage Dashboards. From here, you can:
 Access any dashboard to which you have permissions (click Manage Dashboards > Dashboard
Name)
 Create a new dashboard (click Manage Dashboards > Create Dashboard)
 Set any dashboard as your home page
14
Introduction to the Sentinel Interface
Sentinel Main Interface
The Sentinel Main interface is the main user interface for viewing and interacting with Sentinel data.
For more information about the Sentinel Main interface and its options, see “Understanding Sentinel
Applications” in the NetIQ Sentinel Administration Guide.
Sentinel Control Center
Sentinel presents the collected data in the Sentinel Main interface as well as the Sentinel Control
Center (SCC). For more information on the Sentinel Control Center, see “Understanding Sentinel
Applications” in the NetIQ Sentinel Administration Guide.
Solution Designer
You can use the Solution Designer to package and export different contents, such as filters, reports,
searches, and Correlation rules with associated actions and dynamic lists. For more information on
Solution Designer, see “Solution Designer” in the NetIQ Sentinel Administration Guide.
Introduction to the Sentinel Interface
15
16
Introduction to the Sentinel Interface
2
Viewing Events in Real-Time
2
Sentinel displays events in near real-time. Users in the administrator role can view all events in the
system. Users in non-administrator role can view events based on the security or tenant filter applied
for their role.
For information about permissions to view events, see “Configuring Roles and Users” in the NetIQ
Sentinel Administration Guide.
 “Viewing Events Stored in Traditional Storage” on page 17
 “Visualizing Events Indexed in Scalable Storage” on page 18
Viewing Events Stored in Traditional Storage
To view events stored in traditional storage, you must first create an event view. To create and view
events in event views, you must have the Create and use Event Views permission.
Creating an Event View
To create an event view:
1 From Sentinel Main, click Real-time Views > Events > Create.
2 Specify the following information:
 Name: Specify a unique name for the event view.
 Sharing: Select either of the following options:
 Public: Allow everyone to view the event view. In the Public mode, other users can
only view the events but cannot modify the event view. You are still the owner of the
event view.
 Private: Only you are able to view the event view.
 Criteria: Specify the criteria to view specific events.
 Event Attribute: Select the attribute based on which you want to categorize the event data.
 Tenant: If you are in a multi-tenant environment, select a tenant name for which you want to
view events. The default tenant allows you to view events from all tenants. If you select a
tenant, only users of that tenant can view the events in this event view.
This option is available only if you are an administrator in a multi-tenant environment.
 Chart Type: Specify the chart type in which you want to view the event data.
 Y Axis: Select either of the following options:
 Event Count: Displays a graph with number of events for the specified time range.
 Event Count per Second: Displays a graph with event rate for the specified time
range.
 Time range: Select the time range for which you want to view the event data.
 Display Interval: Select the time interval between two data points.
3 Click Save to save the event view configuration.
Viewing Events in Real-Time
17
Viewing Events
To view an event view:
1 Click Real-time Views > Events.
2 Select the event view and click Open the event view.
Sentinel provides a graphical representation of events for the specified criteria. The chart
automatically refreshes after the interval specified in Display Interval.
As you are viewing event data, you can perform the following actions in the chart:
 Mouse over the data points in the chart to view the number of incoming events or events per
second for a specific time stamp.
 Click any category in the legend to filter the view by the legend items.
 Click and drag the mouse to zoom the view for a specific time range.
The event view enables you to view only the summarized event data. To view the event details or
perform any event operations, you can do either of the following:
 Click a specific area in the chart to open the Search interface with the list of events represented
in that area.
 Click Search Events.
For information about viewing event details and performing event operations, see “Viewing Search
Results” on page 23 and “Performing Event Operations” on page 31.
Visualizing Events Indexed in Scalable Storage
You can visualize events indexed in scalable storage through an interactive dashboard. SSDM
leverages Kibana, a browser-based analytics and search dashboard, that helps you to search and
visualize events.
To visualize events indexed in scalable storage:
1 Log in to the Sentinel Scalable Data Manager (SSDM) web interface.
2 In the Visualize Events section, select the dashboard you want to view, and click View
Dashboard.
SSDM launches the Events Visualization dashboard that displays an overview of events in your
enterprise for the selected time range (by default 1 week). You can visualize various aspects of
events, such as:
 Event time line with threat reputation scores
 Top 5 Taxonomies and top 5 events
 Vulnerability information and threat types
 Geographical origin of the events
 Top 5 initiator and target user names and their departments
 Associated risks
 Associated user activities
18
Viewing Events in Real-Time
You can modify or create new visualizations and dashboards with the data you want to visualize. For
information about creating visualizations and dashboards, see Visualize and Dashboard in Kibana
documentation.
NOTE: If the network latency between SSDM and Elasticsearch nodes is high, the event visualization
interface may not launch due to a time-out error. To avoid this issue, increase the time-out period in
Kibana. For more information, see Event Visualization Interface May Not Launch Due to Time-Out
Error in the Troubleshooting section of the NetIQ Sentinel Administration Guide.
Viewing Events in Real-Time
19
20
Viewing Events in Real-Time
3
Searching Events
3
Sentinel provides an option to perform a search on events. With the necessary configuration, you can
also search system events generated by Sentinel and view the raw data for each event. By default,
events are returned in a reverse chronological order.
By default, the search results include all events generated by the Sentinel system operations. These
events are tagged with the Sentinel tag. If no query is specified and you click Search for the first
time after the Sentinel installation, the default search returns all events with severity 0 to 5.
Otherwise, the Search feature reuses the last specified search query.
To search for a value in a specific field, use the ID of the event name, a colon, and the value. For
example, to search for an authentication attempt to Sentinel by user2, use the following text in the
search field:
evt:LoginUser AND sun:user2
An advanced search can narrow the search for a value to a specific event field. The advanced search
criteria are based on the event IDs for each event field and the search logic for the index. Advanced
searches can include the product name, severity, source IP, and the event type. For example:
 pn:NMAS AND sev:5
This searches for events with the product name NMAS and severity five.
 sip:10.0.0.01 AND evt:"Set Password"
This searches for the initiator IP address 10.0.0.1 and a “Set Password” event.
Multiple advanced search criteria can be combined by using various operators. The advanced search
criteria syntax is modeled on the search criteria for the Apache Lucene open source package. For
more information on building search criteria, see Appendix A, “Search Query Syntax,” on page 161.
NOTE: If time is not synchronized across your server, client, and event sources, you might get
unexpected results from your search. This is especially a problem if searches are performed on time
durations such as Custom, Last 1 hour, and Last 24 hours where display results are based on the
time zone of the machine on which the search is performed.
 “Searching Events Indexed in Traditional Storage” on page 21
 “Searching Events Indexed in Scalable Storage” on page 35
Searching Events Indexed in Traditional Storage
You can run a search to view events indexed in traditional storage. You can also search for events in
other Sentinel servers that are distributed across different geographic locations. For more
information, see “Configuring Data Federation” in the NetIQ Sentinel Administration Guide.
This section provides information about the following topics:
 “Performing a Search” on page 22
 “Viewing Search Results” on page 23
 “Refining Search Results” on page 25
Searching Events
21
 “Saving a Search Query” on page 26
 “Performing Event Operations” on page 31
Performing a Search
To perform a search:
1 From Sentinel Main, in the Reports and Searches panel, click New search.
2 You can perform a search by using any of the following:
 Search criteria: Specify the search criteria in the Search field.
For information on creating search criteria, see Appendix A, “Search Query Syntax,” on
page 161.
 Build criteria: Build a new criteria using the build criteria user interface. For more
information, see “Creating a Filter by Using the Build Criteria Dialog” on page 42.
 Select and Append criteria: Click Select and Append criteria and select from the criteria
listed, click Add, and then click Search. You can select criteria from the list of criteria or filter
the criteria based on recent criteria, tags, or filters.
 Show only recent criteria: Select a search criterion from the recent search history.
The search history displays a maximum of 15 search expressions. Select the criteria,
click Show recent criteria, and then click Add.
 Show only Filters: You can reuse existing filters to perform a new search. Click Show
Filters that lists the existing filters. Select the filter on which you want to perform the
search, and then click Add.
 Show only Tags: You can search events that have a particular tag. Click Show Tags,
that lists the tags in the system. Select the tags, and then click Add.
You can combine multiple criteria, tags, or filters by using the And or Or condition.
3 (Optional) Select a time period for the search.
 The default is Last 1 hour.
 Custom allows you to select a start date and time and an end date and time for the query.
The start date should be earlier than the end date, and the time is based on the machine’s
local time.
 Whenever searches all available data, without any time constraints.
4 (Optional) If you have administrator privileges, you can select other Sentinel servers for the
search.
If you have data federation configured, you can perform a search on other Sentinel servers. For
more information, see “Configuring Data Federation” in the NetIQ Sentinel Administration Guide.
5 Click Search.
The search results are displayed. For information on the search results, see “Viewing Search
Results” on page 23.
6 (Optional) Modify the search criteria by clicking Edit Criteria.
7 (Optional) Modify the search results by selecting the desired event fields in the search results
To add an AND or Or condition to the existing criteria, left-click the event field, select the required
fields, and then specify the desired condition.
8 Click Search.
9 (Conditional) To save the search query, see “Saving a Search Query” on page 26.
22
Searching Events
Viewing Search Results
Searches return a set of events. When results are sorted by relevance, only the top 50,000 events
can be viewed. When results are sorted by time, all the events in the system are displayed.
Occasionally, the search engine might index events faster than they are inserted into the data
directory. If you run a search that returns events that were not added in the data directory, you get a
message indicating that some events match the search query, but they are not found in the data
directory. If you run the search again later, the events are added to the data directory and the search
is shown as successful.
The information in each event is grouped into the following categories:
Category
Icon
Description
General
No icon
Generic information about the event, such as severity, date, time,
product name, and taxonomy.
Initiator
The source that caused the event to occur. The source can be a device,
network port, etc.
Target
The object that is affected by the event. The object can be a file,
database table, directory object, etc.
Observer
The service that observed the event activity.
Reporter
The service that reported the event activity.
Tags
No icon
Tags that the events are being tagged with.
Customer value
No icon
Fields set by the customer.
Retention period
No icon
Retention period of the event.
The initiator, target, and observer can be hosts, services, and accounts. In some cases, the initiator,
target, and observer can be all the same, such as a user modifying this or her own account. In other
cases, the initiator, target, and observer can be different, such as an intrusion detection system
detecting a network attack. If an event field has no data, it is not displayed in the results.
Event fields are grouped according to the following categories:
Group
Icon
Description
Host
The initiator or target host information. For example, initiator host IP, target hostname,
or target host ID.
User
The initiator or target user information. For example, the initiator username, initiator
user department, target user ID, or target username.
Service
The initiator or target service information. For example, the target service name, target
service component, or initiator service name.
Domain
Domain information of both the host and user. For example, the target host domain
and initiator username.
IPCountry
The country information of the initiator and target trust. For example, the target host
country.
Target trust
The target trust and target domain information of the event that was affected. The
name can be a group, role, profile, etc.
Searching Events
23
Group
Icon
Description
Target data
The target data name and data container information. The data name is the name of
the data object, such as a database table, directory object, or file that was affected by
the event. The data container is the full path for data object.
Tenant name
The name of the tenant that owns the event data, applied to all the events in the
inbound stream from a given Collector. The tenant name can be the name of the
customer, division, department, etc.
Vulnerability
A flag that indicates whether Exploit Detection has matched this attack against known
vulnerabilities in the target.
Each event type is represented by a specific icon. The following table lists the icons that represent the
various types of events:
Icon
Type of Event
Audit event
Performance event
Anomaly event
Correlation event
Unparsed event
You can view the search results in the summary view and in the detailed view. When you mouse over
an event field, the information about the field is displayed.
 “Summary View” on page 24
 “Detailed View” on page 24
Summary View
The Summary view of the search results displays the basic information about the event. The basic
information includes severity, date, time, product name, taxonomy, and observer category for the
event.
Detailed View
1 To view the report details, click the More link at the top right corner of the search results.
This displays details such as host/user domain information, IPCountry information, extended
target fields like TargetTrust and TargetData, Observer and Reporter fields, customer set
variables, default data retention duration information for any individual event, and the tags set for
the event.
2 To view all the details of an event, click the All link.
3 To view details about all events, click the Show more details link at the top of the search results
page.
You can expand or collapse the details for all events on a page by using the Show more details
or Show less details link.
24
Searching Events
4 (Optional) Click the get raw data link to open a new Raw Data tab with event source hierarchy
and event source fields populated, based on the information received from the event.
The get raw data link is available only for users in the administrator role.
If the search result is a system or an internal event, the get raw data link does not appear.
To verify and download the raw data files, see “Verifying and Downloading Raw Data Files” in the
NetIQ Sentinel Administration Guide.
Refining Search Results
The search refinement panel can be used to narrow the search results by selecting one or more
values for an event field. You can refine the results for one or more event fields.
The set of event fields that is displayed in the search refinement panel is configurable on a per-user
basis.
For performance considerations, the maximum sample size used to calculate the event field value
statistics is 50,000 events. The actual sample size is displayed in the field count label as Field
counts based on the first <sample-size> events where <sample-size> is replaced by the
actual sampling size.
To refine search results:
1 From Sentinel Main, in the Reports and Searches panel, click New Search.
2 Specify the search criteria, then click Search.
For more information on how to run an event search, see “Searching Events Indexed in
Traditional Storage” on page 21.
3 Click fields in the REFINE section.The Select Event Fields window is displayed.
4 To refine the search, select the event fields from the available fields, then click Save.
The selected event fields are displayed in the REFINE panel.
A count at the right side of each event field displays the number of unique values that exist for
that event field in the data directory. The calculation is based on the first 50,000 events found.
The event field selection is on a per-user basis. Each user can have a different set of selected
event fields.
5 Click each event field to view the unique values for that event field.
For example, if the search results contain events that had severities 1, 2, 5, and 4, the event field
is displayed as Severity (4).
The top 10 unique values are initially displayed in the order of most frequent to least frequent.
The value next to the check box represents the unique value for that event field and the value at
the far right represents the number of times the value appears in the search result.
If there are multiple unique values occurring the same number of times in a search, the values
are sorted by the most recent occurrence of the value.
For example, if events of severity 1 and 4 occurred 34 times in the search results, and an event
of severity 4 was logged most recently, the unique value 4 appears at the top of the list.
To display the unique values in the order of least frequent to most frequent, click reverse.
When there are more than 10 unique values, you can view and filter either the top 10 or the
bottom 10 unique values. You cannot refine your search on both the conditions at the same time.
Searching Events
25
In the following scenarios, the number of events returned from a refined search is greater than
the number of values listed for an event field:
 If the refinement performs a new search with additional terms intersected with the initial
search string, such as by using an AND operator, the new search is run against all events in
the system, including the result set from the initial search. If new events that came into the
system match the refined search, they are shown in the resulting set and the event count is
greater than the field value count.
 If there are more than 50,000 events, the event field statistics are calculated only on the first
50,000 events.
There could be an event field value that occurs 50 times in the first 50,000 events, but it
could occur 1,000 times in all other stored events. In this scenario, the displayed value
count is 50, but when the search is refined with this value it returns 1,000 events.
6 Click OK.
Selected event field values are listed under the event field in the REFINE panel.
The right panel displays the refined search results, which contain only the selected values.
7 Repeat Step 3 through Step 6 to further refine the search.
8 (Optional) Click clear to clear the selected unique event field values from the REFINE panel and
to return to the original search results.
9 (Optional) Click add to search to add the refined search values to the current search tab and to
recalculate the search statistics.
If you have already added the event field value to the current search tab, clicking clear does not
return to the previous search results.
Saving a Search Query
You can save a search query, then repeat it as desired. To save a search query, you must first
perform a search. When you are satisfied with the search results, you save the search query.
NOTE: You must have the necessary permission to access the specific options. For example, only
users in the Report Administrator role can save the search query as a report template.
 “Saving a Search Query as a Search Template” on page 26
 “Saving a Search Query as a Filter” on page 27
 “Saving a Search Query as a Report Template” on page 27
 “Saving a Search Query as a Routing Rule” on page 30
 “Saving a Search Query as a Retention Policy” on page 30
 “Saving a Search Query as a Security Intelligence Dashboard” on page 31
Saving a Search Query as a Search Template
1 Perform and refine a search until you are satisfied with the search results.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 Click Save as, and then click Save search.
3 Specify a unique name for the search and provide an optional description.
4 Specify the following information in the Default Parameters section:
26
Searching Events
Data sources: Displays the number of servers that Sentinel will search for events. This option is
useful if data federation is enabled. To select the data sources you want to search, click selected
data sources, then select the data sources.
Email to: To e-mail the report template to others, specify the e-mail address. To send the report
template to more than one person, specify multiple e-mail addresses separated by a comma.
Result limit: Specify the number of results to be stored in the search template. By default, 1000
results are stored in a report template.
5 Click Save.
Saving a Search Query as a Filter
You can save your search queries as filters for future use so you can perform a search using the
saved filters rather than specifying the query manually every time.
In Sentinel Scalable Data Manager, when you create a filter, it automatically creates a corresponding
Search object in the Event Visualization dashboard. These search objects in the dashboard are
always public. Therefore, these search objects are visible to all users regardless of the Sharing type
you apply when creating a filter. Similarly, when you save a search query in the Event Visualization
dashboard, it also creates a corresponding filter in Sentinel and is private to the user that creates the
search object.
To save a search query as a filter:
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 (Conditional) If you are using Sentinel with traditional storage, click Save as, then click Save
search as filter.
3 (Conditional) If you are using Sentinel with scalable storage, click Save as filter.
4 Specify a unique name for the filter and an optional description.
5 In the drop-down list, select one of the following options to specify the access for this filter:
 Private: Allows you to make this filter private. Other users cannot view or access this filter.
 Public: Allows you to share this filter with all users.
 Users in same role: Allows you to share this filter with users who have the same role as
yours.
 Users in selected roles: Allows you to share this filter with users in specific roles. If you
select this option, a blank field is displayed where you can specify the roles. As you type the
role name, a list of roles is displayed.
Select one or more roles.
NOTE: This option is available only for users in the administrator role.
6 Click Save.
The saved filter is listed in the Filters panel. For more information on filters, see Chapter 4,
“Configuring Filters,” on page 39.
Saving a Search Query as a Report Template
You can save the search query as a search report.
Searching Events
27
NOTE: You must have the Manage Reports permission to save the search query as a report
template.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 When you are satisfied with the search results, click Save as, then click Save search as report.
3 Specify the following parameters:
Parameter
Description
Report name
Specify a unique name for the report. The name should not exceed 200
characters.
Based on
Select the base report from which you want to create the report.
You can view a sample report by clicking the View Sample button.
Description
The description is automatically displayed based on the report that is
selected and you can edit the description.
Criteria
Criteria is automatically populated based on the report selected and is
not editable.
Additional criteria
Specify additional search criteria to the existing criteria. To build a new
criteria on your own, click Edit Criteria. To build a new criteria from
available system objects containing criteria, click Add Criteria.
The criteria that you add here is appended to the existing criteria.
Data sources
Select the source machines on which the reports can be run by clicking
the selected data sources link. You can select data sources only if
your Sentinel is configured for data federation.
For more information, see “Configuring Data Federation”in the NetIQ
Sentinel Administration Guide.
Additional Criteria
Specify additional criteria to refine the results. The criteria that you
specify here can be edited while scheduling the report. If you specify
Criteria name, the name is displayed at the end of the report results.
NOTE: This parameter is not available for all reports.
Time Zone
Specify the time zone with which you want to populate the report. When
you schedule the report, the time zone that you specify here is
displayed in the report data.
For example, if the Time Zone is set to US/Pacific-New time, the report
data displays the selected time zone.
By default, it displays the time zone that is set in the client system.
NOTE: This parameter is not available for all reports.
28
Searching Events
Parameter
Description
Date Range
If the report includes time period parameters, choose the date range.
All time periods are based on the local time for the browser. The From
Date and the To Date automatically change to reflect the option you
selected.
 Current Day: Shows events from midnight of the current day until
11:59:00 PM of the current day. If the current time is 8:00:00 AM,
the report shows 8 hours of data.
 Previous Day: Shows events from midnight yesterday until
11:59:00 PM yesterday.
 Week To Date: Shows events from midnight Sunday of the
current week until the end of the selected day.
 Previous Week: Shows events for the last seven days.
 Month to Date: Shows events from midnight the first day of the
current month until the end of the selected day.
 Previous Month: Shows events for a month, from midnight of the
first day of the previous month until 11:59:00 PM. of the last day of
the previous month.
 Custom Date Range: Shows events for a period whose start and
end date are chosen. If you select Custom Date Range, set the
start date (From Date) and the end date (To Date) for the report.
Group By
Group the events according to specific event field by selecting the
event field from the Group by drop-down list.
NOTE: This parameter is not available for all reports.
Language
Choose the language in which the report labels and descriptions should
be displayed. The possible values are English, French, German, Italian,
Japanese, Traditional Chinese, Simplified Chinese, Spanish, or
Portuguese.
The default value is the language with which the current user logged in,
if that language is supported by the report. If the report does not
support the language, the report’s default language (typically English)
is used.
The data in the report is displayed in the language that was originally
used by the event source.
Email to
Specify an e-mail address in the Email to field. If you want to mail the
report to more than one user, separate the e-mail addresses with a
comma.
Result limit
Specify the number of results to be displayed or stored when you run or
schedule the report. By default, 1000 results are stored.
If you specify a value in Group By field, the result limit is based on
grouping.
4 Click Save to save the search as report definition.
You can see the saved report definition in the Reports and Searches panel in the Sentinel Main
interface. To view the reports, see “Working with Reports” on page 117.
Searching Events
29
Saving a Search Query as a Routing Rule
You must be in the administrator role to save the search query as a routing rule.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 When you are satisfied with the search results, click Save as, then click Save search as routing
rule.
3 Specify a name for the rule.
4 (Conditional) To associate one or more tags to the events, click Select tag, select the desired
tags, then click Set.
5 Select where you want to route the events to:
 All: Events are routed to all Sentinel services, including Correlation and Security
Intelligence.
 Event store only: Events are sent directly to the event store, and are not displayed in
Event Views and the search results page.
 None (drop): Events are dropped or ignored, and are not sent to any Sentinel service.
6 Select one or more actions to be performed on each event that meets the search criteria. Click
the plus and minus icons to add and remove actions.
7 Click Save.
Saving a Search Query as a Retention Policy
You must be in the administrator role to save the search query as a retention policy.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 When you are satisfied with the search results, click Save as, then click Save search as
retention policy.
3 Specify a name for the retention policy.
4 In the Keep at least field, specify the minimum number of days to retain the events in the system.
The value must be a valid positive integer.
5 (Optional) In the Keep at most field, specify the maximum number of days for which the events
should be retained in the system.
The value must be a valid positive integer and must be greater than or equal to the Keep at least
value. If no value is specified, the system retains the events in the system until the space is
available in primary storage.
6 Click Save.
The newly created policy is displayed in the data retention table. For more information on
retention policies, see “Configuring Data Retention Policies” in the NetIQ Sentinel Administration
Guide.
30
Searching Events
Saving a Search Query as a Security Intelligence Dashboard
You must have the Manage and View Security Intelligence Dashboards permission to create a
dashboard.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 When you are satisfied with the search results, click Save as, then click Save search as
dashboard.
3 Specify the following information to create the dashboard:
 Name: Specify a unique name for the dashboard.
 Classifier: Select the classifier that determines the categories displayed in the dashboard.
Click the Info link for information on each category.
 Data Retention Period: Select how long the data for the dashboard is retained.
4 Click Create dashboard to create the dashboard.
The dashboard is displayed in a new browser tab. A new dashboard is empty because it has not had
time to collect any data. For more information on dashboards, see Chapter 7, “Analyzing Trends in
Data,” on page 83.
Performing Event Operations
You can use the events in the search results to perform various tasks as you view the search results.
 “Executing Actions” on page 31
 “Exporting the Search Results to a File” on page 32
 “Adding Events to an Incident” on page 32
 “Creating an Incident” on page 33
 “Adding Events to a Correlation Rule” on page 33
 “Creating a Correlation Rule by Using Events” on page 33
 “Viewing Identity Details of Events” on page 34
 “Viewing Advisor Report” on page 34
 “Viewing Asset Data” on page 34
 “Viewing Vulnerabilities” on page 35
Executing Actions
Only users in the following roles can execute actions on events:
 Administrator
 Incident Administrator
 Security Policy Administrator
 User
You need to configure the actions before executing actions on events. For more information, see
“Prerequisites for Executing Actions on Events” on page 105.
Searching Events
31
To execute actions on events:
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events on which you want to execute actions.
3 Click Event operations > Show action panel.
4 In the Event Actions panel > Actions drop-down, select the desired actions, then click Execute.
For more information on executing actions, see Chapter 11, “Manually Performing Actions on
Events,” on page 105.
The results of the actions are displayed in the Results field.
Exporting the Search Results to a File
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events you want to export to a file.
3 Click Event operations > Export to file.
4 Specify the following information:
File Name: Specify a name for the file to which you want to export the search results.
Event Limit: Specify the maximum number of events to be saved. The event limit must be less
than the number of events you selected and the maximum event limit is 200000.
All the search results are written into a .csv file. These files are then compressed into a .zip file
for downloading.
5 (Optional) You can remove the event fields that you do not want to export to the file. Click
Choose Fields, then clear the selections for the fields that you do not want to export to the file.
By default, the null fields are excluded and not exported to file.
6 Click Export to export the search result to a file.
A download file dialog box is displayed with an option to open or save the .zip file.
7 Select the desired option, then click OK.
Adding Events to an Incident
You must have the View or Create Incidents and Add Events to Incidents permission to add events to
incidents.
For more information on Incidents, see Chapter 16, “Configuring Incidents,” on page 123.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events you want to add to an incident.
3 Click Event Operations > Add to incident.
NOTE: Ensure that incidents are available. If there are no incidents available, then you need to
create one. For more information on creating incidents see“Creating an Incident” on page 33.
32
Searching Events
4 Click Search to view all the available incidents.
5 (Optional) To view incidents based on categories, select a category from the GroupBy drop-
down list.
6 Select the incident to which you want to add events.
7 Click OK.
Creating an Incident
You can create an incident from a group of events representing something of interest. For example,
group together similar events or group together a set of different events that indicate a pattern of
interest such as an attack.
You must have the View or Create Incidents and Add Events to Incidents permission to create
incidents.
For more information on Incidents, see Chapter 16, “Configuring Incidents,” on page 123.
To create an incident from events:
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events you want to add to an incident.
3 Click Event operations > Create incident.
4 Use the following information to create the incident:
Title: Specify a title for the incident.
Description: Specify a description of the incident.
Severity: Select the severity of the incident from the drop-down list.
Priority: Select the priority of the incident from the drop-down list.
Category: Select the category of the incident from the drop-down list.
Responsible: Select the user that is responsible to investigate and close the incident.
iTRAC: Select an iTrac workflow to use to manage the incident.
5 Click OK to create the incident.
Adding Events to a Correlation Rule
You must have the Manage Correlation Engine and Rules permission to create a Correlation rule. For
more information on creating a Correlation rule by using events, see “Creating Correlation Rules
From Search Results” on page 64.
Creating a Correlation Rule by Using Events
You must have the Manage Correlation Engine and Rules permission to create a Correlation rule. For
more information on creating a Correlation rule by using events, see “Creating Correlation Rules
From Search Results” on page 64.
Searching Events
33
Viewing Identity Details of Events
If Sentinel is integrated with Identity Management systems, you can view the user identity details of
events. You must have the View People Browser permission to view the Identity details.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events for which you want to view the identity details.
3 Click Event operations > Show identity details.
4 Select whether you want to view the identity of the Initiator user, the Target user, or both.
For more information on identity details, see Chapter 10, “Leveraging Identity Information,” on
page 101.
Viewing Advisor Report
The following are the prerequisites to view the Advisor data:
 The Advisor feed must be up-to-date, processed, and loaded into the Sentinel database.
 The selected event must be from a product supported by Advisor and it must have the
Vulnerability field value set to 1.
To view the Advisor data:
1 Click Filters > Exploit Detected Events or specify vul:1 in the Search field, then click Search.All
events that are likely to have exploited a known vulnerability are displayed.
2 In the search results, select the events for which you want to view the Advisor data.
3 Click Event operations > View Advisor report.
The Advisor report is displayed in a new tab.
For more information on Advisor, see “Detecting Vulnerabilities and Exploits” in the NetIQ
Sentinel Administration Guide.
Viewing Asset Data
You must have the View Asset Data permission to view the asset data of the selected events. You can
view the asset information related to a machine or device from which you are receiving events. To
view the asset data, you must run the asset management Collector and ensure that the asset data is
being added to the Sentinel database.
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events for which you want to view the asset data.
3 Click Event operations > View assets.
34
Searching Events
Viewing Vulnerabilities
You must have the View asset vulnerability data permission to view the Vulnerability data. You can
view the vulnerabilities of the selected destination systems. To view the Vulnerability data, you must
run the Vulnerability Collector and ensure that the Vulnerability scan information is being added to the
Sentinel database.
Vulnerabilities can be seen for the current time or for the event time.
 View Vulnerabilities at current time: This report queries the database for vulnerabilities that
are active (effective) at the current date and time, and displays the relevant information.
 View Vulnerabilities at time of event: This report queries the database for vulnerabilities that
were active (effective) at the date and time of the selected event, and displays the relevant
events.
To view the Vulnerability report:
1 Perform a search, and refine the search results as desired.
For more information, see “Searching Events Indexed in Traditional Storage” on page 21 and
“Refining Search Results” on page 25.
2 In the search results, select the events for which you want to view the Vulnerability data.
3 (Conditional) To view vulnerabilities at the current time, click Event operations > View
Vulnerabilities at current time.
4 (Conditional) To view vulnerabilities at the time of the event, click Event operations > View
Vulnerabilities at time of event.
Searching Events Indexed in Scalable Storage
You can search for events indexed in scalable storage. By default the search is performed for the last
1 hour. You can change the time range in the Event Visualization interface where the search results
are displayed.
To search for events indexed in scalable storage:
1 Log in to the Sentinel Scalable Data Manager (SSDM) web console:
https://<IP_Address or DNS_SSDM_server:port_number>
IP_Address or DNS_SSDM_server is the IP address or the DNS name of the SSDM server and
port_number is the default port of the SSDM server.
2 You can specify the search criteria by performing any of the following:
 Specify the search criteria in the Criteria field.
For information about the syntax for search criteria, see Appendix A, “Search Query
Syntax,” on page 161.
 Click Build criteria to build the criteria using an interactive user interface.
 Click Select and Append criteria to reuse an existing criteria from Tags and Filters.
3 Click Search.
SSDM displays the search results in a new tab. You can further refine the search results based on the
desired event fields, time range, and so on. For information about refining the search results, see
Discover in Kibana documentation.
Searching Events
35
NOTE: If the network latency between SSDM and Elasticsearch nodes is high, the event visualization
interface may not launch due to a time-out error. To avoid this issue, increase the time-out period in
Kibana. For more information, see Event Visualization Interface May Not Launch Due to Time-Out
Error in the Troubleshooting section of the NetIQ Sentinel Administration Guide.
Saving Searches
You can save your search queries for future use so that you can perform a search using the saved
query rather than specifying the query manually every time. You can save the search query either as
a search in the Event Visualization interface or as a filter in the SSDM home page.
When you save your search query as a search in the Event Visualization interface, it automatically
creates a corresponding filter in SSDM and the filter is private to the user that creates the search.
Similarly, when you save your search query as a filter in SSDM, it automatically creates a
corresponding search object in the Event Visualization interface. These searches are always public.
Therefore, the searches are visible to all users regardless of the Sharing type you apply when
creating a filter.
Search objects that already exist in the Elasticsearch cluster before it’s configured with SSDM are not
listed under Filters by default. You must manually save the pre-existing search objects as filters, if
required.
To save the search query:
1 In the SSDM home page, specify the search criteria in the Criteria field and click Search.
Sentinel displays the search results in the new Event Visualization interface.
2 (Conditional) To save the search query as a search object, click the Save search icon, specify a
unique name for the search, and then click Save.
If you specify a duplicate name, you can still save the search but it will not create a
corresponding filter in SSDM for this search.
3 (Conditional) To save the search query as a filter in SSDM, go to the SSDM home page, and
click Save as filter.
3a Specify a unique name for the filter and an optional description.
3b In the Sharing drop-down list, select one of the following options to specify the access for
this filter:
 Private: Allows you to make this filter private. Other users cannot view or access this
filter.
 Public: Allows you to share this filter with all users.
 Users in same role: Allows you to share this filter with users who have the same role
as yours.
 Users in selected roles: Allows you to share this filter with users in specific roles. If
you select this option, a blank field is displayed where you can specify the roles. As you
type the role name, a list of roles is displayed.
Select one or more roles.
NOTE: This option is available only for users in the administrator role.
3c Click Save.
36
Searching Events
Managing Searches and Filters
When you edit or delete a search in the Event Visualization interface, the changes are applied to the
corresponding filter in SSDM as well. Similarly, when you edit or delete a filter in SSDM, the changes
are applied to the corresponding search in the Event Visualization interface as well.
You can edit and delete only the filters that you created. The default filters and the filters that other
users have shared with you cannot be edited or deleted. For information about managing searches,
see Managing Saved Searches, Visualizations, and Dashboards in Kibana documentation.
Searching Events
37
38
Searching Events
4
Configuring Filters
4
The Filters feature in Sentinel allows you to customize the event search and prevent data overload.
You can save a search query as a filter and reuse it as required, so you can perform a search by
selecting the filter rather than specifying the query manually every time.
You can reuse filters while using or configuring Sentinel features, such as:
 Configuring Data Synchronization
 Configuring a Data Retention policy.
 Configuring the data visibility settings for a role.
 Creating dashboards.
 Configuring event routing rules.
 Viewing real-time events in Event Views.
Sentinel provides a list of filters by default. You can also create your own filters. To view the Filters
available in Sentinel, click Filters in the left navigation panel.
 My Filters: Lists the default filters and the filters you created.
 Shared Filters: Lists the filters that other users have shared with you.
To view events based on filters, select the desired filter. The associated events are displayed in the
search results panel.
 “Creating Filters” on page 39
 “Sample Filters” on page 43
 “Viewing Events by Using Filters” on page 45
 “Managing Filters” on page 45
Creating Filters
Filter criteria are simple math expressions and simple evaluations. Filters work on selection sets by
matching events against the specified criteria. If the match is TRUE, the event is displayed in realtime views or search results, or passed to other functions. If the match is FALSE, the event is
blocked. The filter criteria is nothing but your search query.
For example, consider a search query that is written as follows:
(sip:"10.0.0.1")
Events whose source IP address is 10.0.0.1 are included in the filter.
You must use the event field ID to represent an event name. Click the Tips link on the top right of the
Sentinel Main interface for a list of event field names and their IDs.
Configuring Filters
39
For information about the syntax for the criteria, see Appendix A, “Search Query Syntax,” on
page 161.
 “Building a New Criteria” on page 40
 “Selecting an Existing Criteria” on page 41
 “Creating a Filter” on page 42
Building a New Criteria
The Build criteria interface provides a list of parameters required to build filter criteria ranging from
simple to complex. You can either select the parameters, or you can manually specify the filter
criteria.
For information about the syntax for criteria, see Appendix A, “Search Query Syntax,” on page 161.
The Build Criteria dialog box includes the following elements:
Table 4-1 Build Criteria Dialog Box Elements
Element
Description
Criteria
If you select Structured, this field displays the criteria formed by the parameters you
select. You cannot modify or specify the filter criteria.
If you select Free-form, you can manually specify the filter criteria.
Structured
Allows you to select the various parameters to build the filter criteria.
Free-form
Allows you to manually specify the filter criteria rather than selecting from the
available parameters.
The search criteria is based on the standard Lucene syntax with some Sentinel
extensions. For information on creating a filter criteria (search query), see
Appendix A, “Search Query Syntax,” on page 161.
If this option is selected, the following elements are not displayed:
 Event fields
 Criteria fields
 Field details
Exclude system events
Select this option to exclude Sentinel internal events such as audit events and
performance events from the search results.
Event fields
Displays a categorized list of possible event fields you can add to the filter criteria.
You can expand each category to display the set of fields in that category. If you
know the name of the field you want, specify the name in the Search field. The event
category list will adjust to present only matching fields.
For more information on event fields, click Tips located at the top right of the
Sentinel Main interface.
40
Configuring Filters
Element
Description
Criteria fields
Lists a set of overlay criteria that you can use on top of per-field searches. The
following fields are displayed by default:
 All data: Performs a search across all event fields.
For more information, see “The Default Search Field” on page 163 in
Appendix A, “Search Query Syntax,” on page 161.
 Tags: Events can be tagged in various ways to help identify relationships
between events. Queries that include a “Tags” search will look at the event tags
(rv145) for matches.
 Taxonomy: Events are also classified using a number of taxonomic categories
for the action, outcome, and so on. Queries that include a “Taxonomy” search
will search for specific classes of events.
For more information on taxonomy, see Sentinel Taxonomy.
Field details
The fields in this section vary depending on the event or criteria fields you select. For
example:
 For tokenized fields, you can specify the words that you want to include or
exclude in the filter criteria. For information on the tokenized and non-tokenized
fields, click Tips located at the top right of the Sentinel Main interface.
 For non-tokenized fields, you can specify a value or a range of values.
 For taxonomy fields, specific taxonomy options are displayed.
 For date attributes, a date-time calendar is displayed as you type the date. You
can select a date.
 For fields that contain internal Sentinel UUIDs, such as the CollectorID field,
the corresponding Sentinel object names are displayed and can be selected.
Condition: AND OR
Allows you to specify the AND or OR condition between the criteria fields. These
options are available when you add additional event criteria to the criteria fields.
Selecting an Existing Criteria
You can create a filter by using existing criteria from the predefined criteria list. The filter can be
based on recent criteria, tags, or existing filters.
 Show only recent criteria: Select a search criterion from the recent search history. The search
history displays a maximum of 15 search expressions. Select the criteria, click Show only recent
criteria, and then click Add.
 Show only tags: You can search events that have a particular tag. Click Show only tags to list
the tags in the system. Select the tags, and then click Add.
 Show only filters: You can reuse existing filters to perform a new search. Click Show only
filters to list the existing filters. Select the filter on which you want to perform the search, and
then click Add.
You can combine multiple criteria, tags, or filters by using the And or Or condition. After adding the
criteria, you can test the filter by clicking Test Filter.
Configuring Filters
41
Creating a Filter
You can create filters either by building a new filter criteria or by saving a search query as a filter.
While creating a filter, you can specify whether you want to share a filter with other users. You must
have the Share Search Filters permission to share filters with everyone or with users in the same
role as yours. If you are a user in the administrator role, you can share filters with users in a different
role.
In Sentinel Scalable Data Manager, you can create a filter only by saving the search query as a filter.
For more information, see “Saving a Search Query as a Filter” on page 27.
 “Creating a Filter by Using the Build Criteria Dialog” on page 42
 “Creating a Filter by Using a Search Query” on page 43
Creating a Filter by Using the Build Criteria Dialog
1 From Sentinel Main, in the navigation panel, click Filters > Create a filter.
2 Select one of the following methods to create a filter criteria:
 To build the filter criteria by selecting parameters, make sure that Structured is selected,
select the parameters, then continue with Step 3.
For information on these parameters, see Table 4-1, “Build Criteria Dialog Box Elements,”
on page 40.
 To manually specify the filter criteria rather than selecting the listed parameters, select Freeform. In the Criteria field, specify the filter criteria, then continue with Step 3.
For information about the syntax for the criteria, see Appendix A, “Search Query Syntax,” on
page 161.
3 (Conditional) If you do not want to include Sentinel internal events in the search, select Exclude
system events.
4 Click Search to search events according to the specified filter criteria.
By default, the search is performed on events that were generated within the last 1 hour.
5 Review the search results to verify that the filter is retrieving the expected events.
6 (Optional) You can modify the search query by selecting one or more event field values from the
search results, or you can click Edit search filter, then make necessary changes.
7 When you are satisfied with the search results, click
, then click Save as Filter.
8 Specify a name for the filter and an optional description.
9 In the Sharing drop-down list, select one of the following options to specify the access for this
filter:
 Private: Allows you to make this filter private. Other users cannot view or access this filter.
 Public: Allows you to share this filter with all users.
 Users in same role: Allows you to share this filter with users who have the same role as
yours.
 Users in selected roles: Allows you to share this filter with users in specific roles. If you
select this option, a blank field is displayed where you can specify the roles. As you type the
role name, a list of roles is displayed.
Select one or more roles.
42
Configuring Filters
NOTE: This option is available only for users in the administrator role or users with the
Share search filters permission.
10 Click Save.
Creating a Filter by Using a Search Query
You can save a search query as a filter and use this filter to perform searches when required rather
than specifying the search query again. For more information about creating a filter by using a search
query, see “Saving a Search Query as a Filter” on page 27.
Sample Filters
This section lists a few examples on how you can create filters.
 “View Events of Severity 3 to 5 from a System in China” on page 43
 “Determine if User “Bob Smith” Tried to Log In after His Account was Disabled” on page 43
 “View Events from Two Subnets and Share the Filter with Network Administrators” on page 44
 “Find all Events that Include the Words “database” and “service,” and exclude “test”” on page 44
View Events of Severity 3 to 5 from a System in China
 Click Build Criteria > Event fields, select SourceHostCountry.
 The name should match any string that contains the name “China.” For example, “ChinaBeijing.”
Specify china* in the Value field.
 The severity of the events must be 3 to 5:
 In Event fields, select Severity.
 In the Values that range from field, specify 3 TO 5.
NOTE: If you are familiar with the search query syntax, you can directly specify the query in the
Criteria field as follows:
(rv29:china*) AND (sev:[3 TO 5])
For more information on the search query syntax, see Appendix A, “Search Query Syntax,” on
page 161.
Click Search to view events that match the specified criteria.
Determine if User “Bob Smith” Tried to Log In after His
Account was Disabled
 Click Build Criteria > Event fields, select the following:
 InitiatorUserName
 TargetUserName
 EffectiveUserName
 Select the OR condition.
Configuring Filters
43
 Specify "Bob Smith" in the Value field.
 To determine if the user has logged in, or tried to log in, select Taxonomy in Criteria fields.
NOTE: You can also select the appropriate event fields if you are familiar with the values to be
specified for the event fields. Taxonomy is a classification of events where events of similar type
are grouped together. It helps you search events based on the taxonomy classification rather
than you specifying the specific event names and their values.
 In the Field details, select the following:
 From the Class drop-down list, select User Session Events.
 From the Identifier drop-down list, select Create.
 For Outcome, select Success, then select Failure.
NOTE: If you are familiar with the search query syntax, you can directly specify the query in the
Criteria field as follows:
(xdasclass:2 AND xdasid:0 AND (xdasoutcome:0 OR xdasoutcome:1)) AND (iufname:"Bob
Smith")
For more information on taxonomy, see Sentinel Taxonomy.
Click Search to view the events that match the specified criteria.
View Events from Two Subnets and Share the Filter with
Network Administrators
 Select subnets:
 Click Build Criteria > Event fields, select SourceIP.
 In Field details > Value, specify the subnet, for example, 172.17.0.0/16.
 Repeat the above two steps to specify another subnet.
 The events must be from either of the subnets. Therefore, select OR as the condition.
 Click Search to view events that match the specified criteria.
 The filter must be shared with network administrators:
 In the search results panel, click
, then click Save as new filter.
 Specify an intuitive name and an optional description.
 From the drop-down list, select Share with roles, then select Network Administrator.
 Click Save.
Find all Events that Include the Words “database” and
“service,” and exclude “test”
 Click Build Criteria > Criteria fields, select All data.
 You want to find events that include words “database” and “service,” and exclude “test.”
Therefore, in Field details, specify the following:
 In the All of these words field, specify database service.
 In the Exclude these words field, specify test.
44
Configuring Filters
NOTE: If you are familiar with the search query syntax, you can directly specify the query in the
Criteria field as follows:
_data:(database AND service) NOT _data:test
The _data field allows you to search for words that might appear in any event field. For more
information, see “The Default Search Field” in Appendix A, “Search Query Syntax,” on page 161.
Click Search to view the events that match the specified criteria.
Viewing Events by Using Filters
You can use filters to view events either by selecting the desired filter in the Filters panel or by using
the Filter
icon in the search results panel. For more information, see Chapter 3, “Searching
Events,” on page 21.
Managing Filters
You can edit and delete only the filters that you created. The default filters and the filters that other
users have shared with you cannot be edited or deleted.
Configuring Filters
45
46
Configuring Filters
5
Correlating Event Data
5
A single event viewed in the system might not necessarily draw your attention. But when you
correlate a set of similar or comparable events in a given period, you might identify a potential
problem. Sentinel helps you correlate events by using the rules you create and deploy in the
Correlation Engine, so you can take appropriate action to mitigate any problems.
 “Overview” on page 47
 “Understanding the Correlation Interface” on page 51
 “Creating Correlation Rules” on page 55
 “Associating Actions to a Rule” on page 64
 “Testing a Correlation Rule” on page 65
 “Sample Correlation Rules” on page 66
 “Deploying Rules in the Correlation Engine” on page 67
 “Viewing Correlated Events” on page 68
 “Customizing Correlated Event” on page 68
 “Managing Correlation Rules” on page 69
 “Managing the Correlation Engine” on page 70
Overview
Correlation adds intelligence to security event management by automating analysis of the incoming
event stream to find patterns of interest. Correlation allows you to define rules that identify critical
threats and complex attack patterns so that you can prioritize events and initiate effective incident
management and response.
 “How Correlation Works” on page 48
 “Correlation Rules” on page 48
 “Correlation Engine” on page 50
Correlating Event Data
47
How Correlation Works
The following illustration shows how Correlation works:
Figure 5-1 Correlation Workflow
Sample actions...
Message Bus
Monitoring
events
4
Send
e-mail
Actions are
executed
Rules
fire
1
Create rule
2
Associate action
Log
to file
Trace
Initiator IP
5
3
Correlation events
are generated
Deploy in
Correlation Engine
1. A user creates a Correlation rule.
2. The user associates one or more actions to the Correlation rule.
3. The user deploys the rule in the Correlation Engine.
4. The Correlation Engine processes events from the real-time event stream to determine whether
they should trigger any of the active rules to fire the associated actions.
5. If events match the rule criteria, correlation events are generated and associated actions are
executed.
Sentinel’s correlation is near real-time and depends on the time stamp of the individual events. When
an event arrives at the Correlation Engine, the engine reorders the events in a buffer based on the
event time stamp (dt) field so that the events are evaluated in time order. This is done partly to
evaluate sequence rules in which the rule only fires if events occur in a specific order.
The buffer is 30 seconds long, so if the event time stamp (dt) is more than 30 seconds older than the
Collector Manager time stamp, the event is not evaluated. To minimize false time differences, you
must use an NTP (Network Time Protocol) server to synchronize the time settings on the relevant
machines. For more information, see “Configuring Time” in the NetIQ Sentinel Installation and
Configuration Guide.
Correlation Rules
Correlation rules define a pattern of events that should trigger a rule. You can create rules that range
from simple to extremely complex. For example:
 High severity event from a finance server
 High severity event from any server brought online in the past 10 days
 Five failed logins in 2 minutes
48
Correlating Event Data
 Five failed logins to the same server from the same user name in 2 minutes
 Intrusion detection event targeting a server, followed by an attempted login to root originating
from the same server within 60 seconds
 A service stop event is not followed by the service start within 5 minutes
A rule can have one or more subrules:
 “Simple Rule” on page 49
 “Sequence Rule” on page 49
 “Composite Rule” on page 49
 “Sequence Timeout Rule” on page 50
 “Free-form Rule” on page 50
 “Combining Different Rule Types” on page 50
Simple Rule
The simple rule has just one subrule. You can specify additional criteria if you want the rule to fire
when all or any of the specified criteria are met. You can also specify the number of times the event
should occur for the rule to fire. For example, to monitor a situation with five failed logins within a
minute on a finance server.
For information on creating a simple rule, see “Creating a Simple Rule” on page 57.
Sequence Rule
The Sequence rule has two or more subrules that fire in a sequence. You can use a Sequence rule
when you want the rule to fire if its subrules meet the specified criteria in the specified sequence
within the defined time frame. For example, to monitor a situation where there has been a successful
login after three failed logins by the same user within five minutes.
The Sequence rule can also fire even when a single event can satisfy multiple or all of the subrules
within the time frame and the times at which they were satisfied are in ascending order. For
information about creating a Sequence rule, see “Creating a Sequence Rule” on page 58.
For more information on Sequence rule expression syntax, see “Sequence Operation” on page 180.
Composite Rule
The Composite rule has two or more subrules that fire according to the criteria you define. There are
two types of Composite rules:
 Composite (AND): Indicates that all subrules must fire.
 Composite (OR): Indicates that a specified number of subrules must fire.
For example, you can create a Composite (AND) rule to monitor a situation where there have been
failed logins on a finance server and a database server within two minutes.
Similarly, for example, you can create a Composite (OR) rule, if you have three or more subrules and
you want the rule to fire if a maximum of two subrules meet the specified criteria.
The Composite rule can also fire even when a single event can satisfy multiple or all of the subrules.
For information on creating a Composite rule, see “Creating a Composite Rule” on page 59.
For information about Composite rule expression syntax, see “Gate Operation” on page 180.
Correlating Event Data
49
Sequence Timeout Rule
The Sequence Timeout rule fires when an event that matches the first subrule is not followed by an
event that matches the second subrule in a specified time frame.
For example, you can create a Sequence Timeout rule to detect a scenario where the server stopped
but did not start again within an interval of 5 minutes.
Similarly, you can also create a Sequence Timeout rule to detect a scenario where a firewall security
update started but was not followed by successful installation of updates within the specified time
interval.
For information about creating a Sequence Timeout rule, see “Creating a Sequence Timeout Rule” on
page 60.
For information about Sequence rule expression syntax, see “Sequence Timeout Operation” on
page 181.
Free-form Rule
If you are familiar with the rule expression syntax, you can create correlation rules by manually
specifying the rule expression. You can use free-form rules to create complex rules by using
additional operators such as Window, Intersection, and Union.
For information about the rule expression syntax, see Appendix B, “Correlation Rule Expression
Syntax,” on page 173.
For information about creating a free-form rule, see “Creating a Free-Form Rule” on page 61.
Combining Different Rule Types
You can create correlation rules with a combination of different rule types to detect complex
scenarios.You can create rule combinations such as a Sequence rule with a Composite rule or a
Sequence Timeout rule with a Sequence rule, and so on. You can create a combination of different
rule types either by using the free-form view or by using a combination of structured view and the
free-form view.
Consider a scenario where you want a correlation rule to fire when a system scan (Event A) detects a
virus (Event B), but is not followed by a quarantine (Event C) in 30 seconds. The overall timeframe for
this complete activity is 1 hour. For this scenario, you can create a combination of Sequence and
Sequence Timeout rules.
For information about combining different rule types, see “Creating a Combination Rule” on page 63.
Correlation Engine
To monitor events according to the correlation rules, you must deploy the rules in the correlation
engine. When an event occurs that satisfies the rule criteria, the correlation engine generates a
correlation event describing the pattern.
NOTE: Events that are sent directly to the event store or dropped by event routing rules are not
processed by the correlation engine.
50
Correlating Event Data
The Sentinel correlation engine provides specific advantages over database-centric correlation
engines.
 By relying on in-memory processing rather than database inserts and reads, the correlation
engine performs during high steady-state volumes as well as during event spikes when under
attack, which is the time when correlation performance is most critical.
 The correlation volume does not slow down other system components, so the user interface
remains responsive, especially with high event volumes.
 The correlation engine can add events to incidents after an incident has been created.
 You can deploy multiple correlation engines, each on its own server, without the need to replicate
configurations or add databases. The correlation engine is built with a pluggable framework that
allows the addition of new correlation engines. Independent scaling of components provides
cost-effective scalability and performance.
NOTE: You cannot install more than one correlation engine on a single system. You can install
additional correlation engines on remote systems, and then connect them to the Sentinel server.
For more information about installing the Correlation Engine, see “Installing Collector Managers
and Correlation Engines” in NetIQ Sentinel Installation and Configuration Guide > Installing
Sentinel.
Understanding the Correlation Interface
The Correlation interface includes the following:
 “Correlation Panel” on page 51
 “Correlation Rule Builder” on page 52
Correlation Panel
The Correlation panel lists the rules and the Correlation Engines installed on your system.
The Correlation panel includes the following options:
 “Rules” on page 51
 “Engines” on page 52
Rules
The Rules section lists all the available rules in the system. The icon next to the rule indicates the
status of the rule:
 Enabled
: The rule is deployed in the Correlation Engine and is enabled to process events.
 Disabled : The rule is deployed in the Correlation Engine, but the rule is disabled and is not
processing events.
 No icon: The rule is not deployed in the Correlation Engine.
To view the details of any rule, click the rule. When you select or click any rule, the following icons are
displayed:
 Search : Searches for the events that meet the rule criteria. The events are displayed in the
search results panel.
Correlating Event Data
51
 Edit
: Allows you to edit the rule.
 Delete : Allows you to delete the rule.
Engines
The Engines section lists the Correlation Engines installed in the system. The icon next to the
Correlation Engine indicates the status of the Correlation Engine.
 Start
: The Correlation Engine is started and is processing the deployed correlation rules.
 Stop : The Correlation Engine is stopped. When the Correlation Engine is stopped, all inmemory data is preserved and no new correlation events are generated.
 Offline
: The remote Correlation Engine is off.
Click any engine to view the details, such as the rules deployed in this engine and information about
the engine. For more information, see “Using the Correlation Engine Dashboard” on page 70.
Correlation Rule Builder
The Correlation Rule Builder helps you to create correlation rules and includes the following:
 “Command Buttons” on page 52
 “Rule Builder Elements” on page 52
 “Subrule Window” on page 53
 “Expression Builder” on page 54
 “Actions Panel” on page 55
Command Buttons
The following command buttons are available:
 Subrule: Adds a subrule window in the rule builder. You can add additional subrules to create a
Sequence or Composite rule.
 View Rule Expression/Hide Rule Expression: Displays or hides the expression of the rule.
This is a toggle button.
 Save Rule: Saves the rule in the Sentinel database.
 Save As: Allows you to save the rule with another name.
 Test Rule: Tests the rule against the events in your system. For more information, see “Testing a
Correlation Rule” on page 65.
Rule Builder Elements
Table 5-1 Common Rule Builder Elements
52
Element
Description
Action
edit
Allows you to edit the rule name
Click the edit link.
Correlating Event Data
Element
Description
Action
Rule type
Lists the types of rules:
Select an appropriate rule type for the rule
you want to create.
 Sequence
 Composite (AND)
 Composite (OR)
This list is displayed only if there is more than
one subrule.
Count
This field is enabled only for Composite (OR)
rules and if there are more than 2 subrules.
Specify a number or use the up/down arrow
keys to select a number.
It indicates the maximum number of subrules
NOTE: The value should always be less
that should meet the specified criteria for the
than the number of subrules in the rule.
rule to fire. For example, if you have 5 subrules
and you specify the Count as 3, the rule fires if
one, two, or three subrules meet the specified
criteria.
Group by
Lists the attributes you can use to group the
correlation events.
The Group by list is enabled if there are two or
more subrules.
Time frame
Hr: Min: Sec
Indicates the time within which the specified
criteria in the subrules should be satisfied for
the rule to fire.
Select one or more attributes. For example,
to group events by username, select
initusername.
Specify the time in hours, minutes, or
seconds.
Subrule Window
The subrule window allows you to specify the expressions (criteria) for the rule and lists the various
expressions that you have created for a subrule.
Table 5-2 Subrule Window Elements
Element
Description
Toggle icons
Toggles between a structured rule and a free- Click the icon to toggle to the freeform rule.
form or structured view.
Group by
Lists the attributes you can use to group the
correlation events.
The Group by list is enabled only if the Count
is greater than 1.
Count
Close icon
Action
Select one or more attributes. For
example, to group events by
username, select initusername.
Indicates the number of times the expressions Specify a number or use the up/down
must meet the specified criteria for the
arrow keys to select the number.
subrule/rule to fire.
Closes the subrule window.
Click the icon to close the subrule
window.
Correlating Event Data
53
Element
Description
Action
Time frame
Indicates the time within which the specified
criteria in the subrule should be satisfied for
the rule to fire.
Specify the time in hours, minutes, or
seconds. For example, if you want
the rule to fire within 2 minutes,
specify 2 in the Min field.
Determines whether the subrule should fire
when all or any of the conditions in the
expression are met, according to the
selection.
Select one of the conditions.
Hr: Min: Sec
Condition: AND OR
These option buttons are enabled only if there
are two or more expressions in a subrule.
Create a new
expression
Delete expression
Allows you to create a new expression.
Displays the Expression Builder. For more
information, see “Expression Builder” on
page 54.
Deletes the expression.
Click the link to create a new
expression.
Click the icon to delete the
expression.
Expression Builder
The Expression Builder allows you to select various parameters required to create an expression for
the rule. The various parameters include Attributes, Operator, and Value. These parameters are
interdependent, and changing one of them affects the validity of others.
Attribute: Displays a categorized list of possible event fields that can be used to create a Correlation
rule. Each category can be expanded to display the set of fields in that category. If you know the
name of the field you want, specify the name in the Search field. The event category list adjusts to
present only matching fields.
For information on the various event fields, click Tips located at the top right corner.
Operator: Lists the various operators. The list varies depending on the selected attribute type. For
example:
 For all attributes, the =, <, >, !=, <=, >=, inlist, isnull, not inlist, and not isnull operators are
available.
 For string attributes, the match regex operator is available.
 For IP attributes, the match subnet operator is available.
 For tag attributes, the contains operator is available.
For more information on using the operators, see “Filter Operation” in Appendix B, “Correlation Rule
Expression Syntax,” on page 173.
Value: This field varies, depending on the attribute and operator. For example:
 For the isnull and not isnull operators, no value can be chosen.
 For the inlist and not inlist operators, the available Dynamic Lists are displayed. You can also
create a new empty Dynamic List, if necessary. Once the Dynamic List has been created, click
View to add list items. For more information about Dynamic Lists, see “Configuring Dynamic
Lists” on page 99.
 For the Severity attribute, the severity list is displayed.
54
Correlating Event Data
 For date attributes, a date-time calendar is displayed.
 For xdas taxonomy attributes, the taxonomy builder is displayed.
 For numeric attributes, only numbers are accepted.
 For the Sensor type attribute, the list of sensor types is displayed.
 For the Tags (rv145) attribute, the list of available tags is displayed.
 For Collector fields, a list of Collectors is displayed.
You can also select one or more event attributes as the value by using the Show Attributes option.
Actions Panel
The Actions panel lists the actions associated with the rule, allows you to associate actions to the
rule, and allows you to define when the action should execute.
The Actions panel includes the following icons:
 Action execution criteria
: Allows you to specify when the rule should initiate the action.
When you click this icon, the Action Execution Criteria dialog box is displayed:
You can select one of the following options:
 Perform actions every time the rule fires: The action executes each time the rule criteria
are met.
 Perform actions at most every: The action executes at most every specified time interval.
By default, this option is selected and the time interval is set to 1 hour. This is to ensure that
the rule does not fire continually and over utilize resources.
 Add action
: Allows you to associate actions to the rule. When you click this icon, a list of
actions is displayed. Select one or more actions that you want to associate to the rule.
For more information on associating actions to a rule, see “Associating Actions to a Rule” on page 64.
Creating Correlation Rules
The procedure to create various types of Correlation rules is the same for all rule types, except for a
few steps that are specific to each rule type. Events are evaluated by rules in the specified order until
a match is made, so you should order subrules accordingly. More narrowly defined subrules and
more important subrules should be placed at the beginning of the list. When creating correlation
rules, you can also define what you want to see in the correlated event.
NOTE: You must have the Manage correlation engine and rules permission to access the Correlation
interface.
 “Understanding the Correlated Event” on page 56
 “Creating a Simple Rule” on page 57
 “Creating a Sequence Rule” on page 58
 “Creating a Composite Rule” on page 59
 “Creating a Sequence Timeout Rule” on page 60
 “Creating a Free-Form Rule” on page 61
 “Creating a Combination Rule” on page 63
 “Creating Correlation Rules From Search Results” on page 64
Correlating Event Data
55
Understanding the Correlated Event
By default, correlated events display the event name and message as the rule name and description
respectively.
The correlated event field values depend on the number of events that triggered the correlated event
and whether any of the event fields are grouped.
 In case of a single event triggering the correlated event, all the event field values are copied to
the correlated event. If one or more event fields are grouped, only the grouped event fields are
copied to the correlated event.
 In case of multiple events triggering a correlated event, the grouped event field values are
copied to the correlated event. If none of the event fields are grouped, no values are copied to
the correlated event.
The following table describes the default event fields in a correlated event. You can also customize
the event field values to suit your requirements. For more information, see “Customizing Correlated
Event” on page 68.
Table 5-3 Default Correlated Event Fields
56
Correlation Event Field
ID
Sample Value
Description
EventName
evt
LoginUser
The name of the correlation
rule.
EventTime
dt
2014-02-10T05:21:29.047Z
The time when the last trigger
event was fired.
Message
msg
Rule triggered for every
successful login
The description in the
correlation rule.
ObserverCategory
rv32
SIEM
For a correlated event, this
event field is always set to
SIEM.
ObserverServiceComponent
rv150
SessionServices
This value is same as that of
the last trigger event.
ObserverTZ
estz
Asia/Kolkata
The time zone in which the
correlation engine is located.
ObserverType
st
C
For a correlated event, the
event field is always set to C.
SentinelProcessingComponent rt2
LoginUser
The correlation rule name.
SentinelProcessingComponent rv123
ID
CC72FBA4-711D-1031-8046005056A56C5B
This is the ID of the correlation
rule. The correlation rule ID
remains the same even though
the correlation rule name
changes.
SentinelServiceComponentNa
me
sres
LoginUser
It is the name of the correlation
rule.
SentinelServiceName
res
Correlation
For a correlated event, this
event field is always set to
Correlation.
Correlating Event Data
Correlation Event Field
ID
Sample Value
Description
Severity
sev
4
For a correlated event, this
event field is always set to 4.
XDASClass
xdasclass
2
This value is same as that of
the last trigger event.
XDASDetail
xdasdetail
0
This value is same as that of
the last trigger event.
XDASIdentifier
xdasid
0
This value is same as that of
the last trigger event.
XDASOutcome
xdasoutco
me
0
This value is same as that of
the last trigger event.
XDASOutcomeName
xdasoutco
mename
XDAS_OUT_SUCCESS
This value is same as that of
the last trigger event.
XDASProvider
xdasprov
0
This value is same as that of
the last trigger event.
XDASRegistry
xdasreg
0
This value is same as that of
the last trigger event.
XDASTaxonomyName
xdastaxna
me
XDAS_AE_CREATE_SESSIO
N
This value is same as that of
the last trigger event.
For more information on correlated event fields, click Tips in the Sentinel Main interface. For more
information on the event taxonomy and event fields, see Sentinel Taxonomy.
NOTE: By default, Sentinel correlates the correlated events received from remote Sentinel servers. If
you do not want the correlation rules to consider remote correlated events, set the following property
in the /etc/opt/novell/sentinel/config/server.xml file to false and restart the Sentinel server:
<property name="correlateRemoteCorrelationEvents">false</property>
Creating a Simple Rule
A simple rule has just one subrule. You can specify additional criteria if you want the rule to fire when
all or any of the specified criteria are met. You can also specify the number of times the event should
occur for the rule to fire.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation and click the Create a correlation rule icon.
3 In the subrule window, click Create a new expression.
The Expression Builder is displayed. For more information, see “Expression Builder” on page 54.
4 Select the criteria for the subrule, then click OK.
The specified criteria are displayed in the subrule window.
Correlating Event Data
57
5 (Conditional) Specify additional expressions as necessary:
5a Repeat Step 3 and Step 4.
5b Select either of the following conditions:
 AND: Use this condition if you want the subrule to fire when the conditions in all of the
expressions are met.
 OR: Use this condition if you want the subrule to fire when the condition in either of the
expressions is met.
5c (Conditional) You can group events based on the distinct values of event fields or group
events by same values of event fields. Select the Group by drop-down list, drag and drop
the desired event fields in the Group By Fields or Distinct Fields list depending on how you
want to group the events.
5d In the Count field, specify the number of times the expressions must meet the specified for
the rule to fire. If the count is greater than 1, the Hr, Min, and Sec fields are enabled.
5e Specify the time frame within which the subrule should fire.
5f (Conditional) If the count is greater than one and if there are any grouped event fields, by
default only the grouped event field values are copied to the correlated event. If you want to
copy all the event field values from the last event that triggered the correlated event,
deselect Copy only group by fields from the trigger events.
6 (Optional) To associate one or more actions to the rule, click
in the Actions panel.
For more information on associating actions, see “Associating Actions to a Rule” on page 64.
7 (Optional) To test whether the rule works as expected, click Test Rule.
For more information on testing the rule, see “Testing a Correlation Rule” on page 65.
8 Click Save As.
9 Specify a name for the rule and an optional description, then click OK.
10 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating a Sequence Rule
A Sequence rule has two or more subrules that fire in sequence. You can use a Sequence rule when
you want the rule to fire if its subrules meet the specified criteria in the specified sequence within the
defined time frame. Therefore, you need to order the subrules in the required sequence.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation and click the Create a correlation rule icon.
3 In the Subrule window, click Create a new expression.
The Expression Builder is displayed. For more information, see “Expression Builder” on page 54.
4 Select the criteria for the subrule, then click OK.
The specified criteria are displayed in the subrule window.
5 (Conditional) Specify additional expressions as necessary:
5a Select either of the following conditions:
 AND: Use this condition if you want the subrule to fire when the conditions in all of the
expressions are met.
 OR: Use this condition if you want the subrule to fire when the condition in either of the
expressions is met.
58
Correlating Event Data
5b (Conditional) You can group events based on the distinct values of event fields or group
events by same values of event fields. Select the Group by drop-down list, drag and drop
the desired event fields in the Group By Fields or Distinct Fields list depending on how you
want to group the events.
5c In the Count field, specify the number of times the expressions must meet the specified
criteria for the rule to fire. If the Count is greater than 1, the Hr, Min, and Sec fields are
enabled.
5d Specify the time frame within which the subrule should fire.
5e (Conditional) If the count is greater than one and if there are any grouped event fields, by
default only the grouped event field values are copied to the correlated event. If you want to
copy all the event field values from the last event that triggered the correlated event,
deselect Copy only group by fields from the trigger events.
6 To add additional subrules, click Add Subrule, then repeat Step 3 through Step 5 to specify the
subrule criteria.
7 In the rule type drop-down list, select Sequence rule.
8 Specify the time frame within which the rule should fire.
9 (Optional) To associate one or more actions to the rule, click
in the Actions panel.
For more information on associating actions, see “Associating Actions to a Rule” on page 64.
10 (Optional) To test whether the rule is works as expected, click Test Rule.
For more information on testing the rule, see “Testing a Correlation Rule” on page 65.
11 Click Save As.
12 Specify a name for the rule and an optional description, then click Save.
13 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating a Composite Rule
A Composite rule has two or more subrules that fire according to the criteria you define.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation and click the Create a correlation rule icon.
3 In the Subrule window, click Create a new expression.
The Expression Builder displayed. For more information, see “Expression Builder” on page 54.
4 Select the criteria for the rule, then click OK.
The specified criteria are displayed in the subrule window.
5 (Conditional) Specify additional expressions as necessary:
5a Select either of the following conditions:
 AND: Use this condition if you want the subrule to fire when the conditions in all of the
expressions are met.
 OR: Use this condition if you want the subrule to fire when the condition in either of the
expressions is met.
5b (Conditional) You can group events based on the distinct values of event fields or group
events by same values of event fields. Select the Group by drop-down list, drag and drop
the desired event fields in the Group By Fields or Distinct Fields list depending on how you
want to group the events.
Correlating Event Data
59
5c In the Count field, specify the number of times the expressions must meet the specified
criteria for the rule to fire. If the Count is greater than 1, the Hr, Min, and Sec fields are
enabled.
5d Specify the time frame within which the subrule should fire.
5e (Conditional) If the count is greater than one and if there are any grouped event fields, by
default only the grouped event field values are copied to the correlated event. If you want to
copy all the event field values from the last event that triggered the correlated event,
deselect Copy only group by fields from the trigger events.
6 Complete Step 1 through Step 5 in “Creating a Simple Rule” on page 57.
7 To add additional subrules, click Add Subrule, then repeat Step 3 through Step 5 to specify the
subrule criteria.
8 In the rule type drop-down list, select Composite rule.
9 Select one of the following:
 Composite Rule (AND): The rule fires if all the subrules meet the specified criteria within
the defined time frame.
 Composite Rule (OR): The rule fires if any of the subrules meets the specified criteria
within the defined time frame.
10 (Conditional) If you selected Composite Rule (OR), use the Count field to specify the number of
subrules that should meet the specified criteria.
The value in the Count field must be less than the number of subrules. For example, if there are
5 subrules and you specify the count as 3, the rule fires if 3 or more subrules meet the specified
criteria.
11 Specify the time frame within which the rule should fire.
12 (Optional) To associate one or more actions to the rule, click
in the Actions panel.
For more information on associating actions, see “Associating Actions to a Rule” on page 64.
13 (Optional) To test whether the rule is works as expected, click Test Rule.
For more information on testing the rule, see “Testing a Correlation Rule” on page 65.
14 Click Save As.
15 Specify an intuitive name for the rule and an optional description, then click Save.
16 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating a Sequence Timeout Rule
A Sequence Timeout rule fires when events that match the first subrule are not followed by events
that match the second subrule in a specified time frame. For example, you can create a Sequence
Timeout rule to detect a scenario where the server stopped but did not start again within an interval of
5 minutes. Similarly, you can also create a Sequence Timeout rule to detect a scenario where a
firewall security update started but was not followed by successful installation of updates within the
specified time interval. A Sequence Timeout rule has two subrules. You must order the subrules in the
required sequence.
To create a Sequence Timeout rule, perform the following the steps:
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation and click the Create a correlation rule icon.
3 In the subrule window, click Create a new expression.
60
Correlating Event Data
For more information about using the Expression Builder, see “Expression Builder” on page 54.
4 Select the criteria for the subrule, then click OK.
5 (Conditional) Specify additional criteria as necessary for the subrule:
5a Select either of the following conditions:
 AND: Use this condition if you want the subrule to fire when the conditions in all of the
expressions are met.
 OR: Use this condition if you want the subrule to fire when the condition in either of the
expressions is met.
5b (Conditional) You can group events based on the distinct values of event fields or group
events by the same values of event fields. Select the Group by drop-down list, and drag and
drop the desired event fields in the Group By Fields or Distinct Fields list depending on
how you want to group the events.
5c In the Count field, specify the number of times the expressions must meet the specified
criteria for the rule to fire. If Count is greater than 1, the Hr, Min, and Sec fields are enabled.
5d Specify the time frame within which the subrule should fire.
5e (Conditional) If the count is greater than one and if there are any grouped event fields, by
default, only the grouped event field values are copied to the correlated event. If you want to
copy all the event field values from the last event that triggered the correlated event,
deselect Copy only group by fields from the trigger events.
6 To add the second subrule, click Add Subrule, then repeat Step 2 through Step 4 to specify the
criteria for the second subrule.
7 In the Rule Type drop-down list, select Sequence Timeout.
8 Specify the time frame after which the rule should fire if the second subrule conditions are not
met.
9 (Optional) To associate one or more actions to the rule, click
in the Actions panel.
For more information about associating actions, see “Associating Actions to a Rule” on page 64.
10 (Optional) To test whether the rule works as expected, click Test Rule.
For more information about testing the rule, see “Testing a Correlation Rule” on page 65.
11 Click Save As.
12 Specify a name for the rule and an optional description, then click Save.
13 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating a Free-Form Rule
If you are familiar with the rule expression syntax, you can create correlation rules by manually
specifying the rule expression. You can use free-form rules to create complex rules by using
additional operators such as Window, Intersection, and Union.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation and then click Create a correlation rule icon.
Correlating Event Data
61
3 (Conditional) Perform Step 2a to create a free-form rule using a single subrule otherwise, follow
Step 2b if you want to create a free-form rule using multiple subrules:
3a Using single subrule:
3a1 Click Create.
3a2 In the subrule window, click
to switch to the free-form view.
3a3 Specify the criteria for the rule.
3a4 (Optional) Click
to view the rule in a structured format.
Free-form expressions that include the Window operator or a combination of AND, OR,
Sequence and Sequence Timeout operators are not supported in the structured view.
3b Using multiple subrules:
3b1 Click Create.
3b2 In the Subrule window, click Create a new expression.
The Expression Builder is displayed. For more information, see “Expression Builder” on
page 54.
3b3 Select the criteria for the rule expression.
3b4 (Conditional) Specify additional expressions as necessary:
3b4a Select either of the following conditions:
 AND: Use this condition if you want the subrule to fire when the conditions in
all of the expressions are met.
 OR: Use this condition if you want the subrule to fire when the condition in
either of the expressions is met.
3b4b (Conditional) You can group events based on the distinct values of event fields or
group events by same values of event fields. Select the Group by drop-down list,
drag and drop the desired event fields in the Group By Fields or Distinct Fields
list depending on how you want to group the events.
3b4c In the Count field, specify the number of times the expressions must meet the
specified criteria for the rule to fire. If the Count is greater than 1, the Hr, Min, and
Sec fields are enabled.
3b4d Specify the time frame within which the subrule should fire.
3b4e (Conditional) If the count is greater than one and if there are any grouped event
fields, by default only the grouped event field values are copied to the correlated
event. If you want to copy all the event field values from the last event that
triggered the correlated event, deselect Copy only group by fields from the
trigger events.
3b5 Follow Step 2b1 through Step 2b4 to create multiple subrules in the structured format.
3b6 Click Edit in Free-form view to view the combined free-form expression syntax of all
the subrules in the structured format.
3b7 Edit the free-form expression syntax further to suit your requirements.
NOTE: As you type the rule expression, the Free-form editor validates the rule expression
syntax and indicates errors if the syntax is wrong.
For more information on the rule expression syntax, see Appendix B, “Correlation Rule
Expression Syntax,” on page 173.
4 (Optional) To associate one or more actions to the rule, click
62
Correlating Event Data
in the Actions panel.
For more information on associating actions, see “Associating Actions to a Rule” on page 64.
5 (Optional) To test whether the rule works as expected, click Test Rule.
For more information on testing the rule, see “Testing a Correlation Rule” on page 65.
6 Click Save As.
7 Specify an intuitive name for the rule and an optional description, then click Save.
8 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating a Combination Rule
You can create correlation rules with a combination of different rule types to detect complex
scenarios. For example, a Sequence rule with a Composite rule or a Sequence Timeout rule with a
Sequence rule, and so on. You can create a combination of different rule types either by using the
free-form view or by using a combination of the structured view and the free-form view.
Consider a scenario where you want a correlation rule to fire when a system scan (Event A) detects a
virus (Event B), but is not followed by a quarantine (Event C) in 30 seconds. The overall timeframe for
the sequence of events is 1 hour. For this scenario, you can create a combination of Sequence and
Sequence Timeout rules as follows:
Event A followed by (Event B not followed by Event C), which can also be represented as Event A ->
(Event B ->x Event C),
To create a combination of different rule types for the above scenario:
1 Create a Sequence Timeout rule for (Event B ->x Event C) in the structured view and specify the
time frame as 30 seconds.
2 Click Edit in Free-form View to combine the two subrules (Event B ->x Event C) into a single
subrule in the free-form view.
3 (Conditional) Perform Step 3a if you are familiar with the rule expression syntax. Otherwise,
perform Step 3b.
3a Using free-form expression:
3a1 Edit the free-form rule expression further to add the Sequence operator such that the
final expression is sequence(Event A, sequence_timeout(Event B, Event C, 30), 3600).
3a2 Skip to Step 4.
3b Using a combination of free-form and structured view:
3b1 Click Add Subrule to add a new subrule for Event A.
3b2 Add the rule criteria for Event A.
3b3 Drag the subrule for Event A by the rule header and place it before the free-form
subrule to reorder the subrules.
3b4 Select Sequence from the Rule Type drop-down to create the rule as follows.
Event A -> (Event B ->x Event C)
3b5 Specify the overall time frame as 1 hour.
4 (Optional) To associate one or more actions to the rule, click
in the Actions panel.
For more information about associating actions, see “Associating Actions to a Rule” on page 64.
5 (Optional) To test whether the rule works as expected, click Test Rule.
For more information about testing the rule, see “Testing a Correlation Rule” on page 65.
Correlating Event Data
63
6 Click Save As.
7 Specify a name for the rule and an optional description, then click Save.
8 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Creating Correlation Rules From Search Results
1 In the search results panel, select the events from which you want to create a Correlation rule.
2 In the Events Operations drop-down list, select one of the following:
 Add to correlation rule: Adds the selected events to an existing rule.
 Create correlation rule: Creates a new rule with the selected events.
3 (Conditional) If you selected create correlation rule, the Correlation Rule Builder is displayed.
The events that you selected to build the rule are displayed below the rule builder. Skip to Step 5.
4 (Conditional) If you selected add to correlation rule, the Add events to an existing rule window is
displayed that lists the rules in the system.
Select a rule, then click OK.
The Correlation Rule Builder is displayed. The events that you selected to build the rule are
displayed below the rule builder.
5 From the event list, drag the attributes that you want to add to the rule to the Subrule window.
6 (Optional) To associate one or more actions to the rule, in the Actions panel, click
.
For more information on associating actions, see “Associating Actions to a Rule” on page 64.
7 (Optional) To test whether the rule is works as expected, click Test Rule.
For more information on testing the rule, see “Testing a Correlation Rule” on page 65.
8 Click Save As.
9 Specify an intuitive name for the rule and an optional description, then click Save.
10 Deploy the rule in the Correlation Engine so that events can be processed according to the rule.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
Associating Actions to a Rule
You can configure one or more actions to a rule. The associated actions are executed when the rule
fires.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation.
3 In the Correlation panel, click any rule to which you want to associate actions, then click
The Correlation Rule Builder is displayed.
4 In the Actions panel, click
to associate one or more actions to the rule.
The list of actions is displayed.
5 Select the actions that you want to associate with the rule, then click OK.
6 Click
64
to define when the action should execute.
Correlating Event Data
.
7 Select one of the following:
 Perform actions every time the rule fires: Sentinel creates a correlated event and
executes the associated action each time the rule fires.
 Perform actions at most every: Sentinel creates a correlated event and executes the
action at most every specified time interval. By default, this option is selected and the time
interval is set to 1 hour. This is to ensure that rule does not fire continually and over utilize
resources. You can also define the maximum number of trigger events to be associated with
the correlated event. For more information, see “Configuring the Number of Trigger Events
to be Associated with a Correlated Event” in the NetIQ Sentinel Administration Guide.
8 Click OK.
9 Click Save Rule.
NOTE: If you modified a deployed rule, you must redeploy the rule in the Correlation Engine for the
changes to take effect. For information on deploying a rule, see “Deploying Rules in the Correlation
Engine” on page 67.
Testing a Correlation Rule
You can determine whether the rule is working as expected by testing a rule on the events that are
already in the system before deploying it to monitor real-time events.
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation.
3 In the Correlation panel, click any rule that you want to test, then click
.
4 Click Test Rule.
5 Specify the time frame during which you want to test the rule.
6 (Optional) Click
to filter events that the rule should process.
7 Click Test Rule.
The test takes some time, depending on the specified criteria. After the test is complete, the test
results are displayed.
The test results display the rule details:
 Status: Indicates whether the test is running, stopped, or completed. The test stops when
the rule has fired at least 20 times during the test process. This ensures that the rule is
working as expected and saves time when there are many events.
 Started at: The date/time when the rule started to fire.
 Finished at: The date/time when the test stopped.
The indicators (dots) indicate when the rule fired. The white dot indicates a single correlation
event. The black dot indicates multiple correlation events generated within a short period of time.
Click the indicator to see the event details.
8 Click the Close icon to close the test results.
Correlating Event Data
65
Sample Correlation Rules
This section provides a few examples on how you can create correlation rules. For more examples,
see Appendix B, “Correlation Rule Expression Syntax,” on page 173.
 “Detecting Critical Events from an Intrusion Detection System” on page 66
 “Detecting a Spreading Attack” on page 66
 “Detecting an Attack that Came from Outside the Firewall” on page 67
Detecting Critical Events from an Intrusion Detection
System
This example identifies critical events from an intrusion detection system and sends an e-mail to the
Administrator.
 Launch the Correlation Rule Builder. In the Correlation panel, click Create.
 In the Subrule window, click Create a new expression.
 Specify that the events must be from an intrusion detection system (IDS):
 In the Expression Builder > Event Fields, select ObserverCategory.
 Ensure that the “=” operator is selected.
 In the Value field, specify IDS, then click OK.
 Identify critical events:
 Add another expression. In the Subrule window, click Create a new expression.
 In the Expression Builder > Event Fields, select Severity.
 Select >= as the operator.
 In the Value field, select 4, then click OK.
 If events are found, send an e-mail to the administrator:
 In the Actions panel, click
to associate the action with the rule.
 Select Send E-mail.
 Click
to update the action execution criteria.
 Select Perform actions everytime the rule fires, then click OK.
 Click Save Rule.
 Deploy the rule in the Correlation Engine.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
 Search events that match the rule criteria.
For more information, see “Viewing Correlated Events” on page 68.
Detecting a Spreading Attack
This example creates a Correlation rule that indicates whether the source of an attack was previously
the destination of an attack (within 15 minutes.) Because this involves comparing a current event set
with a past event set, it uses the window operation.
 In the Subrule window, click
66
Correlating Event Data
to switch to the free-form editor.
 Specify the expression as follows:
filter(e.TaxonomyLevel1="Attack") flow window(w.dip=e.sip,
filter(e.rv51="Attack"), 15m)
 Click Save Rule.
 Deploy the rule in the Correlation Engine.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
 Search events that match the rule criteria.
For more information, see “Viewing Correlated Events” on page 68.
Detecting an Attack that Came from Outside the Firewall
This example creates a Correlation rule that checks whether an intrusion detection system attack
event seen inside your network came through your firewall in the last 10 seconds.
 In the Subrule window, click
to switch to the free-form editor.
 Specify the expression as follows:
filter(e.TaxonomyLevel1="Attack") flow window(w.dip=e.sip,
filter(e.rv32="FW"), 10)
 Click Save Rule.
 Deploy the rule in the Correlation Engine.
For more information, see “Deploying Rules in the Correlation Engine” on page 67.
 Search events that match the rule criteria.
For more information, see “Viewing Correlated Events” on page 68.
Deploying Rules in the Correlation Engine
You can deploy the Correlation rules either from the rule dashboard or from the Correlation Engine
dashboard.
To deploy rules from the Correlation Engine dashboard:
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation.
3 In the Correlation panel, select the rule that you want to deploy and click the Open Overview
icon.
4 In the Deploy/Undeploy section, select the engine to which you want to deploy the rule, then click
Deploy.
To deploy rules from the Correlation Rule dashboard:
1 Log in to the
2 In the Correlation panel, click the engine to which you want to deploy rules.
The Correlation Engine dashboard is displayed.
3 In the Available rules section, select the rule or rules that you want to deploy, then click Deploy.
Correlating Event Data
67
Viewing Correlated Events
Correlated events contain detailed information about the trigger events. To view correlated events,
perform the following:
1 Log in to the Sentinel Main or SSDM Main interface.
2 In the navigation panel, click Correlation.
3 In the Correlation panel, select any rule, then click
.
The events that match the rule criteria are displayed in the search results panel. The correlated
events are displayed with the
icon.
4 (Optional) Click
to see the correlated event fields and their values. For more information, see
Table 5-3 on page 56.
You can use the event field IDs to create search queries to find specific correlated events. For
example, if you want to search for the correlated events that were generated because of the
correlation rule LoginUser, specify the following query in the Search field:
st:C AND rt2:LoginUser
For more information about searching for events, see “Searching Events Indexed in Traditional
Storage” on page 21.
5 (Optional) Click View triggers to view the events that generated the correlated event.
Customizing Correlated Event
Correlated events include specific event fields with some default values. For more information, see
Table 5-3 on page 56 in “Understanding the Correlated Event” on page 56.
You can customize the default correlated event field values. For example, when a specific event
pattern is detected and you want the rule to create correlated events with a high severity value, you
can customize the Severity field of the correlated event. Similarly, if you want to allow a specific
tenant to view correlated events specific to their tenant, you can set either the TenantID field or the
TenantName field to the tenant associated with the rule.
You can customize the correlated event when creating the correlation rule. You can use the
Customize correlated event option that allows you to customize almost all the correlated event fields
except for the Sentinel internal fields. Any customization in the correlated event field values is
applicable only to the specific correlation rule.
To customize correlated event field values:
1 In the Correlation panel, select the correlation rule, then click the Edit icon.
2 In the correlation rule builder, click Customize correlated event.
3 Drag the event fields you want to edit from the Available event fields section to the Selected
event fields section.
4 Click the Edit icon to specify the value for the event field.
By default, the value is same as the event field value of the last event that triggered the
correlated event. You can also reference other event field values in the Value field by enclosing
the event field in $.
For example, for a login failure event, in the Message field you may want to refer to the
InitiatorUserName, you can specify the Value as Login failure by $sun$.
68
Correlating Event Data
5 Click OK.
6 After customizing the correlated event fields, click Set to save the correlated event.
7 Click Save Rule.
The customized correlated event values are applied only for correlated events generated after
the customization.
Managing Correlation Rules
 “Viewing the Rule Dashboard” on page 69
 “Editing a Rule” on page 70
 “Deleting a Rule” on page 70
Viewing the Rule Dashboard
The Rule dashboard displays overall information of the rule. The Rule dashboard helps you to deploy
or undeploy a rule on a Correlation Engine, and also helps you manage the rule status. After a rule is
deployed, you can monitor the health of the rule, activities such as the events processed, and the
memory usage by the rule.
To view the Rule dashboard, select the desired rule in the Correlation panel.
After a rule is deployed, the dashboard displays the following information:
 Rule health statistics: Indicates the overall performance of the rule and enables you to monitor
the activities of the rule.
 Activity statistics: Indicates the activities of the rule since it was deployed in the
Correlation Engine:
 Fire count: The number of times the rule fired. You can use this information to
discover a rule that fires more than expected and that might need to be tuned, or to
discover a rule that does not fire as often as you would expect. In either case, this tab
guides you to the rules that are the most and least active. The search icon allows you
to view the events generated since the rule was deployed or enabled.
 Fire rate: The number of times the rule has been fired relative to the events processed
by the rule. This statistic is similar to fire count in that it gives an indication of how
active a rule is. However, instead of giving a raw count, the fire rate gives a percentage
that is relative to the number of events a rule has processed.
 EPS utilization: The processing time this rule consumes relative to the capacity of the
engine. This statistic provides an estimate of the amount of engine capacity a given
rule is currently consuming. Rules that are more complex, have time-consuming
actions, or fire frequently consume more capacity. You can use this statistic to
determine whether the rule needs to be tuned or perhaps moved to another Correlation
Engine for scalability reasons.
 Events processed: The number of events processed by the rule since the rule was
deployed.
 Total processing time: Total time spent by the Correlation Engine processing the rule
since it was deployed or enabled.
Correlating Event Data
69
 Memory statistics: Indicates the memory consumed by the rule:
 Estimated memory utilization: Gives a snapshot of roughly how much memory a rule
is consuming. Rules consume memory when they have discriminators specified for
fields with multiple values (through the Group by list), and when rules hold events in
memory for operations like the advanced “window” operation. Rules that consume a lot
of memory are a potential liability to a healthy system and should be carefully reviewed
to ensure they are properly written or possibly moved to another Correlation Engine for
scalability reasons.
 Events in memory: Number of events held in memory by the rule.
 Cardinality: Number of strings and related structures held in memory by the rule.
 Deploy/Undeploy: Lists the available Correlation Engines.You can select an engine, then click
Deploy or Undeploy to add or remove the rule in the Correlation Engine.
 Associated actions: Lists the actions associated with the rule.
 Status: Indicates the current status of the rule. You can also use this option to enable or disable
the rule.
Editing a Rule
NOTE: If you modify a deployed rule, you must redeploy the rule in the Correlation Engine for the
changes to take effect. For information on deploying a rule, see “Deploying Rules in the Correlation
Engine” on page 67.
Deleting a Rule
You can delete rules that are not deployed in the Correlation Engine. To delete a deployed rule, you
must first undeploy the rule from the Correlation Engine.
Managing the Correlation Engine
 “Using the Correlation Engine Dashboard” on page 70
 “Stopping or Starting a Correlation Engine” on page 73
Using the Correlation Engine Dashboard
The Correlation Engine dashboard provides an overall picture of the health of the engine and the
various rules deployed to it. The dashboard provides information on the activity of an engine and
provides insights about which rules are behaving as expected and which rules might need additional
tuning.
To view the Correlation Engine dashboard, select the desired Correlation Engine in the Correlation
panel.
The dashboard displays a simple view of all the rules deployed to that engine and a list of rules
available to deploy. You can also see some general information about the engine, such as its current
state (running, stopped, or offline) and how long the engine has been in that state. There is also a
summary that shows how many events the engine has processed, and an indication of current
utilization of the engine (EPS utilization). In general, you can think of this number as something
analogous to CPU utilization, but this metric indicates how much of the capacity of the engine is
currently utilized. As the number of rules and the complexity of rules increase along with the current
70
Correlating Event Data
EPS (events per second) rate of the system, you can expect this number to grow larger. The
Deployed rules comparison tab provides a more granular view of engine activity. The various tabs
represent various statistics, and you can select a given tab to sort the rules (ascending or
descending) by these statistics to get a clear picture of how various rules are behaving and
consuming resources.
The Correlation Engine dashboard also allows you to manage the engine and the rules in your
system:
 “Managing the Correlation Engine” on page 71
 “Managing Deployed Rules” on page 71
 “Comparing Deployed Rules” on page 71
 “Viewing Engine Details” on page 72
 “Distributing Events Across Correlation Engines” on page 72
 “Viewing Available Rules” on page 73
Managing the Correlation Engine
The following options are available to manage the Correlation Engine:
 Stop: Stops an active Correlation Engine. When the engine stopped, it does not monitor the
events against the deployed rules.
 Undeploy all: Undeploys all the deployed rules from the engine.
 Rename: Allows you to rename the engine.
Managing Deployed Rules
This section lists the number of rules and the rules deployed in the engine.
The following options are displayed when you mouse over a rule:
 View: Opens the Rule dashboard to provides overall information on the rule. For more
information, see “Viewing the Rule Dashboard” on page 69.
 Disable: Allows you to disable the rule. When a rule is disabled, it does not process the events.
 Undeploy: Undeploys the rule from the Correlation Engine.
Comparing Deployed Rules
This section helps you compare the rules based on parameters such as fire count, EPS capacity, and
memory utilization. You can sort the rules as desired by using the up-arrow and down-arrow icons.
 Fire count: The number of times the rule has fired since it was deployed or enabled. You can
use this information to discover a rule that fires more than expected and that might need to be
tuned, or to discover a rule that does not fire as often as you would expect. In either case, this
tab guides you to the rules that are the most and least active.
 Last fired: The last time the rule fired since it was deployed. This statistic is useful for
determining the rules that are currently active and inactive in the system. A rule might have fired
frequently, but it has not fired recently. Or, a rule might fire infrequently, but it fired recently. This
tab gives you a real-time picture of what is active in the engine at any given time.
Correlating Event Data
71
 Fire rate: The number of times the rules have fired relative to the events processed by the
engine. This statistic is similar to fire count in that it gives an indication of how active a rule is.
However, instead of giving a raw count, the fire rate gives a percentage that is relative to the
number of events a rule has processed. This normalizes the metric, and rules that were recently
deployed can be compared with rules that were deployed at an earlier time.
 EPS utilization: The events processing time the rule consumes relative to the capacity of the
engine. This statistic provides an estimate of the amount of engine capacity a given correlation
rule is currently consuming. Rules that are more complex, have time-consuming actions, or fire
frequently consume more capacity. You can use this statistic to identify rules that need to be
tuned or perhaps moved to another correlation engine for scalability reasons.
 Memory utilization: The estimated memory utilization of the rule. In addition to EPS utilization,
which provides a good picture of how much time a rule consumes relative to the total available
processing time of the engine, the memory utilization gives a snapshot of roughly how much
memory a rule is consuming. Rules consume memory when they have discriminators specified
for fields with multiple values (through the Group by list), and when rules hold events in memory
for operations like the advanced “window” operation. Rules that consume a lot of memory are a
potential liability to a healthy system and should be carefully reviewed to ensure they are
properly written or possibly moved to another engine for scalability reasons.
Viewing Engine Details
This section lists the Correlation Engine details and so you can monitor the performance of the
Correlation Engine.
 Engine ID: The Correlation Engine ID.
 Engine Name: The name of the Correlation Engine.
 Host IP: The IP address of the host machine where the Correlation Engine is installed.
 Hostname: The hostname of the machine where the Correlation Engine is installed
 State: Whether the status of the Correlation Engine is running or stopped.
 Events Processed: The number of events processed by the deployed rules since they were
deployed.
 Last changed state: The time the Correlation Engine status was last changed.
 EPS utilization: The processing time the Correlation Engine consumes relative to the capacity
of the engine.
Distributing Events Across Correlation Engines
In a scalable storage setup where the EPS rate is usually high, Correlation Engines could be loaded
with a large number of events to process. By default, all events are sent to all Correlation Engines. To
avoid event overload, you can check the EPS utilization on the Correlation Engine and then distribute
the event load evenly across multiple Correlation Engines as necessary. Distributing events across
Correlation Engines not only helps you in balancing the event load, it also helps you segregate events
tenant-wise to specific Correlation Engines. For example, in a multi-tenant environment, you can set
up designated Correlation Engines for each tenant so that the Correlation Engine processes events
specific to each tenant. The option to distribute events across Correlation Engines is available only in
Sentinel with scalable storage.
By default, Correlation Engines process all events with severity 0 to 5. You can modify the event
criteria as required in the Events Routed to This Engine section. By default, the Correlation Engine
processes events from the security.events.normalized Kafka topic. When you modify the default
event criteria, Sentinel creates a new dedicated Kafka topic for the Correlation Engine in the
72
Correlating Event Data
security.events.normalized.analytics.<correlation_engine_ID> format so that the
Correlation Engine can process only the specific events from this dedicated topic. Sentinel creates a
new topic dedicated to each Correlation Engine only the first time you modify the default event
criteria. For any subsequent updates to the event criteria, Sentinel updates the dedicated Kafka topic
accordingly.
After you modify the event criteria, you must restart data processing in CDH for the changes to take
effect. For more information, see “Processing Data” in the NetIQ Sentinel Administration Guide.
When you uninstall and delete the Correlation Engine, you must restart data processing and then
delete the associated Kafka topics.
Viewing Available Rules
This section lists the available rules in the system that are not deployed in the Correlation Engine. It
also allows you to select rules and deploy them in the Correlation Engine.
Stopping or Starting a Correlation Engine
The Correlation Engine is in the Start mode by default and keeps processing events for the rules
deployed in the engine. You can determine when the Correlation Engine should process the events
and start or stop the Correlation Engine accordingly.
Correlating Event Data
73
74
Correlating Event Data
6
Visualizing and Analyzing Alerts
6
Alerts notify you of what is most important for you to look at. Alerts can relate to threats to IT
resources or performance thresholds such as system memory full or IT resources not responding.
Correlation rules define the patterns that you are alerted to. Sentinel automatically associates the
relevant events and identities with the alert to help you determine the root cause of a potential threat.
Visualizing alerts helps you identify and analyze potential threats against your IT resources. Sentinel
provides graphical and tabular representations of alerts.
This chapter provides information about the following:
 “Viewing and Triaging Alerts” on page 75
 “Creating an Alert View” on page 77
 “Escalating Alerts to an Incident” on page 78
 “Analyzing Alert Dashboards” on page 79
 “Video” on page 82
 “Troubleshooting” on page 82
Viewing and Triaging Alerts
Sentinel provides several ways to view alerts. The alerts you can view depend on the alert
permissions applicable to your role and the tenancy of your role. For more information about
permission to manage alerts, see “Configuring Roles and Users” in the NetIQ Sentinel Administration
Guide.
Sentinel provides the following ways for you to view alerts in real time and triage them:
 Threat Response Dashboard: The Threat Response dashboard provides an overview of your
current workload by breaking down alerts in groups, such as status, assignment, and priority.
With the alerts grouped in this way, you can focus on and triage the high priority alerts assigned
to you before triaging other alerts.
To view alert details, click on any of the numbers or graphs.
You can also:
 Launch multiple pages in the browser
 Share content with colleagues using a URL
 Bookmark pages for quick access
NOTE: For users in the Operator role, the Threat Response dashboard is the main user
interface for viewing and triaging alerts. Any user with permission to manage alerts can also use
it. Users who wish to use alert views in the Sentinel Main interface, or do not have permission to
view or manage alerts on the Threat Response dashboard, can click Sentinel Main in the left
side navigation.
Visualizing and Analyzing Alerts
75
 Alert Views: In the Sentinel Main interface, alert views provide a graphical and tabular
representation of alerts that match the specified alert criteria. Charts provide a summary of alerts
and the table provides high-level information about individual alerts. Sentinel provides some alert
views, but you can also create your own alert views and customize the alert criteria as
necessary. For more information, see “Creating an Alert View” on page 77.
To access alert views, click Real-time Views > Alert Views.
The alert table displays only distinct alerts. Duplicate alerts are rolled up to a single distinct alert. For
more information about rolling up of duplicate alerts, see “Configuring Alert Creation” in the NetIQ
Sentinel Administration Guide. Alerts from Sentinel servers in a distributed location are distinguished
by the Remote icon ( ) next to the name of the alert. You can view the IP address of the remote
Sentinel server by moving the mouse over the name of the alert.
As you monitor alerts, you can perform the following activities:
 Mouse over the charts to determine the number of alerts based on alert states, priority, and
severity.
 Sort alerts based on one or more columns in the table. Press Shift+click to select multiple
columns to sort. By default, the alert view table displays alerts based on the time when the alerts
were triggered. Therefore, the latest alerts are listed on the top in the table.
 Assign alerts to a user or a role, including yourself or your role.
 Modify the alert state to indicate the progress on the alert investigation.
 Add comments to the alert to indicate the changes you made to the alert, which helps you to
keep an up-to-date record of the alert investigation. For example, you can add comments when
you change the state of a specific alert or when you have gathered more information about the
alert. Providing specific comments allows you to accumulate knowledge about a particular
instance of the alert and track how a particular condition was addressed. Comments are
important in tracking the alert, particularly if the process of resolving the alert spans several
users or roles.
 View the events that triggered the alert and drill-down for more information. You can drill down to
view the user identities that triggered the event by clicking the View details icon in the alert view
table.
The Alert Details page displays detailed information about an alert including the following:
 Source / Background Information: Displays the correlation rule that generated the alert.
You can also annotate the correlation rule by adding information to the knowledge base so
that future alerts generated by this correlation rule include the associated historical
information.
NOTE: In Sentinel Main, the field is Source. In the Threat Response dashboard, the field is
Background Information.
 Knowledge Base: Knowledge base is a repository that contains information about the
conditions that resulted in the alert. It can also include information about resolution of a
particular alert, which can help others resolve similar alerts in the future. Over time, you can
collect a valuable knowledge base about the alert specific to a tenant or an enterprise.
For example, an employee has recently joined the organization and has the access
permissions to a secured server. However, this employee might not have been added yet to
the authorized users list. Therefore, an alert is generated every time the employee tries to
access the server. In such a case, you can add a note in the alert knowledge base to
indicate that the “employee is approved to access the server, but is not yet listed in the
authorized users list. This alert can be ignored and set to low priority.”
76
Visualizing and Analyzing Alerts
NOTE: To view or edit the knowledge base, you must be an administrator or have the View
Knowledge Base or Edit Knowledge Base permissions.
 Alert Fields: Displays the alert fields that provide the following information:
 who and what caused the alert
 the assets affected
 the taxonomic categories of the action that caused the alert, the outcome, and so on.
For more information on taxonomy, see Sentinel Taxonomy.
For more information about alert fields, click Tips on the top-right corner of the Sentinel
Main interface.
 Trigger Events: Displays the events that triggered the alert. You can investigate the
conditions that triggered the alert by examining the trigger events. By default, the Alert
Details page displays 10000 trigger events per alert. You can also define this number as
necessary. For more information, see “Configuring the Number of Trigger Events to be
Displayed in the Alert View” in the NetIQ Sentinel Administration Guide.
To view the alert trigger events, click the Search icon.
NOTE: Although the alert may include trigger events older than the configured data
retention period, the search will display events that are within the data retention period.
For information about manually performing actions on events, see Chapter 11, “Manually
Performing Actions on Events,” on page 105. You can also perform other event operations
such as adding these events to an incident, exporting these events to a CSV file, and
viewing the vulnerabilities associated with these events. For information about performing
event operations, see “Performing Event Operations” on page 31 in Chapter 3, “Searching
Events,” on page 21.
 Show history: Displays the changes made to the alert, which helps you track any actions
taken on the alert.
 Identities: (Sentinel Main only) Displays the list of users involved in the alert. This
information helps you to investigate about the users involved in the alert and monitor their
activities.
NOTE: To perform more detailed analysis, you can use alert dashboards. For more information, see
“Analyzing Alert Dashboards” on page 79.
Creating an Alert View
To view and analyze alerts in the Sentinel Main interface, you must first create the alert view. To
create the alert view, you must either be an administrator or have the Manage Alerts permission. For
more information, see “Configuring Roles and Users” in the NetIQ Sentinel Administration Guide.
To create an alert view:
1 From Sentinel Main, click Real-time Views > Alert Views > the Create icon.
2 Specify the following information:
 Name: Specify a name for the alert view.
 Sharing: Select either of the following options:
 Public: Allow everyone to view the alert view. In the public mode, you are the owner of
the alert view and other users cannot edit it.
Visualizing and Analyzing Alerts
77
 Private: Only you will be able to view the alert view.
 Data sources: Add other data sources from which you want to view alerts. For information
about data sources, see “Configuring Data Federation” in the NetIQ Sentinel Administration
Guide.
 Criteria: Specify the criteria to filter the alerts.
 Tenant: If you are in a multi-tenant environment, select the department or the tenant name
for which you want to view alerts.
NOTE: This option is displayed only if you are an administrator in a multi-tenant
environment. For information about multitenancy, see “Configuring Sentinel for
Multitenancy” in the NetIQ Sentinel Administration Guide.
 Time range: Specify the time range for which you want to view alerts.
 Use alert period: Select Created or Modified to view the alerts that were created or
modified in the specified time range.
3 Click Save to save the alert view.
Escalating Alerts to an Incident
After performing adequate investigation on an alert, you may determine there is a serious problem
and the alert needs further investigation by the security analyst. You can escalate such alerts by
creating an incident without losing all the work you already did as part of the alert investigation.
You must have any of the following permissions to escalate alerts to an incident:
 Create incidents, add events, and escalate alerts to incidents
 Create, modify, and execute actions on assigned incidents
 Manage all aspects of incidents: create, modify, and delete
In multi-tenancy environments, only users in the default tenant can escalate alerts to incidents.
You can escalate alerts either to an existing incident or create a new incident. When you select the
option to escalate alerts to an existing incident, Sentinel lists the existing incidents.
By default, Sentinel displays 500 incidents in the list. To configure the number of incidents you want to
view by default, see “Configuring the Number of Incidents to be Listed in the Incidents List” in the
NetIQ Sentinel Administration Guide.
Sentinel sorts the list of incidents based on the relevance of the incident to the selected alerts. The
relevance score of the incident helps you to easily identify the appropriate incident rather than having
to scroll through the entire list of incidents. The relevance score ranges from 0 to 100. The higher the
score the higher the relevancy of the incident to the selected alerts. Incidents with the following
properties have a higher relevance score:
 Incident name matches with any of the selected alerts’ names.
 Incident already contains alerts whose names match with the names of any of the selected
alerts.
 Incident name matches with any of the selected alerts’ names and the incident also contains
alerts whose names match with the names of any of the selected alerts.
Sentinel considers only the first 50 selected alerts to calculate the relevance score.
78
Visualizing and Analyzing Alerts
When you escalate alerts to an incident, Sentinel attaches the events that triggered the alert, asset
details, and alert comments to the incident. By default, Sentinel attaches 25 trigger events per alert to
the incident. To configure the number of trigger events to be attached to the incident, see “Configuring
the Number of Alert Trigger Events to be Attached with the Incident” in the NetIQ Sentinel
Administration Guide.
After you escalate an alert, Sentinel changes the alert state to Closed. If you want to escalate the
same alerts to a different incident, you can re-open the alerts and escalate them to a different
incident. However, you cannot re-escalate the same alerts to the same incident again. If there are
additional trigger events to the same alerts that were already escalated and you want to add those
events to the same incident, you can open the alert trigger events in the search pane and then add
the additional trigger events to the already created incident. For more information, see “Adding
Events to an Incident” on page 32.
To escalate an alert to an incident using alert views:
1 (Conditional) If you are using the Threat Response dashboard, click a number or graph to
display a table of alerts.
2 (Conditional) If you are using the Sentinel Main interface, complete the following:
2a Click Real-time Views > Alert Views.
2b Select the desired alert view and click the Open the alert view icon.
3 Select the alerts you want to escalate, and click Escalate.
NOTE: You cannot escalate alerts that are in the Closed state.
4 Specify the reason for escalation.
5 (Conditional) To verify whether there’s an existing incident for the selected alerts, click Select an
existing incident, select the relevant incident, and click Escalate.
6 (Conditional) If there is no matching incident for the selected alerts or you want to create a new
incident, click create a new incident.
Sentinel populates the default values for the incident based on the selected alert. If you selected
more than one alert, Sentinel populates the incident values based on the first alert you selected.
Specify the required information, and click Escalate. For more information about the incident
parameters, see “Creating Incidents” on page 123.
NOTE: If you try to escalate the same alerts to the same incident again, an error is displayed and
the Escalate button is disabled. Click Cancel to cancel the escalation and escalate the alerts to a
different incident.
For more information about viewing and managing incidents in the Sentinel Control Center, see
“Managing Incidents” on page 124.
Analyzing Alert Dashboards
In the Sentinel Main interface, alert dashboards allow you to analyze and study common patterns in
alerts, such as:
 Types of alerts
 Average time owners take to close alerts
 The correlation rule generating the maximum number of alerts
 Geographical origin of high-severity alerts
Visualizing and Analyzing Alerts
79
 Oldest open alerts
 Alerts that took the longest time to close
You can create custom charts and tables for analysis. You can filter and refine the data further as you
select certain areas in the charts and use the query and filter options.
For example, you are a Security Operations Center manager in a multi-tenant environment, and you
want to analyze and investigate alerts in detail and also understand how your team is handling the
alerts. You can perform the following analysis in the alert dashboard:
 Investigate Alerts: You can view the alerts generated over time, number of open alerts versus
closed alerts, top correlation rules generating the most number of alerts, oldest open alerts, any
spikes in alerts at a specific time range, and so on.
 Monitor team performance:
 The type of alerts the team has been working on
 How the alert load is distributed among top owners
 Time taken to close alerts of specific priorities
 Find the team member owning the most number of alerts
 Team members that took longest to investigate alerts
 Monitor performance against tenant service-level agreement (SLA): You can view alerts
from various tenants, analyze the most number of alerts from a specific tenant, time taken to
investigate or close alerts for a specific tenant compared to other tenants, and so on.
The Alert dashboard provides a customizable and an easy-to-configure interface that helps you to
view and investigate alerts in detail.
To create or view alerts in the dashboard, you must either be an administrator or have the permission
to manage alerts. Depending on the alert permissions and the tenant you belong to, Sentinel displays
the relevant alerts in the dashboard.
Creating the Alert Dashboard
To create the alert dashboard:
1 In the Sentinel Main interface, click Dashboards > Alert > click the Create alert dashboard icon.
The Alert dashboard view opens in a new window. For information about analyzing alerts, see
“Analyzing Alerts” on page 80.
2 (Optional) Customize the default dashboard to suit your requirements. For more information
about customizing the alert dashboard, see “Customizing the Alert Dashboard” on page 81.
3 Click the Save icon to save the customized dashboard.
Analyzing Alerts
The Alert dashboard provides some pre-configured panels that provide information about alerts such
as the following:
 Overview: Displays a time series chart that shows alerts generated in Sentinel over time. You
can inspect the time series charts for any spikes, which can indicate increase in attacks in your
organization. You can drag and select the time period when the spike occurred to zoom into the
alerts. As you select the specific time range, Sentinel filters the dashboard for alerts in the
selected time range. Also, you can find out the geographical locations from where the alerts
originated.
80
Visualizing and Analyzing Alerts
To view geographical locations from where the alerts originated, ensure that the
IpToCountry.csv file is populated by using the IP2Location Feed plug-in. For more information,
see the IP2Location Feed documentation on the Sentinel Plug-ins Website (https://
www.netiq.com/support/sentinel/plugins/).
 Alert Load: Provides information about the alerts at a granular level such as the following:
 Topmost alerts in your enterprise
 Alert distribution among top alert owners
 Total number of alerts in individual alert states
 Number of alerts received from each tenant
 Total number of alerts based on priority
 Performance rows: Provides statistical information about how efficiently alerts are investigated
and closed based on priority, correlation rule, alert owners, and tenants.
 Details: Provides detailed alerts information such as the oldest open alerts, number of times the
duplicate alerts were rolled up, and all alert fields.
The alert dashboard displays all alerts in your local Sentinel server. To view alerts from other Sentinel
servers, you need to view the alerts in the Alert Views. For more information, see “Creating an Alert
View” on page 77. The alert dashboard displays only distinct alerts. Duplicate alerts are rolled up to a
single distinct alert. For more information about the rolling up of duplicate alerts, see “Configuring
Alert Creation” in the NetIQ Sentinel Administration Guide.
To view the alert dashboard:
1 In the Sentinel Main interface, click Dashboards > Alert.
2 Select the desired alert dashboard and click the Open alert dashboard icon.
3 As you visualize and monitor alerts, you can perform the following activities in the alert
dashboard:
 Mouse over specific areas in the charts to view more information.
 Select desired areas in the chart to filter the alert data. As you select a specific area in the
chart, Sentinel filters the alerts in rest of the charts and tables in the dashboard. Click
Filtering to remove the applied filters and go back to the unfiltered view.
4 (Optional) You can customize the default view and save the dashboard. For information about
customizing the dashboard, see “Customizing the Alert Dashboard” on page 81.
5 (Conditional) To perform various operations on alerts such as closing an alert, assigning alerts to
a user, and so on, see “Viewing and Triaging Alerts” on page 75.
Customizing the Alert Dashboard
Sentinel leverages Kibana, a browser-based analytics and search dashboard, that helps you to
visualize and analyze data. The dashboard is divided into rows and panels. You can create rows and
add panels as required to display various charts.You can drag and drop the rows or panels to arrange
them on the dashboard. You can also configure the size, style, and type of panels for a row. For more
information, see rows and panels in Kibana documentation. As you visualize and monitor alerts, you
can customize the alert dashboard as follows:
 Apply multiple filters to refine the alert data using the Query and Filter options. For more
information about queries and filters, see queries and filters in Kibana documentation.
Visualizing and Analyzing Alerts
81
 Customize the rows and panels according to your requirements, for example, drag and drop the
panels to arrange them on the dashboard. Click Configure Dashboard > Rows tab to arrange,
create, or remove rows in the dashboard. For example, if you have to view the tenant specific
information frequently, move the tenant performance row to the top or if you do not want to view
the detailed tables, you can remove the Details row.
 Click the configure option in the panels to customize the size and style of panels.
 Add markers in the time series panel to display additional information such as owners, severity,
and so on.
Video
For more information about using visualizing and triaging alerts, see the video Investigating a Data
Breach Using Alerts.
Troubleshooting
This section lists issues, which may occur when viewing alerts, along with the solution to resolve the
issues.
Unable to View Alerts in the Dashboard and Alert Views
The alert dashboard and the charts in the alert view do not refresh or display new alerts. However, the
table in the alert view displays the newly generated alerts. This issue could happen because of a
corrupt alert index. For more information, see “Unable to View Alerts in the Dashboard and Alert
Views” in the NetIQ Sentinel Administration Guide.
82
Visualizing and Analyzing Alerts
7
Analyzing Trends in Data
7
The following sections describe how the Sentinel Security Intelligence feature analyzes trends in data
and how to use the Security Intelligence feature.
 “Overview” on page 83
 “Creating a Dashboard” on page 86
 “Understanding the Dashboard Interface” on page 87
 “Creating Baselines” on page 88
 “Configuring Anomaly Detection” on page 89
 “Viewing Anomaly Events” on page 91
 “Managing Dashboards” on page 93
 “Troubleshooting” on page 94
Overview
The Correlation capability in Sentinel provides security analysis with the ability to look for “known
knowns” occurring within the enterprise in real time. Sentinel provides another way to analyze data by
looking for the “known unknowns” in the events generated within the enterprise.
This second type of analysis is called Security Intelligence in Sentinel. It allows you to perform
anomaly-based analysis so you can find deviations from the normal trends of your enterprise.
A key aspect in looking for deviations depends upon the nature of input data. Input data is typically a
collection of various instances, records, or points. Each data instance itself consists of attributes that
define the type of input. Examples of different types of input data within the SIEM domain are:
 Spatial (location of various entities)
 Graphical (relation between the various entities)
 Sequences (time series)
The Security Intelligence feature in Sentinel focuses on statistical analysis of time series data to
enable analysts to identify and analyze anomalies either by an automated statistical engine or by
visual representation of the statistical data for manual interpretation. The following concepts
collectively define the Security Intelligence feature in Sentinel:
 “Terminology” on page 83
 “How Security Intelligence Works” on page 85
 “Permissions for Security Intelligence” on page 86
Terminology
The following terminology is used with Security Intelligence:
Security Intelligence: The feature that allows you to create dashboards with baselines that define
what is normal in your network. An analysis of the real-time data lets you see if there are any
anomalies, and an e-mail is sent to notify someone that anomalies are occurring.
Analyzing Trends in Data
83
Dashboard: Displays data matching a particular filter, categorizes data using a particular classifier,
and looks for particular anomalies as specified in the dashboard’s set of anomaly rule definitions. This
is not just a front-end web interface, but also a back-end engine because it is always looking for
anomalies, even if the web interface is not open.
Classifier: Determines the categories displayed in the dashboard.
Filter: Determines the scope of events displayed in the dashboard.
MongoDB: A database that stores the Security Intelligence data.
Category: A class or division of events with shared characteristics as defined by the classifier.
Anomaly: Something that deviates from what is standard, normal, or expected when compared to
the user’s selected baseline.
Anomaly Definition: A set of principles, configurable by a user, that describes the threshold and
circumstances as defined in the anomaly rules.
Chart: The graph in the dashboard that depicts the statistical data and baseline.
Time Slider: The web interface component that allows a user to quickly visualize and navigate the
time range of data.
Breakdown: The web interface component that displays the top ten values of a select number of
event fields to show a user details on the most prevalent event values in the data they are viewing.
84
Analyzing Trends in Data
How Security Intelligence Works
The following diagram depicts how the Security Intelligence feature works.
Figure 7-1 How Security Intelligence Works
Message Bus
4
1
Sentinel
Web
Interface
Baseline
Filter
Anomaly
Classifier
5
7
Dashboard
8
Anomaly
Detection
E-mail
Recipient
2
Anomaly
Detection
Engine
Segment of
Data
3
6
Security
Intelligence
Database
Days
1. A user creates a dashboard in the Sentinel Main interface.
2. The dashboard consists of a filter and classifier that create a segment of data from the
normalized events in the message bus.
3. The segment of data is stored in the MongoDB database for up to 28 days.
4. The user then defines a baseline of normal activity for the environment.
5. The user creates anomaly definitions to look for real-time events that are occurring outside of the
defined baseline.
6. The anomaly engine analyzes the events in the MongoDB database.
Analyzing Trends in Data
85
7. This information is displayed in the dashboard.
8. If an anomaly is detected, an anomaly event is generated (e-mail can be sent with the
information about the anomaly).
Permissions for Security Intelligence
The Security Intelligence option is displayed in the web interface if the user has one of the following
permissions:
 Manage and View Security Intelligence Dashboards
 View Security Intelligence Dashboards
A user is assigned these permissions while creating a role. For more information, see “Configuring
Roles and Users”in the NetIQ Sentinel Administration Guide.
Using the Security Intelligence option, you can view, create, and manage dashboards.
Creating a Dashboard
1 From Sentinel Main, on the left side of the page, click Security Intelligence > Dashboards >
Create.
The Create Dashboard page opens in a new tab.
2 Use the following information to create the dashboard:
Name: Specify a unique name for the dashboard.
Classifier: Select the classifier that determines the categories displayed in the dashboard. The
options are:
 Taxonomy Outcome
 Device Activity
 Tag Activity
 Http
 Exploit
Filter: Specify a filter to determine the scope of events displayed in the dashboard, or select a
predefined filter. By default it displays the (sev:[0 TO 5]) filter.
To search for an event field, specify the short name of the field, a colon, and the value. For
example, notnull: xdastaxname displays all events. For more information, see Chapter 4,
“Configuring Filters,” on page 39.
Data retention period: Select how long the data for the dashboards should be retained.
By default the Security Intelligence MongoDB database retains the data for 4 weeks.
Load historical data: Select this option to view historical data, which provides more context
when analyzing the data.
3 Click Create dashboard.
The newly created empty dashboard is displayed because it has not had time to collect any data.
After few minutes, you can see the event data in the dashboard.
86
Analyzing Trends in Data
Creating a Dashboard by Using a Filter
You can use a filter search query as a dashboard filter and create a dashboard. For more information
on creating a dashboard by using a filter, see “Saving a Search Query as a Security Intelligence
Dashboard” on page 31.
Understanding the Dashboard Interface
The dashboard displays the analysis of the data.
Chart: The graph displays the events, the anomalies, and the baseline.
Compared to: Displays the types of baselines for comparison with the flowing data. Baseline is the
referenced line that is displayed in blue color, whereas the actual events that are flowing in to the
system is displayed in brown. You can compare the flowing data to the following:
 Moving Average: Data that is flowing in to the system is compared to the average of the data.
 Previous Day: If you have one day data stored in Security Intelligence database (MongoDB),
then you can compare the flowing data with the previous day data.
 Previous Week: If you have one week of data stored in Security Intelligence database
(MongoDB), then you can compare the flowing data with the previous week data.
 Create Baseline: Allows you to create a custom baseline You must have at least a week’s worth
of data before you can create a baseline. For more information on creating a custom baseline,
see “Creating Baselines” on page 88.
Time range: Displays the time range between which we can see the data. When you create a
dashboard, the Time range shows Hour. It then displays Day and Week as you have one day or one
week data stored in Security Intelligence database (MongoDB). The Hour option does not appear, if
the Security Intelligence database (MongoDB) have 28 days of data.
Analyzing Trends in Data
87
Show Events: Displays the list of events for the selected time range in the Sentinel Main interface.
The total events in the Sentinel Main interface matches with the total events in the dashboard.
However, the total events count in the Sentinel Main interface does not match with the total events in
the dashboard in the following cases:
 If the leftmost and rightmost time point on the dashboard are included. To match the events in
the dashboard and Sentinel Main interface, select the time point between the leftmost and
rightmost time point on the dashboard.
 By default, Sentinel includes internal audit events in the dashboard search results. To exclude
the internal events, create a dashboard by using the filter (sev:[0 TO 5]) -st:A -st:I st:Y. For more information, see “Creating a Dashboard by Using a Filter” on page 87.
Time Slider: The time slider allows you to change the amount of information displayed in the
dashboard. It allows you to zoom in or zoom out for a specific time period. As you move the time
slider, the graph changes accordingly.
Time Slider Data Summaries: Below the graph, a summary of the time slider data is displayed. The
data that is
Anomalies: Displays the anomalies that have occurred during the lifetime of the dashboard. To view
the details of the anomaly, you can click on anomaly name. This displays the anomaly detail page.
Categories: The Categories panel on the right of the dashboard displays the categories of the
current time range at the current level of the dashboard. It provides the ability to drill down and find
more information about the categories of events. This section displays lines identifying changes from
the baseline indicators of the categories. You can sort the category list by percent change, reference
count or current count.
Clicking a specific category in the list on the right displays the data for just that category. It changes
the main graph to show the events in that category list. The totals in the main section changes to
reflect the current category. It also displays the following sections in the bottom of the main panel.
 Category anomalies: Displays anomalies happened in the current time window for the selected
category.
 Category breakdown: Displays the attributes of the selected category. Only top 10 values of
the selected category are displayed in the UI. You can click any value under the Top 10 Values
list to view the list of events in the Sentinel Main interface.
The Categories list on the right changes to Subcategories and displays attributes of the selected
category. You can sort them as per your requirement.
Creating Baselines
You can create a baseline to use for anomaly detection. You must have at least a week’s worth of
data before you can create a baseline.
1 Click the desired dashboard under the dashboard heading.
2 Click the option displayed in the Compare to field.
or
Click Show dashboard details.
3 Click Create baseline.
4 Read the confirmation message, then click Create.
5 After the baseline is created if you want to update the baseline with more amount of data then
you can click Regenerate baseline.
88
Analyzing Trends in Data
After the baseline is created, you can use it to create an anomaly definition as described in
“Configuring Anomaly Detection” on page 89.
Configuring Anomaly Detection
After you create a baseline, you can configure anomalies to use with the information gathered in the
dashboard. This allows you to receive alerts when events occur outside of the baseline.
 “Creating an Anomaly Definition” on page 89
 “Deploying an Anomaly Definition” on page 90
 “Undeploying an Anomaly Definition” on page 90
 “Managing Anomalies” on page 91
Creating an Anomaly Definition
1 From Sentinel Main, click the desired dashboard under the dashboard heading, then click
Configure anomaly detection.
2 Click Create anomaly definition.
The Anomaly detection definition details screen is displayed.
3 Use the following information to create the anomaly definition:
Anomaly name: Specify a unique name for the anomaly.
Anomaly description: Specify a description for the anomaly. The description is displayed in the
anomaly event.
Comparison type: Select and define the anomaly type. The options are:
 Threshold: When the number of a specific type of events exceeds a specified limit,
Sentinel triggers an anomaly event. For example, if you set the threshold for login failures to
five and if more than five failed logins occur, Sentinel triggers an anomaly event.
 Moving Average: Moving averages are calculated over a specific period of time. All
averages in that period are recalculated to remove noise and deviations which results in the
moving average. Sentinel triggers an anomaly event if the moving average deviates from
the normal averages. For example, in the holiday seasons, the internet traffic for ecommerce websites might spike which might result in abnormal average compared to the
rest of the year. Sentinel triggers an anomaly event indicating the deviation in the moving
average.
 Ratio: Provides a comparison between the number of different types of events. If the ratio
of a specific event type compared to the other type exceeds beyond a specified limit,
Sentinel triggers an anomaly event. For example, if a significant number of events were
reported for viruses as compared to network attacks.
 Historical: Provides a comparison of the number of current events with the events received
in the past. For Example, if the historical data reports the number of invalid logins per day in
the range of 100-150 and if the current number of invalid logins is1000, Sentinel triggers an
anomaly event.
 Baseline: Provides a comparison to an established baseline. A baseline is usually the
accepted or agreed upon values of event data. You must have a custom baseline to use this
option. For more information, “Creating Baselines” on page 88. If there is a deviation from
the baseline, Sentinel triggers an anomaly event. For example, if the event stream baseline
is 1000 per second and if the event stream rate increases or decreases, Sentinel triggers an
anomaly event.
Analyzing Trends in Data
89
As per your requirement, you can select the Comparison type and specify the anomaly
definition.
When specifying the anomaly definition, specify the event category or the category and the
subcategory combination delimited by two greater than signs. For example, Create a user
session >> Disabled. Enter a text string to get auto-complete suggestions on relevant event
categories. Leave it blank to include all categories.
Anomaly state: Define the state of the anomaly by selecting any one of the following:
 Always active: You can use this option to keep the anomaly definition active always and
trigger when the specified anomaly definition is met.
 Only active for selected days and times: You can use this option to define the specific
times for anomaly definition to trigger. When you select this option, it displays a default time
grid. You can change the time grid and specify different time periods for the same anomaly
definition by holding the Ctrl key.
NOTE: The timing that is displayed in the time grid is the local time.
Notification information: Select the information to define the notification information.
 Severity: Select the severity of the notification. The options are 0 to 5.
 After this anomaly definition fires: Specify the notification time gap to send e-mail or
events after an anomaly triggers.
Optionally send notification via e-mail after the anomaly triggers: Fill in the following fields
to send an e-mail when the anomaly triggers.
 E-mail address: Specify the e-mail addresses of the people who should receive notification
when the anomaly occurs. Separate multiple e-mail addresses with commas.
 Subject: Specify a subject for the e-mail.
 Message: Specify a message for the e-mail to explain the anomaly that occurred.
4 Click Save.
5 Continue with “Deploying an Anomaly Definition” on page 90.
Deploying an Anomaly Definition
After the anomaly definition is created, it must be deployed to be applied to the dashboard.
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard where you created the anomaly definition.
2 Click Configure anomaly detection.
The Anomaly detect screen is displayed.
3 Mouse over the anomaly definition you want to deploy, then click Deploy.
You receive a message that the anomaly definition was deployed.
Undeploying an Anomaly Definition
To undeploy the anomaly definition:
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard where you created the anomaly definition.
2 Click Configure anomaly detection.
3 Mouse over the anomaly definition you want to undeploy, then click Undeploy.
90
Analyzing Trends in Data
4 Click Undeploy again to verify that you want to perform this action.
You receive a message that the anomaly definition was undeployed.
Managing Anomalies
You can perform the following management tasks on the anomalies:
 “Editing an Anomaly” on page 91
 “Deleting an Anomaly” on page 91
Editing an Anomaly
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard where you created the anomaly definition.
2 Click Configure anomaly detection.
3 Mouse over the anomaly you want to edit, then click Edit.
4 Make any desired changes to the anomaly definition, then click Save.
Deleting an Anomaly
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard where you created the anomaly definition.
2 Click Configure anomaly detection.
3 Mouse over the anomaly you want to delete, then click Delete.
4 Click Delete again to verify that you want to perform this action.
Viewing Anomaly Events
When an anomaly is detected, Sentinel generates an anomaly event. Anomaly event fields contain
detailed information about the anomaly.
To view the anomaly events:
1 In the Sentinel Main interface, in the left pane, expand Filters > My filters, click Anomaly Events,
click
.
2 To view the event field values for an anomaly event, in the search results, click All next to the
anomaly event.
The following table describes the various event fields in an anomaly event:
Anomaly Event Field
ID
Sample Value
Description
BeginTime
bgnt
2014-01-06T07:13:00.000Z
The start of the time range
when the anomaly was
detected.
EndTime
endt
2014-01-06T07:17:00.000Z
The end of the time range
when the anomaly was
detected.
Analyzing Trends in Data
91
92
Anomaly Event Field
ID
Sample Value
EventName
evt
FailedLogins:AbnormalFailed The name of the anomaly
Logins
definition.
EventTime
dt
2014-01-06T07:18:54.285Z
The time when the anomaly
event was generated.
Message
msg
abnormal failed login activity
The description in the
anomaly definition.
ObserverCategory
rv32
SIEM
For an anomaly event, this
event field is always set to
SIEM.
ObserverServiceComponent
rv150
/Create a user session/
Failure
The classifier path which
contains the categories
displayed in the dashboard.
ObserverTZ
estz
Asia/Kolkata
The time zone in which the
anomaly engine is located.
ObserverType
st
Y
For an anomaly event, the
event field is always set to Y.
SentinelProcessingComponent
rt2
AbnormalFailedLogins
The anomaly definition name.
SentinelProcessingComponentID
rv123
2F38BBCA-1A39-42A99873-D2C4CE732B0D
This is the UUID of the
dashboard which is
associated with the anomaly
definition. The UUID remains
the same even though the
dashboard name changes.
SentinelServiceComponentID
rv124
B7E6B2A7-CDB1-40A8AA33-8AE99284DE6B
This is the ID of the anomaly
definition. The ID remains the
same even though the
anomaly definition name
changes.
SentinelServiceComponentName
sres
FailedLogins
This is the dashboard name
associated with the anomaly
definition.
SentinelServiceName
res
SecurityIntelligence
For an anomaly event, this
event field is always set to
SecurityIntelligence.
Severity
sev
5
The severity in the anomaly
definition.
XDASClass
xdasclas 11
s
For an anomaly event, this
event field is always set to 11.
XDASDetail
xdasdeta 12
il
For an anomaly event, this
event field is always set to
12.
XDASIdentifier
xdasid
For an anomaly event, this
event field is always set to
13.
XDASOutcome
xdasoutc 1
ome
Analyzing Trends in Data
13
Description
For an anomaly event, this
event field is always set to 1.
Anomaly Event Field
ID
Sample Value
XDASOutcomeName
xdasoutc XDAS_OUT_THRESHOLD_
omenam EXCEEDED
e
For an anomaly event, this
event field is always set to
XDAS_OUT_THRESHOLD_
EXCEEDED.
XDASProvider
xdasprov 0
For an anomaly event, this
event field is always set to 0.
XDASRegistry
xdasreg
For an anomaly event, this
event field is always set to 0.
XDASTaxonomyName
xdastaxn XDAS_AE_ANOMALY
ame
0
Description
For an anomaly event, this
event field is always set to
XDAS_AE_ANOMALY.
For more information on anomaly event fields, click Tips in the Sentinel Main interface. For more
information on the event taxonomy and event fields, see Sentinel Taxonomy.
You can use the event field IDs to create search queries to find specific anomaly events. For
example, if you want to search for the anomaly events that were generated because of the anomaly
definition AbnormalFailedLogins, specify the following query in the Search field:
st:y AND rt2:AbnormalFailedLogins
For more information about searching for events, see “Searching Events Indexed in Traditional
Storage” on page 21.
Managing Dashboards
You cannot change the filter or classifier for an existing dashboard, because this changes all of the
data. If you want to change the filter or classifier, you must create a new dashboard.
However, you can perform the following management tasks on dashboards:
 “Viewing a Dashboard” on page 93
 “Renaming a Dashboard” on page 94
 “Deleting a Dashboard” on page 94
Viewing a Dashboard
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard that you want to view.
2 Click Show dashboard details to see the following information about the dashboard:
 The classifiers used to create the dashboard.
 The filter used to create the dashboard.
 When the dashboard was created.
 The amount of time data is retained for the dashboard.
Analyzing Trends in Data
93
Renaming a Dashboard
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard that you want to rename.
2 Click Show dashboard details in the toolbar.
3 Click Rename in the toolbar, then rename the dashboard.
4 Click Save to save the change.
Deleting a Dashboard
1 In the Sentinel Main interface, click Security Intelligence > Dashboard, then select the
dashboard that you want to delete.
2 Click Show dashboard details in the toolbar.
3 Click Delete.
4 Click Delete again to verify that you want to perform this action.
Troubleshooting
 “The Create Button Is Not Displayed” on page 94
 “The Main Graph and the Time Slider Are Not Synchronized” on page 94
 “Both Names for a Renamed Anomaly Are Displayed in the Filter” on page 94
 “Dashboard Date Range Not Updated to in Real Time” on page 95
The Create Button Is Not Displayed
If you access the Security Intelligence feature and the Create button is not displayed, the MongoDB
database is not running. The solution is to restart the Sentinel system.
The Main Graph and the Time Slider Are Not Synchronized
The main graph and the time slider can display different data because of the potential differences in
granularity.
Both Names for a Renamed Anomaly Are Displayed in the
Filter
If an anomaly definition display name changes but the anomaly was fired in both the old name and
the new name within the selected time range, the anomaly shows two filters: the old anomaly display
name with its firing count and new anomaly display name with its firing count.
If you filter on the new anomaly, only the new anomaly name is shown in the list, but the Show x of y
anomaly message shows x as the total count of the anomaly fired under the new name and y as the
total count of the anomaly fired in both the new and old display names.
The x will never equal y if there are events fired in both names within selected date range.
94
Analyzing Trends in Data
For example, assume that there is an anomaly definition of DemoDef that was renamed to DemoDefnameChanged within the selected time range and it has fired under the old name 60 times and under
the new name 180 times. In the filter drop-down list, both anomalies are displayed, showing DemoDef
(fired 60 times) and DemoDef-nameChanged (fired 180 times) for a total of 240. If you filter on
DemoDef, the filter message displays, Showing 60 of 240 anomalies. If you filter on DemoDefnameChanged, the filter message displays, Showing 180 of 240 anomalies.
Dashboard Date Range Not Updated to in Real Time
When the dashboard is bigger, the time granularity is bigger, so it page refreshes slowly. In another
words, the date range for the bigger display takes longer to show a difference. Even though the auto
refresh timer is the same, it might need to fire two times before you see any change in data.
Analyzing Trends in Data
95
96
Analyzing Trends in Data
8
Visualizing and Analyzing Network Flow
Data
8
Sentinel provides a graphical representation of the statistical network flow data that helps you identify
and analyze suspicious activities in your network. You can view the network flow data in real-time for
a specific department, for a specific customer, a specific event, an IP address, or a time range.
To view and analyze the network flow data, you must first configure Sentinel for network flow data
collection. To configure network flow data collection, you must either be an administrator or have the
Send NetFlow data permission. For more information about configuring network flow data collection,
see “Visualizing Network Traffic” in the NetIQ Sentinel Administration Guide.
NOTE: To view the network flow data, you must have the View NetFlow data permission.
To view the NetFlow data:
1 From Sentinel Main, perform either of the following:
 To view real-time network flow data for a specific department or a tenant:
1. In the navigation panel, click Real-time Monitoring > NetFlow > Create.
2. Specify the following information:
Tenant: If you are in a multi-tenant environment, select the department or the tenant
name for which you want to view network flow data. Otherwise, select Default.
Address: Specify the IP address for which you want to view the network flow data. By
default, Sentinel provides the network flow data for the entire network.
Time Range: Specify the time range for which you want to view the network flow data.
3. Click Monitor NetFlow.
 To view network flow data for a specific event:
1. Perform a search to view the desired events.
2. In the search results, click the NetFlow icon for the Source IP address or the
Destination IP address of the event.
Sentinel provides a graphical representation the network flow data, which automatically refreshes
every 10 minutes. You can hover the mouse over the graphs to monitor the incoming and outgoing
number of bytes, packets, and flows for the specified tenant or IP address. Sentinel also helps you
analyze the network traffic by providing a summary of the top 10 hosts and top 10 ports sending data
to the specified tenant or IP address. Similarly, you can view the top 10 hosts and top 10 ports to
which the specified tenant or IP address is sending data.
If you want to analyze the data in detail for a specific time, you can take a snapshot of the graph and
analyze the data at the desired time.You can also compare the changes in the network traffic before
and after the security event.
For more information about visualizing and analyzing NetFlow data, see the video How to Investigate
a UDP Flood / Denial-of-Service (DoS) Attack.
Visualizing and Analyzing Network Flow Data
97
98
Visualizing and Analyzing Network Flow Data
9
Configuring Dynamic Lists
9
Dynamic Lists help you store string elements, such as IP addresses, server names, or user names.
You can use these lists within a correlation rule for a quick lookup to see whether an incoming event
includes an element from the Dynamic List. Because Dynamic Lists are also the only way to share
the state between multiple correlation rules, they are useful when you want to co-ordinate between
different rules or the same rule at different times. For information about correlation rules, see
Chapter 5, “Correlating Event Data,” on page 47.
For example, you can use the following types of Dynamic Lists:
 Terminated user lists
 Suspicious user watchlist
 Privileged user watchlist
 Authorized ports and services list
 Authorized server list
NOTE: You must have the Manage Correlation Engine and Rules permission to create and manage
Dynamic Lists.
Working with Dynamic Lists
You can create Dynamic Lists either in the correlation rule Expression Builder while creating
correlation rules or in the All Dynamic Lists user interface. To create and manage Dynamic Lists, in
the Sentinel Main interface, click Correlation. In the Dynamic Lists section, click All Dynamic Lists.
NOTE: Specify an appropriate name for the Dynamic List and list item. Since the Dynamic Lists are
associated to several correlation rules, you cannot modify the list name and the list item name later.
Adding List Items
When creating Dynamic Lists, you can specify the default life span for the list items. The life span of
the list items is considered from the date and time you create or modify them. If you do not want the
list items to be deleted, you can set the list item to never expire while adding them.
You can add list items in any of the following ways:
 In the All Dynamic Lists page, open the dynamic list to which you want to add list items. Click
Items > Add.
 Import from a CSV or a TXT file. Consider the following when importing list items:
 The file can be in <value, expiration_date> format. Expiration date is optional and it must be
either 0 or 1. 0 indicates that the list item will expire and 1 indicates that the list item will
never expire. The default value is 0.
 The number of list items do not exceed the list items limit for the dynamic list. If the limit
exceeds, Sentinel does not import the list items.
Configuring Dynamic Lists
99
If the list items being imported already exist in the dynamic list, Sentinel updates the life span of
the list items with the value specified in the file.
 Set the correlation rule action to Add to Dynamic List. The correlation rule adds a list item to the
selected dynamic list when the rule fires. For more information, see “Associating Actions to a
Rule” on page 64.
Exporting List Items
If you have multiple Sentinel servers, you do not need to manually create list items on each server.
You can reuse existing list items in other Sentinel servers by using the Export option as needed.
The Export option exports all the list items of a dynamic list. You cannot export only selected list
items.
Deleting Dynamic Lists and List Items
You can delete only the dynamic lists that are not being used by correlation rules or actions.
The list items can be deleted either manually or automatically in any of the following ways:
 Delete manually.
 When a correlation rule, whose action is set to Remove from Dynamic List, fires. For more
information, see “Associating Actions to a Rule” on page 64.
 When the list item’s life span expires.
100
Configuring Dynamic Lists
10
Leveraging Identity Information
10
This section provides information about integrating Sentinel with identity management systems.
 “Overview” on page 101
 “Searching and Viewing User Identities” on page 101
Overview
Sentinel provides an integration framework to identity management systems to track the identities of
for each user account and what events those identities have performed.
This integration provides functionality on several levels:
 The Identity Browser provides the ability to look up the following information about a user:
 Contact information
 Accounts associated with that user
 Most recent authentication events
 Most recent access events
 Most recent permissions changes
 The Identity Browser lets you do a lookup from events
 Reports and Correlation rules provide an integrated view of a user's true identity, even across
multiple systems on which the user has separate accounts. For example, accounts like
COMPANY\testuser; > cn=testuser,ou=engineering,o=company, and TUser@company.com can
be mapped to the actual person who owns the accounts.
By displaying information about the people initiating a given action or people affected by an action,
incident response times are improved and behavior-based analysis is enabled.
NOTE: Only administrators can integrate Sentinel with identity management systems. For more
information, see “Integrating Identity Information” in the NetIQ Sentinel Administration Guide.
Searching and Viewing User Identities
The Identity Browser in Sentinel allows you to search and view user profiles of the identities in the
Sentinel database that have been synchronized from the identity management system. In addition to
information from the identity management system, the Identity Browser also shows recent user
activity that has been collected through the Sentinel Collectors.
Accessing the Identity Browser
From Sentinel Main, click People on the left side.
The Identity Browser is displayed.
Leveraging Identity Information
101
Performing a Search
The Identity Browser allows you to search for people to view what they have been doing. You can use
the search box or click the arrow next to the search box for more options. As you start typing the
information in the search field, the data is automatically displayed.
1 Access the Identity Browser.
For more information, see “Accessing the Identity Browser” on page 101.
2 Search for a user by typing in the search box. The search box is dynamic
or
Click the arrow next to the search box to display more search fields.
You can type letters to view all identities whose first or last name starts with the letters. For
example, if you type the names Abraham, Abdullah, and so on are matched. For more
information, see “Searching” on page 102.
3 If you used the search box, skip to Step 5. Otherwise, specify the search value for the users you
are searching for.
For more information, about the search fields, see “Using the Search Fields” on page 103.
4 Click Search to perform the search, then click Close.
5 Click on the user name to view the information about the user.
6 Proceed to “Viewing Profile Details” on page 103 to view the details about the user.
Searching
You can search for users by using the search box or by using the search fields.
 “Using the Search Box” on page 102
 “Using the Search Fields” on page 103
Using the Search Box
The search box automatically uses the following logic to interpret the text you enter:
 All letters and no spaces searches for the given name or surname.
 All letters and a space between letter groups searches for the given name and surname. The
surname match is a starts-with, unless there is a trailing space.
 All letters with a comma in the middle is a match of the surname and given name. The given
name match is starts-with unless there is a trailing space.
 Anything with a @ in it is a starts-with match for e-mail address.
 All digits, or letters and digits but no telephone punctuation characters is a starts-with match for
workforce ID.
 Digits in addition to a leading +, and spaces, hyphens, periods, or parentheses is a starts-with
match for a telephone number.
 Alphanumeric, or all numeric with no spaces, or all numbers with spaces is a starts-with match
for the workforce ID.
102
Leveraging Identity Information
Using the Search Fields
You can search for many values, including custom values, in the search fields. The following is a list
of the fields you can search:
 Given Name
 Surname
 Telephone
 E-mail
 Position
 Department
 Office Location Code
 Workforce ID
 Vault Name
 Customer ID
 DN
 Custom Value Name
 Custom Value
Viewing Profile Details
After you have performed the search, (see “Performing a Search” on page 102), the user name,
photo, position, department, e-mail, and telephone number are displayed.
Figure 10-1 User Information Displayed
Click Profile to see detailed information about the user and all of the accounts that belong to this user.
Leveraging Identity Information
103
You can use the clipboard functionality to copy the data of the user’s profile and account information.
Click the clipboard icon to the left of the user’s photo and their information is now in the clipboard. You
can paste this information into a text editor.
Viewing Activity
You can view the recent activity of the user through the Identity Browser.
 Authentication information
 Access events
 Permission changes
Select one or more of these options, then click Show Recent Activity.
104
Leveraging Identity Information
11
Manually Performing Actions on Events
1
Administrators can configure event routing rules to automatically perform specific actions on events,
as described in “Configuring Event Routing Rules” in the NetIQ Sentinel Administration Guide.
However, Sentinel allows users to manually perform actions on events returned in searches.
This allows users to perform the desire actions as they are viewing events.
 “Accessing Event Actions” on page 105
 “Prerequisites for Executing Actions on Events” on page 105
 “Assigning Actions to Events” on page 105
 “Configuring Event Actions” on page 106
Accessing Event Actions
To access the event actions:
1 From Sentinel Main, click Event Actions on the left.
If Event Actions is not displayed, you do not have the proper rights to access this feature.
Prerequisites for Executing Actions on Events
In order to manually assign actions to select events, you must perform the following tasks:
 Configure Actions: You must configure the actions that can be executed for the select search
events. For more information, see “Configuring Actions” in the NetIQ Sentinel Administration
Guide.
 Configure the Integrators for the Actions: There are default actions available to perform.
However, the integrators for these actions must be configured before the actions can be
executed. For more information, see “Configuring the Default Integrators” in the NetIQ Sentinel
Administration Guide.
 Perform a Search: You must have the results of a search available in order to perform actions
on selected events. For more information about searching, see Chapter 3, “Searching Events,”
on page 21.
Assigning Actions to Events
1 Access Event Actions in the Sentinel Main interface.
For more information, see “Accessing Event Actions” on page 105.
2 Perform a search.
If you have not performed a search, you cannot execute an action.
3 Select the events in the search to perform actions on.
4 In the Actions field, select the desired action from the drop-down box.
Manually Performing Actions on Events
105
You can add or remove items from this list. For more information, see “Configuring Event
Actions” on page 106.
5 Click Execute.
6 In the Results field, view the results of the action.
Configuring Event Actions
Administrators can control what actions can manually performed on events.
 “Creating a New Event Action” on page 106
 “Cloning an Event Action” on page 106
 “Moving an Event Action” on page 107
 “Deleting an Event Action” on page 107
Creating a New Event Action
If you have imported new action plug-ins into Sentinel and you want to create an event action for the
action plug-in:
1 Access the Sentinel Control Center.
1a From Sentinel Main, in the tool bar, click Applications.
1b Click Launch Control Center.
1c Click Yes to accept the security certificate.
1d Specify a username and password of a user that has rights to access the SCC, then click
Login.
1e Click Accept or Accept Permanently to accept the security certificate and display the SCC.
2 Click the Configuration tab.
3 From the menu, click Configuration > Event Actions Configuration.
4 Click Add to add a new action.
5 Use the following information to create the new event action:
Name: Specify a unique name for the event action.
Description: Specify a description for the new event action.
Action: Select the desired action from the drop-down list.
6 Click Add Action.
7 Create a new action by following the instructions in “Adding an Action” in the NetIQ Sentinel
Administration Guide.
Cloning an Event Action
You can clone an existing event action add give it another name.
1 Access the Sentinel Control Center. For more information, see Step 1 in “Creating a New Event
Action” on page 106.
2 Click the Configuration tab.
3 On the menu, click Configuration > Event Actions Configuration.
106
Manually Performing Actions on Events
4 Select an event action, then click Clone.
5 Change the name to a unique name, then click OK.
Moving an Event Action
You can display the event actions in any order. The order in the Event Actions Configuration page is
the order that is shown in the Sentinel Main interface.
To move event actions:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Creating a New Event
Action” on page 106.
2 Click the Configuration tab.
3 On the menu, click Configuration > Event Actions Configuration.
4 Select the event action you want to move, then click Up or Down until the event action is in the
correct location.
Deleting an Event Action
1 Access the Sentinel Control Center. For more information, see Step 1 in “Creating a New Event
Action” on page 106.
2 Click the Configuration tab.
3 From the menu, click Configuration > Event Actions Configuration.
4 Select the event action you want to delete, then click Delete.
5 Click Yes to confirm the deletion.
Manually Performing Actions on Events
107
108
Manually Performing Actions on Events
12
Configuring Tags
12
Tags are user-defined values that can be used to logically group data collection objects such as event
sources, event source servers, Collector Managers, Collector plug-ins, event routing rules, report
templates, and report results. Tags help you to filter object lists for the data collection objects and also
to augment incoming data. You can search for events, report templates, and report definitions that are
tagged with a particular tag.
NOTE: Only users in the Manage Tags role can create and manage tags.
 “Overview” on page 109
 “The Tags Interface” on page 109
 “Creating a Tag” on page 110
 “Managing Tags” on page 110
 “Performing Text Searches for Tags” on page 111
 “Deleting Tags” on page 111
 “Associating Tags with Objects” on page 111
 “Viewing Tagged Events” on page 113
Overview
You can associate objects with more than one tag. You can, for example, create tags related to
regulations (PCI) or compromised systems or network infrastructure such as routers, switches, and
firewalls. Some organizations need to define data retention or data viewing policies based on the
geographic location, so tags can be used to tag event sources based on different locations.
When ESM objects such as event sources, event servers, Collector Managers, or Collector plug-ins
are tagged, all the events from those ESM objects are tagged with that value. The tag value is placed
in a reserved variable, rv145. However, events generated before tagging the ESM objects are not
tagged. Sentinel does not perform retroactive tagging of data that is already stored because it is not
an accepted practice to modify events that are already stored.
You must have the appropriate permission to view events that are tagged with specific tags. For
example, only users in the PCI Compliance Auditor role can view events that are tagged with at least
one of the regulation-related tags such as PCI, SOX, HIPAA, NERC_CIP, FISMA, GLBA, NISPOM,
JSOX, and ISO/IEC_27002:2005.
The Tags Interface
The Tags interface lists the tags available in the system and allows you to manage the tags. You can
perform text-refined searches to find the tags that you are looking for. The interface also provides
options such as maintaining a list of favorite tags and searching tagged events.
As you mouse over a tag, you can see the icons available to manage the tag. The number next to
each tag indicates the number of objects associated with the tag. For more information on creating
new tags, see “Creating a Tag” on page 110.
Configuring Tags
109
The Tag
icon is available in various parts of the Sentinel interface, which allows you to quickly add
tags to the desired data collection objects such as event sources, event source servers, Collector
Managers, Collector plug-ins, report templates, and report results. When you click the Tag
the Tags dialog box is displayed that allows you to select tags and to create new tags.
icon,
Creating a Tag
1 From Sentinel Main, select Tags in the navigation panel on the left or click the Tag
icon in the
appropriate data object interface to which you want to associate tags.
2 Click Create.
3 Specify a name for the tag.
Tags have the following naming conventions, and a warning message is displayed if the name
you specify does not comply with the following conventions:
 Tag names should not be more than 20 characters.
 There should not be any white space as part of the tag name.
 A tag name is not case-sensitive. You cannot create two tags with identical names except
for capitalization. For example, you cannot have the tag names IDM and idm, because both
are perceived as the same name.
4 Specify an optional description for the tag.
If the tag name is available, a message is displayed.
If a tag with the same name already exists, a message is displayed indicating the name is not
unique. You must specify a different name for the tag.
5 Click Save.
Managing Tags
 “Sorting Tags” on page 110
 “Adding and Removing Tags from Favorites” on page 111
 “Viewing and Modifying Tags” on page 111
Sorting Tags
You can sort tags either based on their names or based on the number of objects associated with the
tags.
1 From Sentinel Main, select Tags in the navigation panel, then click More.
2 (Conditional) To sort the tags in the alphabetical order, select Sort by Name.
3 (Conditional) To sort the tags based on the number of objects associated with them, select Sort
by Count.
The Tags are sorted according to the selection.
110
Configuring Tags
Adding and Removing Tags from Favorites
You can add your frequently used tags to the Favorites section so that it is easier to locate them and
associate them with objects. When a tag is added to the Favorites section, it is removed from the
Other section.
1 From Sentinel Main, select Tags in the navigation panel on the left.
2 To add or remove a tag from Favorites, select the tag, then click the Favorites
icon.
Viewing and Modifying Tags
You can modify only the description of a tag.The tag name cannot be modified because it might be
used to tag events and other data collection objects, and it is not an accepted practice to modify
events that are already stored. Therefore, to modify the name of a tag, you must create a new tag.
1 From Sentinel Main, select Tags in the navigation panel on the left.
2 Select the tag that you want to edit, and click the Edit
icon.
3 Modify the description as necessary, then click Save.
Performing Text Searches for Tags
This option is useful when you want to look for a particular tag.
1 From Sentinel Main, select Tags in the navigation panel on the left.
2 To search for a particular tag, specify the name or description of the tag or a keyword. To search
for multiple tags, specify the tag names separated by the space character.
The tag that matches the keyword is displayed.
Deleting Tags
1 From Sentinel Main, select Tags in the navigation panel on the left.
2 Select the tag that you want to delete, then click the Delete
icon.
The Sentinel tag is a system tag that tags all Sentinel internal events, and cannot be deleted.
3 Click Delete to confirm deletion.
Associating Tags with Objects
You can associate tags with event sources, event source servers, Collector Managers, Collector
Plug-ins, event routing rules, and reports and report templates. You can add more than one tag to a
data collection object. However, the rv145 field, which stores the tag value, can hold a maximum of
256 characters. Therefore, the maximum number of tags that you can associate with an object
depends on the length of the tag name.
 “Associating Tags with Event Routing Rules” on page 112
 “Associating Tags with Event Sources” on page 112
 “Associating Tags with Collector Managers” on page 112
 “Associating Tags with Event Sources Servers” on page 112
Configuring Tags
111
 “Associating Tags with Collector Plug-Ins” on page 112
 “Associating Tags with Report Results and Report Definitions” on page 113
Associating Tags with Event Routing Rules
1 From Sentinel Main, click Routing in the toolbar, then click Create.
2 Specify a name and filter criteria for the rule.
3 Click Select tag, then select the tags that you want to associate with the rule.
4 Click Set.
Associating Tags with Event Sources
1 From Sentinel Main, select Collection > Event Sources.
2 Select the event sources that you want to associate with the tag.
3 Select the Configure
icon, then select Tags.
4 Select the tags you want to associate, then click Set.
Associating Tags with Collector Managers
1 From Sentinel Main, select Collection > Event Sources.
2 From the Collector Managers section, select one or more of the Collector Managers that you
want to associate with the tag.
3 Select the Configure
icon, then select Tags.
4 Select the tags you want to associate, then click Set.
Associating Tags with Event Sources Servers
1 From Sentinel Main, select Collection > Event Sources.
2 From the Event Source Servers section, select one or more event source servers that you want
to associate with the tag.
3 Select the Configure
icon, then select Tags.
4 Select the tags you want to associate, then click Set.
Associating Tags with Collector Plug-Ins
1 From Sentinel Main, select Collection > Event Sources.
2 From the Collector Plugins section, select one or more of the Collector plug-ins that you want to
associate with the tag.
3 Select the Configure
icon, then select Tags.
4 Select the tags you want to associate, then click Set.
112
Configuring Tags
Associating Tags with Report Results and Report
Definitions
NOTE: When a tag is set on a report definition, the report results under the report definition inherit the
tag by default. Inherited tags for a report result appear disabled in the Tag selector dialog box.
1 From Sentinel Main, select Reports in the navigation panel on the left.
2 Select the report result or the report definition that you want to associate with a tag.
3 Do one of the following:
 Select Tags from the more drop-down list.
 Click Edit at the bottom left pane.
4 Select one or more tags that you want to associate with selected reports.
5 Click Set.
Viewing Tagged Events
1 From Sentinel Main, do any of the following:
 From the Tags panel, select the tag for which you want to view events, then select Search.
 In the Search field, click the Tag
Search.
icon, select the desired tags, then click OK. Click
 In the Search field, specify rv145:<tagname> or @<tagname> as the search criteria, then
click Search.
Configuring Tags
113
114
Configuring Tags
13
Reporting
13
Reports help you analyze events to assess your compliance regulatory requirements, security best
practices, and corporate IT policies. You can use reports to demonstrate compliance and manage
information security risk.
Reports emphasize the event data and help you analyze events such as user account visibility,
detection of possible security violations, account compromises, network security problems, and any
other undesired activities. By analyzing reports, you can configure appropriate correlation rules and
actions to prevent any possible non-compliance activities and vulnerabilities.
Consider a scenario where you have an IT policy that states to remove access rights of all employees
to information and information processing facilities upon termination of their employment. To view all
deleted, and disabled user accounts, and revoked accesses, you can run a report that displays the
desired information in a few clicks. You can also schedule the report to run periodically at specific
intervals.
You can generate various types of reports for administration and auditing purposes, including the
following:
 Administrative reports: Helps you to administer Sentinel and analyze Sentinel's internal audit
events.
 Network Security reports: Helps you to track and analyze traffic trends, network threats, and
other vulnerabilities.
 Threat Intelligence reports: Helps you to analyze complex security threats.
 Identity Tracking reports: Helps you to analyze the events associated with the user identities.
 PCI DSS reports: Helps you demonstrate that your enterprise is in compliance with PCI DSS
standards.
 ISO 27000 Series reports: Helps you to generate reports to demonstrate that your enterprise is
in compliance with ISO 27000 series standards.
This chapter provides information about the following:
 “Creating Reports” on page 115
 “Scheduling Reports” on page 116
 “Working with Reports” on page 117
 “Rebranding Reports” on page 118
Creating Reports
A report is a template that is combined at run-time with a number of criteria, such as time parameters,
user security filters, other filter criteria for the events to be displayed in the report. A single report may
have numerous associated report results. Reports can range from a simple list of events to multiple
graphs and tables.
You can manage the reports and report results in the Reports and Searches panel. To manage
reports, you must have the Manage Reports permission.
Reporting
115
Sentinel provides a variety of Solution Packs that enforce a specific business or technical policy.
Some of the Solution Packs are available by default when you install Sentinel. These Solution Packs
include various reports that you can use to solve your business needs.
You can also create new reports in the following ways:
 Using an Existing Report: You can create a new report based on existing reports. These
reports include predefined criteria for the events to be displayed in the report. To create a new
report, select the report based on which you want to create a new report, click Create report, and
then add additional criteria to suit your requirements.
NOTE: You can create new reports only from reports created by users in the same role as yours.
 Using a Search Query: You can save your search query as a new report. For more information,
see “Saving a Search Query as a Report Template” on page 27.
 Importing from Solution Packs: You can update or install new Solution Packs to get new and
updated reports. To download the new and updated Solution Packs, visit the Sentinel Plug-ins
website. For information about installing and updating solution packs, see Managing Solution
Packs in the NetIQ Sentinel Administration Guide.
To import new and updated reports, you must have the Import Reports permission. To import
new and updated reports, click Import Reports and Searches.
 Using the Sentinel SDK: You can use the Sentinel SDK to modify or write your own reports. For
more information, see the Sentinel SDK website.
Scheduling Reports
To view the report result, you must run the report. All reports have a sample report result. You can use
the sample report to preview how the actual report result looks like when you run the report. To run
the report, you must have the Run reports permission.
You can run the report immediately or schedule it to run periodically. Click the Run icon and specify
the appropriate information to schedule a report. By default, Sentinel saves the report in the PDF
format.
Reports run asynchronously.Therefore, you can simultaneously perform other tasks in the Sentinel
Main interface while the report generation is in progress. If the Sentinel server is restarted while the
report generation is still in progress, you can either cancel or reschedule report generation. If you
reschedule the report, it runs with the same parameters that you used initially. If you schedule a report
with a relative time setting, such as Week to Date, the time period for re-running the report is based
on the current date and time and not the date and time when you initially scheduled the report.
NOTE: The report data in the PDF file will be different than the data in the reports that are run with the
Now option. The report data in the PDF file are for the time range that you specified while scheduling
a report definition. When you schedule a report definition with the Now option, the report includes
events from midnight to the time you scheduled the report definition.
Scheduling Reports across Sentinel Servers
You can schedule reports on Sentinel servers distributed across different geographic locations. For
more information, see “Configuring Data Federation” in the NetIQ Sentinel Administration Guide.
116
Reporting
Saving Reports in the CSV Format
You can also save a report in the CSV format along with the existing PDF format. This requires
additional configuration in the Sentinel server. Only users in the administrator role can perform the
additional configuration. For more information, see “Generating a Report in CSV Format” in the NetIQ
Sentinel Administration Guide.
Working with Reports
The data that you view in reports depends on the security filter applied to your role. For example, if
the security filter for your role is set to view events of severity 1 to 3, your report results will include
only those events, although the report parameters allow severity 4 and 5 events also.
As you work with reports, you can perform several tasks including the following:
 Finding Reports: Sentinel provides a large number of reports. You can use one of the following
ways to easily find the reports you are interested in:
 Using a particular keyword in the report name or description.
 Using Tags.
 Viewing reports belonging to a specific category: Scheduled or Unread.
 Grouping: To simplify report management as the number of reports grows over time, by default,
Sentinel groups the reports by Category.
You can change the grouping to None if you want to list all your reports and searches under one
heading. To change the grouping, click More options, select Group by, and then select the
necessary option.
 Tagging: You can associate reports with existing tags. When a tag is set on a report, the report
results associated with the report inherit the tag by default.
 Marking reports and searches as Favorites: You can mark the most frequently used reports
and searches as Favorites to make them easier to find. You can also store them in folders to
locate and manage them easily.
 Drilling down into the reports to further analyze the data: You can view events directly for a
report without scheduling the report. The search results provide a preview of what to expect
when you generate a report and the ability to investigate further. To view events for a report, click
Search Events.
 Sharing reports with other roles: The Share functionality allows you to share reports with
other roles and also control who can access your reports.
For example, the out-of-the-box report templates are accessible to all Sentinel users. Consider a
scenario where you have several groups in your organization such as system administrators,
database administrators. Because of the sensitivity of the audit data available in the report
results when you run the out-of-the-box report templates, you may want to ensure that these
administrators do not gain access to any unauthorized data. In such a scenario, you can restrict
the report templates visibility only to you, to users in your role, or to users in selected roles.
NOTE: Only users in the Administrator role can restrict the visibility of the out-of-the-box reports.
By default, the reports that you create or import from Solution Packs are visible only to you and
to users in the Administrator role. You can share your reports with other roles as necessary
without transferring the complete ownership of the reports.
Reporting
117
For example, consider a scenario where there is a dedicated audit team in your organization
whose primary job is to analyze and validate the accuracy of reports. You may want them to only
view your reports but not modify or delete reports. In such a scenario, you can share your reports
with the audit team. The audit team will only be able to view or run the reports depending on the
permission they have. However, they will not be able to modify or delete reports.
To share reports, you must have the Share reports permission. To share reports with users in
other roles, you must have the Manage roles and users permission in addition to the Share
reports permission. You can share only the reports that you create or import from Solution
Packs. You cannot share reports that other users have shared with you. To share a report, select
the report you want to share, click the Share icon, and select the relevant sharing option.
The events in the report results that users, with whom you have shared reports, can view depend
on the permission their role has. For example, if their role has permission to view only events of
severity 4 and 5, the report results include only those events.
If the user account of a report owner is deleted, reports that are set as Private are deleted. The
ownership of all the shared reports is transferred to the admin user. If that report owner had
shared any reports with you, you can no longer view those shared reports unless the admin user
shares those reports with you.
Rebranding Reports
Sentinel delivers an out-of-the-box white label report template as part of the Sentinel Core Solution
Pack. By customizing this template, you can rebrand the reports with your own header, footer, and
logo. Only users in the administrator role can customize the white label report template.
For more information about customizing the white label report template, see Rebranding Reports in
the NetIQ Sentinel Administration Guide.
118
Reporting
14
Viewing Compliance to Configuration
Policies
14
Sentinel is a compliance monitoring system that helps you verify whether your enterprise is compliant
with internal policies, information security standards such as PCI DSS and ISO 27000 series, and
government regulations such as Sarbanes-Oxley, HIPAA, GLBA, and FISMA.
Sentinel extends its compliance monitoring capability by integrating seamlessly with your existing
security management solutions, such as NetIQ Secure Configuration Manager (SCM). Integration
with Secure Configuration Manager helps you to assess system configurations against regulatory
requirements, security best practices, and corporate IT policies to demonstrate compliance and
manage information security risk. This integration helps you to view the security and audit information
from both Sentinel and Secure Configuration Manager in a single interface.
Sentinel is auto-configured to receive events from Secure Configuration Manager. You must
configure Sentinel to receive compliance details associated with the Secure Configuration Manager
events. For information about configuring Sentinel to receive compliance details from Secure
Configuration Manager, see “Viewing Compliance to Configuration Policies ” in the NetIQ Sentinel
Administration Guide.
Viewing Secure Configuration Manager Events and
Compliance Details
To view the compliance details, search for Secure Configuration Manager events by using the
appropriate query, for example, (sev:[0 TO 5]) AND pn:(Secure OR Configuration OR
Manager), then click the View compliance details icon associated with the event. For more
information about searching events in Sentinel, see “Searching Events” on page 21.
Compliance details provide information about compliance to configuration policies of various assets
in your IT environment based on rules configured in the Secure Configuration Manager. Compliance
details also provide information about the risk to the organization because of the non-compliance of
the assets and the validation results of security checks in the policies.The compliance details can be
based on assets, policy, or both assets and policy. The compliance details provides information about
the following:
 Introduction: This section provides information about the assets, user accounts, policy, and the
timestamp when the compliance was checked.
 Risk Analysis: This section displays charts representing the risks involved based on the
compliance status of the assets and the importance of the asset in the organization.
 Security Check Details: This section displays the validation results for security checks in the
policies.
For more information about understanding compliance details, see Understanding Report Results in
the NetIQ Secure Configuration manager User Guide.
Viewing Compliance to Configuration Policies
119
120
Viewing Compliance to Configuration Policies
15
Viewing Change Guardian Events
15
If the Change Guardian server is configured to send its events to Sentinel, you can view Change
Guardian events in Sentinel. To verify whether Change Guardian is configured, contact your system
administrator.
To view the Change Guardian events and the event details, run a search by using the appropriate
query, for example, pn:ChangeGuardian, then click Search. For more information about searching
events in Sentinel, see “Searching Events” on page 21.
Change Guardian events indicates activities such as:
 Changes or access to critical files, platforms and systems
 Activities of privileged users
Each event provides detailed information about the file that was changed, the actual changes made
to the file, and so on. For more information about the event details, see Understanding Event
Information in the Change Guardian User Guide.
To view the event details, click the Change Guardian icon associated with the event.
Viewing Change Guardian Events
121
122
Viewing Change Guardian Events
16
Configuring Incidents
16
In Sentinel, a set of related events (for example, a possible attack) can be grouped together form an
incident. An incident in open state alerts you to investigate, resolve, and close the incident. For
example, the resolution to an attack might be to close a port, block a source IP, or rebuild a machine.
Incidents are created automatically as a result of a correlation rule being triggered, or they are
created manually by a security analyst monitoring incoming data or querying past data.
 “Accessing Incidents” on page 123
 “Creating Incidents” on page 123
 “Managing Incidents” on page 124
 “Adding an Incident View” on page 126
Accessing Incidents
You access the incidents through the Sentinel Control Center. You need to have appropriate
permissions to access this tab. Only an Administrator has controls to enable or disable access to the
features of incidents for a user.
1 From Sentinel Main, click Applications in the toolbar.
2 Click Launch Sentinel Control Center.
3 Log in to the Sentinel Control Center as a user with permissions to access incidents.
4 Click Incidents.
The Incidents are displayed.
Creating Incidents
1 Access the Incidents tab in the Sentinel Control Center.
For more information, see “Accessing Incidents” on page 123.
2 In the menu, click Incidents > Create Incident.
or
Click the Create Incident
button in the toolbar.
3 Use the following information to create the incident:
Title: Specify the title of the incident.
State: Select the state of the incident from the drop-down list.
Severity: Select the severity of the incident from the drop-down list.
Priority: Select the priority of the incident from the drop-down list.
Category: Select the category of the incident from the drop-down list
or
Create your own category by clicking the button next to the Category field, then click Add. You
must specify a name and a description of the new category.
Configuring Incidents
123
Responsible: Select the user that is responsible to investigate and close the incident.
Description: Specify a description of the incident.
Resolution: Specify the steps required to resolve the incident.
4 Click Create.
The Incident ID is automatically generated after you click Create.
You can also create incidents from the Sentinel Main interface. For more information, see “Creating
an Incident” on page 33.
After the incident is created, proceed to “Managing Incidents” on page 124 to manage the incident.
Managing Incidents
 “Viewing an Incident” on page 124
 “Attaching Workflows to Incidents” on page 125
 “Adding Attachments to Incidents” on page 125
 “Adding Notes to Incidents” on page 125
 “Executing Incident Actions” on page 125
 “E-mailing an Incident” on page 126
Viewing an Incident
1 Click Incidents in the Sentinel Control Center.
For more information, see “Accessing Incidents” on page 123.
2 From the menu, click Incidents > Display Incident View Manager
or
Click the Display Incident View Manager
button in the toolbar.
3 Select the desired Incident in the Incidents View window.
When you view an incident, you see the tabs listed below where you can perform Incident related
activities. As you investigate and remediate an Incident, additional information can be added to these
tabs.
Events: Lists events that triggered the incident, correlation rule, or alerts.
Assets: Lists assets affected by the events of this Incident.
Vulnerability: Lists asset vulnerabilities.
Advisor: Displays asset attack information.
iTRAC: Allows you to add a workflow to Incident.
History: Lists the activities performed on the current Incident.
Attachments: Allows you to add an attachment to the Incident created in the system.
Notes: Allows you to add notes to the Incident. If the incident was created as a result of alerts
escalation, by default, this tab displays the comments associated with alerts and the reason for
escalation.
124
Configuring Incidents
Attaching Workflows to Incidents
1 In the Incidents View window, select the desired Incident.
2 Click the iTRAC tab.
3 Select a workflow from the iTRAC process drop-down list.
For more information about workflows, see Chapter 17, “Configuring iTRAC Workflows,” on
page 127.
4 Click Save.
You can attach only one workflow to an Incident.
Adding Attachments to Incidents
1 In the Incidents View window, select the desired Incident.
2 Click the Attachments tab, then click Add.
3 Click Browse, then navigate to the attachment and select it.
4 Specify the required information, or accept the default entries.
5 Click OK, then click Save.
You can right-click the attachment to view it or save it to your local hard drive.
Adding Notes to Incidents
1 In the Incidents View window, select the desired Incident.
2 Click the Notes tab, then click Add.
3 Specify your notes, then click OK.
4 Click Save to update the Incident.
To edit or delete the note, select a note in the Notes tab of the Incident window, right-click the
note, then select edit or delete.
Executing Incident Actions
Any configured Javascript action or iTRAC activity can be executed on an Incident.
1 In the Incidents View window, select the desired Incident.
2 In the menu, click Action > Execute Incident Action.
or
Click the Execute Incident Action button.
3 Select an Action or click the Add Action button to create a new one.
4 Click Execute.
If the action is a Javascript Action, a window opens to show the progress of the action.
5 To add the command output to the Incident, click the Attach to Incident button.
The action output is saved and can be viewed from the Attachments tab of the Incident.
Configuring Incidents
125
E-mailing an Incident
To e-mail an Incident using the preinstalled E-mail Incident action, you must have an SMTP Integrator
configured with valid connection information and with the property SentinelDefaultEMailServer set to
“true”. For more information, see the SMTP Integrator documentation available at the Sentinel Plug-in
Web site.
1 In the Incidents View window, select the desired Incident.
2 Click the Email Incident
icon.
3 Specify the required information.
4 Select which HTML attachments should be included in the mail message: the events included in
the incident, assets, vulnerabilities, Advisor attacks, incident history, attachments, and notes.
5 Click OK.
Adding an Incident View
1 Click the Incidents tab in the Sentinel Control Center.
For more information, see “Accessing Incidents” on page 123.
2 Click the Manage Views drop-down, then select Add View.
3 Specify a name in the Option Name field. Click each button (listed below) to specify the options.
 Fields: The variables of the events attached to Incidents are displayed as fields. By default,
all the fields are arranged as columns in the Incidents View. You can add or remove
columns, and arrange the order of the columns by using the up and down arrows.
 Group By: Allows you to set rules to group Incidents.
 Sort: Allows you to set rules to sort the Incidents.
 Filter: Allows you to set filters. Only Incidents that match the filter are displayed in the
Incidents View.
 Leaf Attribute: Allows you to select attributes from the list, which is displayed as the first
column in the Incidents View.
4 Click Save.
126
Configuring Incidents
17
Configuring iTRAC Workflows
17
This chapter provides information about using iTRAC workflows to automate and track incidents.
 “Overview” on page 127
 “Accessing the iTRAC Administration Tools” on page 128
 “Using the Template Manager” on page 129
 “Template Builder Interface” on page 130
 “Creating a Template” on page 132
 “Managing Templates” on page 132
 “Steps” on page 133
 “Adding Steps to a Workflow” on page 137
 “Managing Steps” on page 138
 “Transitions” on page 141
 “Activities” on page 147
 “Creating iTRAC Activities” on page 149
 “Managing Activities” on page 150
 “Managing iTRAC Roles” on page 151
 “Process Management” on page 152
Overview
iTRAC workflows are designed to provide a simple, flexible solution for automating and tracking an
enterprise’s incident response processes. iTRAC leverages Sentinel’s internal incident system to
track security or system problems from identification (through correlation rules or manual
identification) through resolution.
Workflows can be built using manual and automated steps. Advanced features such as branching,
time-based escalation, and local variables are supported. Integration with external scripts and plugins allows for flexible interaction with third-party systems. Comprehensive reporting allows
administrators to understand and fine-tune the incident response processes.
NOTE: Access to manage iTRAC templates, activities, and processes can be enabled on a user-byuser basis by any user with the ability to change user permissions.
The iTRAC system uses three Sentinel objects that can be defined outside the iTRAC framework:
 Incident: Incidents within Sentinel are groups of events that represent an actionable security
incident, plus associated state and meta-information.
Incidents are created manually or through Correlation rules.They can be associated with a
workflow process. They can be viewed on the Incidents tab.
Configuring iTRAC Workflows
127
 Activity: An activity is a predefined automatic unit of work, with defined inputs, command-driven
activity, and outputs (for example, automatically attaching asset data to the incident or sending
an e-mail).
Activities can be included in a workflow template and executed during workflow processes, or
they can be executed within an incident.
 Role: Sentinel users can be assigned to one or more roles. Manual steps in the workflow
processes can be assigned to a role. For more information, see “Managing iTRAC Roles” on
page 151.
iTRAC workflows have four major components that are unique to iTRAC:
 Step: A step is an individual unit of work within a workflow; including manual steps, decision
steps, command steps, mail steps, and activity-based steps. Each step displays as an icon
within a given workflow template.
 Transition: A transition defines how the workflow moves from one state (activity) to another. A
transition is determined by an analyst action, by the value of a variable, or by the amount of time
elapsed.
 Templates: A template is a design for a workflow that controls the flow of execution of a process
in iTRAC. The template consists of a network of manual and automated steps that combine
activities and criteria for transition between the steps.
Workflow templates define how an incident is responded to after a process based on that
template is instantiated. A template can be associated with many incidents.
 Processes: A process is a specific instance of a workflow template that is actively being tracked
by the workflow system. It includes all the relevant information for the instance, including the
current step in the workflow, the associated incident, the results of steps, attachments, and
notes. Each workflow process is associated to one incident.
NOTE: On a system with 16GB of RAM and 8 core CPU, you can run a maximum of 1000
processes on a single Sentinel server instance.
Accessing the iTRAC Administration Tools
There are multiple tools that allow you to create iTRAC workflows in Sentinel. To access these tools:
1 Access the Sentinel Control Center.
1a From Sentinel Main, in the toolbar, click Applications.
1b Click Launch Control Center.
1c Click Yes to accept the security certificate.
1d Specify a username and password of a user that has rights to access the SCC, then click
Login.
1e Click Accept or Accept Permanently to accept the security certificate and display the SCC.
2 Click the iTRAC tab, then click iTRAC in the toolbar.
All of the different administrative tools are listed here.
Process Manager: Manages the instantiated workflow processes.
Activity Manager: Defines the activities used in the iTRAC workflows.
Template Manager: Defines the templates used in the iTRAC workflows.
iTRAC Role Manager: Assigns roles that are used by the iTRAC workflows to assign work
items to groups of users.
128
Configuring iTRAC Workflows
Using the Template Manager
The Template Manager can be used to create, view, modify, copy, or delete a template. Within the
Template Manager you can add, delete, copy, view, and edit templates. Templates can be sorted into
folders for easy management
In the Template Manager, you can:
 Create new workflow templates.
 Edit or copy existing templates.
 Define workflow steps:
 Mark steps as Manual or Automated
 Include a description of a step or include instructions for iTRAC users
 Define transitions between steps:
 Transition type
 Escalation procedures
 Timeout and alert attributes
Figure 17-1 iTRAC Workflow
Default Templates
iTRAC is shipped with several templates to use as examples. The process and activity attributes for
these templates are set to pre-defined values. Users can modify them to suit their requirements. The
default templates are:
 AlertTimeoutExample
 TwoStepSimpleExample
 ConditionalTransitionExample
 CommandExample
Configuring iTRAC Workflows
129
Template Builder Interface
Figure 17-2 Template Builder Interface
You see the following panes in the Template Builder window:
 Process Tree: This pane displays the steps, transitions and variables added to the template.
Users can add steps or variables, and edit or remove steps, variables and transitions.
To perform an action on a step, variable, or transition:
 Expand the relevant group in the tree.
 Select and right-click an existing attribute.
 Select the action you want to perform.
 Process: This is the main GUI for viewing and creating a Workflow template. For more
information on creating a Workflow template, see ““Creating a Template” on page 132”.
 Quick Edit: Select a step or transition to see its properties. This pane allows you to edit process
attributes.
To edit the details of steps by using Quick Edit:
1. Click the Process Attribute value in the Quick Edit Pane.
The attribute values are highlighted, indicating Edit Mode.
2. Modify the value and click anywhere outside the Quick Edit frame to save the new value.
 Messages: This pane displays messages if steps or transitions are incomplete. You must
resolve any issues listed here before saving the template.
 Overview: This pane displays an overview of the entire template.
 Step Palette: There are four types of steps in the Step Palette. You can drag and drop the steps
into the Process pane.
 Decision step
 Mail step
 Manual step
 Command step
130
Configuring iTRAC Workflows
 Activities: The activities added in the Activity Manager are shown in this pane and can be
added to a workflow template. The user can also add, edit and remove activities. For more
information, see “Managing Activities” on page 150.
IMPORTANT: Use caution when editing or deleting an Activity that is already in use.
The following icons are used in the Template Builder to represent the steps:
Table 17-1 Template Builder Icons
Icon
Description
Start Step: All workflow templates have a start step.
Decision Step: This step provides different execution paths depending on the value
of a variable defined in a previous step.
Mail Step: This step sends a pre-written e-mail.
Manual Step: This step indicates that manual work must be performed, often outside
the Sentinel system (For example, telephoning the owner of the affected system or
analyzing the results of a scan).
Activity Step: This step is a predefined set of activities.
Command Step: This step executes a command or script on the iTRAC workflow
server, which is usually installed in the same place as the Data Access Service (DAS).
The output of the command can be stored in a string variable and used as input to a
decision step.
End Step: This step signifies the completion of a workflow process.
Configuring iTRAC Workflows
131
Creating a Template
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Click Add to display the iTRAC Template Builder window.
5 In the Process Details window, provide a name and description (optional) of the template, then
click OK.
6 Drag and drop a step from the Step Palette or an activity from the Activities pane into the
Process window.
7 Add as many steps and activities as needed to create the template.
8 Right-click the step where you need to add transition, then click Add Transition.
The transition is added after the selected step.
NOTE: Any step (except for the end step) can have one or more exit transition lines. A decision
step must have at least two exit lines.
9 Right-click each final step in the template, then click Add End Transition.
10 Look at the message pane at the bottom of the iTRAC Template Builder to find any messages
with warnings or errors about incomplete steps, then fix any problems you find.
11 When the template is complete, click File > Save.
or
Click the Save button to save the template.
Managing Templates
After creating a template, you can modify, copy, or delete it.
 “Viewing or Editing a Template” on page 132
 “Copying a Template” on page 133
 “Deleting a Template” on page 133
Viewing or Editing a Template
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 In the toolbar, click iTRAC > Template Manager.
3 Select a template, then click View/Edit to display the Template Builder.
132
Configuring iTRAC Workflows
Copying a Template
One way to create a new workflow template is to copy one of the default templates and modify it.
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select a template, then click Copy to display the Template Builder with the copied template
5 Specify a new name, then edit the template.
Deleting a Template
If you delete a template, any instantiated workflow processes that are based on that template finish
normally.
To delete a template:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select a template, then click Delete.
5 Click Yes to confirm you want to delete the template.
Steps
Steps are the basic components of a template. Every template must have a start step and an end
step. The start step exists by default. You can also add the following types of steps to a template:
 “Start Step” on page 133
 “Manual Steps” on page 134
 “Decision Steps” on page 135
 “Mail Steps” on page 135
 “Command Steps” on page 135
 “Activity Steps” on page 136
 “End Step” on page 137
Start Step
Every workflow template must have one start step. The transition from a start step is always
unconditional.
Configuring iTRAC Workflows
133
Manual Steps
This type of step indicates that manual work must be performed. Every manual step in a template
must be assigned to a role. The users in that role are notified through a worklist item when an
instantiated workflow process reaches the manual step. When a user accepts the worklist item, it is
removed from the queues of the other users in that role. For more information about worklists and
stepping through a workflow process, see “Understanding the Work Item Summary Interface” on
page 157.
The description of the step should indicate what work needs to be performed. The user is expected to
perform that work and then acknowledge completion.
A manual step includes the following attributes:
 Name of step
 Role
 Variables
 Delete
 Add
 Description
Variables
The user can also be asked to set one or more variables to appropriate values. Four variable types
can be assigned to manual steps: Integer, Boolean, String, and Float. The variable can be set to an
explicit default value during the step definition, or the user can set the value at run-time as part of the
workflow process. The value can be optional or required.
The value of the variable can be used as part of a conditional transition to determine the path the
workflow follows. It can also be used later as part of a conditional transition from a decision step to
determine the workflow path.
NOTE: If the value is to be used later as part of a decision step, it should be marked Required.
For example, an integer variable can be set by the user to hold the event rate. Output transitions from
the manual step can be defined so that if the event rate is greater than 500, one path is followed, and
another path is followed if the event rate is less than 500.
To create a variable:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Click the Add button in upper left corner to open a new template.
or
Select an existing template, then click View/Edit.
5 Right-click Variables in the Process Tree, then select the type of variable to add.
6 Use the following information to define the selected variable:
Name: Specify a name for the variable.
134
Configuring iTRAC Workflows
Variable Type: Select the variable type. The options are:
 INTEGER
 BOOLEAN
 FLOAT
 STRING
Default Value: Specify a default value for the selected variable. The Boolean variable has only
the options of True or False.
Description: (Optional) Specify a description for the variable.
7 Click OK to save the variable.
From a manual step, you can set conditional, unconditional, timeout, or alert transitions.
Decision Steps
This type of step selects different exit transitions, depending on the values of variables defined in
prior steps. See “Manual Steps” on page 134 for the available variable types. The decision step itself
is very simple; you can edit only the step name and description. The workflow path is determined by
the transitions.
From a decision step, you can set conditional and else transitions. Every decision step must have an
else transition and at least one conditional transition. The else transition leads to a workflow path that
is followed if none of the criteria for the conditional transitions are met.
Mail Steps
This step sends a pre-written e-mail. A mail step includes the following attributes:
 Name of step
 To addressee
 From addressee
 Subject of e-mail
 Body of e-mail
From a mail step, you can set a conditional, unconditional, timeout, alert, or error transition. An error
transition should always be included so error conditions can be handled properly.
NOTE: If the first step of a workflow fails without an error transition, the iTRAC process cannot
proceed.
Command Steps
A command step executes an operating system command or script (shell, batch, Perl and so on). The
name of the command can be explicitly provided or set as a string variable, and parameters can be
passed in the same manner. Output from the command can also be placed back into a string variable.
A command step includes the following attributes:
 Name of step
 Description
Configuring iTRAC Workflows
135
 Command (Can be explicit or variable-driven)
 Arguments (Can be explicit or variable-driven)
 Output Variable
NOTE: The command (a script file that refers to the command) must be stored in the /opt/novell/
sentinel/bin/actions directory on the iTRAC workflow server. Symbolic links are not supported
Variables
The command output can also be used to set a variable to the appropriate values. Command steps
must use String variable types.
The value of the variable can be used as part of a conditional transition to determine the path the
workflow follows. It can also be used later as part of a decision step to determine the workflow path.
For example, a command step can return a value of 0 for failure and 1 for success. This output can be
assigned to a variable, and then a conditional transition or a decision step can use this value to
determine which workflow path to take.
The command and its arguments can each be specified explicitly by the person designing the
workflow or can be set as a string variable. If either the command or the argument is set as a String
variable, there must be a previous step in the template where the variable is set to a String value.
From a command step, you can set conditional, unconditional, timeout, alert, or error transitions. An
error transition should always be included so error conditions can be handled properly.
NOTE: If the first step of a workflow fails without an error transition, the iTRAC process cannot
proceed.
Activity Steps
An activity step is a type of automated step that can be used in a workflow template. Activity steps are
created in the Activity Manager and can consist of internal Sentinel operations or external scripted
operations. After activity steps are created, the user can select from a library of these activities and
include them into a workflow. For more information on creating each type of predefined activity, see
“Creating iTRAC Activities” on page 149.
An activity step includes the following attributes:
 Name
 Description
 Activity Assignment
From an activity step, you can set conditional, unconditional, timeout, alert, or error transitions. An
error transition should always be included so error conditions can be handled properly.
NOTE: If the first step of a workflow fails without an error transition, the iTRAC process cannot
proceed.
136
Configuring iTRAC Workflows
End Step
Every workflow template must have an end step to complete every branch of the workflow path.
Adding Steps to a Workflow
Steps can be added to a workflow by using the Step Palette or by right-clicking in the Process Builder.
When you add steps to a workflow, a yellow entry field indicates an invalid entry.
 “Adding a Step from the Step Palette” on page 137
 “Adding a Step in the Process Builder” on page 137
 “Adding an Activity Step” on page 138
 “Adding an End Step” on page 138
Adding a Step from the Step Palette
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Click the Add button in upper left corner to open a new template.
or
Select an existing template, then click View/Edit.
5 Drag and drop a step from the Step Palette.
6 Right-click the step, then select Edit Step.
7 Edit the details of the step, then click Save.
Adding a Step in the Process Builder
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click an existing step in the Process Builder, then click Insert New.
6 Select the type of step you want to add:
 Manual
 Command Step
 Mail Step
 Decision Step
7 Edit the details of the step, then click Save.
Configuring iTRAC Workflows
137
Adding an Activity Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Drag and drop an activity from the Activity Pane to the Process Builder.
Adding an End Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click the last step with no transition, then select Add End Transition.
Managing Steps
Steps can be copied, edited, or deleted.
 “Copying a Step” on page 138
 “Modifying a Step” on page 139
 “Editing a Manual Step” on page 139
 “Editing a Decision Step” on page 139
 “Editing a Mail Step” on page 140
 “Editing a Command Step” on page 140
 “Deleting a Step” on page 140
Copying a Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In toolbar, click iTRAC > Template Manager.
4 Select an existing template, click View/Edit.
5 Right-click an existing step, then select Copy Step.
The step window opens in edit mode with all the attributes of the selected step.
6 Specify a name for the new step.
7 Edit step attributes as necessary, then click OK.
138
Configuring iTRAC Workflows
Modifying a Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click an existing step, then select Edit Step.
6 Edit the step attributes, then click OK.
Editing a Manual Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template that contains a manual step, then click View/Edit.
5 Right-click the manual step, then select Edit Step.
6 Change the name for the step.
7 Attach a role to this step by selecting a role from the drop-down list.
For more information on roles, see “Managing iTRAC Roles” on page 151.
8 Click Associate to associate a variable, then select the variable from the list or create new
variables to be associated.
9 Set a default value for the variable as desired.
10 Check Read-Only, if this variable is to be forced to the default value.
11 Click the Description tab, then provide a description for this step.
12 Click Preview to preview the step you created.
13 Click OK to save the step.
Editing a Decision Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template that contains a decision step, then click View/Edit.
5 Right-click a decision step, then select Edit Step.
6 Change the name of the step.
7 Click the Description tab to provide a description for this step.
8 Click OK to save the step.
Configuring iTRAC Workflows
139
Editing a Mail Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template that contains a mail step, then click View/Edit.
5 Right-click a mail step, then select Edit Step.
6 Change the name of the step.
7 Specify the To and From e-mail addresses, then specify a subject for the e-mail in the General
tab.
8 Click the Body tab, then compose the e-mail message.
9 Click OK to save the step.
Editing a Command Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template that contains a command step, then click View/Edit.
5 Right-click a command step, then select Edit Step.
6 Change the name for this step.
7 Specify the path and name of the command or script to execute relative to the /opt/novell/
sentinel/bin/actions directory.
8 (Conditional) Select Use Variables, if you want to run a command or script referenced in a
variable that is populated during the workflow process.
9 Specify any command line arguments to pass to the command or script.
10 (Conditional) Select Use Variables, if you want to run a command or script referenced in a
variable that is populated during the workflow process.
11 Specify a variable to hold output from the command or script.
Any standard output is placed into these variables.
12 Click the Description tab to provide a description for this step.
13 Click OK to save the step.
Deleting a Step
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click an existing step, then select Delete Step.
6 In the Alert Message window, select Yes to confirm deletion.
140
Configuring iTRAC Workflows
Transitions
Transitions are used to connect steps. There are several types of transitions:
 Unconditional
 Conditional
 Timeout
 Alert
 Else
 Error
A transition can have the following attributes:
 Name
 Description
 Destination: The step where the transition links
 Expression
 Timeout Values
Different steps have different properties and therefore they are associated with different transition
types.
Table 17-2 Steps and Valid Transitions
Step Type
 Decision
Valid Transitions
 Conditional
 Else
 Manual
 Unconditional
 Timeout
 Alert
 Command
 Unconditional
 Mail
 Timeout
 Activity
 Alert
 Error
Unconditional Transitions
An unconditional transition must always be used from a start step. Manual, command, activity, and
mail steps can also have unconditional transitions. The only parameter for an unconditional transition
is the next step.
The transition is carried out when the current step is completed (unless a timeout transition is
configured and the timeout period elapses).
Configuring iTRAC Workflows
141
To add an unconditional transition:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click an existing step, then select Add Transition.
6 Use the following information to create the unconditional transition:
Name: Specify a name for the transition that is displayed in the Process Builder.
Type: Select Unconditional for the transition type.
Destination: Select the next step in the workflow for the unconditional transition.
Description: Specify a description for the transition.
7 Click OK to save the transition.
Conditional Transitions
Select an exit path based on an expression using iTRAC variables set in a manual or command step.
You can add conditional transitions only from a decision step to any other step.
When you create a conditional transition, the conditional expressions can be based on comparing a
variable that is populated during the workflow process to a specific value or to another variable
populated during the workflow process. Multiple conditional expressions can be combined or nested
using the AND and OR operators.
To add a conditional transition:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 Select an existing template, then click View/Edit.
4 Right-click an existing decision step, then select Add Transition.
5 Use the following information to create the conditional transition:
Name: Specify a name for the conditional transition.
Type: Select Conditional for the transition type.
Destination: Select the next step in the workflow for the conditional transition.
Expression: Create an expression for the conditional transition. See “Creating an Expression”
on page 143 for instructions.
Description: Specify a description for the conditional transition.
6 Click OK to save the conditional transition.
142
Configuring iTRAC Workflows
Creating an Expression
Each conditional transition contains an expression that defines the condition. Use the following
procedure to create a transition:
1 Verify you have completed Step 2 through Step 4.
2 Click Set to create the expression.
3 Click EXP to add the first expression.
The evaluation expression is an expression that evaluates to True or False during the workflow
process.
4 Use the following information to define the expression:
Relations: Select how the expression compares the conditional transition:
 Variables and Variable: Compares a variable to another variable.
 Variables and Values: Compares a variable to a constant value.
Attribute: Select a variable from the drop-down list or create a new one if desired.
Condition: Select a condition from the drop-down list.
The condition list varies depending on the type of attribute variable chosen.
 Boolean: The options are:
 equals
 not equals
 Float: The options are:
 is exactly
 is not
 is <
 is <=
 is >
 is >=
 Integer: The options are:
 is exactly
 is not
 is <
 is <=
 is >
 is >=
 String: The options are:
 startsWith
 endsWith
 equals
 equalsIgnorecase
 matches
 is empty
 is not empty
Configuring iTRAC Workflows
143
Value: Either select an existing value or define a new value.
5 Click OK.
6 If a second expression is desired, select the root folder
7 Repeat Step 3 through Step 5 as needed.
8 To nest expressions or to use the OR operator, click the appropriate operator button, then drag
and drop expressions onto that operator.
By default, all expressions at the root level are separated by AND operators.
9 When the expression is complete, click OK.
You can edit or delete an existing expression by using the Edit and Delete buttons in the
Expression window.
10 Continue with Step 5 on page 142 to finish creating the conditional transition.
Else Transitions
An else transition leads to a path that is taken from a decision step when the criteria for the
conditional transitions are not met. This transition only applies to decision steps, and every decision
step must have an else transition. The workflow path with the else transition is only followed if none of
the criteria for the conditional transitions is met.
You can add else transitions only from a decision step to any other step.
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 Select an existing template, then click View/Edit.
4 Right-click an existing Decision step, then select Add Transition.
5 Use the following information to create the else transition:
Name: Specify a name for the else transition.
Type: Select Else for the transition type.
Destination: Select the next step in the workflow for the else transition.
Description: Specify a description for the else transition.
6 Click OK to save the else transition.
Timeout Transitions
A timeout transition leads to a path that is taken when a user-specified amount of time (minutes,
hours, or days) elapses after a base time, which is either step_activated_time or step_accepted_time.
Step_activated_time is the time that iTRAC activates this step within the workflow process.
Step_accepted_time is the time when a user accepts, or takes ownership, of the worklist item for this
step. If the timeout period passes without the step being completed, control moves to the next step.
Timeout transitions can be set for a manual step or a command step. Step_accepted_time is only
relevant for manual steps and should not be selected for a command step.
This transition is represented by a red line.
144
Configuring iTRAC Workflows
To add a timeout transition:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 Select an existing template, then click View/Edit.
4 Right-click an existing manual or command step, then select Add Transition.
5 Use the following information to create the timeout transition:
Name: Specify a name for the timeout transition.
Type: Select Timeout for the transition type.
Destination: Select the next step in the workflow for the timeout transition.
Timeout Details: Click Set to specify the timeout details:
 Time: Specify the timeout value.
 Unit: Select the unit of the timeout value. The options are:
 Minutes
 Hours
 Days
 Base Time: Select the base time to use with the timeout transition.
 Step Accepted Time: The time that iTRAC activates this step within the workflow
process
 Step Activated Time: The time when a user accepts, or takes ownership, of the
worklist item for this step.
Description: Specify a description for the timeout transition.
6 Click OK to save the timeout transition.
Alert Transitions
An alert transition leads to a path that is taken when a user-specified amount of time (minutes, hours,
or days) elapses after step_activated_time or step_accepted_time. At this point, the workflow process
is usually escalated to a user who can intervene and take action.
Step_activated_time is the time that iTRAC activates this step within the workflow process.
Step_accepted_time is the time when a user accepts (or takes ownership) of the worklist item for this
step.
If the alert time period passes without the step being completed, the workflow process branches into
two active paths. The original step remains active for user intervention. The alert path is also initiated.
For example, the alert path might escalate the workflow process to the attention of a supervisor,
although the main path is still open and the original owner still has the option to complete the worklist
item. Another example is that if a command is taking too long to run, you might want to alert an
analyst to investigate the delay or possibly run the command manually.
Alert transitions can be set for a manual step or a command step. Step_accepted_time is only
relevant for manual steps and should not be selected for a command step.
This transition is represented by a yellow line.
Configuring iTRAC Workflows
145
To add an alert transition:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 Select an existing template, then click View/Edit.
4 Right-click an existing manual or command step, then select Add Transition.
5 Use the following information to create the alert transition:
Name: Specify a name for the alert transition.
Type: Select Alert for the transition type.
Destination: Select the next step in the workflow for the alert transition.
Alert Details: Click Set to specify the alert details:
 Time: Specify the alert value.
 Unit: Select the unit of the alert value. The options are:
 Minutes
 Hours
 Days
 Base Time: Select the base time to use with the alert transition.
 Step Accepted Time: The time that iTRAC activates this step within the workflow
process
 Step Activated Time: The time when a user accepts, or takes ownership, of the
worklist item for this step.
Description: Specify a description for the alert transition.
6 Click OK to save the alert transition.
Error Transition
An error transition leads to a path that is taken if an automated step cannot successfully finish. Error
transitions can be used for command, mail, and activity steps (for example, if a command step fails to
execute).
Error transitions should typically lead to some kind of notification. For example, an error transition
might lead to a manual step in which the user is instructed to manually run a process that previously
failed.
The error transition is taken only if the iTRAC call to the command, mail, or activity step fails. If there
is an internal error with the command script or the mail server fails, this does not satisfy the conditions
for an error transition.
To add an error transition:
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 Select an existing template, then click View/Edit.
4 Right-click an existing command, mail, or activity step, then select Add Transition.
5 Use the following information to create the error transition:
146
Configuring iTRAC Workflows
Name: Specify a name for the error transition.
Type: Select Error for the transition type.
Destination: Select the next step in the workflow for the error transition.
Description: Specify a description for the error transition.
6 Click OK to save the error transition.
Managing Transitions
After creating a transition, you can edit or delete the transition.
 “Editing a Transition” on page 147
 “Deleting a Transition” on page 147
Editing a Transition
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Double-click an existing transition line.
6 Edit the transition as needed.
7 Click OK to save the changes.
Deleting a Transition
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Template Manager.
4 Select an existing template, then click View/Edit.
5 Right-click an existing step, then select Remove Transition.
6 Click Yes to confirm the deletions of the transition.
Activities
An activity is very similar to a command step, except that activities are reusable and cannot use input
or output variables. The activities pane shows a library of user-defined, reusable activities that can
reduce the amount of configuration necessary when building templates.
Activities are exported or imported as .xml files. These files can be exported or imported from one
system to another.
Configuring iTRAC Workflows
147
iTRAC activities can be used in iTRAC templates to define a workflow step, or they can be manually
executed from within an incident. Sentinel provides three types of actions that can be used to build
activities:
 “Incident Command Activity” on page 148
 “Incident Internal Activity” on page 148
 “Incident Composite Activity” on page 148
Incident Command Activity
An incident command activity enables you to launch a specific command with or without arguments.
The following fields from the incident associated with the workflow process can be used as input to
the command:
 DIP [Target IP]
 DIP: Port
 RT1 (IDSAttackName)
 SIP [Initiator IP]
 SIP: Port
 Text (incident information in name value pair format)
The command (a script file that refers to the command) must be stored in the /opt/novell/
sentinel/bin/actions directory on the Sentinel server.
Incident Internal Activity
An incident internal activity enables you to email and attach information from the Sentinel database to
the incident associated with the workflow process. Each of these options has a prerequisite:
 Vulnerability for the Initiator IP address (SIP) or the Target IP address (DIP): Requires that
you run a vulnerability scanner and bring the results of the scan into Sentinel by using a
Vulnerability (or information) Collector
 Advisor attack-related data: Requires the purchase and installation of the optional Advisor
data subscription service.
 Asset data: Requires that you run an asset management tool such as NMAP and bring the
results into Sentinel by using an Asset Collector.
To send mail messages from within the Sentinel Control Center, you must have an SMTP integrator
that is configured with connection information and with the SentinelDefaultEMailServer property set to
True.
Incident Composite Activity
An incident composite activity enables you to combine one or more existing commands and internal
activities.
148
Configuring iTRAC Workflows
Creating iTRAC Activities
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Activity Manager.
4 Select an existing activity, then click View/Edit.
or
Click the Add button to create a new activity.
5 Use the following information to define the activity type:
Type: Select the activity type you want to create:
 Incident Command Activity
 Incident Composite Activity
 Incident Internal Activity
Usage: The Usage field is populated with the type of activity you selected.
Name: Specify a name for the activity
Description: Specify a description for the activity.
6 Configure the necessary settings for the type of activity you chose:
Incident Command Activity: Use the following information to create the incident command
activity:
 Command: Specify the command the activity performs.
 Arguments: Select the type of arguments for this command. The options are:
 None
 Incident Output
 Custom
Incident Composite Activity: Select one or more of the activities to create a composite activity.
The options are:
 CollectionActivity
 EraditionaActivity
 ContainmentActivity
Incident Internal Activity: Configure the incident internal activity to e-mail the output to a
specific address and attach the output to the incident associated with the workflow process.
 Mail and Attach: Select whether you want to e-mail the vulnerability and Advisor data.
 Mail Details: Specify the details of the e-mail that will be sent. You must define the To,
From, and Subject fields.
7 View and confirm the details you chose in the Summary page, then click Finish.
Configuring iTRAC Workflows
149
Managing Activities
After creating an activity, you can modify, import or export it.
 “Editing an Activity” on page 150
 “Exporting an Activity” on page 150
 “Importing an Activity” on page 150
Editing an Activity
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Activity Manager.
4 Select activity you want to edit, then click View/Edit.
5 Edit information in General, Attachments and Mail tabs.
6 Click OK to save the changes.
Exporting an Activity
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Activity Manager.
4 Click Import/Export.
5 Use the following information to export the activity:
Action: Select Export Activity.
File Name: Click Explore, then browse to and select the file you want to export this information
to.
File Path: This is automatically populated when you select the export file.
6 Click Next.
7 Select one or more activities to be exported.
8 Click Next, then click Finish.
Importing an Activity
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Activity Manager.
4 Click Import/Export.
5 Use the following information to import the .xml file that contains the activity:
Action: Select Import Activity.
File Name: Click Explore, then browse to and select the file you want to import.
150
Configuring iTRAC Workflows
File Path: This is automatically populated when you select the import file.
6 Click Next.
The list of activities is displayed.
7 Click Next, then click Finish.
Managing iTRAC Roles
Sentinel users can be assigned to one or more roles. Manual steps in the workflow processes can be
assigned to a role.
 “Adding a Role” on page 151
 “Deleting a Role” on page 151
 “Viewing the Role Details” on page 151
Adding a Role
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the menu bar, click iTRAC > iTRAC Role Manager.
4 Click Add Role.
5 Specify a unique name for the role.
6 Click Add to specify which users must be members of this role.
7 Click OK.
Deleting a Role
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the menu bar, click iTRAC > iTRAC Role Manager.
4 Right-click the role you want to delete, click Delete Role.
5 Click Yes to confirm deletion.
Viewing the Role Details
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the menu bar, click iTRAC > iTRAC Role Manager.
4 Right-click the role for which you want to view details, click iTRAC Role Details.
Configuring iTRAC Workflows
151
Process Management
Process management allows you to view the incident’s progress in the workflow or terminate a
workflow process.
Process execution is the time period during which the process is operational, with process instances
being created and managed.
When an iTRAC process is executed or instantiated in the iTRAC server, a process instance is
created, managed, and eventually terminated by the iTRAC server in accordance with the process
definition. As the process progresses towards completion or termination, it executes various activities
defined in the workflow template based on the criteria for the transitions between them. The iTRAC
workflow server processes manual and automatic steps differently.
An iTRAC process must be created with a single associated incident; there is therefore a one-to-one
match between iTRAC processes and incidents. Not all incidents are attached to a process. Only one
incident can be associated to an iTRAC process instance.
 “Instantiating a Process” on page 152
 “Automatic Step Execution” on page 152
 “Manual Step Execution” on page 153
 “Display Status” on page 153
 “Displaying the Status of a Process” on page 153
 “Changing Views in Process Manager” on page 154
 “Starting or Terminating a Process” on page 154
Instantiating a Process
An iTRAC process can be instantiated in the iTRAC server by associating an incident to an iTRAC
process by any of the following three methods
 Associating an iTRAC process to the incident at the time of incident creation
 Associating an iTRAC process to incident after an incident has been created
 Associating an iTRAC process to an incident through correlation
For more information on associating a process to an incident, see Chapter 16, “Configuring
Incidents,” on page 123.
Automatic Step Execution
When the process instance executes an automatic activity step, command step, or mail step, it
executes the associated activity or command defined in the template and stores the result in process
variables. It then transitions to the next step in the iTRAC template.
For example, an activity might be defined to ping a server. When this activity is executed in a
workflow process, the activity runs and attaches the results to the associated incident.
152
Configuring iTRAC Workflows
Manual Step Execution
On encountering a manual step, the iTRAC server sends out notifications in the form of work items to
the assigned resource. If the step was assigned to a role, a work item is sent to all users within the
role. The iTRAC server then waits for the user to complete the work item before proceeding to the
next activity.
For more information, see “Understanding the Work Item Summary Interface” on page 157.
Display Status
The Display Status option monitors the progress of a process. As the process instance progresses
from one activity, the user can track the progress visually by clicking the Refresh button. The process
monitor also provides an audit trail of all the actions performed by the iTRAC server when executing
the process.
Activities that are running, completed, or terminated are represented by the following icons.
Table 17-3 Display Status Icons
Icon
Description
Indicates that the activity is running.
Indicates that the activity is completed.
Indicates that the activity is terminated.
Displaying the Status of a Process
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Display Process Manager.
4 Click the down-arrow on the Switch Views button to select a view or create a new view.
5 In the Process Manager window, right-click a process, then select Actions > Display Status.
The current step is highlighted in red.
Configuring iTRAC Workflows
153
6 To close, click the X in the upper right corner.
Changing Views in Process Manager
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
3 In the toolbar, click iTRAC > Display Process Manager.
4 Click the Manage View drop-down list, then select Edit Current View.
5 Change the following options to change your current view:
 Fields
 Group by
 Sort
 Filter
 Leaf Attribute
6 Click Apply, then click Save.
Starting or Terminating a Process
1 Access the Sentinel Control Center. For more information, see Step 1 in “Accessing the iTRAC
Administration Tools” on page 128.
2 Click the iTRAC tab.
154
Configuring iTRAC Workflows
3 In the toolbar, click iTRAC > Display Process Manager.
4 In the Process View Manager window, right-click a process, then select Actions > Start Process
or Terminate Process.
Configuring iTRAC Workflows
155
156
Configuring iTRAC Workflows
18
Managing Work Items
18
 “Overview” on page 157
 “Understanding the Work Item Summary Interface” on page 157
 “Viewing a Work Item” on page 158
 “Processing a Work Item” on page 159
 “Managing Work Items Of Other Users” on page 159
Overview
A work item is a workflow task assigned to a particular user or role in the iTRAC application. The
individual activities to be performed to complete an iTRAC process are listed as work items in Work
Item Summary in the Sentinel Control Center. For more information on iTRAC processes, see
Chapter 17, “Configuring iTRAC Workflows,” on page 127. You can access the work items from any
tab in the Sentinel Control Center.
NOTE: To have access to a work item, you must assign it to you or acquire the work item
management permission. If you have the work item management permission, you can manage work
items of other users.
Understanding the Work Item Summary Interface
The Work Item Summary lists the work items allocated to a user as an individual and as a member of
a group. It can be used as an incident workflow to-do list for a user who is a part of the incident
response process. In the Work Item Summary, you can access the work items and perform different
tasks:
 View the details of a work item
 Process the work item to complete the task
In the Work Item Summary, work items are grouped by current user and by other users with similar
roles. The following example is for a user who is a member of the Admin, Analyst, Jr Analyst, and
Admin Asst groups.
Managing Work Items
157
Figure 18-1 Work Item Summary Example 1
The following example is for a user who is a member of the Analyst group who has a process
assigned to his role (group).
Figure 18-2 Work Item Summary Example 2
Viewing a Work Item
1 In the Work Item Summary, click the yellow or green bar.
A work item list for the group or the current user displays and shows the name and ID of the
incident, the workflow process name, and the step name and description
2 Double-click any work item and click View Details.
The Work Item Details window appears and shows the process details, including any detailed
instructions included by the iTRAC workflow developer and any variables that need to be set in
the step.
3 Click Process Overview to view an overview of the entire iTRAC process.
4 Click Incident to view the details of the associated incident.
5 To take responsibility for this work item, click Acquire. Otherwise, click Cancel.
NOTE: Any changes to the incident from this page must be saved. There is a Save button on the
toolbar and a Save button at the bottom of the page.
The information on the Process Details and Process Overview tabs is defined by the iTRAC workflow
designer. For more information on creating workflow templates, see Chapter 17, “Configuring iTRAC
Workflows,” on page 127.
158
Managing Work Items
Processing a Work Item
A work item can be accessed from any part of the main tabbed Sentinel Control Center interface.
 You can process a work item in a group even if you have logged in as a different user. However,
you cannot acquire a step if you have logged in as a different user.
 The work item remains with the user of a group who has acquired it.
 Consecutive steps are dependent. If two consecutive steps are assigned to the same role, the
user who acquires the first step is also assigned the second step.
 Non-consecutive steps are independent. For example, if a workflow proceeds from steps that are
assigned to the Tier 1 Analyst group to the Tier 2 Analyst group and then back to the Tier 1
Analyst group, the third step is available to the entire Tier 1 Analyst group. It is not assigned to
the individual user who handled the first step.
To process a work item, you must accept and complete the work item:
1 In the Work Item Summary, click the yellow or green bar. A work item list for the group or the
current user displays.
2 To assign an iTRAC process to you, select the process and click Acquire.
The Work Item Summary changes from yellow to green.
NOTE: When you acquire (accept) a work item, it is removed from the queues of all other users
in the same role. The work item can be returned to the group by clicking Release.
3 Click View Details.
The current step within a work item is highlighted in red.
4 To take action on the step, click the Process Details tab.
Depending on the type of variable (Integer, String, Boolean and Float) in a manual step, you can
click the down-arrow and select a value. If needed, you can add comments or add an
attachment.
In all other cases, the steps are automatic.
5 Click Complete to complete the process.
Completing the work item signals the completion of the task to the iTRAC server. The updateable
variables from the work item are processed by the server to move to the next step, which depends on
how the workflow is defined. The work item is removed from the user’s worklist and appears in the
worklist of the individual or role associated with the next step in the process.
Managing Work Items Of Other Users
The Administration function allows an administrative user to release a work item from a specific user
back to everyone in a role. This is beneficial if a work item is in already in process but the assigned
user cannot complete the work.
1 Log in into Sentinel as a user with iTRAC – Manage Work Items Of Other Users user rights.
2 In the Summary pane, click View work items.
3 In the Work Items window, set the following:
 User: Name of the user that has acquired the process
 Group: Name of the group that the user belongs to. In this example, the user belongs to the
Analyst group.
Managing Work Items
159
 Owner: Select <All> (all processes acquired or not), me (acquired processes), or Group
(un-acquired processes).
 Process: Name of the process.
In this example, all processes are acquired by jr1, who belongs to the Analyst group.
4 To release the work item, select the work item and click Release. Release changes to Acquire
(not available).
In this example, only a member of the Analyst group can acquire this work item.
160
Managing Work Items
A
Search Query Syntax
A
Sentinel uses the Lucene query language for searching events. This section provides an overview of
how to use the Lucene query language to perform searches in Sentinel. For more advanced features,
see Apache Lucene - Query Parser Syntax.
For information on the event fields in Sentinel, click Tips on the top right corner in the Sentinel Main
interface. A table is displayed that lists the event names and their IDs.
 “Basic Search Query” on page 161
 “Wildcards in Search Queries” on page 166
 “The notnull Query” on page 168
 “Tags in Search Queries” on page 168
 “Regular Expression Queries” on page 169
 “Range Queries” on page 169
 “IP Addresses Query” on page 170
Basic Search Query
A basic query is a search for a value on a field. The syntax is as follows:
msg:<value>
The field name (msg) is separated from the value by a colon.
For example, to search for a phrase that includes the word “authentication,” you can specify the
search query as follows:
msg:authentication
Or, to search for events of severity 5, you can specify the search query as follows:
sev:5
If the value has spaces or other delimiters in it, you should use quotation marks. For example:
msg:"value with spaces"
Sentinel classifies event fields as either tokenized fields or non-tokenized fields. A tokenized field is
indexed and is searched differently than a non-tokenized field.
 “Case Insensitivity” on page 162
 “Special Characters” on page 162
 “Operators” on page 162
 “The Default Search Field” on page 163
 “Tokenized Fields” on page 164
 “Non-Tokenized Fields” on page 166
Search Query Syntax
161
Case Insensitivity
Indexing and searching in Sentinel is not case-sensitive. For example, the following queries are all
equivalent:
msg:AdMin
msg:admin
msg:ADMIN
Special Characters
If you include special characters as part of a search, the special characters must be escaped. These
characters are as follows:
+ - && || ! ( ) { } [ ] ^ " ~ * ? : \ /
Use “ \” before the character you want to escape. For example, to search for ISO/IEC_27002:2005 in
the rv145 (Tag) field, use the following query:
rv145:ISO\/IEC_27002\:2005
You can also use quotation marks around the query:
rv145:"ISO/IEC_27002:2005"
If the value contains quotation marks, you must escape it by using the “\” character instead of
quotation marks. For example, to search for “system “mail” service” in the initiatorservicename
field, you must specify the query as follows:
sp:"system \"mail\" service"
For more information on quoting wildcard characters, see “Quoted Wildcards” on page 167.
Operators
Lucene supports AND, OR, and NOT Boolean operators, which allow words to be combined. Boolean
operators must be always capitalized.
 “OR Operator” on page 162
 “AND Operator” on page 163
 “NOT Operator” on page 163
 “Operator Precedence” on page 163
OR Operator
The OR operator is the default conjunction operator. If there is no Boolean operator between two
clauses, the OR operator is used. The OR operator links two clauses and finds a matching event if
either of the clauses is satisfied. The symbol || can be used in place of the word OR. For example,
consider the following query:
sun:admin OR dun:admin
This query finds events whose initiator username or target username is “admin.” The following query
produces the same result because OR is used by default:
sun:admin dun:admin
162
Search Query Syntax
AND Operator
The AND operator links two clauses and finds a matching event only if both clauses are satisfied. The
symbol && can be used in place of the word AND. For example, consider the following query:
sun:admin AND dun:tester
This query finds events whose initiator username is admin and the target username is tester.
NOT Operator
The NOT operator excludes events that match the clause after the NOT. The symbol ! can be used in
place of the word NOT. For example, consider the following query:
sev:[0 TO 5] NOT st:I NOT st:A NOT st:P
This query matches all events whose severity is between 0 and 5, but excludes those whose sensor
type is I (internal), A (audit), or P (performance); that is, it excludes Sentinel internal events.
The NOT operator cannot be used by itself because it is a way to exclude events from a set that has
been found by other search terms. For example, consider the following query:
NOT st:I NOT st:A NOT st:P
This query might seem like it should return all events where the sensor type is not I, A, or P. However,
it is an invalid query because a query cannot begin with the NOT operator.
Operator Precedence
Parentheses can be used in the usual way to change operator precedence. They can be nested to
any depth, as shown in the following examples:
(sun:admin OR dun:admin) AND (sip:10.0.0.1 OR sip:10.0.0.2)
((sun:admin OR dun:admin) AND (sip:10.0.0.1 OR sip:10.0.0.2)) OR (msg:user AND
evt:authentication)
The Default Search Field
Lucene uses a default search field, which is the field that is searched if no field is specified. In
Sentinel, _data is the default search field. By default, the default search field is a concatenation of the
following event fields:
evt,msg,sun,iuid,dun,tuid,sip,sp,dip,dp,rv42,shn,rv35,rv41,dhn,rv45,obsip,sn,obsdo
m,obssvcname,ttd,ttn,rv36,fn,ei,rt1,rv43,rv40,isvcc
The default search field is indexed and searched as a tokenized field. The result is that you can
search for words that might appear in any event field.
You can also customize the set of event fields that are concatenated in the default search field by
adding the indexedlog.datafield.ids property in the configuration.properties file. For more
information, see Customizing the Default Search Field in the NetIQ Sentinel Administration Guide.
For example, suppose you have two non-tokenized fields in an event, sun (initiatorusername) and
dun (targetusername). The sun field has the following value:
report-administrator
The dun field has the following value:
Search Query Syntax
163
system-tester
The _data field contains the concatenation of these fields separated by a single space character:
report-administrator system-tester
Because the _data field is a tokenized field, the words “report,” “administrator,” “system,” and “tester”
are indexed and searchable. The following queries would find this event:
report
_data:report
report-administrator
_data:report-administrator
report tester
In addition, the following queries also find this event:
sun:report-administrator
dun:system-tester
Tokenized Fields
Fields that are classified as tokenized fields are parsed into individual words for indexing. Therefore,
a search occurs only on words within the field value. Characters that are considered to be word
delimiters are not searchable, nor are words that are considered to be stop words. Lucene removes
extremely common words to save disk space and speed up searching. These words are ignored in
search filters. Currently, the following stop words are removed:
 a
 an
 and
 are
 as
 at
 be
 but
 by
 for
 if
 in
 into
 is
 it
 no
 not
 of
 on
164
Search Query Syntax
 or
 such
 that
 the
 their
 then
 there
 these
 they
 this
 to
 was
 will
 with
When it does a search, Lucene examines all of the words in a field and tries to match words in the
search value. For example, suppose that you specify a search for messages containing the following
value:
msg:"user-authentication failed on the server"
The words that are parsed within this value are “user,” “authentication,” “failed,” and “server.” These
are the only search words that would match this value. “On” and “the” are omitted because they are
stop words.
The value has the hyphen character (-) between some words. Hyphens are treated as word
delimiters, so Lucene does not search for hyphens. Consider, the following query:
msg:"user-authentication"
The results might not be exactly what you expect. The query search value matches the value, but not
because it is matching the hyphen. It matches because Lucene first parses the words in the search
value and identifies the words “user” and “authentication.” Lucene then matches those words against
values that have the words “user” and “authentication” with no intervening words in between. This
query would also match the following value, even though there is no hyphen between “user” and
“authentication”:
user authentication has failed on the server
Consider the following query:
msg:"failed on server"
This query has the stop word, "on," which is ignored. However, the stop word does affect the relative
positioning that is expected to be between words when evaluating a value to see if it matches. The
“failed on server” search matches any phrase where the words “failed” and “server” are separated by
exactly one word. It does not matter what the word is because the separating word is a stop word and
is ignored. Thus, the above query would match all of the following:
failed on server
failed-on server
failed a server
Search Query Syntax
165
failed-a-server
Proximity indicators created by using the ~ character followed by a value, make this more
complicated. The query dictates an expected distance between words. In the “failed on server” query,
the expected distance between “failed” and “server” is one word. The proximity indicator specifies
how much variance there can be from the expected distance. For example, consider the following
query, where a proximity indicator of one (~1) is specified:
msg:"failed on server"~1
This query indicates that the distance between “failed” and “server” could be plus or minus one from
the expected distance, which is one because of the stop word “on.” Thus, the distance could be 1, 11 (0), or 1+1 (2). Thus, all of the following would match:
failed on server
failed on the server
failed finance server
As of Lucene version 3.1, word parsing is done according to word break rules outlined in the Unicode
Text Segmentation algorithm. For more information, see Unicode Text Segmentation.
For information on tokenized fields in Sentinel, in the Sentinel Main interface click Tips on the top
right corner of the Sentinel Main interface. A table is displayed that lists all the event fields and
whether an event field is searchable or not.
Non-Tokenized Fields
Fields that are classified as non-tokenized fields are parsed fully for indexing. Thus, a search occurs
on full field values. For example, to search events whose initiatoruserfullname (iufname) field has the
value “Bob White”, you must specify the query as follows:
iufname:"Bob White"
Wildcards in Search Queries
Sentinel supports wildcards in search values but not in regular expressions:
 The asterisk (*) matches zero or more characters.
 The questions mark (?) matches any one character.
For example:
 adm*test: Matches admtest, ADMTEST, admintest, adMINtEst (note the lack of case
sensitivity).
 adm?test: Matches adm1test and AdMatest. Does not match admtest or ADMINTEST because
it must have exactly one character between "adm" and "test."
 “Wildcards in Tokenized Fields” on page 167
 “Quoted Wildcards” on page 167
 “Leading Wildcards” on page 167
166
Search Query Syntax
Wildcards in Tokenized Fields
Wildcards are applied differently to tokenized fields and non-tokenized fields. Wildcards for tokenized
fields match only words that were parsed from the value and not the entire value. For example, if you
specify the search query msg:authentication*failed to search for the message The user
authentication has failed on the server, it does not return the events with this message. This
is because “*” does not match anything between “authentication” and “failed.” However, it matches
any words that begin with “authentication” and end with “failed.” For example, it returns results if any
of the following words are used: “authenticationhasfailed,” “authenticationuserfailed,” and
“authenticationserverfailed.” For tokenized fields, all matching that uses wildcard searches is done on
the words within the value and not on the full value.
Quoted Wildcards
 “Tokenized Fields” on page 167
 “Non-Tokenized Fields” on page 167
Tokenized Fields
When wildcards are quoted, they are not treated as wildcards, but as word delimiters. For example,
consider the following query:
msg:"user* fail*"
The search value "user* fail*" is parsed into two words, “user” and “fail.” The semantic is "find any
event where the msg field contains “user” AND “fail” words in that order, and there are no intervening
words between them.” Thus, it does not match the following value:
The user authentication has failed on the server.
This is because the wildcard is not treated as a wildcard but as a word delimiter.
Non-Tokenized Fields
When wildcards are quoted, they are treated as literal characters to search. For example, if the query
is: sun:"adm*," it returns the following values:
adm*
ADM* (case-insensitive)
The query does not return the following values:
admin
ADMIN
Leading Wildcards
Leading wildcards are not valid in searches because Lucene does not allow the * or ? characters to
be the first character of a search value. For example, the following queries are invalid:
 sun:*adm* The semantic is “find any event whose initiator username value contains the letters
a, d, and m in sequence.“
 sun:*tester The semantic is “find any event whose initiatorusername value ends with “tester.”
Search Query Syntax
167
 sun:* The semantic is “find any event whose initiator username field is non-empty.”
Because this is an important type of query, Sentinel provides an alternative way to accomplish
this. For more information, see “The notnull Query” on page 168.
The notnull Query
You might need to find events where some field is present, or non-empty. For example, to find all
events that have a value in the sun field, you can specify the query as sun:*
The query does not return the expected results because Lucene does not support wildcards to be the
first character of a search value. However, Sentinel provides an alternate solution. For every event,
Sentinel creates a special field called notnull. The notnull field is a list of all fields in the event that are
not null (not empty). For example, if there is an event that has values in the evt, msg, sun, and xdasid
fields, the notnull field contains the following value:
evt msg sun xdasid
The notnull field is a tokenized field, so the following kinds of queries are possible:
 notnull:sun Finds all events whose sun field has a value.
 notnull:xdas* Finds all events where any field beginning with the name "xdas" has a value.
When a notnull field is added in Lucene, creating, indexing, and storing this field adds a cost to
processing each event as CPU needs to create and index the field and it also requires additional
storage space. If you want to disable storing the list of non-empty fields in the notnull field, set the
following property in the /etc/opt/novell/sentinel/config/configuration.properties file:
indexedlog.storenotnull=false
Save the file and restart the Sentinel server. All events received after this property was set do not
have a notnullfield associated.
NOTE: If you disable the notnull field, do not use the notnull field in search filters, rule filters, or
policy filters because the results might be incorrect and unpredictable.
Tags in Search Queries
The Tag field (rv145) is a tokenized field that has special parsing rules for words. The parsing rules
enable you to search on tags that include non-alphanumeric characters. However, the only word
delimiters are white space characters such as the blank and the tab. This is because tags do not
include white space in their names. For example, the following queries find the event if the event is
tagged with the ISO/IEC_27002:2005 tag and the NIST_800-53 tag:
rv145:"ISO/IEC_27002:2005"
rv145:"iso/iec_27002:2005"
rv145:"ISO/IEC_27002*"
rv145:nist_*
The slash (/), hyphen (-), and colon (:) characters are significant in the search value because, unlike
other tokenized fields, the parsing rules for rv145 do not treat them as a word delimiter. Also, the
search is not case sensitive.
168
Search Query Syntax
The following queries would not find the event:
rv145:"ISO IEC_27002 2005"
rv145:"iso *"
Regular Expression Queries
Regular expression queries allow you to search events that match a pattern. These queries must be
enclosed in quotation marks (“ “) and forward slash (/). For example, to search for an initiator user
name that ends with the character "a”, you can specify the search query as follows:
sun:"/.*a/"
If you need to include special characters in your query, you must escape special characters by
preceding them with the backslash (\) character. For example, to search for an initiator user name
that ends with the character “$”, you can specify the search query as follows:
sun:"/.*\$/"
For more information about using special characters, see “Special Characters” on page 162.
NOTE: Regular expression queries utilize significantly more system resources than other kinds of
queries because they are unable to leverage the more efficient data structures available in the index.
Executing regular expression queries take longer than other kinds of queries and potentially pull
system resources from other components of the system. Therefore, use regular expression queries
carefully and narrow the breadth of the search as much as possible by using time range and nonregular expression criteria terms.
Range Queries
Range queries allow you to find events where a field value is between a lower bound and an upper
bound. Range queries can be inclusive or exclusive of the upper and lower bounds. Whether a
particular value falls in the specified range is based on lexicographic character sorting. Inclusive
ranges are denoted by square brackets []. Exclusive ranges are denoted by curly brackets {}.
For example, consider the following query:
sun:[admin TO tester]
This query finds events whose sun field has values between admin and tester, inclusive. Note that
"TO" is capitalized.
However, if you change the query as follows:
sun:{admin TO tester}
The query now finds all events whose sun field is between admin and tester, not including admin and
tester.
Some event fields such as sev and xdasid are numeric. In Sentinel, range queries on numeric fields
are based on numeric sorting and not on lexicographic character sorting. For example, consider the
following query:
xdasid:[1 TO 7]
Search Query Syntax
169
This query returns events whose xdasid value is 1, 2, 3, 4, 5, 6, or 7. If the range evaluation was
based on lexicographic sorting, it would incorrectly match 10, 101, 100001, 200, and so on.
IP Addresses Query
There are several extensions that Sentinel has implemented for searching on IP addresses.
Specifically, there are a number of convenient ways to specify IP address ranges. These are
explained in the following sections:
 “CIDR Notation” on page 170
 “Wildcards in IP Addresses” on page 170
CIDR Notation
Sentinel supports the Classless Inter-Domain Routing (CIDR) notation as a search value for IP
address fields such as sip (initiator IP) and dip (target IP) for specifying an IP address range. The
notation uses a combination of an IP address and a mask, as follows:
"xxx.xxx.xxx.xxx/n"
In this notation, n is the number of high order bits in the value to match. For example, consider the
following query:
sip:"10.0.0.0/24"
This query returns events whose sip field is an IPv4 address ranging from 10.0.0.0 to 10.0.0.255.
The same notation works for IPv6 addresses. For example, consider the following query:
sip:"2001:DB8::/48"
This query returns events whose sip field is an IPv6 address ranging from 2001:DB8:: to
2001:DB8:0:FFFF:FFFF:FFFF:FFFF:FFFF.
Wildcards in IP Addresses
You can use only the asterisk character (*) in the IP address search values to specify ranges of IP
addresses. You cannot use the question mark (?) character.
In IPv4 addresses, an asterisk (*) can be used at any of the positions in the quad format. In IPv6
addresses, an asterisk (*) can be used between colons to specify a 16-bit segment. For example, all
of the following queries are valid on the sip field:
sip:10.*.80.16
sip:10.02.*.*
sip:10.*.80.*
sip:"CAFE:*::FEED"
sip:"CAFE:*:FADE:*::FEED"
If an asterisk (*) is used in one of the quad positions in an IPv4 address or between colons in an IPv6
address, it cannot be combined with other digits. For example, all of the following queries are invalid:
sip:10.*7.80.16
170
Search Query Syntax
sip:10.10*.80.16
sip:"CAFE:FA*::FEED"
sip:"CAFE:*DE::FEED"
Because the question mark (?) is not allowed, the following queries are invalid:
sip:10.10?.80.16
sip:10.?.80.16
sip:"CAFE:FA??::FEED"
sip:"CAFE:??DE::FEED"
Search Query Syntax
171
172
Search Query Syntax
B
Correlation Rule Expression Syntax
B
Correlation rules are written to match specific events or sequences of events by using field
references, comparison and match operators on the field contents, and operations on sets of events.
The Correlation Engine loads the rule definition and uses the rules to evaluate, filter, and store events
in memory that meet the criteria specified by the rule. Depending on the rule definition, a correlation
rule might fire according to several different criteria:
 The value of one field or multiple fields matches
 The comparison of an incoming event to past events
 The number of occurrences of similar events within the specified time period
 One or more subrules firing
 One or more subrules firing in a particular order
 An event that matches the first subrule is not followed by an event that matches the second
subrule within the specified time period
This section provides a basic overview of how to build Correlation rules and the various parameters
required to build a rule.
 “Event Fields” on page 173
 “Event Operations” on page 174
 “Operators” on page 182
 “Order of Operators” on page 183
Event Fields
All operations function on event fields, which can be referred to by their names or by their IDs within
the rule expression. For a full list of event field names and their IDs, in the Sentinel Main interface,
click Tips on the top right corner of the Sentinel Main interface.
The event field name or its ID must also be combined with a prefix to designate whether the event
field is part of the current event (e) or a past event that is stored in memory. For the Window operator,
the stored events are prefixed with (w).
Examples:
e.dip (Destination IP for the current event)
w.dip (Destination IP for any stored event)
IMPORTANT: If you rename an event field by using the Event Configuration utility in the Sentinel
Control Center, use the new name when writing rules. In all cases, rules are stored internally with the
fixed IDs and the names are translated dynamically when viewed.
Correlation Rule Expression Syntax
173
Event Operations
Event operations evaluate, compare, and count events. Each operation works on a set of events,
receiving a set of events as input and returning a set of events as output. The current event
processed by a rule often has a special meaning within the language semantics. The current event is
always part of the set of events output by the operation unless the set is empty. If an input set of an
operation is empty, then the operation is not evaluated.
The individual correlation operations evaluate sets of events and, if matches are produced, generates
sets of corresponding events. You can chain together multiple correlation operations by using the flow
operator. The most common use of a chain construct is to begin a chain with a filter to select a subset
of events. The subset is then grouped by operations, such as Trigger, or by cross-event comparisons,
such as Window. For more information on the flow operator, see “Flow Operator” on page 182.
<operation 1> [flow <operation N> ...]
<operation 1> is a fully-specified operation.
In the above example, the output from one operation is treated as input to the next operation, much
like the UNIX pipe operator. The last operation in a chain's output causes the whole rule to fire,
generating a correlated event.
 “Filter Operation” on page 174
 “Trigger Operation” on page 177
 “Window Operation” on page 178
 “Gate Operation” on page 180
 “Sequence Operation” on page 180
 “Sequence Timeout Operation” on page 181
 “Distinct Operation” on page 182
Filter Operation
A filter consists of evaluation expressions that evaluate the current event from the real-time event
stream. It compares the event field values with user-specified values by using a wide set of
comparison and match operators. If a match is found, the output set is the matched event, and then
the filter resets.
The syntax for the filter operation is:
<filter expression> ::= "filter("<evaluation expression 1> [NOT|AND|OR <evaluation
expression 2>] […] [NOT|AND|OR <evaluation expression n>]")"
<evaluation expression 1..N> is an expression constructed of one event field
reference (name or ID) and a comparison or match operator.
<evaluation expression> ::= "e." <event_name | event_ID> <comparison operator |
match operator> <user_specified_value>
Multiple evaluation expressions can be combined by using the standard Boolean operators (AND,
OR, and NOT) and grouping parentheses.
For example, the following rule detects whether the current event has a severity of 4 and the event
name contains either “FW” or “Comm.”
filter(e.sev = 4 and (e.evt match regex ("FW") or e.evt match regex ("Comm")))
174
Correlation Rule Expression Syntax
The filter operation supports the following operators:
 “Boolean Operators” on page 175
 “Standard Arithmetic Operators” on page 175
 “Match Regex Operator” on page 175
 “Match Subnet Operator” on page 176
 “Inlist and Not Inlist Operators” on page 176
 “Isnull Operator” on page 176
Boolean Operators
Filter expressions can be combined by using the Boolean operators AND, OR, and NOT. The filter
Boolean operator precedence (from the highest to the lowest precedence) is described in the
following table:
Table B-1 Boolean Operators
Operator
Meaning
Operator Type
Associativity
NOT
logical NOT
unary
None
AND
logical AND
binary
left to right
OR
logical OR
binary
left to right
Standard Arithmetic Operators
Standard arithmetic operators can be used to build a condition that compares the value of an event ID
and a user-specified value, which is either a numeric value or a string field. The standard arithmetic
operators in Sentinel are =, <, >, !=, <=, and >=.
Examples:
filter(e.sev > 3) filter(e.BeginTime < 1179217665) filter(e.iufname != “Administrator”)
Match Regex Operator
The match regex operator is used to match an event field value by using standard regular
expressions. This operator is used only for string type tags.
Examples:
Match the exact phrase (case sensitive):
filter(e.evt match regex ("LoginUser"))
Match the exact phrase (not case sensitive):
filter(e.evt match regex ("(?i)^TeSt EvenT$"))
The value includes the phrase (not case sensitive):
filter(e.evt match regex ("(?i)EsT EVen"))
Match the exact phrase that contains quotation marks, escape quotation marks with \x22 or \u0022:
Correlation Rule Expression Syntax
175
filter(e.evt match regex (\x22test\x22))
For more information about the match regex operator, see Regular Expressions.
Match Subnet Operator
The match subnet operator is used to match event field IP addresses to a subnet in standard CIDR
notation. This operator is used only for IP address fields.
Example:
filter(e.dip match subnet (10.0.0.1/22))
filter(e.sip = 10.0.0.1 or e.sip=10.0.0.2) and (e.dpint=80)
For more information on CIDR notation, see CIDR.
Inlist and Not Inlist Operators
The inlist operator is used to perform a lookup on an existing dynamic list of string values. This
operator returns TRUE if the event field value is present in the list. The dynamic list name and the list
elements names are case sensitive. When you specify the dynamic list name and list elements
names, ensure that you match the case for the lookup to work properly. For more information on
Dynamic Lists, see Chapter 9, “Configuring Dynamic Lists,” on page 99.
For example, the following expression is used to evaluate whether the source IP address of the
current event is present in a Dynamic List named MailServerList. If the source IP address is present
in this list, the expression evaluates to TRUE.
filter(e.sip inlist MailServerList)
As another example, this filter expression combines the NOT operator and the inlist operator. This
expression evaluates to TRUE if the source IP address is not present in the Dynamic List named
MailServerList.
filter(not (e.sip inlist MailServerList))
The following expression is used to evaluate whether the event name of the current event equals “File
Access” and the InitiatorUserName is not present in a Dynamic List named AuthorizedUsers. If both
conditions are true for the current event, the expression evaluates to TRUE.
filter(e.evt="File Access" and not(e.sun inlist AuthorizedUsers))
Isnull Operator
The isnull operator returns TRUE if the event field value is equal to null. For example:
Filter(isnull(e.sip))
Output Sets
 The output of this expression is either the empty set (if the evaluation expression evaluates to
FALSE) or a set containing the current event (if the evaluation expression evaluates to TRUE).
176
Correlation Rule Expression Syntax
 If the filter is the last or only operation of a correlation rule, the output set of the filter is used to
construct a correlated event.The input event that matched the filter is associated with the
correlated event.
 If the filter is not the last operation of a correlation rule (that is, if the filter is followed by a flow
operator), the output set of a filter is used as the input set to other operations through the flow
operator.
Additional Information
The filter operator can be used to compare event field values with other event field values within the
same event. For example:
filter(e.sip=e.dip)
Trigger Operation
The trigger operation counts a number of events for a specified duration. The trigger command
defines a threshold count of events within a time condition and applies an optional discriminator that
splits events into unique buckets on which to apply the threshold count and time window conditions.
Trigger itself does not apply any filtering. Every event that enters the trigger function is put in a bucket
and is counted. If you want to use trigger on certain type of events, you must prefilter the events and
then flow that output to trigger.
Syntax
<trigger expression> ::= "trigger("<threshold count>","<evaluation
period>","discriminator ("<list of event fields>")")"
<threshold count> is an integer value specifying the number of events in a single bucket that are
necessary for the rule to fire.
<evaluation period> indicates the duration for which old events are kept in the bucket and counted
towards the threshold. The duration can be seconds (s), minutes (m), hours (h), and days (d.).
discriminator (<list of event fields>) specifies the set of fields to use to segregate each event into its
unique bucket. All fields are logically combined to define the bucket.
For example, the following rule detects if 5 events with the same source IP address happen within 10
seconds.
trigger(5,10,discriminator(e.sip))
Note that the discriminator is used to split the input stream of events into distinct buckets where all
events in a bucket have identical data for the specified fields (SourceIP in the example above.)
Multiple fields can be used to create buckets where all events in a single bucket have, for example,
the same SourceIP and TargetUserName. However, you cannot count across multiple buckets. For
example, you cannot use the Trigger operation to detect conditions where a source system contacts
N distinct target systems.
Output Sets
 If the specified count is reached within the specified duration, a set of events containing all of the
events maintained by the trigger is output.
Correlation Rule Expression Syntax
177
 When receiving a new input set of events, a trigger first discards the outdated events (events that
have been maintained for more than the duration) and then inserts the current event. If the
number of resulting events is greater than or equal to the specified count, the trigger outputs a
set containing all of the events.
 If a trigger is the last operation (or the only operation) of a correlation rule, then the output set of
the trigger is used to construct a correlated event. The raw events associated with the correlated
events are the trigger operation output set of events with the current event listed first.
Window Operation
The Window operation compares the current event to a set of past events that are stored in a window
that is defined as part of the Window operation. Window allows you to temporarily store events of
interest and then use the data within those stored events to filter the incoming raw events.
For example, suppose you want to detect if someone attempts to log in to an account several times
and fails, but then guesses that password and succeeds in logging in. You would collect the failed
login events and store them in the window, then compare new successful login events against those
stored events and match the username. If a match is found, then the user first failed to log in and then
did so successfully. Any event field can be matched against any other event field for more
sophisticated correlations.
How the Window Operation Works
The incoming raw stream of events is split before it arrives at the window operation:
 Storage filter (w.event tag): One stream of raw events is matched against the storage filter
and, if any events match, they are placed in the window. Note that the current event is not part of
this stream (that is, this stream is delayed by one event.) Events in the window are referred to
with the “w.” prefix, which can be interpreted as "the set of events in the window."
 Evaluation filter (e.event tag): The other stream of raw events is filtered and then passed, one
at a time, into the Window operation. Each event (the current event) is matched against the set
of events stored in the window by using the defined comparison expression. The current event
passing into the Window operation is referred to with the “e.” prefix, which can be interpreted as
"the current event."
You can define two filters for the Window operation to constrain resource usage. You define the first
filter within the Window operation itself to set the storage filter. You define the second filter as a prefix
to the Window operation using a standard in-line filter that sets the evaluation filter. These filters are
optional, but recommended.
To ensure that the current event does not match itself in cases where the comparison operator is
matching on the same field and a single event would match both the evaluation and storage filters,
the set of events in the window does not include the current event.
NOTE: It is critical to design your storage and evaluation filters carefully to minimize resource usage
by the Window operation. The window stores the event UUID and any fields necessary for
comparison for all events that match the storage filter. Therefore, constraining the set of matched
events is important to reduce memory use.
Syntax
The syntax is as follows:
178
Correlation Rule Expression Syntax
<window expression> ::= "window(" <comparison expression> "," <storage filter> ","
<storage_time_period> ")"
<comparison expression> matches a current event field against a field in the set of past events stored
in the window. The standard comparison operators are supported.
<comparison expression> ::= "w." <event_ID | event_name> <comparison operator> "e."
<event_ID | event_name>
Multiple comparison expressions can be combined by using the standard Boolean AND, OR, and
NOT operators. Note that it is also possible to compare stored event fields against literals, in which
case the Window operation ignores the contents of the current event and always copies it to the
output as long as an event that matches the literal is in the window.
<storage filter> is an embedded filter expression that defines the storage filter. All events that match
this filter are stored in the window for later comparison until they expire.
<storage filter> ::= <filter_rule>
<filter_ rule> is a simple expression using the filter operator. For more information, see “Filter
Operation” on page 174.
<storage_time_period> is the total time for which a single event is stored in the window. The storage
time period can be seconds (s), minutes (m), hours (h), and days (d.)
<storage_time_period> ::= <1 or more digits> "s" | "m" | "h" | "d"
Examples
The following rule detects whether the current event has a source IP address that matches the source
IP address of an event that happened within the past 60 seconds, with the past events limited to
those whose source IP address is within the specified subnet. This Window would typically be
preceded by an evaluation filter to restrict the set of events evaluated by the Window.
window(w.sip = e.sip, filter(e.sip match subnet (10.0.0.10/22),60)
As another example, the following rule is a domino type of rule. An attacker exploits a vulnerable
system and uses it as an attack platform. This Window would typically be preceded by an evaluation
filter to restrict the set of events evaluated by the Window.
filter(e.XDASTaxonomyName = "XDAS_AE_IDS_PROBE" OR e.XDASTaxonomyName =
"XDAS_AE_IDS_PENETRATE") flow window((e.sip = w.dip AND e.dp = w.dp AND e.evt =
w.evt), filter(e.XDASTaxonomyName = "XDAS_AE_IDS_PROBE" OR e.XDASTaxonomyName =
"XDAS_AE_IDS_PENETRATE"), 1h)
The following rule identifies a potential security breach after a denial of service attack. The rule fires if
the destination of a denial of service attack has a service stopped within 60 seconds of the attack.
filter(e.rv51="Service" and e.rv52="Stop") flow window (e.sip = w.dip,
filter(e.XDASTaxonomyName = "XDAS_AE_DOS"), 60)
Output Sets
 If the Window operation matches a current event against the window based on the comparison
expression, the output set is the incoming event plus all matching past events
Correlation Rule Expression Syntax
179
 If no events in the window match the current event, the output set is empty.
 If a window is the last or only operation of a correlation rule, the output set of the window is used
to construct a correlated event. The raw events associated with the correlated events are the
window operation output set of events with the current event first.
Additional Information
 All window simple evaluation expressions must include an event ID in the form w.[event_ID].
 Every event coming in to the Correlation Engine that passes the storage filter is put into the
window of past events except for the most recent, or current, event.
 If no storage filter expression is defined, all events coming into the Correlation Engine are stored
by the window. With extremely high event rates or long duration storage time period, this might
require a large amount of memory.
 To minimize memory usage, only the relevant parts of the past events, not all event ID values,
are maintained in memory.
Gate Operation
The Gate operation is used to combine multiple subrules together to detect conditions where several
distinct activities happen within a given time period. The order in which each activity occurred is not
considered.
The gate operation is made up of one or more nested subrules and can be configured to fire if some,
any, or all of the subrules fire within a specified time. The subrules can be a simple rule or another
Composite rule. For more information on Composite rules, see “Composite Rule” on page 49.
Syntax
<gate expression> ::= "gate("<subrule 1>","<subrule 2>","<subrule
n>","<mode>","<evaluation period>","discriminator ("<list of event fields>")")"
<subrule 1...N> rules are the rule definitions for 1 to n subrules. Each subrule is an independent,
valid, correlation rule.
<mode> can be one of the subrules that must be triggered for the Gate operation to trigger.
<evaluation period> indicates the time period over which the specified number of subrules must fire in
order for the whole Gate rule to fire.
discriminator (<list of fields>) acts similar to the discriminator in the Trigger operation. The output from
each subrule is placed into unique buckets based on the data in the fields specified in this
discriminator. The <mode> count and <evaluation period> is then applied to each bucket separately.
For example, the following rule is a typical perimeter security IDS inside/outside rule:
filter(e.sev > 3) flow gate(filter(e.sn = "in"), filter(e.sn = "out"), all, 60s,
discriminator(e.dip, e.evt))
Sequence Operation
Sequence rules are similar to gate rules, except that all subrules must fire in sequence for the overall
Sequence operation to fire.
The subrules can be a simple rule or another Composite rule.
180
Correlation Rule Expression Syntax
Syntax
Syntax:
<sequence expression> ::= "sequence("<subrule 1>","<subrule 2>","<subrule
n>","<evaluation period>","discriminator("<list of event fields>")")"
<subrule 1..N> are the rule definitions for 1 to n subrules. Each subrule is an independent, valid,
correlation rule.
<evaluation period> is a time period expressed in seconds (s), minutes (m), or hours (h).
discriminator (<list of fields>) acts similar to the discriminator in the Trigger operation; the output from
each subrule is placed into unique buckets based on the data in the fields specified in this
discriminator. The <evaluation period> is then applied to each bucket separately.
For example, this rule detects three failed logins by a particular user in 10 minutes followed by a
successful login by the same user.
sequence (filter(e.evt="failed logins") flow trigger(3, 600, discriminator(e.sun,
e.dip)), filter(e.evt="goodlogin"), 600, discriminator(e.sun, e.dip))
Sequence Timeout Operation
A Sequence Timeout rule fires only when an event that matches the first subrule is not followed by an
event that matches the second subrule in a specified time frame. A Sequence Timeout rule has two
subrules.
Each subrule can be a simple rule or complex rule such as Sequence rule, Composite rule or a
Sequence Timeout rule itself.
Syntax
<sequence_timeout expression> ::= "sequence_timeout("<subrule 1>","<subrule
2>","<evaluation period>","discriminator("<list of event fields>")")"
<subrule 1> and <subrule 2> are the two subrule definitions. Each subrule is an independent and
valid correlation rule.
<evaluation period> is a time period expressed in seconds (s), minutes (m), or hours (h).
discriminator (<list of fields>) acts similar to the discriminator in the Trigger operation. The output from
each subrule is placed into unique buckets based on the data in the fields specified in this
discriminator. The <evaluation period> is then applied to each bucket separately.
For example, the rule detects a scenario where the server is stopped but did not start again within an
interval of 5 minutes.
sequence_timeout(filter(e.evt="service stopped"), filter(e.evt="service started"),
300)
Similarly, the following rule detects three failed logins with the same user ID from three different
source IPs in 60 seconds, but not followed by locking the user account in the specified time frame.
sequence_timeout(filter(e.evt="LoginFailed") flow trigger(3, 60,
discriminator(e.sun, distinct e.sip)), filter(e.evt="AccountLocked"), 70)
Correlation Rule Expression Syntax
181
NOTE: It is critical to design the first subrule carefully to minimize resource usage by the Sequence
Timeout operation. To fire a Sequence Timeout rule, events matching the first subrule are stored in
memory from the time they arrive till the rule duration expires. Extremely high event rates or longer
rule duration may require a large amount of memory. So constraining the set of matched events for
the first subrule is important to reduce memory use.
Distinct Operation
The Distinct operation considers only the unique values in events. You can use this operation in
scenarios where you need to differentiate scans versus flood type attacks. In flood type attacks the
overall quantity is important, with scans the overall unique information disseminated is important.
The following are some examples where you can use the Distinct operation:
Example B-1 You want a rule to trigger if five events have unique source IP addresses but the same destination
IP address within a 10 second period. You can create a free-form rule as follows:
trigger(5,10, discriminator(e.dip, distinct e.sip))
Example B-2 You want a rule to trigger if three severity 5 events occur from distinct combination of initiator IP
addresses and initiator users within a 60 second period. You can create a free-form rule as follows:
filter(e.sev = 5) flow trigger(3, 60, discriminator(distinct e.sip, distinct
e.sun))
Example B-3 You want a rule to trigger if three severity 5 events occur from the same initiator IP address but
distinct initiator users within a 60 second period. You can create a free-form rule as follows:
filter(e.sev = 5) flow trigger(3, 60, discriminator(e.sip, distinct e.sun))
Example B-4 You want a rule to trigger if three severity 5 events occur from the same initiator user but distinct
initiator IP addresses within a 60 second period. You can create a free-from rule as follows:
filter(e.sev = 5) flow trigger(3, 60, discriminator(distinct e.sip, e.sun))
Operators
Operators are used to transition between operations or expressions. The following fundamental
operators are used between operations:
 “Flow Operator” on page 182
 “Union Operator” on page 183
 “Intersection Operator” on page 183
Flow Operator
The output set of events of the left side operation is the input set of events for the right side operation.
Flow is typically used to transition from one correlation operation to the next.
For example:
filter(e.sev = 5) flow trigger(3, 60)
182
Correlation Rule Expression Syntax
The output of the filter operation is the input of the trigger operation. The trigger only counts 3 events
with severity equal to 5.
Union Operator
The union operator is the union of the left side operation output set and the right side operation output
set. The resulting output set contains events from either the left side operation output set or the right
side operation output set, without duplicates.
For example:
filter(e.sev = 5) union filter(e.sip = 10.0.0.1)
is equivalent to
filter(e.sev = 5 or e.sip = 10.0.0.1)
Intersection Operator
The intersection operator is the intersection of the left side operation output set and the right side
operation output set. The resulting output set contains events that are common to both the left side
operation output set and the right side operation output set without duplicates.
For example:
filter(e.sev = 5) intersection filter(e.sip = 10.0.0.1)
is equivalent to
filter(e.sev = 5 and e.sip = 10.0.0.1)
Order of Operators
The operator precedence (from the highest to the lowest) is as follows:
Table B-2 Operator Precedence
Operator
Meaning
Operator Type
Associativity
flow
The output set becomes the input set
binary
left to right
intersection
Set intersection (remove duplicates)
binary
left to right
union
Set union (remove duplicates)
binary
left to right
Correlation Rule Expression Syntax
183
184
Correlation Rule Expression Syntax