Plan the upgrade

This section describes how to upgrade from the Splunk App for Enterprise Security 2.x to the latest version. The Enterprise Security Install App can also be used to perform a new install.

Note: Users of the Splunk Enterprise Security Suite 1.1.x need to perform a clean install or upgrade to 2.x using an older installer before using the current installer. The current installer does not support upgrades from Splunk Enterprise Security Suite 1.1.x. Contact Splunk Support for more information.

Before beginning the upgrade or install process, read "Enhancements" in the Release Notes to understand the new features and functionality and the rest of the prerequisites to become familiar with the Splunk App for Enterprise Security 3.0 system and hardware requirements.

Important: If changes have been made to the core Splunk-provided Enterprise Security Suite components or the Splunk core, the upgrade will not work correctly. Contact Splunk Support for more information on upgrading a customized Splunk for Enterprise Security configuration or a modified instance of Splunk.

Audience

This manual is intended for Splunk administrators who maintain and work with the Splunk App for Enterprise Security. This manual assumes familiarity with both Splunk and the Splunk App for Enterprise Security. It also assumes knowledge of the core Splunk Admin Manual and the Enterprise Security User Manual.

What is covered here

This section covers both the manual upgrade steps for the Splunk App for Enterprise Security, and the install app steps using the Enterprise Security Install App.

Note: The Install App will only perform a complete upgrade in a single server deployment environment. In a distributed server environment, the Splunk for Enterprise Security search head can be upgraded using the Install App, but distributed components (the deployment-apps) should be upgraded using the steps described in Manualupgradesteps#Deployment-apps"Deployment-apps" in the Manual upgrade steps.

Minimum requirements for upgrade

Review the system requirements for the Splunk App for Enterprise Security prerequisities in this manual.

What to know about the upgrade

Here are several things to keep in mind as you plan your upgrade of the Splunk App for Enterprise Security.

Splunk App for *Nix

To improve and consolidate Unix performance and configuration data collection, the Splunk App for Enterprise Security contains a set of views in SA-EndpointProtection that display performance and configuration information from Solaris, Linux, and Mac OS X systems.

In previous versions, the collection of performance and configuration data from Unix systems was handled separately from Splunk "knowledge objects" (like props.conf, transforms.conf, and related files) that parsed and interpreted the data.

These functions are now merged into the Splunk for Unix and Linux app and distributed with the Splunk App for Enterprise Security. A version of the Splunk for Unix and Linux app is also available as a separate download from Splunk Apps.

In the earlier version of the Splunk App for Enterprise Security:

• Deployment apps were distributed to forwarders to collect Unix performance and configuration data. These apps were located in $SPLUNK_HOME/etc/deployment_apps/ after installation. There were three of these apps:

   - linux_base
   - osx_base
   - solaris_base

These apps used Python-based scripted inputs to perform collection tasks, making them unsuitable for installation on universal forwarders (which do not contain a Python distribution).

• The TA-nix, TA-deploymentapps, and SA-EndpointProtection all contained "knowledge objects" used to interpret the collected data.

In this version of the Splunk App for Enterprise Security:

• A single app, Splunk for Unix and Linux (or Splunk_TA_nix) now replicates the functionality of the older TA_nix and TA-deploymentapps -- which have been deprecated.

Note: SA-EndpointProtection has not been deprecated, but knowledge pertaining to Unix data collection has been migrated into Splunk_TA_nix.

• Shell scripts are now used to perform data collection, so that the Splunk_TA_nix can be installed on universal forwarders.

For instance, the functions provided by the following scripts in the older deployment apps are now performed by a single script in Splunk_TA-nix named "service.sh":

    linux_base/bin/linux_service.py
    osx_base/bin/os_service.py
    solaris_base/bin/solaris_service.py

• Outputs from the older Splunk_TA_nix have been leveraged to provide data in Enterprise Security. These outputs are:

    cpu.sh - provides CPU utilization data
    df.sh - provides filesystem utilization data
    ps.sh - provides process information data
    vmstat.sh - provides memory utilization data

• Splunk_TA_nix contains all the knowledge objects necessary to parse data produced by the scripted inputs. A few minor modifications were made to SA-EndpointProtection to facilitate backwards compatibility.

Previously, scripted inputs in the deprecated deployment apps generated source and sourcetype values in the following format:

  <OS>:<script name or identifier>

For instance, CPU data collected from a Linux, Solaris, or OS X host would have received the following source and sourcetype classifications:

  Linux:CPUTime
  Solaris:CPUTime
  OSX:CPUTime

In the new Splunk_TA_nix script architecture being used, it is not possible in all cases to distinguish the source operating system (OS) at the time of sourcetype classification. Therefore, sources and sourcetypes from scripted inputs in the unified Splunk_TA_nix app have the following, less granular format:

  Unix:<script name or identifier>

For example, CPU information collected from a Linux, Solaris, or OS X host using the new Splunk_TA_nix receive the following source and sourcetype classification irrespective of the source host's operating system:

  Unix:CPUTime

Splunk administrators should be aware of this naming change, especially when writing searches that perform cross-platform comparison of data. For example, depending on the target system architecture, it may not be accurate to compare CPU utilization percentages directly.

Summary of *nix upgrade considerations

Consider these important changes as you upgrade:

• If you were using the older deployment apps (linux_base, osx_base, solaris_base) and distributing these apps to forwarders, you can continue to do so without impact. The data collected by these older apps will still be collected and interpreted correctly.

• To begin data collection on universal forwarders, you can now distribute Splunk_TA_nix to your systems.

• Splunk_TA_nix now supersedes the TA-nix and TA-deploymentapps apps. Both of theses older apps will be disabled during installation. If custom modifications have been made to these apps, the changes need to be migrated manually into an appropriate app of your choosing.

Mapping the old scripts to the new scripts

Platform: linux_base
former script	new script (or existing script)
linux_cputime.py	(cpu.sh)
linux_disk.py	(df.sh)
linux_listening_ports.py	openPortsEnhanced.sh ***
linux_memory.py	(vmstat.sh)
linux_passwd.py	passwd.sh
linux_process.py	(ps.sh)
linux_selinux_checker.py*	selinuxChecker.sh
linux_service.py	service.sh
linux_sshd_checker.py	sshdChecker.sh ***
linux_update.py**	update.sh
linux_uptime.py	uptime.sh
linux_version.py	version.sh
linux_vsftpd_checker.py	vsftpdChecker.sh ***
Platform: osx_base
osx_cputime.py	(cpu.sh)
osx_disk.py	(df.sh)
osx_listening_ports.py	openPortsEnhanced.sh ***
osx_memory.py	(vmstat.sh)
osx_passwd.py	passwd.sh
osx_process.py	(ps.sh)
osx_service.py	service.sh ***
osx_sshd_checker.py	sshdChecker.sh
osx_update.py**	update.sh ***
osx_uptime.py	uptime.sh
osx_version.py	version.sh
osx_vsftpd_checker.py	vsftpdChecker.sh ***
Platform: solaris_base
solaris_cputime.py	(cpu.sh)
solaris_disk.py	(df.sh)
solaris_listening_ports.py	openPortsEnhanced.sh
solaris_memory.py	(vmstat.sh)
solaris_passwd.py	passwd.sh
solaris_process.py	(ps.sh)
solaris_service.py	service.sh
solaris_sshd_checker.py	sshdChecker.sh
solaris_uptime.py	uptime.sh
solaris_version.py	version.sh
solaris_vsftpd_checker.py	vsftpdChecker.sh ***

* Only present on Linux

** Only present on Mac OS X and Linux

*** May require root privileges to produce complete results on the indicated OS

Monitor paths for shared search heads

In previous releases, monitor paths were coded as relative paths (//./).

For example:

#####################
Incident Review
#####################
[monitor://./lookups/incident_review.csv]
disabled = false
index = _audit
sourcetype = incident_review

Monitor paths are now hard-coded. Search head pool users need to modify this relative path to use the full path to the shared storage.

A local override for search head pooling would look like this:

SA-ThreatIntelligence/local/inputs.conf
[monitor://$SPLUNK_HOME/etc/apps/SA-ThreatIntelligence/lookups/incident_review.csv]
disabled = true
[monitor:///my/shared/storage/etc/apps/SA-ThreatIntelligence/lookups/incident_review.csv]
disabled = false
index = _audit
sourcetype = incident_review

Upgrade from the Splunk App for Enterprise Security to a newer version

The Splunk App for Enterprise Security upgrade process assumes the following:

• You have an installation of Enterprise Security 2.x and the required add-ons on a dedicated search head
• You are running of Splunk 6.0.x on a supported Linux or Windows system
• Your distributed add-ons will not be automatically upgraded as part of this process
• Extensions such as custom dashboards and lookup files will be migrated
• Built-in lookups that have changed format will be migrated to new formats

Note: The Enterprise Security Install App will not perform a complete upgrade in distributed deployments. Distributed components must be upgraded manually.

System requirements

The Splunk App for Enterprise Security system requirements have changed. Review the Splunk App for Enterprise Security system requirements in this manual and make sure that your system meets these requirements.