[calm music]
>>In this video,
we're going to discuss building and configuring rules.
So we can access the rules page
by going to this Rules tab at the very top.
We have a couple of options
on how we want to roll out these rules.
We can just create a rule from scratch,
we can create a rule from one of our hundreds of templates,
and they're both very valid options.
One final way you could consider creating a rule
is if you go to the Events tab,
and you have a filter
that you already have pre-configured previously,
you would like to associate it
with some sort of action with it.
you can easily do that from here.
You can pick any of these filters,
click on the little drop down button,
and just do a Send Filter to Rule.
And that will essentially clone
all of the conditions for this particular filter
over to a brand new rule,
which you can then assign as an associated action with it.
But we're just going to start from scratch over here.
So the very first thing you want to do
when building a brand new rule,
really, every time, is to check our list of templates
to see if we have a template that will suit your situation.
It is far better to clone a template
and just assign an action to it,
than starting from scratch,
it's much less likely to have an error with it.
These templates are all vetted there,
we all know they all work.
So it's much quicker,
it's much easier,
and it's much more likely to be successful
the first time around
than building a rule from scratch.
So let's say we needed to build a brand new rule here
for something like critical account lockout.
Okay, something we want to monitor our critical accounts
for multiple login failures type of situation.
We'll do that,
we'll first check the template list
as see if it is something that we can use
that's appropriate for this.
So we can do just a keyword search.
Anything that might be appropriate,
such as account lockout, maybe,
or critical accounts.
Okay, so something like that.
So we got critical account logon failures.
We can actually hover our mouse over this
and read the description for it.
This sounds like about what we want to do,
so let's try and clone that.
Let's go to next.
Here, you can see the rule conditions of this rule.
This one's pretty simple, right?
User login failure,
where the destination account is in this list of accounts.
Now, I might want to make a modification here
because this list of accounts
is actually a built-in user-defined group,
which is a static list of accounts.
But I may want to substitute that with my own list
of possibly dynamic groups,
such as the directory service groups.
We've shown that in a previous video.
So let's make a slight modification here.
I'm going to click on Edit rule.
And instead of using this group,
let's sub it out for our very own directory service group.
I pull that up.
We have a list of accounts
that are pulled straight out of active directory.
In this case, I could do something like domain admin,
just drag and drop and replace that.
Now, this rule as it's built right now,
if you look at this whole rule section,
is designed to fire off for every occurrence.
So occurs at least one time in a 32nd window.
So I may not want this rule
to fire for every time a domain admin
fat-fingers a password.
That might be a little outside of scope,
or what I want to care about,
so I could make an adjustment here
and adjust some of these whole rule setting.
So I could adjust how many times
this particular set of conditions has to fire
before this rule will actually trigger.
So I could adjust this to say like,
half dozen times within five minutes.
That may make more sense in this context.
Below that we have this extra box
called the response window.
And the short of this is,
this box is designed to prevent old data
from triggering new rules.
Because rules are designed
for real time alerting or real time actions.
We don't want it to fire off of old data,
possibly hours, days, weeks old.
So what this is designed to do is,
compare the detection time
versus the insertion time of every event in this rule.
So if the difference between those two fields
is greater than five minutes, this will not fire.
So the extra short of it is,
you only ever need to adjust this value here,
is if your top row is greater than five minutes.
This would not work, if I were to save it like this,
this would not fire.
I will need to adjust this
to be at least 10 minutes as well.
But there's never any reason to adjust it downwards
that will do nothing.
So don't worry about that.
We'll just leave like this,
because that should work for our rule.
Now there is another important thing here
called the incurrence instance properties.
If I were to save this rule exactly like this
and just configure it,
it probably is going to work exactly as I intended
because this is a list of accounts.
So what could happen is,
I have one domain admin that failed to login two times.
A separate domain admin failed to login four times
all within that five minute window,
and that would still trigger this rule.
That's probably not what I'm going for here,
I want one account to fail six times
before this rule fires, right.
So we have what's called the current instance properties.
I can add a condition for that.
And I can essentially say,
this is a good field for this action.
And in this case,
I could essentially say that I want this particular field
the destination account to all be the same,
or all be distinct from each other.
So all six of these
has to have an identical destination account field
for it to apply to this rule.
That's exactly what I'm going for.
So I'm going to save it like that.
Now we have another option at the bottom
called set time when a rule won't trigger.
And this is also another safeguard
against too many rules firing too frequently.
Okay, so as far as rules goes,
you wanna make them as simple as possible
while getting the job done.
And part of that is
making it so they fire as few times as possible,
while still alerting you
to the stuff you need to be alerted about.
Now, most of that comes down
to building a really robust rule
that has very precise conditions.
But sometimes you can have the most precise conditions,
and it's still going to fire more often than you would like,
because they're receiving duplicate events
for some important event you care about.
There's a lot of reasons for that.
But there's an extra safeguard here
to prevent the rule from triggering too many times.
So if I were to click on this,
this is essentially forcing the rule,
no matter how many times the conditions are true
and the rule should fire,
it's actually only going to perform the action of this rule
one time every 30 seconds by default.
Okay, so if this rule fires 10 times in a minute,
you're only gonna get a couple of those emails,
which is much more manageable.
But ideally,
rather than rely on
this particular backup option, if you will,
it is much better to get the rule conditions,
as precise as possible
to prevent those additional rules from firing.
We'll go to next.
We just want to give this name, this rule a quick name.
Such as domain admin log on failures.
Give it a description, if you want to,
you can add tags as appropriate,
or you just curl them all out.
We have tags here for many different types of activities,
devices, compliance frameworks, etc.
Tag them as appropriate for you.
Then we have some final options,
enable the rule after saving.
So if you wanna automatically turn the rule on
and have it start doing its thing right away,
you can toggle that on.
You can also toggle on test mode.
This is more useful
if you're building your rule from scratch,
and you're not quite sure if it's going to work as anticipated,
you may want to toggle on test mode,
which, essentially, will still perform the correlation
and still trigger the rule as necessary.
But it's not actually going to trigger
any of the actions you specify below.
So if you were to set this up for a sent email action
is not going to flood your exchange server
with too many messages if it's not quite set up properly.
Okay, then finally, what makes a rule a rule
is really the action piece.
So this is where we set up
the actions of what we want this rule to do
when it actually fires.
This default is an incident alert,
which is something that's going to go into security port
that you can check off later and say,
we looked into this and it was resolved.
But maybe that's not what I want to do here.
Maybe I'll swap this out for a send email action.
We have a nice list of actions here you can choose from.
I'll choose send email message, go to next,
it's going to take me to the email configuration page
where I can choose which template I want to use.
Choose which recipients should be receiving this,
add a recipient here,
and then you'll see below that,
what the message will actually look like.
So here's your subject line, here's who it's from.
Here's the actual body of the message,
which is comprised of static text
along with these parameters, if you will.
These variables that have the dollar sign in front of them.
So what this is designed to do, when the rule fires,
it's going to look for the source event or events.
And it's going to pull these variables or these fields
out of the original event
and put them into the message body.
So you have more context and more detail in the message,
rather than having to just get the alert
and then go back to SEM and look it up.
Okay, so right now it's going to pull these two
out of the original event.
And I need to tell it, where are these,
what fields these parameters
are going to correlate to exactly.
So these ones are fairly obvious,
it's literally labeled the field names that we want,
so I'll just plug in the field names as appropriate.
And that will do.
Okay, now, this is a complete rule
for all intents and purposes.
So I can click on Create.
It'll show up on my list.
It'll be enabled automatically.
And this is good to go.
I'm going to pull up one of these rules
and just have another look at these actions sections for you.
We do want to—
let's pull up this one
—I do want to clarify something here really quickly.
For all the actions you see in this list,
these are all dependent on what's called
the active response type of connectors,
the active response connectors.
So, basically, all the actions you see here are commands
that are going to be sent back to some source device somewhere
to execute remotely.
Now to actually send the command back to a device
and have it translated properly,
we have to have the appropriate active response connector
configured and enabled for this and to be able to do that,
otherwise, the action will just be sent into the ether,
will go to nowhere.
Luckily, most of these actions are Windows associated,
you'll see we have disable the main account,
disable networking,
send a popup message,
create an account,
add or remove groups,
those are all sorts of
Windows related actions we can associate with here.
And these are all taken care of automatically,
because, as we discussed in the connectors video,
all of the Windows agents deploy with
a list of Windows connectors already,
and one of them is the Windows active response connector.
So all the Windows machines are going to be good to go.
But what if you want to choose one of these actions
that are not Windows specific, such as Block IP?
This will essentially tell your firewall
to shun an IP address based on this rule firing.
We don't know what firewalls you have.
And there's no agent to install on a firewall.
So this is something you have to configure manually
under the nodes page
and then the managers connectors sub page.
You have to go there,
configure the appropriate active response type connector
for your firewall,
or your other device,
that you want to send a command back to.
This is an important note
when you're talking about rules and actions
and that sort of thing.
We'll go through one more example here
just to show you what it looks like to build a rule,
totally from scratch.
I can click on this Create New Rule button.
And let's build a rule for say,
monitoring a USB mass storage device for file deletions.
We can easily do that.
So we'll add a couple of conditions here,
we're first going to start off with a,
so we're looking for a file delete event,
whereas the field name,
let's see,
field name is going to be provider SID,
equal to
wild card USB wild card.
Actually, that's probably
the only condition we're going to need for this one.
This is looking at all file delete events
where the provider SID is from USB defender, essentially.
So every USB defender everywhere
is going to have this USB defender
and then a five digit code associated with it.
So this will,
this basically forces it to filter down
all file, delete events to just from USB defender,
that's what we're going for.
So, very simple rule.
We can probably leave this whole rule section alone,
because we do want this to fire on
every file deletion, most likely.
So I'll just leave that alone.
Go to next,
name the rule.
Give it a description, add my tags,
enable test mode, if necessary,
find the associate or add my actions.
In this case, I might want to do something like,
send a popup message to the user.
Okay, now this case,
the fields I have to pop up here
aren't quite as obvious as they were in that template.
I have to choose the agent to send it back to.
Now, if I'm familiar with some events,
I know that this is probably going to be the agent,
the agent that sent this event over
is going to be the agent that I want to send the command back to.
So I can just point it directly
towards the detection IP field, like so.
The account name
is going to be the person that initiated the action.
So this is going to show up in the source account field.
You do that.
And then, finally, I have to provide a message.
So this is probably something
I don't want to just pull straight
out of one of the existing fields,
that probably isn't going to make a lot of sense.
So I could just switch this to a string constant
and type my message.
Whatever you want to put there,
we'll just add that in
and create
and that is that.
We can plug in a device and test that if you wanted to.
But that is a pretty simple straightforward rule
and it should just work.
So that is essentially how you build and configure rules.
Thanks for your attention.
I will see you the next time.