Let’s take a moment to think about how security operation centers (SOC) actually work.
Can security operations in an enterprise run as a single, flat team? Is it sensible for all SOC analysts to have access to the same set of assets, all the data collected from those assets, and the same set of response actions?
Or is it true that SOCs are typically arranged in tiers of expertise and capabilities to protect and monitor specific groups of assets split into different physical locations, functions, etc.?
If SOCs don’t run a single tier, their tools shouldn’t force them to.
Basic tiers of service
At their simplest, SOCs in enterprises support at least two tiers of services, represented by separate teams with varying levels of technical capability and oversight.
|
Tier |
Description |
|
Tier 1 (T1) |
Security personnel for initial response This team usually triages alerts and performs initial investigation. They often aren’t authorized to take remediation action and will often escalate complex cases. |
|
Tier 2 (T2) |
Security experts This team consists of more advanced security personnel with authority to take necessary actions. They handle more complex cases, applying more sophisticated knowledge of security and the threat landscape. |
A SOC solution with a simple role-based access control (RBAC) mechanism might provide sufficient functionality to support this basic two-tiered operation. The RBAC only needs to limit T1 users to investigative tasks, isolating them from the all other tasks, while giving T2 users complete control over the system.
However, often times, this operational model is insufficient or over-simplistic. With this model, organizations are forced to unnecessarily expose sensitive data to a large group of users which can include external contractors.
Operational requirements of enterprises and governments
Many enterprise and governments are geographically distributed and consist of relatively independent suborganizations in different physical locations. Hence, they are subject to different data-access and operational requirements. These local sub-orgs typically have their own local security operations teams in charge of incident response and the local security posture. On the other hand, there are global security teams that deliver higher levels of security support, while providing organization-wide incident response and security posture management.
With more restrictive data-handling policies, many organizations try to ensure that the local, sub-org security teams can only see the data and perform actions associated with local assets. They often want to ensure that local teams can’t, under any circumstances, operate on, or see assets that belong to other sub-orgs. While enforcing this restriction, many customers want to continue allowing global security teams to operate on and see all assets, enabling them to combat threats across sub-orgs which affect the entire organization.
In a nutshell, large organizations often require:
- Multiple local operations that support different cities or countries
- Regional operations that support multiple countries, but still do not have global view permissions
- Global operations for org-wide response
To further complicate things, some organizations have dedicated SOC teams covering specific assets, such as the devices used by C-level executives. These organizations want to ensure that no other teams can see the data on these assets.
To meet these requirements, a role-based access control (RBAC) solution must support granular control over user actions and operational scope. It must support segmentation that matches actual customer organizational and operational realities.
Complex SOC models
Let’s look at a fictitious company Contoso to understand the operational needs of a global enterprise.
Contoso is headquartered in the US and has three additional sites: in Canada, the UK, and France.
- The sites in Canada, the UK, and France are self-contained and have their own IT or security personnel that manages their assets.
- They have a US SOC team responsible for global security, providing org-wide incident response and security posture management.
- They also have a dedicated team of security experts that protect executive devices across all Contoso sites.
To meet their operational requirements, Contoso runs their SOC with more tiers.
|
Tier |
Description |
|
Tier 1 (T1) |
· Local security operations teams o Canada T1 o UK T1 o France T1 · Activities and capabilities o Triage and investigate alerts in their geolocation and escalate cases that require remediation actions to Tier 2 o In some cases, local IT or subcontractors acts as the T1 SOC team · Allowed actions and scope o Actions – investigate alerts only o Scope – access to devices in their country, except executive devices |
|
Tier 2 (T2) |
· Regional security teams o Europe T2 o North America T2 · Activities and capabilities o Consists of more advanced security personnel with good organizational network architecture knowledge o Can deal with threats impacting multiple sub-orgs in their specific region (Europe or North America), but escalates complex or broader cases to T3 · Allowed actions and scope o Actions – investigate alerts and take remediation actions o Scope – access to devices in their region, except executive devices |
|
Tier 3 (T3) |
· Global security team o T3 · Activities and capabilities o Consists of security experts that deal with threats impacting multiple sub-orgs or the entire organization · Allowed actions and scope: o Actions – all actions o Scope – all devices, except executive devices |
|
Executives device tier (EDT) |
· Executives device monitoring team o EDT · Main activities o Consists of T3 analysts from a limited circle of trust, with the primary goal of protecting executive devices globally o Might also assist T3 on complex investigations · Allowed actions and scope o Actions – all actions o Scope – all devices |
The table above represents a more complex SOC model that can only be fulfilled by an advanced RBAC with full isolation capabilities. Let’s see how you can conveniently support this model using the RBAC in Windows Defender Advanced Threat Protection (Windows Defender ATP).
Support your SOC model with Windows Defender ATP RBAC
Windows Defender ATP RBAC is designed to support your SOC operational model of choice. It can easily be adjusted according to your needs and it provides full isolation capabilities.
By default, Windows Defender ATP already supports two levels of access: full access and read-only access, applying permissions based on Azure AD directory roles. However, you can quick configure Windows Defender ATP to support complex SOC operational models, such as the described Contoso model.
Assuming your SOC isn’t entirely built from scratch—you already have Azure AD user groups for your SOC analysts that map to your organizational structure (such as Contoso’s SOC T1 UK, SOC T1 Canada, etc.)—you can set up the RBAC in a few simple steps.
1. Turn on Windows Defender ATP custom roles
Go to Settings > Permissions > Roles and select Turn on roles.
Note: Once you enable custom roles, you also enable scoping capability (through machine groups). This allows you to segment your tenant to multiple, fully isolated subtenants. Portal users can now natively use all Windows Defender ATP features, such as entity searches, prevalence checks, file blocking, alert suppression and even advanced hunting—while the RBAC transparently ensures these users see data and perform actions only on machines they are authorized to access.
2. Configure granular permissions
Set permissions for your T1, T2, T3 and EDT teams by creating Windows Defender ATP custom roles and applying them to relevant user groups. See how to create custom roles for details.
The new roles should look something like this:
Note: In the image above, T3 and EDT teams have the same role and thus the same permissions. However, you will assign them with different scopes.
3. Create machine groups to set different operational scopes
Now, all you need to do is create machine groups to match the operational scopes that you need. In Contoso’s case, they need an executive group and groups that match the different sites. See how to create machine groups for details.
The new machine groups will look something like this:
Only specific user groups have been given access to the machine groups, limiting the operational scope of those user groups.
Note: Machine groups are evaluated according to their rank in the stack, so make sure you order them appropriately. In Contoso’s case, isolation of the Executive machines group is of utmost importance, so this machine group should be at the top.
That was easy, wasn’t it?
Congratulations! You just learned how to set up a powerful RBAC that can help your SOC run as a tiered, totally non-flat organization, that can support the complex needs of your organization.
For more information, see the Windows Defender ATP RBAC documentation.