Changes to be done in cef.xml to support unknown CEF logs

[AbhishekDwivedi]

Hi All,

I am forwarding my logs from ESA to hybrid in CEF format (using syslog) . I am extracting all available  information  from alerts. I have enabled cef.xml , but logs are going as rsa_securitanyaltics_esa. 

jun 29 07:27:46 localhost CEF:2.0|RSA|Security Analytics ESA|10.5.1.0|Module_7001_Alert--0|RSA_IGSOC_CitrixNetScaler_7001_Misuse_SSLVPN Connectivity Originated from same source by different Users|5|rt=2016-06-29T07:27Z id=7cd4c968-85f2-4cd1-9cd6-6fd7bb68c4f2 source=10.68.136.105:56005:484525335521 alert="rcf_test2" bytes_src="0" city_src="Hyderabad" country_dst="India" country_src="India" dclass_r1="0.00%" dclass_r1_str="Compression_ratio_send" dclass_r2="0.00%" dclass_r2_str="Compression_ratio_recv" device_class="Application Firewall" device_group="Citrix Netscalar" device_ip="10.68.100.134" device_type="citrixns" device_type_id="168" did="blrsiemdec1" disposition="Allowed" dtransaddr="10.67.252.6" dtransport="443" duration_str="00:00:00" endtime="1467185619" esa_time="1467185060412" event_byte_size="531" event_cat="1605000000" event_cat_name="System.Normal Conditions" event_desc="TCP connection related information for a connection belonging to a SSLVPN session" event_source_id="10.68.136.105:56005:484525335521" event_time="1467185619" global_alerting="citrixns.forward" group="N/A" header_id="0001" ip_addr="203.171.211.144" ip_dst="122.15.156.5" ip_dstport="47873" ip_src="203.27.235.106" ip_srcport="64303" latdec_dst="13" latdec_src="17" level="6" log_session_id="6515" longdec_dst="80" longdec_src="78" medium="32" msg_id="SSLVPN_TCPCONNSTAT" msg_vid="SSLVPN_TCPCONNSTAT" org_dst="Vodafone India" org_src="ICICIBANK Ltd, Banking, Mumbai" rbytes="346" rid="485773059317" sessionid="484525335521" severity="Informational" size="632" starttime="1467185619" stransaddr="10.68.100.135" time="1467185058" user_dst="venuskalra" alert="rcf_test2" bytes_src="0" city_src="Hyderabad" country_dst="India" country_src="India" dclass_r1="0.00%" dclass_r1_str="Compression_ratio_send" dclass_r2="0.00%" dclass_r2_str="Compression_ratio_recv" device_class="Application Firewall" device_group="Citrix Netscalar" device_ip="10.68.100.134" device_type="citrixns" device_type_id="168" did="blrsiemdec1" disposition="Allowed" dtransaddr="10.6

Please suggest the changes what I need to do in cef.xml  .Also please suggest do I need to do some work around in case of custom parsers.

[EricPartington]

You can do two things with RSA Live content.

Subscribe - allows you to be notified that new subscriptions are available, then you have to manually update your content

Subscribe and Deploy - allows the content to be updated automatically for you whenever RSA Live is updated.  This is the more efficient method and allows updating of Feeds and Parsers with new content whenever RSA published updates.  You can chose which decoders/log decoders you publish content to so they are updated appropriately.

[JoeGumke]

Thanks eric. Are you aware of alot of customers that leverage automatically pulling down content automatically? I would highly recommend customers to NOT do this, mainly because you cant blindly trust content that RSA , or any vendor pushes down, as it can create downstream affects. For instance changing tags in a log parser would break rules/reports that customers have running in their production environment.

[SalSanshez]

good point!

[EricPartington]

I would suggest that you do allow the auto update of content for most situations, otherwise you will be spending all your time QA content updates and not using the platform for investigations and alerting.

• For instance Feeds from RSA are updated as quickly as every 4 hours, those should be automatically updated and applied to your environment to get the best coverage
• Packet parsers should be subscribed to from RSA live, so that you get immediate improvements when RSA provides the updates.  When Heartbleed was discovered we had updates in the HTTP parser within 24 hours.
• Log Parsers are clear text so you could subscribe to them and validate the parsers to see what changed if you have that operation in your shop.  Otherwise subscribing to the content will save you time and effort if you have many log parsers leveraged in your environment.

[JoeGumke]

Not sure if I entirely agree with that. I would still strongly recommend customers make some effort at checking log parsers at a minimum before they push to production. So for log parsers, how do you validate the log parsers to ensure that custom content doesn't break? If a customer makes a quick change to a log parser, and they have auto updates enabled, those changes will be wiped out without notice, and they will assume that their custom content is still working. How do we as a consumer of this ensure that our custom reports/rules are broken when we pull them down? What methods does RSA support in terms of pulling down ESA syntax and reporting engine rule syntax? RSA doesnt have content management, so when we push down any content from LIVE, we have no idea what is changing/updated, unless we make some effort at due diligence of checking updates manually. I have noticed a couple parsers that have been pushed out recently that have tag changes. That's great that updated log parsers have content that will help environment, but RSA can't possibly regression test all custom content users have, especially when the live interface doesnt populate anything in terms of diffs from previous versions and/or dependencies for tags that we need. Our teams spends copious amounts of time having to backend engineer diffs from log parser updates to ensure that existing content does NOT break, and I think every customer should make some attempt at testing what content they push down from RSA live. We have noticed content from RSA doesnt even work (look at rsa rules), hence why we are VERY hesitant at blindly pulling down content into our production environment.

[EricPartington]

If customers are making custom changes to a parser from RSA Live, best practices are to remove (unsubscribe) that parser from the deployment/subscription so they are not updated when RSA publishes updates.  Customers will then need to diff their updates with RSA live versions to see if the updates now include their changes.  I would also encourage you to submit CS cases with the enhancements that customers have made so that they can be incorporated into our RSA Live versions.  You might also consider (depending on what changes you are making) of using Lua for some manipulation of logs that you might otherwise update a parser for.  That would enable you to keep the stock RSA parser while implementing the customizations and not have to unsubscribe from the parser (see the post on VxStream CEF messages for an example).

What methods does RSA support in terms of pulling down ESA syntax and reporting engine rule syntax?

• 'Pull down' as in export the syntax for offline analysis ?
• There is a rpm (esatool) that is available from support for additional ESA analysis and exporting of rules that will help you export the content in a programmatic fashion.

We have noticed content from RSA doesn't even work (look at rsa rules)

• please open CS cases for these so they can be addressed and resolved if you haven't already.
• 'RSA Rules' you mean Reporting engine rules or application rules or correlation rules ?

[JoeGumke]

problem is that we have several internal modifications that RSA will not support, and we submit several dozen requests a month for content engineering
to resolve / update log parsers to update our misidentified events. Its quite burdening for us continually merging our updates as RSA wont support them.

Where is the rsa supported lua tool that we can leverage to write custom scripts? I hesistate to write lua parsers as its a trial and error process, and
the overall process to write lua, especially for logs its not efficient. You have to write the lua, find method to check lua syntax is correct, upload to decoder,
reload decoder, and inject logs...this should be self contained lua tool that does this for you.

What methods does RSA support in terms of pulling down ESA syntax and reporting engine rule syntax?
    Yes, we need to pull down the raw syntax for all deployed ESA AND reporting engine rules to ensure that our content does NOT break when deploying new content, especialyl log parsers.
    what is the RSA recommended/documented solution for extracting esa rule syntax AND reporting engine rule syntax?