This post details some of the implications of running in a mixed-mode environment. For the purposes of this post, a mixed-mode environment is one in which some services are running on RSA Security Analytics 10.6.x, and others are running on RSA NetWitness 11.x.
Note: RSA strongly suggests upgrading your 10.x services to 11.x to match your NetWitness server version, but running in Mixed-Mode allows you to stage your upgrade, especially for larger environments. |
If you run in a mixed-mode environment for an extended time, you may see or experience some or all of the following behaviors:
Overall Administration and Management Functionality
- If you add any 10.6.x hosts, you must add them manually to the v11.x architecture.
- There is no automatic discover, or trust establishment via certificates.
- You need to manually add them through username and password.
- In 11.x, a secondary or alternate NetWitness (NW) Server is not currently supported, though this may change for future NetWitness versions.
- Only the Primary NW Server could be upgraded (which would become "Node0").
- Secondary NW Servers could be re-purposed to other host types.
- The Event Analysis View is not available at all in mixed mode, and will not work until ALL devices are upgraded to 11.x.
Mixed Brokers
If you do not upgrade all of your Brokers, the existing Navigate and Event Grid view will still be available.
Implications for ESA
If you follow the recommended upgrade procedure for ESA services, note the following:
- During the ESA upgrade, the following mongo collections are moved from the ESA mongodb to the NW Server mongodb:
- im/aggregation_rule.*
- im/categories
- im/ tracking_id_sequence
- context-wds/* // all collections
- datascience/* // all collections
- The upgrade process performs some reformatting of the data: so make sure to follow those procedures as described in the Physical Host Upgrade Guide and Physical Host Upgrade Checklist documents, available on RSA Link. One way to find these documents is to open the Master Table of Contents, where links are listed in the Installation and Upgrade section.
IMPORTANT! | You MUST upgrade your ESA services at the same time you upgrade the NetWitness Server. If you do not, you will have to re-image all of the ESA services as new, and thus lose all of your data. Also, if you do not plan on updating your ESA services, you would need to REMOVE them from the 10.6.x Security Analytics Server before you start your upgrade |
Hosts/Services that Remain on 10.6.x
- If you add a 10.6.x host after you upgrade to 11.x, no configuration management is available through the NetWitness UI. You must use the REST API for this. Existing 10.6.x devices will be connected and manageable via 11.x -- as long as you do not remove any aggregation links.
- You need to aggregate from 10.6.x hosts to 11.x hosts manually.
- For example, for a Decoder on 10.6.x and a Concentrator on 11.x:
- Same applies for any other 11.x service that is aggregating from a 10.6.x host.
- If you have a secondary Security Analytics Server, RSA recommends that you keep it online to manage any hosts or services that still are running 10.6.x, until you have upgraded them all to 11.x.
Hybrids
If you are doing an upgrade on a system that has hybrids, the communication with the hybrids will still be functional. The Puppet CA cert is used to as the cert for the upgraded 11.x system, so the trust is still in place.
For example, if you have a system with a Security Analytics or NetWitness Server, an ESA service, and several hybrids, you can upgrade the NW Server and the ESA service, and communications with the hybrids will still work.
Recommended Path Away from Mixed-Mode
For large installations, you can upgrade services in phases. RSA recommends working "downstream." For example:
- For the initial phase (phase 1), upgrade the NW Server, ESA and Malware services. Also, upgrade at least the top-level Broker. If you have multiple Brokers, the suggestion is to upgrade all of them in phase 1.
- For phase 2, upgrade your concentrators, decoders, and so forth. The suggestion is to upgrade the concentrators and decoders in pairs, so they can continue communicating correctly with each other.