Virtual Host Upgrade: Post Upgrade Tasks

Document created by RSA Information Design and Development on Apr 11, 2019Last modified by RSA Information Design and Development on Apr 11, 2019
Version 3Show Document
  • View in full screen mode
  

You must complete the following tasks after you upgrade your hosts from 10.6.6.x to 11.3. These tasks are organized by the following categories.

Go to the Master Table of Contents to find all NetWitness Platform Logs & Network 11.x documents.

General

General tasks apply to all customers regardless of the NetWitness Components you deploy.

Task 1 - Remove Backup-Related Files from Host Local Directories

Caution: 1) You must retain a copy of all backup files on an external host. 2) Validate that you have all your data from your backup restored in 11.3 before you remove the backup-related files from the local directories on your 11.3 hosts.

Backup .tar Files

After all the hosts are upgraded to 11.3, you must remove:

  • The backup files from the local directories on the hosts.
  • All the files from nw-backup and restore directories on the hosts.
                                 
HostBackup PathRestore Path
Malware/var/lib/rsamlware/nw-backup /var/netwitness/malware_analytics_server/nw-backup/restore
Event Stream Analysis/opt/rsa/database/nw-backup /var/netwitness/database/nw-backup/restore
NW Server/var/netwitness/database/nw-backup /var/netwitness/restore
All Other Hosts/var/netwitness/database/nw-backup /var/netwitness/database/nw-backup/restore

Task 2 - Make Sure Port 15671 Is Configured Correctly

Port 15671 is new in 11.x, but you do not need to open a firewall for this port. Make sure that port 15671, and all ports, are configured as shown in the "Network Architecture and Ports" topic in the Deployment Guide.

(Optional) Task 3 - Reissue Certificates for Your Hosts

In 11.3.0.0, RSA introduced a cert-reissue command line command and its arguments to reissue host certificates. After you update all your hosts to 11.3, you should reissue certificates for all of them as soon as possible to avoid having them expire. If the certificates expire, this places your NetWitness deployment in a bad security state. Refer to the Security Configuration Guide for instructions on how to use the cert-reissue command.

(Conditional) Task 4 - Restore Custom Analysts Roles

If you had custom analyst roles in 10.6.6.x, you must reinstate them in 11.3. See "Add a Role and Assign Permissions" in the System Security and User Management Guide.

(Conditional) Task 5 - If NetWitness Platform Has No Web Access, Upload Response .bin File Again (License Server)

If your NetWitness Deployment does not have Internet access, after you upgrade to 11.3, you must upload the response .bin file again to view the license information in the ADMIN > System > Licensing view in the NetWitness Platform User Interface. See “Upload an Offline Capability Response to NetWitness Platform” in the Licensing Management Guide for instructions.

Task 6 - Migrate Active Directory (AD)

The first time you log into the NetWitness Platform 11.3 User Interface, you must click on the Migrate button to complete the migration of AD.

  1. Log in to NetWitness Platform 11.3 with your admin user credentials.
  2. Go to ADMIN > SECURITY and click the Settings tab.
    The following dialog is displayed.

  3. Click Migrate.
    The migration is complete and the dialog closes.

Task 7 - Modify Migrated AD Configuration to Upload Certificate

If you authenticated through Active Directory (AD) server, and enabled SSL for the AD connection in 10.6.6.x, you must modify the migrated AD configuration to upload the Active Directory server certificate.

Complete the following procedure to modify the migrated AD configuration to upload the certificate.

  1. Log in to NetWitness Platform 11.3, go to ADMIN > Security and click the Settings tab.
  2. Under Active Directory Settings, select an AD configuration and click .
    The Edit Configuration dialog is displayed.
  3. Go to the Certificate File field, click Browse, and select a certificate from your network.
  4. Click Save.

Task 8 - Reconfigure Pluggable Authentication Module (PAM) in 11.3

You must reconfigure PAM after you upgrade to 11.3. See "Configure PAM Login Capability" in the System Security and User Management Guide for instructions.

You can refer to your 10.6.6.x PAM configuration files in the /etc directory in the your 10.6.6.x backup data for guidance.

Task 9 - Restore NTP Servers

You must use the NetWitness Platform 11.3 user interface to restore NTP server configurations. NTP server configuration information is located in $BUPATH/restore/etc/ntp.conf. Use the NTP server name and hostname from the /var/netwitness/restore/etc/ntp.conf file. See "Configure NTP Servers" in the System Configuration Guide for detailed instructions on how to add NTP servers.

Task 10 - Restore Licenses for Environments without FlexNet Operations-On Demand Access

If your environment does not have access to FlexNet Operations-On Demand, you need to re-download your NetWitness Platform licenses. Refer to "Step 1. Register the NetWitness Server" in the Licensing Management Guide for instructions on how to re-download licenses.

(Conditional) Task 11 - If You Disabled Standard Firewall Config - Add Custom IPtables

During the upgrade, you have the option of using these rules or disabling them. If you disabled them, follow these instructions as a baseline to create user-managed firewall rule sets on all the hosts for which you disabled the standard firewall configuration.

Note: You can refer to the $BUPATH/restore/etc/sysconfig/iptables and $BUPATH/restore/etc/sysconfig/ip6tables in the restore folder of the backup to update the ip6tables and iptables files. The /etc/netwitness/firewall.cfg file contains the standard iptables firewall rules.

  1. SSH to each host and log in with your root credentials.
  2. Update the following ip6tables and iptables files with the custom firewall rules.
    /etc/sysconfig/iptables
    /etc/sysconfig/ip6tables
  3. Reload the iptables and ip6tables services.
    service iptables reload
    service ip6tables reload

(Conditional) Task 12 - Specify SSL Ports If You Never Set Up Trusted Connections

Complete this task only if you never set up Trusted Connections. You would not have set up Trusted Connections if you:

  • Used the base ISO image for 10.3.2 or earlier.
  • Updated the system using RPMs exclusively to get to 10.6.6.x.

NetWitness Platform 11.3 cannot communicate with the Core services if you are using a non-SSL port 500XX. You must update the Core service ports to an SSL port in the Edit Service dialog.

  1. Log in to NetWitness Platform and go to ADMIN > Services.
  2. Select each core service and change the ports from Non-SSL to SSL ports.
    ServiceNon-SSLSSL
    Broker5000356003
    Concentrator5000556005
    Decoder5000456004
    Log Decoder50002

    56002

  3. Click (Edit icon) from the SERVICES view toolbar.
    The Edit Service dialog is displayed.
  1. Change the port from Non-SSL to SSL as shown in the table and click Save (for example, change the Broker port from 50003 to 56003).

Task 13 (Conditional) Reconfigure Public Key Infrastructure (PKI) Certificates

If you had PKI keystores that contained server certificates with private keys and the truststores that contain the trusted CA certificates, you must reconfigure after you upgrade to 11.3. For instructions on how to configure PKI authentication, see the “System Security and User Management Guide”.

Event Stream Analysis (ESA)

Task 14 - Reconfigure Automated Threat Detection for ESA

If you used Automated Threat Detection in 10.6.6.x, you must complete the following steps to reconfigure it using the ESA Analytics service in 11.3.

  1. Log in to NetWitness Platform and go to ADMIN > System > ESA Analytics.
    The Suspicious Domains modules, Command and Control (C2) for Network data and C2 for Logs, require a whitelist named “domains_whitelist”.
  2. Conditional - If your previous Automated Threat Detection whitelist appears on the Lists tab of the Context Hub service:
    1. Go to ADMIN > Services, select the Context Hub service, in the action commands () drop-down menu, click View > Config > Lists tab.
    2. Rename your old Automated Threat Detection whitelist to “domains_whitelist” for the Suspicious Domains module.

For more information, see the Automated Threat Detection Guide and the "Configure ESA Analytics" section of the ESA Configuration Guide.

Task 15 (Conditional) Verify String Array Type Meta Keys on the ESA Correlation Service

If you added any string array type meta keys to the Event Stream Analysis service for your ESA correlation rules in 10.6.6.x or earlier, verify that they appear on the ESA Correlation service in 11.3.

  1. Follow the “Configure Meta Keys as Arrays in ESA Correlation Rule Values” procedure in the ESA Configuration Guide to verify if the string array type meta keys that were added before the upgrade are on the ESA Correlation service. Add any missing string array type meta keys.
  2. Do not remove any meta keys from the multi-valued parameter on the ESA Correlation service. In NetWitness Platform 11.3, the ESA rules from Live use meta keys with array syntax and they depend on these meta keys to work correctly. Removing values from the multi-valued list can cause the ESA Rule Deployments to fail.

Task 16 (Conditional) Update RSA Live ESA Rules with Meta Type Changes from String to Array

The following table lists the ESA rules from RSA Live that had meta key type changes from String to Array in NetWitness Platform 11.3.

                                                
Rule #Rule NameArray Type Meta Keys in 11.3
1RIG Exploit Kitthreat_category
2 AWS Critical VM Modifiedalert
3Multiple Successful Logins from Multiple Diff Src to Same Dest host.src and host.dst
4Multiple Successful Logins from Multiple Diff Src to Diff Dest host.src and host.dst
5Multiple Failed Logins from Multiple Diff Sources to Same Dest host.src and host.dst
6Multiple Failed Logins from Multiple Users to Same Destination host.src and host.dst
7User Login Baselinehost.src and host.dst
  1. If you:
    • Deployed these rules before version 11.3:
      1. Note any rule parameters that you have changed so you can adjust the rules for your environment.
      2. Download the updated rules from RSA Live.
      3. Reapply any changes to the default rule parameters and deploy the rules.

        (For instructions, see “Download RSA Live ESA Rules” in the Alerting with ESA Correlation Rules User Guide.)

    • Are deploying these rules for the first time in version 11.3, follow the customization directions with the ESA rule descriptions. Rules 3 to 7 in the above table require that the Context Hub lists for User_Whitelist, Host_Whitelist and IP_Whitelist to be added as enrichments to ESA. (See “Configure Context Hub List as an Enrichment Source” in the Alerting with ESA Correlation Rules User Guide.)
  2. Deploy the ESA rule deployment that contains these rules. (See “ESA Rule Deployment Steps” in the Alerting with ESA Correlation Rules User Guide.)

Task 17 (Conditional) - Verify ESA Rule Deployment

After you upgrade to 11.3, verify your ESA rule deployments. For every ESA host, a new deployment is created in the format “<ESA Host name> – ESA Correlation”.

  1. Make sure that a new deployment was created.
  2. Make sure that the new deployment contains an ESA Correlation service, data sources, and rules for all previous deployments on that ESA host.
  3. Make sure that the ESA Correlation service has status of “Deployed”.

For a detailed example, see the ESA Configuration Guide. For Deployment information, see “ESA Rule Deployment Steps” in the Alerting with ESA Correlation Rules User Guide. For troubleshooting information, see the Alerting with ESA Correlation Rules User Guide.

Investigate

Task 18 - Make Sure Customized User Roles Have Investigate-server Permissions for Event Analysis Access

After you upgrade to 11.3.0.0, any customized user role does not have investigate-server.* permission enabled by default. Complete the following procedure to make sure that the appropriate user roles have permission to access Event Analysis.

  1. Log in to NetWitness Platform 11.3.0.0 with your Admin user credentials and go to ADMIN > Security.
  2. Click the Roles tab.
  3. Select the roles that need investigate-server.* permissions and click (Edit icon).
  4. Select the Investigate-server tab under under Permissions.
  5. If the investigate-server checkbox is not set, set it for the Roles that require Event Analysis access.
  6. Click Save.

Log Collection

Task 19 - Reset Stable System Values for Log Collector after Upgrade

Complete the following tasks to reset stable system values for the Log Collector after you upgrade it to 11.3 to ensure that all collection protocols resume normal operation.

Reset Stable System Values for the Lockbox

The Lockbox stores the key for encrypting event source and other passwords for the Log Collector. The Log Collector service cannot open the Lockbox because of the stable system value changes. As a result, you must Reset Stable System Values for the Lockbox . See "Log Collection: Step 3. Set Up a Lockbox" in the Log Collection Configuration Guide for instructions.

Update Log Collector Service RabbitMQ User Account Password

If the logcollector service RabbitMQ user account password was changed, you must reenter it after the 11.3 upgrade.

  1. Log in to NetWitness Platform and go to ADMIN > Services.
  2. Select the Log Collector service.
  3. Click (Actions) > View > Explore.
  4. Right click event-broker > Properties .
  5. Select passwd from the drop-down list, enter newpw=><newpassword> in Parameters (where <newpassword> is the RabbitMQ user account password), and click Send.

Task 20 - (Conditional) Update SSHD Configuration after Upgrade with Older Windows and UNIX SFTP Agents

This task applies if you have Log Collection, Log Collector (LC) and or Virtual Log Collector (VLC), with File Collection event sources.

If all the event sources:

  • Resume collection after upgrade, you do not need to do anything.
  • Do not resume collection after the upgrade, you may have to restore Cipher, MACs and Key Exchange Algorithms to the SSHD configuration from the original LC/VLC. Change the /etc/ssh/sshd_config file.
    1. Make the following changes to /etc/ssh/sshd_config file.
      1. If the KexAlgorithms line:
        • Exists, append “,diffie-hellman-group1-sha1” to the file.
        • Does not exist, add “KexAlgorithms +diffie-hellman-group1-sha1” line.
      2. If the Ciphers line:
        • Exists, append “,aes128-cbc” to the file.
        • Does not exist, add the “Ciphers +aes128-cbc” line to the file.
    2. Restart SSHD service.
    3. If collection still fails, edit the /etc/systemd/system/sshd.service.d/sshd-opts-managed.conf file and change “OWB_ALLOW_NON_FIPS=on” to “OWB_FIPS_MODE=off” in the Environment line and restart SSHD service.
    4. If collection still fails, contact RSA Customer Support (https://community.rsa.com/docs/DOC-1294).

Task 21 - Enable FIPS Mode

Note: This task is optional for Upgrades from 10.6.6.x with FIPS enabled for Log Collectors, Log Decoders and Network Decoders)

FIPS is enabled on all services except Log Collector, Log Decoder, and Decoder. FIPS cannot be disabled on any services except Log Collector, Log Decoder, and Decoder.

Log Decoder and Decoder

(Conditional) Task 23 - Enable Metadata for GeoIP2 Parser

By default, the GeoIP2 parser generates less metadata than the GeoIP parser did. After updating to 11.3, if you require any of the additional metadata, you must enable them (once only) for each Decoder. This can also be altered post-upgrade. Note that the isp and org meta fields usually produce an equivalent value to domain.

To enable metadata:

  1. Go to ADMIN > Services.
  2. In the Administration services view, select a Log Decoder or a Decoder.
  3. Click the settings icon (Image of the Action button) and select View > Config. The Parsers Configuration panel is displayed, from which you can select GeoIP2 to enable the desired metadata.

For more information about GeoIP2 parsers, see the "GeoIP2 and GeoIP Parsers" topic in the Decoder and Log Decoder Configuration Guide.

Malware Analysis

Task 24 - Enable Threat - Malware Indicators Dashboard

In 11.3, the 10.6.6.x Threat -Indicators Dashboard was renamed to Threat - Malware Indicators Dashboard. If you used this dashboard in 10.6.6.x, you must:

  1. Enable the Threat - Malware Indicators Dashboard in 11.3.
  2. Set datasource for new dashlets.
    See "Dashlets" in RSA Link (https://community.rsa.com/docs/DOC-81463) for a description of Dashlets in the context of NetWitness Platform.

Note: After upgrading to 11.3, both the Threat-Indicators and the Threat-Malware Indicators dashboards can be displayed in the User Interface. If this is the case, disable the Threat-Indicators dashboard, and enable the Threat-Malware Indicators report charts and dashboard. For information about disabling dashboards, see the "Managing Dashboards" topic in the NetWitness Getting Started Guide.

Reporting Engine

(Conditional) Task 25 - Restore the CA certificates for External Syslog Servers for Reporting Engine

You must restore CA certificates after the upgrade from the backup you made prior to the upgrade. The Backup script backs up the 10.6.6.x CA certificates into the /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-0.b15.el6_8.x86_64/jre/lib/security/cacerts directory.

Complete the following procedure to restore the CA certificates in 11.3.

  1. SSH to the NW Server host.
  2. Export the CA certificates.
    keytool -export -alias <alias_name> -keystorepath_to_keystore_file -rfc -file path_to_certificate_file
  3. Copy the CA PEM file into /etc/pki/nw/trust/import directory.

(Conditional) Task 26 - Restore External Storage for Reporting Engine

If you have external storage for the Reporting Engine (such as SAN or NAS for storing reports), you must restore the mount you unlinked before the upgrade. See "Reporting Engine: Add Additional Space for Large Reports" in the Reporting Engine Configuration Guide for instructions.

Respond

Task 27 - Restore Respond Service Custom Keys

In 10.6.6.x, if you added custom keys for use in the groupBy clause, the alert_rules.json file was modified. The alert_rules.json file contains aggregation rule schema. RSA moved the alert_rules.json file to the following new location:
/var/lib/netwitness/respond-server/scripts

  1. Copy the custom keys from /opt/rsa/im/fields/alert_rules.json file in the backup directory.
    This directory is where the alert_rules.json file is restored from the 10.6.6.x backup.
  1. Go to the /var/lib/netwitness/respond-server/data/aggregation_rule_schema.json in 11.3.
    This is the new file for 11.3.
  2. Edit the /var/lib/netwitness/respond-server/data/aggregation_rule_schema.json to include the custom keys you copied in step one.

Task 28 - Restore Customized Respond Service Normalization Scripts

RSA re-factored the Respond service normalization scripts in 11.3 and moved them to the following new location:
/var/lib/netwitness/respond-server/scripts
If you customized these scripts in 10.6.6.x, you must:

  1. Go to the to the /opt/rsa/im/scripts directory.
    This directory is where the following Respond service normalization scripts are restored from the 10.6.6.x backup.
    data_privacy_map.js
    normalize_alerts.js
    normalize_core_alerts.js
    normalize_ecat_alerts.js
    normalize_ma_alerts.js
    normalize_wtd_alerts.js
    utils.js

  2. Copy any custom logic from the 10.6.6.x scripts.
  3. Go to the /var/lib/netwitness/respond-server/scripts directory.
    This directory is where NetWitness Platform 11.3 stores the re-factored scripts.
  4. Edit the new scripts to include the custom logic you copied in step 2 from the 10.6.6.x scripts.
  5. Copy any custom logic from /opt/rsa/im/fields/alert_rules.json file.
    The alert_rules.json file contains aggregation rule schema.

Task 29 - Add Respond Notification Settings for Custom Roles

Respond Notification Setting permissions enable Respond Administrators, Data Privacy Officers, and SOC Managers to access Respond Notification Settings (CONFIGURE > Respond Notifications), which enable them to send email notifications when incidents are created or updated.

To access these settings, you will need to add additional permissions to your existing built-in NetWitness Platform user roles. You will also need to add permissions to your custom roles. See the “Respond Notification Settings Permissions” topic in the NetWitness Respond Configuration Guide. For detailed information about user permissions, see the System Security and User Management Guide.

Task 30 - Manually Configure Respond Notification Settings

The Incident Management notification settings in NetWitness Platform 10.6.6.x are different from the Respond notification settings available in 11.3, so your existing 10.6.6.x settings will not migrate to 11.3.

NetWitness Respond notification settings enable email notifications to be sent to SOC Managers and the Analyst assigned to an incident when an incident is created or updated.

To manually configure the Respond Notification Settings, go to CONFIGURE > Respond Notifications. See the “Configure Respond Email Notification Settings” procedure in the NetWitness Respond Configuration Guide.

Notification Servers from 10.6.6.x will not display in the Email Server drop-down list. The email servers must be edited and saved in the Global Notification Servers panel (ADMIN > System > Global Notifications > Server tab).

  1. Log in to NetWitness Platform and go to CONFIGURE > Respond Notifications.
    The Respond Notifications Settings view is displayed. Notice that the email notification servers do not appear in the EMAIL SERVER drop-down list.
  2. Click the Email Server Settings link.
    You will see the Global Notifications panel.
  3. Click the Servers tab.
  4. For each of your email notification servers:
    1. Select the Email notification server and click (Edit icon).

    2. In the Define Email Notification Server dialog, click Save.
  5. Go back to CONFIGURE > Respond Notifications. Your servers will appear in the EMAIL SERVER drop-down list.
    Custom Incident Management notification templates cannot be migrated to 11.3. No custom templates are supported in 11.3.

Task 31 - Update Default Incident Rule Group By Values

The following default incident rules now use “Source IP Address” as the Group By value.

  • High Risk Alerts: Reporting Engine
  • High Risk Alerts: Malware Analysis
  • High Risk Alerts: ESA

To update the above default rules, change the Group By value to “Source IP Address.”

Note: If you already updated the Group By values for the default rules listed above in 11.1 or later, you do not have to do it again.

The High Risk Alerts: NetWitness Endpoint default incident rule now uses Host Name as the Group By value. If you have NetWitness Endpoint you can use this rule. Change the Group By value of the default NetWitness Endpoint rule to "Host Name."

  1. In the NetWitness Platform menu, select CONFIGURE > Incident Rules and click on the rule that you want to update in the Name column. The Incident Rule Details view is displayed.
  2. In the GROUP BY field, select the new Group By value from the drop-down list.
  3. Click Save to update the rule.

To aggregate NetWitness Endpoint alerts based on the File Hash, complete the following steps to clone the default NetWitness Endpoint incident rule and change the Group By value.

  1. In the NetWitness Platform menu, select CONFIGURE > Incident Rules. The Incident Rules List view is displayed.
  2. Select the High Risk Alerts: NetWitness Endpoint default incident rule and click Clone. You will receive a message that you successfully cloned the selected rule.
  3. Change the Name of the rule to an appropriate name, such as High Risk Alerts: NetWitness Endpoint File hash.
  4. In the GROUP BY field, remove the previous Group By value and add File MD5 Hash. It is important that File MD5 Hash is the only Group By value listed.
  5. Click Save to create the rule.

For detailed information, see the Respond Configuration Guide.

Task 32 - Add Group By Field to Incident Rules

The Group By field is not required in 10.6.6, but it is required in 11.3. After you upgrade to

11.3, some incident rules will not have a Group By field, so you must add them to the rules or the rules will not work and they will not create incidents.

Complete the following steps for each incident rule:

  1. Log in to NetWitness Platform.
  2. Go to CONFIGURE > Incident Rules and click the link in the Name column for the rule that you want to update.

  3. In the Group By field, verify that a Group By value is selected. If not, select a Group By value.
  4. Click Save to update the rule.
    For information about incident rules, see the NetWitness Respond Configuration Guide.

Task 33 - Update Incident Rules Identified in the Domain Matching Conditions Upgrade Preparation Task

Modify the incident rules that you identified in the Task 7 - Check Aggregation Rules Match Conditions for “Domain” or “Domain for Suspected C&C” upgrade preparation task, which contained Domain or Domain for Suspected C&C in the matching conditions in rule builder.

For each rule that you previously identified:

  1. Log in to NetWitness Platform, go to CONFIGURE > Incident Rules and click the link in the Name column for the rule that you want to update.

  2. In the Match Conditions section, in the blank fields, select Domain and Domain for Suspected CC in the drop-down list and then select the conditions that you previously identified in the pre-upgrade tasks.

  3. Click Save to update the rule.
    For information about incident rules, see the NetWitness Respond Configuration Guide.

Warehouse

Task 34 - Restore keytab Files, Mount NFS, Install Service

  1. Restore the keytab files from <backup-path>/restore directory.
  2. Restore the Kerberos Realm Configuration from the <backup-path>/restore/etc/krb5.conf into /etc/krb5.conf.

  3. (Conditional) If you perform the upgrade from a Non - FIPS environment and the isCheckValidationRequired parameter is not enabled in the destination, to configure the SFTP destination:

    1. SSH to the Warehouse Connector host and submit the following commands:
      cd /root/.ssh/
      mv id_dsa id_dsa.old
      OWB_FORCE_FIPS_MODE_OFF=1 openssl pkcs8 -topk8 -v2 des3 -in id_dsa.old -out id_dsa

      You are prompted for the pass phrase.
    2. Enter the Encryption password.
    3. Run the following command.
      chmod 600 id_dsa
  4. Install the Warehouse Connector.
    See the Warehouse Connector Configuration Guide for instructions.

Task 35 - Refresh Warehouse Connector Lockbox and Start Stream

Note: If the streams have auto start turned on in 10.6.6.x, there will be a small delay before you will see the Warehouse Connector service in the NetWitness Platform User Interface.

  1. Refresh the Lockbox of Warehouse Connector.
  2. SSH to the Warehouse Connector and log in with root credentials.
  3. Restart the service.
    service nwwarehouseconnector restart
  4. (Conditional) If the auto start was not enabled in 10.6.6.x, you must start the stream manually after the service restarts.

Task 36 - Update Hive Version

After you update to 11.3, you must update to the Hive version that is compatible with the 11.3 Warehouse (either Hive version 0.12 or version 1.0).

  • Hive Version 0.12
    SSH to the NW Server and run the following command.
    rpm -ivh rsa-nw-hive-jdbc-0.12.0-1.x86_64.rpm
  • Hive Version 1.0
    SSH to the NW Server and run the following command.
    rpm -ivh rsa-nw-hive-jdbc-1.0.0-1.x86_64.rpm

RSA Archer Cyber Incident & Breach Response

Task 37 - Reconfigure RSA Archer Cyber Incident & Breach Response Integration

For information on how to reconfigure RSA Archer Cyber Incident & Breach Response for Event Stream Analysis, Reporting Engine, and Respond, see RSA Archer Integration Guide.

RSA NetWitness® Endpoint

Task 38 - Reconfigure Endpoint Alerts Via Message Bus

  1. On the NetWitness Endpoint Server, modify the virtual host configuration in the C:\Program Files\RSA\ECAT\Server\ConsoleServer.exe file to reflect the following configuration.
    <add key="IMVirtualHost" value="/rsa/system" />

    Note: In NetWitness Platform 11.3, the virtual host is /rsa/system. For 10.6.6.x and earlier versions, the virtual host is /rsa/sa.

  2. Restart the API Server and Console Server.
  3. SSH to the NW Server and log in with root credentials.
  4. Submit the following command to add all certificates to the truststore.
    orchestration-cli-client --update-admin-node
  5. Submit the following command to restart the RabbitMQ server.
    systemctl restart rabbitmq-server
    The NetWitness Endpoint account should automatically be available on RabbitMQ.
  6. Import the /etc/pki/nw/ca/nwca-cert.pem and /etc/pki/nw/ca/ssca-cert.pem files from the NW Server and add them to the Trusted Root Certification stores in the Endpoint Server.

Task 39 - Reconfigure Recurring Feed Configured from Legacy Endpoint Because Java Version Changed

You must reconfigure the Legacy Endpoint recurring feed due to the change in Java version. Complete the following step to fix this problem.

  • Import the NetWitness Endpoint CA certificate into the NetWitness Platform Trusted store as described in "Export the NetWitness Endpoint SSL Certificate" under the "Configure Contextual Data from Endpoint via Recurring Feed" topic in the RSA NetWitness Endpoint Integration Guide to import the certificate.

(Optional) Task 40 - Install Endpoint Log Hybrid and Endpoint Agents

See:

RSA NetWitness Platform 11.3 Physical Host Installation Guide for instructions for installation on a physical host.

RSA NetWitness Platform 11.3 Virtual Host Installation Guide for instructions for installation on a virtual host.

RSA NetWitness® UEBA

Task 41 - Install NetWitness UEBA

NetWitness UEBA is new a new feature as of NetWitness Platform 11.3.

See:

RSA NetWitness Platform 11.3 Physical Host Installation Guide for instructions for installation on a physical host.

RSA NetWitness Platform 11.3 Virtual Host Installation Guide for instructions for installation on a virtual host.

RSA NetWitness UEBA User Guide for information about NetWitness UEBA.

NetWitness Platform Integrations

(Conditional) Task 42 - For Integrations with Web Threat Detection, RSA Archer® Cyber Incident & Breach Response or NetWitness Endpoint.

If you integrate with Web Threat Detection, Archer Cyber Incident & Breach Response or NetWitness Endpoint, you must configure Mutually Authenticated SSL on each integrated system so that the application can authenticate itself when connecting to the RabbitMQ message bus.

Note: Use the RabbitMQ usernames and passwords that were obtained when you backed up your 10.6.6.x data (see Backup Instructions).

  1. Create a user on the host system that is integrating with NetWitness Platform by logging into the host and running the following rabbitmqctl command.
    > rabbitmqctl add_user <username> <password>
  2. Set permissions for users by running the following command (use the username from step 1).
    > rabbitmqctl set_permissions -p /rsa/system <username> ".*", ".*", ".*"
    For example:
    > rabbitmqctl set_permissions -p /rsa/system wtd-incidents ".*", ".*", ".*"

Other

Task 43 - Remap Virtual NW Server License to 10.6.6.x MAC Address

If you are upgrading a Security Analytics server running on a virtual machine, change the 11.3 NW Server virtual host to the 10.6.6.x MAC address to retain licensing. Refer to "Licensing: Step 1. Register the NetWitness Server" in the RSA NetWitness Platform Licensing Management Guide for instructions on remapping a license to a new MAC address." Go to the Master Table of Contents to find all NetWitness Platform Logs & Network 11.x documents.

You are here
Table of Contents > 7. Post Upgrade Tasks

Attachments

    Outcomes