Guardium Big Data Intelligence (GBDI) v3.2.

2 - Hands-on
Lab – Short version
This Hands-On Lab is designed to get you familiar with using Guardium Big Data Intelligence. You will
practice the following:

1. Explore GBDI’s pre-defined reports

2. Reduce the number of rows in a report, by filtering out “noisy data”
3. Explore GBDI’s data collections using elastic search (“Kibana”)
4. Use Guardium’s pre-defined groups as search filters
5. Build graphical reports and dashboards

1. Image Credentials

VM Image Credentials

Password for Guardium10

environment on
Skytap

GBDI GUI: admin/Guardium12#

Linux command line:

root/Guardium12#
Additional users for the GBDI GUI:
user2 .. user25
Password: Guardium12#.
If prompted to change password, change it to
Guardium12$

2. Accessing the GBDI interface

1
1. Click on the link in the email you received after you schedule the demo.
2. If prompted for a password.
a. Enter Guardium10
b. Click the Submit button.

3. You should see this image:

4. Click on the VMs tab to go to the GBDI VM image and click on the play button to start the
VM Image.

5. To open a browser window to the GBDI interface, follow these steps:

a. Open the email your received when you scheduled the GBDI environment and find the
URL to the environment:

2
 b. Paste the URL in a browser window (we suggest Firefox or Chrome) and append
/?ports=y to the end of the URL
https://labs.edu.ihost.com/XX.XXXXXXX.sX/XXXX/?ports=y

c. You will see the list of URLs (https published services) for GBDI. One for port 8443 and
the other for 22 (SSH). Click on the https service for port 8443.

d. The GBDI interface will come up.

3. Getting Started on GBDI

a. Logon to GBDI : admin/Guardium12#

b. Set the timeframe to the last 1 year (right hand corner of the main dashboard) – The timeframe
window needs to include November of 2018
Note: to work on a larger amount of data, you can set the timeframe to the last 1 or 5 years.

Your Dashboard will look like this:

3
 4. Navigating through GBDI out-of-the-box reports
a. On Reports drop down menu, select Failed Login Offenders and click on Submit. You will find
out which Database Users are generating the highest number of Failed Login errors.

b. Hit Submit again.

You will see a report where the data is grouped by Server, Database type, Instance/Service name
and type of SQL Error that caused the failed login.
Note: the report is on a separate tab in your browser.

4
c. We see that there are 35 errors SQL on the OracleOra12 instance. If you click on the […] under
Sources (on the Oracle12 row), it will give you more details of the DBUsers, IP addresses that
generated each of those SQL error2.

d. Now you have more specific details of which user is getting most of the SQL errors. For example:
- 6 errors ORA-01017 (invalid user name/password) came from user Bill on a particular client IP

- 16 errors ORA-01017 came from user System on a particular client IP

If you are a DBA, you don’t need to read a long report with all SQL errors. The grouping (or reduction) helps
the key stake holders take action and go after the exact source of the failed login.

On a “real” production environment, you would be able to quickly narrow down the sources for millions of
failed logins.

e. Close this report tab in your browser.

5. Reducing Data
a. On the main GBDI Dashboard (go back to the original tab), go to Reports , click on the drill down
menu, select Sessions > Opened On, click on Submit.

5
b. You can adjust several run time parameters on a report. For example, you can use Guardium’s
groups as filters for the report. In this report, both Server and User Groups are populated with
group definitions from Guardium. The groups’ definitions from Guardium are updated on an hourly
basis.

c. You can run the Session report filtering on “Admin Users” group. This will give you a report of all
database sessions started by users in this group (which are privileged users).

If you run the report, you will see that this filter still brought a lot of rows. In the next step you will
use different filters for the report. You can close the report tab.

d. From the main GBDI dashboard, open the Sessions > Opened On report. Hit Submit and do not add
any run time filter. You will notice that the report has a lot of data.

Note: The timeframe is set to the last 6 months because that’s the period we set in the main GBDI
dashboard. You can change that as you run a report, by picking a different date in the From field.

6
 e. Click on Reduce. Let’s use the reduce function to see who has been accessing all databases in the
last 6 months.

f. Increase the number of rows to 50. Main Reduce options:

Omit Do not include this field in the reduced result. This is
the default option.
Unique Include this field and use it as a “group by” parameter
Per Day It will give a summary count of that field on a daily
interval
Combined Groups the fields marked as Combined

g. We will use the reduce options to answer the following scenario: List the users that are accessing
each Database Instance in the last 6 months

Mark as unique the following fields: Database name, Server Host Name, Server Type
7
Mark as combined: Database User Name. (This will combine or group all the different Database users per
Database Name, Server and Server type)

Increase the Limit to 10000 and click on Reduce Now

h. The report shows the count of sessions per Database name, and the list of users who accessed each
database. With reduce, we from thousands or millions of rows to a much more manageable list.

This report can also be used as a baseline for the regular activity, by proving a list “regular” users that
access each database.
For example: Root and GRDVA users are the approved database users for MySQL. If a user not in the
approved group connects to the Employees database, you can define an Alert.

Note: Alerts can be defined in GBDI or in Guardium. We are not covering it in this Lab.

6. Using Elastic Search (“Kibana”)

a. In the main GBDI Dashboard, click on Discover:

8
b. Change the timeframe to Absolute and set it to Nov 1, 2018.

c. From the collections available, choose sonargd-exception

d. Click on Exception Type ID and then click on Analyze entire selected data. It’s important to choose
Analyze entire selected data to analyze the entire result set. Otherwise it will analyze just the initial 500
records.

e. Now you will see a list of all exceptions available. Let’s choose only SQL Errors by clicking on the plus
sign.

f. You can repeat the step above and filter on Server Type Oracle

9
f. You will notice that the SQL Errors filter is added to the filter list on the top of the page.

g. There are still too many rows. To further narrow the result set, you can select with the mouse the days in
the Histogram that have a high number of SQL Errors, by drawing a box around the days with a high
number of exceptions. That will narrow the result set to only those days.

h. You will also notice that the data in the report itself looks very raw and is hard to read. So the best thing
now is to select a few fields to show in the report.

10
i. On the left side select the field DB User Name and click on Add

j. Add DB Error Text, Database Name, Exception Description, SQL String that caused the exception. Now the
report looks more readable, but there are still many repeated rows (such as for Exception ORA-00942). In
order to remove the duplicate rows, click on the Reduce Noise Icon.

11
k. After Reduce Noise is done, you will see a Count field on the list of fields available on the left. Add this
field to the report.

l. You will see the Count field on the right, in the report. Click on the twisty by the Count to get the records
in descending order.

m. Now you will see the DB Users with most exceptions. You can click on the arrow on the top left to
expand the report area and see all the fields in the report.

n. Open the twisty by the Time field and you will see all the details of the offending SSQL stmt, and the
entire string that caused the SQL Exception.

12
o. You will notice that there are still many records, but using the Reduce function we could easily group the
records and quickly find the worst offenders when it comes to generating SQL Errors. If you scroll down you
will see that the report is no longer than one page.

7. Data discovery using Guardium groups

a. In the GBDI main dashboard, set the timeframe to the last 6 months and click on Discover. That will
bring up the Kibana elastic search interface.

b. Select the sonarg-instance collection and set the time frame to search data from the last 6 months.

13
c. The purpose is to find who has been accessing objects in the Guardium group “Bank Objects” in the
last 6 months. In order to use Guardium groups in a search on GBDI, use the GBDI function OV:
“name of the Guardium group” (for Objects and Verbs).

OV: will allow you to run searches on Guardium Object groups and Guardium commands (verbs)
groups:

In the search bar, type OV:”Bank Objects” and hit enter. You will see that the number of hits will
decrease.

d. Let’s further narrow the search to find out who has been extracting data from the Bank Objects
group. For that, you will combine two groups in the search criteria: OV:”Bank Objects” AND
OV:”Select Command”.

14
e. Now we will drill down to find out which DB Users have been extracting most of the data from the
Bank Objects group. This will help see if there is any suspicious user accessing these tables.

On the left side, click on DB User Name, click on Analyze entire data set and click on Add.

It’s important to click on Analyze the entire data set, otherwise it will only search in the last 500 rows,
and not the entire data set.

f. Now you see all Db Users that have been running Select commands on the Bank Objects group. While
all the users may seem legitimate, there are a few suspicious users in the list. You should see
Rogue1203 and Roge1126.
Click on the + sign by the DB User Rogue1203 to add this particular user as a filter.

15
g. Now we can examine in details the record of a suspicious user that has been accessing a group of
sensitive objects (Bank Objects). You can open the twisty by the timestamp and that will show all the
details, including the SQL command that was executed, server information, etc.
The UID chain shows that the OS user root switched to Oracle and used sqlplus to connect to the
database as Rogue1203.

16
h. You can remove any filter by clicking on the trash can, in the search bar. You can remove all filters by
clicking on New, on the very top of the screen,

8. Creating Reports and Dashboards

8.1 Pie chart showing Session count per Database Type and DB User

a. On the left menu click on Visualize. The click on the plus sign.

b. Select the pie chart.

c. Choose the session collection

17
d. Click on Split slices and choose Terms.

e. On Field choose Server Type. Click Play to preview the chart.

f. Now on each slice (representing server types) we will show the number of DB Users. Click
on Add sub-bucket.

18
g. Click on Split slices, then choose Terms. For field pick DB User Name. Click on Play.

h. Change the size to 20 (to show more users). When you hover over each color it will display what it
represents. The inner layer are the server types. The outer layer are the users with significant
activity.

i. If you click in one particular slice of the pie, it will redraw the pie based on the filters from that
slice.
19
j. Save as Session_Count_Per_User_[YourUserID]

8.2 Adding graphs and reports to a Dashboard

a. On the left menu, click on Dashboard. The click on the + sign to create a new Dashboard.

b. Click on Add

c. Now you will add the visualizations you created in the previous steps. You just need to click
on the visualization name and it will be added to the Dashboard at the bottom of the page.
• Session_Count_Per_Database
• Session_Count_Per_ServerIP
20
 • Session_Count_Per_User
• Session_Count_Per_Database_Type

d. Click on Saved Search and add the Session_Details tabular report.

e. Scroll down and you should see your populated Dashboard. You can move the
visualizations graphs around and make the tabular report wider:

f. Click on Save and name your Dashboard [UserID]_Session_Dashboard. Check Store time
with dashboard to save the “Last 90 days” timeline w/ the Dashboard.

g. The dashboard is completely interactive. For example, say you only want to see
information related to MySQL sessions. Click on MySQL and then on the + sign.

21
h. Now all visualizations are filtered on MySQL. To remove the filter, hover over MySQL on
the filter and then click on the trash can icon.

i. Similarly, on the visualization Session_Count_PerUser, you can filter on the activity of a

particular user id, such as ROGUE

*** END OF THE LAB ***

22