Replacement Symantec Endpoint ASP Parser rules for McAfee/Nitro SIEM

The built-in Symantec ASP parser rules are OK, but unfortunately like I’m finding for most rules that come “out of the box” they fall short in actually extracting enough meta-data from the log to be able to create useful reports or create actionable alerts and dashboards!

So once again you can find a link to my Symantec Endpoint Protection rules written for SEP 12, but should find they work for version 11 as well.  Continue reading to get a bit more detail.

DISCLAIMER & WARNING:

There are issues deploying my solution in an environment that is already capturing Symantec events using McAfee’s built-in Symantec ASP parsers that you will need to understand and ensure you are comfortable with prior to attempting to deploy in your environment, especially if it is your production environment.

To implement successfully you will need to “delete all auto-learned rules for this data source” for the Symantec data source.  This is so that my parser rules can create data source rules  for your Symantec data source that better (in my opinion) log your Symantec events.  Make sure that this is acceptable in your environment prior to doing so.

This version 1 of the rules do not pull Agent Traffic Log or Agent Proactive Log.  Its not very hard to incorporate, but I find that two weeks have gone by and I still haven’t done it. When I finally do I’ll post.  I’m ok with this being missing in m environment for the time being.

Why create my own Symantec ASP parser rules?

Creating the custom Symantec ASP parser rules was a substantial effort and probably consumed 20 hours of my time.  The main reasons for doing so are below:

  1. I found it very difficult to incorporate the default Symantec events into “global threat dashboards” because much of the required information in the events needed to build queries on were just not to be found in meta-data fields, ie. required event information was often not extracted and put into normalized McAfee fields from the actual events.  Many events had very little data extracted even when there was alot of obviously useful information to be extracted.  I couldn’t create any useful reports either.
  2. It was arduous reviewing Symantec rules since there are 40+ rules.  After reviewing a few and seeing the limited amount of data being extracted I quickly decided to just scrap them and write my own.  My strategy was to create a single rule for each type of SEP log: scm_system.log, scm_policy.log, scm_agent_act.log, scm_admin.log, agt_traffic.log, agt_system.log, agt_security.log, agt_scan, agt_risk, agt_proactive, agt_behavior.log  (Note: proactive and traffic logs do not have parsers written yet, sorry, I’ll get to it.)
  3. Events have a description starting with SEP followed by the log type and then threat.  The application field is recorded as log type: ex. “Agent Risk” for easy filtering and reporting and I have extracted as much data and put in McAfee relevant fields.  See this link for an example of an Agent Risk Event.   Hopefully you will agree the information extracted is richer and far more useful.

My Experience thus far:

I’ve been using my custom Symantec rules for 3 weeks now and have been able to successfully build Global “Threat” and “High Threat” dashboards, reports and alerts.  Once again I find myself not missing any of the McAfee ASP rules, just the 20 hours or so of my life it took to create another set of rules.  This seems to be a recurring trend; existing rules don’t bother extracting some or even worse most of the rich log data available and the customer has to decide whether there is enough business justification to rewrite and test new parsers.

Instructions for installing:

  1. If you have been capturing SEP events, you’ll need to delete the existing automatically created data source rules for your SEP Data Source as they will likely conflict with the ones my ASP rules will generate.
  2. Disable all McAfee SEP rules on your Symantec Server Data Source.
  3. Import my ASP rule set.  Review the NRF file and edit the <nitro id> to reflect your available rule IDs or ensure that you DO NOT OVERWRITE any existing rule IDs on import but instead CREATE NEW Signature IDs ON ANY CONFLICTS – otherwise you will overwrite any custom rules you have already created.
  4. Enable these rules for your Symantec data source, change data aggregation settings and/or exceptions as appropriate in your environment for these rules.
  5. Follow McAfee instructions and/or Symantec Instructions on how to forward logs from SEP Management server using its Syslog log forwarding  feature.  Do not use the McAfee Agent to parse the actual SEP log files – this is unlikely to work.

Link to Symantec Custom ASP parser rules