Replacement Checkpoint ASP Parser rules for McAfee/Nitro SIEM

The built-in Checkpoint ASP parser rules are actually an example of rules created by McAfee that are quite good, but unfortunately they fell short in a few key areas, at least in my opinion, that prevented them from being usable in my environment.  So find attached my Checkpoint Parser rules and continue reading to get a brief synopsis of how my rules deviate from McAfee’s.

DISCLAIMER & WARNING:

There are issues deploying my solution in an environment that is already capturing Checkpoint events using McAfee’s built-in Checkpoint 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 Checkpoint data source.  This is so that my parser rules can create data source rules  for your Checkpoint data source that better (in my opinion) log your Checkpoint events.  Make sure this this is acceptable in your environment prior to doing so.

Why create my own Checkpoint ASP parser rules?

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

  1. I found it very difficult to incorporate the default Checkpoint 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.
  2. Attempts were made to consistently extract event data and place in the same meta-data fields in McAfee where possible (Mcafee Nitro Database has an odd behaviour of sharing database fields with different event fields so this was not always possible).  The original rules did not do a good job in this regard.
  3. Events are broken out by Checkpoint “Blade” and the “Application” field records the originating blade.  For example interested in the mobile blade events then search on Application: “Connectra” (checkpoint’s legacy name for mobile). Interested in IPS type events well then your are likely interested in the “Anti Malware” or “SmartDefense” blades.  I stuck with Checkpoint’s nomenclature as tightly as possible.
  4. Firewall ACL events are reported as the VPN & Firewall:1″  Application which directly correlates to the Checkpoint “blade” that handles these events.  I also added the firewall ACL rule number to the event description which Mcafee does not do, this allows for useful dashboard views when: 1. You did not provide a friendly ACL name in Checkpoint, 2. To better differentiate similar or exactly named rules.
  5. Checkpoint events now have much more information in meta fields extracted from the actual log entry.  IPS events now have threat category, threat name, CVE threat references, etc.  that McAfee never bothered extracting from the underlying log entry.

Caveats:

There is a rule called Checkpoint 99 – Unknown Event.  This is in place to give parties the visibility into events that would not be captured by my ASP rules.  This will also sometimes capture an event that would indeed be caught by one of the other Checkpoint rules in place, as I have been unable to determine how McAfee Nitro determines order of precedence in rule processing (it doesn’t seem to be based on Signature ID or Name?).   In my environment for every 3 million events, 50 or fewer events fall into the “Unknown” rule.  I know I have a few administrative rules to create that capture actions taken in the “SmartReporter” or “SmartLog” checkpoint applications for instance which will come out in subsequent versions of this ASP rule collection.  If you find the events captured by this rule irrelevant you can delete this particular Unknown rule from your deployment.

My Experience thus far:

I’ve been using my custom Checkpoint rules for 3-4 weeks now and have been able to successfully build Global “Threat” and “High Threat” dashboards incorporating multiple products including Symantec Endpoint Protection(once again I created my own rules for similar reasons) and Checkpoint due to meta-data now existing in the events and being able to be queried in reports and dashboards.

Instructions for installing:

  1. If you have been capturing Checkpoint events, you’ll need to delete the existing automatically created data source rules for your Checkpoint Data Source as they will likely conflict with the ones my ASP rules will generate.
  2. Disable all McAfee checkpoint rules on your Checkpoint Data Source.
  3. Import my ASP rule set.  Review the XML file and edit data between the <rule><id>5000112</id> tags 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.  You should also edit the following tag data: <tag origin=”1″>Checkpoint</tag> to reflect how you want these imported rules to be tagged and more easily visible in the Policy tree.
  4. Enable these rules for the Checkpoint data source, change data aggregation settings and/or exceptions as appropriate in your environment for these rules.

Link to Checkpoint Custom ASP parser rules

Advertisements