1 Reply Latest reply on Mar 17, 2014 12:58 PM by Scott Taschler

    New custom types and clashes with existing custom types

    dmease729

      Hi,

       

      Trying to get my head around custom fields, and the fact that not all of them apparently can be used as custom fields (example post here).

      Using an example I am working through in a lab, I have ESM9.3.0 and ePO added as a device, with VSE running on test endpoints.  On the endpoints, I have ran through a simple EICAR test (repeated 5 times).

       

      ePO event ID: 1278
      ESM sig ID: 357-1278 (Settings accessible via Policy Editor > <select ePO sever next to 'Default Policy'> > Data Source Rule Types

       

      With the rule setting at default, I end up with an aggregated alert in ESM as follows:

       

      01 - Aggregation.jpg02 - Aggregation.jpg

       

      As per this post, I am currently playing around with Data Enrichment, and want to make it so another field appears under the custom types tab in the above.  While trying to get this to work (and trying to fully understand how it works!), I have created a new custom type field called 'VSEDAT' - and that is the field I am trying to insert in future events.

       

      As there are already custom types in the existing event, I have created the below table based on the 2nd image above, and the details found in ESM > System Properties > Custom Types

       

      Custom Type NameData TypeEvent Field
      ApplicationStringCustom Field - 1 (short)
      Object_TypeStringCustom Field - 2 (short)
      HostStringCustom Field - 4 (short)
      ObjectStringCustom Field - 5 (short)
      Destination UserStringCustom Field - 6 (short)
      Destination_FilenameRandom StringCustom Field - 9 (short)
      Device_ActionRandom StringCustom Field - 21 (long)
      Detection_MethodRandom StringCustom Field - 22 (long)
      Analyzer_DAT_VersionLong Custom (16 byte) DecimalCustom Field - 24 (long)
      Threat_CategoryRandom StringCustom Field - 25 (long)
      Threat_HandledRandom StringCustom Field - 27 (long)

       

      Questions:

      - If I add a new custom type, with name 'VSEDAT' of data type 'string' and set the events field to 'Custom Field - 1 (short)', then add a data enrichment rule with the enrichment field set to 'VSEDAT', does the receiver ignore this completely, or would the 'Application' field in the above be overwritten? 

      - Do I need to modify the specific rule to include my newly created field?  If so, how is this achieved?  I have tried to use 'Operations > Browse Reference' but get a message advising that documentation for the requested rule is not available.

      - Are rules and signatures essentially the same thing?...

      - If I set my field to 'Custom Field 3' (clashing with 'Recipient_Count', 'Filename', 'Domain', 'Elapsed Time' and 'Count'), would this be better than using 'Custom Field 1', as 3 isnt used in the current custom fields for this particular signature?

       

      At the moment it all looks a little bit messy - I am sure with a little more experience it will start to make sense, but my mind is boggled at present!

       

      Cheers,

        • 1. Re: New custom types and clashes with existing custom types
          Scott Taschler

          Fantastic questions.

           

          - If I add a new custom type, with name 'VSEDAT' of data type 'string' and set the events field to 'Custom Field - 1 (short)', then add a data enrichment rule with the enrichment field set to 'VSEDAT', does the receiver ignore this completely, or would the 'Application' field in the above be overwritten? 

           

          If you add an enrichment rule to populate Custom 1, the enrichment will happily overwrite what was put there by the parsing rule.

           

          - Do I need to modify the specific rule to include my newly created field?  If so, how is this achieved?  I have tried to use 'Operations > Browse Reference' but get a message advising that documentation for the requested rule is not available.

           

          No need to update the parsing rule.  You can use enrichment to populate fields that are not referenced by the parsing rule.

           

          - Are rules and signatures essentially the same thing?...

           

          Well, there are many different things in the McAfee SIEM that we call "rules".  A signature maps 1:1 to a Data Source Rule.  Note that Data Source rules and Parsing Rules are very different things.

           

          - If I set my field to 'Custom Field 3' (clashing with 'Recipient_Count', 'Filename', 'Domain', 'Elapsed Time' and 'Count'), would this be better than using 'Custom Field 1', as 3 isnt used in the current custom fields for this particular signature?

           

          Yes, what you propose is sound.  It's certainly a good idea to avoid re-using a custom field for enrichment if that field is already used by the parser (unless you need to override what the parser is doing in some way).  You have 17 string fields available to you (Custom 1-10 and 21-27).  Custom 3 is a fine choice.  I would avoid Custom 7: that's used for Source User in many parsing rules, and it's best not to overload this one. 

           

          Also, since you made the point above around rule vs. signature, it would be more accurate to say "[custom] 3 isnt used in the current custom fields for this particular parsing rule?"  One parsing rule (sometimes just called a "parser" or "ASP rule") can end up parsing events into multiple different data source rules (signatures/event IDs).  In the case of ePO, we have a small handful of parsing rules that end up creating hundreds of different data source rules.

           

          epoasp.jpg

           

          epodatasource.jpg