Solution - Cisco Security Suite Blank Dashboard - Different Index

[domenico_perre]

Hi All,

I thought I would put up a solution that I found out for myself the hard way.

Version:3.1.1

Issue:
After using props.conf / transforms.conf to move your firewall data to a different index (not main). Your dashboard is empty in the cisco security suite.

Solution:

For completeness sake I will show you my props and transforms

transforms.conf
[set_index_firewall]
REGEX = \%FWSM\-\d{1}\-\d{5}
DEST_KEY = _MetaData:Index
FORMAT = firewallIndex


props.conf
[host::(x.x.x.x)] 
#Sends Cisco Firewall Log to index firewallIndex replace x.x.x.x with your firewall IP.
TRANSFORMS-SetNetwork Devices = set_index_firewall

Now for the reason why you dont get any results......

In $SPLUNKHOME/etc/apps/Splunk_CiscoSecuritySuite/default there is a file called savedsearches.conf. You will notice that under each stanza i.e. [Cisco Security Suite - Overview - Global Security Events Map] there is a field called 'search = '

For example:

[Cisco Security Suite - Overview - Global Security Events Map]

search = eventtype=cisco-security-events dest_ip!="255.255.255.255" dest_ip!="0.0.0.0" src_ip="*" | eval isLocalIP=`local-ip-list(src_ip)` | where isLocalIP!=1 AND isnotnull(threat_reason) AND threat_reason!="-" | stats count by src_ip | iplocation src_ip | geostats latfield=lat longfield=lon count by Country

As an admin (other splunkers correct me if I am wrong) the default index you search is 'main'. When you throw the above search into Splunk you will get no results as the index you are wanting to search is not the default one.

So how do you fix it. Before eventtype= add 'index=yourindexname

I added firewallIndex So the line looks like this

[Cisco Security Suite - Overview - Global Security Events Map]
search = index=firewallIndex eventtype=cisco-security-events dest_ip!="255.255.255.255" dest_ip!="0.0.0.0" src_ip="*" | eval isLocalIP=`local-ip-list(src_ip)` | where isLocalIP!=1 AND isnotnull(threat_reason) AND threat_reason!="-" | stats count by src_ip | iplocation src_ip | geostats latfield=lat longfield=lon count by Country

Now add add 'index=yourindexname throughout the file, save it and copy to $SPLUNKHOME/ etc/apps/Splunk_CiscoSecuritySuite/local (create the folder if it doesn't exist).

Wala it works now :).

Hope this helps someone else.

[bwooden]

Springboarding off the jcoates reply: Splunk defers index creation, management, routing, and use to the Splunk administrator.

It appears that your Splunk instance was successfully customized to route firewall data to a specific index. This is fine and good (and documented).

Yet Splunk's User role, by default, only searches the main (default) index. When data is routed to a custom index, users will not be able to implicitly search it until it is included among the default search indexes (step #7). Per your original post, it can be explicitly referenced in the search (provided it is also allowed to do so, per step #8)

[jcoates_splunk]

Hi,

There's been a bit of back and forth on this, but we've settled on a best practice that we're now implementing across the supported and certified apps and add-ons. I expect there will be an update to Cisco Security Suite that will address this. Add-ons and apps should not contain index definitions. This is because indexes cannot not be safely created or managed without an understanding of the target Splunk deployment's:

• Security goals & settings (which roles have access to which indexes, etc)
• Retention goals & settings (restrictions due to disk size, legal, compliance, etc)
• Storage location, sizes, and performance (local disks, NAS, SAN, allocated free space, IOPS, etc)
• Index configuration management choices (deployment server, master node, puppet, chef, etc)

This isn't solely a technology issue, it's also a compliance issue. The App or Add-on author doesn't know any of the things that a Splunk Administrator would need to consider before adding a new index...

• desired retention policy
• desired access controls
• desired volume/storage location to use
• which volumes have which IOPS
• how many warm buckets should we keep or how big should they be
• Where to store TSIDX namespaces
• Where to store cold data
• Store or destroy frozen data? Where?
• What roles get to search this index?
• Which search heads get to search this index?
• etc.

An App or Add-on can easily break a production environment's data storage or data security policy by auto-creating indexes. We can stop indexing by filling a partition, we could fill volumes shared with other indexes and thereby cause unexpected reaping, &c. It's much safer and better to default data storage to main and encourage the complex data routing decisions to be reviewed.