Admin 2
Admin 2
Administration Guide
July 2018
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/.
For information about NetIQ trademarks, see http://www.netiq.com/company/legal/. All third-party trademarks are the property
of their respective owners.
Contents
3 Security Considerations 21
Basic Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Traditional Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appliance Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Securing Sentinel Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Enforcing Password Policies for Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Securing Communication with Collector Managers and Event Sources . . . . . . . . . . . . . . . . . . . . . . 24
Securing Communication for Traditional Storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Auditing Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Determining if Data was Tampered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Using CA Signed Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Using Multi-factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Network Communication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Communication between Sentinel, Collector Manager, and Correlation Engine . . . . . . . . . . . . . . . . 31
Communication between Sentinel and the Sentinel Control Center and Solution Designer
Client Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Enabling Higher Versions of TLS for Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Communication between the Server and the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Communication with Web Browsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Communication between Sentinel and Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Communication between the Database and Other Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Sensitive Data Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Implementing Intruder Detection and Lockout Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Applying Updates for Security Vulnerabilities in Embedded Third-Party Products . . . . . . . . . . . . . . . . . . . . 36
Contents 3
5 Authentication Methods 47
Enablement Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
LDAP Authentication Against a Single LDAP Server Or Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Setting Up LDAP Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Logging in by Using LDAP User Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Configuring Multiple LDAP Servers for Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
LDAP Authentication Against Multiple LDAP Servers Or Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Enabling Strong Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Configuring LDAP Servers Or Domains Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Configuring LDAP Servers Or Domains As Authentication Sources . . . . . . . . . . . . . . . . . . . . . . . . . 57
Logging In With LDAP User Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Prerequisites for MFA, Kerberos, and OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Sentinel DNS Name is Case-Sensitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
LDAP and Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Edit Sentinel Server Hosts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Edit OSP Configuration Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Edit Sentinel Configuration Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Update All Computers That Access Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Ensure All Users Have a Valid Email ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Using LDAP with SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Restart Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Configuring Sentinel In High Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Configuring the Sentinel Server for Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Configuring the Kerberos User Account in Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Configuring Browsers to Use Integrated Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Multi-factor Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Using Advanced Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Configuring Sentinel in FIPS Mode to use Advanced Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 75
Using Other SAML 2.0 IDP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configuring Sentinel in FIPS Mode to use SAML 2.0 IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
OAuth Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Creating Credentials for the Google Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configuring the Sentinel Server for OAuth Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configuring Sentinel in FIPS Mode to Use Google OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
An Invalid OAuth2 Request was Received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Invalid Host Header Name or Request URL Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Login Redirects to the Standard Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4 Contents
Accessing Event Source Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Viewing Data in Event Source Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Searching for Event Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Installing Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Updating a Connector or a Collector Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Adding Components to Sentinel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Connecting to Event Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Exporting Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Importing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Managing Event Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Viewing the Event Sources Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Changing the Data Logging Status of Event Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Contents 5
Renaming Event Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6 Contents
15 Configuring Data Retention Policies 181
Rules for Applying a Retention Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Raw Data Retention Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Event Data Retention Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Creating Event Data Retention Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Configuring the Retention Period for the Event Associations Data . . . . . . . . . . . . . . . . . . . . . . . . . 183
Data Deletion Policy for Traditional Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Data Deletion Policy for Scalable Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Contents 7
Configuring the Advisor Products for Exploit Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Downloading the Advisor Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Configuring the Sentinel Server for Automated Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Creating a Download Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Downloading the Feed Instantly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Audit Events for the Download Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Downloading the Advisor Feed Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Viewing the Advisor Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Viewing the Advisor Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Resetting the Advisor Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Deleting the Advisor Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
8 Contents
Managing Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Filtering Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Configuring Alert Retention Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Contents 9
30 Monitoring Sentinel Health 279
10 Contents
Configuring Sentinel Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Decommissioning Tenants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
B Troubleshooting 329
Collector Manager Logs Display the Copying back to Persist Queue Error . . . . . . . . . . . . . . . . . . . . . . . . 329
Event Visualization Dashboards Take a Longer Time to Load Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Unable to View Alerts in the Dashboard and Alert Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Unable to Connect to Sentinel Agent Manager Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Customizing Logging Settings in Sentinel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Customizing Logging Settings in Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Sentinel Control Center Does Not Launch When Identity Manager Designer is Installed on the Client
Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Error While Installing Correlation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Dashboard and Anomaly Definitions with Identical Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Sentinel High Availability Installation in FIPS 140-2 Mode Displays an Error . . . . . . . . . . . . . . . . . . . . . . . 332
Sentinel Services Might Not Start Automatically After the Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Sentinel Does Not Configure the Sentinel Appliance Network Interface By Default . . . . . . . . . . . . . . . . . . 332
New Incoming Alerts Incorrectly Appear to be Selected When You Modify Existing Alerts. . . . . . . . . . . . . 333
Security Intelligence Database and Alert Dashboard Occasionally Do Not Work in Upgraded Custom
Installations of FIPS 140-2 Enabled Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Error When Configuring the NFS Storage After Upgrading Sentinel Appliance to Version 7.3 SP1
and Later. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Cannot Receive Events from Secure Configuration Manager After Upgrading Sentinel to Version 7.3
SP1 and Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Cannot Receive Events from Sentinel UNIX Agent 7.4 After Upgrading Sentinel to Version 7.3 SP1
and Later. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Cannot Create Reports by Using Sentinel SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Data Synchronization Fails While Synchronizing IPv6 Addresses in Human Readable Format. . . . . . . . . 335
Contents 11
12
About this Book and the Library
The Administration Guide provides the administration information and tasks required to manage a
Sentinel deployment.
Intended Audience
This guide is intended for Sentinel administrators and consultants.
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.
Sentinel is a Security Information and Event Management (SIEM) system that receives information
from many sources throughout an enterprise, standardizes it, prioritizes it and presents it to you to
make threat, risk and policy related decisions. For detailed information about Sentinel and its
components, see “Understanding Sentinel” in the Sentinel Installation and Configuration Guide.
Getting Started 15
16 Getting Started
1 Understanding Sentinel Applications
1
There are different tools to help you take advantage of all of the features Sentinel has to offer. For
more information about these tools, see “Introduction to the Sentinel Interface” in the Sentinel User
Guide.
You can add a license key when installing Sentinel. This section provides information about adding
the license key after the Sentinel installation.
If you are using the temporary license key, you must add the enterprise license key before the
temporary key expires to avoid any interruption in the Sentinel functionality. For information about
how to purchase the license, see the Sentinel Product Web site.
You can add a license key either by using the Sentinel Main interface or through the command line.
./softwarekey.sh
This section provides information on how to securely maintain your Sentinel environment.
Traditional Installation
All unnecessary ports are turned off.
Whenever possible, a service port listens only for local connections and does not allow remote
connections.
Files are installed with least privileges so that the least number of users can read the files.
Default passwords are not used.
Reports against the database are run as a user that only has SELECT permissions on the
database.
All web interfaces require HTTPS.
All communication over the network uses SSL by default and is configured to require
authentication.
User account passwords are encrypted by default when they are stored on the file system or in
the database.
Appliance Installation
In addition to the points mentioned in “Traditional Installation” on page 21, the appliance has
undergone the following additional hardening:
Security Considerations 21
The firewall is enabled by default and all unnecessary ports are closed in the firewall
configuration.
Sentinel is automatically configured to monitor the local operating systems syslog messages for
audit purposes.
Sentinel is compatible with disk encryption technologies. These technologies provide a higher level of
data privacy when they are used on file systems where Sentinel stores its data. However, software-
based encryption technologies, such as dm-crypt, have a significant CPU overhead, and they can
dramatically reduce the performance of Sentinel by 50% or more. However, hardware-based
encryption technologies have a much lower impact on the performance of the rest of the system and
are available from leading hard drive manufacturers.
Best Practices
Use the following best practices to secure your Sentinel server:
Changing Passwords
To increase security, you can change the passwords of the system users created during the
installation of Sentinel. There are three types of users:
Administration Users
The admin user is the administrator user for Sentinel applications. The password is set during the
installation process.
22 Security Considerations
Operating System Users
The Sentinel server installation creates a novell system user and a novell group that owns the
installed files within the install_directory. The user’s home directory is set to /home/novell. The
novell user does not have a password and cannot log in to the operating system unless you assign a
password after installation.
dbauser: The dbauser is created as a superuser who can manage the database and is typically the
user who can log in to pgAdmin for troubleshooting purposes. The password for the dbauser is the
same as the admin user password specified during installation. The password must meet
PostgreSQL database password standards.
appuser: The appuser is used to connect to the database for regular operations that do not require a
superuser. The password for the appuser is the same as the password for the admin user specified
during installation.
To modify the password for admin, dbauser, or appuser, use the configure.sh script. For more
information, see Appendix A, “Command Line Utilities,” on page 319. When you change the
password by using the script, Sentinel updates the password in all relevant places without any
manual intervention. However, if you try to change the password by any other method, the password
does not get updated in all of the relevant files and some parts of Sentinel might stop working.
NOTE: There is also a PostgreSQL database user that owns the entire database, including system
database tables. By default, the PostgreSQL database user is set to NOLOGIN, so that no one can log
in as the PostgreSQL user.
You can also use an LDAP directory to authenticate Web application users. To enable this option by
using the Sentinel Main interface, see “LDAP Authentication Against a Single LDAP Server Or
Domain” on page 49. This option has no effect on accounts used by back-end services, which
continue to authenticate through PostgreSQL.
Security Considerations 23
Securing Communication with Collector Managers and
Event Sources
You can configure Sentinel to securely collect data from various event sources. However, secured
data collection is determined by the specific protocols supported by the event source. For example,
the Check Point LEA, Syslog, and Audit Connectors can be configured to encrypt their
communication with event sources.
For more information about the possible security features that you can enable, see the Sentinel Plug-
ins Web site (http://support.novell.com/products/sentinel/secure/sentinelplugins.html).
For more information about configuring the secondary storage location server settings, see
“Configuring Secondary Storage Locations” on page 151.
Auditing Sentinel
Sentinel generates audit events for many actions performed manually and also for actions performed
internally for system activities. Sentinel tags these events with the Sentinel tag. To include these
events in a report, perform a search by using the rv145:Sentinel query and select include system
events. However, you must have the necessary permissions to view system events. For more
information, see Chapter 4, “Configuring Roles and Users,” on page 39.
Sentinel provides reports that are preconfigured to include only the events tagged with the Sentinel
tag.
A well-audited Sentinel system not only audits events occurring within Sentinel, but also the
infrastructure on which Sentinel is running. You can set up data collection from the computers and the
devices that make up the Sentinel infrastructure and tag them with the Sentinel tag to enable a
complete auditing of the systems that can affect the behavior of Sentinel. For appliance installations,
Sentinel is automatically configured to monitor the local operating system’s syslog messages for audit
purposes.
24 Security Considerations
Event Data Approach
The event data approach involves proving that a particular event of interest has not been tampered
with. At a high level, this involves verifying that the partition that the event is stored in has not been
tampered. Since Sentinel computes integrity hashes at the partition level and not the per-event level,
the integrity check must be done at the partition level.
You can verify the integrity of event data by checking if the data in the secondary storage location has
been tampered. Immediately after an event data partition is copied from primary storage to secondary
storage, a hash is computed on the copy of the partition in the secondary storage. You can verify the
integrity of event data using the hash.
1. In the event partition, the data in the following files are concatenated in the following order:
a. index.sqfs
b. All the files in the events.evt directory, in alphabetical order.
2. The concatenation of the files is hashed using the SHA-256 algorithm.
3. The hash is base64 encoded. The base64 encoded hash value is stored in the row associated
with the event partition under the HASH column of the IXLOG_PART table. The event partition
directory name is stored under the NAME column of the IXLOG_PART table.
After the event partition is copied to the secondary storage, the hash value populates in the HASH
column of the IXLOG_PART table. You can determine if the integrity of the event partition has been
compromised by recomputing the hash of the event partition and comparing it with the HASH value in
the IXLOG_PART table.
NOTE: This approach depends on the concept that the hash is stored separately and securely from
the event data. The hash is stored in the authenticated Sentinel database whereas the event data is
stored on the file system (not within the database). You can further protect the hashes by taking
regular backups of the Sentinel database and storing the backups in an even more secure location.
You can retrieve the hashes later to check the event data integrity.
db.sh sql SIEM dbauser "select name, part_date, hash, state, part_id,
ret_pol_id from IXLOG_PART where ret_pol_id='<retention_policy_ID>'"
1d Determine the exact partition by comparing the value in the EventTime field of the event
with the partition dates. The partition dates are in UTC. If you are viewing the EventTime in
your local time, you need to convert the time to UTC to find the right partition date.
2 Find the hash stored in the database for the partition by running the following command:
Security Considerations 25
db.sh sql SIEM dbauser "select name, hash, state from IXLOG_PART where
name='<partition_name>'"
For example,
4 Calculate the hash of an event partition by executing the following command in the partition
directory.
5 Compare the hash values calculated in Step 2 and Step 3. If they match, the event partition has
not been tampered with. If they do not match, the integrity of the file has been compromised.
Sentinel stores the raw data files in one of the following locations:
If your secondary storage is NFS or CIFS, the NFS/CIFS share is automatically mounted to the /var/
opt/novell/sentinel/data/archive_remote directory on the Sentinel server. If the secondary
storage is SAN, the NFS/CIFS share is mounted to the configured directory.
1 Perform the steps described in section, Event Data Approach. These steps are important
because the data in the event is required to find the associated raw data record.
2 In the event, find the value in the following fields:
RawDataRecordId: The ID of the raw data record that was normalized to create the event
is stored in this field. For example, B926DF62-462C-1031-8FE2-000C29E90B7D.
EventSourceID: The ID of the event source the data came from. For example, 9DA14E20-
4595-1031-BE22-000C29E90B7D. In some cases, the display name is shown for the
EventSourceID, such as: sles11sp2:Syslog:Map Output (universal).
SentinelProcessTime: the time when Sentinel processed the data. This information is
useful as an approximation of which raw data log file the data is stored in.
3 In the Sentinel Main interface, click Storage > Download Raw Data.
4 Identify the event source in the list that exactly matches the EventSourceID.
5 Using the SentinelProcessTime, find the raw data files that have a date that is approximately
around this time.
26 Security Considerations
6 Download the raw data files that might have the raw data record.
7 Open the file and search for the RawDataRecordId.
8 After identifying the right raw data file, verify the integrity of the file by clicking Verify Integrity.
Verify the sequence number of JSON records. All JSON records have the same ChainID with a
monotonically increasing ChainSequence number starting with zero. There are no gaps or
missing numbers in the ChainID sequence. If a new ChainID is present, its ChainSequence
begins with zero.If there are gaps in the sequence of numbers, the records were either tampered
or were manually deleted.
Verify the RawDataHash against the RawData. To do this, convert the RawData value to a
sequence of bytes in UTF-8 format. Calculate a 256 SHA digest against those bytes. Convert the
digest to a HEX string, and compare the string with the value in RawDataHash. If they are not
identical, either the RawData or the RawDataHash file was tampered.
If, for example, you want to compute the hash of a file on the file system on Linux, specify a command
similar to the following:
sha256sum F6673C60-573A-102D-ADE0-003048306A7C/2010-06/15-1600.gz
For example, if you want to query the database for the hash of a file, you can specify a command
similar to the following:
However, there is a possibility that a person tampered the files in such a way that the tampering
cannot be detected, because the person also recomputed the sequence number or the RawDataHash.
To determine if the raw data files were tampered, you can also use the hash key values of each raw
data file stored in the database. The Sentinel server calculates a hash key value for every raw data
file and stores it in the RAW_DATA_FILES_INFO in the database.
FILE_NAME: This column contains the relative file name in the following format:
To determine if a file is tampered, compute the SHA-256 hash, convert it to a HEX string (lowercase),
then compare this computed value with the hash value stored in the RAW_DATA_FILES_INFO. If the
values are different, it indicates that either the file or the database has been tampered.
To determine if the files were deleted in an unauthorized way, you can scan the records in the
RAW_DATA_FILES_INFO and look for files whose STATE value is ARCHIVED, ONLINE, or COMPRESSED.
You can ignore those marked DELETED. If the STATE value is ARCHIVED, the raw data file should be in
the secondary storage location. If the STATE value is ONLINE or COMPRESSED, the raw data file should
be in the primary storage location or the secondary storage location.
Security Considerations 27
Using CA Signed Certificates
Sentinel uses several digital, public-key certificates as part of establishing secure TLS/SSL
communications. During the initial configuration of Sentinel, these certificates are self-signed. In
some circumstances, it might be necessary to obtain certificates digitally signed by a certificate
authority (CA).
You can replace the self-signed certificate with a certificate signed by a well-known CA, such as
VeriSign, Thawte, or Entrust. You can also replace the self-signed certificate with a certificate digitally
signed by a less common CA, such as a CA within your company or organization.
NOTE: There are many well-known CAs and identifying which CAs are most commonly used varies
with country.
This section provides information about various certificates used in Sentinel, instructions about
configuring the TLS/SSL certificates to get them digitally signed by a CA, and then importing the
digitally signed certificates into Sentinel:
Types of Certificates
“Web Server Certificate” on page 28
“Java Messaging Service Certificates” on page 28
“SSL Proxy Server Certificate” on page 28
If the web server certificate is not signed by a well-known CA and you connect to the Sentinel Main
interface, Sentinel displays the Connection is Untrusted message.
Broker Certificate
Client Certificate
The JMS certificates are used to establish secure communications between various components of
Sentinel, including the Sentinel server and remote Collector Managers.
28 Security Considerations
Configuring the TLS/SSL Certificates
Configuring the TLS/SSL certificates involves the following steps:
The certificate signing requests are now saved in the specified file.
The details of how this is done depend on the CA. For more information, consult your CA.
You must import the intermediate, root, and signed certificates. You can specify the desired alias
names for the intermediate and root certificates. However, the signed certificate must be imported
with the same alias that was used while creating a certificate pair, which is webserver.
The default keystore password is password. If you have changed the keystore password, specify the
changed password.
cp /etc/opt/novell/sentinel/config/.webserverkeystore.jks /etc/opt/novell/
sentinel/config/.webserverkeystore.jks_bkp
Security Considerations 29
3 Copy the CA signed certificate to the Sentinel server:
cp <CA_signed_certificate> /etc/opt/novell/sentinel/config/
.webserverkeystore.jks
8 Restart Sentinel:
rcsentinel restart
To synchronize the signed certificate with the distributed components after you have successfully
configured it for Sentinel using the steps provided in “Configuring the TLS/SSL Certificates” on
page 29, run the configure.sh script on each distributed component.
1 Log in to the distributed component computer to which you want to synchronize the signed
certificate as the novell user.
2 Go to the /opt/novell/sentinel/setup directory.
3 Run the following command:
configure.sh
For more information about the configure.sh script, see the description in Table A-2 on
page 321.
This ensures that the distributed components use the same signed certificate that Sentinel uses, and
avoids any conflict.
30 Security Considerations
Using Multi-factor Authentication
By default, Sentinel uses single-factor authentication, which matches a password to a user name in
the database. Sentinel also supports multi-factor authentication, which is a more advanced method of
authentication that uses a combination of at least two factors. For example, a combination of a
password and a token or a smart card and a fingerprint. For more information, see “Multi-factor
Authentication” on page 72.
For more information about the various authentication methods Sentinel supports, see Chapter 5,
“Authentication Methods,” on page 47.
<jms brokerURL="failover://(ssl://
${activemq.ip.server}:${activemq.port.userapps}?wireFormat.maxInactivityDuration=3
0000)?randomize=false" interceptors="compression"
keystore="${esecurity.config.home}/config/.activemqclientkeystore.jks"
keystorePassword="${sentinel.keystore.password}" password-
file="${esecurity.config.home}/config/activemqusers.properties"
username="${activemq.client.username}"/>
The jms strategy shown in this XML snippet defines how the Sentinel process connects to the server.
This snippet defines the client-side settings of the connection.
ssl:// Indicates that SSL is used for secure connection. You should not modify this
value.
Security Considerations 31
XML Entry Description
${activemq.ip.server} The hostname or IP address where the Java message service (JMS) server
is running.
${activemq.port.userapps} The port that the JMS server is listening on. The default value is 61616.
interceptors="compression" Enables compression over the connection. You should not modify this
value.
keystore="${esecurity.confi The path to the Java keystore that is used to check if the server is trusted.
g.home}/config/
.activemqclientkeystore.jks
"
password- The location of the file containing the password to present to ActiveMQ for
file="${esecurity.config.ho authenticating the connection.
me}/config/
activemqusers.properties"
username="${activemq.client The user name to present to ActiveMQ for authenticating the connection.
.username}" This corresponds to a ActiveMQ user name in the password-file.
The client applications use SSL by reading the following information in /etc/opt/novell/sentinel/
config/configuration.xml:
32 Security Considerations
Perform the following steps on Sentinel server, Collector Manager, and Correlation Engine:
IMPORTANT: If you are using Agent Manager for host-based data collection, you must use Agent
Manager 8.2 and later and enable a higher version of TLS on the Agent Manager server. For steps to
enable a higher version of TLS on the Agent Manager server, see Enabling Sentinel Agent Manager
to Communicate using TLS 1.2.
Sentinel uses the PostgreSQL driver to connect to the PostgreSQL database, which is a Java Type IV
implementation. This driver supports encryption for data communication.
NOTE: Turning on encryption has a negative impact on the performance of the system. Therefore,
this security concern needs to be weighed against your performance needs. The database
communication is not encrypted by default for this reason. Lack of encryption is not a major concern
because communication with the database occurs over the localhost network interface.
The PostgreSQL database is compiled with the --with-openssl flag. You can configure it to use
encrypted communication, although that is not the default setting. Typically all database
communication in Sentinel is performed locally and not over the network.
Security Considerations 33
To allow pgAdmin to connect from any client computer, add the following line in the /var/opt/
novell/sentinel/3rdparty/postgresql/data/pg_hba.conf file:
If you want to limit the client connections that are allowed to run and connect to the database through
pgAdmin, specify the IP address of the host in the above line. The following line in the pg_hba.conf
file is an indicator to PostgreSQL to accept connections from the local computer so that pgAdmin is
allowed to run only on the server.
To allow connections from other client computers, you can add additional host entries in the
pg_hba.conf file.
To provide maximum security, by default, PostgreSQL only allows connections from the local
computer.
Even if the password is encrypted, you must ensure that the access to the stored password data is
protected to avoid password exposure. For example, you can set permissions to ensure that files with
sensitive data are not readable by other users.
username=appuser
database=SIEM
password=<password>
The following database tables store passwords (/certificate) in encrypted format. You must limit
access to these tables.
Sentinel stores both configuration data and event data in the following locations:
34 Security Considerations
Table 3-2 Locations for Configuration Data and Event Data
Sentinel server The database tables and file system at The database (for example,
/etc/opt/novell/sentinel/ CORRELATED_EVENTS and EVT_RPT_*
config. tables) and the file system at /var/opt/
novell/sentinel/data/eventdata, /
This configuration information includes var/opt/novell/sentinel/data/
the encrypted database, event source, rawdata, /var/opt/novell/sentinel/
integrators, and passwords. data/server.cache, /var/opt/novell/
sentinel/data/map_data, and /var/opt/
novell/sentinel/3rdparty/mongodb.
Collector Manager The file system at /etc/opt/novell/ Event data might be cached on the file system
sentinel/config. The most during error conditions such as the message
sensitive configuration information is bus being down or event overflow. This event
the client key pair used to connect to data is stored in the /var/opt/novell/
the message bus. sentinel/data/collector_mgr.cache
directory.
Security Considerations 35
intruderDetectAdminAutoLock: Specifies whether or not the Sentinel admin account is subject
to automatic locking in response to a series of failed authentication requests. The default is
false since a denial-of-service attack exists in which an attacker can continually lock the built-in
admin account, unless there is a separate administrator account.
The values listed above are defined in the AuthenticationService component of the /etc/opt/
novell/sentinel/config/server.xml file. To customize the AuthenticationService component,
see “Maintaining Custom Settings in XML Files” on page 302.
However, each of these products has its own release cycle, which means that there might be CVEs
that are discovered before a Sentinel update is released. You need to separately review the CVEs for
each embedded third-party product, and decide whether to apply these updates to your Sentinel
system outside of the Sentinel updates.
If you decide to apply patches to address these CVEs outside of a Sentinel update, contact Technical
Support.
36 Security Considerations
II Configuring Roles and Users
I
This section provides information about configuring roles and users that can use Sentinel.
In Sentinel, you can add, edit, and delete roles. You can also grant different permissions at the role
level, and edit the details of user and role profiles.
“Overview” on page 39
“Creating Roles” on page 40
“Configuring Password Complexity” on page 43
“Creating Users” on page 44
Overview
You can create different user roles and assign them different permissions. Role assignment helps you
control users access to functionality, data access based on fields in the incoming events, or both.
Each role can contain any number of users. Users belonging to the same role inherit the permissions
of the role they belong to. You can set multiple permissions for a role.
Administrator: A user in this role has administrative rights in the Sentinel system. You cannot delete
users in this role. Administrative rights include the ability to perform user administration, data
collection, data storage, search operations, rules, report, dashboard, and license management.
Database Administrator: A user in this role has access to events coming from database event
sources. The Collector parsing the data from the event source determines the type of the event
source (database). A user in this role can view data that matches filter rv32:"DB" and search data
targets.
Data Proxy User: This is a system role for proxy users. This role is critical to setting up another
Sentinel system to access your local Sentinel system using the Data Federation feature.
Incident Administrator: A user in this role can manage incidents in the system and control incidents
being handled by other users.
NetFlow Provider: A user in this role can send NetFlow data to Sentinel and manage NetFlow
Collector Managers. A user in this role can also view and analyze the NetFlow data.
Network Administrator: A user in this role can administer network infrastructure devices, such as
routers, switches, and VPNs. This role has access to events coming from devices in the category
NETD or VPN (as determined by the Collector parsing the data) or from event sources with the Network
tag. Set the Network tag on network infrastructure event sources to allow users in this role to view the
events. A user in this role can view data that matches filter rv32:"NETD" OR rv32:"VPN" OR
rv145:"Network", and can search data targets.
Network Security Administrator: A user in this role can administer network security infrastructure
devices, such as firewalls, Ides, and Web proxies. This role has access to events coming from
devices in the category AV, FW, or IDS (as determined by the Collector parsing the data) or from
event sources with the NetworkSecurity tag. Set the NetworkSecurity tag on network
Operator A user in this role can manage alerts, view Security Intelligence Dashboards, share alert
and event views, run reports, view and rename reports, and delete report results. The Threat
Response dashboard allows Operators to triage alerts quickly and efficiently.
PCI Compliance Auditor: A user in this role has access to view events that are tagged with at least
one of the regulation tags such as PCI, SOX, HIPAA, NERC, FISMA, GLBA, NISPOM, JSOX, and
ISO/IEC_27002:2005, and can view system events, view the Sentinel configuration data, and search
data targets.
Report Administrator: A user in this role can run reports, view, rename and delete report results,
add and delete report templates and report results, run reports on configuration database, export all
reports, and save search results as a report. A Report Administrator can also tag report templates
and report results. The Report Administrator can search report templates and report results based on
these tags.
Security Policy Administrator: A user in this role can implement the security policies within the
system for users to access anomaly detection, correlation, incident remediation, and iTRAC
workflows.
System Event Monitor: A user in this role can monitor the Sentinel system for errors or outages.
This role has access only to events coming from Sentinel systems. A user in this role can also access
data coming from event sources that Sentinel is dependent on. For example, you can tag operating
systems on which Sentinel and the Collector Managers are running with a Sentinel event source tag
so that the users in this role can monitor problems in the operating systems. A user in this role can
view data that matches filter rv145:"Sentinel", view system events, and search data targets.
Unix Administrator: A user in this role has access to events from operating system event sources
that are not Windows computers.The type of the event source is determined by verifying the Collector
parsing data and also by verifying if a Windows tag is present. A user in this role can view data that
matches filter (rv32:"OS" NOT (("Microsoft?Active?Directory*" NOT
msg:"Microsoft?Active?Directory*") OR ("Microsoft?Windows*" NOT
msg:"Microsoft?Windows*"))) NOT rv145:"Windows" and search data targets.
User: A user in this role can manage dashboards, run reports, view and rename reports, and delete
report results.
Windows Administrator: A user in this role can administer Windows computers. This role has
access to data generated by Windows event sources. The type of the event source is determined by
verifying the Collector parsing the data. If data from a Windows event source is not being processed
by the Active Directory or the Windows Collector, add the Windows tag to event sources to indicate
that Windows data is being collected from the event source. This enables the Windows administrator
to access the data. A user in this role can view data that matches filter (rv32:"OS" AND
(("Microsoft?Active?Directory*" NOT msg:"Microsoft?Active?Directory*") OR
("Microsoft?Windows*" NOT msg:"Microsoft?Windows*"))) OR rv145:"Windows" and search
data targets.
Creating Roles
Roles allow you define what a user can manage and what data they can view. Permissions are
granted to the role, and then the user is assigned to the role.
To create users for this role, see “Creating Users” on page 44.
By default, all the validation rules are disabled and commented with #. To enable validation rules,
uncomment the rules, specify the values for the rules, and save the file.
RESTRICTED_WORDS_IN_PASSWORD Specifies the words that are not allowed in a password. The
restricted words are case-insensitive. You can specify multiple
words separated by a comma.
For example,RESTRICTED_WORDS_IN_PASSWORD=
admin,password,test
Creating Users
Adding a user in the Sentinel system creates an application user who can then log in to Sentinel. You
also assign roles when you create the user.
If you selected Yes for Anonymous Search: The user name must be the same as the
LDAP directory user name.
If you selected No for Anonymous Search and did not specify the domain name: The
user name does not need to be the same as the LDAP directory user name.
You must also specify the LDAP User DN. If Base DN was set, the Base DN is appended to
the relative user DN to construct the absolute user DN.
For example, if the Base DN was set to o=netiq and the absolute user DN is
cn=sentinel_ldap_user,o=netiq only the relative user DN for example,
cn=sentinel_ldap_user can be specified.
CN=Test\,User,CN=Users,DC=netiq,DC=com
eDirectory or Active Directory might require additional characters to be escaped. Refer the
eDirectory or Active Directory documentation for any additional characters to be escaped.
If you selected No for Anonymous Search and specified the domain name: The user
name must be the same as the LDAP directory user name.
8 Specify a password in the Password field.
NOTE: For local user password, ensure that the password adheres to the password complexity
validation rules. For more information, see “Configuring Password Complexity” on page 43.
By default, Sentinel uses single-factor authentication (SFA), which matches a password (“something
that you know”) to a user name in the database. Sentinel Administrators can configure different types
of strong and multi-factor techniques for all its users.
In addition to the default SFA authentication, Sentinel supports the following types of authentication:
LDAP Authentication: Allows users to log in to Sentinel with their LDAP directory credentials.
For more information, see “LDAP Authentication Against a Single LDAP Server Or Domain” on
page 49 and “LDAP Authentication Against Multiple LDAP Servers Or Domains” on page 55.
Kerberos Authentication: Uses secret-key cryptography to provide strong authentication. For
more information, see “Kerberos Authentication” on page 68.
Multi-factor Authentication (MFA): A more advanced method of authentication that uses a
combination of at least two factors. For example, a combination of a password and a token or a
smart card and a fingerprint. For more information, see “Multi-factor Authentication” on page 72.
OAuth Authentication: Allows users to log in to Sentinel using providers such as Google or
Facebook. For more information, see “OAuth Authentication” on page 77.
An administrator can switch to a different authentication method at any time. Once the administrator
enables an authentication method, Sentinel requires all users to use the authentication process
associated with the selected authentication method.
Enablement Considerations
Before you enable a different authentication method, be aware of the following:
If your environment contains multiple Sentinel servers, all servers must use the same
authentication method. If the servers use different authentication methods, some Sentinel
features, such as distributed search, remote alerts, and Data Federation, do not work.
When you enable MFA, Sentinel is not compatible with the following software:
Secure Configuration Manager 6.2
Change Guardian 4.2.1
Identity Manager
Sentinel and Cisco ISE pxGrid Integration utility
Authentication Methods 47
When you enable MFA, the installation processes for the following components prompt you for
an OAuth client ID and OAuth client secret:
Remote Collector Manager
Remote Correlation Engine
When you map the LDAP user to the Sentinel user, ensure the LDAP user DN field in Sentinel
contains the full DN of the LDAP user in the same case. For example, if the LDAP DN in LDAP
directory is CN=doej,CN=Users,DC=mycompany,DC=com, the LDAP user DN field must also
contain CN=doej,CN=Users,DC=mycompany,DC=com.
For any Sentinel administrator, ensure the logon name contains no spaces between the first
name and last name. For example, JohnSmith. If the logon name has a space, such as John
Smith, the administrator will not be able to install the following:
Remote Collector Manager
Remote Correlation Engine
When you enable MFA, using a previously downloaded .jnlp file to launch either Sentinel Control
Center or Solution Designer is disabled for security reasons. Instead, use the web console to
launch Sentinel Control Center or Solution Designer using a freshly downloaded .jnlp file.
If you are using Sentinel in FIPS mode, Kerberos authentication is not supported.
When you enable MFA, the following utility scripts must specify the OAuth client ID and OAuth
client secret:
backup_util.sh
convert_to_fips.sh
configure.sh
rest_client.sh
To retrieve the OAuth client ID and OAuth client secret, go to the following URL:
https://Hostname:port/SentinelAuthServices/oauth/clients
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
The specified URL uses your current Sentinel session to retrieve the OAuth client ID and OAuth
client secret.
You can create any number of client IDs and clients. To create a new client ID and client secret,
use a RESTful API to send a POST request with the following settings:
Header: application/json
URL: https://Hostname:port/SentinelAuthServices/oauth/clients
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
Payload:
{
appname:"<appname>"
}
To delete a client ID and client secret, use a RESTful API to send a DELETE request to the
following URL:
48 Authentication Methods
https://Hostname:port/SentinelAuthServices/oauth/clients/<clientID>
Where:
Hostname is the host name of the Sentinel server.
Port is the port Sentinel uses (typically 8443).
<clientID> is the client ID you want to delete.
When you run the backup_util.sh script, use the mapped LDAP logon credentials of the Sentinel
administrator wherever the user name and password are required.
For example:
./backup_util.sh -m backup -s -A -b -c -e -i -l -r -w -u myusername -p
mypassword -f fullbackup_up.tar.gz
Where myusername and mypassword are the mapped LDAP credentials for the Sentinel
administrator.
If you create a backup of Sentinel configurations when either MFA or Kerberos is enabled, you
must restore the backup on the same computer.
When you enable Kerberos, logging into Windows also logs you in to Sentinel. When you launch
Sentinel, your browser bypasses the Sentinel login window and automatically proceeds to the
Sentinel landing page. When users log out of Sentinel, they can log back in at any point in time
during the same Windows session by specifying the Sentinel URL.
NOTE: Sentinel LDAP authentication has been tested with Novell eDirectory and Microsoft Active
Directory. Other LDAP compliant directories might be used, but have not been tested. If an issue is
encountered with a directory that has not been tested, support will be provided to the extent that the
issue can be reproduced on one of the tested directories.
“Overview” on page 49
“Prerequisites” on page 50
“Setting Up LDAP Authentication” on page 51
“Logging in by Using LDAP User Credentials” on page 53
“Configuring Multiple LDAP Servers for Failover” on page 53
Overview
LDAP authentication can be performed either using an SSL connection or an unencrypted connection
to the LDAP server.
You can configure the Sentinel server for LDAP authentication either with or without using
anonymous searches on the LDAP directory.
Authentication Methods 49
NOTE: If anonymous search is disabled on the LDAP directory, you must not configure the Sentinel
server to use anonymous search.
Anonymous: When you create Sentinel LDAP user accounts, the directory user name must be
specified and the user distinguished name (DN) does not need to be specified.
When the LDAP user logs in to Sentinel, the Sentinel server performs an anonymous search on
the LDAP directory based on the specified user name, finds the corresponding DN, then
authenticates the user login against the LDAP directory by using the DN.
Non Anonymous: When you create Sentinel LDAP user accounts, the user DN must be
specified along with the user name.
When the LDAP user logs in to Sentinel, the Sentinel server authenticates the user login against
the LDAP directory by using the specified user DN and does not perform any anonymous search
on the LDAP directory.
There is an additional approach applicable only for Active Directory. For more information, see
“Domain Name:” on page 51.
Prerequisites
“Exporting the LDAP Server CA Certificate” on page 50
“Enabling Anonymous Search in the LDAP Directory” on page 50
To export an eDirectory CA certificate in iManager, the Novell Certificate Server plug-ins for
iManager must be installed.
Active Directory: See “How to enable LDAP over SSL with a third-party certification authority”
(http://support.microsoft.com/kb/321051).
eDirectory: See ldapBindRestrictions in section Attributes on the LDAP Server Object (http://
www.novell.com/documentation/edir88/edir88/data/agq8auc.html).
Active Directory: Enabling anonymous binds for Active Directory requires two steps. These
steps are the same for both Windows 2003 and Windows 2008 Active Directory.
Enable Anonymous LDAP Operations: By default, anonymous LDAP operations are
disabled in Active Directory. You must enable anonymous LDAP operations in Active
Directory by setting the dsHeuristics attribute to an appropriate value.
For more information, see Anonymous LDAP operations in Windows 2003 AD (http://
www.petri.co.il/anonymous_ldap_operations_in_windows_2003_ad.htm).
50 Authentication Methods
Assign Permissions to the ANONYMOUS LOGON User: The Read and List Contents
permissions must be assigned to the ANONYMOUS LOGON user.
For more information, see Granting anonymous read access (http://www.petri.co.il/
anonymous_ldap_operations_in_windows_2003_ad.htm).
uid
Active Directory:
sAMAccountName
This field is available only if you selected Yes for Anonymous Search.
Domain Name: Specify the name of the Active Directory domain.
This is an additional approach applicable only for Active Directory for performing LDAP
authentication without using anonymous search.
When you specify the Domain Name, username@domainname (userPrincipalName) is used to
authenticate the user before searching for the LDAP user object.
Authentication Methods 51
For example, test.example.com
This field is applicable only for Active Directory and is available only if you selected No for
Anonymous Search.
NOTE: If Base DN is set and Domain Name is not set, the Base DN is appended to the relative
user DN to construct the absolute user DN.
For example, if the Base DN is set to o=netiq and the absolute user DN is
cn=sentinel_ldap_user,o=netiq when the LDAP user account is created, only the relative
user DN of cn=sentinel_ldap_user can be specified.
CN=Test\,User,CN=Users,DC=netiq,DC=com
eDirectory or Active Directory might require additional characters to be escaped. Refer the
eDirectory or Active Directory documentation for any additional characters to be escaped.
If you selected No for Anonymous Search and specified the Domain Name: Specify
the user name and password.
4b Click Test to test the LDAP connection.
A message is displayed that indicates whether the connection is successful.
If there is an error, review the configuration details you provided and test the connection
again.You can determine the cause of the failure by examining the /var/opt/novell/
sentinel/log/server0.0.log file. You must ensure that the test connection is successful
before saving the LDAP settings.
5 Click Save to save the LDAP settings.
On successful configuration:
The LdapLogin section of the /etc/opt/novell/sentinel/config/auth.login file is
updated. For example:
52 Authentication Methods
LdapLogin {
com.sun.security.auth.module.LdapLoginModule required
java.naming.ldap.factory.socket="com.esecurity.common.communication.ProxyL
dapSSLSocketFactory"
userProvider="ldap://10.0.0.1:636/o=netiq"
userFilter="(&(uid={USERNAME})(objectclass=user))"
useSSL=true;
};
After saving the LDAP settings successfully, you can create LDAP user accounts to enable users to
log in to Sentinel by using their LDAP directory credentials.
NOTE: You can also configure the Sentinel server for LDAP authentication by running the
ldap_auth_config.sh script in the /opt/novell/sentinel/setup directory.
The script also supports command line options. To view the command line options, run the script as
follows:
/opt/novell/sentinel/setup/ldap_auth_config.sh --help
After you create the LDAP user account, you can log in to the Sentinel by using your LDAP user
name and password.
su - novell
cd /etc/opt/novell/sentinel/config/
vi auth.login
5 Update the userProvider in the LdapLogin section to specify multiple LDAP URLs. Separate
each URL by a blank space.
For example:
userProvider="ldap://primary_server_IP:port/BaseDN ldap://
failover_server_IP:port/BaseDN"
For Active Directory, ensure that the BaseDN in the LDAP URL is not blank.
Authentication Methods 53
For more information on specifying multiple LDAP URLs, see the description of the
userProvider option in “Class LdapLogin Module” (http://java.sun.com/javase/6/docs/jre/api/
security/jaas/spec/com/sun/security/auth/module/LdapLoginModule.html).
6 Save the changes.
If you are using an SSL connection to the LDAP server and if the LDAP server certificate is not signed
by a well-known CA, you must perform the following additional steps:
1 Export the certificate of each failover LDAP server and copy the certificate file to the /etc/opt/
novell/sentinel/config directory on the Sentinel server.
For more information, see “Exporting the LDAP Server CA Certificate” on page 50.
2 Ensure that you set the necessary ownership and permissions of the certificate file for each
LDAP server.
Replace <certificate-file> is the LDAP certificate filename and <alias_name> with the alias
name for the certificate to be added.
IMPORTANT: Ensure that you specify the alias. If no alias is specified, the keytool takes mykey
as the alias by default. When you import multiple certificates into the keystore without specifying
an alias, the keytool reports an error that the alias already exists.
In some environments, the Sentinel server might not connect to the failover LDAP server if the
Sentinel server times out before it finds that the primary LDAP server is down. In such cases, perform
the following additional steps to ensure that the Sentinel server connects to the failover LDAP server
without timing out:
vi /etc/sysctl.conf
2 Ensure that the net.ipv4.tcp_syn_retries value is set to 3. If the entry does not exist, add
the entry. Save the file:
net.ipv4.tcp_syn_retries = 3
/sbin/sysctl -p
/sbin/sysctl -w net.ipv4.route.flush=1
vi /etc/opt/novell/sentinel/config/server.conf
5 Set the Sentinel server time out value to 60 seconds by appending a new parameter in the Java
Additional Parameters section as follows:
wrapper.java.additional.53=-Desecurity.remote.timeout=60
54 Authentication Methods
6 Restart the Sentinel server:
/etc/init.d/sentinel restart
“Prerequisites” on page 55
“Enabling Strong Authentication” on page 56
“Configuring LDAP Servers Or Domains Properties” on page 56
“Configuring LDAP Servers Or Domains As Authentication Sources” on page 57
“Logging In With LDAP User Credentials” on page 62
Prerequisites
Complete the prerequisites listed in “Enablement Considerations” on page 47.
(Conditional) Edit the Sentinel server Hosts file. If the Sentinel server is not a member of the
enterprise domain, update the /etc/hosts file with the fully qualified domain name (FQDN) of
the Sentinel server.
Update the hosts file on all the client machines that access Sentinel:
1. Open the hosts file:
Windows: Browse to C:\Windows\System32\Drivers\etc directory.
Linux: Go to /etc directory.
2. Add the following entry:
<sentinel_ip> <sentinel_fqdn> <sentinel_hostname>
Where:
<sentinel_ip> is the IP address of the Sentinel server.
<sentinel_fqdn> is the FQDN of the Sentinel server.
<sentinel_hostname> is the host name of the Sentinel server.
For example:
1.2.3.4 sentinel.mycompany.com sentinel
Ensure that all LDAP users have an email ID and that the email ID is populated in the mail
attribute in the LDAP directory.
(Conditional) If you are using LDAP with SSL and you want the Sentinel server to communicate
with LDAP servers over the SSL port (default 636), perform the following:
If the Sentinel server is running in non-FIPS mode, import the CA certificate chain of each
LDAP server into the Sentinel server keystore:
1. Log in to the Sentinel server as root.
2. Execute the following commands:
Authentication Methods 55
cd /opt/novell/sentinel/jdk/jre/bin
./keytool -importcert -file <cert_file_path> -keystore /etc/opt/novell/
sentinel/config/.webserverkeystore.jks -alias <alias>
Where:
<cert_file_path> is the path of the certificate file you want to import.
<alias> is the alias name you want to assign to the certificate in the Sentinel keystore.
If the Sentinel server is running in FIPS mode, import the CA certificate chain of each LDAP
server into the Sentinel FIPS keystore. For more information about importing certificates in
FIPS mode, see Importing Certificates into FIPS Keystore Database.
NOTE: Ensure that there are no extra spaces when you add the following properties.
com.netiq.sentinel.osp.ldap.host=<ldap_host>
Where <ldap_host> is the IP address or hostname of the LDAP server.
com.netiq.sentinel.osp.ldap.port=<ldap_port>
Where <ldap_port> is the port number of the LDAP connection. The default SSL port
number is 636 and the default non-SSL port number is 389.
com.netiq.sentinel.osp.ldap.use-ssl=true/false
Where true/false specifies whether the LDAP connection uses SSL or not.
com.netiq.sentinel.osp.ldap.dir-type=<ldap_directory_type>
Where <ldap_directory_type> is the directory type of the LDAP server. For example, the
directory type of Active Directory is AD and the directory type of eDirectory is edir.
com.netiq.sentinel.osp.as.naming-attr=<naming_attribute>
56 Authentication Methods
Where <naming_attribute> is the naming attribute of the LDAP server. Naming attribute is
the LDAP attribute that contains the user login name and is used in the LDAP search filter
while searching for users. For example, the naming attribute for Active Directory can be
sAMAccountName and the naming attribute for eDirectory can be uid or cn.
com.netiq.sentinel.osp.as.admins-container-dn=<admins_container_dn>
Where <admins_container_dn> is the DN of the container for admin users in the LDAP
server. For example, CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.as.users-container-dn=<users_container_dn>
Where <users_container_dn> is the DN of the container for users in the LDAP server. For
example, CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.ldap.admin-dn=<ldap_admin_dn>
Where <ldap_admin_dn> is the DN of the admin user in the LDAP server. For example,
CN=Administrator,CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.ldap.admin-pwd=<ldap_admin_pwd>
Where <ldap_admin_pwd> is the encrypted password of the admin user in the LDAP
server.
To get the encrypted password, run the encryptpwd script. Log in as the novell user and
go to the /opt/novell/sentinel/bin directory. Run the following command:
./encryptpwd -e LDAPAdminPassword
4 Configure every additional LDAP server or domain by adding the properties of each additional
LDAP server or domain to the osp-configuration.properties as follows:
For the second LDAP server or domain, add:
com.netiq.sentinel.osp.ldap.host2, com.netiq.sentinel.osp.ldap.port2,
com.netiq.sentinel.osp.ldap.use-ssl2, com.netiq.sentinel.osp.ldap.dir-
type2, com.netiq.sentinel.osp.as.naming-attr2,
com.netiq.sentinel.osp.as.admins-container-dn2,
com.netiq.sentinel.osp.as.users-container-dn2,
com.netiq.sentinel.osp.ldap.admin-dn2, com.netiq.sentinel.osp.ldap.admin-
pwd2
For the third LDAP server or domain, add:
com.netiq.sentinel.osp.ldap.host3, com.netiq.sentinel.osp.ldap.port3,
com.netiq.sentinel.osp.ldap.use-ssl3, com.netiq.sentinel.osp.ldap.dir-
type3, com.netiq.sentinel.osp.as.naming-attr3,
com.netiq.sentinel.osp.as.admins-container-dn3,
com.netiq.sentinel.osp.as.users-container-dn3,
com.netiq.sentinel.osp.ldap.admin-dn3, com.netiq.sentinel.osp.ldap.admin-
pwd3
Repeat the same instructions for subsequent LDAP servers or domains.
Authentication Methods 57
To configure LDAP Servers Or Domains As Authentication Sources
<LDAPDataSource
displayName="LDAP Datasource2"
id="ds-ldap2"
adminName="${com.netiq.sentinel.osp.ldap.admin-dn2}"
adminPassword="${com.netiq.sentinel.osp.ldap.admin-
pwd2}"
dirType="${com.netiq.sentinel.osp.ldap.dir-type2}"
>
<Server
secureConnection="${com.netiq.sentinel.osp.ldap.use-ssl2}"
host="${com.netiq.sentinel.osp.ldap.host2}"
maxConnections="${com.netiq.sentinel.osp.ldap.max-connections2:31}"
port="${com.netiq.sentinel.osp.ldap.port2}"
/>
</LDAPDataSource>
<LDAPDataSource
displayName="LDAP Datasource3"
id="ds-ldap3"
adminName="${com.netiq.sentinel.osp.ldap.admin-dn3}"
adminPassword="${com.netiq.sentinel.osp.ldap.admin-
pwd3}"
dirType="${com.netiq.sentinel.osp.ldap.dir-type3}"
>
<Server
secureConnection="${com.netiq.sentinel.osp.ldap.use-ssl3}"
host="${com.netiq.sentinel.osp.ldap.host3}"
maxConnections="${com.netiq.sentinel.osp.ldap.max-connections3:31}"
port="${com.netiq.sentinel.osp.ldap.port3}"
/>
</LDAPDataSource>
58 Authentication Methods
4 Add additional LDAPAuthenticationSource elements:
4a Search for the existing LDAPAuthenticationSource element corresponding to the first
LDAP server or domain.
4b Add a new LDAPAuthenticationSource element below the existing element in a
sequence, for every additional LDAP server or domain, as follows:
For the second LDAP server or domain:
<LDAPAuthenticationSource
displayName="LDAP Authentication Source2"
id="as-ldap2"
restrictToContexts="${com.netiq.sentinel.osp.as.restrict-to-
contexts2:false}"
>
<Reference refId="ds-ldap2" type="DataSource"/>
<!-- NamingAttr values for LDAP define which attributes
are used in an LDAP search filter when search for a user object -->
<NamingAttr name="${com.netiq.sentinel.osp.as.naming-
attr2:cn}"/>
<NamingAttr name="mail"/>
<!-- Context values define the base context(s) in which
to search for users. Each context will be searched in order -->
<Context context="${com.netiq.sentinel.osp.as.users-
container-dn2}" decorator="search" order="0"
scope="${com.netiq.sentinel.osp.as.scope2:subtree}"/>
<Context context="${com.netiq.sentinel.osp.as.admins-
container-dn2}" decorator="search" order="1"
scope="${com.netiq.sentinel.osp.as.scope2:subtree}"/>
<AttributeMapping>
<AttributeMapEntry localName="userDN"
nativeName="{$dn}"/>
<!-- The "dn" entry is for use in admin-defined
SelectExpression instances ("{$dn}" is a predefined "pseudo" attr name)
-->
<AttributeMapEntry localName="dn"
nativeName="{$dn}"/>
<AttributeMapEntry localName="userName"
nativeName="${com.netiq.sentinel.osp.as.naming-attr2:cn}"/>
<AttributeMapEntry localName="saml2-mapping-attr"
nativeName="${com.netiq.sentinel.osp.login.saml2.mapping-attr2:mail}"/
>
</AttributeMapping>
</LDAPAuthenticationSource>
Authentication Methods 59
For the third LDAP server or domain:
<LDAPAuthenticationSource
displayName="LDAP Authentication Source3"
id="as-ldap3"
restrictToContexts="${com.netiq.sentinel.osp.as.restrict-to-
contexts3:false}"
>
<Reference refId="ds-ldap3" type="DataSource"/>
<!-- NamingAttr values for LDAP define which attributes
are used in an LDAP search filter when search for a user object -->
<NamingAttr name="${com.netiq.sentinel.osp.as.naming-
attr3:cn}"/>
<NamingAttr name="mail"/>
<!-- Context values define the base context(s) in which
to search for users. Each context will be searched in order -->
<Context context="${com.netiq.sentinel.osp.as.users-
container-dn3}" decorator="search" order="0"
scope="${com.netiq.sentinel.osp.as.scope3:subtree}"/>
<Context context="${com.netiq.sentinel.osp.as.admins-
container-dn3}" decorator="search" order="1"
scope="${com.netiq.sentinel.osp.as.scope3:subtree}"/>
<AttributeMapping>
<AttributeMapEntry localName="userDN"
nativeName="{$dn}"/>
<!-- The "dn" entry is for use in admin-defined
SelectExpression instances ("{$dn}" is a predefined "pseudo" attr name)
-->
<AttributeMapEntry localName="dn"
nativeName="{$dn}"/>
<AttributeMapEntry localName="userName"
nativeName="${com.netiq.sentinel.osp.as.naming-attr3:cn}"/>
<AttributeMapEntry localName="saml2-mapping-attr"
nativeName="${com.netiq.sentinel.osp.login.saml2.mapping-attr3:mail}"/
>
</AttributeMapping>
</LDAPAuthenticationSource>
60 Authentication Methods
<PrincipalMapping
id="ldap-mapping2"
displayName="LDAP User to Sentinel User Mapping2"
enabled="true"
>
<Reference refId="as-ldap2" type="AuthenticationSource"
decorator="srcId"/>
<Reference refId="as-sentinel" type="AuthenticationSource"
decorator="destId"/>
<And>
<Or>
<Equal sourceAttrName="userDN" targetAttrName="userDN"/>
<Equal sourceAttrName="userName"
targetAttrName="userName"/>
</Or>
<Equal targetAttrName="authSource">LDAP</Equal>
</And>
</PrincipalMapping>
<PrincipalMapping
id="ldap-mapping3"
displayName="LDAP User to Sentinel User Mapping3"
enabled="true"
>
<Reference refId="as-ldap3" type="AuthenticationSource"
decorator="srcId"/>
<Reference refId="as-sentinel" type="AuthenticationSource"
decorator="destId"/>
<And>
<Or>
<Equal sourceAttrName="userDN" targetAttrName="userDN"/>
<Equal sourceAttrName="userName"
targetAttrName="userName"/>
</Or>
<Equal targetAttrName="authSource">LDAP</Equal>
</And>
</PrincipalMapping>
Authentication Methods 61
<PasswordAuthentication
displayName="Name/Password (Form)"
id="np-auth"
enabled="${com.netiq.sentinel.osp.np-enabled:true}"
continueButton="${com.netiq.sentinel.osp.login.use-continue-button:true}"
showHide="${com.netiq.sentinel.osp.login.allow-show-hide:undefined}"
showHideInitialState="${com.netiq.sentinel.osp.login.show-hide-initial-
state:undefined}"
useHints="${com.netiq.sentinel.osp.login.use-hints:false}"
<!-- these references define which authentication sources will be used with
the name/password auth class -->
<!-- disabled db user login in strong auth mode -->
<!--<Reference refId="as-sentinel" type="AuthenticationSource">
<Reference refId="ul-sentinel" type="UserLookup"
decorator="additional-criteria"/>
</Reference>-->
<Reference refId="as-ldap" type="AuthenticationSource"/>
<Reference refId="as-ldap2" type="AuthenticationSource"/>
<Reference refId="as-ldap3" type="AuthenticationSource"/>
<!-- And so on... -->
</PasswordAuthentication>
<AuthContract
displayName="Username/Password Login"
id="np-contract"
uri="sentinel:login:user:np"
expiredPasswordUrl="${com.netiq.sentinel.osp.auth.pwd.expire.url}"
showExpiredPwdUI="${com.netiq.sentinel.osp.auth.pwd.expire.show:false}"
enabled="${com.netiq.sentinel.osp.np-enabled:true}"
>
<Reference refId="np-auth" type="ContractExecutable"/>
<Reference refId="ldap-mapping" type="ContractExecutable"/>
<Reference refId="ldap-mapping2" type="ContractExecutable"/>
<Reference refId="ldap-mapping3" type="ContractExecutable"/>
<!-- And so on... -->
<Reference refId="unlocked-validator" type="ContractExecutable"/>
<Reference refId="admin-role-mapping" type="ContractExecutable"/>
</AuthContract>
8 (Conditional) If you are using Sentinel in High Availability (HA) mode, perform the steps at
“Configuring Sentinel In High Availability” on page 67.
9 For the above configuration changes to take effect, restart the Sentinel server:
rcsentinel restart
62 Authentication Methods
NOTE: After you enable LDAP authentication against multiple LDAP servers or domains, you
can only use the hostname in the URL, and not the IP address.
2 Log in to Sentinel with the value of the naming attribute of the LDAP user to which you mapped
the Sentinel admin user.
You mapped the Sentinel admin user to a corresponding LDAP user DN in Step 4 on page 56
and configured the LDAP naming attribute when “Configuring LDAP Servers Or Domains
Properties” on page 56.
NOTE: After you enabled LDAP authentication against multiple LDAP servers or domains, you
cannot use the user name admin to log in to Sentinel as the admin user.
Before you configure the Sentinel server to use either MFA or Kerberos, complete the following:
Authentication Methods 63
“Restart Sentinel” on page 67
“Configuring Sentinel In High Availability” on page 67
NOTE: After you configure your environment to use MFA, the Email ID and User DN fields are
required. As a result, existing Sentinel users will not be able to log in to Sentinel. You must update all
users with valid email ID and User DN.
When you create new users, ensure that they have a valid email ID and User DN.
com.netiq.sentinel.osp.as.naming-attr=LDAPProviderName
Where LDAPProviderName is the name attribute of your LDAP provider. For example, the name
attribute for Active Directory is sAMAccountName.
com.netiq.sentinel.osp.ldap.dir-type=LDAPDirectoryType
Where LDAPDirectoryType is the directory type of your LDAP provider. For example, the
directory type for Active Directory is AD.
com.netiq.sentinel.osp.as.admins-container-dn=AdminContainerDN
Where AdminContainerDN is the container DN for the admin user in Sentinel. For example,
CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.ldap.host=LDAP_IP
Where LDAP_IP is the IP address of the LDAP server.
com.netiq.sentinel.osp.ldap.port=LDAP_Port
Where LDAP_Port is the port number for the LDAP connection. The default SSL port number is
636 and the default non-SSL port number is 389.
64 Authentication Methods
com.netiq.sentinel.osp.ldap.use-ssl=true/false
Where true/false specifies whether LDAP uses SSL.
(Conditional) If this value is true, you must use the keytool command to import the LDAP
server certificate into the /etc/opt/novell/sentinel/config/.webserverkeystore.jks file.
For example:
/opt/novell/sentinel/jdk/jre/bin/keytool -importcert -alias <AliasName> -file
<FileName>.cer -keystore /etc/opt/novell/sentinel/config/
.webserverkeystore.jks
Where:
<AliasName> is the new alias name you want to assign to the certificate in the Sentinel
keystore.
<FileName> is the name of the certificate file you want to import.
com.netiq.sentinel.osp.as.users-container-dn=UserContainerDN
Where UserContainerDN is the container DN for the users in Sentinel. For example,
CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.ldap.admin-dn=AdminDN
Where AdminDN is the DN for the admin user in Sentinel. For example,
CN=Administrator,CN=Users,DC=mycompany,DC=com.
com.netiq.sentinel.osp.ldap.admin-pwd=LDAPAdminPassword
Where LDAPAdminPassword is the encrypted password for the LDAP server administrator.
NOTE: To encrypt the password, run the encryptpwd script as the novell user:
./encryptpwd -e LDAPAdminPassword
The script is located in the /opt/novell/sentinel/bin directory.
1 Set strong.authentication.enabled=true
2 Add admin.user.auth.dn=LDAP_DN_ForSentinelAdminUser
Where LDAP_DN_ForSentinelAdminUser is the mapped LDAP DN for the admin user in
Sentinel.
NOTE: When you install Sentinel, the installation process creates the admin user by default as
an out-of-the-box user. To enable MFA or Kerberos authentication and use the admin user again,
you must map the admin user to a corresponding LDAP DN. Once you enable Kerberos
authentication, you cannot use the out-of-the-box admin user to log in to Sentinel. Instead, you
must use the mapped LDAP DN to log in to Sentinel.
3 (Conditional) If you are using Sentinel in High Availability (HA) mode, Add
sentinel.ha.cluster.hostname=FQDN_Virtual_Hostname.
Where FQDN_Virtual_Hostname is the FQDN of the HA virtual IP address in all nodes of the HA
cluster.
Authentication Methods 65
Update All Computers That Access Sentinel
On every computer your users will use to access Sentinel, go to
C:\Windows\System32\Drivers\etc and complete the following steps:
OAuth Ensure that all Sentinel users (including the admin) have a valid registered email ID with the
same email provider as the OAuth IDP. For example, if you use Google, all users must have valid
gmail IDs.
1 Import the certificate file for AD and LDAP to the Sentinel server keystore.
In a command prompt, go to /opt/novell/sentinel/jdk/jre/bin and use the following
command:
./keytool -importcert -file FileName.cer -keystore /etc/opt/novell/sentinel/
config/.webserverkeystore.jks -alias AliasName
Where:
FileName is the name of the certificate file you want to import.
AliasName is the new alias name you want to assign to the certificate in the Sentinel
keystore.
2 Go to the /etc/opt/novell/sentinel/config directory and complete the following steps:
2a Open the osp-configuration.properties file.
2b Ensure the following:
com.netiq.sentinel.osp.ldap.port=636
com.netiq.sentinel.osp.ldap.use-ssl=true
3 Log in to the Sentinel server as the novell user, then run the following command:
touch /etc/opt/novell/sentinel/3rdparty/jetty/contexts/osp.xml
66 Authentication Methods
Restart Sentinel
After you have completed all the prerequisites, restart Sentinel. Use the following command:
rcsentinel restart
1 Log in to the active node of the HA cluster and run the following command:
csync2 -x -v
2 (Conditional) If the cluster does not start correctly, perform the following steps:
2a Manually copy the /etc/corosync/corosync.conf file from node01 to node02, or run the
csync2 -x -v on node01, or manually set the cluster up on node02 through YaST.
2b (Conditional) If the csync2 -x -v command you run in the previous step fails to
synchronize all the files, perform the following procedure:
2b1 Clear the csync2 database (in the /var/lib/csync2 directory) on all the nodes.
2b2 Run the following command on all servers to update the csync2 database to match the
filesystem, but without marking anything as needing to be synchronized to other
servers:
csync2 -cIr /
2b3 Run the following command to find all the differences between authoritative server and
remote servers, and mark for synchronization:
csync2 -TUXI
2b4 Run the following command to reset the database to force the current server to be
winner on any conflicts:
csync2 -fr /
2b5 Run the following command to start a synchronization to all the other servers:
csync2 -xr /
2b6 Run the following command to verify that all the files are synchronized:
csync2 -T
This command will not list any files if the synchronization is successful.
2c Run the following command on node02:
For SLES 11 SP4:
/etc/rc.d/openais start
For SLES 12 SP1 and later:
systemctl start pacemaker.service
(Conditional) If the xinetd service does not properly add the new csync2 service, the script
will not function properly. The xinetd service is required so that the other node can sync the
cluster configuration files down to this node. If you see errors like csync2 run failed, you
may have this problem.
Authentication Methods 67
To resolve this issue, execute the kill -HUP `cat /var/run/xinetd.init.pid
command and then re-run the sleha-join script.
2d Run crm_mon on each cluster node to verify that the cluster is running properly. You can also
use 'hawk', the web console, to verify the cluster. The default login name ishacluster and
the password is linux.
Kerberos Authentication
This section provides instructions for configuring Sentinel to work with Kerberos authentication.
Before you continue, ensure that you have met all prerequisites. For more information, see
“Prerequisites for MFA, Kerberos, and OAuth” on page 63.
NOTE: Before you continue, ensure that you have read the enablement considerations and met all
prerequisites. For more information, see “Enablement Considerations” on page 47 and “Prerequisites
for MFA, Kerberos, and OAuth” on page 63.
NOTE: For domain or realm references, use uppercase format. For example @MYCOMPANY.COM.
1 As an Administrator in Active Directory, use the Microsoft Management Console (MMC) to create
a new user account with the DNS name of the Sentinel server.
For example, if the DNS name of the Sentinel server is rbpm.mycompany.com, ensure the
following:
First name: rbpm
User logon name: HTTP_rbpm.mycompany.com
68 Authentication Methods
NOTE: The slash character ( / ) is not supported during user creation. After you save the user
account, edit the user account and replace / with an underscore ( _ ).
For example:
For example:
IMPORTANT: For domain or realm references, use uppercase format. For example,
@MYCOMPANY.COM.
Authentication Methods 69
# Default Kerberos Realm
[libdefaults]
default_realm = <WINDOWS-DOMAIN>
kdc_timeout = 15000
max_retries = 2
udp_preference_limit = 1
admin_server = <DomainControllerIPAddress>
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
7 In the /etc/opt/novell/sentinel/config directory, open the auth.login file and add the
following entry:
com.sun.security.jgss.krb5.accept {
com.sun.security.auth.module.Krb5LoginModule required
debug="true"
refreshKrb5Config="true"
doNotPrompt="true"
principal="HTTP/<DNS_Sentinel_server>@<WINDOWS-DOMAIN>"
useKeyTab="true"
keyTab="/etc/opt/novell/sentinel/config/<filename>.keytab"
useTicketCache="false"
storeKey="true";
};
8 To enable AES256 in your Java Runtime Environment, complete the following steps:
8a Download Java Cryptography Extension (JCE) 8 from the following location:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-
2133166.html
8b Extract the two *.jar files and copy them to the /opt/novell/sentinel/jdk/jre/lib/
security directory.
8c (Conditional) If you are running Sentinel in an HA environment, repeat these steps on all
nodes in the cluster.
9 (Optional) To enable debug logs for troubleshooting, complete the following steps:
9a In the /etc/opt/novell/sentinel/config directory, open the server.conf file.
9b Ensure the following:
wrapper.java.additional.50=-Dsun.security.krb5.debug=true
com.netiq.sentinel.osp.logging.level=ALL
10 Ensure that user mapping are correct between AD, LDAP, and Sentinel.
11 Restart the Sentinel server:
70 Authentication Methods
rcsentinel restart
12 (Conditional) If you are running Sentinel in an HA environment, log in to the active node of the
HA cluster and run the following command:
csync2 -x -v
NOTE: You must perform this procedure for each user’s computer.
Internet Explorer
1 In the Internet Options dialog box, click Security.
2 Click Trusted Sites > Sites.
3 Add the DNS name of the Sentinel server.
For example: https://rbpm.mycompany.com
4 Click Add, then click Close.
5 Click Custom level.
6 Under User Authentication, select Automatic logon with current user name and password.
7 Click OK.
8 Repeat this procedure for each end-user computer.
Mozilla Firefox
1 In the browser’s address field, type about:config.
2 Set the Value of the following Preferences to the Windows domain name, such as
.mycompany.com:
network.automatic-ntlm-auth.trusted-uris
network.negotiate-auth.trusted-uris
3 Repeat this procedure for each end-user computer.
Google Chrome
1 Go to Settings, and then click Show advanced settings.
2 Under Network, click Change proxy settings.
3 In the Internet Properties dialog box, click Security.
4 Click Trusted Sites > Sites.
5 Add the DNS name of the Sentinel server.
For example: https://rbpm.mycompany.com
6 Click Add, then click Close.
Authentication Methods 71
7 Click Custom level.
8 Under User Authentication, select Automatic logon with current user name and password.
9 Click OK.
10 Repeat this procedure for each end-user computer.
Multi-factor Authentication
Sentinel supports MFA by integrating with any identity provider (IDP) software that supports the
following:
Multi-factor authentication
SAML 2.0
For example, if you integrate Sentinel with Advanced Authentication™ in your environment,
Advanced Authentication handles authentication while Sentinel handles authorization.
NOTE: Before you continue, ensure that you have read the enablement considerations and met all
prerequisites. For more information, see “Enablement Considerations” on page 47 and “Prerequisites
for MFA, Kerberos, and OAuth” on page 63.
NOTE: Ensure that you are using a supported version of Advanced Authentication. For information
about which versions of Advanced Authentication are supported, see the Technical Information for
Sentinel page.
72 Authentication Methods
4 To establish a trust relationship between Sentinel and Advanced Authentication, you need to
generate a .jks file for the keystore that contains a self-signed certificate for Advanced
Authentication.
NOTE: You cannot use the existing Advanced Authentication certificate because it does not
contain a subject alternative name.
Authentication Methods 73
./keytool -exportcert -keystore FileName.jks -alias AliasName -file
FileName1.cer
Where:
FileName is the name of the file you want to convert.
AliasName is the alias name you assigned to the certificate.
FileName1 is the name of the file you want to create.
For example:
./keytool -exportcert -keystore AA.jks -alias selfsigned1 -file myAA.cer
7 To import the new certificate file to the Sentinel server keystore, complete the following steps.
7a Go to the /opt/novell/sentinel/jdk/jre/bin directory.
7b Use the following command:
./keytool -importcert -file FileName.cer -keystore /etc/opt/novell/
sentinel/config/.webserverkeystore.jks -alias AliasName
Where:
FileName is the name of the certificate file you want to import.
AliasName is the new alias name you want to assign to the certificate in the Sentinel
keystore.
For example:
./keytool -importcert -file myAA.cer -keystore /etc/opt/novell/sentinel/
config/.webserverkeystore.jks -alias myAA
8 Log in to Advanced Authentication and complete the following steps:
8a Navigate to Server Options.
8b Upload the .pfx file you created previously, using the password you used for creating the
.jks file.
8c Enable WebAuth.
9 On the Sentinel server, run the following command:
touch /etc/opt/novell/sentinel/3rdparty/jetty/contexts/osp.xml
10 To retrieve the SAML metadata from Sentinel, complete the following steps:
10a In the /etc/opt/novell/sentinel/osp/WEB-INF/conf/current/siem/services
directory, open the authcfg.xml file and modify the following property:
failOnError="false"
10b In your web browser, go to the following URL:
https://DNS_Sentinel_server:Port/osp/a/siem/auth/saml2/spmetadata
Where DNS_Sentinel_server is the FQDN of the Sentinel server and Port is the port
Sentinel uses (typically 8443).
10c Copy the SAML metadata and save it in a new sentinel.xml file.
11 In Advanced Authentication, complete the following steps:
11a Navigate to Events.
11b Create a new event named SAML and upload the sentinel.xml file.
11c (Optional) Create a new chain of authentication factors to replace the default Password
only chain.
74 Authentication Methods
11d Navigate to Policies and edit the SAML 2.0 policy and specify the IP address of the
Advanced Authentication server.
11e Navigate to Repositories and add the LDAP repository.
12 (Conditional) Ensure that you add any additional authenticators that are required for the
authentication chain. The default authentication chain includes the Email, OTP, LDAP password,
Mobile ID, and RADIUS authentication methods. For more information, see the Advanced
Authentication Administration Guide.
13 (Conditional) If your authentication chain includes any authentication methods other than the
default methods, have all users go to the Advanced Authentication Self-Service Portal (https:/
/IDP_IP/account, where IDP_IP is the IP address of the Advanced Authentication server) and
enroll in the additional authenticator methods, as defined in the authentication chain. For
example, finger prints, retinal scans, or security questions. For more information, see the
Advanced Authentication User Guide.
14 (Conditional) If you are using Sentinel in High Availability (HA) mode, log in to the active node of
the HA cluster and run the following command:
csync2 -x -v
rcsentinel restart
Authentication Methods 75
8 (Conditional) If you are using Sentinel in High Availability (HA) mode, log in to the active node of
the HA cluster and run the following command:
csync2 -x -v
76 Authentication Methods
Configuring Sentinel in FIPS Mode to use SAML 2.0 IDP
1 Log in to the Sentinel server.
2 Browse to the Sentinel bin directory.
3 Run the following script:
create_mfa_fips_keys.sh <nss_password/password_file>
Where nss_password is the password for the NSS database and password_file is the file that
stores the NSS password. Specify only one of these.
4 Update the /etc/hosts file with the hostname of your IDP server.
5 In the /etc/opt/novell/sentinel/config directory, open the osp-
configuration.properties file and modify the following property:
com.netiq.sentinel.osp.login.saml2.metadata-url=https\://<IDP_Hostname>/osp/a/
TOP/auth/saml2/metadata
Where <IDP_Hostname> is the host name for your IDP server.
6 To import the IDP server certificate to the NSS database, complete the following steps:
6a Copy the IDP server certificate to the Sentinel server.
6b Import the IDP server certificate to the Sentinel server. Use the following command:
/usr/bin/certutil -A -d sql:/etc/opt/novell/sentinel/3rdparty/nss -t
"CT,CT,CT" -n SAMLIDP -i /<location to certificate>/FileName.crt
For example:
/usr/bin/certutil -A -d sql:/etc/opt/novell/sentinel/3rdparty/nss -t
"CT,CT,CT" -n SAMLIDP -i /root/SAMLIDP.crt
7 Run the following command:
touch /etc/opt/novell/sentinel/3rdparty/jetty/contexts/osp.xml
8 (Conditional) If you are using Sentinel in High Availability (HA) mode, log in to the active node of
the HA cluster and run the following command:
csync2 -x -v
OAuth Authentication
OAuth authentication allows users to log in to Sentinel using OAuth 2.0 providers such as Google or
Facebook. This section provides instructions for configuring Sentinel to work with Google as the
OAuth provider.
NOTE: By design, OAuth authentication does not support single logout. To completely log out of a
Sentinel session when you are using OAuth authentication, you must clear your browser cache and
cookies.
NOTE: Before you continue, ensure that you have read the enablement considerations and met all
prerequisites. For more information, see “Enablement Considerations” on page 47 and “Prerequisites
for MFA, Kerberos, and OAuth” on page 63.
Authentication Methods 77
Creating Credentials for the Google Web Application
1 In your browser, go to https://console.developers.google.com/.
2 Create the credentials for a web application. For more information, click the Help button on the
toolbar to see the Google documentation.
NOTE: You must run this command separately for each of the Google certificates.
csync2 -x -v
78 Authentication Methods
3 Import the Google certificates to the Sentinel server. Use the following command for each
certificate:
/usr/bin/certutil -A -d sql:/etc/opt/novell/sentinel/3rdparty/nss -t
"CT,CT,CT" -n google -i /<location to certificate>/FileName.crt
For example:
/usr/bin/certutil -A -d sql:/etc/opt/novell/sentinel/3rdparty/nss -t
"CT,CT,CT" -n google -i /root/sai/google.crt
NOTE: You must run this command separately for each of the Google certificates.
Troubleshooting
This section helps you troubleshoot issues that might occur when using a non-default authentication
method.
The service may be disabled or an invalid request was made to an active service.
Please contact your system administrator. (An invalid OAuth2 request was received.)
Fix: You need to correct one or more settings for the current authentication method. For detailed
information, check the osp-sentinel-<date>.log file in the /var/opt/novell/sentinel/log/osp
directory.
Unrecognized interface. Invalid Host Header Name or Request URL Domain Name.
Fix: Ensure the FQDN is set properly. On the Sentinel server, update the /etc/hosts file with the
following:
Where:
Authentication Methods 79
FQDN_Sentinel_server is the FQDN of the Sentinel server.
Hostname is the host name of the Sentinel server.
For example:
NOTE: You can use the $hostname command to verify whether the host name is correct.
Fix 2: If Fix 1 does not work, ensure the Sentinel server time is synchronized with NTP, and then
restart the Sentinel server.
80 Authentication Methods
III Collecting and Routing Event Data
I
Sentinel can collect data from a wide range of event sources, such as intrusion detection systems,
firewalls, operating systems, routers, databases, switches, mainframes, antivirus applications, and
Novell applications. A modular architecture divides the task of protocol-level connections
(Connectors) and the parsing logic (Collectors) for specific event sources.
Sentinel supports a wide variety of Connectors and also includes a variety of Collectors. The
configuration required to integrate a new event source with Sentinel varies, depending on the type of
event source and the communication method selected.
You should review the Collector and Connector documentation for any new event source integration
to ensure that all available features are enabled.
The configuration required to integrate a new event source with Sentinel varies depending on the
type of event source and the communication method selected.
You can configure Sentinel to resolve hostnames to IP addresses or vice versa by editing the
configuration.properties file. These two options can be enabled independently. Both successful
and failed lookups are cached for a short period to minimize lookups to the DNS server and maximize
event throughput.
The following sections describe how you can configure the event sources to send data to Sentinel
and how you can configure new Syslog ports to receive data:
You can filter the collected data to drop any unwanted events. Messages from recognized data
sources are parsed into fields such as target IP address and source username. Messages from
unrecognized data sources are placed in a single field for storage, searching, and reporting.
The Generic Event Collector collects and processes data from unrecognized event sources that have
suitable Connectors. If the data was generated by a supported event source, the Generic Event
Collector analyzes the received data and attempts to parse the information. If the Generic Event
Collector does not understand the message, it does minimal parsing and places the text in the
Message (Msg) field.
To add or remove Syslog servers, use the Event Source Management interface. For more
information, see “Configuring Data Collection for Other Event Sources” on page 91.
Green Check Mark If the specified port is valid and is not in use, a port is valid and
open message is displayed.
Red Cross If the specified port is not valid (non-numeric or not between 1 to
65535), a port is not valid message is displayed.
Red Cross If the specified port is valid but it is already in use, or if the Syslog server
does not have permission to use it, a port is valid but not open
message is displayed.
5 Set the appropriate client authentication and server key pairs settings for the SSL Syslog server.
For more information about setting the client authentication, see “Configuring Client
Authentication for the SSL Syslog Server” on page 85.
The SSL Syslog server is automatically restarted if any changes are made here.
6 (Optional) Click Reset to restore the previous settings.
7 Click Save to save the new settings.
The Save button is disabled until you specify a valid port for all of the servers.
Open: No authentication is required. Sentinel does not request, require, or validate a certificate from
the event source.
Strict: A valid X.509 certificate is required from the event source, and it must be signed by a trusted
certificate authority. If the event source does not present a valid certificate, Sentinel does not accept
its event data.
The following procedure must be run on the computer that has the trust store on it. You can open a
web browser on the computer with the trust store or move the trust store to any computer with a web
browser.
NOTE: If the CA is signed by another CA, you must import the chain of CA certificates until the root
CA.
After the trust store is successfully imported, you can click Details to see the certificates included in
the trust store.
The following sections describe the procedure to configure the Audit Server port to receive data and
also to set the Audit Server options:
WARNING: If you select Drop oldest messages, there is no supported method to recover
dropped messages,
6 Select Idle Connection to disconnect event sources that have not sent data for a certain period
of time.
The event source connections are automatically re-created when they start sending data again.
7 Specify the number of minutes before an idle connection is disconnected.
8 (Optional) Select Event Signatures to receive a signature with the event.
To receive a signature, the Platform Agent on the event source must be configured properly. For
information on validating event signatures, see the Signing Events section in the Audit Platform
Agent Guide.
9 (Optional) Click Reset to restore the previous settings.
10 Click Save to save the new settings.
The Save button is disabled until a valid port is specified for the server.
These settings might affect data collection for several servers (for example, multiple eDirectory
instances). However, they do not start or stop services on the event source computers. Changes on
this page take effect immediately.
To view the health of the Audit Server and its event sources, see “Managing Event Sources” on
page 109.
“Port Configuration and Port Forwarding for the Audit Server” on page 89
“Client Authentication for the Audit Server” on page 89
Binding to ports lower than 1024 requires root privileges, so you should use a port higher than 1024.
You can change the source devices to send data to a higher port or use port forwarding on the
Sentinel server.
Replace protocol with tcp or udp, incoming port with the port where the messages are arriving,
and IP:rerouted port with the IP address of the local computer and an available port above 1024.
4 Save the changes.
5 Reboot the server. If you cannot reboot immediately, run the iptables command in Step 3 from
a command line.
Open: No authentication is required. Sentinel does not request, require, or validate a certificate from
the Event Source.
Loose: A valid X.509 certificate is required from the Event Source, but the certificate is not validated.
It does not need to be signed by a certificate authority.
The following procedure must be run on the machine that has the trust store on it. You can open a
web browser on the machine with the trust store or move the trust store to any machine with a web
browser.
NOTE: If the CA is signed by another CA, then you must import the chain of CA certificates until the
root CA.
After the trust store is imported successfully, you can click Details to see the certificates included in
the trust store.
NOTE: If you are using openSUSE11.1, update your JRE to the latest version. Then use the Java
Web Start (javaws) launcher command to launch the Event Source Management.
You can perform the following tasks through the Event Source Management window:
By default, the Health Monitor Display frame displays in the graphical view. The data can be
displayed in several different layouts. The default layout in graph is the Hierarchic Left to Right layout.
You can change between these layouts by selecting the layout format from the drop-down list in the
toolbar.
TIP: Click in the graphical ESM view and use the “+” or “-”sign to zoom in or zoom out, or use the
mouse wheel to zoom in and zoom out.
In the graphical view, the lines connecting the components are color-coded to indicate data flow.
Grey Line: Indicates that the connection is not live and there is no data flow.
To improve the manageability and performance of the graphical display, Sentinel automatically
collapses any node with 20 or more immediate child node. This is especially useful for Connectors
such as Syslog or Novell Audit that have the ability to automatically configure a large number of event
sources.
In collapsed state, a node displays the number of immediate child nodes, such as WMI Connector (3)
[Collector name (Number of immediate children)]. The Children panel of a collapsed node shows the
immediate children of that node, each of which can be managed in the same way as nodes in the
tabular ESM view.
NOTE: Event Source Server node do not have the plus or minus sign after their names even if they
contain child nodes.
The parent node can take several minutes to expand if it has a large enough number of child nodes to
potentially cause the user interface to become unresponsive.
Configured Status: The On state the object is configured to be in. This is the state that is stored in
the database, which does not necessarily match the actual On state of the object. For example, the
two states do not match if a parent object is turned off or if there is an error.
Actual Status: The On state of the object as reported by the actual running Collector Manager.
Connection Info (populated for Event Sources only): A text description of the event source
connection.
Sentinel The single Sentinel icon represents the main Sentinel Server that
manages all events collected by the Sentinel system.
Collector Manager The Collector Manager display name in the ESM is Sentinel
or the Sentinel Server.
Server
Each icon represents another instance of a Collector Manager
process. Multiple Collector Manager processes can be installed
throughout the enterprise. As each Collector Manager process
connects to Sentinel, the objects are automatically created in ESM.
Collector Collectors instantiate the parsing logic for data from a particular
event source. Each Collector icon in ESM refers to a deployed
Collector script as well as the runtime configuration of a set of
parameters for that Collector.
Event Source The event source represents the actual source of data for Sentinel.
Unlike other components, this is not a plug-in, but is a container for
metadata, including runtime configuration about the event source.
In some cases a single event source can represent many real
sources of event data, such as if multiple devices are writing to a
single file.
Error Indicates that an error is associated with the component. See the
individual component’s status display for details about the error.
Reporter Time is Indicates when the time of a component differs from the main
Skewed server’s time. (The difference is greater than a predefined time
threshold.)
Unknown Indicates that the status of the object in the ESM panel is not yet
known.
Right-Click Menus
The Health Monitor Display View provides a set of right-click menus that helps you execute a set of
actions, as described below:
Status Details: View all information known about the status of the selected object.
The selected object starts only after the parent nodes starts and is running.
Edit: Modifies the editable information (Filter information, Object name and so on).
Debug: Debugs the Collector. You must stop the running Collector before you debug it.
Move: Moves the selected object from its current parent object to another parent object. You can
move objects from a Live View to the scratch pad and vice versa.
Clone: Creates a new object that has its configuration information pre-populated with the settings of
the currently selected object. This allows you to quickly create a large number of similar event
sources without retyping the same information over and over again. You can clone objects from Live
View to the scratch pad and vice versa. Cloning an object copies all the settings except the Run
status. New objects created using the Clone command are always in the Stopped state after creation.
Contract: Collapses the child nodes into this node. This option is only available on parent nodes that
are currently expanded.
Expand: Expands the child nodes of this node. This option is only available on parent nodes that are
currently collapsed.
Add Connector: Opens an Add Connector Wizard that guides you through the process of adding a
Connector to the selected Collector.
Add Event Source: Opens an Add Event Source Wizard that guides you through the process of
adding an event source to the selected Connector.
Open Raw Data Tap: Lets you view the live stream of raw data from an event source or flowing
through the selected object.
Show in Tabular/Graphical View: Lets you switch between the graphical view and the tabular view
and automatically selects the object that is selected in the current view. When switching to the
graphical view, it also zooms in on the selected object.
Raw Data Filter: Filters the raw data flowing through the selected node. The raw data filter is
available on Collectors, Connectors, and event sources. If a filter specifies to drop data, the data to be
dropped is not passed to the parent node and is not converted into events.
Add Event Source Server: Adds an Event Source Server to the selected Collector Manager
Add Collector Manager: In Scratch pad mode, you can add a Collector Manager to the scratch pad
by using this option. In the Live view, Collector Manager objects are created automatically as each
Collector Manager connects to the Sentinel system.
When you select multiple objects in the ESM panel and right-click, the following options are available:
Remove selected objects: Removes the selected objects along with their children.
When you add a plug-in to Sentinel, it is placed in the plug-in repository, which enables Sentinel
components on other machines to start using the plug-in without adding the plug-in separately.
Adding a Collector
1 Access Event Source Management.
For more information, see “Accessing Event Source Management” on page 92.
2 In the main ESM display, locate the Collector Manager where the Collector will be associated.
3 Right-click the Collector Manager, then select Add Collector.
4 Follow the prompts in the Add Collector Wizard.
These prompts are unique for each Collector. For details, see the specific Collector
documentation at the Sentinel Plug-ins Web page (http://support.novell.com/products/sentinel/
secure/sentinelplugins.html).
5 Click Finish.
Adding a Connector
1 Access Event Source Management.
For more information, see “Accessing Event Source Management” on page 92.
2 In the main ESM display, locate the Collector where the new Connector will be associated
3 Right-click the Collector, then select Add Connector.
4 Follow the prompts in the Add Connector Wizard.
These prompts are unique for each Connector. For details, see the specific Connector
documentation at the Sentinel Plug-ins Web page (http://support.novell.com/products/sentinel/
secure/sentinelplugins.html).
5 Click Finish.
This Add Event Source Server Wizard can also be initiated from within the Add Connector Wizard if a
compatible Event Source Server has not yet been added.
Prerequisites
Make sure you have the following prerequisites:
Collector Script: Collector scripts can be downloaded from the Sentinel Plug-ins Web site (http://
support.novell.com/products/sentinel/secure/sentinelplugins.html) or built with the Collector Builder.
Connector: Connectors can be downloaded from the Sentinel Plug-ins Web site (http://
support.novell.com/products/sentinel/secure/sentinelplugins.html). There are also some Connectors
included in the installed Sentinel system, but there might be more recent versions on the Web site.
Documentation: Check the documentation for each Connector and Collector, because they have
different configuration steps for the event source. The documentation is located on the Sentinel Plug-
ins Web site (http://support.novell.com/products/sentinel/secure/sentinelplugins.html). Make sure you
download the documentation when you download the Connector and Collector.
Event Source Configuration: You must have configuration information for the event source.
The Collector parsing script is executed on the same system as the Collector Manager that you select
here.
Exporting Configurations
Event Source Management allows you to export the configuration of Event Source Management
objects along with the associated Collector scripts and the Connector plug-ins. You can export the
configuration at Sentinel level or at individual objects’ level such as Collector Manager, Collector and
Connector. However, exporting the configuration at Collector Manager level allows you to easily
import the configuration to individual Collector Manager.
Importing Configurations
Event Source Management allows you to import the configuration files that you export. The
configuration files contain configuration information for Event Source Management objects along with
the associated Collector scripts and Connector plug-ins.
For more information on customizing or creating new Collectors, obtain the Developer's Kit for
Sentinel at the Sentinel SDK Web site (http://www.novell.com/developer/develop_to_sentinel.html).
1. The code for all Collectors is stored in a plug-in repository on the central Sentinel server when
the Collectors are imported.
Upload/Download: Upload or download a JavaScript file here. You can download an existing
JavaScript file, edit it, and upload it again to continue debugging.
Context: Displays the variable that the debugger is pointing to and its value.
Hot Keys
When the source code window has the focus in the debugger, you can use the following hot keys:
You can also open a script file, set break-point, step through the script code, and watch variables and
methods values at each step.
Live Mode
Live debug mode requires that the Collector Manager associated with the Collector is running.
In Live debug mode, Input to the script comes from actual event sources connected to the
Collector. To get data from a specific event source, you must right-click and start the desired
event source via the Event Source Management display. Starting or stopping event sources can
be done any time during the debug session.
If no event source is started during the debug session, no data is available in the buffer for the
Collector and you see the Collector script’s readData method blocking.
In Live debug mode, output from the script is via live Sentinel Events.
When you are in Live debug mode, the script engine is executed on the local computer rather
than the actual computer that the associated Collector Manager is running on. The Connectors
and event sources still runs on the same box as the Collector Manager. When you are running
debug mode, data is automatically routed from the event sources to the script engine running in
debug on the local box.
IMPORTANT: The account running the Sentinel service on the Collector Manager machine must
have permissions to write to the file location.
Troubleshooting
If the help does not launch, there is a cache file on the local machine that is running the Event Source
Management that must be deleted.
You can refine the displayed event sources by selecting Collector Managers, Event Source Servers,
and Collector plug-ins. You can also specify a filter on the event source name and select particular
event source health states you want to view. All of these selections and filters are stored on a per-
user basis, so that each time you log into the Sentinel server you can view event sources that match
your last selections.You can also perform filtering based on tags. For more information, see
“Configuring Tags” in the Sentinel User Guide.
Collector Managers: Lists all the Collector Managers associated with the Sentinel system. It also
displays the state and details about the Collector Managers.
Event Source Servers: Lists all the Event Source Servers associated with the Sentinel system. It
also displays the state of the Event Source Servers.
Collector Plug-ins: Lists all the Collector plug-ins associated with the Sentinel system. You can also
view the details about the installed plug-ins.
The Event Sources section in the right pane lists the event sources based on the options selected
from the left pane.
Collection
Agent Manager provides host-based data collection that complements agentless data collection by
allowing you to:
Agent Manager allows you to deploy agents, manage agent configuration, and act as a collection
point for events flowing into Sentinel. For more information about Agent Manager, see the Agent
Manager documentation.
Sentinel leverages ArcSight SmartConnector to collect events from various types of event sources
not directly supported by Sentinel. SmartConnectors collect events from supported devices,
normalizes events into the Common Event Format (CEF), and forwards them to Sentinel through the
Syslog Connector. The Connector then forwards the events to Universal Common Event Format
Collector for parsing.
For more information about configuring Sentinel with SmartConnectors, see the Universal Common
Event Format Collector documentation on the Sentinel Plug-ins Website.
The Event Sources interface displays the health of the event source and the volume of data being
received from it in events per second. The event sources page lists all the event sources, such as
Syslog, Audit, File, and Database, which are configured in the Event Source Management interface.
You can refine the displayed event sources by selecting Collector Managers, Event Source Servers,
and Collector plug-ins. You can also specify a filter on the event source name and select particular
event source health states you want to view. All of these selections and filters are stored on a per-
user basis, so that each time you log into the Sentinel server you can view event sources that match
your last selections.You can also perform filtering based on tags. For more information, see
“Configuring Tags” in the Sentinel User Guide.
Collector Managers: Lists all the Collector Managers associated with the Sentinel system. It also
displays the state and details about the Collector Managers.
Event Source Servers: Lists all the Event Source Servers associated with the Sentinel system. It
also displays the state of the Event Source Servers.
Collector Plug-ins: Lists all the Collector plug-ins associated with the Sentinel system. You can also
view the details about the installed plug-ins.
The Event Sources section in the right pane lists the event sources based on the options selected
from the left pane.
NOTE: The Event Sources page shows event sources that were already configured or automatically
detected. To manually configure additional event sources, use the Event Source Management user
interface described in “Configuring Data Collection for Other Event Sources” on page 91.
NOTE: If the Store raw data option is set to No, Sentinel does not parse the data.
Create Date: Specifies the date and time when the event source was created. You can sort the
event sources based on when they were created.
EPS: Displays the events per second value received from the event source. You can sort the
event sources based on their events per second value.
If you see a value of less than one (<1) in this column, it indicates that the EPS rate is greater
than zero, but less than one.
2 To select or deselect an event source, select the check box next to the event source.
To select all the available event sources, select the check box at the top of the column.
3 To sort the event sources by Health, Name, Collector Plug-in, Drop Data, Create Date, and EPS
values, click the column header. The selected column header is displayed in bold.
NOTE: If you select multiple event sources, the settings apply to all the selected event sources.
Matching is case insensitive. The name value can contain wildcard characters. Use * to match zero or
more characters and use ? to match one character. If no wildcard characters are specified in the
name value, it is assumed that the name value is intended to mean contains <name value>, or
*<name value>*.
For example, an event source value of abc is interpreted as *abc*. Some examples of common filter
types are:
If the event source name starts with abc, enter the filter value as abc*.
If the event source name ends with abc, enter the filter value as *abc.
If the event source name contains abc, enter the filter value as abc or *abc*.
The Event Source table displays the list of event sources whose names match the value entered in
the filter input box.
The Event Source table displays the list of event sources with the selected health states.
In the Event Source section, click the Next, Previous, First, and Last arrow links to scroll through all
the event sources. The event source section displays 30 Event Sources per page.
A search is performed using the universally unique identifier (UUID) of the event source (for example,
rv24:"2CBFB8A0-F24B-102C-A498-000C").
If multiple event sources are selected for search, the rv24:<UUID> expressions are combined with
the OR operator in the search filter expression.
If none of the Collector Managers are selected, event source filtering is not performed based on the
Collector Managers. This is not the same as selecting all Collector Managers, because it also
includes event sources that are not connected to any Collector Manager.
To select or deselect Event Source Servers, select the check boxes next to the Event Source
Servers.
If none of the Event Source Servers are selected, event source filtering is not performed based on the
Event Source servers. This is not the same as selecting all Event Source Servers, because it also
includes event sources that are not connected to any Event Source Server.
To select or deselect Event Source Servers, select the check boxes next to the Event Source
Servers.
If none of the Collector plug-ins are selected, event source filtering is not performed based on the
Collector plug-in. It is essentially equivalent to selecting all of the Collector plug-ins.
You can configure event routing rules to evaluate and filter all incoming events and deliver selected
events to designated output actions. For example, each severity 5 event can be logged to a file.
You can configure event routing rules to filter events based on one or more of the searchable fields.
You can associate each event routing rule with one or more of the configured actions. You can also
assign tags to group the events logically.
Sentinel evaluates the event routing rules on a first-match basis in top-down order and applies the
first matched event routing rule to events that match the filter criteria.
NOTE: When you associate an action with routing rules, ensure that you write rules that match a
small percentage of events, if the rule triggers a Javascript action. If the rules trigger actions
frequently, the system might backlog the actions framework. This can slow down the EPS and
might affect the performance of the Sentinel system. If the rule triggers non-Javascript actions
like Sentinel Link, then there is no limitation.
For the actions to work, you must have configured the Integrator associated with each action for
your environment.
The actions listed here are different than the actions displayed in the Event Actions tab in the
Sentinel Main interface, and are distinguished by the <EventRouting> attribute in the
package.xml file created by the developer.
Adding or Removing Actions: You can add more than one action to perform on the events that
meet the filter criteria:
Click to remove the selected action for this event routing rule.
3 Click Save to save the event routing rule.
The newly created event routing rule appears at the end of the rules list under the Event Routing
Rules tab. By default, this new event routing rule is active.
The first routing rule that matches the event based on the filter is processed. For example, if an event
passes the filter for two routing rules, only the first rule is applied. The default routing rule cannot be
reordered. It always appears at the end.
Sentinel provides the ability to use mapping to inject additional information into events. This increases
Sentinel’s ability to analyze events, execute correlation rules, or provide detailed reports.
Overview
There are two major components of mapping:
Maps
A map is a collection of keys and associated values defined in a simple text CSV (comma-separated
value) file format. You can enrich your event data by using maps to add additional information such as
host and identity details to the incoming events from your source devices. This additional information
can be used for advanced correlation and reporting. The system supports several built-in maps as
well as custom user-defined maps. For more information, see “Using Maps for Event Configuration”
on page 139.
Built-in maps are stored in the database, updated via APIs in Collector code, and automatically
exported the Mapping service.
Custom maps are stored as CSV files and can be updated on the file system or via the Map Data
Configuration UI, then loaded by the Mapping service.
In both cases, the CSV files are kept on the central Sentinel server but changes to the maps are
distributed to each Collector Manager and applied locally. This distributed processing ensures that
mapping activity does not overload the main server.
Because virtually any data set can be made into a map, Event Mapping is useful for incorporating
data from elsewhere in your organization into the event stream. Some opportunities that Event
Mapping provides are:
When an Event Mapping is defined, it is applied system-wide to all events from all Collectors. Sentinel
automatically distributes map data to all processes that perform event mappings and also keeps the
map data in these processes up-to-date.
One application of Event Mapping is Sentinel's Asset Data functionality. Asset information is collected
and stored in the Sentinel database asset schema and is represented by a Physical Asset entry. Soft
assets, such as services and applications, are represented by an entry that is linked to a Physical
Asset. The primary automated update mechanism for asset data is through an asset Collector
reading data from a scanner such as Nmap. The asset Collector automates the retrieval of asset
information by reading asset data from the scanner and populating the asset schema tables with this
data. For Event Mapping, asset information is mapped from the destination IP and source IP.
10.0.0.1 Marketing0
10.0.0.2 Marketing02
10.0.0.3 ProgramMgmt03
10.0.0.4 Finance34
10.0.0.5 Finance35
You can have more than one column set as a key if you do not want the map to be a Range Map
(Range Maps can only have one key column, with that column type set to NumberRange). For
instance, with column type set to String, the AttackId tag has the DeviceName (name of the security
device) and DeviceAttackName columns set as keys and uses the NormalizedAttackID column in the
AttackNormalization map for its value. In a row where the DeviceName event ID matches the data in
Device map column and the DeviceAttackName matches the data in the AttackSignature map
column, the value for AttackId is the value in the NormalizedAttackID column. The configuration for
the Event Mapping just described is:
Figure 11-2 Event Mapping Configuration
Snort RPC TCP rwalld request 4 Sun Microsystems Solaris rwall Elevated
Snort RPC UDP rwalld request 4 Sun Microsystems Solaris rwall Elevated
Default Maps
Maps defined in this tool work together with the Referenced from Map data source setting for
individual fields. The following built-in maps are available:
Identity: Contains information about identities and the accounts associated with them. Data is
added to the Identity map through the Collector API (http://www.novell.com/developer/
develop_to_sentinel.html) and Identity Tracking Module for Sentinel. Data is then extracted to
the identityAccountMap.csv file.
Keys: User name and domain, TenantName (mapped to both Initiator and Target users).
Data added to event: User identity (an internal GUID), full name, department, workforce
ID, and email address.
Asset: Contains information about hosts in the environment. Data is added to the Asset map
using a Collector API (http://www.novell.com/developer/develop_to_sentinel.html) and
Collectors such as the Generic Asset Collector, stored in the database, and then extracted to the
asset.csv file.
Keys: IP address and TenantName (mapped to Initiator, Target, Observer, and Reporter
hosts).
Data added to event: Host identity (an internal GUID), function, class, department, and
criticality.
Country: Contains information about which physical location hosts reside in, including country,
latitude, and longitude. Data is downloaded from a commercial IP location database and added
to the IpToCountry.csv file 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/).
Keys: IP address and TenantName (mapped to Initiator, Target, and Observer hosts).
Data added to event: Country, latitude, and longitude.
Exploit: Contains information about vulnerabilities present in and attacks on enterprise hosts.
Information is added to the Exploit map by the Advisor service, stored in the database, and
extracted to the exploitDetection.csv file.
Keys: Target IP address, IDSAttackName, IDSName, and TenantName.
Data added to event: Vulnerability flag.
NOTE: For map files that have a large number of entries, the map.h2.db file in the /var/opt/
novell/sentinel/tmp directory may grow in size and would eventually stop growing. For example,
when the IP2Location feed plug-in updates the IpToCountry.csv file, the map.h2.db file may grow
up to 20 to 25 GB.
The main Mapping GUI displays a list of the maps that have been defined for the system. Default
Sentinel maps cannot be edited or deleted.
NOTE: If you specify a map name that already exists, Sentinel displays a confirmation message.
You can either specify that the existing map name can be overwritten, or provide a new map
name.
File Name: Select whether the file is local or remote, then browse to and select your map
definition.
Local File: Allows you to browse for your file on your local file system (on the machine
where Sentinel Control Center was launched).
Remote File: Allows you to select from existing map source data files on the Sentinel
server. The remote file points to /var/opt/novell/sentinel/data/map_data.
You can have more than one column set as a key if you do not want the map to be a Range Map
(Range Maps can only have one key column, with that column type set to NumberRange). For
instance, with column type set to String, the AttackId tag has the DeviceName (name of the security
device) and DeviceAttackName columns set as keys and uses the NormalizedAttackID column in the
AttackNormalization map for its value. In a row where the DeviceName event ID matches the data in
Device map column and the DeviceAttackName matches the data in the AttackSignature map
column, the value for AttackId is the value in the NormalizedAttackID column.
To create a range map, select a single column to be the key of the map and select NumberRange as
the type of the column. The format of the data in a column of type NumberRange must be “m-n”,
where m is the minimum number in the range and n is the maximum number in the range (for
example, 10-200). The maximum number in the range is not included in the range (m,n). This means
a range of 10-200 only uses numbers equal to 10 to 199. An example set of data has the first column
defined as the key column:
1-2,AA
2-4,AA
4-12,BB
10-20,BB
30-31,BB
100-200,AA
110-120,CC
When the source CSV file is loaded into the system, any common or overlapping number ranges are
collapsed into a single entry as follows:
FROM TO
1-2, AA 1-4, AA
2-4, AA 4-20, BB
4-12, BB 30-31, BB
10-20, BB 100-110, AA
30-31, BB 110-120, CC
100-200, AA 120-200, AA
110-120, CC
An example event configuration on the above map might look like this:
Figure 11-4 Event Configuration
In the scenario above, CustomerVar97 must contain a numeric value. That value is compared against
each NumberRange defined in the RangeMap until a match is found. The corresponding row from the
map is returned and used to set CustomerVar89, as follows:
For Sentinel event fields that are defined as having an IP address or Date datatype, Sentinel
internally converts those fields to an integer representation of the values of that field.
SourceIP (sip)
TargetIP (dip)
SourceTranslateIP (sxip)
TargetTranslateIP (dxip)
ObserverIP (obsip)
EventTime (dt)
ObserverEventTime (det)
SentinelProcessTime (spt)
BeginTime (bngt)
EndTime (endt)
CustomerVar11 to CustomerVar20 (cv11 to cv20)
ReservedVar11 to ReservedVar20 (rv11 to rv20)
IP address ranges are automatically converted into decimal integer ranges. The following example
shows a numerical range equivalent to an IP range of 10.0.0.0 to 10.0.2.255.
167772160-167772415,AAA
167772416-167772671,BBB
167772672-167772927,CCC
In Key Configuration, the Event ID used for comparison is set to TargetIP for the range Map Key
field.
The Map column returned from the map to set CustomerVar89 is defined as a value, as
displayed in the second column below.
If an event contains a target IP of 10.0.1.14 (equivalent to numerical value of 167772430), the output
for column CustomerVar89 within the event is BBB.
Dates are represented as an integer number of seconds since midnight January 1, 1970. Data and
time ranges can be used in maps in a similar fashion as the IP address sample above.
NOTE: In all cases, the min must be less than or equal to the max (for example, “-234- -235” is NOT
valid).
Map updates can be performed on demand from the Sentinel Control Center. To set up an automated
process to update map data, you can run an equivalent process from the command line using
map_updater.sh.
There are two map locations: the location referenced by the Event Map Configuration (which is a
user-defined location) and the location where Sentinel stores its internal representation of the map (/
var/opt/novell/sentinel/data/map_data). The internal representation of the map should never
be manually updated.
1 If you haven’t already done so, create a CSV file containing the new map source data.
This file can be generated (for example, from a data dump script), created manually, or be an
edited version of the existing map data source file. If necessary, you can obtain the existing map
data source file from /var/opt/novell/sentinel/data/map_data.
2 Access a map definition.
For more information, see “Accessing Map Definitions” on page 133.
3 Expand the folder of interest and select the mapping, then click Update.
4 Select the new map data source file by clicking Browse and selecting the file with the new map
data.
After you select the file, the data from the new map data source file displays under the New tab.
The map data you are replacing is under the Current tab.
5 Deselect or leave the default setting for Backup Existing Data On Server.
Enabling this option puts a backup of the existing map data source file in the /var/opt/novell/
sentinel/data/map_data folder. The prefix of the name of the backup map data source file is
the name of the existing map data source file. The end of the filename includes a set of random
numbers followed by the .bak suffix. For example: vuln_attacks10197.bak.
6 Click OK.
The data from the new map data source file is uploaded to the server, replacing the contents of
the existing map data source file. After the source data is completely uploaded, the map data is
regenerated and distributed to map clients such as, Collector Manager.
6 The data from the new map data source file is uploaded to the server, replacing the contents of
the existing map data source file. After the source data is completely uploaded, the map data is
regenerated and distributed to map clients (for example, Collector Manager).
Unless the optional -nobackup argument is added, the previous map data is saved in a backup file on
the server. Enabling this option results in a backup of the existing map data source file being put in
the <install_directory>/data/map_data folder. The prefix of the name of the backup map data
source file is the name of the existing map data source file. The end of the filename contains a set of
random numbers followed by the .bak suffix. For example: vuln_attacks10197.bak.
Renaming event fields does not change the event ID in Collector scripts or in internal Sentinel
representations of the event. For example, if you rename the event name BeginTime to StartTime, the
ID will still remain as bgnt. Any references to this ID in Correlation or Filters still work, even if they
were originally written using bgnt.
Sentinel Link is a mechanism that provides the ability to hierarchically link multiple Sentinel systems,
including Sentinel Log Manager, Sentinel, and Sentinel Rapid Deployment. You can hierarchically link
two or more Sentinel systems to forward filtered events from one Sentinel system to another for
further evaluation.
Benefits
Multiple Sentinel servers, local or distributed, can be linked in a hierarchical manner. In this
setup, Sentinel servers can manage a large volume of data, retaining raw data and event data
locally, while forwarding important events to a central Sentinel server for consolidation.
One or more Sentinel servers can forward important data to either a Sentinel server, Sentinel
Log Manager server, or a Sentinel Rapid Deployment server. These systems provide real-time
visualization of data, advanced correlation and actions, workflow management, and integration
with identity management systems.
Multiple Sentinel, Sentinel Log Manager, or Sentinel Rapid Deployment servers can be
hierarchically linked to monitor the consolidated event information.
One or more Sentinel, Sentinel Log Manager, or Sentinel Rapid Deployment servers can forward
important events to a Sentinel server for event consolidation.
Prerequisite
Before you forward events from the sender machine, ensure that the Sentinel Link server is up and
running on the receiver machine.
To configure a Sentinel link, you need to configure at least two systems: the sender machine and the
receiver machine. For further details on configuring Sentinel Link, see the Sentinel Link Overview
Guide (http://www.novell.com/documentation/sentinel70/sentinel_link_overview/data/bookinfo.html).
Sentinel receives two separate but similar data streams from the Collector Managers: raw data and
event data.
Raw Data
Raw data files are unprocessed events received by the Connector and sent directly to the Sentinel
message bus.This data is written to the Sentinel server. Sentinel receives all raw data without being
filtered. When the event is sent to the message bus, the following additional information is also sent
without altering the original event:
Because the raw data is not searched or used to generate reports, the data is not indexed.
Event Data
Event data is created as a result of a Collector parsing and normalizing raw data.
You can set filtering rules on the event source, Connector, and Collector, which selectively prevent
the Collector from parsing raw data. Filtering rules avoid the overhead of parsing and normalizing
data you do not need for further processing or analysis, and free up hardware resources for more
important tasks. These rules do not affect the storage of the raw data. However, event data can be
dropped after it is created by the parsing and normalization logic of the Collector by configuring an
event routing rule to selectively drop the event data. This is useful when it is more convenient to
define the rule on normalized data rather than non-normalized (raw) data. For more information, see
Chapter 10, “Configuring Event Routing Rules,” on page 125.
This section provides information about how you must configure your data storage to collect and
store raw data and event data.
Sentinel stores raw data and compressed event data on the primary location. You can configure
Sentinel to store the data in a secondary location for long-term storage.
The data files are deleted from the primary and secondary storage locations on a configured
schedule. Raw data retention is governed by a single raw data retention policy. Data retention is
governed by a set of event data retention policies. All of these policies are configured by the Sentinel
administrator.
Sentinel stores the raw data files in one of the following locations:
The compressed raw data files are moved from the primary storage to the secondary storage
location.
The following table describes the directory structure of the raw data in the primary storage under the
installation directory:
/data/rawdata/online The directory where all the raw data in the primary storage is stored.
/data/rawdata/online/ There is one subdirectory for each event source under the online subdirectory.
EventSource UUID That subdirectory contains all raw data received from that event source.
The subdirectory name is the universally unique identifier (UUID) of the event
source (for example, E20D0840-1E0A-102C-9F30-000C2949BA91).
/data/rawdata/online/ Data in the event source subdirectory is partitioned by month. Each month has its
EventSource UUID/Month own subdirectory.
The subdirectory name is in the yyyy-mm format. For example, 2009-05 indicates
May 2009.
/data/rawdata/online/ Each file in the Month directory contains data received during a specific one-hour
EventSource UUID/ period. Most data in the file has a time stamp that is within the one-hour period.
Month/1 Hour Data
Files The name of the file indicates the day of the month and the one-hour period that
is represented.
NOTE: Raw data files are compressed and have the extension .gz. However,
when the raw data file is being written into, the raw data file appears with the
extension.open.
For example:
If the raw data files are stored in the primary storage location, the full path name of the file is in the
following format:
For example:
/var/opt/novell/sentinel/data/rawdata/online/A75CF6A0-4948-102D-A615-000C29A9C3DB/
2010-05/24-0600.gz
If the raw data files are stored in the secondary storage location, the full path name would be as
follows:
For example:
/sentinel_archive_data/rawdata_archive/A75CF6A0-4948-102D-A615-000C29A9C3DB/2010-
05/24-0600.gz
{
"EventDate": "<date>",
"EventRecordID:" "<event record uuid>",
"RawData": "<raw data>",
"RawDataHash": "<SHA256 hash of raw data, in hex format>",
"EventSourceManagerID", "<uuid of event source manager>",
"CollectorID", "<uuid of collector>",
"EventSourceID:", "<uuid of event source>",
"ChainID", "<chain ID>",
"ChainSequence", "<Sequence number>"
}
The following table describes each of the fields in the raw data event:
EventDate The date and time when Sentinel received this event and not the date and time
when the event occurred.
Example: "595829C0-1C8F-102C-A922-000C2949BA91"
If an event was generated as a result of parsing a raw data record, this ID is set in
the event RecordID field. Because of filtering, not all raw data records result in an
event.
RawDataHash The SHA-256 hash of the RawData value represented as a HEX string. The hash
is calculated by converting the RawData value to a UTF-8 string and then
performing the hash over that string.
To detect tampering, each raw data event is stored with a SHA-256 hash value.
Example:
cc661009e2f3dc565c0c7fe25b705219004dcd8132c0b0a7e987bfdcb55e49cf
EventSourceID The UUID of the event source from which the raw data originated.
Example: A2A0C600-1C6C-102C-A781-000C2949BA91
EventSourceGroupID The UUID of the event source group (Connector) to which the event source was
connected when the raw data was received.
Example: A2A0C600-1C6C-102C-A77A-000C2949BA91
Different raw events from the same event source can have different event source
group IDs, because event sources can be moved from one Connector to another.
CollectorID The UUID of the Collector that the Connector and event source were connected to
when the raw data was received.
Different raw events from the same event source can have different Collector IDs,
because event sources and event source groups can be moved from one
Collector to another.
Example: A2A0C600-1C6C-102C-A779-000C2949BA91
EventSourceManagerID The UUID of the Event Source Manager (Collector Manager) object where this
raw data was received.
Example: C76D2820-C395-1029-BB86-001321B5C0B3
ChainID A random number that identifies a raw data chain. Whenever an event source is
stopped and restarted between generation of raw data events, a new ChainID
number is generated.
To detect tampering, each raw data event is stored with a ChainID and a
ChainSequence number.
Example: 1241630654754
The raw data events in a given raw data chain must have an uninterrupted
sequence of numbers starting with 0. In addition, all raw data events in a given raw
data chain must appear sequentially in the files, with no other chains intermixed. If
a raw data chain can span files, the sequence should continue uninterrupted into
the file that represents every hour during which raw data was received.
Example: 4
If no raw data is received for the one-hour period, the file records only from the
next arrival of raw data. Nonetheless, the raw data chain sequence should
continue uninterrupted until a new raw data chain begins. A new raw data chain is
signaled by a changed ChainID value, and a ChainSequence value of zero (0).
{
"EventDate":"05\/24\/2010 06:15:06.676",
"EventRecordID":"A75CF6A0-4948-102D-A61C-000C29A9C3DB",
"RawData":"Sep 22 10:22:00 testhost Message #100",
"RawDataHash":"7003c0e0be4ddf43a3b49026a37483f59c7f839950f581ec9fde5dea43da90f5",
"EventSourceManagerID":"C76D2820-C395-1029-BB86-001321B5C0B3",
"CollectorID":"A75CF6A0-4948-102D-A613-000C29A9C3DB",
"EventSourceGroupID":"A75CF6A0-4948-102D-A614-000C29A9C3DB",
"EventSourceID":"A75CF6A0-4948-102D-A615-000C29A9C3DB",
"ChainID":"1274696106664",
"ChainSequence":"0"
}
{
"EventDate":"05\/24\/2010 06:15:07.358",
"EventRecordID":"A75CF6A0-4948-102D-A624-000C29A9C3DB",
"RawData":"Sep 22 10:22:00 testhost Message #99",
"RawDataHash":"f5681ba965144d2d22b13188767d94540b5fe57904afcee5821854bde2afca72",
"EventSourceManagerID":"C76D2820-C395-1029-BB86-001321B5C0B3",
"CollectorID":"A75CF6A0-4948-102D-A613-000C29A9C3DB",
"EventSourceGroupID":"A75CF6A0-4948-102D-A614-000C29A9C3DB",
Event Data
Sentinel closes the event data partitions after one day, and no more events are written to the closed
partitions. Even though the duration for event data partitions is one day, a grace period of 10 minutes
is given to accommodate events arriving late. You can change the grace period as necessary. For
more information, see “Setting the Grace Period to Close Event Data Partitions” on page 299.
By default, after the partitions are closed, Sentinel copies a compressed copy of the partition to
secondary storage, but also retains the uncompressed copy on primary storage as a fast-access
cache for searching. When the primary storage reaches its maximum disk usage, Sentinel deletes the
copy in the primary storage and the copy in the secondary storage remains online for searching.
NOTE: However, if disk space in primary storage is at a premium, you can compress these partitions
as soon as they are closed to save the disk space on the primary storage. This requires additional I/O
to compress and store on the primary partition, which means that the supported EPS rate will be
significantly lower. Also, searches on these partitions will be slower. Therefore, this option is only
suitable for lower EPS rates and if you want to get the most out of primary storage space. For
information about compressing the storage index on primary partitions, see “Compressing the
Storage Index on Primary Partition” on page 299.
Open partitions: The partitions that new data is being written to.
Secondary storage: Most recent N days of closed partitions + The rest of the online data
The rest of the online data: The older closed partitions that primary storage no longer has
room to hold. This data is online (searchable), just like the data in primary storage.
NOTE: Because of the above design consideration, the secondary storage size must be always
larger than the primary storage size.
A central partition index is maintained in the database that keeps track of all the existing partitions
and their location.
The following table describes the directory structure under the installation directory where event data
is stored:
/data/eventdata/ A partition consists of the events for a single day (midnight-midnight UTC) within
events/ a given data retention class and is held within a subdirectory named
YYYYMMDD_<classid> YYYYMMDD_<class-id>.
/data/eventdata/ events.evt contains the binary event data for the partition. The format of the
events/ binary event data is stored as a Reliable Persistent Random Access
YYYYMMDD_<class_id>/ Compressed Stream.
events.evt
/data/eventdata/ The index directory contains the Lucene index for the partition.
events/
YYYYMMDD_<class_id>/
index
/data/eventdata/ This directory contains the event associations data. It includes both the
exported_associations correlated event association data and the incident event association data.
SAN: The Storage Area Network (SAN) option includes storage that is attached directly to the
Sentinel computer. This option provides the best combination of performance, security, and
reliability.
CIFS: The Common Internet File System (CIFS) is a native Windows protocol. It is also known
as the Server Message Block (SMB) protocol in later implementations. The latest
implementation from Microsoft is referred to as SMB 2.
NFS: The NFS protocol requires significant configuration to optimize performance and security,
and it is recommended only if you already have a well-established NFS infrastructure in your
environment.
If the secondary storage is an NFS server, additional configuration is necessary to ensure that
the Sentinel server has the necessary permissions. For more information, see “Exporting the
Secondary Storage Volume” on page 153.
WARNING: Only one Sentinel server should be configured to use a particular secondary storage
directory (remote share). Configuring the same secondary storage location across multiple Sentinel
servers might cause system failure.
The primary storage must use a different partition than the partition that is used for the secondary
storage.
The system monitors the disk usage of both primary storage and secondary storage, freeing
space on primary storage when it fills up. If both storage locations share the same underlying file
system partition, the way in which the partition usage changes as a result of deleting data
confuses the system and could result in undesirable behavior.
The event data is first copied to secondary storage rather than moved, because there is an
assumption that these are two different disk partitions. If they are in same disk partition instead of
being on the different disk partition, the storage usage monitoring is confused by how the usage
is changing and could result in undesirable behavior.
If secondary storage is configured and enabled, Sentinel copies the compressed raw data files to the
configured secondary storage location every 15 minutes.
For CIFS/SMB and NFS, if multiple Sentinel instances are moving the closed partitions to the same
secondary storage location, ensure that each Sentinel instance has its own unique directory on that
secondary storage location.
1 Identify a volume on the NFS server with sufficient space to hold the Sentinel secondary storage
data.
2 Create a new directory on that volume to store the Sentinel data. For example, /sentinel-
secondary.
3 Create a novell user and novell group on the NFS server with the same user ID and group ID as
the corresponding user/group on the Sentinel server. For example, user ID 1000 and group ID
1000. If this is not possible, see “Squashing User IDs” on page 154.
4 Change the directory ownership to be owned by novell user and novell group:
The following table describes an example of exporting the /sentinel-secondary directory from the
nfs-server to the sentinel-server.
An alternate solution involves mapping all source user IDs to an anonymous user ID specified by the
NFS server. For example, any user ID that attempts to access the NFS export. This reduces security
allowing any user to read or write the Sentinel data on the export (subject to the IP-based access
permissions of the export). This is called squashing. In most cases, the root user is re-mapped and
most other users are not. In this case, you need to re-map the novell user and all other users.
If the user ID 1000 is in use on the NFS server, this may not work. In that case use
sec=none.
If the user ID 1000 is in use on the NFS server, the above may not work.
The above command mounts the export on the /mnt directory. You can see the mount in the list by re-
issuing the mount command without options. You may not be able to perform any file actions using
the root user instead use the novell user (su novell) to perform the file operations. Use umount /mnt
command before you attempt to set up the secondary storage within Sentinel.
For more information about NFS security recommendations, see Chapter 3, “Security
Considerations,” on page 21.
Sentinel moves the raw data to the secondary storage location after approximately one hour.
NOTE: This field is displayed only if you have enabled secondary storage.
3 (Conditional) If you have enabled secondary storage, specify the secondary storage utilization
value in the Use __% of total secondary storage size field. This is the threshold at which
Sentinel stops using the secondary storage disk space.
Overview
Sentinel can store the data in an external database by synchronizing a subset of the data that
Sentinel gathers.
1. Sentinel gathers the events from the Event Sources through the Connectors.
2. Sentinel uses Collectors to normalize the event data.
3. The normalized event data is then sent to the Sentinel message bus.
4. The event data is then stored and indexed in the file system in the primary storage.
5. The data synchronization policies allow events in the primary storage to be copied and stored in
PostgreSQL and external SQL databases.
a. User-defined data synchronization policies synchronize the filtered event data to an external
SQL database. For information about the certified databases, see the Sentinel Technical
Info Website.
b. Report Data Definitions (RDD) generate system data synchronization policies that are used
to copy event data into tables in the internal PostgreSQL database. These data
synchronization policies cannot be edited or deleted. Reports that rely on an RDD will
search internal database tables for events instead of the primary storage. These kinds of
reports search internal tables instead of the event store because they utilize more complex
SQL SELECT statements that need to join event data to the data in other tables in the
internal database.
Event Sources
Collecting and
Normalizing Data
3 Message Bus
4
File System
(Lucene)
Primary Storage
5a 5b
Data Synchronization
Policies
MSSQL
Or Oracle Database
Sentinel allows you to partition tables if they are in the internal PostgreSQL database. When you
choose to partition a table in the internal PostgreSQL database, a new table partition is created for
each days worth of data.
Partitions are only used with RDD data sync policies. Partitioning has advantages and
disadvantages:
Disadvantages
Reports that do not query on event time might be slower where there are multiple of partitions,
because every partition must be searched.
Each partition causes one or more schema items to be created and managed by the database
system. If there is no retention period, the number of partitions just keeps growing.
jsse.enableCBCProtection=false
<JDBCProperties>
</JDBCProperties>
<JDBCProperties>
</JDBCProperties>
<JDBCProperties>
</JDBCProperties>
NOTE: The above update is applicable only if you are upgrading previous versions of Sentinel to
8.x.
4 Browse to a select an existing table you want to use, then click OK.
5 (Optional) Select the Summarize Events option if you want a summary of events during a
specific period.
6 (Optional) If you selected Summarize Events, specify the amount of time in minutes to
summarize events.
7 Change the field mappings for the desired fields.
8 Click Save.
NOTE: If you set the value of this property to zero, the RDD table entries are never deleted.
Event Views use data synchronization policies to display data dynamically and more accurately. Data
synchronization policies related to Event Views remain enabled and active while being used by an
Event View. If there are no data requests from an Event View for a given data synchronization policy
within a specified time period, the data synchronization policy will be automatically deleted.
To specify the time period for which an Event View related data synchronization policy should
remain active:
The Health page of Sentinel also displays the current storage capacity and also forecasts the storage
capacity for both primary and secondary storage.
WARNING: When the system is running out of primary disk storage space, a warning message is
displayed and a system audit event is logged. To avoid data loss, you must increase the primary
storage space.
You can search the raw data by using tools such as egrep or a text editor, but this search might not be
sufficient for your requirements. The search mechanism provided by Sentinel on event data is more
powerful than these tools.
The high-level approach to configure Sentinel is to retain data for a longer duration so you can
perform searches and run reports on the data you regularly need to access, and to copy the data to
tape before Sentinel deletes it. To search or run reports on data that was copied to tape, but deleted
from Sentinel, copy the data from the tape back to Sentinel.
If you want to perform searches or reports on the data, copy both the raw data and the event data to
tape so that you can copy both sets of data back into Sentinel when the data is needed. If you want to
store data only to comply with legal requirements, copy only the raw data to the tape.
Configuration Data: This option includes non-event or raw data backup. It is faster because it
contains small amount of data, including all the installation directories except the data directory.
Data: This option backs up all the data in the primary storage and secondary storage directories. This
option takes a longer time to finish.
Periodically export all the Event Source Management configurations and save them. When the
environment is relatively stable, you can generate a full Event Source Management export
including the entire tree of the Event Source Management components. This action captures the
plug-ins and the configuration of each node. You must back up the resulting .zip file and move
it to secondary storage.
If changes such as updating plug-ins or adding nodes are made to Event Source Management
later, you must export the configuration and save it again.
Back up the entire installation directory so there is no risk of manual mistakes and the process is
quicker.
You must configure data retention policies so that the data that you want to search and report is
retained within the Sentinel server until you no longer need it. Additionally, a data retention policy
should ensure that Sentinel is not prematurely deleting the data because of storage utilization limits. If
the storage utilization limit is exceeded and you notice that the data is being prematurely deleted,
change the data retention policy to expand the data storage space.
The directory hierarchy in which the raw data files are placed is organized by the event source and
the date of the raw data. You can use this hierarchy to periodically copy a batch of raw data files to
tape. For more information on raw data directory hierarchy, see Table 13-1, “Raw Data Directory
Structure,” on page 145.
You cannot copy files that are in the process of being compressed. You must wait until the raw data
files are compressed and moved to secondary storage before copying them to tape.The presence of
a .log file with the same name as the zip file indicates that the file is still in the process of being
compressed.You must also ensure that the raw data files are copied to the tape before the interval
configured in the Raw Data Retention policy expires so that the data is not lost.
For more information about the event data directory hierarchy, see Table 13-3, “Event Data Directory
Structure,” on page 150.
You should wait until event data partitions have been copied to secondary storage before copying
them to tape. Before you copy, ensure that the directory is not currently being copied from primary
storage. To do this, see if there is a primary storage directory partition of the same name. If the
corresponding primary storage directory partition is not present, the secondary storage directory
partition is not being copied. If the corresponding primary storage directory partition is still present,
sure that all of the files in the primary storage directory partition are also in the secondary storage
directory partition and that they are all of the same size. If they are all present and of the same size, it
is highly likely that they are not currently being copied.
Restoring Data
The event data restoration feature enables you to restore old or deleted event data. You can also
restore the data from other systems. You can select and restore the event partitions in the Sentinel
Main interface. You can also control when these restored event partitions expire.
NOTE: The Data Restoration feature is a licensed feature. This feature is not available with the free
or trial licenses. For more information, see “Understanding License Information” in the Sentinel
Installation and Configuration Guide.
For primary storage, you can copy the event data directories to /var/opt/novell/sentinel/
data/eventdata/events/.
For secondary storage, you can copy the event data directories to /var/opt/novell/
sentinel/data/archive_remote/<sentinel_server_UUID>/eventdata_archive.
To determine the Sentinel server UUID, perform a search in the Web interface, in the Search
results, click All for any local event. The value of the SentinelID attribute is the UUID of your
Sentinel server.
Restoring Event Data Where UID and GID are not the Same on the Source and
the Destination Server
There may be a scenario where the secondary storage data if the novell user ID (UID) and the group
ID (GID) are not the same on both the source (server that has the secondary storage data) and
destination (server where the secondary storage data is being restored). In such a scenario, you
need to unsquash and squash the squash file system.
1 Copy the partition that you want to restore on the Sentinel server where you want to restore the
data at the following location:
/var/opt/novell/sentinel/data/archive_remote/<sentinel_server_UUID>/
eventdata_archive/<partition_ID>
unsquashfs index.sqfs
rm -r index.sqfs
su novell
9 Restore the partitions. For more information, see “Restoring Event Data.”
The restored partitions that are set to expire are removed from the Restored Data table and returned
to normal processing.
It might take about 30 seconds for the Restored Data table to reflect the changes.
When you enable scalable storage, the Sentinel server user interface is trimmed down to just cater to
scalable data collection, event routing, events dashboard, and other administrator activities. This
trimmed down version of Sentinel is referred to as Sentinel Scalable Data Manager (SSDM).
1 Complete the prerequisites to enable scalable storage. For information about prerequisites, see
“Installing and Setting Up Scalable Storage” in the Sentinel Installation and Configuration Guide.
2 From Sentinel Main, click Storage > Scalable Storage.
3 Select Configure scalable storage.
4 Specify the IP addresses or hostnames and port numbers of the scalable storage components.
5 (Conditional) To customize the default configuration of CDH components, click Show advanced
configuration.
If the properties you want to modify are not listed in the user interface, click Add property and
set the value.
Customizing Kafka Configuration
You can customize the following properties in the Sentinel web interface only when you enable
scalable storage for the first time. If you want to modify these properties after scalable storage is
enabled, you must use appropriate Kafka tools as mentioned in Kafka documentation. For more
information, see Apache Kafka documentation.
For information about how to set these values, refer to the Cloudera documentation.
Kafka Data retention hours Configure the retention days based on the disk space available on
the Kafka node, EPS rate, and the number of days needed to
log.retention.ho recover the system from a scalable storage outage if one were to
urs occur. Kafka will retain the data while the scalable storage system is
recovered, preventing data loss.
HDFS HDFS block size Increase the block size to 256 MB to reduce the disk seek time
among data nodes and to reduce the load on NameNodes.
dfs.block.size
Replication factor Set the value to 3 so that it creates three copies (1 primary and 2
replicas) of files on data nodes.
dfs.replication
More than 3 copies of files require additional disks on data nodes
and reduce the disk I/O latency. The number of data disks required
is usually multiplied with the number of replicas.
dfs.datanode.max
.xcievers,dfs.da
tanode.max.trans
fer.threads
HBase HBase Client Write Set this value to 8 MB to increase the write performance of HBase
Buffer for a higher EPS load.
hbase.client.wri
te.buffer
hbase.regionserv
er.global.memsto
re.upperLimit
hbase.regionserv
er.global.memsto
re.size
hfile.block.cach
e.size
hbase.hregion.me
mstore.flush.siz
e
hbase.hstore.com
pactionThreshold
RegionServer in
Bytes
yarn.scheduler.m
aximum-
allocation-
vcores
Container Memory Spark runs 3 applications: event data, raw data, and event indexer.
Maximum Ensure that each AM container has sufficient memory to run these
applications.
yarn.scheduler.m
aximum- For example, if YARN ResourceManager has 24 GB, allocate a
allocation-mb maximum of 8 GB memory per AM container.
spark.history.fs
.cleaner.enabled
spark.history.fs
.cleaner.interva
l
spark.history.fs
.cleaner.maxAge
Disk Latency Whenever the disk latency goes beyond 100 ms on a data node,
add more JBOD disks to the data node and configure the
component causing the highest I/O load to utilize the directories
where additional disks are mounted.
To avoid data loss and to optimize performance, SSDM automatically configures certain scalable
storage components’ settings described in the following table. For more information about these
advanced properties and the guidelines to consider when configuring these properties, see the
documentation for the specific component.
IMPORTANT: You can add new properties or modify the existing properties as required. You must
specify these settings at your own discretion and validate them because the changes are applied as
is.
Processing Data
Data processing includes streaming of event data and raw data to HBase tables and indexing data
into Elasticsearch.
1 Log in to the SSDM server as the novell user and copy the files to the Spark history server
where HDFS NameNode is installed:
cd /etc/opt/novell/sentinel/scalablestore
scp SparkApp-*.jar avroevent-*.avsc avrorawdata-*.avsc spark.properties
log4j.properties manage_spark_jobs.sh root@<hdfs_node>:<destination_directory>
where <destination_directory> is any directory where you want to place the copied files. Also,
ensure that the hdfs user has full permissions to this directory.
2 Log in to the <hdfs_node> server as the root user and change the ownership of the copied files
to hdfs user:
cd <destination_directory>
chown hdfs SparkApp-*.jar avroevent-*.avsc avrorawdata-*.avsc spark.properties
log4j.properties manage_spark_jobs.sh
Assign executable permission to the manage_spark_jobs.sh script.
3 (Conditional) To restart data processing, stop the currently running Spark jobs by running the
following script:
./manage_spark_jobs.sh stop
4 Run the following script to start data processing:
./manage_spark_jobs.sh start
The above command takes a while to complete the data processing.
5 (Optional) Run the following command to verify the data processing status:
./manage_spark_jobs.sh status
To configure data collection and event routing rules, see Part III, “Collecting and Routing Event Data,”
on page 81.
To search and visualize events, see the following chapters in the Sentinel User Guide:
To extract raw data or event data, you can run the rest_client.sh script and specify the RecordID
of raw data or EventID of the event respectively along with the time range during which the event
occurred. The time range must be in yyMMddHHmmss format. To determine the RecordID of the raw
data, you must first extract the event data and note down the RecordID (rv25 value) of the event.
1 Log in to the Spark history server and change to the directory where you stored the Spark job
related files when submitting Spark jobs.
2 Delete the existing index file to consider any updates to event fields that need to be indexed:
curl -XDELETE 'http://<elasticsearch_ipaddress:elasticsearch_port>/
security.events.normalized_*/'
3 Run the following command:
sudo -u hdfs spark-submit --master yarn --files
spark.properties,log4j.properties --deploy-mode client --class
com.novell.sentinel.spark.scanner.HbaseScanner SparkApp-<latest_file>.jar -
confFile=spark.properties -table=<hbase_table_name> -from=<yyddmmhhmmss> -
to=<yyddmmhhmmss> -interval=<seconds> -
outputhandler=com.novell.sentinel.spark.scanner.EventIndexRDDHandler
1 In Sentinel Main, click Storage > Scalable Storage > Advanced Configuration > Kafka.
2 (Conditional) Before you upgrade the scalable storage component, pause event forwarding by
adding the following property and set it to true:
pause.events.tokafka
3 (Conditional) After you upgrade the scalable storage component, resume event forwarding by
setting the following property to false:
pause.events.tokafka
4 Click Save.
Troubleshooting
“Sentinel Operations Do Not Complete Successfully When Any of the CDH Components Are Not
Running” on page 178
“Event Visualization Interface May Not Launch Due to Time-Out Error” on page 178
Fix: Restart Sentinel once the CDH components are up and running.
The data retention policies control when data should be deleted from the system. A retention policy
contains a filter that is used to identify the events for which the retention policy applies and the
minimum and maximum number of days these events should be kept in the system.
You can configure one or more data retention policies to control the duration for which specific types
of events are retained in Sentinel. Except for the Raw Data Retention policy, all of the configured
policies apply to the event data.
The configured retention policies are displayed in the data retention policy table. By default, the data
retention policy table is refreshed every 30 seconds to reflect the changes made by multiple
administrators.
NOTE: For traditional storage, data retention policies are applied in addition to the configured disk
space usage parameters, as described in “Configuring Disk Space Usage” on page 156. These
policies are a logical overlay, whereas the disk space usage configuration is related to the physical
memory space usage.
To determine which data retention policy will apply to an event and, therefore, how long an event will
be retained before deleting it from the data storage, apply the following rules:
1. If an event meets the criteria of only one data retention policy filter, that data retention policy is
applied to the event.
2. If an event does not meet the criteria for any of the data retention policies, the default data
retention policy is applied to that event.
3. If an event meets the criteria for more than one of the data retention policies, the following
guidelines are used to determine which data retention policy should be applied:
If the maximum retention period of a policy is shorter than the others, that policy is applied.
(If the maximum retention period is not specified for a policy, the policy is considered to
have a long maximum retention period.)
If multiple matching policies have the same shortest maximum retention period, the policy
with the longest minimum retention period is applied.
If multiple matching policies have the same shortest maximum retention period and the
same longest minimum retention period, the system arbitrarily applies one of the policies.
The process to delete raw data files runs every time the server is started, every hour because that is
when the raw data files are closed, and whenever the Keep at most value is changed. All the files
exceeding the retention time are removed permanently from the data storage.
NOTE: For scalable storage, if you specify both Keep at least and Keep at most values, Sentinel
considers only the Keep at most value for data retention.
Sentinel ensures that partitions that contain this kind of data will never be retained for longer than
this value (assuming Sentinel is running and has access) for privacy or compliance reasons.
If no value is specified, Sentinel retains events of this type until the disk space usage policies
remove them.
4 Click Save. The newly created policy is displayed in the data retention table.
The table also contains the following additional columns:
However, you can change this retention period by performing the following steps:
1. All partitions (both primary storage and secondary storage) are deleted as soon as the Keep at
most time limit of their retention policy is reached.
2. Partitions that are successfully moved to secondary storage. The oldest partition is deleted first
until none are left or until the desired amount of space is available.
3. Partitions that are not yet moved to secondary storage, but have reached their retention policy's
Keep at most time limit. The partitions that are close to the Keep at most limit are deleted first,
until none are left or until the desired amount of space is available.
If at least half of the desired space is not yet free, partitions are deleted early, on the assumption
that incoming data is more important than old data.
4. Partitions that are not yet moved to secondary storage that have reached their retention policy's
Keep at most time limit. The partitions that are close to the Keep at most limit are moved first,
until none are left or at least half of the desired amount of space is available, but the current UTC
day partitions are not deleted.
Sentinel does not delete data based on the disk usage. You must manually monitor the disk usage in
the CDH UI and take appropriate measures to avoid data deletion.
This section provides information about integrating Sentinel with external systems.
An Action is a configured instance of an Action plug-in. Actions are used to execute some type of
action in Sentinel, either manually or automatically. Actions can be triggered by routing rules, by
manually executing an event or incident operation, and by correlation rules.
Overview
Sentinel provides a list of pre-configured Actions that should be useful in most standard situations.
You can use the default Actions and reconfigure them as necessary, or you can add new Actions.
NOTE: Only users in the administrator role can configure and manage Actions.
An Action can be executed on its own, or it can make use of an Integrator instance configured from an
Integrator plug-in. Integrators provide the ability to connect to an external system, such as an LDAP,
SMTP, or SOAP server, to execute an action.
The general process for using an Action to perform remediation is shown in the following figure:
Figure 16-1 Actions Workflow
Execute actions
manually
1 2 3
Select the desired Configure the Configure the
Action Action Integrator
Associate actions
with rules
1. Determine the best type of Action plug-in that should be used to perform your desired action.
2. Configure the appropriate Action plug-in with appropriate parameter settings for your
environment.
For more information, see “Adding an Action” on page 190.
3. If the Action requires an Integrator, configure the appropriate Integrator.
The Action Manager window lists the pre-configured actions. You can configure these Actions further
as necessary.
Actions: To configure an Action, select the desired action, then click View/Edit.
Add: Allows you to add an action. For more information, see “Adding an Action” on page 190.
Manage Plug-ins: Allows you to import new and updated action plug-ins, and manage the
action plug-ins. For more information, see “Managing Action Plug-Ins” on page 191.
Managing Actions
An Action is a configured instance of an Action plug-in.There can be one or more instances of an
Action plug-in with different parameters or settings. A few Actions are available by default. You can
also add additional actions as required.
Each individual Action plug-in defines where it can be used and what data it requires as input. Every
Action plug-in has certain performance characteristics relating to how quickly it can execute, reset,
and be ready for the next event. When an Action instance is created, it inherits the characteristics of
the selected Action plug-in. For better performance, not all Actions are available for all the different
Action modes in Sentinel. For example, Actions based on the Send E-mail Action plug-in do not
appear in Event Routing rules because you might not want to receive messages with a large event
stream every time the rule fires.
For information on where an Action plug-in can be used, refer to the Action Modes section in the
specific Action plug-in document.
Only actions that are executed in an Incident can be debugged. Therefore, a prerequisite to debug an
action is to execute that action in an Incident. For more information, see “Executing Incident Actions ”
in the Sentinel User Guide.
Action Description
Step Over Steps over a function to the next line in the script.
Step Out Steps out of the function to the next line in the script.
To debug an action:
2 In the Sentinel Control Center toolbar, click the Action Debugging icon.
3 Click to start the debugging process. The debugger panel displays the source code and
positions the cursor on the first line of the script.
You can debug the script as many times as needed. To debug the script by using a different
incident, close the Debug JavaScript Correlation Action window and repeat the debugging
process.
Although common Action plug-ins can be obtained from the Sentinel Plug-ins Web site, you can
create and manage your own Action plug-ins. New Action plug-ins can be developed by using the
Sentinel Plug-in SDK (http://www.novell.com/developer/develop_to_sentinel.html).
NOTE: You can delete an Action plug-in only if there are no Action instances configured to use it.
For example, if an Action is referenced by an Integrator, the Action cannot be deleted.
When you import a file from a directory, it is important to define the required objects correctly so that
the Actions are available for the appropriate Sentinel features.
NOTE: The Options area is available only for the String type parameters.
Overview
Integrators are plug-ins that can be used in Sentinel to extend the features and functionality of
Sentinel remediation actions. Integrators allow Sentinel to connect to external systems, such as an
LDAP server, SMTP server, or SOAP server. Actions use Integrators to interact with other systems.
For example, you can set an attribute in eDirectory, an LDAP server, to enable or disable a user, edit
details, and so on. You can also start an Identity Manager workflow, such as a provisioning request,
by using SOAP calls.
The general process for using an Integrator to perform remediation actions involves the following
steps:
1. Determine the best type of Integrator to access the external system with which you want to
interact.
2. Import and configure the appropriate Integrator to connect to the external system. Or, you can
use the Integrators that are configured by default.
3. Configure the appropriate Action. Or, you can use the Actions that are configured by default.
For more information, see Chapter 16, “Configuring Actions,” on page 187.
4. Perform additional configuration, if desired, to associate the action with a deployed correlation
rule or an event menu action.
5. The action is executed:
When an associated correlation rule fires.
When you execute actions on the selected events in the Sentinel Main interface > Event
Actions tab.
When you execute actions on the selected Incident in the Sentinel Control Center >
Incidents > Actions > Execute Incident Action.
For more information on specific Integrators, see the documentation that is available with the
Integrators. Alternatively, you can view a specific Integrator’s documentation by clicking the Help
button in the Integrator Manager after configuring that Integrator.
NOTE: Only users in the administrator role can configure and manage Integrators.
Adding an Integrator
The specific steps to configure an Integrator depend on the type of Integrator. The steps are
described in detail in documents that come with the Integrators. Documentation for installed plug-ins
can be viewed by selecting an Integrator in the Integrator Manager and clicking Help. Or, you can
refer to the document that comes with the Integrator plug-in.
NOTE: The most recent success or failure time is shown in the overall health status for the
configured Integrator.
Integrator Health Details: Provides information about the success of the API methods
called in the JavaScript action files associated with the Integrator. It provides information
specific to the methods called.
Method Name: Name of the API method used in the JavaScript.
NOTE: The most recent success or failure time is shown in the overall health status of the
method.
After importing the Integrator plug-in, you must configure the Integrator plug-in for your environment.
For more information, see “Configuring the Default Integrators” on page 196.
This chapter provides information about integrating Sentinel with identity management systems.
Overview
Users in an IT environment have multiple accounts and sometimes multiple account identifiers per
user. Normally, if a user has multiple account identifiers, Sentinel treats each identifier as a unique
account.
This means a user could log in to Active Directory and an LDAP directory and Sentinel tracks these
events, but Sentinel does not realize these events are related to the same user account.
In order to overcome this issues, 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.
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 [email protected] 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.
Sentinel provides an optional integration with Identity Manager. The figures and descriptions in this
section are based on Identity Manager.
Sentinel synchronizes identity information with major identity management systems and stores local
copies of key information about each identity. The following table summarizes the commonly used
information provided:
Name User name that references the account, generally provided by the user to log
in.
ID The numeric or other identifier that represents the account in the event
source. This ID is used for resolution when the user name is not available.
Authority The realm within which this account is unique. Collectors calculate the realm
based on event information.
The identities stored by Sentinel are then linked with accounts created on endpoint systems by the
identity management system. This helps Sentinel associate the correct identity information with the
native events from those endpoint system. Some identity information is injected directly into the
inbound event by using the mapping service. The remaining identity information, such as photograph
and contact information, is accessible through the Identity Browser.
The identity information injected into the event can be used for correlation and for performing actions
on the identities that are associated with detected activity. For example, Sentinel is able to see
multiple failed logins from a given person and not just an account. A detected violation could trigger
disabling activities for all accounts associated with an identity.
The examples and illustrations in this section use Identity Manager to explain how integration works
among identity management systems.
Sentinel integration with Identity Manager is provided using the Identity Manager driver called the
Identity Tracking Module for Sentinel. Standard event collection must also be set up with the systems
to which Identity Manager has provisioned accounts using the Collectors available at the Sentinel
Plug-ins Web site.
After Sentinel and Identity Manager are installed, the Identity Tracking Module for Sentinel sends
identity and account information from the Identity Vault to the Sentinel REST API, which populates
the Sentinel database.
IT Environment Sentinel
Identity Manager
Accounts
Table
Identity
Tracking REST API
LDAP
Driver Module
for
Sentinel
jsmith
DirXML-Accounts
jsmith LDAP
Database Driver/ Account Account Identifier
Application Identifier Type Sample Data
AD sAMAccountName jsmith
AD userPrincipalName [email protected]
AD DN cn=John Smith,cn=users,dc=company,dc=com
AD association 5de77f84f3ab534babbf13edd6540d77
LDAP DN cn=jsmith,cn=users,dc=company,dc=com
The time required to initially populate the Sentinel database depends on the amount of data in the
Identity Vault; identity information including photographs requires significantly more time to load.
The Identity Tracking Module for Sentinel also keeps the identity information synchronized as
information is updated in the Identity Vault during normal Identity Manager operations.
After the identity and account information are loaded, a map named IdentityAccount is
automatically generated in /var/opt/novell/sentinel/data/map_data. The map contains the following
information:
Account Name
Authority
Customer Name
Identity GUID
Full Name
Department
Job Title
IMPORTANT: An identity can have multiple accounts but one account cannot be assigned to multiple
identities.
The identity map is automatically applied to all events from Collectors to look for an identical match
between the information in the event and key fields in the map. The table below shows the fields that
are populated if all of the map key fields and event data exactly match. These mappings are
automatically configured and are not editable.
InitUserDepartment Department
TargetUserDepartment Department
NOTE: To find a match, the event fields and map key fields must match exactly. This might require
modifications to existing Collectors to enable them to parse or concatenate data to make these fields
match the data from the Identity Vault.
After these fields are added to the event by the mapping service, they are used by Correlation rules,
remediation actions, and reports in the Identity Tracking Solution Pack. In addition to using the
content included in the Solution Pack, users can also perform the following actions:
Create Correlation rules based on identity in addition to account name. This allows you to look
for similar events from a single user, which provides a more comprehensive view than looking at
events from a single account
Create reports that show identity, including all accounts associated with a user
Use the Identity Browser to get more information about users and their activities
Sources
There are several threat intelligence data sources that provide information about existing or emerging
threats to an organization’s security. Sentinel supports IP lists data sources. A typical data source
might provide a list of known compromised hosts, and when Sentinel receives events from those
hosts, the associated event source becomes a suspect. For example, you can download lists of
known Zeus botnet IP addresses. You can leverage the data sources in correlation rules to detect
communications to known botnets in your network.
Many of these data sources are updated daily. Sentinel provides the ability to download this data into
a map file, update it at scheduled intervals or as needed, and incorporate the relevant threat
information into correlation rules.
You can add threat intelligence data sources from any of the following sources:
URL: Specify the URL from where you want to download threat intelligence information. Since
these data sources are updated at regular intervals by external sources, you can configure
Sentinel to download the data at regular intervals. You can use the URL option for data feeds
that are open and do not require authentication. For commercial data feeds that require
authentication, use the File configuration option described below.
Some of the data source URLs including the ones that are available out-of-the-box use HTTPS
connection to download the feeds from their data source server. If Sentinel is in FIPS mode, the
certificates used by the data source server for secure communication must be added to the
Sentinel FIPS keystore database.
1. Download the certificates from the data source server and save them in individual files with
the .cer extension.
2. Import the certificates into the Sentinel FIPS keystore.
For more information about importing the certificate, see “Importing Certificates into FIPS
Keystore Database” in the Sentinel Installation and Configuration Guide.
File: If you want to subscribe to commercial feeds that require authentication, you can download
feeds at regular intervals to a file and use that file as the data source. For Sentinel to process the
data, you must place the file in the <sentinel_data_directory>/data/feed_data directory
and then add the file as a data source.
NOTE: If you are using the curl command in the plug-in to download data from the data source,
ensure that the curl package version is minimum curl4-7.37.0-28.1.x86_64. The plug-in does
not work if your operating system has a lower version of this package. For example, as of the
publication date of this document, SLES 11 SP4 has a lower version of the curl package. SLES
12 SP1 and later have the required version of the curl package.
While adding a data source, you can select an appropriate threat type for the data source. By default,
Sentinel populates several common threat types in a drop-down list from which you can select. You
can also add your own threat type to the list by updating the configuration.properties file as follows:
SourceHostThreatSource (shts)
TargetHostThreatSource (thts)
SourceHostThreatType (rv198)
TargetHostThreatType (rv199)
SourceHostReputationScore (rv158)
TargetHostReputationScore (rv159)
If the IP addresses are listed in more than one data source, Sentinel considers the values for the
above event fields from the data source that has a higher priority.
Sentinel provides the Threat Intelligence Solution Pack out-of-the-box, which includes correlation
rules that detect communications to or from these IP addresses in your network. In upgrade
installations, you must manually upgrade the Threat Intelligence Solution Pack in Solution Manager
to get these latest correlation rules.
You can uninstall the previously installed Palevo and Zeus feed plug-ins in the Plug-ins > Catalog
user interface.
Sentinel Advisor, powered by Security Nexus, is an optional data subscription service that provides
device-level correlation between real-time events, from intrusion detection and prevention systems,
and from enterprise vulnerability scan results. Advisor acts as an early warning service and detects
attacks against vulnerable systems by providing normalized attack information. It also provides the
associated remediation information.
The Advisor subscription is optional. However, it is necessary if you want to use the Sentinel Exploit
Detection or the Advisor Reporting features.
Understanding Advisor
The Advisor service and its corresponding Exploit Detection feature depend on the mappings
between the attacks against enterprise assets and the known vulnerabilities of those assets. The
Advisor and the Exploit Detection features require the following data to work with the Advisor
products:
Vulnerability scan data: The vulnerability scanners check enterprise assets for known
vulnerabilities. The scanned data can then be loaded into the Sentinel database to serve as
referential information, by using the Collectors that support Advisor.
Advisor mapping data: The Advisor data contains information about known threats, including
attacks and vulnerabilities. The Advisor service gathers information from various vulnerability
and intrusion detection vendors, and creates mappings between abstract vulnerabilities and
attacks.
Security Nexus provides the Advisor feed data that contains information about known security
vulnerabilities and threats, and also provides normalization of intrusion detection signatures and
vulnerability scans. The Advisor data feed is updated on a regular basis as new attacks and
vulnerabilities are reported. The updates are available at the Novell download Web site (https://
secure-www.novell.com/sentinel/download/advisor/).
NOTE: The initial Advisor data feed is installed by default on the Sentinel server at /var/opt/
novell/sentinel/data/updates/advisor. However, you must purchase an additional license
to download the updated Advisor feed.
Both vulnerability scanners and the intrusion detection systems must report vulnerabilities and
attacks against the same set of systems. In Sentinel, systems are identified by their IP
addresses and their tenant name. The tenant name is a namespace identifier that prevents
overlapping IP ranges from matching incorrectly. The tenant name can be the name of the
customer, division, department, and so forth that owns this event data.
The vulnerability scanner and intrusion detection system products must be supported by the
Advisor service. This data uses specific product identifiers to ensure proper matching.
The specific reported attacks and vulnerabilities must be known to the Advisor service and
Exploit Detection.
All Collectors available on the Sentinel Plug-ins Web site meet these requirements, as long as they
are declared as being supported by Advisor. To write your own vulnerability or intrusion detection
Collector, or to modify one of the shipped Collectors, refer to the Sentinel Plug-in SDK (http://
developer.novell.com/wiki/index.php?title=Develop_to_Sentinel) for specific information about which
event and vulnerability fields must be filled in to support this service.
The following table lists the supported products with their associated device type (IDS for intrusion
detection system, VULN for vulnerability scanners, and FW for firewall).
To enable exploit detection, the Sentinel Collectors must populate several variables as expected.
Collectors available for download on the Sentinel Plug-ins Web site populate these variables by
default. For information on configuring the Collectors, Connectors, and Event Sources, see
“Configuring Data Collection for Other Event Sources” on page 91.
In intrusion detection systems and vulnerability Collectors, the RV31 (IDSName) variable in the
event must be set to the value in the RV31 column in Table 20-1. This string is case sensitive.
In the intrusion detection systems Collector, the DIP (TargetIP) must be populated with the IP
address of the machine that is being attacked.
In the intrusion detection systems Collector, RT1 (IDSAttackName) must be set to the attack
name or attack code for that intrusion detection system.
In the intrusion detection systems and vulnerability Collectors, the RV39 (TenantName) value
must be populated. For a standard corporation, the value can be anything. For a Managed
Security Service Provider (MSSP), the tenant name should be set for the individual customer.
For either type of company, the value in the intrusion detection systems Collector must exactly
match with the value in the vulnerability Collector.
These values are used by the Mapping Service to populate the VULN field in the event. This value is
used to evaluate the incoming events to determine whether a vulnerability is exploited or not. When
the vulnerability field (VULN) equals 1, the asset or destination device is exploited. If the vulnerability
field equals 0, the asset or destination device is not exploited.
The initial mapping time might take up to 30 minutes. However, you can modify the time by changing
the value of the minregenerateinterval property in the ExploitDetectDataGenerator
component of the server.xml file. The time is given in milliseconds. For example, you can change
the time from 1800000 (30 minutes) to 180000 (3 minutes). For more information about modifying the
server.xml file, see “Maintaining Custom Settings in XML Files” on page 302.
NOTE: You must restart the Sentinel service for the changes to take effect.
NOTE: If the Vulnerability field is blank, the exploitdetection.csv file is not generated.
For more information on viewing events, see “Viewing the Advisor Data” on page 222.
Download Method: Enables you to process the Advisor feed files manually and launch the
Download Manager feature to configure the Sentinel server for automated processing of the feed
files. For more information on processing the Advisor feed, see “Processing the Advisor Feed”
on page 216.
Exploit Detection: Lists the vulnerable products that are included in the feed files, and enables
you to configure the products for exploit detection. For more information, see “Configuring the
Advisor Products for Exploit Detection” on page 217.
NOTE: The Exploit Detection section initially displays a blank list unless you process the initial
Advisor feed that was loaded during Sentinel installation. For more information, see “Processing
the Advisor Feed” on page 216.
Preview Threat Map: The Preview Threat Map window lists the top 5000 entries of the
exploitdetection.csv file. This list displays the attacks that attempt to exploit your machine.
To view the threat map: click Preview Threat Map.
NOTE: This list is blank unless the exploitdetection.csv file has been generated.
For more information on exploit detection, see “Understanding Exploit Detection” on page 212.
NOTE: To download Advisor updates, you must purchase the Advisor Data Subscription and obtain
the credentials.
For example, you can configure the Sentinel server to download the Advisor feed at fixed intervals.
After the feed is downloaded, the Download Manager notifies the Advisor processes to process the
downloaded feed and load it into the Sentinel database.
The Download Manager window lists the download configurations and displays the status of the
previous download for each download configuration. By default, a download configuration is available
that is partially configured for Advisor. You can use the same configuration to download an Advisor
feed, by specifying the login credentials and other details, and activating the download configuration.
NOTE: The Advisor feed can also be manually downloaded from the Novell Download Web
site (https://secure-www.novell.com/sentinel/download/advisor/). However, the manual
download URL does not work in Download Manager.
NOTE: An audit event is generated regardless of whether the download status indicates success
or failure.
You can create appropriate correlation rules to receive notifications of these audit events through
email. For more information on creating correlation rules, see “Correlating Event Data” in the Sentinel
User Guide.
The Advisor Status window displays the Advisor information only if the feed files are processed and
loaded into the database.
Fields Description
For example: Cisco Secure IDS and Enterasys Dragon Host Sensor.
Product Type Shows whether the product type is a Vulnerability, Intrusion Detection System
(IDS), or Firewall.
Number of Signatures Shows the number of signatures for the product by Nexus.
Last Update Time stamp indicating when the product was last updated.
Feed File Name Shows the name of the feed files that have been processed and are currently
being processed.
Process Start Time stamp indicating when processing the feed file started.
Process End Time stamp indicating when processing the feed file finished.
The process end time is blank if there is an error that halts processing or if
processing is still in progress.
The Advisor feed must be up-to-date, processed, and loaded into the Sentinel database.
The selected event is from a product supported by Advisor and has the Vulnerability field value
set to 1.
In the Sentinel Main interface, click Filters > Exploit Detected Events or specify vul:1 in the Search
field, then click Search.
Sentinel displays all events that are likely to have exploited a known vulnerability.
You can also view the report for these events by selecting the desired events, then clicking Event
Operations > View Advisor report.
You can configure Sentinel to analyze your events, detect patterns, set up baselines, configure
workflows to act on the events, manage and remediate threats, visualize network activities, and more.
For more information about using these features, see the Sentinel User Guide.
The Sentinel Data Federation feature enables you to search for events, view alerts, and run reports
not only on your local Sentinel server, but also on other Sentinel and Sentinel Log Manager servers
distributed across the globe.
Overview
The Data Federation feature facilitates searching events, viewing alerts, and reporting event data
from local and remote Sentinel servers. When you are working with multiple servers, you can perform
a search or run a report on just one server and have it automatically run a search or report across the
selected remote servers. The server on which the search is initiated is referred to as the authorized
requestor, and the remote servers are referred to as the data sources or data source servers.
When you run a search or report on the authorized requestor, search queries are sent to each
selected data source server. The data source server authenticates the authorized requestor server,
using a password that is exchanged during configuration. Event or alert data is returned to the
authorized requestor, where it is merged, sorted, and rolled up for presentation. Individual search
results display the data source servers from which they were received. The search status for each
server is available for viewing and troubleshooting.
Figure 21-1 shows how you can set up the Sentinel servers across the globe for data federation,
which enables distributed search and reporting.
After you enable data federation, you need to add data source servers to the authorized requestor
server. If you know the administrator user name and password for the data source server, you can
add the data source server directly from the authorized requestor.
If you do not know the administrator user name and password for a data source server, you can set
up the authorized requestor with an opt-in password that allows administrators of data source servers
to add their data source servers to the authorized requestor. When you do this, administrators of data
source servers do not need to share their user names and passwords with you. You must share the
opt-in password with the data source server administrator.
IMPORTANT: You should ensure that the data source server that you add is able to communicate
with the authorized requestor. The data source server should be able to communicate through TCP/
IP. The IP address or host name of the data source server must be accessible through firewalls,
NATs, etc. You can use the ping command to ensure that there is communication from both ways. If
there is a communication failure between the servers, an error is displayed in the extended status
page. For more information, see “Managing the Data Federation Search Results” on page 231.
1 If you are continuing from “Enabling Data Federation” on page 228, skip to Step 3; otherwise,
continue to Step 2.
2 From Sentinel Main, click Integration > Sentinel.
You can now search events, view event reports, and view alerts from the data source server. For
more information, see “Searching for Events” on page 231, “Running Reports” on page 233, and
“Viewing Alerts” on page 233 respectively.
When a data source server opts in to the authorized requestor, a message is sent to the authorized
requestor server requesting that it be added to the list of data source servers maintained by the
authorized requestor server. The request authorizes the authorized requestor to access data on the
data source server. The authorized requestor requires an opt-in password to verify that the opt-in
request has originated from a valid data source server. During the opt-in process, the authorized
requestor and the data source server exchange the appropriate password, which allows the data
source server to authenticate the search requests from the authorized requestor.
1 Log in to the authorized requestor server as a user with Search Remote Data Sources
permission.
2 Click New Search.
3 Click the Data sources link under the Search field.
A dialog box is displayed that lists the data source servers that you have added, including the
local server. The data source servers that are disabled are also displayed, but they are dimmed.
4 Select the check boxes next to the data source servers on which you want to perform a search,
then click OK.
5 Specify the search criteria in the search field, then click Search.
If you do not specify any search criteria, the authorized requestor server runs a default search for
all events with severity 0 to 5.
The Search Results page displays the events from the selected data source servers and the
local server (if selected). The search results are filtered through the combination of the security
filter and permissions of the logged-in user and the security filter and permissions of the search
proxy role on the data source servers. For information on the distributed search results, see
“Managing the Data Federation Search Results” on page 231.
You can expand the event results to see the details by clicking the All link.
For non-internal events, the get raw data link is displayed. You can view the raw data only if your
role's security filter is set to view all event data.
NOTE: For search results that come from the data source servers, the role that is used to retrieve raw
data is not the role of the logged-in user that is performing the search on the authorized requestor
server, but the role that is assigned to the authorized requestor server on the data source server.
Data Source Name: The descriptive name of the data source server. If you did not specify a
descriptive name for the data source server, this field displays the IP address or DNS name of
the data source server.
Events Available: Indicates the number of events that have actually been retrieved from the
data source server. The value is displayed as N of M events available, where N is the
number of events that have been retrieved so far and M is the total number of events on the data
source server that match the search criteria.
Retrieval Rate (EPS): An approximate rate of how fast the events were retrieved from a specific
data source server.
Status: Displays the error messages, if any (generally in red). In addition to error messages, this
field also displays the status of the search.
Running: Indicates that the search is still running on the data source server.
Buffering events for display: Indicates that the search is finished on the data source
server, but the authorized requestor server is retrieving events from the data source server
and buffering them for display.
Paused buffering events for display: Indicates that the search is finished on the data
source server, and the authorized requestor has paused while retrieving events from the
data source. The authorized requestor reads ahead a few pages from the last page that you
scrolled down to. When it has buffered enough pages ahead, it pauses so that events are
not buffered unnecessarily.
Searching, paused buffering events for display: This is similar to pausing and buffering
events for display, except that the search is not yet complete on the data source server.
Done buffering: Indicates that the search is complete on the data source server, and all of
the results are retrieved by the authorized requestor and queued for display.
You can further refine the distributed search results and perform various actions based on your
requirements. For more information, see “Searching Events” in the Sentinel User Guide.
You can also refine the search activity query. For example, you can change the date range to see
what queries have been performed today or yesterday or in the last hour, or you can drill down to see
the queries that were made by particular users on the authorized requestor.
Running Reports
Running reports in a distributed environment is similar to running reports on your local server, except
that you select the data source servers from which you want to view the reports while specifying the
report parameters.
1 Log in to the authorized requestor sever as a user with Search Remote Data Sources
permission.
2 From the Reports section, select the report you want to run, then click Run.
The Run Report page is displayed.
3 Click the Data sources link.
A page is displayed that lists the data source servers that you have added, including the local
server. The data source servers that are disabled are also displayed, but they are dimmed.
4 Select the data source servers from which you want to view the reports, then click OK.
5 Specify the other parameters for the report.
For more information on these parameters, see “Reporting” in the Sentinel User Guide.
6 Click Run.
A report results entry is created and listed under the selected report. For more information on
managing reports, see “Reporting” in the Sentinel User Guide.
Viewing Alerts
Viewing alerts in a distributed environment is similar to viewing alerts from your local server, except
that you select the data source servers from which you want to view alerts while creating alert views.
To view alerts from data source servers, you must log in to the authorized requestor server as a user
with Search Remote Data Sources permission.
For information about creating alert views, see “Creating an Alert View” in the Sentinel User Guide.
When you create an alert view with data source servers specified as data sources, you can view the
alerts from the data source servers in that alert view. For information about viewing alerts, see
“Viewing and Triaging Alerts” in the Sentinel User Guide.
NOTE: In distributed environments, you can view alerts only from Sentinel data sources and not from
Sentinel Log Manager data sources, because Sentinel Log Manager does not support alerts.
Troubleshooting
You can perform some basic troubleshooting to ensure that you have successfully configured the
authorized requestor for data federation. This section lists the most common issues and the probable
causes for these issues.
Permission Denied
After doing a distributed search, check the extended status page to view the search status. If the
search is not successful, check the following possible causes:
The data source server administrator might have disabled data federation on the data source
server. To enable data federation on the data source server, see Step 3 in “Authorizing an
Authorized Requestor Server” on page 230.
The data source server administrator might have disabled the authorized requestor server for
data federation. Ensure that the authorized requestor server is enabled in the data source
server. Fore more information, see “Authorizing an Authorized Requestor Server” on page 230.
The role that you used for connecting might not have the Search Data Targets permission.
Connection Down
Network issues in your organization.
Sentinel servers or Sentinel services might be down.
The trial license might be expired. You must purchase an enterprise license to reactivate this
feature to view the events from the data source servers.
The user who has logged in to the authorized requestor has one set of permissions on the local
data such as view all data, view system events, security filter settings, and so on. The search
proxy group has another set of permissions, possibly more restrictive. Therefore, certain types of
data, such as raw data, system events, and PCI events, might be returned only from the local
system and not the data source server.
Error Logs
You can also determine the cause of a search failure by examining the log file on the authorized
requestor server. The default location for the log file is /var/opt/novell/sentinel/log. For
example, you might see one of the following messages:
To perform a complete investigation and analysis of a security event, you might want to monitor the
entire network activities in detail. Sentinel leverages ArcSight SmartConnectors that help you monitor
your enterprise network by collecting IP Flow data (NetFlow, IPFIX, JFlow, sFlow, and so on) in your
network. SmartConnectors collect IP Flow data from network devices such as routers, switches, and
firewalls.
IP Flow data describes basic information about all the network connections between hosts, including
transmitted packets and bytes. This helps you to visualize the behavior of individual hosts or the
entire network.
For more information, see the Universal Common Event Format Collector documentation on the
Sentinel Plug-ins Website.
Policies
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 Secure Configuration Manager (SCM). Integration with SCM
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 SCM in a
single interface.
Sentinel is auto-configured to receive SCM events. Ensure that SCM is configured to send events to
Sentinel. For more information, see “Integrating Secure Configuration Manager with Sentinel” in the
Secure Configuration Manager User Guide.
NOTE: When configuring SCM to send compliance information to Sentinel, SCM administrator can
configure it in the following two ways:
If SCM administrator configures to send compliance information as an event with attachment, you do
not need to perform any configuration in Sentinel to receive compliance information from SCM.
Perform the following procedure only if SCM administrator has configured to send compliance
information just as an event.
For information about viewing Secure Configuration Manager events and the associated compliance
details, see “Viewing Compliance to Configuration Policies ” in the Sentinel User Guide.
You can extend Sentinel’s threat monitoring capability by integrating Sentinel with Change Guardian.
Change Guardian gives you the security intelligence you need to rapidly identify and respond to
privileged-user activities that could signal a security breach or result in compliance gaps. It helps
security teams detect and respond to potential threats in real-time through intelligent alerting of
authorized and unauthorized access and changes to critical files, systems, and applications.
To receive Change Guardian events, the Change Guardian administrator must configure the Change
Guardian server to send events to Sentinel. For more information, see “Managing Event
Destinations” in the Change Guardian User Guide.
For information about viewing Change Guardian events, see “Viewing Compliance to Configuration
Policies ” in the Sentinel User Guide.
You can also view Change Guardian reports, by importing reports from Change Guardian. For more
information, see “Creating Reports” in the Sentinel User Guide.
This chapter provides information about configuring and monitoring threat detection notifications by
using alerts in Sentinel.
Understanding Alerts
An event, which is generated externally, represents some activity that might not be always
exceptional. But a set of similar or comparable events in a given period, might indicate a potential
threat. Sentinel helps you correlate events by using correlation rules, which helps you take
appropriate actions to mitigate any problems. However, to receive instant notification about such
potential threats, you can configure correlation rules to create alerts.
Alerts notify you about potential threats against some IT resource. In addition to potential threats,
alerts can also indicate any performance thresholds, such as system memory full or IT resources not
responding. Alerts help you to analyze the events and identities to determine the root cause of
potential threats.
Alerts provide some high-level details of an event that allow you to quickly drill down to event details
and determine whether it's a potential threat or a false positive. If the alert seems to be a potential
threat, you can optionally escalate that alert to an incident. You can attach multiple events, host
information, vulnerabilities, and even arbitrary attachments to an incident that may help analysts in
further investigation of the incident.
Overview
The following figure provides an overview of creating and monitoring alerts:
Figure 25-1 Alert Overview
Visualization and
Alert Creation Triage Maintenance
Monitoring
Closed
Correlation Rule Role - based Access
Alert
REST API
Retention Policy
External Systems
As subsequent instances of the same alert are detected, Sentinel associates the trigger events
to the existing alert to avoid duplication of alerts.
Associate the Create alerts action to a correlation rule. Sentinel generates an alert when the
correlation rule fires.
Create alerts by using the REST API. For more information, see the Alert Create Method section
in Help > API Documentation.
1. When a new alert is created, Sentinel initializes the Occurrences field value in the alert to 1.
2. Subsequent instances of the same alert are rolled up into the existing alert until the existing alert
is closed. After the existing alert is closed, if a new instance of the same alert is detected, a new
alert is created.
When rolling up alerts, Sentinel performs the following activities:
Increments the value of the Occurrences field by one.
Associates trigger events of the new alert instance to the existing alert.
Sentinel determines the sameness of alerts by comparing the existing alert fields with the fields
of the new alert instance. When comparing the alerts, Sentinel considers all fields except unique
and date/time fields.
3. Multiple open alerts with identical fields can exist if one or more alerts are re-opened from the
closed state. In this case, Sentinel chooses the most recently created alert for roll up.
Rolling up of alerts helps in reducing the number of open and duplicate alerts in Sentinel.
When the alert is created by a correlation rule, the fields of the correlated event are copied to the
alert. The Create alerts action also sets the following properties on the alert: Owner, Priority, and
State. Therefore, you can control the alert output by customizing the correlated event. To customize
the correlated event, see “Customizing Correlated Event” in the Sentinel User Guide.
For example, consider a correlation rule that generates a correlated event with severity 5 whenever
User A logs in to the system and the Create Alerts action is associated to the correlation rule. When
the correlation rule fires, Sentinel creates an alert with severity 5. Subsequent alert instances
triggered by this correlation rule are identical to the existing alert. Therefore, Sentinel rolls up the alert
instances into the existing alert. If the severity field value of the correlated event is customized to 3,
Sentinel generates a new alert with severity 3 instead of rolling up the alert instance to the existing
alert.
1 In the Correlation panel, select the correlation rule to which you want to associate the Create
Alerts action, and click the Edit icon.
2 In the correlation rule builder, in the Actions section, select Create alert.
3 To configure the alert, click Configure.
4 Specify the following details in the Configure Alert window:
Owner: You can specify a user or a role as the owner of the alert. If you specify a role as
the owner of the alert, all the users in that role are owners for the alert. One of the users in
that role can acknowledge the alert to notify that they have taken the ownership of the alert
and are investigating the issue.
NOTE: When assigning an alert to a user or a role, ensure that the role or the user has the
Manage Alerts permission.
Filtering Alerts
You can configure alert routing rules to filter the alerts and choose to either store the alerts in the
Sentinel database or drop the filtered alerts. For example, if you want to exclude the alerts involving
the initiator user Albert, you can configure the rule criteria to drop all the alerts with the initiator user
name Albert.
Sentinel evaluates the alert routing rules on a first-match basis in top-down order and applies the first
matched alert routing rule to alerts that match the filter criteria. If no routing rule matches the alerts,
Sentinel applies the default rule against the alerts. The default routing rule stores all the alerts
generated in Sentinel.
1 From Sentinel Main, click Routing > Alert Routing Rules > Create.
2 Specify the following information:
Name: Specify a name for the alert routing rule.
Criteria: Specify the criteria to filter alerts.
Action: Select either of the following options:
Store: Stores the filtered alerts in the alert store.
Drop: Drops or ignores the alerts that match the specified criteria.
WARNING: If you select Drop, the filtered alerts are lost permanently.
Enable: Allows you to enable the alert routing rule. By default, this option is deselected.
3 Click Save to save the alert routing rule.
Sentinel processes the first routing rule that matches the alert based on the criteria. For example, if
an alert passes the criteria for two routing rules, only the first rule is applied. The default routing rule
always appears at the end.
Sentinel checks for closure and deletion of alerts once every day, at midnight.
This section provides information about using the built-in solution packs and creating your own
solution packs.
Solution Packs allow partners and customers to create and easily manage solutions to specific
business problems.
Overview
Solution Packs provide a framework within which sets of content can be packaged into controls, each
of which is designed to enforce a specific business or technical policy. The control can use any of the
detection, filtering, alerting, and response features of Sentinel, as well as provide documentation on
control status and enforcement. By managing the set of content as a unit within the control, the
Solution Pack solves dependency problems and simplifies implementation.
Controls within a Solution Pack can include the following types of content:
Correlation rule deployments, including deployment status and associated Correlation rules,
Correlation actions, JavaScript plug-ins and integrators, and Dynamic Lists
Reports
Filters
Searches
iTRAC workflows, including associated roles
Event enrichment, including map definitions and event meta tag configuration
Other associated files added when the Solution Pack is created, such as documentation,
example report PDFs, or sample map files.
For example, a Solution Pack can package content related to governance and regulatory compliance
into a comprehensible and easily enforceable framework that is easy to deploy.
Solution Packs are created with the Solution Designer application. Using this tool, a user creates the
Solution Pack, associated controls and documentation, and then associates Sentinel content with
each control. The entire package is then exported as a ZIP file. For more information on creating a
Solution Pack and adding content to it, see “Solution Designer” on page 264.
The ZIP file containing the Solution Pack is first imported into an existing Sentinel system by using
the Solution Packs Manager in the Sentinel Control Center. You then use the Solution Manager to
install the imported Solution Pack.
NOTE: Only users in the administrator role can access the Solution Packs Manager.
Solution Pack A Solution Pack is the root node in the content hierarchy. Each
Solution Pack can contain one or multiple Category nodes.
N/A Content Group A content group is a set of related content. There are several
types of content groups, such as reports, Correlation rules, and
event configurations, each with its own icon.
The following table describes the types of content groups and what the content that they contain:
Event Configuration A content group that contains a map definition and the
configuration of one or more related Sentinel meta tags.
Report A report.
The first step in using a Solution Pack is to import the .zip file into the system through the Import
Plug-in Wizard. When a Solution Pack is imported, the .zip file is copied to the server. The actual
contents of the Solution Pack are not available in the target Sentinel system until the controls are
installed through the Solution Manager. For more information, see “Installing Content from Solution
Packs” on page 257.
If you import an updated version of a Solution Pack, you are prompted to replace the existing plug-in.
1 Launch the Sentinel Control Center as a user who has the administrator role.
2 Launch the Solution Packs Manager.
(Conditional) If the Configuration menu is not enabled, click the Configuration tab, then
click the Configuration menu > Solution Packs or click the icon in the toolbar.
(Conditional) If the Configuration menu is enabled, click the Configuration > Solution
Packs or click the icon in the toolbar.
The Solution Packs Manager window is displayed.
3 Click the Import icon in the Solution Packs Manager window to open the Import Plug-in Wizard.
4 Select Import Solution package plugin file (.zip), then click Next to display the Choose Plugin
Package File window.
5 Use the Browse button to the locate the Solution Pack to import to the plug-in repository. Select
a .zip file and click Open.
6 Click Next.
If you selected a solution pack that already exists, the Replace Existing Plugin window displays.
Installing a control and the child content for the control into the Sentinel system. When the
content is initially installed, its status is Not Implemented.
Implementing a control by configuring event source systems and Sentinel to use the content
associated with the control. Solution Packs include detailed documentation describing
implementation steps.
Testing a control to verify the content associated with the control. Solution Packs include detailed
documentation describing testing steps.
Content Panel
The Content panel provides information about the extracted Solution Pack files. This panel displays a
hierarchical view of the category, control, content group, and various types of content. All parent
nodes reflect the overall state of the controls they contain. This means that parent nodes have an
inherited status based on their child content.
Content Comparison
When the Solution Pack is opened, the Solution Manager compares the contents of the Solution Pack
to other Solution Pack content from different Solution Packs or previous versions of the same
Solution Pack.
Installed Indicates that the content is already installed in the target Sentinel
system.
The version is the same in the opened Solution Pack and the
previously installed Solution Pack.
Out of Sync Indicates that a different version of the content is already installed in
the target Sentinel system. A difference in name, definition, or
description could trigger an Out of Sync status.
NOTE: The Solution Manager only compares content from different Solution Packs (or different
versions of the same Solution Pack) for installed content. It does not compare content that has not yet
been installed. It also does not compare Solution Pack content to content in the target system, so
manual changes to content in the Sentinel Control Manager are not reflected in Solution Manager.
Documentation Panel
The Documentation panel displays descriptive information provided to describe the Solution Pack
when it was created in the Solution Designer. For more information on the Solution Designer, see
“Solution Designer” on page 264.
The following informational tabs, populated and edited in the Solution Designer, are available:
Description: A description of the selected node. You can view attachments and their
descriptions in the Description tab.
You can add text to the External ID field to refer to specific regulations or corporate IDs.
Implementation: Instructions for implementing the selected control.
Testing: Instructions for testing the selected control.
Notes: Use this tab for any notes related to the control, including user comments on the testing
or implementation process.
1 Click the Configuration menu and select Solution Packs to display the Solution Packs Manager
window:
2 Double-click a Solution Pack in the Solution Packs window to display the Solution Manager.
When you install either a Solution Pack or an individual control, all of the child nodes are installed.
Only fully defined controls can be installed. For controls that contain placeholders, the Install option is
disabled.
1 In the Solution Packs Manager window, double-click a Solution Pack to open the Solution
Manager.
Alternatively, you can select a Solution Pack that you want to install and click Open with Solution
Manager icon.
For more information, see “Launching the Solution Manager” on page 254.
2 Select a Solution Pack or a control that you want to install. Click Install.
Alternatively, right-click a Solution Pack or control and select Install.
The Install Control Wizard opens. If you select a Solution Pack, all the controls in that Solution
Pack display. If you select an individual control, then that control is displayed in the Install
Control Wizard window.
3 Click Next to display the Install Content window.
If Correlation rules and actions are included in the Solution Pack, you need to proceed through
several additional screens until you reach the Install Content window. For more information, see
“Correlation Rules and Actions” on page 258.
4 Click Install.
5 After the installation is complete, click Finish.
Correlation rules deploy in an Enabled or Disabled state, depending on their status in the source
Sentinel system when the Solution Pack was created.
If an Execute Script Correlation action is associated with the Correlation rule, the Solution Manager
attempts to install the associated JavaScript code on all Correlation Engines. If a Correlation Engine
is idle, you can still deploy the rule. However, the status of the rule will be disabled in the Sentinel
Main interface after importing.
If an Execute Command Correlation action is associated with the Correlation rule, the Solution
Manager installs the command and its arguments, but the script or utility must be manually configured
on the Correlation Engine. This might require installing the utility, configuring permissions, or
manually copying a script file to the proper directory on the Correlation Engine.
In a default installation, the proper directory for the script file is /opt/novell/sentinel/bin/
actions.
If a JavaScript Action is associated with the Correlation rule, the Solution Manager installs the Action
configuration, the Action plug-in, and the associated integrator configuration and Integrator plug-in (if
it is needed).
Configuring Controls
“Duplicate Content within a Solution Pack” on page 259
“Content with the Same Name in the Target Sentinel System” on page 259
“Resolving Out of Sync Content” on page 259
“Copying a Map File” on page 260
Each content item is only installed once. If the same content item (for example, an iTRAC workflow or
a Correlation rule) is included in more than one control, it is only installed once. Therefore, if you
install one of those controls, the content displays with an installed status in the other control. In this
scenario, the Solution Manager might show that the content for the second control is only partially
installed.
NOTE: To prevent confusion for end users, rename one of these rules.
1 Open the Solution Pack in the Solution Manager for which you want to resolve the out of sync
content.
2 Select the out of sync content (not the control or category) in the Solution Manager.
3 Select the content, right-click, then select Out of synchronization content detail.
A message displays information about which Solution Pack is the source of the out of sync
content.
4 Compare the content in the two Solution Packs to determine which version you want to keep.
5 Uninstall the control from the Solution Pack that you do not want to keep. For more information,
see “Uninstalling a Control” on page 261.
Resolve the out of sync issue before installing the new Solution Pack.
6 Reinstall the control with the content you want to keep.
7 Implement and test as necessary.
When you create a Solution Pack using a Map control, the map definition file (.csv) that is used to
create the Map is not bundled in the Solution Pack. Therefore, when you install this Solution Pack on
any other Sentinel server, you do not get the expected behavior This is because this Map looks for
the required information in the map definition file (.csv) in the var/opt/novell/sentinel/data/map_data
folder of the Sentinel Server to populate the tag. If the correct .csv file is not there, the Map control
does not work properly.
You must copy the map definition file that you used to create the Map to the var/opt/novell/sentinel/
data/map_data folder whenever you install any Solution Pack that has a Map control.
Implementing a Control
The steps on how to implement a control is added when the Solution Pack is created in the Solution
Designer. The steps might include instructions for the following types of implementation actions:
You only need to follow the instructions that are in the Implementation tab for the control.
To implement a control:
Because of potential legal and regulatory implications, the status for a control should only be changed
after all of the implementation steps have been successfully completed.
To test a control:
Because of potential legal and regulatory implications, the status for a control should only be changed
after all of the testing steps have been successfully completed.
Uninstalling a Control
Controls are often used to meet legal or regulatory requirements. After they are implemented and
tested, controls can be uninstalled after careful consideration.
When a control is uninstalled, the status for the control reverts to Not Implemented and child content
is deleted from the Sentinel system. There are a few exceptions and special cases:
Dependencies are checked to ensure that no content that is still in use is deleted. Some
examples of this include a Dynamic List that is used by a Correlation rule created in the target
Sentinel system, a report that is used in a control that is still installed, an iTRAC workflow
template that is used in a Solution Pack that is still installed, or a folder that still contains other
content.
Reports (.rpt files) copied to a local system cannot be removed if the uninstall is performed
from a Sentinel Control Center on a different machine.
JavaScript files associated with Execute Script Correlation actions remain on the Correlation
Engines.
Maps (.csv files) and the data they contain are not deleted.
Roles associated with workflows are not deleted.
iTRAC workflow processes that are already in progress continue until completion even if the
iTRAC workflow is uninstalled.
To uninstall a control:
None/Blank: No status indicator for a control indicates that the associated content has not been
installed yet.
Not Implemented: When none or some of the contents of a control are installed, the control is in
the Not Implemented state. If the same content is installed by another control, a control might be
Not Implemented even if some of its child content is Installed.
Implemented: Indicates that a user has completed all of the implementation steps and manually
set the control status to Implemented. For more information, see “Implementing a Control” on
page 260.
Tested: Indicates that a user has completed all of the testing steps and manually set the control
status to Tested. For more information, see “Testing a Control” on page 261.
Out of Sync: Indicates that a different version of the content in the Solution Pack has been
installed in the Sentinel target system by another Solution Pack or a previous version of the
same Solution Pack. For more information, see “Out Of Sync Status” on page 256
1 Open a Solution Pack in the Solution Manager for which you want to generate a status report.
2 Click Create PDF. The Report Options window displays.
Show status information: Select this option to show deployment status for each control
(Not Installed, Not Implemented, Implemented, or Tested) and whether it’s Out of Sync.
You cannot delete a Solution Pack without uninstalling the controls first. For more information, see
“Uninstalling a Control” on page 261. If you do not uninstall the controls and try to delete a solution
pack, you are notified that content is still deployed.
After the new Solution Pack is installed, its behavior varies, depending on the status of the original
Solution Pack’s content.
If the content from the original Solution Pack was not installed yet, the content is simply
replaced. When a user installs content, the new content is installed to the target Sentinel system.
If the content from the original Solution Pack was installed (Not Implemented), Implemented, or
Tested, the original content is compared to the new content.
If the content version is the same, the original content is still valid and no action is necessary.
If the content version is different, the content status is set to Out of Sync. You must decide how
to resolve the synchronization issue. For more information, see “Out Of Sync Status” on
page 256.
If the content did not exist in the original Solution Pack, it is displayed in Solution Manager as not
installed. You can install, implement, and test the new content.
If the content existed in the original Solution Pack but has been deleted from the modified
Solution Pack, it does not appear in the Solution Manager.
NOTE: The Solution Manager only handles differences in the contents of Solution Packs. It does not
recognize manual content changes that are performed after content is installed.
Solution Designer
You can use the Solution Designer to package and export different contents, such as a Correlation
rule with associated actions and Dynamic Lists. These items can be selected and packaged with their
configuration to a .zip file. You can then view or select the content of the file in the Solution Manager.
For more information, see Chapter 27, “Creating Solution Packs,” on page 265.
You can use the Solution Designer to package and export different contents, such as a Correlation
rule with associated actions and dynamic lists. The content can be selected and packaged with its
configuration in a ZIP file. You can then view or select the content of the ZIP file by using the Solution
Manager. For more information on the Solution Manager, see Chapter 26, “Using Solution Packs,” on
page 251.
To use the Solution Designer, you must have the correct permission. All roles contain the permission
for the Solution Designer except for the PCI Compliance Audit role and the Search Proxy User role.
For more information, see Chapter 4, “Configuring Roles and Users,” on page 39.
IMPORTANT: To add a content object to a Solution Pack, it must already exist in Sentinel. Content
objects cannot be created in the Solution Designer.
Although you can save a Solution Pack with empty placeholders, you cannot install controls in the
Solution Manager unless all placeholders have been filled with content.
Sentinel Content
The same general procedure is used to add all types of Sentinel content to a Solution Pack. The
Sentinel content palette includes the following:
Actions
Correlation Rule deployments, including their deployment status (enabled or disabled) and
associated Correlation rules, Correlation Actions, and Dynamic Lists
Event Actions
Reports
Filters
Searches
iTRAC workflows, including associated roles
Event enrichment, including map definitions and event metatag configuration
Other associated files added when the Solution Pack is created, such as documentation,
example report PDFs, or sample map files.
Using Placeholders
If the user is not ready to associate content with a control, an empty placeholder can be used instead.
1 Click the Correlation, Event Actions, Actions, Filters, Event Enrichment, iTRAC, or Jasper
Report button in the Content Palette to open the panel for the type of placeholder you want to
add.
2 Drag and drop the placeholder to the appropriate control in the Solution Pack panel.
3 Rename the placeholder, if desired.
1 Click the Correlation, Event Actions, Filters, Event Enrichment, iTRAC, or Jasper Report button
in the Content Palette to open the panel for the type of placeholder you want to add.
2 Drag and drop the appropriate Content Group from the Content Palette to the placeholder in the
Solution Pack panel or select the appropriate Content Group, then click Add Selected Content.
You can set properties for placeholders to indicate whether a placeholder is designed for specific
Sentinel platforms. Placeholders that are designed in newer versions of Sentinel might not be
supported in older versions because of changes in the Sentinel schema. If you try to install a
placeholder on an unsupported Sentinel platform, the install does not proceed and shows an “Out of
date” error.
File Attachments
You can attach a file or files to any node in the hierarchy. The content in the attachment is included in
the Solution Pack. These files can include anything useful for a user who must deploy the Solution
Pack, such as a PDF view of a report, sample map data for event enrichment, or a script for an
Execute Command Correlation Action. These files can be added, deleted, viewed, renamed, or saved
to the local machine.
1 Create a text file with the values you want to add to the Dynamic List. Add each different value
on a separate line.
2 In the Solution Designer, expand the Correlation content, and then select the Dynamic List.
3 Click Add a new attachment in the Attachment panel, and attach the file that you created in
Step 1.
All the list items in the Dynamic List never expire. For more information, see “Configuring
Dynamic Lists” in the Sentinel User Guide.
Description
Allows you to provide a detailed description about the Solution Pack for your users.
Implementation Steps
Lets you add the steps required to implement the content in the target Sentinel system to the
Implementation tab of the Documentation panel. The steps might include instructions for the following
types of implementation actions:
Populating a .csv file that is used by the mapping service for event enrichment.
Scheduling automatic report execution
Enabling auditing on source devices.
Copying an attached script for an Execute Command Correlation Action to the appropriate
location on the correlation engines.
After the content implementation, the content should be tested to verify that it is working as expected.
Testing Steps
Lets you add the steps required to test the content in the target Sentinel system to the Testing tab of
the Documentation panel. The steps can include instructions for the following types of testing
activities:
Synchronizing Content
If you modify the content in the source system, the content in the source system and the content in
the original Solution Pack can be out of synchronization. To synchronize the content, do one of the
following:
For content with no dependencies, drag and drop the content from the Content Palette onto the
control.
The modified content is immediately updated. For example, a report has no dependencies.
When an action uses the Send Email action, this action always appears as Out of Synchronization.
This is expected and does not cause an error.
You can also specify if you want to overwrite an existing control during installation. For example, if
you include a newer version of a White Label Template and want to ensure that this newer version is
automatically installed with a new install of solution pack, you can enable the overwrite properties.
1 In the Solution Designer, select the control that you want to mark as required.
2 Right-click the control and select Properties.
3 (Conditional) Select Required if you want to ensure that this control is also installed while
installing any specific control from a solution pack.
4 (Conditional) Select Enable Overwrite if you want to automatically install this control with a new
install of solution pack.
5 Click Apply.
To move a node to another branch in the hierarchy, drag and drop a node to its new parent node. A
control can be moved to a new category. A content group can be moved to a new control.
To reorder a node, drag and drop it on top of the node it should appear after in the Solution Pack.
Environment
Sentinel provides an option to monitor and manage active searches and reports on the Sentinel
server for the purpose of resource management. You can view all the searches and reports currently
active on the Sentinel server, determine which long-running searches or reports are no longer
needed, and stop them as necessary.
Sentinel helps you monitor search and report activities and determine whether a search or a report is
not retrieving events as expected or whether a search or a report is retrieving more than the expected
events, which might indicate that the search or the report needs to be tuned. It also helps you
determine if too many searches or reports are running, and helps identify long-running searches and
reports that might slow down the system. Searches and reports that consume a lot of memory are a
potential liability to a healthy system and should be carefully reviewed to ensure that the search query
is specified properly. You can also stop the searches and reports that are no longer needed and
thereby free up system resources.
Sentinel helps you monitor the events per second (EPS) received for processing. You can use this
information to generate reports for auditing purposes, such as verifying license compliance and EPS
trends.
NOTE: To view the EPS rate received by other systems, you need to configure other Sentinel servers
as search targets. For more information, see Chapter 21, “Configuring Data Federation,” on
page 225.
Understanding the operational EPS rate helps you determine whether the EPS rate is as expected
and in compliance with the license. You can also generate reports to analyze the EPS rate over a
specified time period and from specific Sentinel servers in your organization.
The Sentinel Health page provides information such as CPU utilization, processing, queue status,
garbage collection, and so on about various components of Sentinel. The health page enables you to
assess the health of Sentinel and also helps you find out the components that are potentially causing
decrease in the overall Sentinel performance. You can view the Sentinel Health page in Sentinel Main
interface > Storage > Health tab.
The Component information section provides information about the CPU utilization by various
components of Sentinel. The CPU utilization is expressed in the percentage of time. High percentage
of CPU utilization, such as more than 60%, might indicate a potential problem with the processing of
the particular component. You can investigate further to troubleshoot the component and optimize the
Sentinel performance.
The General Information section provides information about the processing of data such as events,
alerts, and audit events, alert creation, queue status, garbage collection, and so on. Certain
components of Sentinel are combined with a queue. While processing the data, each component
stores the incoming data into the corresponding queues. If the particular component is slow or unable
to process the data, the data starts accumulating into the queue and the queue size increases.
Increase in the queue size of a component indicates potential problem with the processing in the
component. Therefore, if the Sentinel performance slows down, you can inspect the queue sizes in
the General Information section to find out the component causing decrease in sentinel performance,
and then troubleshoot the component. For example, if the Events queued for Correlation increases
beyond 70%, it indicates a problem in the correlation rules evaluating the events. You can modify the
correlation rules accordingly.
Availability
You can install Sentinel in an Active-Passive High Availability mode, which allows Sentinel to fail over
to a redundant cluster node in case of hardware or software failure. Consulting and partners can help
you implement Sentinel high availability and disaster recovery. For more information about
configuring Sentinel for High Availability, see “Deploying Sentinel for High Availability” in the Sentinel
Installation and Configuration Guide.
This section provides information about configuring the default alert generation settings to maintain
the stability and optimize performance of Sentinel if large number of alerts are triggered by correlation
rules.
When a correlation rule fires, which is configured to create an alert, the correlation engine generates
the alert and sends it to Sentinel. By default, Sentinel limits the rate of alerts generation in the local or
remote correlation engine to 0.5 alerts per second. To customize the rate of alert generation in the
correlation engine, modify the following parameter in the configuration.properties file:
sentinel.alert.max.ratepersec=.5
If the alert generation rate is increased to more than 0.5 alerts per second, the correlation engine
stores the additional alerts in a queue. The maximum number of alerts that can be stored in the
queue is 10,000. If the number of alerts stored in the queue exceeds the limit, Sentinel starts dropping
the alerts and generates an audit event. Increasing the rate of alert generation might impact the
overall Sentinel performance. You can view the updated queue size information in the Sentinel Main
interface > Storage > Health > General Information section.
To view the audit event, search the query (evt:BufferOverLimit) AND (sres:Alert-Buffer) in
the search interface. After the alerts queue limit is reached, Sentinel generates audit events every ten
minutes. The audit events provide information about the number of alerts dropped after a specific
time interval and the total number of dropped alerts so far. You can customize the frequency of audit
events creation by adding the following parameter in the configuration.properties file:
Sentinel automatically deletes old report to optimize the usage of disk space. Sentinel performs the
auto deletion of reports once per day, the same time the event partitions are processed. You can
define the report retention period as desired. You can also define how many reports should be
deleted at a time and whether the auto deletion should start the first time you start the Sentinel server.
In new installations of Sentinel, the default report retention period is 60 days. In upgrade installations
of Sentinel, the default report retention period is 365 days.
By default, Sentinel generate reports in PDF format. You can also generate reports in CSV format by
making additional configurations to the Sentinel server.
cd /etc/opt/novell/sentinel/config/
vi obj-component.JasperReportingComponent.properties
When you generate a report, it is stored in the CSV format in the directory specified in the
reporting.csv.outputdir attribute.
The Sentinel backup and restore utility is a script that backs up the Sentinel data and also lets you
restore the data at any given point in time. This utility helps you back up only the Sentinel data in
Sentinel server. This utility is not applicable for Collector Manager, Correlation Engine, and operating
system configuration data.
You can use the backup and restore utility in the following scenarios:
System Failure: In this scenario, you must first reinstall Sentinel and then use the
backup_util.sh script with the restore parameter to restore the most recent data that you
backed up.
Data Loss: In this scenario, use the backup_util.sh script with the restore parameter to
restore the most recent data that you had backed up.
Configuration data: Data stored in the config, data, 3rdparty/postgresql, and 3rdparty/
jetty directories, and the data in the Sentinel database. This data includes configuration files,
property files, and keystore files. For traditional storage, it also includes correlation rules and
dynamic lists. The Sentinel database contains various configuration information related to users,
plug-ins, Collectors, Connectors, and filters.
NOTE: The configuration data is critical and you should always include the configuration data in
the backup.
Event data: Dynamic event data and raw event data stored in the data/eventdata and /var/
opt/novell/sentinel/data/rawdata directories. The event data also includes event
associations stored in the /var/opt/novell/sentinel/data/eventdata/
exported_associations directory. The event associations data includes correlated event
association data and the incident event association data.
Secondary storage data: The closed event data files that have been moved to the secondary
storage.
Runtime data: Dynamic file-based queues used by plug-ins, Sentinel Link, and other Sentinel
components. This includes the data in the data/plugindata and the /var/opt/novell/
sentinel/data/sentinel_link.queues directories.
Security Intelligence data: The Security Intelligence data stored in the MongoDB database.
Sentinel logs: Log files generated by Sentinel and stored in the /var/opt/novell/sentinel/
log directory.
NOTE:
If you are using scalable storage, you can back up only the configuration data and Sentinel logs.
You can restore data only on the same version of Sentinel in which the data was backed up because
there might be changes between Sentinel versions, which might make the data incompatible.
Similarly, you can restore data only on the same type of data storage using which the data was
backed up. For example, data that you back up in traditional storage can be restored only in
traditional storage.
Parameters Description
-m restore Restores the specified data. The restore mode of the script is interactive and
allows you to specify the data to be restored from the backup file.
-c Backs up the configuration data. If you are using scalable storage, this
parameter also backs up scalable storage and Kibana configurations. It also
backs up the default event visualizations and dashboards.It does not back up
any custom event visualizations and dashboards. You have to manually export
the custom dashboards and visualizations. For more information, see Managing
Saved Searches, Visualizations, and Dashboards section in Kibana
documentation.
-e Backs up the event data. All event partitions are backed up except the current
online partition. If the backup is being performed with the Sentinel server shut
down, the current online partition is also included in the backup.
-dN Backs up the event data for the specified number of days. The -dN option backs
up the primary storage event data stored for the last N days. Based on the
current data retention policy settings, many days of events might be stored on
the system. Backing up all of the event data might not always be necessary and
might not be desirable. This option allows you to specify how many days to
include when backing up the event data. For example, -d7 includes only the
event data from the last week in the backup. -d0 just includes the data for the
current day. -d1 includes the data from the current day and previous day. -d2
includes the data from the current day and two days ago.
Online backups (that is, backups performed while the system is running) only
back up the closed event partitions, which means partitions one day old or older.
For online backups, a value of -d1 is the appropriate specification for the number
of days.
-u Specifies the user name to use when backing up the event associations data. If
the user name is not specified, "admin" is used as the default value.
This parameter is required only when backing up the event associations data.
-p Specifies the user password when backing up the event associations data.
This parameter is required only when backing up the event associations data.
NOTE: If your environment uses MFA, specify the LDAP user name. For more
information about MFA, see “Multi-factor Authentication” on page 72.
-x Specifies a file name that contains the user password when backing up the event
associations. This is an alternative to the -p option.
This parameter is required only when backing up the event associations data.
-f Enables you to specify the location and name of the backup file.
-l Includes the log files in the backup. By default, the log files are not backed up
unless you specify this option.
-r Includes the runtime data in the backup. Runtime data can only be backed up if
the Sentinel server is shut down, because the data is dynamic. This means that
this parameter can only be used in combination with the -s option (described
below). If -s is not specified, this parameter is ignored.
-b Backs up the NetFlow data collections and the baseline Security Intelligence,
and not the entire MongoDB database. The following baseline data is backed up:
configs
anomalydefs
baselines
baselines.ID.URN
paths.UUID.URN
anomalydeployment
-A Backs up alerts and the events that triggered the alert.
-s Shuts down the Sentinel server before performing the backup. Shutting down the
server is necessary to back up certain dynamic data such as the Runtime data
and the current primary storage partitions. By default, the server is not shut down
before performing the backup. If this option is used, the server restarts
automatically after the backup is complete.
NOTE: If you backed up the data by using the -i or -A options, you must restore the configuration
data along with alerts. Otherwise, if you restore only alerts data, all the alerts show as remote
alerts because the alerts configuration data is not restored.
For more information on the different parameters, see Table 35-1. The following table lists
examples of how to specify the parameters:
backup_util.sh -m Shuts down the Sentinel server and performs a full system backup.
backup -c -e -i -l -r -
w -s -u admin -x
<mypassword.txt> -f /
var/opt/novell/
sentinel/data/
<my_full_backup>.tar.gz
backup_util.sh -m Performs an online backup without shutting down the server. This backup
backup -c -e -i -l -w - includes everything except online event data and dynamic runtime data.
u admin -x
<mypassword.txt> -f /
var/opt/novell/
sentinel/data/
<my_weekly_backup>.tar.
gz
backup_util.sh -m Performs an online backup with event data just from the last week. This
backup -b -c -e -d7 -u backup includes configuration data, the baseline Security Intelligence
admin -x collections, and the event data for the last 7 days. Event data older than 7
<mypassword.txt> -f / days is not backed up because that data can be extracted selectively, if
var/opt/novell/
necessary, from an older backup.
sentinel/data/
<my_weekly_backup>.tar.
gz
backup_util.sh -m Performs a local backup of the configuration data. This is a minimal backup
backup -c -f /var/opt/ of the system without any event data.
novell/sentinel/data/
config_backup.tar.gz
backup_util.sh -m Performs a local backup of the event data. This is a minimal backup of the
backup -e -f /var/opt/ primary storage event data.
novell/sentinel/data/
events_backup.tar.gz
backup_util.sh -m Performs a local backup of the event data from the last 5 days. This is a
backup -e -d5 -f /var/ minimal backup of the primary storage event data from the last five days.
opt/novell/sentinel/
data/
events_5days_backup.tar
.gz
backup_util.sh -m info Displays the backup information for the specified backup file.
-f /var/opt/novell/
sentinel/data/
config_backup.tar.gz
backup_util.sh -m Performs a backup of event data on the machine where the secondary
simple_event_backup -e storage directory is located.
-z /opt/archives/
archive_dir -f /opt/ If the /opt/archives/archive_dir is not located in the server, you
archives/ might need to copy the backup_util.sh script to the machine where the
archive_backup.tar.gz secondary storage is located and then run the simple_event_backup
command from that machine.
Alternatively, you can also use any 3rd party backup tool to backup the
event directories on secondary storage.
3 (Conditional) If you have restored any data, restart the server because the script might make
several modifications to the database.
4 (Conditional) For traditional storage, use the Data Restoration feature to restore the extracted
partitions. For more information, see “Restoring Data” on page 166.
Sentinel clients include Collector Manager and Correlation Engine. You must update Sentinel clients’
configuration when you change the Sentinel server or change the IP address or port number of your
current Sentinel server.
1 Log in as novell user to the Sentinel client computer you want update.
2 Run the following script:
/opt/novell/sentinel/setup/configure.sh
3 Specify the number for the language you want to use for the installation.
The end user license agreement is displayed in the selected language.
4 Press the Spacebar to read through the license agreement.
5 Enter yes or y to accept the license agreement and continue with the installation.
The installation might take a few seconds to load the installation packages and prompt for the
configuration type.
6 When prompted, specify the appropriate option to proceed with the Standard or Custom
configuration.
7 Enter the default Communication Server Hostname or IP Address of the machine on which
Sentinel is installed.
8 Conditional) If you chose Custom configuration, specify the following:
8a Sentinel server communication channel port number.
8b Sentinel Web server port number.
9 When prompted to accept the certificate, run the following command in the Sentinel server to
verify the certificate:
For FIPS mode:
/opt/novell/sentinel/jdk/jre/bin/keytool -list -keystore
/etc/opt/novell/sentinel/config/.activemqkeystore.jks
For Non-FIPS mode:
/opt/novell/sentinel/jdk/jre/bin/keytool -list -keystore
/etc/opt/novell/sentinel/config/nonfips_backup/.activemqkeystore.jks
Compare the certificate output with the Sentinel server certificate displayed in Step 7.
NOTE: If the certificate does not match, the installation stops. Run the installation setup again
and check the certificates.
10 Accept the certificate if the certificate output matches the Sentinel server certificate.
11 Specify credentials of any user in Administrator role.
12 (Conditional) If you chose Custom configuration, enter yes or y to enable FIPS 140-2 mode in
Sentinel and continue with the FIPS configuration.
This section provides information about configuring the default Sentinel settings to optimize the
performance.
mksquashfs.numprocessors=4
You can change the default value as necessary. To customize the grace time period to close a
partition, perform the following steps:
To make changes to the default memory settings, you must create a setmemory.properties file.
The default location of this file is /etc/opt/novell/sentinel/config/setmemory.properties.
You can set the following configuration parameters in the setmemory.properties file:
JAVA_MEM_SERVER: The maximum heap memory (Xmx in MB) allocated to the Java process.
The maximum setting for this parameter is 16384 (or 16 GB). Removing or increasing this limit
can have a detrimental effect on system performance, including a reduced event rate (EPS).
JAVA_MEM_REPORT_PROCESS: The maximum memory allocated to the report processes.
The maximum setting for this parameter is 16384 (or 16 GB). Removing or increasing this limit
can have a detrimental effect on system performance, including a reduced event rate (EPS).
JAVA_MEM_PERMGEN: The maximum permanent generation memory (in MB) allocated to the
process. By default, this value is 10% of the remaining allocated memory for the Sentinel server.
JAVA_MEM_BROKER: The maximum amount of memory allocated for the message bus
broker. This affects how many connections the message bus broker can accept. By default, this
value is 10% of the remaining allocated memory for the Sentinel server.
BROKER_MAX_CON: The maximum number of connections the message bus broker can
accept. By default, this value is 10% of the remaining allocated memory for the Sentinel server.
CORRELATION_INPUT_BUFFER_MAX_SIZE: The memory allocated to hold the Correlation
events. By default, this value is 10% of the remaining allocated memory for the Sentinel server.
On the remote Correlation Engine, this value is 50% of the allocated memory for the Sentinel
server.
When the server starts, these memory settings in the setmemory.properties file override the default
settings.
To limit the number of updates to the correlated event, you can define the maximum number of trigger
events to be associated with the correlated event. The default limit is 100. When the number of trigger
events exceed the defined limit, the correlated event is not further updated with the trigger events.
Sentinel generates the audit event, CorrelatedEventUpdate, to indicate the suppression of further
correlation updates.
To define the maximum number of trigger events to be associated with a correlated event, set the
maxCorrelationEventUpdates property in the /etc/opt/novell/sentinel/config/server.xml
file to the desired value. For more information about modifying the server.xml file, see “Maintaining
Custom Settings in XML Files” on page 302.
To define the number of trigger events you want to view per alert:
Consider an example where you want to customize the tokenExpireTime property in the
AuthenticationService component below, which is present in the server.xml file:
<obj-component id="AuthenticationService">
<class>esecurity.ccs.comp.auth.AuthenticationService</class>
<property name="handler">esecurity.login.request</property>
<property name="maxThreads">100</property>
<property name="tokenExpireTime">86400000</property>
</obj-component>
To ensure that the modifications do not get overwritten during the upgrade, create a file in the /etc/
opt/novell/sentinel/config/ directory with its name in the format: obj-component.<obj-
component id>.properties. In the properties file, set the property to the value you desire in the
format <property name>=<value>.
In the case of the AuthenticationService component, create the file as: obj-
component.AuthenticationService.properties and set the tokenExpireTime property as:
tokenExpireTime=90000000.
To configure the number of user identities you want to view per search:
NOTE: Configuring the refresh interval to less than 3 hours takes up lot of memory and may
result in performance issues.
Sentinel provides the white label report template that is available under the Sentinel Core Solution
Pack. Sentinel uses this template to generate reports. You can customize the template to have your
own header, footer and logo to suit your organization needs.
1 In the Reports and Searches panel, select the Sentinel Core White Label Template report
definition, and then click Export.
2 Save the file to your local computer.
3 Create a new folder.
4 Extract the file contents to the new folder by using any ZIP extraction tool.
5 In the new folder, open the resources folder. In this folder, you can modify the following files:
Header/Footer.jrxml: Contains the report layout descriptions. You can modify the layout of
fields, text, or images in the header and footer, but you must ensure that the overall size of
the header and footer does not change. You can manually edit the XML file or use iReport to
modify them.
Header/Footer*.properties: Contains the text in the layout file, which localized into various
languages. You can modify the strings that appear in the header or footer by editing this file.
Ensure that the new strings do no exceed the space allocated to them. For information
about editing the .properties file, see Oracle Java documentation.
Logo.jpg: Contains the logo that appears in the footer. You can replace this file with
another image. Ensure that the size of the new image is exactly the same size of the
existing image.
6 Use a ZIP tool to re-zip the modified report template.
7 In the Reports and Searches panel, click Import reports or searches, browse to this zip file, and
then click Import.
NOTE: If the folder structure is different than the original ZIP file, the import process displays an
error. Ensure that you do not modify the folder structure after making the changes.
8 Schedule any report definition and view the report to ensure that the changes are applied
correctly.
To reduce the total cost of ownership associated with managing security data from several
organizations where data sharing across them is not allowed, some users prefer to use Sentinel in a
multitenant mode where each organization's data is in a logical silo, preventing one organization from
seeing the data of another. A logical silo, as opposed to a physical silo, allows the same hardware
and software instances to be used to manage the data from multiple organizations while preserving
data privacy. One typical user of this approach are Managed Security Service Providers (MSSPs),
which might use this approach to keep their costs low while providing security monitoring for many
customers. Multiple MSSP models are possible, ranging from Cloud-based services to outsourced
Security Operating Center (SOC) monitoring.
In MSSP environments, the MSSP (Sentinel administrator) administers the Sentinel system and the
MSSP's customers, often referred to as tenants, utilize a portion of the system's processing power to
perform their security monitoring. Each tenant's data is stored alongside other tenant's data, while the
system keeps track of the data that belongs to each tenant and preserves data privacy. Some form of
logical separation is important to ensure that one tenant does not see another tenant's data. Only the
MSSP should have the ability to see the data across all tenants. Sentinel provides multitenancy
capabilities that enable the security monitoring of multiple tenants to be handled by a single instance
of hardware and software while preserving data privacy.
MSSP Setup
Monitoring and
Analyzing
Tenant Setup
Sentinel Data
Server Warehouse
MSSP Setup
Monitoring and
Analyzing
Sentinel
Server Data
Warehouse
Tenant Setup
In an MSSP environment, multiple tenants can deliver data to a single Sentinel instance. Alternatively,
the MSSP can also dedicate a Sentinel instance to each tenant.
Figure 39-3 Full SaaS or Cloud Model
MSSP Setup
Monitoring and
Analyzing
Sentinel
Server Data
Warehouse
Tenant Setup
Creating Tenants
You can create tenants in the Tenants interface and then associate the tenant name to events when
configuring Sentinel for data collection.
To create tenants:
You can also create tenants when configuring the Collector for data collection. For more information,
see “Associating Incoming Events with a Tenant.”
For all other MSSP models, every incoming event should include the tenant name in the TenantName
(rv39) field. This is handled at the Collector level as a Collector property. The implication is that all the
data that passes through a single Collector must belong to a single tenant. If there are multiple
tenants sending data from the same type of event source, you should deploy individual instances of
the appropriate Collector for each tenant to split the data and specify the TenantName in the Collector
parameter. The Collector then adds the TenantName to the event field as specified by the parameter.
The Collector also generates a unique ID for each tenant in the tid (TenantID) field.
You can assign a tenant name to events when configuring the Collector for data collection. Each
tenant must have a dedicated Collector so that their data can be identified with their tenant name. You
can have multiple event sources forward data to one Collector, however, all event sources for the
Collector must be from one tenant.
The tenant information that you add in the Collector sets up a namespace, which you can use to
configure other functions of Sentinel. For example, the identity and host (asset) information that
Sentinel receives is transferred to maps for the mapping Service. In the case of the Identity Manager
Sentinel Driver, you can set the tenant name in the driver parameter. This means that the mapping
service and identity services can function properly even if the same IP addresses or user account
names are present in more than one tenant environment.
For information about mapping, see Chapter 11, “Mapping Events,” on page 129. For information
about Identity Manager Sentinel Driver, see the Driver for Sentinel Implementation guide.
You should define at least one retention policy to segregate event data from different tenants into
different folders for each tenant. When creating retention policies for each tenant, specify the Criteria
as tid:"tenant_ID" where tenant_ID is the ID of the tenant.
Each retention policy creates a separate partition so that you can manage it separately. Sentinel
saves the event file in a folder in the format YYYYMMDD_<Data Retention Policy ID>. Therefore,
with an unique retention policy for each tenant, you can achieve event data segregation on the folder
level.
Flexibility to define data retention parameters for each tenant according to their requirements.
Ensures that each tenant data is physically separated in different folders.
NOTE: The recommendations above apply to parsed event data. Sentinel automatically segregates
raw data if you configured individual Collector instances for each tenant.
For more information about data retention policies, see Chapter 15, “Configuring Data Retention
Policies,” on page 181.
If each tenant has a unique Sentinel instance, you can use standard role definitions and users for the
tenant. For more information, see Chapter 4, “Configuring Roles and Users,” on page 39.
If multiple tenants have access to the same Sentinel instance, it is important to configure the system
to restrict access appropriately. Sentinel provides the ability to define tenants, tenant-specific roles,
and tenant-specific users. When creating roles, you can select the relevant tenant name for the role.
Users in that role can see data and real-time views specific to only the tenant they belong to. You can
assign the default tenant for MSSP employees who need to view multiple tenants' data, which gives
them access to data and real-time views of all the tenants.
You can also delegate the responsibility of administering a tenant's roles and users to the tenant by
assigning the Manage roles and users permission to the tenant. For more information, see
Chapter 4, “Configuring Roles and Users,” on page 39.
Dynamic lists that are global to all tenants. For example, you might want to create a black list of
well-known bad IP address ranges.
Dynamic lists that are specific to particular tenants. For example, a list of important assets or
privileged accounts. In this case, you should create the following:
A separate dynamic list for each tenant
A separate correlation rule for each tenant to refer to the specific dynamic list
A separate action to write to a specific dynamic list
For information about creating dynamic lists, see “Configuring Dynamic Lists” in the Sentinel User
Guide.
WARNING: In any MSSP model where multiple tenants send data to the same Sentinel instance, you
must configure correlation rules correctly to ensure that the TenantID field is populated. This ensures
that automatic tenant filtering applies to keep correlated events and alerts private. If TenantID is not
populated, there is a risk of one tenant seeing another tenant’s data.
For correlation rules that fire based on a single event, append AND tid="Tenant_ID" to the
correlation rule criteria. The correlated event automatically populates the TenantID field in the
correlated event output.
For correlation rules that fire based on multiple events, gate rules, and sequence rules, append
AND tid="Tenant_ID" to the rule criteria. Set the TenantID field to the ID of the tenant in the
correlated event output.
You can use tenant-specific (for example, “Tenant A Critical Servers”) or cross-tenant (MSSP)
dynamic lists.
You can use a tenant-specific action (for example, “Send email to Tenant A”) or an MSSP action
(for example, “Send email to MSSP analyst”).
For rules that fire based on a single event, you do not need to filter by tenant. The correlated
event automatically populates the TenantID field based on the trigger event.
For rules that fire based on multiple events, gate rules, and sequence rules, you do not need to
filter by tenant. You should group by the TenantID field. The correlated event automatically
populates the TenantID field.
You can add a filter that includes multiple tenants if the rule should only be run for a subset of
tenants.
Use only cross-tenant (MSSP) dynamic lists. For example, Known Bad Source IPs.
Use only cross-tenant (MSSP) actions. For example, Send email to MSSP analyst.
Guidelines for Multiple Tenants and Are Visible Only to the MSSP
The following guidelines apply if you want to create a correlation rule that runs across all tenants and
creates output that is viewable only by the MSSP (Sentinel Administrator).
For rules that fire based on a single or multiple events, gate rules, and sequence rules, you do
not need to filter by tenant. You do not need to group by the TenantName field since you want the
rule to run across tenants. Set the TenantName field to default in the correlated event output to
ensure only the MSSP users will see the events and alerts.
You can add a filter that includes multiple tenants if the rule should be run only across a subset of
tenants.
Use only cross-tenant (MSSP) dynamic lists. For example, Known Bad Source IPs.
Use only cross-tenant (MSSP) actions. For example, Send email to MSSP analyst.
For more information about creating correlation rules, see “Correlating Event Data” in the Sentinel
User Guide.
For more information, see the specific chapters in the Sentinel User Guide.
Decommissioning Tenants
If a tenant's contract ends, you can restrict tenant access to the Sentinel server by disabling the
tenant. When you disable a tenant:
All users associated with that tenant can no longer access the Sentinel server or use any of the
REST APIs.
Data collection continues until the tenant stops sending data or until you have disabled the
relevant data collection nodes.
MSSP users associated with the default tenant will no longer see the disabled tenant in
Sentinel functions where they could choose a tenant. For example, when creating real-time
views or setting the tenancy for a role.
You can still see the disabled tenant in the Tenants interface and when you select Show
disabled.
You cannot delete tenants because MSSP employees may want to run reports for a disabled tenant
or verify whether they are still receiving events from a disabled tenant.
To disable a tenant:
This appendix provides information about managing some of the Sentinel activities by using the
command line and troubleshooting instructions.
Appendix 317
318 Appendix
A Command Line Utilities
A
The command line utilities included with Sentinel are useful for managing and configuring many lower
level functions of the system.
The utility has the following options to manage the Sentinel services:
rcsentinel try-restart: Restarts the Sentinel service if the Sentinel service is running.
rcsentinel force-reload: Forces the Sentinel service to reload the Sentinel configuration.
rcsentinel -h, --help: Displays all options for the rcsentinel utility.
Sentinel Scripts
Sentinel provides operational scripts that are appropriate for use during normal operations. These
scripts are located in the following directories:
/opt/novell/sentinel/bin
/opt/novell/sentinel/setup
For most scripts that require arguments, running the scripts without arguments provides details about
how to use the arguments.
backup_util.sh Use this script to back up and restore Sentinel event data and
configuration data. For more information, see Chapter 35, “Backing Up
and Restoring Data,” on page 289.
data_uploader.sh Use this script to upload event and raw data from traditional storage to
scalable storage. You can also use this tool to upload Sentinel data in
various formats such as JSON and CEF. For more information, see
“Migrating Data to Scalable Storage” in the Sentinel Installation and
Configuration Guide.
db.sh Allows you to manage the PostgreSQL database without Sentinel running.
For more information, see “Managing the Internal Database” on page 324.
clean_db.sh Allows you to clean up data from the PostgreSQL database without
Sentinel running. For more information, see “Cleaning Up the Internal
Database” on page 325.
softwarekey.sh Use this script to add and view a license key through the command line.
event_assoc_data.sh Use this script to import or export the event association data. For more
information, see “Importing or Exporting Event Association Data” on
page 322
server.sh Use this script to manually manage the Sentinel server with this script. For
more information, see “Managing the Sentinel Server” on page 326.
report_dev_setup.sh Use this utility to set up the report development environment. For more
information, see “Running the Report Development Utility” on page 321.
updateServerLocale.sh This utility provides an option to change the language of Sentinel server
process. The Sentinel server messages that are displayed on the user
interface appear in the language selected by this script.
If the appliance language is changed through WebYaST, you can use this
script to change the language of the Sentinel process in the server.
versionreader.sh Displays the version of the .jar files for Sentinel. For more information,
see “Getting the .jar Version Information” on page 322.
configure.sh This utility runs on a remote Correlation Engine or Collector Manager if your
change the hostname of the Sentinel server. For more information, see
“Changing the Hostname of a Sentinel Server” on page 322.
ldap_auth_config.sh This utility helps you configure Sentinel to receive LDAP authentications. For
more information, see “LDAP Authentication Against a Single LDAP Server Or
Domain” on page 49.
Opens the PostgreSQL database port so that other systems can connect to the database.
Updates the firewall to allow connection on the PostgreSQL database port.
Modifies the database configuration files (postgresql.conf and pg_hba) so that other
applications can connect to the database. The database configuration files are located at /var/
opt/novell/sentinel/3rdparty/postgresql/data.
Changes the rptuser password, if necessary, and saves it in an encoded format in the obj-
component.JasperReportingComponent.properties file. This password can also be
changed in the database.
Collects the required Sentinel jar files, xml files, and the keystore file for report development and
creates a tar file sentineljarsforireport.tar file in the /opt/novell/sentinel/bin
directory.
cd /opt/novell/sentinel/bin/
./report_dev_setup.sh
A warning message is displayed, indicating that the Sentinel server will be restarted after the
script is executed.
4 To continue running the script, press 1.
5 Specify the root password when prompted.
The script opens the database port, updates the firewall configuration files, and modifies the
configuration files and database files.
./report_dev_setup.sh -h
The configure.sh file also allows you to change the password of the appuser. The appuser is an
internal Sentinel identity that is used to establish a connection and interact with the PostgreSQL
database.
Incident events: There is a record in the database for every event that is associated with an incident,
including what partition the event came from. When a partition is deleted, all incident events records
for the partition are exported to a file on the file system, and the records are then deleted from the
database. The file name is incidents_events.json.
When you export event association data, it is saved to the files in the following default directory
structure /var/opt/novell/sentinel/data/eventdata/exported_associations/<partition
name>/*.json
When a partition is restored from backup, the system automatically attempts to import the event
association records for the partition. The .json file must be restored to the correct directory structure
when the event association records are restored. If these files are not restored, the event association
records are not imported, but the partitions are restored without this information. The event
association records for the partitions are not available.
You can use the following options with for the event_assoc_data.sh file:
-i, --import: Imports event association data. This option works only on partitions that are currently in
the restored state, but have not yet imported the event association data.
-x, --export: Exports event association data. This option works only on partitions that are currently in
the deleted state, but have not exported their event association data.
-s, --startdate=<date>: Specify a start date and end date to select partitions in the specified date
range.
-e, --enddate=<date>: Specify an end date and start date to select partitions in the specified date
range.
--date=<date>: The utility selects the partitions with the specified date. You can use this option
multiple times to select multiple dates.
-u, --user=<user name>: Specify the name of the user with administrative privileges to the Sentinel
server.
--host=<host name>: Specify the host name or IP address of the Sentinel server.
--port=<port>: Specify the port number for communication to the Sentinel server. If this option isn’t
specified, the default port of 8443 (HTTPS) or 8000 (HTTP) is used.
-l, --log file=FILE: Logs messages from the utility to the file name specified in the parameter.
The script db.sh is located in the /opt/novell/sentinel/bin directory. The script has commands
and options. You must be logged in as the user that installed Sentinel for the script to work. The
command must come first, followed by the option.
This command writes the status of the internal database to the log file named sentinel_status.txt.
Commands
You can use the following commands with the db.sh script.
start: Starts the internal database without starting the Sentinel server.
force_stop: Forces the database to stop when the Sentinel service is still running.
sql <db name> <user name> <sql statement>: Allows you to send SQL commands to the internal
database.
force_restart: Forces the database to restart when the Sentinel service is still running.
Options
You can use the following options with the db.sh script. The options must start with a - or -- to be
executed.
-w, --wait=<seconds>: Allows you to specify the amount of time to wait for the database to start or
stop.
WARNING: Because this script is designed to delete information from your database, it should be
used carefully and only after understanding the implications.
Prerequisites
Ensure that you have permission to run the script. Only the user who installed Sentinel has
permission to run this script.
Ensure that the database is started and is running.
3 At the prompt, indicate which objects you want to remove from the database.
4 Specify the following information to connect to the PostgreSQL database:
The database connection is verified before proceeding to the next step. If the connection was not
successful, the script exits.
101
NOTE: If you have a distributed Sentinel install, you might need to manually connect to the main
Sentinel server to delete the identityAccountMap.csv file.
Commands
You can use the following commands with the server.sh script:
-p, --priority=<integer>: Specifies the process priority for the Sentinel server.
This section helps you troubleshoot issues that might occur when using Sentinel.
“Collector Manager Logs Display the Copying back to Persist Queue Error” on page 329
“Event Visualization Dashboards Take a Longer Time to Load Data” on page 330
“Unable to View Alerts in the Dashboard and Alert Views” on page 330
“Unable to Connect to Sentinel Agent Manager Database” on page 330
“Customizing Logging Settings in Sentinel” on page 331
“Customizing Logging Settings in Elasticsearch” on page 331
“Sentinel Control Center Does Not Launch When Identity Manager Designer is Installed on the
Client Computer” on page 331
“Error While Installing Correlation Rules” on page 331
“Dashboard and Anomaly Definitions with Identical Names” on page 332
“Sentinel High Availability Installation in FIPS 140-2 Mode Displays an Error” on page 332
“Sentinel Services Might Not Start Automatically After the Installation” on page 332
“Sentinel Does Not Configure the Sentinel Appliance Network Interface By Default” on page 332
“New Incoming Alerts Incorrectly Appear to be Selected When You Modify Existing Alerts” on
page 333
“Security Intelligence Database and Alert Dashboard Occasionally Do Not Work in Upgraded
Custom Installations of FIPS 140-2 Enabled Sentinel” on page 333
“Error When Configuring the NFS Storage After Upgrading Sentinel Appliance to Version 7.3
SP1 and Later” on page 334
“Cannot Receive Events from Secure Configuration Manager After Upgrading Sentinel to
Version 7.3 SP1 and Later” on page 334
“Cannot Receive Events from Sentinel UNIX Agent 7.4 After Upgrading Sentinel to Version 7.3
SP1 and Later” on page 335
“Cannot Create Reports by Using Sentinel SDK” on page 335
“Data Synchronization Fails While Synchronizing IPv6 Addresses in Human Readable Format”
on page 335
|SEVERE|I/O dispatcher
21|esecurity.ccs.comp.event.visualization.EventVisualizationProcessor$3.onFailure
Failed to forward <number> events in this batch, copying back to persist queue
As a result, Collector Manager starts buffering events and eventually may result in memory dump
issue on the Collector Manager.
Troubleshooting 329
Fix: Perform any of the following:
rcsentinel stop
/opt/novell/sentinel/3rdparty/mongoconnector
rm config.txt
rcsentinel start
The alert index is rebuilt. The alert dashboard and the charts in the alert view display all the alerts.
330 Troubleshooting
Login failed. The login is from an untrusted domain and cannot be used with Windows
authentication.
Fix: Update the SQL connection security settings in the Agent Manager. For more information, see
“Updating Security Settings for SQL Connection” in the Sentinel Agent Manager User Guide.
You can customize the logging settings as necessary in the respective files:
For information about configuring logging settings, see the documentation embedded in the
respective files.
To customize logging settings in third-party components such as ActiveMQ, Jetty, and PostgreSQL,
see the documentation for the respective components.
NOTE: Changing the log levels to ALL or FINEST results in verbose logs and may slow down the
system performance.
Troubleshooting 331
Dashboard and Anomaly Definitions with Identical
Names
Issue: When a Security Intelligence dashboard and an anomaly definition have identical names, the
dashboard link is disabled on the Anomaly Details page.
Workaround: Ensure you use unique names when creating dashboards and anomaly definitions.
Workaround: The error is expected and you can safely ignore it. Although the installer displays the
error, the Sentinel High Availability configuration works successfully in FIPS 140-2 mode.
Workaround: As a one-time activity, start the Sentinel services manually by specifying the following
command:
rcsentinel start
332 Troubleshooting
New Incoming Alerts Incorrectly Appear to be
Selected When You Modify Existing Alerts
Issue: When you click Select All in alerts views to select alerts, deselect few alerts, and modify them,
new incoming alerts are also selected in the refreshed alert views. This results in wrong count of
alerts selected for modification, and also it appears as if you are modifying new incoming alerts too.
However, only the originally selected alerts are modified.
Workaround: No new alerts will appear in the alert view if you create the alert view with a custom
time range.
If any of the above mentioned three services are not running, perform the following steps.
3 Run the following command to stop Sentinel:
rcsentinel stop
4 Log in to the Sentinel server as the novell user.
5 Run the following command:
<custom installation directory>/opt/novell/sentinel/bin/si_db.sh startnoauth
6 Run the following commands to add dbauser and appuser users:
cd <custom installation directory>/opt/novell/sentinel/3rdparty/mongodb/bin
./mongo
use admin
db.addUser ("dbauser", "novell")
use analytics
db.addUser ("appuser", "novell")
exit
7 Stop the MongoDB database:
<custom installation directory>/opt/novell/sentinel/bin/si_db.sh stop
Troubleshooting 333
8 Perform the following steps to add encrypted password fields:
8a Run the following command to get the encrypted password for the novell user:
<custom installation directory>/opt/novell/sentinel/bin/encryptpwd -e
novell
Encrypted password is displayed. For example:
bVWOzu6okMmMCkgM0aHeQ==
8b In the configuration.properties file, update the baselining.sidb.password and
baselining.sidb.dbpassword properties with the encryptedpassword. for example:
baselining.sidb.password=9bVWOzu6okMmMCkgM0aHeQ==
baselining.sidb.dbpassword=9bVWOzu6okMmMCkgM0aHeQ==
9 Exit from the novell user account and start Sentinel as the root user using the following
command:
rcsentinel start
NOTE: Run the configure.sh script to reset the password whenever needed. For more information
about running the configure.sh script, see “Modifying the Configuration after Installation” in the
Sentinel Installation and Configuration Guide.
Workaround: After upgrading the Sentinel appliance, restart the SLES operating system using the
following command:
init 6
Workaround: Upgrade Secure Configuration Manager to version 6.1. For more information, see the
Secure Configuration Manager 6.1 Release Notes.
334 Troubleshooting
Cannot Receive Events from Sentinel UNIX Agent 7.4
After Upgrading Sentinel to Version 7.3 SP1 and Later
Issue: The security vulnerability fixes included in Sentinel 7.3 SP1 involved changes to the
communication mechanism for a secured connection. These changes are not compatible with
Sentinel UNIX Agent 7.4. Therefore, Sentinel cannot receive events from Sentinel UNIX Agent 7.4.
Workaround: To create reports by using Sentinel SDK, perform the steps mentioned in
Knowledgebase Article 7017293.
Workaround: To fix this issue, manually change the maximum size of the IP address fields to at least
46 characters in the target database, and re-synchronize the database.
Troubleshooting 335
336 Troubleshooting