000026549 - Performance impact and considerations for deploying SSL on RSA NetWitness NextGen systems

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000026549
Applies ToRSA NetWitness NextGen
RSA NetWitness Decoder
RSA NetWitness Log Decoder
RSA NetWitness Concentrator
RSA NetWitness Hybrid
RSA NetWitness Broker
IssuePerformance impact and considerations for deploying SSL on RSA NetWitness NextGen systems.
How will enabling SSL affect my NetWitness appliances?
Resolution

NetWitness NextGen systems support SSL encryption for appliance-to-appliance and client-to-appliance communications.  How to enable and use SSL is covered in the NextGen Administrator's Guide as well as the knowledgebase article How to enable SSL on an RSA NetWitness NextGen appliance.  This solution only discusses the performance impacts of SSL on the NextGen System.


Impact:
Generally the impact of enabling SSL between client and appliance is significantly less than enabling SSL between appliances.  This is a straight factor of the amount and frequency of traffic passed in the two types of sessions.
Appliance to Appliance
In appliance to appliance communications, vast and usually continuous streams of data are being passed.  These streams come in bursts as the data is packaged encrypted for transport.  Being in mind that a Decoder aggregating the rated limit of 1Gbps will in many cases be passing 10% of that traffic up to a Concentrator in the form of meta in a series of sessions.  Scale that up the three attached Decoders and you have 300Mbps of SSL traffic in the form of numerous discrete sessions.  Each session requires the full SSL handshake which includes numerous steps.  While an SSL handshake is not very processor intensive to newer processors, there are many discrete steps and these steps coupled with both the raw volume of data and the high number of sessions could lead to a dramatic and potentially detrimental amount of overhead leading to aggregation falling behind on Decoder-Concentrator pairs.
Client to Appliance
Unlike the constant data stream from one appliance to another, a client request is a small, discrete request to an appliance in the form of a query.  The appliance then searches for the data and queries one or more levels of downstream devices, reassembles the results and returns them to the client.  Again, this is a discrete and relatively small data transfer.  Under almost all circumstances, the impact on the appliance the the user experience will be minimal.  The exception may be when the client is an automated, highly-repetitive call like an SDK call from an automated query agent or an Informer appliance running a high volume of reporting and/or alerting.
Alternatives:
SSL may be the only alternative if requirements dictate however, if permissible, there are alternatives that can mitigate the risks of traffic interception.  Among them:
If possible devices may be direct-connected. 


  • Direct Connection.  For example a Decoder can be directly connected to a Concentrator via a single Ethernet cable
  • VLAN or ACL segregation in network equipment.  Setting up a NetWitness-specific VLAN or setting up ACLs on network equipment to restrict access to NetWitness appliances.
  • High-speed in-line encryption gear.  Hardware-based encryption gear that doesn't significantly impact line speed and is transparent to the appliances/clients may be used. 

Additional Consideration:
Is SSL truly a requirement? The communication protocol between NetWitness products is proprietary and asynchronous.  It is binary encoded so data is not passed clear text.  Regarding authentication, with SSL or not we are passing salted hash values, so the authentication is secure.

Legacy Article IDa58782

Attachments

    Outcomes