Skip navigation
All Places > Products > RSA NetWitness Platform > RSA NetWitness Platform Online Documentation > Documents
Log in to create and rate content, and to follow, bookmark, and share content with other members.

Upgrade Guide 11.5.1: Post Upgrade Tasks

Document created by RSA Information Design and Development Employee on Nov 11, 2020Last modified by RSA Information Design and Development Employee on Dec 11, 2020
Version 5Show Document
  • View in full screen mode
 

This topic is divided into two sections. Complete the tasks in one of the following sections based on your upgrade path:

Post Upgrade Tasks for Customers Upgrading from version 11.5.x.x

Complete the tasks that apply to the hosts in your environment.

User Entity Behavior Analytics

Task 1- Update UEBA Configurations

Perform the following steps after upgrading the UEBA to version 11.5.1.0.

IMPORTANT: In order to complete an upgrade process, every UEBA upgrade needs to be followed by upgrade steps.
In case of gradual upgrade, follow the instruction of each upgrade’s guide before continuing to the next upgrade.

Note: The Modeled Behaviors functionality is added to UEBA in 11.5.1. For any reason if you need to disable this functionality for your organization, see "Enable or Disable the Modeled Behaviors for Users" topic in the NetWitness UEBA Configuration Guide.

  1. (For Virtual Machines Only) Update the airflow parallelism on VM.

    If the UEBA system is running on VM, update the airflow parallelism to be 64 by running the following command as root from the UEBA host.

    sed -i "s|parallelism = 256|parallelism = 64|g" /var/netwitness/presidio/airflow/airflow.cfg

  2. Update the UEBA configuration using the following command as root from the UEBA machine.

    python /var/netwitness/presidio/airflow/venv/lib/python2.7/site-packages/presidio_workflows-1.0-py2.7.egg/presidio/resources/rerun_ueba_server_config.py

  3. (Optional) Update the UEBA processing schemas:

    Note: Adding a UEBA schema does not require to re-run the UEBA system if it was upgraded from version 11.5.0.

    To add a new UEBA schema, run the following command from the UEBA host.

    curl -X PATCH http://localhost:8881/configuration -H 'content-type: application/json' -d '{"operations":[{"op":"add","path":"/dataPipeline/schemas/-","value":"<SCHEMA>"}]}'

    where <SCHEMA> string is the schema that you can replace from the following list:

    AUTHENTICATION, FILE, ACTIVE_DIRECTORY, PROCESS, REGISTRY, and TLS.

  4. Run the airflow upgrade DAG.

    Note: An error message may appear at the top of the Airflow home page until the post upgrade process is complete.

    1. Go to Airflow main page https://<UEBA-host-name>/admin and enter the credentials.

      User: admin

      Password: The environment deploy admin password.

    2. Click the Play in presidio_upgarde_dag_from_<previous_version> to_11.5.1.0.

      Airflow

      Note: A light green circle will appear next to the upgrade DAG row during the upgrade. If the upgrade process is completed successfully the light green circle changes to green. If the upgrade process fails, the light green circle changes to red.

  5. Set the appropriate Boot Jar Pools according to the setup.

    • Physical Appliance: Update the spring_boot_jar_pool slot value be 18.

    • Virtual Appliance: Update the spring_boot_jar_pool slot values to 22.

    To update the number of Spring Boot Jar Pools:

    1. Go to the Airflow main page https://<UEBA_host>/admin and enter the credentials.

      User: admin

      Password: The environment deploy admin password.

    2. Click the Admin > Pools.
    3. Edit the spring_boot_jar_pool and update the slots amount.

      Airflow

Task 2- Update the User Entity Behavior Analytics Incident Rule Priority Thresholds, Grouping Options, and Title

In NetWitness 11.5.1, the Entity Behavior Analytics incident rule default priority threshold ranges are now consistent with the severity ranges in NetWitness UEBA. The rule also captures user entity behavior grouped by both UEBA Classifier Id and UEBA Entity Name. The incident name created by the rule uses the UEBA Entity Name.

It is important to update the User Entity Behavior Analytics incident rule priority thresholds for matched incidents, grouping options, and incident title to the 11.5.1 default values.

  1. Go to (Configure) > Incident Rules and in the Incident Rules list, double-click the User Entity Behavior Analytics incident rule.
  2. In the Grouping Options – Group By field, add UEBA Entity Name.
    You should have both UEBA Classifier Id and UEBA Entity Name.
    User Entity Behavior Analytics Incident Rule Grouping Option and Title changes
  3. In the Incident Options – Title field, change ${groupByValue1} to ${groupByValue2}:
    ${ruleName} for ${groupByValue2}

  4. In the Incident Options – Priority section, update the Critical, High, Medium, and Low priority thresholds to the default values.
  5.                              

    Priority ThresholdDefault Value
    Critical98
    High93
    Medium85
    Low1

    For example, with the Critical priority now set to 98, incidents with a risk score of 98 or higher are assigned a Critical priority for this rule.
    User Entity Behavior Analytics incident rule thresholds for NetWitness Platform 11.5.1 and later

     
  6. Click Save.

 

Post Upgrade Tasks for Customers Upgrading From 11.3.x.x or 11.4.x.x

Complete the tasks that apply to the hosts in your environment.

General

(Conditional) Configure NAT-Based IP Addresses

If you have a host, such as a VLC, that requires a NAT-based IP address in order to connect to the NW Server host, you must update the host configuration with the following steps.

  1. Log in to the host that requires the use of NAT IP addresses, using the console or SSH.
  2. Run the following command:
    nw-manage --enable-nat-usage
  3. To set the NAT address for the NW Server:
    1. Log into the NW Server using the console or SSH.
    2. Run the following command:
      nw-manage -update-host --host-id <UUID of NW Server> --ipv4-public <NAT IP of NW Server>
    3. Note: You can find the UUID and view the current NAT IP address of the host by running nw-manage --list-hosts.

(Conditional - For Warm-Standby Hosts Only) Register the Secondary IP Address of Warm-Standby Hosts

The Warm-Standby server must be upgraded to 11.5 or later before completing the following steps.

  1. Log in to the NW Server using the console or SSH.
  2. Run the following command:
    nw-manage --add-nws-secondary-ip --ipv4 <ip address of Warm/Standby Server>
  3. Note: If the Warm-Standby server requires a NAT-based IP address (IPv4-public) for any host to access it during failover, the NAT IP address must also be registered by running the following command: nw-manage --add-nws-secondary-ip --ipv4 <NAT-based IP address of Warm Standby Server>

  4. Verify the correct Warm Standby host IP address value by running the following command:
    nw-manage --get-nws-secondary-ip

Review Contents of /etc/hosts.user for Obsolete Host Entries

After upgrading the NW Server host or a component host, review the contents of the /etc/hosts.user file for any obsolete host entries. The /etc/hosts.user file contains system and user-generated entries that are not managed by NetWitness Platform. However, entries from /etc/hosts.user are merged with NetWitness Platform-generated host mappings to create and update /etc/hosts. To avoid conflicts with NetWitness Platform-generated mappings, and to avoid generating connectivity errors resulting from an IP address change, RSA recommends that you remove any entries in /etc/hosts.user that include a non-loopback IP address of a NetWitness Platform host.

After updating /etc/hosts.user, you must refresh the system by running the following command:
nw-manage --refresh-host --host-key <ID, IP, hostname or display name of host>

Reconfigure DNS Servers

By default, a component host upgraded from 11.4 or earlier is configured with the same system DNS server as the NW Server. If this component host requires a different system DNS address, see "Change Host Network Configuration" in the System Maintenance Guide for instructions.

Make Sure Services Have Restarted and Are Capturing and Aggregating Data

Make sure that services have restarted and are capturing data (this depends on whether or not you have auto-start enabled).

If required, restart data capture and aggregation for the following services:

  • Decoder
  • Log Decoder
  • Broker
  • Concentrator
  • Archiver

Start Network Capture

  1. In the NetWitness Platform menu, go to (Admin) > Services.
    The Services view is displayed.
  2. Select each Decoder service.
  3. Under (actions), select View > System.

  4. In the toolbar, click

Start Log Capture

    1. In the NetWitness Platform menu, go to (Admin) > Services.
      The Services view is displayed.
    2. Select each Log Decoder service.
    3. Under (actions), select View > System.
    4. In the toolbar, click
  • Start Aggregation

    1. In the NetWitness Platform menu, go to (Admin) > Services.

      The Services view is displayed.

    2. For each Concentrator, Broker, and Archiver service:

      1. Select the service.
      2. Under (actions), select View > Config.
      3. In the toolbar, click

    Event Stream Analysis (ESA)

    Note: Mixed mode is not supported for ESA hosts in NetWitness Platform version 11.5 and later. The NetWitness server, ESA primary host, and ESA secondary host must all be on the same NetWitness Platform version.

    There are no required post-upgrade tasks for ESA. For ESA troubleshooting, see ESA Troubleshooting Information.

    If you want to add support for Endpoint, UEBA, and Live content rules, you must update the multi-valued and single-valued parameter meta keys on the ESA Correlation service to include all the required meta keys. It is not necessary to make these adjustments during the upgrade; you can make the adjustments later at a convenient time. For detailed information and instructions, see "Update Your ESA Rules for the Required Multi-Value and Single-Value Meta Keys" in the ESA Configuration Guide.

    New Health and Wellness

    Note: New Health and Wellness in 11.5.x.x replaces Next GEN Health and Wellness (BETA) in 11.4.x.x.

    Deploy the New Health and Wellness Content from Live

    After you upgrade from version 11.4.x.x to 11.5.1.0, New Health and Wellness content is not updated. To use the latest (default) content, you must deploy the content through NetWitness Live Services.

    Note: RSA recommends you to take a copy of 11.4.x.x Health and Wellness content before you deploy the content from NetWitness Live Services, as it overwrites the existing content.

    1. Log in to NetWitness Platform UI.

    2. Click (CONFIGURE) > LIVE CONTENT.

    3. In the Search Criteria panel, select the Resource Types as:

      • Health and Wellness Dashboards
      • Health and Wellness Monitors
    4. Click Search.

    5. In the Matching Resources view, select the checkbox to the left of the resources that you want to deploy.

    6. In the Matching Resources toolbar, click .

    7. In the Deployment Wizard > Resources tab, click Next.

    8. In the Services tab, select the Metrics Server service.

    9. Click Next.

    10. Click Deploy.
      The Deploy page is displayed. The Progress bar turns green when you have successfully deployed the resources to the selected services.

    11. Click Close.

    (Optional) Update UUID of New Health and Wellness Host to Update Service Configuration Documents

    If you have configured services for New Health and Wellness from nw-shell using set-config API and upgrade NetWitness Platform version from 11.4.x.x to 11.5.1.0, you must update IP with UUID for a host on which New Health and Wellness is installed.

    This is an example of service configuration file with the file path /root/example_config.json

    {

    "service" : "concentrator",

    "serviceId" : "6c552cde-4153-4e1b-a0a0-c74e8756cce1",

    "enabled" : true,

    "username" : "nwservice",

    "password" : "4f809baabcbe7ed663c10e4cf786ce24",

    "port" : 9200,

    "secure" : true,

    "host" : "196.168.0.1",

    "verifyHostname" : false,

    "conversionUnit" : "SECONDS",

    "interval" : "60 SECONDS",

    "exclusion" : [ ],

    "inclusion" : [

    "/concentrator/**",

    "/database/**",

    "/sdk/**",

    "/sys/**"

    ]

    }

    To update UUID of a host:

    1. SSH to Admin Server.

    2. Check the UUID of a host on which New Health and Wellness is installed using the command:
      orchestration-cli-client --list-hosts

      This lists NetWitness Platform hosts along with the respective UUIDs. Make a note of the UUID of host on which New Health and Wellness is installed.

    3. Identify the services on which set-config API is invoked using the command:
      mongo localhost/metrics-server -u deploy_admin -p <deployment_password> --authenticationDatabase admin --eval 'db.metric_config.find({ "createdBy": { $ne: "system" }})'
      This will list the configuration documents of the services on which set-config API is invoked.
      Sample output
      { "_id" : ObjectId("5f83f44b913a613985072396"), "port" : 0, "secure" : true, "family" : "NEXTGEN", "service" : "concentrator", "enabled" : true, "interval" : { "duration" : NumberLong(120), "unit" : "SECONDS" }, "inclusion" : [ "/concentrator/**", "/database/**", "/sdk/**", "/sys/**" ], "exclusion" : [ "/concentrator/config/recovery/**", "/concentrator/config/rules/**", "/concentrator/devices/**", "/sdk/stats/queries/**", "/sys/config/scheduler/**" ], "forceDisabled" : false, "createdBy" : "admin", "createdOn" : NumberLong("1602483359444"), "lastModifiedBy" : "system", "lastModifiedOn" : NumberLong("1604382316156"), "_class" : "com.rsa.asoc.metrics.config.ElasticConfigUpdateEntity" }

    Note: If no service documents are listed which means no services are configured before the upgrade, so you can ignore the remaining steps.

    1. In the configuration file, update the service document “host” field by replacing IP with the UUID of the host on which New Health and Wellness is installed.

    For example, "host" : "196.168.0.1" will become "host" : "e28665d5-1c2c-dbe3-1b9e- 4767271ce805"

    Note: If you do not know the file used for configuration (For example, /root/example_config.json). You can create a new file containing the configuration of the service.
    To create new configuration file:
    1) List all the services using the following command:
    orchestration-cli-client --list-services
    Result
    Service-ID of the service is displayed. For example,
    2020-12-01 10:11:30.195 INFO 11535 --- [ main] c.r.n.i.o.c.OrchestrationApplication : Service: ID=60a97481-1568-4da1-b91a-e0f0b38836d4, NAME=concentrator, HOST=196.168.0.1:56005, TLS=true
    2) To get the current configuration of the same service run the following commands:
    a) SSH to Admin Server
    b) Log in to nw-shell
    c) Run the following command:
    connect --service metrics-server
    d) Navigate to the below location:
    /rsa/metrics/elastic/get-config
    e) Run the following command:
    invoke <service_id> [example: invoke 60a97481-1568-4da1-b91a-e0f0b38836d4]
    Result:
    example_config.json
    {
    "service" : "concentrator",
    "serviceId" : "6c552cde-4153-4e1b-a0a0-c74e8756cce1",
    "enabled" : true,
    "username" : "nwservice",
    "password" : "4f809baabcbe7ed663c10e4cf786ce24",
    "port" : 9200,
    "secure" : true,
    "host" : "196.168.0.1",
    "verifyHostname" : false,
    "conversionUnit" : "SECONDS",
    "interval" : "60 SECONDS",
    "exclusion" : [ ],
    "inclusion" : [
    "/concentrator/**",
    "/database/**",
    "/sdk/**",
    "/sys/**"
    ]
    }

    3) Copy the Configuration file above (For example, /root/example2_config.json) and save it in a file (For example, /root/example2_config.json).

    1. Log in to nw-shell using the command:
      nw-shell
    2. Connect to metrics-server service using the command:
      connect --service metrics-server
    3. Enter the log in command:
      login

    4. Enter the admin username and password.
    5. Go to /rsa/metrics/elastic/set-config and invoke configuration files using the command:
      invoke --file /<absolute_path_of_service_config_file>
      For example, invoke --file /root/example2_config.json

    (Optional) Uninstall New Health and Wellness

    To uninstall New Health and Wellness, perform the following:

    1. Take a backup of NetWitness Server host. For more information, see “Disaster Recovery (Back Up and Restore)” topic in the NetWitness Recovery Tool User Guide.

      nw-recovery-tool --export --dump-dir /some/folder --category AdminServer --category Search

      Note: If New Health and Wellness is not installed on NetWitness Server, you must take a backup of the host on which New Health and Wellness is installed.

    2. Make sure that the installation or upgrades are not in progress and stop the orchestration server on NetWitness Server host:

      systemctl stop rsa-nw-orchestration-server

    3. Remove the New Health and Wellness service category (“Search") from the host:

      1. SSH to Admin server

      2. Fetch host details where New Health and Wellness is installed using the following command:
        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.find({ "installedServices": /.*Search.*/i })'

        Sample output

        { "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8", "hostname" : "10.10.10.11", "ipv4" : "10.10.10.11", "ipv4Public" : "", "displayName" : "adminserver", "version" : { "major" : 11, "minor" : 5, "servicePack" : 0, "patch" : 0, "snapshot" : false, "rawVersion" : "11.5.1.0" }, "lastFailedRefreshAttempt" : NumberLong(0), "refreshAttemptDelayFactor" : 0, "thirdParty" : false, "installedServices" : [ "Search", "AdminServer" ], "meta" : { "node-zero" : true }, "_class" : "com.rsa.asoc.orchestration.host.HostEntity" }

      3. Remove the "Search" from the installedServices.

      IMPORTANT: Do not remove any other category names.

      1. Replace <LIST-OF-CATEGORIES-EXCEPT-SEARCH> with a comma-delimited AND double-quoted list of all the existing installed services found earlier EXCEPT "Search":
        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.update({ "_id" : "<hw-node-uuid>" },{$set: {"installedServices" : [ <LIST-OF-CATEGORIES-EXCEPT-SEARCH> ]}})'

        Example
        mongo localhost/orchestration-server -u deploy_admin -p netwitness --authenticationDatabase admin --eval 'db.host.update({ "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8" },{$set: {"installedServices" : [ "AdminServer" ]}})'

        Sample output

        MongoDB shell version v4.0.19

        connecting to: mongodb://localhost:27017/orchestration-server?authSource=admin&gssapiServiceName=mongodb

        Implicit session: session { "id" : UUID("04e32380-347e-4b7d-a63e-a094536d7242") }

        MongoDB server version: 4.0.19

        WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })

      2. Make sure that the "Search" category is removed in the updated host record in the installedServices :

        mongo localhost/orchestration-server -u deploy_admin -p <deploy_admin-password> --authenticationDatabase admin --eval 'db.host.find({ "_id" : "<hw-node-uuid>" })'

        Example

        mongo localhost/orchestration-server -u deploy_admin -p netwitness --authenticationDatabase admin --eval 'db.host.find({ "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8" })'

      Note: Any inconsistencies can result in unrecoverable errors.

      Sample output

      { "_id" : "56f2a90b-1f03-d09a-fb71-42c2a93958a8", "hostname" : "10.10.10.11", "ipv4" : "10.10.10.11", "ipv4Public" : "", "displayName" : "adminserver", "version" : { "major" : 11, "minor" : 5, "servicePack" : 0, "patch" : 0, "snapshot" : false, "rawVersion" : "11.5.1.0" }, "lastFailedRefreshAttempt" : NumberLong(0), "refreshAttemptDelayFactor" : 0, "thirdParty" : false, "installedServices" : [ "AdminServer" ], "meta" : { "node-zero" : true }, "_class" : "com.rsa.asoc.orchestration.host.HostEntity" }

    4. Stop the New Health and Wellness services:

      systemctl stop rsa-nw-metrics-server elasticsearch opendistro-performance-analyzer kibana

    5. Disable the New Health and Wellness services:

    systemctl disable rsa-nw-metrics-server elasticsearch opendistro-performance-analyzer kibana

    1. Uninstall the New Health and Wellness packages using the command:

      yum erase -y rsa-nw-metrics-server opendistroforelasticsearch opendistroforelasticsearch-kibana

      Note: rsa-nw-shell (installed with metrics server) is a shared package and should not be removed.

    2. Remove the configuration folders or files:
      • /etc/netwitness/metrics-server
      • /etc/netwitness/platform/elasticsearch
      • /etc/netwitness/platform/nodeinfo/metrics-server
      • /etc/netwitness/platform/nodeinfo/elasticsearch-open-distro
      • /etc/netwitness/platform/nodeinfo/kibana-open-distro
      • /etc/systemd/system/rsa-nw-metrics-server.service.d
      • /etc/systemd/system/elasticsearch.service.d
      • /etc/pki/nw/service/bootstrap/metrics-server.completed
      • /etc/pki/nw/service/rsa-nw-metrics-server-cert.pem
      • /etc/pki/nw/service/rsa-nw-metrics-server.chain
      • /etc/pki/nw/elastic
      • /etc/pki/nw/kibana
      • /var/log/netwitness/metrics-server
      • /var/log/kibana
      • /etc/collectd.d/rsa-metrics-server.conf
      • /etc/logrotate.d/kibana
      • /etc/elasticsearch
      • /etc/kibana
      • /var/lib/elasticsearch
      • /var/lib/kibana
      • /var/netwitness/elasticsearch
    3. Start the orchestration Server on NetWitness Server:
      systemctl start rsa-nw-orchestration-server

    4. Unregister the New Health and Wellness from the installedService:

      1. Find the service IDs for metrics-server, elasticsearch-open-distro, and kibana-open-distro

        Note: Make sure you look for service IDs for the correct host; do not unregister elastic or kibana on an UEBA host.

        orchestration-cli-client --list-services | grep <hw-node-IP-address>

        Sample output

        ID=50082d04-320c-4ce2-8379-00f38ae2d1df, NAME=metrics-server, HOST=192.168.1.2:7018, TLS=true

        ID=530ff46a-8793-4e8e-be9c-742193d1705a, NAME=elasticsearch-open-distro, HOST=192.168.1.2:9200, TLS=true

        ID=4bad6ea8-e3a4-46ab-a342-34356bea65bb, NAME=kibana-open-distro, HOST=192.168.1.2:5601, TLS=true

        ... (other services) ...

      2. Remove the service IDs returned above for metrics-server, elasticsearch-open-distro, and kibana-open-distro (associated with New Health new Wellness host):

        orchestration-cli-client --remove-service --id <metrics-server-service-id>

        orchestration-cli-client --remove-service --id <elasticsearch-open-distro-service-id>

        orchestration-cli-client --remove-service --id <kibana-open-distro-service-id>

      3. Verify if the services are removed:

        orchestration-cli-client --list-services | grep <hw-node-IP-address>

    5. On all hosts, except for UEBA, stop and disable metricbeat:

      systemctl stop metricbeat

      systemctl disable metricbeat

      Note: For NetWitness Platform without UEBA, you can stop and disable metricbeat on all hosts through salt:
      salt '*' cmd.run 'systemctl stop metricbeat && systemctl disable metricbeat'

    6. (Optional) - If you are not reinstalling New Health and Wellness (on same or other hosts), you can also remove metricbeat package and configuration:
      1. Package to uninstall:
        metricbeat
      2. Service configurations to uninstall:
        • /etc/metricbeat

        • /var/log/metricbeat

        • mongo account

        • systemd configuration

    1. Refresh the New Health and Wellness host:
      nw-manage --refresh-host --host-key <node-ip>
      Make sure that the New Health and Wellness service is not installed or running and metricbeat service is not active on the New Health and Wellness host.

    2. If you are not reinstalling New Health and Wellness on another host, you must refresh UI hosts (NetWitness Server host and Analyst UI) to update NGNIX:

      nw-manage --refresh-host --host-key <node-ip>

    Note: After uninstalling New Health and Wellness, if you want to install New Health and Wellness again, see "New Health and Wellness" in the Deployment Guide.

    Investigate

    (Conditional - For Custom Roles Only) Adjust investigate-server Permissions for Custom User Roles

    If you are upgrading from a version prior to 11.5, after upgrading to version 11.5 or later, the built-in user roles for analysts (and others) using Investigate have the investigate-server.event.filter permission enabled, but the upgrade process does not enable the permission for custom user roles. Users who are assigned a custom user role that does not have this permission enabled cannot see the Filter Events panel, a new panel in 11.5.x.x where they can drill into metadata.

    Note: When upgrading from Version 11.3.x.x or earlier, the built-in user roles for analysts using Investigate have three additional permissions added in Version 11.4 enabled, but the upgrade process does not enable the permissions for custom user roles. Users who are assigned a custom user role that does not have these permissions cannot see the Navigate view and Legacy Events view in the Investigate menu. The three permissions that need to be enabled for custom user roles are:
    investigate-server.columngroup.read, investigate-server.metagroup.read, and investigate-server.profile.read

    To enable the permissions for a user role:

    1. Go to (Admin) > Security and click the Roles tab.
    2. Select the custom user role that needs to be edited and click (edit icon).
    3. In the Edit Role dialog, ensure that these four permissions are enabled:
      investigate-server.event.filter
      investigate-server.columngroup.read
      investigate-server.metagroup.read
      investigate-server.profile.read
    4. Click Save to save your changes. When analysts with the custom user role log in to the NetWitness Platform, the changes are in effect.

    Respond

    The Primary ESA server must be upgraded to 11.5.1.0 or later before you can complete these tasks.

    Note: After upgrading the primary NW Server (including the Respond Server service), the Respond Server service is not automatically re-enabled until after the Primary ESA host is also upgraded to 11.5.1.0. The Respond post-upgrade tasks only apply after the Respond Server service is upgraded and is in the enabled state.

    (Conditional) Restore Any Respond Service Custom Keys in the Aggregation Rule Schema

    Note: If you did not manually customize the incident aggregation rule schema, you can skip this task.

    If you added custom keys in the var/lib/netwitness/respond-server/data/aggregation_ rule_schema.json file for use in the groupBy clause for 11.x, modify the /var/lib/netwitness/respond-server/data/aggregation_rule_schema.json file and add the custom keys from the automatic backup file.

    The backup file is located in /var/lib/netwitness/respond-server/data and it is in the following format:
    aggregation_rule_schema.json.bak-<time of the backup>

    (Conditional) Restore any Customized Respond Service Normalization Scripts

    Note: If you did not manually customize any alert normalization scripts, you can skip this task.
    This procedure applies to upgrades from 11.3.x to 11.5.1.0. (For upgrades from 11.4.x to 11.5.1.0, there are no backups of the normalization script files since customizations are in separate custom_normalize script files, which are not overwritten during the upgrade.

    To prevent overwriting future customizations, custom normalization script files are available in NetWitness Platform 11.4 and later. Add any custom logic to the custom_normalize_<alert type>.js files.

    1. Locate any custom logic from the backup Respond normalization scripts located in the /var/lib/netwitness/respond-server/scripts.bak-<timestamp> directory, where <timestamp> is the time that the backup completed:
      data_privacy_map.js
      normalize_alerts.js
      normalize_core_alerts.js
      normalize_ecat_alerts.js
      normalize_ma_alerts.js
      normalize_ueba_alerts.js
      normalize_wtd_alerts.js
      utils.js

    2. Edit the new 11.4 or later script files in the /var/lib/netwitness/respond-server/scripts directory to include any logic from the back up files. If you have any customizations in the normalization files, add them to the normalization files with the custom prefix.
      data_privacy_map.js
      custom_normalize_alerts.js
      custom_normalize_core_alerts.js
      custom_normalize_ecat_alerts.js
      custom_normalize_ma_alerts.js
      custom_normalize_ueba_alerts.js
      custom_normalize_wtd_alerts.js
      utils.js

      For Example, the custom_normalize_core_alerts.js is the normalization script for ESA to add any custom logic. This java script file has a function ‘normalizeAlert’ with the parameters headers, rawAlert, and normalizedAlert. The variable ‘normalized’ is an immutable copy object, which has an embedded object of a list of normalized events. So if you have any custom meta keys configured for the events then you have to iterate through the ‘normalized.events’ to populate the appropriate meta keys with values from the ‘rawAlert.events’ object. Below is the sample code.

       

      normalizeAlert = function (headers, rawAlert, normalizedAlert) {

      // normalizedAlert is the immutable copy of ootb normalizer alert, make sure you use

      // normalized object to update/set the values in your scripts

      var normalized = Object.assign(normalizedAlert);

      var custom_events;

      if(normalized.events !== undefined) {

      custom_events = normalized.events;

       

      } else {

      custom_events = new Array([]);

       

      }

      for (var i = 0; i < rawAlert.events.length; i++) {

      custom_events[i].legalentity=Utils.stringValue(rawAlert.events[i].isgs_legalentity);

      custom_events[i].companycode=Utils.stringValue(rawAlert.events[i].isgs_companycode);

       

      }

       

      if(normalized.events === undefined){

      normalized.events = custom_events;

      }

      return normalized;

      };


      You can also look at the built-in Respond normalization script files for reference, such as normalize_alerts.js. For more information, see "Configure Custom Respond Server Alert Normalization" in the NetWitness Respond Configuration Guide.

    Update the User Entity Behavior Analytics Incident Rule Priority Thresholds, Grouping Options, and Title

    In NetWitness 11.5.1, the Entity Behavior Analytics incident rule default priority threshold ranges are now consistent with the severity ranges in NetWitness UEBA. The rule also captures user entity behavior grouped by both UEBA Classifier Id and UEBA Entity Name. The incident name created by the rule uses the UEBA Entity Name.

    It is important to update the User Entity Behavior Analytics incident rule priority thresholds for matched incidents, grouping options, and incident title to the 11.5.1 default values.

    1. Go to (Configure) > Incident Rules and in the Incident Rules list, double-click the User Entity Behavior Analytics incident rule.
    2. In the Grouping Options – Group By field, add UEBA Entity Name.
      You should have both UEBA Classifier Id and UEBA Entity Name.
      User Entity Behavior Analytics Incident Rule Grouping Option and Title changes
    3. In the Incident Options – Title field, change ${groupByValue1} to ${groupByValue2}:
      ${ruleName} for ${groupByValue2}

    4. In the Incident Options – Priority section, update the Critical, High, Medium, and Low priority thresholds to the default values.
    5.                              

      Priority ThresholdDefault Value
      Critical98
      High93
      Medium85
      Low1

      For example, with the Critical priority now set to 98, incidents with a risk score of 98 or higher are assigned a Critical priority for this rule.
      User Entity Behavior Analytics incident rule thresholds for NetWitness Platform 11.5.1 and later

       
    6. Click Save.

    Reference Log Decoder

    For full functionality, make sure your reference Log Decoder is at 11.5 or later. If you never set up a reference Log Decoder, there is no need to take action. For details, see the Log Parser Customization Guide.

    Windows Log Collector

    Update the Windows Log Collector UUID

    After upgrading to 11.5 or later, for each Windows Log Collector configured in your environment, run the following command on the NW Server:

    wlc-cli-client --update-to-uuid --host <WLC host address>

    Context Hub

    Disable the UCF configuration

    Disable the UCF (Unified Collection Framework) configuration to stop sending events to NetWitness Platform. Do the following steps.

    1. On the UCF host, stop the UCF services (SA SecOps Watchdog, RSA Unified Collector Framework). For more information, see "Manage Unified Collector Framework" topic in Archer Integration Guide for RSA NetWitness Platform.
    2. Create a backup of the collector-config.properties file which is in the following location.
      C:\Program Files\RSA\SA IM integration service\config
    1. In the collector-config.properties file, comment the lines that starts with “archer.ArcherPull.baseUri = xxx” by adding # character before the line.
      For example,
      #archer.ArcherPull.baseUri = xxx
      #archer.ArcherPull.instance = xxx
      #archer.ArcherPull.userName = xxx
      #archer.ArcherPull.password = xxx
      #archer.ArcherPull.readWrite = xxx
      #archer.ArcherPull.moduleId.dataBreach = xxx
      #archer.ArcherPull.moduleId.incident = xxx

    1. Also delete the value “ArcherPull” in all the lines. For example, for the line “archer.configured.endpoints = ArcherPull,ArcherPush”, delete “ArcherPull” but retain the other values. “archer.configured.endpoints = ArcherPush
    1. Start the UCF services (SA SecOps Watchdog, RSA Unified Collector Framework). For more information, see "Manage Unified Collector Framework" topic in Archer Integration Guide for RSA NetWitness Platform.

    Update UEBA Configurations

    IMPORTANT: In order to complete an upgrade process, every UEBA upgrade needs to be followed by upgrade steps.
    In case of gradual upgrade, follow the instruction of each upgrade’s guide before continuing to the next upgrade.

    IMPORTANT: The UEBA system requires a re-run in the following cases:
    (a) When removing a UEBA schema.
    (b) When the UEBA is upgraded from 11.3.x or from a lower version.
    The UEBA system does not require a re-run in case of upgrading from 11.4.x or higher version (even in case of adding a schema).

    Note: The Modeled Behaviors functionality is added to UEBA in 11.5.1. For any reason if you need to disable this functionality for your organization, see "Enable or Disable the Modeled Behaviors for Users" topic in the NetWitness UEBA Configuration Guide.

    1. (For Virtual Machines Only) Update the airflow parallelism on VM.

      If the UEBA system is running on VM, update the airflow parallelism to be 64 by running the following command as root from the UEBA host.

      sed -i "s|parallelism = 256|parallelism = 64|g" /var/netwitness/presidio/airflow/airflow.cfg

    2. Update the UEBA configuration using the following command as root from the UEBA machine.

      python /var/netwitness/presidio/airflow/venv/lib/python2.7/site-packages/presidio_workflows-1.0-py2.7.egg/presidio/resources/rerun_ueba_server_config.py

    3. (Optional) Update the UEBA processing schemas:

      • In case of upgrade from 11.4.x or higher versions:

        To add a new UEBA schema, run the following command from the UEBA host.

        curl -X PATCH http://localhost:8881/configuration -H 'content-type: application/json' -d '{"operations":[{"op":"add","path":"/dataPipeline/schemas/-","value":"<SCHEMA>"}]}'

        where <SCHEMA> string is the schema that you can replace from the following list:

        AUTHENTICATION, FILE, ACTIVE_DIRECTORY, PROCESS, REGISTRY, and TLS.

      • In case of upgrade from 11.3.x or lower versions:

        Upgrade from version 11.3.x or lower requires re-run of the UEBA system.

        RSA recommends that the UEBA start date is set to 28 days earlier than the current date. For UEBA systems that intend to process TLS data, you must make sure that the start date is set to no later than 14 days earlier than the current date.

        Use the reset_presidio.py script to update the UEBA system, by running the following commands from the UEBA host:

        source /etc/sysconfig/airflow

        source $AIRFLOW_VENV/bin/activate

        OWB_ALLOW_NON_FIPS=on python /var/netwitness/presidio/airflow/venv/lib/python2.7/site-packages/presidio_workflows-1.0-py2.7.egg/presidio/utils/airflow/reset_presidio.py --help

        For more information about the script, see "reset-presidio script" section in the NetWitness UEBA Configuration Guide.

    4. Run the airflow upgrade DAG.

      Note: An error message may appear at the top of the Airflow home page until the post upgrade process is complete.

      1. Go to Airflow main page https://<UEBA-host-name>/admin and enter the credentials.

        User: admin

        Password: The environment deploy admin password.

      2. Click the Play in presidio_upgarde_dag_from_<previous_version> to_11.5.1.0.

        Note: A light green circle will appear next to the upgrade DAG row during the upgrade. If the upgrade process is completed successfully the light green circle changes to green. If the upgrade process fails, the light green circle changes to red.

    5. Set the appropriate Boot Jar Pools according to the setup.

      • Physical Appliance: Update the spring_boot_jar_pool slot value be 18.

      • Virtual Appliance: Update the spring_boot_jar_pool slot values to 22.

      To update the number of Spring Boot Jar Pools:

      1. Go to the Airflow main page https://<UEBA_host>/admin and enter the credentials.

        User: admin

        Password: The environment deploy admin password.

      2. Click the Admin > Pools.
      3. Edit the spring_boot_jar_pool and update the slots amount.

    Previous Topic:Upgrade Tasks
    You are here
    Table of Contents > Post Upgrade Tasks

    Attachments

      Outcomes