Skip to content
  • There are no suggestions because the search field is empty.

RSA NetWitness generates a new incident and it is successfully received by RSA Archer's Unified Collector Framework (UCF) Service but a new incident is not created in RSA Archer

Issue

  • New Incidents created in NetWitness and sent to UCF are not created in Archer.
  • New Alerts that are created in NetWitness and sent to UCF are associated with old Security Incident records in Archer.
  • UCF service had successfully received the new incident, processed the new incident, and pushed the new incident to Archer as per UCF collector.log file.
 
07 Jan 2020 15:01:52,263 | INFO - ArcherDataStoreTasklet.pushToArcher(362) | Pushing message to Archer: 1 - SecurityIncident -

07 Jan 2020 15:01:52,263 | INFO - ArcherDataStore.handleData(423) | PERF(Archer DS Received Request)

07 Jan 2020 15:01:59,443 | WARN - ArcherDataStore.handleData(481) | PERF(Archer DS Processed Request - 7180 milliseconds)

07 Jan 2020 15:01:59,443 | INFO - PasswordAwareSimpleJobLauncher$1.run(100) | Job: [FlowJob: [name=pushIncidents]] completed with the following status: [COMPLETED]

Important Note: This issue has also been found in environments where multiple RSA NetWitness servers are generating incidents and sending them to the same Archer instance. The sequential incident #s between the two NetWitness servers overlap, and the UCF cannot properly identify the correct security incident records in Archer for each Security Incident received from NetWitness.  Multiple NetWitness servers sending new security incidents to the same Archer instance are not supported as per (ARCHER-51820) and are not covered or resolved by this KB.

Cause

  1. It is standard practice to copy Production Archer instance databases down into the lower environments for testing purposes.
  2. NetWitness uses a sequential number (ex: INC-12345) for Incidents generated in NetWitness. 
  3. The incidents are then sent to the Unified Collector Framework (UICF) service. 
  4. The hash_code field in the Security Incidents application of Archer contains the NetWitness Incident ID#. This value is, by design, different from the Archer Incident ID#. 
  5. The Security Incidents application in Archer is searched for records that have a hash_code field value matching the Incident ID # received by NetWitness. 
  6. The [hash_code] field in the Security Incidents application which contains the NetWitness Incident# in Archer is off the layout and disabled for search.  For troubleshooting this issue, put it on layout and enable it for search. 
  7. If an existing Security Incident record matching the specified (hash_code) field which contains the NetWitness Incident # is found, then this is the security incident record that will be used. 
Due to customers copying Archer instance databases from Production down to lower environments (#1 above), the new Incidents that are generated by NetWitness may incorrectly match to unrelated Security Incidents in the Security incidents application due to #2, #4, #5, and #7 above. Also, this problem is hidden from Archer users by the out of the box configuration due to #5 above. 
 

Workaround

Workaround #1: For lower/test environments, the Security Incidents application in RSA Archer can be purged of record content so that the new incidents generated by NetWitness for the lower environment do not conflict with the NetWitness Incident numbering (stored in hash_code field) of older security incident records that have been copied down into this environment from Production.

Workaround #2: The NetWitness server can be reconfigured so that the incident #s generated do not match the [hash_code] field value of any existing records in the Archer Security Incidents application.  There is a database command that can be run on the NetWitness server to increase the numbering of Security Incidents to a specified value that is out of range/greater than the hash_code value of existing Security Incident records in Archer.  

(As per NetWitness Customer Support to continue NetWitness incident numbering at 199999)
On NWAdmin (not ESA):
systemctl stop rsa-nw-respond-server
mongo admin -u deploy_admin
<provide password>
use respond-server
> db.tracking_id_sequence.find().pretty()
----- this shows the current highest number NW is aware of, in my lab:
{ "_id" : "incident", "lastId" : NumberLong(1490) }
>> db.tracking_id_sequence.update({_id: "incident"},{ $set: {"lastId" :
>> NumberLong(199999) }})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
> db.tracking_id_sequence.find().pretty()
{ "_id" : "incident", "lastId" : NumberLong(199999) } systemctl start rsa-nw-respond-server





Internal Comments

There is a correction on the command that needs to be run.
When I followed the commands to run on the mongodb, I encounter an issue.
I was able to resolve it by running the commands correctly.
This is the original command which is slightly incorrect:
>> db.tracking_id_sequence.update({_id: "incident"},{ $set: {"lastId" :
>> NumberLong(199999) }})

Correct command which was tested on lab and was working:
>db.tracking_id_sequence.update({_id: "incident"},{ $set: {"lastId" : NumberLong(199999) }})

If you will check to original command on the KB Article, it looks like you need to run 2 commands well in fact command was one-liner only.

Product Details

RSA Product Set: RSA Archer
RSA Product/Service Type: RSA Archer (On-Premise)
RSA Version/Condition: 6.4.1.3

Approval Reviewer Queue

RSA Archer Suite Approval Queue