000013001 - RSA NetWitness Platform Investigator RDP session detailed view shows the session time as 60 seconds

Document created by RSA Customer Support Employee on Jul 22, 2016Last modified by RSA Customer Support on Oct 1, 2019
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000013001
Applies ToRSA Product Set: Security Analytics
RSA Product/Service Type: Security Analytics Investigation, Security Analytics Decoder
RSA Version/Condition: 10.x,11.x
Platform: CentOS
O/S Version: EL6/EL7 
IssueRSA NetWitness Investigation RDP session detailed view shows the session time as 60 seconds.
When viewing an RDP session in RSA NetWitness Investigation, the session time duration for the RDP session is showing at around 60 seconds, even though the actual RDP session is much longer.

This is a tradeoff in design, not a bug.

In decoder, there is a /decoder/config/assembler.timeout.packet (also /decoder/config/assember.timeout.session) parameter which is set to 60 seconds by default. This is intended to time the packets out of the packet pool and force session assembly/parsing activity and write the session to the database; the lifetime meta will always reflect the session lifetime at the time of parsing (~60 secs default). This comes into play when line rates are sufficiently low that waiting for the packet pool to fill would introduce latency beyond the timeout duration. When the packet pool is full, the oldest packets are removed when new packets are received and assembler.timespan will be less then assembler.timeout.packet.

Normal behavior is for a session to be parsed after a timeout is reached or it's forced out of the pool due to memory constraints. However, if the session is not finished, packets should continue to be chained to that session after parsing, assuming /decoder/config/assembler.session.flush is set to 1 (not working prior to, NEX-1452). The session will not be reparsed, but viewing the session in wireshark or in Investigator's content view will show the full packet capture, up until the session size limit is reached or until no more packets are seen according to the session timeout settings in /decoder/config/assember.timeout.session parameter.

So, if the session is finished at the time of parsing, then the meta is accurate. If the session continues, then any meta that would normally be affected by additional packets (lifetime, size, payload, etc) will obviously become less and less accurate as packets are added after parsing finishes. However, the bulk of the meta generated IS accurate, no matter how many additional packets are later added, it's only a few global session meta items that are typically affected.

Netwitness's greatest strength is the sessionization and parsing we do, which nobody else in the industry does. It also comes with a price, and this is it. If the session was never kicked out for parsing, you would never be able to query it. It can't be aggregated until meta is generated. You have to take the good with the bad.

You can adjust pool sizes and timeouts larger, but the consequence is the session stays hidden in assembler longer, so this is not a good solution.

NotesSee the knowledgebase articles What is a 'session' in regards to RSA NetWitness? and Why are RSA NetWitness Investigator session size and packet count values inaccurate? for additional details on assembler.timeout.session; assembler.timeout.packet and assembler.size.max parameters in a decoder /decoder/config node.
Legacy Article IDa58898