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

Citrix Xenserver XenCenter RBAC logging for Mcafee/Nitro SIEM

Wish you could log activity occurring against your XEN Center environment?  I did as well.

I was unable to find any useful Citrix XenServer logging documents that outlined what was being logged, where and the format.  But perhaps they do exist and I would appreciate any community feedback that includes links that I could review.

This was a very important data source in my environment to monitor so I took it upon myself to research viable methodologies and options to get this information into the McAfee SIEM as sadly this didn’t exist as a predefined data source.  Ultimately I settled on the RBAC events as the most viable, easy to ingest, and immediately useful events to pursue.  There are numerous log file sources in XEN but unfortunately the signal to noise ratio tends to be very poor and when coupling that fact with lack of documentation on types and format of log entries in these files it seemed too large of a hurdle to overcome in a short period of time.  Once again any feedback from the community here might be of help and I would welcome it.

So find below my first attempt at incorporating XEN center events into the McAfee SIEM product.  It is incomplete, but still useful in MHO.

Pre-amble:

The following rules and processes were developed against a Citrix XEN server 6.1 environment but I have reason to believe it should e quite effective against 5.6 and 6.2 pools as well.

My approach:

Targeting the RBAC role based security events which tend to capture a large number of relevant events occuring against the XEN Server environment by admins and automated processes with little to no noise.

To log RBAC activity it is necessary to add the following line to the XEN management server syslog.conf file: \etc\syslog.conf    to send RBAC events via SYSLOG to the McAfee SIEM receiver.  I would do this against the pool master server only, otherwise you will get duplicate events if deployed to more than one server.   Risk note: when the pool master is down you may lose events.

local6.* @mcafeesiemreceiver IPorDNSaddress

* In XEN 6.1 facility local6 appears to be dedicated to RBAC activity and can be instructed to send to syslog destination server.
Custom rules are developed to parse the RBAC data and separate out relevant entries and data.

Custom ASP rules have been developed to parse out relevant events and respective data fields from RBAC syslog entries.

Setting up a data source involves:

  1. Import the latest “XenServer” custom ASP parser rules are imported to the SIEM policy panel.
    WARNING: You will likely want to edit the attached XML policy specification to include Signature ID numbers valid in your deployment or at a minimum specify on import that any duplicates result in a new Signature being created AND NOT TO REPLACE any existing signature IDs.  Otherwise you may delete some of you own created signatures!  example for each rule edit the 5000026 tags.  Also I “Tagged” these XENserver events into a custom “TAG” labelled: XENServer.  You may or may not want this designation which can be changed in the following tag: XenServer.
  2. Adding a Generic Syslog Data source for each XEN pool to be monitored.
  3. Enabling the custom Xenserver ASP rules for just the XenServer data source!
  4. Modify /etc/syslog.conf on Xen server pool master to send local6 events to receiver, and then restart syslog service.

The following events are currently captured, there are more and should appear in subsequent releases of this XENServer ASP parser rule.   Please feel free to modify and contribute!

  • VM.Start
  • VM.set_protection_policy  (unfortunately Citrix XEN in all their wisdom has deprecated this feature in 6.2!)
  • VM.set_name_label
  • VM.set_VCPUs_max
  • VM.Destroy
  • VDI.Destroy
  • Session.Create
  • Message.Destroy
  • Async.host.license_apply
  • Async.VMPP.create (deprecated in Xen6.2)
  • Async.VM.snapshot
  • Async.VM.Provision
  • Async.VM.clone
  • Async.VDI.Destroy

Link to XENCenter SIEM ASP rule file