CIM Compliance – A Simple Walkthrough

CIM Compliance – A Simple Walkthrough

Making data CIM compliant can be a daunting and confusing exercise for new Splunkers and experienced ones alike. Often the biggest misconceptions have to do with the approach rather than the exercise itself. My biggest piece of advice – start with the end in mind. (i.e. you should be familiar enough with your data to understand which data model it should be mapped to, what fields the data model requires, and what fields your data actually has).

In this exercise I’m going to do a simple walkthrough making Checkpoint firewall data (sourcetype=cp_log) CIM compliant with the Network Traffic data model.

You should already be comfortable performing extractions in props.conf and transforms.conf. If you’re not, here’s a cool cheat sheet.

Before we begin, you should do the following:

  • Identify the app for our given data’s sourcetype

| rest /services/admin/sourcetypes | fields title eai:acl.app | where title like “cp_log%”

We get TA-check-point-app-for-splunk

  • Familiarize ourselves with our app’s default/props.conf and transforms.conf
  • Familiarize ourselves with the Network Traffic data model
  • Consult vendor documentation to understand Checkpoint’s fields. Here is Checkpoint’s data dictionary. Not all vendors make this readily available online. Thank you Checkpoint <3. If I can’t find one online, I would consult with the device’s administrator, if I can’t make sense of it myself. But this one is pretty straight forward.

Now, let’s begin

Step 1. Map Checkpoint’s fields to Splunk CIM fields in the Network Traffic data model

Splunk CIM Field (Network Traffic data model)

Splunk CIM required values 

Checkpoint Equivalent Fields 

Checkpoint possible field values 

Making it CIM Compliant

Action 

Allowed, Blocked

Action 

Accept, Reject, Drop…

Looks like all this requires is a simple eval…

EVAL-action = case(action==”accept”,”allowed”,
(action=”reject” OR action=”drop”),”blocked”,
true(), action

But there’s a gotcha… After reviewing default/props.conf, I noticed EVAL-action had already been defined in default/props.conf. 10 Pro points for checking the defaults first!

Default/props.conf
EVAL-action = if(isnull(email_status),action,email_status)

So now, how do we define a new EVAL-action statement while keeping the vendor’s definitions? Here’s how I would do it, you can probably think of more clever ways!

Let’s test it out in SPL first
| eval action = if(isnull(email_status), case(action==”Accept”,”allowed”,(action==”Reject” OR action==”Drop”),”blocked”,true(),action),email_status)

…looks good.

local/props.conf:
EVAL-action = if(isnull(email_status), case(action==”Accept”,”allowed”,(action==”Reject” OR action==”Drop”),”blocked”,true(),action),email_status)

done!

app

N/A (Application protocol of the traffic)

service_id 

https, domain-udp, microsoft-ds, ldap,….

local/props.conf:

FIELDALIAS-service_id = service_id AS app

SPL equivalent:
… |rename service_id AS app

bytes 

N/A (numerical. Total bytes)

bytes

289234,23093,…

No action required 

dest

ip or hostname

dst

10.x.x.x, 172.x.x.x, …

local/props.conf:

FIELDALIAS-dst = dst AS dest

Step 2. Test our changes as SPL before we jump into *.conf files

Before I jump into the .conf files, I like to test out my changes as SPL so we cut down on rework and from disappointing your client/end users when you’re constantly reloading Splunk. (Pro Tip: Download CIM Vladitator and test your search out on the scoring dashboard).

index=security sourcetype=cp_log

| eval action = if(isnull(email_status), case(action==”Accept”,”allowed”,(action==”Reject” OR action==”Drop”),”blocked”,true(),action),email_status)

| rename service_id as app

| rename dst AS dest

An easy visual using CIM Validator:

Step 3. Prepare our props and transforms.conf changes to be deployed.

TA-check-point-app-for-splunk/local/props.conf

[cp_log]

EVAL-action = if(isnull(email_status), case(action==”Accept”,”allowed”,(action==”Reject” OR action==”Drop”),”blocked”,true(),action),email_status)

FIELDALIAS-service_id = service_id AS app

FIELDALIAS-dst = dst AS dest

Step 4. Create event types (if not defined by default).  Event types will allow us to filter in only Checkpoint’s firewall data and filter out non-firewall data.

Reviewing the default/eventtypes.conf we see Firewall data if being filtered with the value eventtype=Network_Traffic. No changes required here.

[Network_Traffic]

search = (sourcetype=cp_log AND product=”*Firewall*” AND NOT fw_subproduct=”*VPN*”)

Step 5. Create tags (if not defined).  This should always be the final step because this is when the data will be imported into the data model.

Reviewing the default/tags.conf we also see the tags required for the Network Traffic data model have been defined. No changes required here either. If it wasn’t there, we would have to create a local/tags.conf with the content below.

[eventtype=Network_Traffic]

communicate = enabled

network = enabled

Step 6. Deploy the Search Heads 

7. Check whether our datamodel is pulling in our new sourcetype (assuming the Network_Traffic data model has been enabled)

|tstats count from datamodel=Network_Traffic by sourcetype

In the next article, I’ll do a more advanced walk through and explain additional concepts and tricks. You should get to a point where you no longer need a table and be able to do all of this in your head!

About Aditum

Aditum’s Splunk Professional Services consultants can assist your team with best practices to optimize your Splunk deployment and get more from Splunk.

Our certified Splunk Architects and Splunk Consultants manage successful Splunk deployments, environment upgrades and scaling, dashboard, search, and report creation, and Splunk Health Checks. Aditum also has a team of accomplished Splunk Developers that focus on building Splunk apps and technical add-ons.

Contact us directly to learn more.