Post Upgrade Tasks

Document created by RSA Information Design and Development on Sep 26, 2019Last modified by RSA Product Team on Nov 19, 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.0.2. 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.0.2 before you remove the backup-related files from the local directories on your 11.3.0.2 hosts.

Backup .tar Files

After all the hosts are upgraded to 11.3.0.2, 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.2, RSA introduced a cert-reissue command line command and its arguments to reissue host certificates. After you update all your hosts to 11.3.0.2, 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.0.2. 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.0.2, 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.0.2 User Interface, you must click on the Migrate button to complete the migration of AD.

  1. Log in to NetWitness Platform 11.3.0.2 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.0.2, 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.0.2

You must reconfigure PAM after you upgrade to 11.3.0.2.

These are the high-level tasks you must complete to configure PAM login capability:

  1. Configure and test the PAM module.
  2. Configure and test the NSS service.
  3. Enable PAM in NetWitness Server.
  4. Create group mappings in NetWitness Server.

See "Configure PAM Login Capability" in the System Security and User Management Guide for the detailed 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.0.2 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.0.2 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.0.2. For instructions on how to configure PKI authentication, see the “System Security and User Management Guide”.

Event Stream Analysis (ESA)

Task 14 - Update Memory Required for ESA Host

You must update the Xmx memory setting from 164G to eighty percent of the total host memory to prevent the Correlation Server failing to start and re-spawning. For example, if

  • 180 Gigabytes is eighty percent of your memory, specify -Xmx180G.
  • 500 Megabytes is eighty percent of your memory, specify -Xmx500M.
  1. SSH to the ESA host and log in with your ESA host credentials.
  2. Open the correlation-server.conf file in edit mode.
    vi /etc/netwitness/correlation-server/correlation-server.conf
    JAVA_OPTS="-XX:+UseG1GC -Djava.security.egd=file:/dev/./urandom –Xmx164G -javaagent:/var/lib/netwitness/esper-enterprise/esperee-utilagent-7.1.0.jar"
  3. Modify the Xmx parameter.
    JAVA_OPTS="-XX:+UseG1GC -Djava.security.egd=file:/dev/./urandom –<eighty-percent-of-total-memory> -javaagent:/var/lib/netwitness/esper-enterprise/esperee-utilagent-7.1.0.jar"
  4. Save and exit the correlation-server.conf file.
  5. Restart the Correlation service.
    systemctl restart rsa-nw-correlation-server

Task 15 - 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.0.2.

  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 (Actions icon) 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 16 - Verify the String Array Type Meta Keys on the ESA Correlation Service and Next Steps

  1. Verify that your existing string array meta keys migrated to the ESA Correlation Service.

    1. Go to ADMIN > Services, and in the Services view, select an ESA Correlation service and then select Actions icon > View > Explore.

    2. In the Explore view node list for an ESA Correlation service, select correlation > stream.

    3. Verify that the previously recorded ArrayFieldNames values are the same as in the multi-valued parameter. The multi-valued parameter shows the string array meta keys currently used for your ESA rules.

  2. Your ESA rules continue to work, but if you are using Live, UEBA, or Endpoint rules, follow the Task 19 - (Conditional) Update the Multi-Valued and Single-Valued Parameter Meta Keys for the latest Endpoint, UEBA, and RSA Live Content Rules procedure.

To support Endpoint, UEBA, and RSA Live content, a data change from single-value (string) to multi-value (string array) is required for several meta keys within the ESA Correlation service for 11.3 and later. Additional string meta keys are also required.

If the meta keys used for your ESA rules are different from the required default multi-value meta keys, your ESA rules continue to work, but you should update your ESA rules to use the required meta keys as soon as possible to ensure that your rules continue to deploy properly.

The ESA Correlation service has the following multi-valued (string array) and single-valued (string) parameters:

  • multi-valued - Shows the string array meta keys currently used for your ESA rules. For an upgrade to NetWitness Platform 11.3.0.2, it shows the existing string array meta keys before the upgrade. (This parameter is equivalent to the Event Stream Analysis service ArrayFieldNames parameter in NetWitness Platform versions 11.2 and earlier.)
  • single-valued - Shows the string meta keys currently used for your ESA rules. For an upgrade to NetWitness Platform 11.3.0.2 from versions prior to 11.3.0.2, this parameter value is empty.
  • default-multi-valued - Shows the required string array meta keys for the latest version.
  • default-single-valued - Shows the required string meta keys for the latest version.

Note: If you have the same value in the single-valued and multi-valued parameter fields, the single-valued meta key value takes precedence over the multi-valued meta key value.

To use the latest Endpoint, UEBA, and Live content rules, you must update the multi-valued parameter on the ESA Correlation service to include all of the meta keys in the default-multi-valued field. You must also update the single-valued parameter field to include all of the meta keys in the default-single-valued field. To do this, follow the Task 19 - (Conditional) Update the Multi-Valued and Single-Valued Parameter Meta Keys for the latest Endpoint, UEBA, and RSA Live Content Rules procedure.

Caution: Any changes that you make to the multi-valued parameter may cause an error when you deploy your existing rules. You can update the multi-valued parameter, resync your meta keys, and update the ESA rules at your convenience. You may want to add a couple meta keys at a time to reduce the number of reported errors.

Note: If you are using multiple ESA Correlation services, the multi-valued and single-valued parameters should be the same on each ESA Correlation service.

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

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

Rule #Rule NameArray Type Meta Keys in 11.3.x
1RIG Exploit Kitthreat_category
2AWS Critical VM Modifiedalert
3Multiple Successful Logins from Multiple Diff Src to Same Desthost.src and host.dst
4Multiple Successful Logins from Multiple Diff Src to Diff Desthost.src and host.dst
5Multiple Failed Logins from Multiple Diff Sources to Same Desthost.src and host.dst
6Multiple Failed Logins from Multiple Users to Same Destinationhost.src and host.dst
7User Login Baselinehost.src and host.dst
  1. If you:
    • Deployed these rules before version 11.3.0.2:
      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.0.2, follow the customization directions within 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 18 Verify the ESA Rule Deployments

After you upgrade to 11.3.0.2, verify your ESA rule deployments. For every ESA host, a new deployment is created in the format “<ESA-Hostname> – 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”.
  4. If the ESA rule status shows “Disabled” or shows the Red Exclamation point icon icon in the Status column, you need to determine the issue to fix the rule. If a disabled rule has an error message, it now shows Red Exclamation point icon in the Status field. You can hover over the rule to view the error message tooltip without going to the error log. (The ESA Correlation Service log files are located at /var/log/netwitness/correlation-server/correlation-server.log)
    See ESA Troubleshooting Information.
  5. Check the status of the overall ESA rule deployment. If the ESA rule deployment is successful, the ESA Services and ESA Rules show a status of “Deployed,” the Data Sources show a green circle, and the Deploy Now button is disabled.

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.

Task 19 - (Conditional) Update the Multi-Valued and Single-Valued Parameter Meta Keys for the latest Endpoint, UEBA, and RSA Live Content Rules

To use the latest Endpoint, UEBA, and Live content rules, you must update the multi-valued parameter field on the ESA Correlation service to include all of the meta keys in the default-multi-valued field. You must also update the single-valued parameter field to include all of the meta keys in the default-single-valued field.

Caution: Any changes that you make to the multi-valued parameter may cause an error when you deploy your existing rules. You can update the multi-valued parameter, resync your meta keys, and update the ESA rules at your convenience. You may want to add a couple meta keys at a time to reduce the number of reported errors.

Note: If you see a warning message in the ESA Correlation server error logs that means there is a difference between the default-multi-valued parameter and multi-valued parameter meta key values, the new Endpoint, UEBA, and Live content rules will not work. Completing this procedure should fix the issue. For example warning messages, see Example ESA Correlation Server Warning Message for Missing Meta Keys.

  1. After an upgrade to 11.3.0.2 or later, go to ADMIN > Services, and in the Services view, select an ESA Correlation service and then select Actions icon > View > Explore.
  2. In the Explore view node list for the ESA Correlation service, select correlation > stream.
  3. Compare the multi-valued parameter meta keys with the required default-multi-valued meta keys. Copy and paste the missing string array meta keys from the default-multi-valued parameter to the multi-valued parameter. (You may want to copy only a couple meta keys at one time to reduce the number of reported errors).
  4. Copy and paste the string meta keys from the default-single-valued parameter to the single-valued parameter.
  5. Apply the changes on the ESA Correlation service:
  6. Go to CONFIGURE > ESA Rules and click the Settings tab.
    • In the Meta Key References, click the Meta Re-Sync (Refresh) icon (Meta Re-Sync (refresh) icon ).
    • If you have multiple ESA Correlation services, make the same meta key changes on each ESA Correlation service.
  7. If you are using any of the default-multi-valued or default-single-valued meta keys in your ESA Advanced rules, update the rule syntax. See also Task 20 - (Conditional) Adjust Custom ESA Rule Builder and ESA Advanced Rules .
  8. If you used any meta keys in the ESA rule notification templates from the default-multi-valued parameter list, update the templates with the meta key changes. See "Configure Global Notification Templates" in the System Configuration Guide.
  9. Deploy your ESA rule deployments.
  10. Check your rules for error messages in the ESA Rules section of the ESA rule Deployment or check the ESA Correlation error logs for errors.
    • To access the error messages in the ESA rule deployment, go to CONFIGURE > ESA Rules > Rules tab, select a deployment in the options panel on the left, and go to the ESA Rules section.
    • To access the ESA Correlation service logs, you can use SSH to get in the system and go to: /var/log/netwitness/correlation-server/correlation-server.log.

Task 20 - (Conditional) Adjust Custom ESA Rule Builder and ESA Advanced Rules

Update your ESA Rule Builder and ESA Advanced rules to work with the string and string array meta keys listed in the default-multi-valued and default-single valued parameter fields for the ESA Correlation service. You can add additional meta keys to the multi-valued and single-valued parameters.

For example, if you use ec.outcome as a single-valued meta key in your ESA rule as shown below:

@RSAAlert

SELECT * FROM Event((ec_outcome IN ( 'Success' )))

.win:time_length_batch(2 Minutes, 2)

HAVING COUNT(*) >= 2;

If you add ec.outcome to the multi-valued parameter field, you need to update your rule as shown below:

@RSAAlert

SELECT * FROM Event(( 'Success' = ANY( ec_outcome ) ))

.win:time_length_batch(2 Minutes, 2)

HAVING COUNT(*) >= 2;

For more information, see “Configure Meta Keys as Arrays in ESA Correlation Rule Values” in the ESA Configuration Guide.

ESA Troubleshooting Information

Note: To avoid unnecessary processing overhead, the Ignore Case option has been removed from the ESA Rule Builder - Build a Statement dialog for meta keys that do not contain text data values. During the upgrade to 11.3.0.2, NetWitness Platform does not modify existing rules for the Ignore Case option. If an existing Rule Builder rule has the Ignore Case option selected for a meta key that no longer has the option available, an error occurs if you try to edit the statement and try to save it again without clearing the checkbox.

To support Endpoint and UEBA content as well as changes to ESA rules from Live, a data change from single-value (string) to multi-value (string array) is required for several meta keys within the ESA Correlation service. In NetWitness Platform 11.3.0.2 and later, ESA automatically adjusts the operator in the rule statement when there is a change from string to string array, but you still may need to make manual adjustments to adjust for the string array changes.

To change the string type meta keys to string array type meta keys manually in 11.3.0.2 and later, see “Configure Meta Keys as Arrays in ESA Correlation Rule Values” in the ESA Configuration Guide.

To use the latest Endpoint, UEBA, and Live content rules, the following default multi-valued meta keys are required on the ESA Correlation service in NetWitness Platform version 11.3.0.2 and later:

action , alert , alert.id , alias.host , alias.ip , alias.ipv6 , analysis.file , analysis.service , analysis.session , boc , browserprint , cert.thumbprint , checksum , checksum.all , checksum.dst , checksum.src , client.all , content , context , context.all , context.dst , context.src , dir.path , dir.path.dst , dir.path.src , directory , directory.all , directory.dst , directory.src , email , email.dst , email.src , eoc , feed.category , feed.desc , feed.name , file.cat , file.cat.dst , file.cat.src , filename.dst , filename.src , filter , function , host.all , host.dst , host.orig , host.src , host.state , inv.category , inv.context , ioc , ip.orig , ipv6.orig , netname , OS , param , param.dst , param.src , registry.key , registry.value , risk , risk.info , risk.suspicious , risk.warning , threat.category , threat.desc , threat.source , user.agent , username

The following default single-valued meta keys are also required on the ESA Correlation service in NetWitness Platform 11.3.0.2 and later:

accesses , context.target , file.attributes , logon.type.desc , packets

If you used any meta keys in the ESA rule notification templates from the Required String Array or String Meta Keys list, update the templates with the meta key changes. See "Configure Global Notification Templates" in the System Configuration Guide.

Note: Advanced EPL rules may get disabled and are not automatically updated so they must be fixed manually.

For additional troubleshooting information, see “Troubleshoot ESA” in the Alerting with ESA Correlation Rules User Guide for RSA NetWitness Platform.

Example ESA Correlation Server Warning Message for Missing Meta Keys

If you see a warning message in the ESA Correlation server error logs that means there is a difference between the default-multi-valued parameter and multi-valued parameter meta key values, the new Endpoint, UEBA, and Live content rules will not work. Completing the Task 19 - (Conditional) Update the Multi-Valued and Single-Valued Parameter Meta Keys for the latest Endpoint, UEBA, and RSA Live Content Rules procedure should fix the issue.

Multi-Valued Warning Message Example

2019-08-23 08:55:07,602 [ deployment-0] WARN Stream|[alert, alert_id, browserprint, cert_thumbprint, checksum, checksum_all, checksum_dst, checksum_src, client_all, content, context, context_all, context_dst, context_src, dir_path, dir_path_dst, dir_path_src, directory, directory_all, directory_dst, directory_src, email_dst, email_src, feed_category, feed_desc, feed_name, file_cat, file_cat_dst, file_cat_src, filename_dst, filename_src, filter, function, host_all, host_dst, host_orig, host_src, host_state, ip_orig, ipv6_orig, OS, param, param_dst, param_src, registry_key, registry_value, risk, risk_info, risk_suspicious, risk_warning, threat_category, threat_desc, threat_source, user_agent] are still MISSING from multi-valued

Single Value Warning Message Example

2019-08-23 08:55:07,602 [ deployment-0] WARN Stream|[accesses, context_target, file_attributes, logon_type_desc, packets] are still MISSING from single-valued

Investigate

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

After you upgrade to 11.3.0.2, 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.2 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 22 - 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.0.2 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.0.2 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 23 - (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 24 - 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 25 - Enable Metadata for GeoIP2 Parser

By default, the GeoIP2 parser generates less metadata than the GeoIP parser did. After updating to 11.3.0.2, 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 26 - Enable Threat - Malware Indicators Dashboard

In 11.3.0.2, 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.0.2.
  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.0.2, 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 27 - 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.0.2.

  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 28 - 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 29 - 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.0.2.
    This is the new file for 11.3.0.2.
  2. Edit the /var/lib/netwitness/respond-server/data/aggregation_rule_schema.json to include the custom keys you copied in step one.

Task 30 - Restore Customized Respond Service Normalization Scripts

RSA re-factored the Respond service normalization scripts in 11.3.0.2 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.0.2 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 31 - 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 32 - 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.0.2, so your existing 10.6.6.x settings will not migrate to 11.3.0.2.

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.0.2. No custom templates are supported in 11.3.0.2.

Task 33 - 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 34 - 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.0.2. After you upgrade to

11.3.0.2, 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 35 - Update Incident Rules Identified in the Domain Matching Conditions Upgrade Preparation Task

Modify the incident rules that you identified in the "Task 4 - Check Aggregation Rules Match Conditions for “Domain” or “Domain for Suspected C&C” in Upgrade Preparation Tasks, 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 36 - 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 37 - 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.

RSA Archer Cyber Incident & Breach Response

Task 38 - 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 39 - 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.0.2, 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 40 - 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 41 - Install Endpoint Log Hybrid and Endpoint Agents

See:

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

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

RSA NetWitness UEBA

Task 42 - Install NetWitness UEBA

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

See:

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

RSA NetWitness Platform 11.3.0.2 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 43 - 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 ".*", ".*", ".*"

 

You are here

Table of Contents > Post Upgrade Tasks

Attachments

    Outcomes