Role-based access control provides granular control
of what users can see and do in Microsoft Defender Security
Center.
In this video, I’ll demonstrate how to configure RBAC
in Microsoft Defender ATP.
Large organizations use tier-based models
to assign and authorize access to security systems.
For example, they typically need a first tier
that supports local operations in cities or countries.
It can investigate alerts but escalates
remediations to tier 2.
Tier 2 is a regional SecOps team that covers multiple countries
but doesn’t have global view.
It can investigate and also remediate threats
within its own region.
Tier 3 is a global SecOps team that handles
organization-wide responses.
It can perform all actions across the entire organization,
except in cases where there are special SecOps teams dedicated
to special assets, like executives’ machines.
In these cases, you want to limit who
can see data on those assets.
Role-based access control in Microsoft Defender ATP
supports this and any other tier model you choose.
Next, I’ll demonstrate how to define a role for the first
tier in this example.
Roles in Microsoft Defender ATP control
the actions users can perform in Microsoft Defender Security
Center.
You scope them by using machine groups, but more on that later.
I’ll start by creating a new role for Tier 1 SecOps teams.
This role will be able to triage and investigate alerts
but must escalate remediation actions to tier 2.
Therefore, I need to give this role permission to investigate
alerts, and that’s it—keeping in mind that all roles can view
data in the portal.
The other permissions available are only
appropriate for higher tiers in my example.
Active remediation actions is for tier 2 and above.
Manage security settings is for tier 3,
and special-asset roles.
Moving on I’ve already created Azure AD security groups
for this role—one group for each country—so I’ll add them
and save it.
Of course, I still have to repeat
this process for the remaining tiers, and you see those here.
Next, I’ll demonstrate how to scope which machines each user
group can manage by using machine groups.
Machine groups are based on criteria
like machine names, tags, domains, and other attributes.
Use them to limit access to alerts and data on a group
of machines—also to configure auto-remediation settings
for the group.
Continuing my example, I’ll add a new machine group for devices
in the United States.
The automation levels range from requiring
approval for any remediation to fully automatic.
For this team, I like the idea of remediating threats
automatically—no approval required;
no delays experienced.
Under Members is where I specify the matching rule
for this group.
I can use the computer name, domain, tag,
or operating system.
In this case, I want to match this group
to computers in the United States, based on their names.
And just to make sure the rule is correct,
I can preview some of the machines that match it.
Looks right, so I’ll assign the appropriate user groups to it.
Those include tier one in the United States,
tier 2 for North America, and tier 3 users.
Then, save my work and apply the changes.
Roles and machine groups enable any tier model you can imagine,
but machine tagging makes both controls even more powerful.
That’s next.
Machine tags are like hashtags, only
for computers in Microsoft Defender ATP.
Use them to represent anything, from a location, activity,
or importance.
The beauty of tagging is that you can move computers
in and out of machine groups dynamically,
just by tagging them, without having
to change group membership.
Using machine tags during an alert investigation
is a powerful example.
This machine is a high-value asset,
and it has an alert about the Dofoil attack.
I’ll tag this with the codename for the investigation.
During my initial investigation, I found other machines
that ran the same malware file, and so I also tagged them
with the same codename.
NOW FOR THE GOOD PART: Since I had previously
created a machine group for this outbreak, which
uses the tag as its matching rule,
a lot has happened behind the scenes.
Notice that Microsoft Defender ATP automatically added
the machines I tagged to this machine group.
That’s a great thing, too, since the teams investigating this
outbreak are from different tiers and user groups.
Works the other way, too.
Tagging can bring together machines
that normally live in separate groups
into a single group for investigation and remediation
by a geographically dispersed team.
Powerful stuff.
Tagging leads to an interesting question:
What happens when a machine is in multiple groups?
Easy answer: Microsoft Defender ATP adds the machine
to the highest priority group it matches—and only that group.
For that reason, important groups
like the one we created to investigate the Dofoil Outbreak
should be at the top of the list.
Otherwise, the machines you tagged during the investigation
will match their original groups instead of the specialty group.