2.2 Best Practices

Use the following best practices to secure your Sentinel Log Manager server:

2.2.1 Changing Passwords

Operating System Users

Server Installation

The Sentinel Log Manager server installation creates a novell system user and novell group that owns the installed files within the install_directory. The user’s home directory is set to /home/novell. By default, if a new user is created, the password for the user is not set in order to maximize security. If you want to log in to the system as the novell user, you must set a password for the user after installation.

Collector Manager Installation

System users might vary in their level of security depending on the operating system on which the Collector Manager is installed.

Linux: The installer prompts you to specify the name of the system user who owns the installed files, as well as the location to create its home directory. By default, the system user is esecadm; however, you can change this system username. If the user does not exist, it is created along with its home directory. By default, if a new user is created, the password for the user is not set in order to maximize security. If you want to log in to the system as the user, you must set a password for the user after installation. The default group is esec.

During the client installation, if the user already exists, the installer does not prompt for the user again. This behavior is similar to the behavior while installing or uninstalling software. However, you can have the installer prompt for the user again:

  1. Delete the user and group created at the time of first installation.

  2. Clear the ESEC_USER environment variables from the /etc/profile file.

Windows: No users are created.

The password policies for system users are defined by the operating system that is being used.

Application and Database Users

Sentinel Log Manager application users are native database users and their passwords are protected by the native database platform, unless LDAP authentication is used. 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.

The admin user is the administrator user for Sentinel Log Manager user applications.

By default, the following database users are created during installation:

  • dbauser: The dbauser is created as a superuser who can manage the database and is typically the user who can log in to the pgAdmin. The password for the dbauser is accepted at the time of installation. This password is stored in the user home directory/.pgpass file. The system follows the PostgreSQL database password policies.

  • appuser: The appuser is the non-superuser used by Sentinel Log Manager to connect to the database. By default, the appuser uses a password randomly generated during installation, which is stored encrypted in the /etc/opt/novell/sentinel_log_mgr/config/server.xml file. To modify the password for appuser, in the database use the following command:

    db.sh sql SIEM dbauser "ALTER ROLE appuser WITH password 'new_password’”
    

    Update the server.xml file by using the using the /opt/novell/sentinel_log_mgr/bin/dbconfig utility.

For more information, see Command Line Utilities.

NOTE:There is also a PostgreSQL database user that owns the entire database, including system database tables. By default, the postgres database user is set to NOLOGIN, so that no one can log in as the PostgreSQL user.

2.2.2 Securing Communication with Collector Managers and Event Sources

You can configure Sentinel Log Manager 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 on the possible security features that can be enabled, see the Sentinel Plug-ins Web site

2.2.3 Auditing Sentinel

Sentinel Log Manager generates audit events for many actions performed by users and also for actions performed internally for system activities. These events are tagged with the SentinelLogManager tag and can be included within a report by selecting include system events and search by using the rv145:SentinelLogManager query. However, you must have the necessary permissions to view system events. For more information, see Section 10.1.2, Filtering Data.

Sentinel Log Manager includes reports that are pre-configured to include only the events tagged with the SentinelLogManager tag.

A well-audited Sentinel Log Manager not only audits the events occurring within Sentinel Log Manager, but also the infrastructure that Sentinel Log Manager is running on top of. You can set up data collection from the machines and the devices that make up the Sentinel Log Manager infrastructure and tag them with the SentinelLogManager tag to enable a complete auditing of the systems that can affect the behavior of Sentinel Log Manager.

2.2.4 Determining if Raw Data Files Were Tampered With

The raw data files are stored in one of the following locations:

  • Local storage location: <SLM data directory>/rawdata/online

  • Networked storage location: <SLM networked storage directory>/rawdata_archive

If your networked storage is NFS or CIFS, then the NFS/CIFS share is automatically mounted to the /var/opt/novell/sentinel_log_mgr/data/archive_remote directory on the Sentinel Log Manager server. If the networked storage is SAN, then the NFS/CIFS share is mounted to the directory configured by you.

Each raw data file is either a .zip file or a .log file. A .zip file contains the.log files in a compressed format. For more information on raw data files, see Section 3.1.1, Raw Data.

You can check the integrity of raw data files present in local or networked storage by using the Collection > Raw Data UI.

To determine if the deleted raw data files were tampered with:

  • Verify the sequence number of JSON records. All JSON records have 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, then its ChainSequence begins with zero.If there are gaps in the sequence of numbers, then the records were either tampered with 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 with.

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

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.zip';"

However, there is a possibility that a person tampered with 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 with, there is another method by using the hash key values of each raw data file stored in the database. The Sentinel Log Manager calculates a hash key value for every raw data file and stores it in the RAW_DATA_FILES_INFO table 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 local storage location or the networked storage location.If the value is ARCHIVED, the raw data file is in the networked storage location.If the value is ONLINE or COMPRESSED, then, the raw data file is in the local storage location.If the value is DELETED, it indicates that the file is deleted from the disk and is not present either in local or in networked storage location.

  • FILE_HASH: Hash value is computed after the file is compressed and placed in a .zip file. Therefore, only files in the COMPRESSED or ARCHIVED state have a hash value.The FILE_HASH column contains an SHA256 hash key value computed over the contents of the file.The file is treated as a stream of binary bytes in order to compute the hash.The hash is stored as a HEX string (lowercase).

To determine if a file is tampered with, compute the SHA256 hash, convert it to a HEX string (lowercase), then compare this computed value with the hash value stored in the RAW_DATA_FILES_INFO table.If the values are different, it indicates that either the file or the database has been tampered with.

To determine if the files were deleted in an unauthorized way, you can scan the records in the RAW_DATA_FILES_INFO table 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 networked storage location.If the STATE value is ONLINE or COMPRESSED, the raw data file should be in the local storage location or the networked storage location.

2.2.5 Using CA Signed Certificates

Novell Sentinel Log Manager uses several digital, public-key certificates as part of establishing secure TLS/SSL communications. During the initial configuration of Sentinel Log Manager, 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 the country.

This section provides information on various certificates used in Sentinel Log Manager and also provides instructions on configuring the TLS/SSL certificates to get them digitally signed by CA and then importing the digitally signed certificates into Sentinel Log Manager:

Types of Certificates

Web Server Certificate

The Web server certificate is used for the following purposes:

  • It is used with Web browsers to connect to the Sentinel Log Manager Web user interface.

  • It is used to establish trust relationships for the REST API calls between Sentinel Log Manager 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 Log Manager Web user interface, the Connection is Untrusted message is displayed.

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 Log Manager, including the Sentinel Log Manager server and remote Collector Managers.

Client Proxy Server Certificate

The Client Proxy Server certificate is used to establish secure communication between the Sentinel Log Manager server and client applications, including the Web user interface.

Configuring the TLS/SSL Certificates

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

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

The tool can be run 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 will be presented to the CA. To generate one or more Certificate Signing Request, perform the following steps on the Sentinel Log Manager 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 command.

    The following options are displayed:

    1. Generate certificate signing requests
    2. Import Certificate Authority root certificate
    3. Import certificates signed by Certificate Authority
    4. Exit
    
  4. Enter 1.

    The following options are displayed:

    1. Web Server
    
    2. Java Messaging Service
    
    3. Client Proxy Service
    
    4. All
    
    5. Done
    
  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 required, or enter 5 to select Done to exit from the service option.

  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 Log Manager

Copy the files that contains the digital certificates signed by the CA to the Sentinel Log Manager server. In cases where 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 Log Manager server.

To import the certificate files to the Sentinel Log Manager 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 command.

    The following options are displayed:

    1. Generate certificate signing requests
    2. Import Certificate Authority root certificate
    3. Import certificates signed by Certificate Authority
    4. Exit
    
  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.

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

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

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

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

  8. Restart Sentinel Log Manager.