ES Admin - v7.1 - Id0501 - LabGuide

Administering Splunk Enterprise Security Lab Exercises
Lab Environment
Welcome to the Splunk Education lab environment. Your instructor will give you the URL to access your
Splunk server which has the Enterprise Security app installed. You will access the Splunk Web interface via
HTTPS (port 8443) using a browser on your local computer.
IMPORTANT: Please disable popup blockers, ad blockers, and clear your cache (or use incognito mode).
A set of Technical Add-ons (TAs) for Enterprise Security have been installed, and the lab environment is
running a testing app called SA-Eventgen that is generating simulated source events. In a production
environment, these events would be sent by Splunk forwarders which would gather data from your network’s
servers, routers, and applications. Your lab event data only goes back as far as the time the lab server was set
up—probably only a day or so.
If you copy text from this document, please note that character formatting and artifacts created
IMPORTANT: by the PDF generation process can cause errors in the XML. Consider using a text editor as an
interim step.
Splunk Logon Credentials:

Username: admin, password: I@ms3cur3!
Username: analyst, password: b0ss0fth3s0c
Username: soc_analyst, password: b0ss0fth3s0c
Administering Splunk Enterprise Security 9/13/23 © 2023 Splunk Inc. All rights reserved. 1
Module 1 Lab Exercise – Overview of Splunk Enterprise Security
Description
In this exercise, you will get familiar with your lab environment and access the ES user interface.
Steps
Task 1: Log on to your lab Splunk server and navigate to the ES home page.
1. Record your ES server URL (provided by your instructor): _____________________________________
Important! The lab server runs on port 8443.
2. Log into Splunk Web using port 8443 and username admin with the password I@ms3cur3!.
3. From the Splunk home page, click Enterprise Security in the list of apps on the left.
4. Note that besides links to the Security Posture, Incident Review, and App Configuration pages, the
Enterprise Security home page has links to ES Documentation, the Splunk Answers Community site,
and a Product Tour.
Task 2: Make an installed app visible on the Splunk homepage.
5. Click the splunk>enterprise at the top of the window to return to the Splunk home page. Notice which
apps are visible on the home page.
6. Click the Apps cog icon.

7. For the ES Content Updates app, click Edit properties.
8. Click the Yes radio button for Visible and click Save.
9. Click the splunk>enterprise button to return to the home page.
10. Notice that the ES Content Updates app is now visible on the home page.
Important! Some apps may have an Update button. Do not update the apps at this time.
Task 3: Customize Splunk Preferences for the Administrator account.
11. From the Splunk main menu select the drop-down for the admin user and select Preferences. Notice that
there are two tabs, Global and SPL Editor.
12. On the Global window, set your local time zone and select Enterprise Security as the Default application.
13. On the SPL Editor window, toggle the Advanced editor button, then toggle the Line numbers button.
14. Click the Themes tab and select Dark Theme. Click Apply.
15. Click the splunk>enterprise button and notice that you are directed to the Enterprise Security
homepage because it was set as the default application above.
Task 4: Examine the source events in Splunk that ES is using to monitor the security environment
and review the notable events in the notable index.
16. From the main ES menu, select Search > Search to run a search using Splunk Search Processing
Language (SPL). This page is the Search and Reporting app you have used before.
17. Begin a search for all events coming into the main index (index=main) over the Last 15 minutes.
NOTE: If the search runs for more than 30 seconds, you can stop it before it completes.
18. Examine the results. You will probably have many events. From the result count of this search, you can
determine how many events Splunk is processing per day. Also, look at the sources and source types—
this will give you an understanding of the type of systems being monitored.
19. Examine the variety of src and dest IP addresses and hostnames. Other fields to notice are host,
signature, and eventtype.
If you do not see one of the fields above, proceed to the next step and use the All Fields button to add
TIP: them. You could also increase the time range of the search, but in a production environment this would be
initiating a lengthy search.
20. Select All Fields.

a. Select the checkbox for a couple of fields you would like to add to the search results.
b. Close the Select Fields window.
Notice that the new fields are added to the search window under SELECTED FIELDS.
21. Run a new search for all events in the notable index (index=notable) over the Last 24 hours.
22. Note the number of results and compare this to the total number of indexed events in the main index over
the Last 15 minutes from step 17. This demonstrates how useful notable events are; you do not need to
search through all the data to find the events that need attention.
23. Examine the values in the source field. These are the correlation search names that created the notable
events.
24. Examine some of the other discovered fields. Note that they are extracted from the source events, so they
will be like what you saw in the main index.
Module 2 Lab – Monitoring with ES
Description
In this lab exercise, you will use the Security Posture dashboard to monitor your organization for
unauthorized network access and the Incident Review dashboard to work an incident. Next, you will use the
Incident Review dashboard to find false positive events coming from a set of test servers, use the Adaptive
Response Ping action to check the status of the servers, and finally suppress the notable events coming from
the servers.
Steps
Scenario: You are investigating reports of unauthorized access to your network resources.
Task 1: Use the Security Posture dashboard.
1. Navigate to the Security Posture dashboard.

2. Review the values in the Key Indicators. Note the totals as well as the net change for each in the last 24
hours.
3. Examine the results in the 4 panels: Notable Events By Urgency, Notable Events Over Time, Top
Notable Events, and Top Notable Event Sources.
4. Hover over the bars in the Notable Events by Urgency panel and note the values.
5. In the Notable Events By Urgency panel, click the red (critical) bar.
6. The Incident Review dashboard opens to display only notable events with an urgency of Critical.
7. Navigate back to the Security Posture dashboard.
8. Examine the Top Notable Events panel. Click the Activity from Expired User Identity row. Note that
this time the Incident Review dashboard shows only the notable events from the Activity from Expired
User Identity correlation search.
The user account Hax0r has been accessing resources even though the account is expired.
NOTE:
You may have to scroll through the pages of events to view any Hax0r notables.
9. Reset the Incident Review dashboard by clicking Incident Review.

This re-opens the Incident Review dashboard with all filters set to default. This is a fast way to clear
Important! all applied filters and reset the Incident Review dashboard. You will use this technique frequently
throughout the lab exercises.
Task 2: Continue researching unauthorized network access.
10. On the Incident Review dashboard, in the Search field enter the username Hax0r and search over the
Last 24 hours. Click Submit. You should find one or more notable events for this user.
Unless otherwise indicated, execute all subsequent searches in the lab exercises using a time range of
Important!
Last 24 hours.
11. In the results, expand one of the notable events using the down arrow to view the details.
12. Examine the details of the Original Event. Some of this data may be useful to determine the seriousness
of this vulnerability.
13. Click the View activity from Hax0r link to see source events associated with this username.
14. This opens a new search window that uses a custom 10-minute time range which references the creation
time of the notable event (5 minutes before and 5 minutes after). This allows you to see source events that
were indexed immediately before and after the notable event.
15. Expand an event and note the following fields. You may have to click the Show all n lines link to view all
the fields.
● Type=Failure Audit
● Message=Logon Failure
● User Name=Hax0r
● Source Network Address
In this case, Type=Failure Audit and Message=Logon Failure indicate failed logon attempts. So, Hax0r
NOTE: is not actually authenticating, but the fact that someone is attempting to use this expired account is an
issue.
16. Close the search window and return to the Incident Review dashboard.
Task 3: Begin working the issue.
17. In the Incident Review dashboard, make sure the search results are still filtered to the user Hax0r.
18. Click Edit All Matching Events (n).
19. Set the Status to In Progress and click Assign to me. Click Save changes, then click Close.
Now you would begin working with network analysts and others to research and resolve the issue. While
NOTE:
this takes place, you would still need to review new incidents.
20. Click Incident Review.

21. Set the Status filter to New, then click Submit.
Notice that you no longer see your in-progress Hax0r incidents. You would do this to see only New
incidents requiring attention. They would normally then be assigned to an owner and their status changed
to show they are In Progress or Resolved.
22. Reset the Incident Review dashboard.
23. In the Owner filter, select yourself (admin) and click Submit.
Now you only see your incidents. This is a typical way to view your queue of assigned incidents.
Task 4: You have resolved the Hax0r issue by hardening a firewall asset. You can now resolve your
incident.
24. Reset the Incident Review dashboard and search for all Hax0r incidents.
26. Change the Status to Resolved and enter a Comment of “Firewall has been hardened”, click Save
changes, then click Close.
27. In the future, you probably want to see only unresolved, open incidents. Click Clear all to reset the
dashboard filters. Search for open incidents by selecting all Status values except Resolved and Closed.
The Hax0r events should not appear in the search results.
You can also use the Search field to find events by status, owner, etc. For instance, use the status field
(lower case) and the status values: 0 = “Unassigned”, 1 = “New”, 2 = “In Progress”, 3 = “Pending”, 4 =
TIP:
“Resolved”, and 5 = “Closed.” For example, enter status<4 in the Search field to filter out Resolved (4) or
Closed (5) events.
Task 5: Configure the Incident Review dashboard to display a new column named User with
information from the user field.
28. From the Configure menu, select Incident Management > Incident Review Settings.
29. From the Incident Review – Table Attributes list, select +Add Column.
30. For the new column, enter user in the first field and User in the second field.
31. Use the vertical dotted lines on the left of the new column to move it under the rule_title/Title column.
32. Click Save at the bottom right of the Incident Review Settings window.
33. When the changes are successful, click Close.
34. Click Incident Review and confirm that the new User column is displayed. You may have to click the sort
ascending/descending arrows to see the new user information.
Scenario: Several false positives have been generated and are coming from a set of servers named PROD-
MFS-XXX, which are a set of QA lab workstations used to test production security configurations.
You want to first determine the workstation’s status—are these workstations still online? You will
ping them to see.
Task 6: Test workstation status.
35. Clear the Incident Review dashboard by selecting Incident Review.

36. Search for notable events in the Endpoint security domain associated with any server matching
PROD-MFS-*.
37. You should see several notable events for malware infections. Expand the details of one of these events.
38. Click the Contributing Events link to see the original events that triggered this notable event.
39. A new search window opens and displays events from the Malware data model. Note that this information
comes from the Malware_Attacks object. You can see the affected PROD-MFS system in the dest field, the
type of attack in the category field, and other information about the incident.
40. Close the contributing events search window.
41. Next, check the status of the affected system by navigating back to Incident Review.
NOTE: Incident Review should still show the expanded PROD-MFS-XXX notable event.
42. Open the Actions menu of a notable event and select Run Adaptive Response Actions. The Adaptive
Response Actions window opens.
NOTE: This step uses the Actions menu for the notable event, not the Action menu for a field in a notable event.
43. Select +Add New Response Action and select Ping.

44. In the Ping window enter the following and click Run. The ping action is dispatched.
● Host Field: Destination (dest)
● Max Results: 4
● Worker Set: Pick local from the dropdown list. The worker set is specific to running Adaptive
Response actions on a Splunk Cloud ES search head.
45. Close the Adaptive Response Actions window using the X in the upper right.
46. In the expanded incident details of the selected notable event, refresh ( ) the Adaptive Responses list.
The Ping response action should be listed with a Status of success.
47. Click the Ping response to see the results. A new search window opens and displays the results of the
ping action. This verifies that the server is online. (Note that all the PROD-MFS* hostnames resolve to
127.0.0.1—this is normal for our lab environment.)
48. Close the search window.
Scenario: Now that you know the status of the test systems, you will close out the affected false positive
notable events.
Task 7: Remove the false positives from the list of incidents.
49. In Incident Review, make sure you are still displaying the Endpoint events for the PROD-MFS-*
workstations.
51. Change the Status to Closed and select the Disposition as False Positive - Inaccurate Data.
Use the disposition to classify the notable and separate the false positives without impacting the status of
NOTE:
the notable.
52. Click Save changes and close the window.
Scenario: You have closed the PROD-MFS-XXX false positives, but new notable events will still occur. You
would like to suppress them for the rest of the testing project.
Task 8: Suppress notable events.
53. Clear the Incident Review dashboard and search for PROD-MFS-* notable events. Several notable events
appear, including malware infections and access anomalies. For our purposes, use an event from the Host
With Old Infection Or Potential Re-Infection correlation search as an example of a notable event that is
a false positive and should be suppressed.
54. On the notable event, click the Actions menu and select Suppress Notable Events.
Review the fields of the Suppress Notable Events window, these are used to create an event type that
will be used by the correlation search engine to determine if a notable event should be generated or not. If
an event matches the event type’s time range and search criteria, it will be ignored by the correlation
search.
55. Review the Search Preview field. The suppression uses source=(correlation search name) as one
of its criteria. Therefore, the suppression only suppresses this kind of correlation search. Also notice the
Selected Fields are dest and signature. Only events matching this destination and signature are
suppressed (i.e., PROD-MFS-006/LeakTest).
56. Enter the Suppression Name: Suppressing PROD-MFS server for 6 mos.
57. In the Suppress From … To fields, select a range from now until a date 6 months in the future.
58. Click Save to return to Incident Review.
Notable events will be hidden for this destination and signature for the next 6 months. You are
suppressing only one of several servers for the purpose of this exercise. If many servers were
identified as false positives in a production environment, you could locate this event type in Settings >
Event types by searching for notable_suppression across all apps.
1. Pick All from the App dropdown list.
Important!
2. Enter notable_suppression in the filter field and select the search icon.
Then edit the event type’s search string to include wildcards in the dest and/or signature field
values. You can edit the event type in the future if necessary; for instance, you could add additional
selected fields to make the event type more restrictive, or you could alter the search expression to use
a wildcard instead of a specific hostname to make it generalize to a set of servers.
59. From the Audit menu select Suppression Audit. View the data in the panels including suppressed events
over the last 24 hours, suppression history over the last 30 days, and suppression activity.
Because this is a lab environment, there may not be any data for Suppression History Over Time – Last
NOTE:
30 Days.
Module 3 Lab – Risk-Based Alerting
Description
In this lab exercise, you will review Risk Notables and the information provided for risk objects. You will also
review the two default Risk Incident Rules (correlation searches) and what conditions trigger the creation of a
Risk Notable.
Steps
Task 1: Review the risk-based information for a risk notable.
1. Navigate to the Incident Review dashboard.

2. From the Type drop-down select Risk Notable and from the Time drop-down select Last 60 minutes.
Click Submit. Note which correlation search is creating the majority of the Risk Notables.
The Risk Threshold Exceeded For Object Over 24 Hour Period correlation search triggers the 24 hour
NOTE: risk threshold exceeded for user/system risk notable when the risk score for a specific object reaches a
threshold of 100 over a 24-hour period.
3. Review the risk-based fields available for a specific Risk Notable.

● Risk Object: User, system, or other.
● Aggregated Risk Score: Sum of all the scores associated with each of the contributing risk events.
● Risk Events: Events that caused the notable event to be created.
● Disposition: Classifies the notable and separates the false positives without impacting the Status of
the notable. Enables you to drill-down on the notables that pose the highest threat and accelerates the
triage of notables during an investigation, helping to respond to security threats faster.
4. Click the number in the Risk Events column for one of the Risk Notables. The number represents the
number of risk-based events related to the risk notable for the object (system or user).
5. Review the information on the Risk Events window. The top panel displays the timeline visualization of the
contributing risk events. Use the zoom tools on the right to change the timeline.
Zooming in/out can help narrow down the time of occurrence. The timeline visualization plots the
contributing risk events using time on the x-axis and risk score on the y-axis. The timeline visualization
NOTE:
uses color codes on the icons that indicate the severity of the risk scores. A lower risk score corresponds
to a lighter color icon.
6. Click on several of the events in the timeline visualization to view the details of the event including the
name of the correlation search that created the event, the time of the event, and, if present, any MITRE
ATT&CK tactics and techniques configured for the correlation search.
Clicking an event in the timeline visualization highlights the corresponding event in the Contributing Risk
NOTE:
Events panel.
7. From the Contributing Risk Events panel, expand an event to view the details including the source, risk
score, risk message, and threat object.
8. Close the Risk Events window.
Task 2: Review the default Risk-Based Alerting correlation searches (Risk Incident Rules)
9. Navigate to Configure > Content > Content Management.

10. Filter the Content Management window by
● Type: Correlation Search
● App: SA-ThreatIntelligence
● Status: Enabled
11. Click the Risk Threshold Exceeded For Object Over 24 Hour Period correlation search to view the
configuration.
12. Review the search. What portion of the search represents the point when the correlation search will trigger
it will trigger when is greater than 0 once
a Risk Notable? ____________________________________________________________
13. In the Search window, change the search to trigger when the risk score for an object reaches 80. Change
risk_threshold=100 to risk_threshold=80.
14. Add the following MITRE ATT&CK annotations to enrich the results of the correlation search. Click in the
MITRE ATT&CK field and start typing the name of the tactic or technique. Hit Enter to select a value.
● T1200 – Hardware Additions
● T1078.001 – Default Accounts
● T1078.002 – Domain Accounts
● T1078.004 – Cloud Accounts
NOTE: For details on each MITRE ATT&CK tactic and technique visit http://attack.mitre.org/.
15. Edit the correlation search to run every 30 minutes. In the Cron Schedule field enter */30 * * * *
16. Click Save then Close when the changes are confirmed.
17. Click Back to Content Management.
18. View the details of the other default Risk Incident Rule. Filter the Content Management list to view the
ATT&CK Tactic Threshold Exceeded For Object Over Previous 7 Days correlation search.
19. Click on the correlation search to view the configuration.
20. What portion of the search represents the point when the correlation search will trigger a Risk Notable?
it will trigger when is greater than 0 once
________________________________________________________________________
21. Do not make any changes to the correlation search. Click Back to Content Management.
Module 4 Lab – Customizing the Investigation Workbench
Description
In this lab exercise, you will add two panels to a temporary XML dashboard. Those panels will become the
basis for pre-built panels you will add to your custom workbench tab to view activity specific to assets
associated with Cisco Sourcefire investigations.
Steps
Scenario: Analysts are requesting a new “IDS / IPS Activity” investigation workbench tab to be able to
quickly view Cisco Sourcefire information.
Task 1: Create a temporary XML dashboard to build two prebuilt dashboard panels.
1. From Enterprise Security, open a new Search page (Search > Search).
2. Execute the following search over the Last 24 hours:
index=main (sourcetype=snort OR sourcetype=cisco:sourcefire OR sourcetype=eStreamer) dest=*
| stats count by dest
| sort 10 -count
3. Click Save As > New Dashboard and configure the dialog as follows.
• Dashboard Title: Source XML Dashboard
• Permissions: Private
• How do you want to build your dashboard: Classic Dashboards
• Panel Title: Cisco Sourcefire – Top 10 Destinations
• Visualization Type: Statistics Table
• Advanced Panel Settings:
o Panel Powered By: Inline Search
o Drilldown: No action
4. Click Save to Dashboard and close the “Your Dashboard Panel Has Been Created” dialog box. Do not
click View Dashboard.
5. Execute the following search over the Last 24 hours:
index=main (sourcetype=snort OR sourcetype=cisco:sourcefire OR sourcetype=eStreamer) dest
6. Click Save As > Existing Dashboard and configure the dialog as follows:
• Select an Existing Dashboard: Source XML Dashboard
• Panel Title: Cisco Sourcefire – Destination Events
• Visualization Type: Events
• Advanced Panel Settings:
o Panel Powered By: Inline Search
o Drilldown: No action
7. Click Save to Dashboard, then View Dashboard.
8. On the Source XML Dashboard click Edit.
9. On the Cisco Sourcefire – Top 10 Destinations panel, select the More actions ellipsis and click Edit
Drilldown.
10. On the Drilldown Editor configure the following:

• On Click: select Link to search and make sure Auto is selected.
11. Click Apply.
12. For the Cisco Sourcefire – Top 10 Destinations panel, click the gear icon, then Convert to Prebuilt
Panel.
13. From the Convert to Prebuilt Panel dialog, for Permissions select Shared in App, then Apply.
14. Click OK to dismiss the Your Panel Has Been Created dialog.
15. For the Cisco Sourcefire – Destination Events panel, click the Edit search icon:
16. Insert dollar signs ($) around the dest keyword as shown.
index=main (sourcetype=snort OR sourcetype=cisco:sourcefire OR sourcetype=eStreamer) $dest$
17. Click Apply.
The events panel now displays a “Search is waiting for input…” message. This is normal and
NOTE:
expected.
18. For the Cisco Sourcefire – Destination Events panel, click the gear icon, then Convert to Prebuilt
Panel.
19. From the Convert to Prebuilt Panel dialog, for Permissions select Shared in App, then Apply.
20. Click OK to dismiss the Your Panel Has Been Created dialog.
21. Click Save.
Task 2: Create two investigation Workbench Panels.
22. In Enterprise Security, navigate to Configure > Content > Content Management.
23. Click Create New Content > Workbench Panel.
24. On the New Workbench Panel dialog, configure the form as shown:
25. Click Save.

26. Click Create New Content > Workbench Panel.
27. On the New Workbench Panel dialog, configure the form as shown:
28. Do not click Save yet!

29. Click Add Token and configure the form exactly as shown:
NOTE: You must include a space before and after the OR delimiter!
Parenthesis ( )
Dest=”
Single ”
Note the space
before and after OR
Uncheck Is Null
30. The Token Value field must be exactly:

(dest="<Asset_Value_1>" OR dest="<Asset_Value_2>")
31. Click Apply, then Save.
Task 3: Create an investigation Workbench Profile.
32. From the Content Management page, add a workbench profile by clicking Create New Content >
Workbench Profile.
33. Enter the following information:
● Profile Name: Intrusion Detection
This becomes the stanza name in es_investigations.conf and is used as the label if the label is not
NOTE:
specified.
● App: Enterprise Security

● Label: Intrusion Detection
NOTE: Enter a Label name if you want the Profile tab to be named something different than the Profile Name.
● Description: Detects IDS/IPS activity.

34. Click Save.
Task 4: Create an investigation Workbench Tab.
35. From the Content Management page, add a workbench tab by clicking Create New Content >
Workbench Tab.
36. Configure the form exactly as shown:
37. Click Save.
Task 5: Create an investigation to test your configuration.
38. Navigate to the Incident Review dashboard, type threat activity in the search field and click Submit.
39. Select the checkbox for one of the notable events that contains an IP address. For example:
40. Click Add Selected to Investigation.

41. From the Add Event to Investigation dialog, click Create Investigation.
If you do not have the manage_all_investigations capability, the Assignee dropdown will not appear.
NOTE: Choosing User from the Assignee dropdown allows you to see investigations where you are a
collaborator. Selecting All allows you to see all investigations on the system.
42. From the Create New Investigation window, name the investigation: Suspicious Sourcefire Activity
43. Change the Status to In Progress and click Save.
44. Click the Open Suspicious Sourcefire Activity link to open the new investigation. If prompted with the
Artifact Extraction window, review the information, and click Ok. The warning shows that there are
duplicate entries for these artifacts.
45. In the Artifacts panel, click the Select all link, then click Explore.
46. Examine the tabs and panels on the right. Notice that areas are automatically populated with information
for you to explore and document.
47. Select the IDS / IPS Activity tab.
The Cisco Sourcefire – Top 10 Destinations panel should display the 10 most frequent destination IP
addresses. The Cisco Sourcefire – Destination Events panel might display events (if the IP address
added to the investigation as part of the notable event is found in the event search) or you might see a
Search did not return any events message.
48. From the Top 10 Destinations panel, click one of the IP addresses.
The Add Artifacts dialog appears and is pre-populated with the IP address you clicked. The Type field
value should automatically change to Asset.
49. Click Add to Scope.
50. Click another IP address in the table and add it to your investigation.
51. In the Artifacts panel, click the Select all link again, then click Explore.
The Destination Events panel results are updated to include events from the two new IP addresses you
added to the investigation.
52. Scroll to the bottom of Destination Events panel and click the search icon to open a New Search window.
53. Compare the list of destination IP values to the IP addresses (artifacts) contained in your investigation by
clicking the dest field from the Interesting Fields list:
You will see either two or three IP addresses in the dest field, depending upon whether or not
NOTE:
the IP address from the notable event was found by the Destination Events panel search.
Module 5 Lab Exercise – Post-installation Tasks
Description
In this lab exercise, you will examine the configuration of your ES search head. Note, the search head has
recently been upgraded to the latest ES version. You also verify access to your server and perform
initialization procedures.
Steps
Task 1: Following an upgrade, disable un-needed apps.
1. Make sure you are logged on as admin.

2. Use the Apps menu to open the Manage Apps page.
3. Filter the list by Splunk Add-on.
Review the list of add-ons. The customer is not using all the installed add-ons, so un-needed add-ons can
be disabled.
A new ES installation only installs the Splunk Add-on for UBA (SA-UEBA), since this is an upgraded ES
search head, many Splunk Add-ons were previously installed but are not needed. Also note that some add-
NOTE:
ons will show “Update to X.X.X”. This is a lab environment, please do not upgrade the add-ons. In a
production environment, add-ons can be upgraded from this window.
4. Disable the following add-ons:

● Splunk Add-on for Bro
● Splunk Add-on for FTP
Important! Under Messages , a system message may tell you to restart the server. Use the link to
navigate to Server Controls and click Restart Splunk. Then, log back into Splunk Web as admin.
5. Navigate back to Apps > Manage Apps and verify the add-ons you changed are disabled.
Task 2: Create an app package for your indexer(s).
6. Navigate to the Enterprise Security app.

7. Select Configure > General > General Settings.
8. On Distributed Configuration Management, click Download Splunk_TA_ForIndexers.
9. Check both Include index time properties and Include index definitions.
Select Include index time properties to include the props.conf and transforms.conf files in the
NOTE:
package and Include index definitions to include the indexes.conf file in the package.
10. Click Download the Package.

A TA_ForIndexers-1.0.0-0.spl file is downloaded to your workstation. You would normally deploy this file to
the indexers in the Splunk distributed site, but since this lab environment is a single-server setup, you will
not be doing this step.
11. Extract the contents of the SPL file. You can do this on most systems by changing the file extension to
.zip or .tgz and double-clicking the file name to extract the contents. You should see four configuration
files in the default directory, including a props.conf and transforms.conf. These are the index-time
configurations for all enabled TAs. You will also see an indexes.conf. This file contains all the settings for
all indexes needed by ES.
Module 6 Lab Exercise – Initial Configuration
Description
In this exercise, you will carry out some initial configuration tasks: customize Key Indicators, establish
dashboard permissions, and modify ES navigation.
Steps
Task 1: Configure key indicators.
1. In ES, navigate to the Security Posture dashboard.

2. Click Edit on the Security Posture dashboard.
Note the value for the Access Notables key indicator is black.
3. Click the Key Indicators panel. The Configuration panel opens on the right.
4. In the Threshold field for the Notable - Total Events By Access Domain key indicator, set a threshold
slightly below the current count for the indicator and click Save then View to return to the dashboard view.
Note that the ACCESS NOTABLES indicator is now red because it is over the threshold.
5. Edit the Notable - Total Events By Access Domain indicator again, and this time set a threshold slightly
above the current count and click Save then View. Note that the value is now green.
6. Click Edit again to add a new indicator. From the Available Key Indicator dropdown menu filter and select
the IDS - High Severity Attacks indicator and click Add indicators. Click Close.
7. Click Save then View to see the new indicator.
Task 2: Examine the search behind a Key Indicator.
8. In ES navigate to Configure > Content > Content Management.

9. For Type select Key Indicator Search and filter for HTTP.
10. Click the Web – HTTP Category Minimum Count search and examine the details of the indicator.
You can make changes to Key Indicators including the title or subtitle, as well as the search itself. You
NOTE:
can also copy the search and use it to create a new KI with different criteria.
11. Click Back to Content Management to exit without saving any changes.
Task 3: Modify dashboard permissions.
12. Make sure you are logged in as admin.

13. Open the ES Audit menu and select the ES Configuration Health dashboard.
The ES Audit dashboards validate the security and integrity of ES data. They ensure that forwarders are
functioning, that data has not been tampered with and is secured in transmission, and that analysts are
reviewing the notable events detected by correlation searches.
The ES Configuration Health dashboard identifies three types of configuration anomalies and compares
the latest installed version of Enterprise Security to prior releases.
14. From the Search menu, select Dashboards.

15. Locate the ES Configuration Health dashboard entry and select Edit > Edit Permissions.
16. Uncheck Read permission for Everyone, and grant Read (and Write) permissions for admin.
17. Click Save.
18. Examine the Audit menu. You should still see the ES Configuration Health menu item because you are
currently logged in as admin.
19. Log out of Splunk Web and test user access by logging back in with user account analyst and password
b0ss0fth3s0c.
20. You are now logged in as an ES Analyst user.
21. Navigate to the ES application and open the Audit menu. Note the ES Configuration Health menu item is
gone.
22. Select Search > Dashboards and look for the ES Configuration Health dashboard.
Because you removed Read access for all roles except admin, analysts do not even see the dashboard
listed on this page.
23. Log out and log back in as admin with the password I@ms3cur3!.
Task 4: Customize navigation.
24. Click the logo in the upper-left corner. Notice that this takes you to the Splunk
Enterprise Security home page because that is the default app set for the admin account Preferences in
Lab 1.
25. Your users would like to have the Security Posture dashboard open instead, so you will need to modify
the navigation settings.
26. Navigate to Configure > General > Navigation.
27. Notice that the Home item has a checkmark enabled . This indicates it is the default
view for the ES app. You want the Security Posture dashboard to be the default view.
28. Click the checkmark on the Security Posture item. The checkmark should dim on the Home item and
enable on the Security Posture item. Security Posture is now the default view for ES.
29. You decide the Identity dashboards will be frequently used, so you want to make them more accessible.
30. Locate the Identity sub-menu under the Security Domains menu. You will have to scroll down the list of
items under the Security Domains menu to the bottom to see the Identity menu.
31. Click and drag the Identity sub-menu out of the Security Domains menu. Move it so it appears between
the Audit and Search menus.
32. Click Save and OK to apply your changes and close the navigation editor.
The Identity menu should now appear on the app navigation bar.
33. Click or select Enterprise Security from the App: menu. Notice that the Security
Posture dashboard now displays as the default view and the Identity menu is between the Audit and
Search menus.
Scenario: As an ES Admin you have a SOC manager that currently uses the soc_analyst user account with
the ess_user role. The manager needs the ability to edit notable events, change ES navigation,
and view all investigations which the current role does not support. You decide to create a new
role and user account for the SOC manager.
Task 5: Review the capabilities of the soc_analyst user account with the ess-user role.
34. Log out of Splunk and log in with username soc_analyst and password b0ss0fth3s0c.
35. In ES click on Incident Review and select the checkboxes for a couple of notable events. Notice that the
soc_analyst user account does not have the ability to edit notable events.
36. Navigate to Configure > General > Navigation. Notice that the soc_analyst account does not have the
capability to edit ES navigation.
37. Click on Investigations. Notice that the soc_analyst user account does not have permission to access
investigations.
Task 6: Create a SOC manager role and give it specific permissions.
38. Log out of Splunk as soc_analyst and log back in with username admin and password I@ms3cur3!.
39. Navigate to Settings > Roles.
40. Click New Role.
41. Enter soc_manager as the name of the role.
42. On the Inheritance tab select the user, ess_analyst, and ess_user roles.
43. On the Capabilities tab notice that the edit_notable_events capability is inherited. Select the checkboxes
for edit_es_navigation and manage_all_investigations.
NOTE: You can use the Capability Name filter to search by the capability name.
44. On the Resources tab select SplunkEnterpriseSecuritySuite as the Default app and leave the other
fields at the defaults.
45. Click Create.
46. Navigate to Settings > Users and click New User.
47. Enter the name of the user as soc_manager.
48. Enter a password as p@ssw0rd.
49. Select a time zone for the user.
50. Set the Default app as SplunkEnterpriseSecuritySuite (Enterprise Security).
51. In Assign to roles click soc_manager.
Remember: The soc_manager role inherits the ess_analyst and ess_user roles.
52. Ensure the Create a role for this user box is not checked.
53. Uncheck Require password change on first login and click Save.
Task 7: Confirm the capabilities of the new SOC Manager account.
54. Log out of Splunk and log in using the new soc_manager account with p@ssw0rd. Click Skip if prompted
with a message to continue the tour of Splunk.
55. In ES, click on Incident Review and select the checkboxes for a couple of notable events. Notice that the
soc_manager user account has the ability to edit notable events.
56. Navigate to Configure > General > Navigation. Notice that the soc_manager account has the capability
to edit ES navigation.
57. Navigate to Investigations. Notice that there are no investigations under Investigations Assigned to Me,
but this role now has a tab called All Investigations.
NOTE: The new user has not created any investigations of their own.
58. Click on All Investigations and confirm that you can see the Expired User Activity investigation created
earlier. Remember, this investigation was created by the admin user account.
Scenario: As an ES Admin you have the ability to assign specific permissions to the ess_user and
ess_analyst roles.
Task 8: Enable specific ES permissions for the ess_user and ess_analyst roles.
59. Log out of ES as the soc_manager and log in as admin.

60. In ES navigate to Configure > General > Permissions.
61. For the ess_user role, enable Edit Notable Events and Own Notable Events.
62. For the ess_analyst role, enable Edit Sequence Templates.
63. Click Save.
Module 7 Lab Exercise – Validate ES Data
Description
In this exercise, you will identify industry-standard data sources, Splunk add-ons, and source types. You will
normalize a set of indexed Cisco ASA events to the Common Information Model (CIM) using a Splunk add-on.
Steps
Task 1: Plan and verify inputs.
The following vendors and technologies are being used in your ES implementation. The source types are
shown in the table below. Information for each add-on can be found in the Splunk Supported Add-ons
documentation (https://docs.splunk.com/Documentation/AddOns).
Vendor / Technology Source Type
Juniper Netscreen Firewall netscreen:firewall
Cisco Sourcefire / FireSIGHT cisco:sourcefire
Sophos Endpoint Console sophos:threats
Blue Coat ProxySG bluecoat:proxysg*
1. Verify Splunk is inputting these sourcetypes by running the following search, substituting the sourcetype
name from the table below. Run the search for each sourcetype over the last hour and confirm that there
are events being generated and note the number of events.
index=main sourcetype=<sourcetype>
Source Type Number of Events in Last Hour
netscreen:firewall 16
cisco:sourcefire 20
sophos:threats 312
bluecoat:proxysg* 497
2. Confirm that the data is being normalized by the Network Traffic data model by running this search over
the last 60 minutes (searches that reference a data model take longer than normal to complete):
| tstats count from datamodel=Network_Traffic.All_Traffic by sourcetype
3. Confirm that the Juniper, Sophos and Cisco source types are present in the search results. This confirms
normalization is working.
4. Run this search over the last 60 minutes and confirm that the cisco:sourcefire source type is present in
the results.
| tstats count from datamodel=Malware.Malware_Attacks by sourcetype
5. From the Security Domains menu, confirm there is data in the following dashboards and review the data.
● Access > Access Center
● Endpoint > Malware Center (New Malware – Last 30 Days panel might be empty)
● Network > Intrusion Center (New Attacks – Last 30 Days panel might be empty)
● Network > Vulnerability Center (New Vulnerabilities might be empty)
Task 2: Examine data model activity.
6. Use the Data Model Audit dashboard to get an idea of the performance of the data models used by ES.
7. Navigate to Audit > Data Model Audit.
Web - 379.4 Mb
8. What is the largest data model by size? ________________________________
Authentication - 24.325
9. Which data model takes the most time to execute (runDuration(s))? __________________________
10. Which data models are not contained in the CIM app?
Task 3: Install a new Splunk technology add-on to automatically normalize Cisco ASA events.
Out of the box, the ES app does not include an add-on to recognize log events from the Cisco ASA firewall
appliance. You will install the add-on for Cisco ASA and verify that it is working properly.
11. Navigate to Search > Search and run the following search over the Last 60 minutes:
sourcetype=cisco:* | stats count by sourcetype
NOTE: You will see cisco:asa, cisco:fwsm, cisco:pix, and cisco:sourcefire source types.
12. To check for normalization, run this search over the Last 60 minutes:
| datamodel Network_Traffic All_Traffic search | search sourcetype=cisco:*
| stats count by sourcetype
You see cisco:sourcefire, but not cisco:asa. This is because the Splunk Add-on for Cisco FireSIGHT is
already installed on this ES instance, but the Splunk Add-on for Cisco ASA is not. You need to install the
add-on to normalize the cisco:asa source type.
13. In the App menu, select Manage Apps, then click Install app from file.
14. Under File, click Choose File and browse to the Cisco ASA add-on (ta-cisco-asa.tgz) provided by your
instructor.
15. Click Upload to install the add-on.
You could also download and install the Splunk Add-on for Cisco ASA from Splunkbase by clicking
NOTE:
Browse more apps from the Manage Apps page. You will log into splunk.com to install the add-on.
16. After the add-on is installed, navigate to Search > Search.

17. After a couple minutes, run the data model search again:
| datamodel Network_Traffic All_Traffic search | search sourcetype=cisco:*
| stats count by sourcetype
You should now see the cisco:asa and cisco:sourcefire source types.
As of Splunk Add-on for Cisco ASA version 4.0.0, the cisco:fwsm and cisco:pix source types are no
NOTE:
longer supported. Therefore, these events are not normalized with the Cisco ASA add-on.
18. Because the Network_Traffic data model powers the searches for most of the network-oriented
dashboards and several correlation searches in ES, you have successfully normalized log data from your
Cisco ASA appliance into ES. Run the following search:
| tstats summariesonly=t count from datamodel=Network_Traffic.All_Traffic
where sourcetype=cisco:* by sourcetype
You might not see the new source type because, while the data is being normalized to map to the Network
NOTE: Traffic data model, the summariesonly setting is showing only events in accelerated data models and the
accelerated data is only updated once every 5 minutes by default.
19. To force the acceleration, navigate to Settings > Data models > Network Traffic, and expand the data
model to see the details. Under ACCELERATION, click Rebuild.
20. Click Update to view the progress of the rebuild.
21. Wait a few minutes, then run the tstats search again—you should now see both the cisco:sourcefire
and cisco:asa source types.
Any correlation search or dashboard searches using accelerated data will now see all the events.
Module 8 Lab Exercise – Building a Custom Add-on
Description
Your environment has a locally built audit system running to manage transactions between systems during
online purchase situations. This data is being ingested by Splunk but is currently not available in ES because it
is not being normalized to any CIM data models. You will create and implement a custom add-on which maps
the events to the correct data model and normalizes the fields required by ES. The events you need to
normalize have a source type of bcg:accounting.
An example bcg:accounting event:
Thu May 12 19:18:48 2016 device=acct_server policy=3 service=tcp action=allow sent=1933
received=351 host_from=ACME-006 host_to=BUSDEV-005 src_port=4505 dst_port=803 CRC=3423
A discussion with a local sys admin determines the following information about the bcg:accounting source
type:
“The device field is the hostname of the accounting machine. policy is an internal code used by
accounting. service is the network protocol. action can be “allow” or “deny”—deny would only happen
if the transaction was invalid. sent and received show the number of bytes in the actual transaction,
and CRC is the checksum for the transaction. host_from and host_to are the hostnames of the two
machines involved in the transaction, along with their ports.”
Steps
Scenario: Based on this discussion, you decide to normalize this data into the Network Traffic data model
so that the events will be available in ES searches and views that depend upon that data model.
Task 1: Plan the add-on.
1. Open the documentation for the Network Traffic CIM data model:
docs.splunk.com/Documentation/CIM/latest/User/NetworkTraffic
In the following table, identify each CIM field in the Network Traffic data model that corresponds to each field
in the bcg:accounting source. If the source field does not correspond to any CIM field, mark the CIM Field
column N/A. In the Action column, indicate which action is required for normalization: Field Alias (field name
change), val (value change or creation), or N/A (i.e., no action is required).
Source Field CIM Field Action

device
policy
service
action
sent
received
host_from
host_to
src_port
dst_port
CRC
2. From the ES app, select Search > Search and run the search over the Last 24 hours:
index=main sourcetype=bcg:accounting
There are many events being generated for this source type. Also note there are no tags—so this source
NOTE:
type is not being normalized to any of the CIM data models.
3. Run this search over All time:

| datamodel Network_Traffic All_Traffic search | search sourcetype=bcg:accounting
| stats count as Total_Normalized_Events
Total_Normalized_Events should be zero. The bcg:accounting source type is not being normalized.
Task 2: Create the BCG add-on.
4. Navigate to the Splunk Add-on Builder app.

5. Click New Add-on.
6. Name it bcg (the builder will name the actual add-on TA-bcg). Leave all other fields at default and click
Create. The bcg app project home page displays for your add-on.
You may also see a system message to restart Splunk. This is not required at this time. You can
Important!
delete the system message.
7. From the app navigation bar, click Manage Source Types.
8. Click Add > Import From Splunk.

9. From the Select a Source Type drop-down menu, select bcg:accounting. We do not need to configure
any custom time stamps or event breaking, so click Save.
You should now see a row in the Manage Source Types page for bcg:accounting, with sample events
found.
10. Click Map to Data Models from the app navigation bar.
This page is used to create a tagged event type, as well as the necessary field aliases and eval
statements.
11. Click New Data Model Mapping.
The Define Event Type view is displayed. You will define an event type that the mapper will use to identify
the specific events that will be mapped to CIM data models.
12. In enter a name for the event type, type: bcgAcct.
13. In Select one or more source types, select bcg:accounting.
The search bar is populated with (sourcetype=bcg:accounting). This includes all bcg:accounting
events. If needed, you could alter this search string to restrict the event type to more specific events, but
for this exercise, this is fine.
14. Click the search icon . You should see several pages of bcg:accounting events.
15. Click Save. The Data Model Mapping Details view is displayed. Your bcg:accounting fields are
displayed on the left.
16. On the right, click Select Data Model(s), and expand Splunk_SA_CIM to view the CIM data models.
These are the available data models in the CIM.
17. Expand the Network Traffic data model and then check the box to the right of the All Traffic data model
object. The fields in the Network Traffic/All Traffic object are displayed on the right.
18. Click Select (green button in the upper right).
Now you have the Network Traffic data model’s All Traffic object fields displayed on the right, and you
can begin mapping bcg:accounting fields to the corresponding CIM Network Traffic data model fields.
NOTE: The action and src_port fields are green—they do not need an alias, since the names already match.
19. For each field in the table above that is marked as Field Alias do the following (ignore fields marked N/A
or Eval):
● Select New Knowledge Object > FIELDALIAS to add a new row.
● Click on a source field on the left to fill in the Event Type Field or Expression.
● Click on a target field on the right to fill in the Data Model Field.
● Click OK to save the new field alias mapping.
Important! Follow the above steps for each of the 7 Field Alias fields in the table above.
20. For each field in the table above marked Eval (the action field) do the following:
● Select New Knowledge Object > EVAL.
● Enter the following in Event Type Field or Expression:
case(action="allow","allowed",action="deny","blocked")
● For the Data Model Field, click the action target field on the right.
● Click OK to save the new eval mapping.
You should end up with a total of eight mappings, seven Field Aliases and one Eval object as shown
Important!
here.
21. Click Done. On the Data Model Mapping page, you will now see a row for the new mapping you have
created.
22. Click Validate & Package from the app navigation bar.
23. Remove Field Extraction and App Precertification from the list of validations and click Validate.
The validation tests execute—this can take a couple minutes.
24. While the validation is processing, click Download Package to download your new add-on to your local
workstation.
This creates a .spl file on your workstation, which is a compressed .tgz file.
25. On your workstation, locate the TA-bcg_1_0_0.spl file.
26. Change the file extension to .zip or .tgz and double-click it to extract the contents into a directory.
27. Examine the TA-bcg directory contents.
The primary normalization configurations are in the default directory, in the props.conf,
eventtypes.conf and tags.conf files.
You do not need to install the add-on on your lab server—the add-on builder automatically added it to
NOTE:
your search head, so you can test the add-on.
28. After the validation process is complete, you should see no errors or warnings.
29. You can also use Splunk Web to view the contents of your TA-bcg add-on. From the main Splunk menu,
navigate to Settings > All configurations.
30. From the App drop-down menu, select bcg (TA-bcg).
31. Make sure Created in the App is selected. You should see nine items: seven fieldaliases, one
eventtypes, and an fvtag object.
32. Navigate to a new search window and run this search over All Time:
| tstats summariesonly=t count from datamodel=Network_Traffic.All_Traffic
where sourcetype=bcg:* by sourcetype
The count for Total_Normalized_Events should no longer be zero, indicating the bcg:accounting
events are being normalized. These events will now be available through the Network_Traffic data model
for all ES correlation searches and views.
See docs.splunk.com/Documentation/ES/latest/Install/InstallTechnologyAdd-ons for details about
configuring additional regular expressions for ES app import.
Module 9 Lab Exercise – Tuning Correlation Searches
Description
In this lab exercise, you will examine existing correlation searches to identify search thresholds, both numeric
and dynamic.
Steps
Task 1: Identify thresholds in correlation searches.
1. In the ES, navigate to Configure > Content > Content Management.

2. From the Type: drop-down, select Correlation Search.
3. Use the filter field to locate the Excessive DNS Failures correlation search.
4. Click the Excessive DNS Failures correlation search for the DA-ESS-NetworkProtection app and
examine the search string.
NOTE: There are two Excessive DNS Failures correlation searches. Be sure to pick the correct one!
5. Find the portion of the correlation search that represents the “threshold”. You may have to scroll down in
the Search pane.
What part of the search expression defines the threshold for creating a notable event? _______________
How many DNS failures does it take to cause a notable event to be generated? _____________________
What would you do if you wanted to increase or decrease this threshold?

_______________________________________________
6. Examine the search expression for the Brute Force Access Behavior Detected correlation search.
What part of the search string defines the threshold? _________________________________________

Module 10 Lab Exercise – New Correlation Searches
Description
In this lab exercise, you will build a custom correlation search to look for successful SSH login activity—which
is prohibited in your environment—to create notable events. Therefore, your analysts are proactively alerted to
the prohibited activity on the Incident Review dashboard.
Steps
Task 1: SSH logins are prohibited in your environment. Create a custom correlation search that
detects successful SSH logins and generates a notable event to alert analysts.
1. From the Content Management page (Configure > Content > Content Management).
2. Click Create New Content and select Correlation Search.
3. Enter the following values:
● Search Name: SSH login detected
● App and UI Dispatch Context: Enterprise Security
● Description: SSH login detected
4. For Mode, click Guided. Click Enable Guided Mode when prompted with the warning.
5. Complete the steps of the Guided Search Editor with the following information:
Data
o Data source: Data Model
o Data Model: Authentication
o Dataset: Successful_Authentication
o Summaries only: Yes
o Time Range: Last 15 minutes
o Click Next
Filter
o Click Next to skip
Aggregate
o Click Next to skip
Analyze
o Field: Authentication.app
o Comparator: Equal to
o Value: sshd (case sensitive)
o Click Run search. A new search window opens, and events should display
o Close the search window
o Click Next
Done
o Review the final search, it should look like this:
|from datamodel:"Authentication"."Successful_Authentication"|where 'app'="sshd"
o Click Done to add the search string to the correlation search.
6. From the New Correlation Search window, leave the Annotations, Unmanaged Annotations, Time
Range, and Trigger Conditions to the default settings.
7. For Throttling, set the Window duration to 300 seconds and the Fields to group by to dest.
This configures the correlation search to create no more than one notable event per host every 5 minutes.
Fields to group by is a multi-value field. Enter each value and press Enter, otherwise you will receive an
NOTE:
error when saving the search.
8. Click + Add New Response Action, then Notable. Use the following settings, leaving all others default:
● Title: Successful SSH connection on host $dest$
● Description: There has been an SSH connection on host $dest$
● Security Domain: Access
● Severity: High
● Default Owner and Default Status: (leave as system default)
● Drill-down Name: View SSH events on $dest$
● Drill-down Search: index=main dest=$dest$ *sshd*
● Drill-down Earliest Offset: $info_min_time$
● Drill-down Latest Offset: $info_max_time$
The above options create a drill-down search that returns all SSH events for the destination(s) detected by
the correlation search.
9. Leave all other fields default and click Save.
10. Once the correlation search is successfully created, click Close.
12. After a few minutes, open a new search window and run the following search for the Last 60 minutes:
index=notable search_name=*SSH*
After a few minutes, you should see a notable event.
What is the full name of the correlation search (Hint: search_name field)?__________________________
13. Navigate to the Incident Review dashboard.
14. Locate a Successful SSH connection on host notable event (at or near the top of the notable event
results).
15. Expand the notable event and click the View SSH events on {dest} link.
You should see all sshd events from the impacted destination host.
Module 11 Lab Exercise – Working with Assets & Identities
Description
In this lab exercise, you will adjust the priority level of selected systems in an “assets” lookup, which in turn
increases the severity level of any notable events associated with the systems. You will also create two swim
lane searches that track successful and failed logins for an identity. You will use the Identity Investigator to
view the details of an identity and the events in the newly created swim lanes.
Steps
Scenario: You are about to go live with a new customer-facing website that has been developed on a set of
servers. These servers have been located behind the firewall up to now. However, router tables
are now being updated and these servers will be accessible to the public. You need to change the
server’s priority in ES.
Task 1: Modify asset priority for PROD-MFS servers.
1. Navigate to the Incident Review dashboard and search for Endpoint domain notable events for servers
that start with PROD-MFS (Hint: PROD-MFS*) over the last 24 hours.
You should see a few pages of notable events, and the urgency should be Medium. This is because the
servers’ priority is set to Low, and the severity of the correlation search(es) is High, causing the overall
urgency to be set to Medium.
Since you are going live with the PROD-MFS-XXX servers, you want to increase the priority as a mission-
critical asset.
2. Navigate to Configure > Data Enrichment > Asset and Identity Management.
3. From the Asset Lookups tab, click the demo_asset_lookup link under the Source column.
The demo_assets and demo_identities lookups contain sample data that can be used for testing
NOTE: purposes. An ES admin can edit the identity and asset lookups though Configure > Content > Content
Management. Filter on Type: Managed Lookup and select either Assets or Identities.
4. Scroll through the rows until you find a list of servers with nt_host names PROD-MFS-001 to
PROD-MFS-006.
5. Change all PROD-MFS servers from low to critical. The background should change to red.
TIP: Type critical for the first server, then copy/paste to update the other five.
6. Click Save.
It will take a few minutes for your changes to apply. Any changes you make are not validated for formatting
NOTE:
before being saved.
7. Wait several minutes, then navigate back to the Incident Review dashboard.
8. Search the Endpoint Security Domain again for the PROD-MFS* servers.
The Urgency value should now be Critical for all PROD-MFS* notable events. This is a retroactive change
and all new notables for these servers will also be Critical.
Scenario: You would like to use the Identity Investigator to easily track authentications.
Task 2: Create two swim lane searches that track successful and failed logins for an identity.
9. From Configure > Content > Content Management, click Create New Content and select Swim Lane
Search.
10. Create a new swim lane search with the following information:
● Search Name: Failed Authentications
● Search Title: Failed Authentications
● Search:
| tstats `summariesonly` values(Authentication.action) as
action,values(Authentication.app) as app,values(Authentication.src) as
src,values(Authentication.dest) as dest,values(Authentication.user) as user,count
from datamodel=Authentication.Authentication where Authentication.action=failure
AND ( $constraints$ ) by _time span=$span$
● Drilldown Search:
| from datamodel:"Authentication"."Authentication" | search
Authentication.action=failure AND ( $constraints$ )
● Color: select a color for the swimlane
● Entity Type: Identity
● Constraint Fields (click <Enter> or <Tab> for each entry): Authentication.src_user,
Authentication.user, src_user, user
11. Click Save.
12. Create another new swim lane search with the following information:
● Search Name: Successful Authentications
● Search Title: Successful Authentications
● Search:
| tstats `summariesonly` values(Authentication.action) as
action,values(Authentication.app) as app,values(Authentication.src) as
src,values(Authentication.dest) as dest,values(Authentication.user) as user,count
from datamodel=Authentication.Authentication where Authentication.action=success
AND ( $constraints$ ) by _time span=$span$
● Drilldown Search:
| from datamodel:"Authentication"."Authentication" | search
Authentication.action=success AND ( $constraints$ )
● Color: select a color for the swimlane
● Entity Type: Identity
● Constraint Fields (click <Enter> or <Tab> for each entry): Authentication.src_user,
Authentication.user, src_user, user
13. Click Save, and Back to Content Management.
Task 3: Confirm the newly created swim lane searches in the Identity Investigator.
14. Navigate to Security Intelligence > User Intelligence > Identity Investigator.
15. In the Identity Investigator click Edit.
16. Under Collection, select the Custom radio button.
17. Under Individual Lanes, select the boxes for Successful Authentications and Failed Authentications.
(You can uncheck the boxes for unwanted lanes.)
18. Ensure the Time Range Picker is set to Last 24 hours.
Hint: The Time Range Picker is located below the swimlane titles.
19. Enter username admin in the Search for identity box and click Search.
20. Review the swimlane search results by clicking some of the colored bars and viewing the information on
the right. (Remember, the darker bars contain more results.)
NOTE: Note the apps that user admin has successfully accessed, and those they have failed at accessing.
Module 12 Lab Exercise – Threat Intelligence Framework
Description
As an ES administrator, you need to add new threat intel sources to your system, and confirm they are working
properly.
Steps
Scenario: You notice traffic from IP addresses that could belong to hijacked systems. Fortunately, there is a
threat list for hijacked systems available at http://www.iblocklist.com.
You will download the hijacked servers list, which looks like this:
# List distributed by iblocklist.com
Hijacked:2.56.0.0-2.59.255.255
Hijacked:5.34.242.0-5.34.243.255
Hijacked:5.72.0.0-5.75.255.255
Hijacked:5.180.0.0-5.183.255.255
...
Each entry is two fields: the description, followed by the IP address or range, separated by a colon
NOTE:
(:). You will use this in your threat list definition.
Task 1: Add a threat list.
1. Navigate to Configure > Data Enrichment > Threat Intelligence Management.

2. From the Sources tab, click New and select Line Oriented.
3. Create the new threat list using the following values for the indicated fields (leave unspecified fields at
default values):
● General tab:
o Name: hijacked_ip_addresses
o Description: List of IPs hijacked by people who are spammers or generally up to no good.
o Type: hijacks
o URL: http://list.iblocklist.com/?list=tbnuqfclfkemqivekikv
● Parsing tab:
o Delimiting regular expression: : (a single colon)
o Fields: description:$1,ip:$2
4. Click Save.
5. Make sure “hijacked_ip_addresses” appears in the Threat Intelligence Management > Sources list.
Note that supplemental threat lists can be deleted, but the default lists cannot. Also, note that the weight
field, which defaults to 60, can be used to increase or decrease the relative risk associated with events
created by this threat list.
6. In ES, navigate to Security Intelligence > Threat Intelligence > Threat Artifacts.
7. In the Intel Source ID field enter hijacked_ip_addresses and click Submit.
8. After the search completes, click the Network tab. Scroll down to the IP Intelligence panel, to view the
threat list’s content (IP addresses) from the download.

ES Admin - v7.1 - Id0501 - LabGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ES Admin - v7.1 - Id0501 - LabGuide

Uploaded by

Copyright:

Available Formats

Administering Splunk Enterprise Security Lab Exercises

Splunk Logon Credentials:

1. Record your ES server URL (provided by your instructor): _____________________________________

Important! The lab server runs on port 8443.

Task 2: Make an installed app visible on the Splunk homepage.

6. Click the Apps cog icon.

Task 3: Customize Splunk Preferences for the Administrator account.

20. Select All Fields.

Task 1: Use the Security Posture dashboard.

1. Navigate to the Security Posture dashboard.

9. Reset the Incident Review dashboard by clicking Incident Review.

Task 2: Continue researching unauthorized network access.

Task 3: Begin working the issue.

20. Click Incident Review.

Task 6: Test workstation status.

35. Clear the Incident Review dashboard by selecting Incident Review.

43. Select +Add New Response Action and select Ping.

Task 7: Remove the false positives from the list of incidents.

52. Click Save changes and close the window.

Task 8: Suppress notable events.

1. Navigate to the Incident Review dashboard.

3. Review the risk-based fields available for a specific Risk Notable.

9. Navigate to Configure > Content > Content Management.

10. On the Drilldown Editor configure the following:

Task 2: Create two investigation Workbench Panels.

25. Click Save.

28. Do not click Save yet!

30. The Token Value field must be exactly:

Task 3: Create an investigation Workbench Profile.

● App: Enterprise Security

● Description: Detects IDS/IPS activity.

37. Click Save.

Task 5: Create an investigation to test your configuration.

40. Click Add Selected to Investigation.

1. Make sure you are logged on as admin.

4. Disable the following add-ons:

Task 2: Create an app package for your indexer(s).

6. Navigate to the Enterprise Security app.

10. Click Download the Package.

1. In ES, navigate to the Security Posture dashboard.

Task 2: Examine the search behind a Key Indicator.

8. In ES navigate to Configure > Content > Content Management.

Task 3: Modify dashboard permissions.

12. Make sure you are logged in as admin.

14. From the Search menu, select Dashboards.

Task 4: Customize navigation.

Task 6: Create a SOC manager role and give it specific permissions.

Task 7: Confirm the capabilities of the new SOC Manager account.

59. Log out of ES as the soc_manager and log in as admin.

16. After the add-on is installed, navigate to Search > Search.

Task 1: Plan the add-on.

Source Field CIM Field Action

3. Run this search over All time:

Task 2: Create the BCG add-on.

4. Navigate to the Splunk Add-on Builder app.

7. From the app navigation bar, click Manage Source Types.

8. Click Add > Import From Splunk.

1. In the ES, navigate to Configure > Content > Content Management.

What would you do if you wanted to increase or decrease this threshold?

What part of the search string defines the threshold? _________________________________________

Task 1: Modify asset priority for PROD-MFS servers.

Task 1: Add a threat list.

1. Navigate to Configure > Data Enrichment > Threat Intelligence Management.