Show TranscriptHide Transcript
In this video, we're going to be taking a closer look at rules in IARI. In particular, what does it take to build a custom rule that matches a problem we might have in our own environment? To draw this use case, consider a story like this. Imagine in a company last weekend they had a situation where the Hyper-V environment was taken down accidentally by a certain employee. The result of something like that happening could be a SQL database going offline, a major production system going offline. In other words, the outage or attack could be rather significant.
To continue this story, let's also imagine that we knew who it was. So if that person was Dan, let's go over and take a look right now at risk and high risk accounts, and search for Dan. Sure enough, he doesn't come up. Now, why is that? If you had an entitlement that enabled you to take down the Hyper-V environment, why isn't that something that Starling told me?
Well, quite honestly, Starling comes out of the box with a number of built-in rules that we consider best practices across an Active Directory environment, an Active Roles environment, et cetera. However, there might be a highly sensitive group within your own organization where you want to say, this is a group that has significant privileges, and I want to make sure I'm keeping track of anybody who gets added to that group.
Let's go take a look at my Active Directory environment and see the mistake that was made. So here we are in one of my demo environments. And sure enough, we found the Hyper-V administrator group right here. And if we double click on it, we can see that on the Members tab, I have two members, Joe and George. However, someone added SharePoint user group. This seems to me like a mistake. And this is the type of mistake that I might not be aware of if I didn't have a tool like IARI to tell me, you need to take a look at this. Something's wrong.
So what are the steps we need to take in IARI to make sure it knows that we consider this group a highly sensitive group, and we want to make sure we're monitoring people that are added to it? It's not as hard as you may think. Let's go back to IARI and create a custom rule that's going to notify us of changes to this group.
So here we are back on the rule screen, and what we're going to do is simply come over and say, let's create a new rule. So we'll click here. Now the first thing you need to do is choose a template that you'd like to build this rule from. And we're going to make the selection of administration group members. Here we'll give it a rule name. I'm just going to go ahead and give it the rule name Hyper-V administrators. And then finally, in my environment I have three different sources I can pull from for this query. In this particular case, I'm going to be paying attention only to dsgsoft.
Notice that when I make that selection it says, OK, you've made a selection in an Active Directory domain. So now I'm going to give you an editor that allows you to pick a group from an Active Directory domain. Let's open this up and we see a couple of choices available to us. The first one is basically saying, do you want me to be looking at a specific domain, or does it matter which domain this is coming from, et cetera. And in this particular case, I'm only really choosing dsgsoft to begin with. So we'll leave that first option like it is.
Take a look at the second box though-- groups with name, groups with names starting, ending, or containing. For instance, you might just want to say, hey, if there's a group out there called administrators, I just want to know about it. In this particular case though, we're just going to choose groups with name, come over here, and put in the name of that group. Now that we've done that, we'll just scroll up and click Save. The rule is saved, and now it's going through evaluation.
Notice in the box in the bottom left, it says three matched accounts. Let's go take a look at that. So already this is showing me that Dan, George, and Joe are all members of this high risk group. From here let's click on, see all three matched accounts. Let's click on Dan.
Well, now he can see some more information about how Dan got this capability of shutting down Hyper-V environments. In particular, if you come back over here on the right, we see that he's getting this through group membership. Let's click on the entitlement itself.
From here, again, we have some choices that we can make. We can go look up this information ourself; we could click on Request verification right here and start a workflow to a verifier who can tell us whether or not this assignment was made correctly. In any event, what's going to happen is someone's going to get back to that Active Directory environment and realize that Dan, who received this entitlement through group membership, actually achieved that entitlement by being a part of the SharePoint group. That's got to be a mistake. We're going to remove that entitlement and we're going to fix this problem. As a matter of fact, let's go do that now.
Here we are back in Active Directory. I'm simply going to go up to Hyper-V administrators, go to Members, and I'm going to look for that assignment that's been done through group membership. Sure enough, there it is right there, SharePoint user. This clearly is wrong for our environment. I'm going To highlight that, remove it, yep, click Apply, click OK. Now
