Behind the 8 Ball: Splunk Implementation

People tend to get themselves behind the proverbial 8-ball in preparation for their Splunk implementation. You’ve got plenty to do, so let’s make sure Splunk is set up the way you need it. One way to ensure you’re prepared for your Splunk implementation is to look at how you’re segmenting your data.

Q: How can I segment data, of the same sourcetype, so that only those individuals in different business units see data associated with their business unit?

Start with Naming Conventions

Because security and access control in Splunk is configured by index layer, start by standardizing and documenting an index naming convention. Indexes will be named in the following convention — the optional <compliance group> will only apply to indexes that contain compliance data i.e. SOX, PCI, etc:

<category>_<eaccess group>_<compliance group>

Any indexes created with a category outside of the predefined categories shall be reviewed with Splunk PS. Make sure your index names and paths are lowercase.

Set Up Categories

Categories represent a logical group of logs such as nixlog, nixlogsec, firewall, etc. The category is the common element in the index name. This will allow users, regardless of index access permissions to search using a common element such as index=nix*. Let’s take a look at some common Network and Application Categories.

1. Network Categories

stream Splunk Stream logs
firewall cisco:asa
auth 802.1x, tacacs, 2fa
ids sourcefire,tippingpoint
proxy bluecoat
dhcp
dns
network generic network equipment such as switches, routers
lb netscaler
vuln tenable, nessus

2. Application Categories 

malware Symantec endpoint protection
inventory Select logs from Tanium, bdna
dblog oracle, mysql, sqlserver – database specific logs
email exchange, smtp
dlp Data loss protection tools
ticketmgmt service now
web apache, webshere, tomcat
app application tier, datapower, mqseries, jvm, flume, yarn, spark, etc…
storage emc
virtualization vmware, hyperv

Up Next, Logs

Operating system-level logs from Nix servers will be placed into the following categories. This allows for different retention for miscellaneous logs (nixlog), security logs (nixlogsec), etc. This also provide a common element for search on all nix logs (index=nix*).

1. Nix Logs

nixlog /var/log/messages, /var/log/cron, etc.
nixlogsec /var/log/audit, linux_secure
nixperf performance monitoring scripts (cpu.sh, etc.)
nixshell bash history
nixscript non-performance monitoring scripts
nixetc /etc/…/*.conf

Operating system-level logs from Windows servers will be placed into the following categories. This will allow for different retention for miscellaneous logs (winlog), security logs (winlogsec), etc. This also provide a common element for search all nix logs (index=win*).

2. Windows Logs

winlog wineventlog:application, system, etc.
winlogsec wineventlog:security
winperf perfmon
winhost winhostmon
winreg winregmon
winnet winnetmon
winscript non-performance monitoring scripts
winad admon/active directory

Users will be able to search for all OS security logs that they have permission to view from Nix and Windows by using one of the following searches:

index = *logsec*
index = nixlogsec* OR index = winlogsec*

Then, users can search for all OS performance logs that they have permission to view from Nix and Windows by using one of the following searches:

index = *logperf*

index = nixlogperf* OR index = winlogperf* 

Although users are searching with a wildcard, search results will only be returned from indexes that the users have permission to access.

Get Kinney Behind the 8 Ball

Follow these tips and you’ll be on the path to a successful implementation in Splunk.With years of experience implementing Splunk, Kinney Group has a deep bench of engineers ready to lead your Splunk implementation.

Author

Start typing and press Enter to search