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 straightforward.

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!

EVAL-action = if(isnull(email_status),action,ema

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(),

…looks good.

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

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 is 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 

Step 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 SP6

SP6 is a Splunk consulting firm focused on Splunk professional services including Splunk deployment, ongoing Splunk administration, and Splunk development. SP6 has a separate division that also offers Splunk recruitment and the placement of Splunk professionals into direct-hire (FTE) roles for those companies that may require assistance with acquiring their own full-time staff, given the challenge that currently exists in the market today.