Prepare to Upgrade NetWitness Platform

Complete the following tasks to prepare for the upgrade to NetWitness Platform 12.3.1.0.

Warning: The Dell S4 and S4s appliances reached the End of Life (EOL) in June 2021. We recommend that you discontinue installation or upgrade activities on these and upgrade to new hardware.
For more information on End of Life hardware support, see https://community.netwitness.com/t5/product-life-cycle/product-version-life-cycle-for-rsa-netwitnessplatform/ta-p/569875.

Task 1 (Optional). Remove Legacy Package Repositories

You can free up the disk space by removing obsolete repositories from previous releases.

To remove the obsolete repositories:

  1. Determine the version of the oldest NetWitness Platform host in your environment by using the NetWitness Repo tool. Do the following:

  • SSH to the Admin Server as a root user.

  • Run the following command.

    nw-repo-tool --list-obsolete

    After running this command, you will get a list of all the obsolete repositories.

  1. Run the following command to remove all the obsolete repositories.

    nw-repo-tool --purge-obsolete

Note: Alternatively, you can safely remove all legacy package repository folders located at /var/netwitness/common/repo/<version> on the NW Server for all versions prior to the baseline major release version of the oldest active host in the environment. If the oldest host version is 11.7.x.x, you can safely remove 11.0.x.x, 11.1.x.x, 11.2.x.x, 11.3.x.x, 11.4.x.x, 11.5.x.x, and 11.6.x.x repository folders. However, do not remove repository versions greater than or equal to 11.7.0.0.

Task 2. Backup and Remove the Rotated RabbitMQ Logs

Before upgrading from 11.7.x to 12.3.1.0, you must remove the old RabbitMQ logs and free up the space in /var/log mount disk. Follow the below procedure to free up the space in /var/log mount disk.

  1. Backup the rotated RabbitMQ logs into var/netwitness directory. Do the following.

    mkdir /var/netwitness/rabbitmq_logsbkp

    scp -r /var/log/rabbitmq/ /var/netwitness/rabbitmq_logsbkp

  2. Remove the rotated RabbitMQ logs from /var/log/rabbitmq pre-upgrade. Do the following.

    cd /var/log/rabbitmq

    rm -f rabbit\@<sa-uuid>.log.*

    rm -f rabbit\@<sa-uuid>_upgrade.log.*

    rm -f *.gz

    rm -f rabbit@<sa-uuid>.log-*

    Note:
    - This procedure must be performed only once before upgrading to 12.3.1.0. Post-upgrade, the RabbitMQ service automatically handles the log rotation.
    - The command rm -f rabbit\@<sa-uuid>.log.* is used to clean up the old uncompressed logs such as log.1, log.2, and log.3.
    - The command rm -f rabbit\@<sa-uuid>_upgrade.log.* is used to clean up the old uncompressed upgrade logs.
    - The command rm -f *.gz is used to clean up the old compressed logs.
    - The command rm -f rabbit@<sa-uuid>.log-* is used to clean up the old uncompressed logs rotated with logrotate.

Task 3. Prepare ESA Deployments for Migration to 12.3.1.0

Before upgrading to 12.3.1.0, NetWitness recommends that all the ESA deployments maintain an error-free state. You must remove any unused ESA deployments, as ESA deployments will be migrated to policies and groups after upgrading to 12.3.1.0. Each deployment will be converted into a policy and group and will be available to manage only after the upgrade of the Correlation servers to the 12.3.1.x version.

Manage ESA Deployments and Data Sources

In 12.1 and later versions, you can only manage the ESA deployments and Data Sources through Centralized Content Management. Go to ConfigureIcon_12x10.png(CONFIGURE) > Policies > Content > Event Stream Analysis page to manage the ESA deployments and Data Sources. You can only manage the ESA Rules in the ESA Rules page. Refer the following figures.

ESA_DEP_UpG_12.3_2391x592.png

esa_rules_tab_configure_1929x910.png

Make sure that you plan the upgrade process so that Correlation servers are upgraded immediately after the Admin Server is done. The deployments will not be accessible until the corresponding Correlation servers are upgraded. However, the correlation servers will still continue to process the Alerts and Events. You must upgrade the ESA hosts immediately after upgrading the Admin Server.

For more information on Centralized Content Management and managing the deployments, see Centralized Content Management Guide for NetWitness.

IMPORTANT: If there is any need to import ESA Rules and enrichments, NetWitness recommends importing those missing rules and enrichments before the upgrade.

The pre-upgrade and post-upgrade states of deployments are represented in the following table.

 SlNo Pre-upgrade Deployment State Post-upgrade Deployment State
Creates Policy Creates Group The policy will be Published
1 Healthy deployment

Yes

Yes

Yes
2 Deployment with errors Yes Yes Yes
3 Deployment with only rules

Yes

No

No
4 Deployment with no rules No No No

Healthy deployment contains no errors, and the required resources such as ESA Server, Data source, and ESA rules are added.

Note: NetWitness recommends that all the deployments maintain an error-free state. You must remove any unnecessary or unused ESA deployments.

Task 4. Backup Elasticsearch Data (Users, Entities, Alerts, and Indicators)

Before upgrading the UEBA host from 12.0.0.0 and older versions to 12.3.1.0, you must perform the backup of your Elasticsearch data such as Users, Entities, Alerts, and Indicators (using the Elasticsearch migration tool) to retain them post upgrade.

Before you begin 

Make sure the following prerequisites are met:

To backup the Elasticsearch data:

  1. Select the available directory and unzip the ueba_es_migration_tool.zip file.

  2. Go to cd ueba_es_migration_tool. Run the following command.

    sh elk-migration-script.sh

    The Elasticsearch migration tool guide is displayed.

    export_5_5_522x164.png

  3. Select Export documents from elasticsearch 5.5.0 and enter yes when prompted to stop the airflow scheduler.

    Note: When you enter yes, the airflow scheduler stops consuming the fresh incoming data such as Users, Entities, and Alerts. This avoids data loss during the export process.

  4. In the next step, select Fresh Export to export the existing data.

    succeess_export_1844x913.png

    Note:
    - If the Export operation fails due to some technical issue, select Resume Export once the issue is resolved, to resume the Export operation.
    - Go to <backup_directory_path>/log/log/es-migration-export.log if you want to view the log for the succeeded or failed processes.

    Task 5 (Optional). Disable STIG-based FIPS Kernel Controls

    If you enabled STIG-based FIPS Kernel controls, you must disable them before initiating the NetWitness Platform upgrade process to avoid boot errors. To disable STIG-based FIPS Kernel controls, run the following commands:

    manage-stig-controls --disable-control-groups 3 --host-all

    grub2-mkconfig -o /boot/grub2/grub.cfg

    After you upgrade NetWitness Platform, ensure that you enable STIG-based FIPS Kernel controls.

    Note: STIG-based FIPS Kernel controls which require modifications to kernel boot options are not enabled by NetWitness out-of-the-box.

    Task 6 (Optional). Verify Connection for Live Server

    Go to admin/system/live services and do a test connection to verify if you are able to connect to the live server as this is essential for the source-server from 12.x and above. This is an optional step and applicable only for customers who have configured live.

    Task 7. Synchronize Time on Component Hosts with NW Server Host

    Before you upgrade hosts, make sure that the time on each host is synchronized with the time on the NetWitness Server.

    To synchronize the time, do one of the following:

    1. Configure the NTP Server.

    For more information, see Configure NTP Servers in the System Configuration Guide.

    1. Perform the following steps:

    1. SSH to the Admin Server host.

    2. Run the following commands.

      salt \* service.stop ntpd

      salt \* cmd.run 'ntpdate nw-node-zero'

      salt \* service.start ntpd