IP360 and Splunk – Part 2

Introduction

In Part 1, I discussed how I thought integrating Tripwire IP360 vulnerability data into Splunk would be a great way to both learn Splunk and create useful and interesting vulnerability reports.  I gave an overview of IP360’s vulnerability scoring system and showed how I used the IP360 API to develop my IP360 Tools script to pull interesting data.

In this part, I will show how I configured Splunk to ingest the IP360 data and examples of interesting reports and dashboards.

Splunk Configuration

Splunk needs to know how to access your logs and how you want them to be indexed.  This will be trivial to anyone who’s used Splunk, but here are the steps I took.

1. I created a separate “ip360 index” to store and index all the log data.
   

   Splunk – Configuring the IP360 index

2. I defined an “ip360” source type by telling Splunk how to interpret the logs.
   

   Splunk – Defining the IP360 source type

3. I configured Splunk to monitor a local “ip360” logs directory on the Splunk server for new files and set these logs to the “ip360” sourcetype.
   

   Splunk – Configuring IP360 data inputs

4. Finally, I uploaded the ASPL database file (csv format) so Splunk could perform lookups on vulnerability data using the “da_vulnid” field from my Distinct Audit logs.
   

   Splunk – Uploading IP360 vulnerability data lookup table

Once I verified that the logs were properly indexed and parsed, I began developing queries and reports that I thought would be useful.  I considered the reports I had created in the past and what I’ve heard other clients ask for previously.  In the end, I created two dashboards.  One for vulnerability management and the other to monitor system health.

It’s hard to make out the details in the WordPress image viewer, but if you right click the image and open it in a new window you can view it in your browser to get a better look.

This is the “Vulnerability Management” dashboard.

Splunk – IP360 Vulnerability Management Dashboard

Explanation of each section:

• Enterprise Average Scores: The overall enterprise score (sum of each individual network’s scores) for each month across one year.
• Enterprise Scores and Hosts by Month: Enterprise scores in table format with number of hosts.
• Average Network Scores Over Time: Trendlines for average network scores over a one year period.  Each of these networks (Cisco, Linux, Mac, Windows) make up the Enterprise.
• Summary of Network Enterprise Scores: Similar to the trendline above but displayed in column format.
• Average Network Scores by Month: A table summarizing the network scores by month.
• Average Network Hosts and Scores: A table displaying both network scores and number of hosts by month.
• Most Vulnerable Hosts: These are the most vulnerable hosts as determined by overall IP360 score.
• Host Impacts: This is a pie chart showing what the sum of the top 10 host scores are versus all other hosts.  It’s a great way to show how much of an impact the most vulnerable hosts have on the enterprise as a whole.
• Vulnerability Details: A table detailing which vulnerabilities have the most impact on a network.  As mentioned before, impact is equal to a vulnerability’s score multiplied by the number of hosts affected by the vulnerability.
• Vulnerability Impacts: Similar to the “Host Impacts” pie chart except this shows the impact of the top 10 vulnerabilities versus all others.

This is the “IP360 Health” dashboard.

Splunk – IP360 Health Dashboard

Explanation of each section:

• IP360 Version: The current version of IP360 installed.
• ASPL Version: The current ASPL (vulnerability database) version.
• Overall Scan Status: The status of scans for yesterday.
• Scan Status by Network: The status of yesterday’s scans by network.
• Database Backup Information: Database backup information including backup, push, and purge times.
• VnE Load Average: The average load on the VnE.
• VnE Disk Usage: The average disk usage of the VnE.
• Device Profiler Status: The status of IP360 scanners.
• Scan Profile Status: A list of scan profiles and their status.
• Authentication Failures: A list of authentication failures by authentication type and host.

There’s still a few kinks to work out, but overall I’m pretty happy with the results. I’ve got additional data points I’d like to see, but I think this is a great start. Even better, I learned a lot about Splunk administration and its query language.