000029525 - Current issues with SecOps and ArcSight integrations

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

Article Content

Article Number000029525
Applies ToProduct: SecOps
Version: 1.2
Issue1. Extending the CEF Parser in RCF to support additional fields in ArcSight
Issue:
In Arcsight, as part of mandatory configurations to be done which are required for the integration to work only 6 custom variables can be set. (cs1 to cs6).
But if the customer ran out of the custom variables(because of their existing setups) the the remaning variables will be sent to RCF via syslog as additional data where the key name will be starting with "ad.".
But as per CEF standard only alpha numeric variables are allowed as part of the keyname. So the above case violates the this standard , but we will support this based on an explicit configuration driven through a property which externalizes the regular expression to break the CEF message.
Resolution:
1.Edited felix.properties file and un-commented the cef.parser.regex key-value pair.
2.Restarted the RCF service
3.Edited mapping file and so as to contain the key starting from "ad." and refresh the application
4.Edited the arcsight rule with a key-value pair where keyName starts from "ad."
5.Verify alert is created and values are getting mapped as expected.externalizes the regular expression to break the CEF message.
This will also be fixed in 1.2.0.1. See Jira SOC-1247

2. Security Alerts are linking to incorrect device records in RCF
Issue:
If the alerts are set with IP as 10.1.1.1, for a device D1 with 10.1.1.1 as IP and alerts get linked to D1 but when the IP of D1 is changed to 10.2.2.2 and D2 is updated with IP 10.1.1.1 the alerts are still getting associated with the old device D1.
Root cause
In the RCF Code currently all the search results are cached in-Memory HashMap with a dynamically generated Key and value (Archer Tracking ID). The dynamically generated key is a combination of “archerModuleId_archerFieldId_searchCondition_dynamicSearchvalues” and in the current context the same can be translated as “<devices_moduleId><internal_ipaddress_fieldid>_EQUALS<ip_address_value>”.
In case of a device swap which happens at the Archer end and no change in the SA/Arcsight/Splunk end w.r.t the alert (sends same ip address) because of which all the different variants in constructing the caching key (as defined above) remains same so it is picked up from the cache. Also, there is no way RCF gets a notification from Archer about the device swap or any such changes.
Resolution:
We defined a new attribute for the search field in mapping file which dictates RCF whether or not to pull the data from cache. In order to not disturb the other existing functionalities around the search result caching , we defaulted to cache if the attribute is not defined (cacheEnable=true) for a search field tag. 
But in the current case of device search we made changes in the mapping file to explicitly set cacheEnable=false, which dictates the RCF to always make a search call.
Code Changes:
We added the new attribute in the xsd schema file which we use to auto generate the XSD TO JAVA code for the same and added a condition whether to cache the entry or not. (attached screenshots). This has been fixed in 1.2.0.1 See Jira SOC-1236

Attachments

    Outcomes