Monitor your database without logging

[ MUSIC ] BRAVO: In this demonstration, we’re going to show the integration between
QRadar and Guardium. We all know that Guardium is the
best tool to protect databases. It can warn you when somebody is
trying to get access to a database that they’re not supposed to, and
it can even block that access. But it does that without turning any logs on. So, and that’s the beauty of it
because it saves a lot of performance, and many other reasons to do that. But so we love Guardium, but how do we
make Guardium to tell QRadar about things that it’s blocking or it’s
warning or it’s finding about? So, that’s what this demo’s all about. Before I proceed, I want to thank our friend Dr.
David Druker and Steve Cain who have created, put and maintained this system that
we’re using for the demo today. So, we’re going into this fictitious
system called Altoro Mutual, and we log in as the administrator of it. And in this particular corporate
account, we have $52 million. Okay. Good. So, now let’s say that we perpetrate some
sort of advanced persistent threat attack and we gain access to the system and we can
launch a console and we can move the account, the money from one account
to another to cash it in. So, it’s actually if you…if we actually
run this shell command here, we can see that, we see the same balance of
$52 million back in there. But I can actually run a SQL command that
will enable me to actually steal the money. So, that command actually moves the account
from…the money from one account to another and left only $1.61 into that account. And in fact, if I go here and refresh this
screen, we see that there’s only $1.61 left. So, the attack has been perpetrated. But actually the beauty of this is that
those events that Guardium actually found — and we show the policy, we’ll show
the policy name in a second or so — has actually been sent to QRadar. So, if we go to the QRadar console on the logs,
and we are filtering to get only these events on the Guardium event, we get two
events in here, and actually we can see that there has been, the DB2 admin is
the user who perpetrated this attack. And here we can actually even
see that this is a LEEF format, which is one that QRadar understands
very well, and it’s supported by those pipes, characters that we see in there. And we actually see the actual command, the SQL command that was
actually executed for that attack. But how do we made all this work? So, let’s start by going
into the InfoSphere there, the Guardium, InfoSphere Guardium console. So, here we’re going to go to tools, and the
option is policy builder I believe it is. Just click in here because here
is where you define the policies. By no means know much about Guardium,
but I at least have been shown this. So, here in the integrated demo is the
policy that was set up for all these. So, let’s click here and modify. And we see that policy, we click here to edit. And these are the actual policies
that we’re putting in here. Actually I believe that if we click here
on the pencil, we can see it better. So, basically we are saying anyone that
is not DB2, the DB2 user is not Altoro, which in this case matches
because we were using DB2 admin. On this particular database, it’s
actually what the policy are, you can here define whether you want to log it
locally, whether you want to actually block it, or whether you want to alert, which
is actually what we want to do. And here we show that the message that we’re
using is LEEF, which is what QRadar understands. So, this is what sets that policy that says
when anyone tries to access the database that is not the username Altoro, an event
is going to send in a LEEF format to QRadar. I can even open, I already have
open a CLI interface in here. And we click here help to
see what commands do we have, and one of the commands that
we have is actually show. So, if we do show question mark to get the help, one of the things that we can actually
show should be here, remote logs. And here it is. Remote log. So, if we do show, remote log, we
can actually see the configuration. And this is the important
one, the daemon, that alert. And that’s the configuration on the port 514. This is how all this gets defined. The final piece is actually to go into QRadar’s
admin console and go into the log sources and actually define the DSN, which
is out of the box for Guardium. So, we click here, and you specify
like you do with any DSN here, you can specify the credibility
you want to give to Guardium event. I probably will give it a bigger credibility,
probably, credibility of ten to Guardium events. And this completes the puzzle. Now, there’s another thing that I can show you
just for sake of…the sake of completeness, is how Guardium can actually not
only detect that somebody’s trying to steal stuff but actually how to block it. And one of those policies, one of the things that you can actually do
is actually block a user. So, first let me click on this
executable here to put the money back. In fact, if we can even go here and refresh the
screen and actually have the $52 million back. And now let me actually open
another command, DB6. This, unlike the other one that we use,
this one actually is going to be blocked if it tries to attempt to steal the money. So, if we view accounts, we see
that there are the 52 million. If we try to execute the same
command to steal the money, we actually see that this one lets…that
didn’t go through like the previous one. In fact, if we click execute
the view accounts again, we see that the $52 million are still there. So, Guardium actually block
that attempt from me. Going back to QRadar, we even set this up
to, here it is, to generate an offense, and we see that the offense
is actually for the user DBA6. So, this is the one that
actually was actually blocked from accessing, from transferring that money. [ MUSIC ]

Add a Comment

Your email address will not be published. Required fields are marked *