3.3 Best Practices

Use the following best practices to secure your Sentinel server:

3.3.1 Changing Passwords

To increase security, you can change the passwords of the system users created during the installation of Sentinel. There are two different types of users:

Administration Users

The admin user is the administrator user for Sentinel applications. You can use the administrator credentials to log in to the Sentinel Web interface. The password is set during the installation process.

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.

Application and Database Users

Sentinel application users are native database users and their passwords are protected by the native database platform, unless you have configured LDAP authentication. These users have only read access to certain tables in the database so that they can execute queries against the database. Users authenticated by LDAP do not have read access on the database.

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 Section A.0, Command Line Utilities. 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.

3.3.2 Changing Collector Manager or Correlation Engine User Credentials

The ActiveMQ user credentials for the Collector Manager and the Correlation Engine are stored in the /<install_dir>/etc/opt/novell/sentinel/config/activemqusers.properties file located in the Sentinel server. You can add additional ActiveMQ users or change the password for the existing users by modifying the activemqusers.properties file. For more information, see Adding a Custom ActiveMQ User for the Collector Manager or Correlation Engine in the NetIQ Sentinel Installation and Configuration Guide.

If you modify the password for an existing ActiveMQ user or create a new user by modifying the activemqusers.properties file in the Sentinel server, you must copy the same changes to all of the remote Collector Managers and Correlation Engines and then restart the services. Otherwise, the Collector Manager and the Correlation Engine would not be able to connect to the Sentinel server.

3.3.3 Enforcing Password Policies for Users

To achieve robust password policy enforcement in Sentinel, use Sentinel's built-in password complexity policy enforcement capability. For more information about configuring password complexity, see Section 4.3, Configuring Password Complexity.

You can also use an LDAP directory to authenticate Web application users. To enable this option by using the Sentinel Web interface, see Section 5.0, Configuring LDAP Authentication. This option has no effect on accounts used by back-end services, which continue to authenticate through PostgreSQL.

3.3.4 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.

3.3.5 Securing Communication with Secondary Storage

You must consider the security implications before deciding the type of secondary storage location to use. If you are using CIFS or NFS servers as secondary storage locations to store the Sentinel event data and raw data, remember that these protocols do not offer data encryption. An alternative is to use direct attached storage (Primary, formerly known as local or SAN), which does not have the same security vulnerabilities. If you choose to use CIFS or NFS, it is important to configure the CIFS or NFS server to maximize the security of your data.

For more information about configuring the secondary storage location server settings, see Section 6.2, Configuring Secondary Storage Locations.

3.3.6 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 Section 4.0, Configuring Roles and Users.

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.

3.3.7 Determining if Data was Tampered

There are two approaches to verify that the event was not tampered while in storage.

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.

The hash is computed as follows:

  1. In the event partition, the data in the following files are concatenated in the following order:

    1. index.sqfs

    2. 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.

To verify whether the event data was tampered:

  1. Determine the partition the event is stored in:

    1. Export the event of interest to a CSV file and including the RetentionPolicyID (rv171) field in the export.

    2. Note down the value in the RetentionPolicyID (rv171) field. It is a unique ID of the retention policy under which the event is stored.

    3. Find the exact partition by executing database queries by running the following command as the novell user on the Sentinel server:

      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>'"
      

      where <retention_policy_ID> is the value in the RetentionPolicyID (rv171) field determined in Step 1.b.

    4. 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:

    db.sh sql SIEM dbauser "select name, hash, state from IXLOG_PART where name='<partition_name>'"
    

    where <partition_name> is the name of the partition

    The hash value is in base64 format. You need to convert the hash value to hexadecimal to compare it with the value returned by sha256sum.

  3. Convert the hash value found into hexadecimal.

    echo "<hash>" | base64 -d - | hexdump -e '/1 "%02x" '
    

    For example,

    echo "lUrp+hejhDbyb59ZRpoQ88vpA8eiZfI2ySVCibMoDXo=" | base64 -d - |
    hexdump -e '/1 "%02x" '
    
  4. Calculate the hash of an event partition by executing the following command in the partitiondirectory.

    cat index.sqfs events.evt/* | sha256sum
    
  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.

Raw Data Approach

The raw data approach involves finding the raw data associated with the normalized event and proving the raw data has not been tampered.

Sentinel stores the raw data files in one of the following locations:

  • Primary storage location: <Sentinel data directory>/rawdata/online

  • Secondary storage location: <Sentinel secondary storage directory>/rawdata_archive

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.

Each raw data file is a .gz compressed file. For more information about raw data files, see Section 6.1.1, Raw Data.

To identify the raw data associated with the normalized event:

  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 Web interface, click Storage > 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.

  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.

To determine if the deleted raw data files were tampered:

  • 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:

db.sh sql SIEM dbauser "select FILE_HASH from RAW_DATA_FILES_INFO where FILE_NAME='/F6673C60-573A-102D-ADE0-003048306A7C/2010-06/15-1600.gz';"

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.

The table has the following columns:

  • FILE_NAME: This column contains the relative file name in the following format:

    <Event Source UUID>/<Date>/<RawDataFile>

  • STATE: This column indicates if the raw data file is in the primary storage location or the secondary storage location. If the value is ARCHIVED, the raw data file is in the secondary storage location. If the value is ONLINE or COMPRESSED, the raw data file is in the primary storage location. If the value is DELETED, it indicates that the file is deleted from the disk and was not present either in primary or in secondary storage location.

  • FILE_HASH: The hash value is computed when the files are closed for writing. Therefore, only files in the COMPRESSED or ARCHIVED state have a hash value.The FILE_HASH column contains a SHA256 hash key value computed over the contents of the file. The file is treated as a stream of binary bytes to compute the hash. The hash is stored as a HEX string (lowercase).

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.

3.3.8 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

The Web server certificate is used for the following purposes:

  • With Web browsers to connect to the Sentinel Web user interface.

  • Establish trust relationships for the REST API calls between Sentinel instances. For example, it is used when configuring Distributed Search.

If the Web server certificate is not signed by a well-known CA and you connect to the Sentinel Web user interface, Sentinel displays the Connection is Untrusted message.

Java Messaging Service Certificates

The Java Messaging Service (JMS) certificates include the following:

  • 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.

SSL Proxy Server Certificate

The Client Proxy Server certificate is used to establish secure communication between the Sentinel server and client applications, such as the Sentinel Control Center or the Solution Designer. This certificate is not used with the Sentinel Web interface.

Configuring the TLS/SSL Certificates

Sentinel provides the ssl_certs command line tool that helps with the certificate signing process. This tool is available at:

<installation_root>/opt/novell/sentinel/setup/ssl_certs

You can run the tool in an interactive mode or with the command line specifications and options. To see the command line options, change to the directory that contains ssl_certs, then run the -help command.

Configuring the TLS/SSL certificates involves the following steps:

Generating a Certificate Signing Request

To obtain a digitally signed certificate, you must first generate a certificate signing request, which is presented to the CA. To generate one or more certificate signing requests, perform the following steps on the Sentinel server:

  1. Log in as the novell user, or switch to the novell user.

  2. Change to the setup directory:

    cd $APP_HOME/setup
    
  3. Run the ./ssl_certs script.

  4. Enter 1 to generate certificate signing requests.

  5. Specify the service for which you want to obtain the signed certificates.

  6. Specify a filename where the certificate signing request must be saved.

    The default filename is based on the internal name of the certificate entry.

  7. Select another service if necessary, or enter 5 to exit from the service options.

  8. Enter 4 to exit from the TLS/SSL certificate configuration.

The certificate signing requests are now saved in the specified files.

Getting the Certificate Signing Requests Signed by the CA
  1. Submit the certificate signing requests to the CA for signature.

  2. Obtain the signed certificate files from the CA.

The details of how this is done depend on the CA. For more information, consult your CA.

Importing the Digitally Signed Certificates into Sentinel

Copy the files that contains the digital certificates signed by the CA to the Sentinel server. If the files are signed by an enterprise or organizational CA rather than a well-known CA, you must copy the CA's self-signed root certificate to the Sentinel server.

To import the certificate files to the Sentinel server:

  1. Log in as the novell user, or switch to novell user.

  2. Change to the setup directory:

    cd $APP_HOME/setup
    
  3. Run the .ssl/certs command.

  4. (Conditional) For certificates that are signed by the enterprise or organizational CAs, enter 2, then specify the name of the file that contains the CA root certificates.

  5. (Conditional) For certificates that are signed by a well-known CA such as Verisign or Entrust, enter 3.

  6. Select the service for which you obtained the signed certificates.

  7. Specify the name of the file that contains the CA’s signed digital certificate.

  8. Select another service if necessary, or enter 5 to select Done and exit from the service option.

  9. Enter 4 to exit from the TLS/SSL certificate configuration.

  10. Restart Sentinel.

Using a Signed Certificate on Distributed Components

There can be conflicts with the certificates on the distributed components: remote Collector Manager, remote NetFlow Collector Manager, and remote Correlation Engine, depending on the order you installed these components and generated certificates. A common cause of conflicts occurs if you installed the components in the following order:

  1. Installed the Sentinel server.

  2. Installed a Remote Collector Manager, NetFlow Collector Manager, or a Correlation Engine.

  3. You obtained and imported a digitally signed certificate into the Sentinel server first.

If you do things in this order, the certificates on the distributed components do not match the certificates on the Sentinel server. This causes errors when trying to access the Sentinel Web interface and other Sentinel services.

To fix this issue you must import the digitally signed certificate into the distributed components.