Netwrix and Stealthbits merge to better secure sensitive data. LEARN MORE
Stealthbits

Cutting down the Red Forest

Blog >Cutting down the Red Forest

Microsoft recently updated their guidance for organisations. The guidance includes some significant changes to how organizations should approach privileged access, so Stealthbits (now part of Netwrix) is here to provide advice and guidance on what this means for you.

Tiered access model and the red forest

To protect our most privileged credentials, for the last several years Microsoft has described using the tiered access model (TAM), coupled with the Enhanced Security Admin Environment (ESAE) – commonly referred to as the ‘red forest’.  These controls were themselves predicated on the Bell LaPadula model, which goes way back to the 70’s, which is just a smidge before the writer of this post was born. The TAM remains, although it becomes refactored (more on this later), but the ESAE has been removed from the guidance.

There were really two main issues with the red forest in particular:

  1. It was very expensive. You had to build it. Integrate all the accounts and systems involved. Onboard people. Arrange access. Then you had to run the thing. Keep it patched, backed up and monitored – all on separate infrastructure. Manage access and accounts as systems and people came and went. It got really spendy.
  2. It was scoped to Active Directory, which would have been fine back in the day when that was all we had to contend with. But now we operate in the cloud. We have multiple cloud management platforms and identity providers that sit completely outside the scope of AD.

So, Microsoft really needed an alternative; The ESAE was too expensive for most organisations to consider, and it no longer protected enough. Solorigate also demonstrated that Azure AD needs to be considered as its own security boundary instead of ‘as one’ with Active Directory. We need to contain the blast zones, if AD goes down, we do not want to necessarily lose Azure AD with it.

Attempting to translate TAM into Azure AD

One method you could take was to map functions of the tiered access model to Azure AD.

There are several highly privileged roles in Azure AD that can be used to affect data and systems integrity across the entire organisation. These are roles which we could ‘call’ tier zero and place stronger controls around – for example cloud only accounts with PIM enabled, FIDO2 authentication tokens, Azure Managed Workstations and so on.

That would be the ‘cloud tier zero’ equivalent, and then the conversation would get muddled up with applying conditional access policies to different levels of sensitivity and, it was just a bit clunky. The separation you get in AD doesn’t really translate into Azure AD – it was not a seamless transition.

Enter the Enterprise Access Model

https://aka.ms/AccessModel

The big leap with the Enterprise Access Model is how it accepts that control is not entirely rooted in, nor exclusively controlled from, Active Directory.

You have a control plane in your identity systems: Active Directory and Azure Active Directory, networks, and other locations where we control access. Management of those control planes, through their various management interfaces is very tightly constrained to highly trusted devices and credentials. You then have management layers which are what we use to manage our data and applications – what we used to call Tier One. Through our management layer we partition access as much as possible across whatever vector is appropriate.

  • Local, hosted, or cloud-based systems
  • IaaS, PaaS, SaaS
  • Different apps and platforms
  • Organizational hierarchy

Then you have users and other applications consuming those services – could be internal users, partners, or customers etc.

Perhaps intentionally, but end user devices not represented in the visual representation Microsoft uses to describe the Enterprise Access Model. Of course, that’s not to say they’re not important, but we use our control plane to determine what kinds of devices we’re happy connecting to what. We are simply no longer assuming trust of devices in Active Directory or any other platform. Association is no longer a reason to implicitly trust.

With that said, End User Devices still represent a degree of threat with Active Directory. What we can target now is lifting these devices out of AD entirely and manage them through modern platforms. Getting apps and resources to Azure AD (https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/migration-resources) means we can now do everything we need through a pure Azure AD joined and Intune/Microsoft Endpoint Manager (MEM) managed device. There is an excellent podcast on the topic from the Blue Security podcast (hosted by Adam Brewer and Andy Jaw) where they had guest Shannon Fritz on talking about device identity, management, and what that means in terms of IT and the user experience.

People want devices to ‘just work’ as our mobile devices do. We get our laptop, we want to turn it on, and get productive. We want to be remote, so we should be able to get working from anywhere. And why not, right?

So, dependant on what the device is, who is signing into it, where it’s connecting from, the state it’s in – we can use these signals to make a policy-based decisions on whether or not we allow access or place some control around that access – MFA, monitoring whatever.

And that is the zero trust element.

With this shift to the Enterprise Access Model, we now predicate access on three key layers:

  • Control plane
  • Management plane
  • User access

These roughly equate to what we used to think of in terms of tiers, accept how those are categorised and how we control access to those is what has changed.

Instead of Active Directory, and the features and controls within Active Directory being what we use to affect the tiered access model, which was always its limitation, we are applying principles that span control planes and management systems, through modern controls.

With the Enterprise Admin Model comes some core principles:

Principle of Least Privilege

The principle of least privilege is here to stay.

Whilst advanced cloud-based controls using AI and ML to detect and respond to attacks are a piece of the puzzle, it is important to underline this does not mean we can lose sight of protecting against attacks. It is no use having the most expensive IP-based webcam doorbell if we habitually leave the door open. When we manage something, we need to take responsibility for ensuring we’re not leaving access open on those control plane and management interfaces because that’s how we let the internal threats, criminal enterprise and nation-state hacking groups win this battle.

Whether we call this ‘secure by design’, or the ‘shift left’, secops and so on, the basic premise is the same. We need to ensure the services we deploy meet common criteria. We make sure the guardrails are in place to ensure that any single app is not going to be the weak chink in our armour and bring everything down.

Assume Breach

Assume breach and explicit validation, to me, is about not accepting domain membership as assumed trust. We want to look at the conditions under which access is being requested and make an informed decision. For example, you’re requesting access to our payment backend. Your credential has permissions, your device is one we own and manage, but you have skipped updates for the past month and you have disabled your screen lock. So maybe we just block access, or maybe we allow access but not to the sensitive stuff, maybe we record the session. The controls can flex, but the point is, just having a relation to the organisation simply is not enough. We no longer exist in mostly isolated environments as we did in decades past. The workforce is now mobile, and our controls must reflect that.

Consistent enforcement

Consistent policy enforcement internally and externally, means that we apply these policies regardless of where people are sitting or resources hosted. Fundamentally this requires gating access to resources through Azure AD as much as possible. This means getting apps to Azure AD one way or another, natively or through Azure AD App Proxy. And then limit AD to backend infrastructure. This reinforces that message about getting devices out of AD into AZURE AD and Intune/MEM. We want to make AD something we target for legacy architectures, with the front-end presented out of Azure AD. So AD becomes a support structure for legacy infrastructure, and users have minimal interaction with it. You can see the trajectory coming together here with things like modern access controls, passwordless, modern management, all contributing towards a more seamless user experience, with the job of IT shifting towards policy and code-based management of cloud platforms, and AD becoming a smaller concern over time. This is all ‘journey’ business, but the path is clear.

All accounts and access methods matter

Account for all access methods. People generally place a more emphasis on how we manage person-based user access to critical or sensitive resources. Because that is the most obvious thing to most people. That is their daily interaction with the systems we manage. Of course, users are not the only concern. We also have service accounts and application accounts in particular. Leaving the security configuration of these objects is sure fire way of baking in risk. Trade secret, administrators and developers are just as lazy as every other human on the planet. Everyone is looking to find the shortest route to getting what they need done. This is not about being the ‘world of no’, but guardrails are needed to make sure workloads and activities are safe. Make sure those controls are applied consistently, because attackers certainly could not care any less. Attackers are trying to find the shortest route to owning us. If we have put stringent controls around user accounts but let our guard down in terms of systems, they will be the first to abuse an open door.

Mitigate Escalation

This is where the principle of least privilege and those guardrails really come in. We make sure that we have tight controls around the accounts that we give privileges to. And what devices those accounts can access our control interfaces from. Make sure to use network segregation – for example local network rules or features like Management Groups, Network Security Groups and Azure Policy. Do not re-use service accounts in multiple services. Make sure service principals and enterprise apps in Azure AD are controlled in terms of who can manage them and the scopes they have access to are acceptable. Something which should be very much at the forefront of our minds, is the level of privilege that we give to applications. Application vendors will very frequently request a level of privilege that is not strictly in line with the principle of least privilege. You should not be afraid to provide a robust challenge to requests for things like Domain Admin membership and determine something more fine-grained that reduces the risk of using that application should it be compromised.

Audit, monitor and respond

Where we see those guardrails failing, or external attacks succeeding visibility is critical. Simply relying on protective controls alone is not enough. This is where the NIST Cybersecurity Framework can really help. We can lock the front door but if someone cuts a wallet-shaped hole and removes our wallet, we really want to know about that. So, visibility, and the ability to respond, is vital.

Summarising EAM

What the Enterprise Access Model represents is an acceptance that the world does not live entirely within Active Directory. We use modern controls and updated principles to focus on what really matters – giving people the access they need, restricting or blocking access where it makes sense given the context, placing great care in how we provide privileged access, particularly when it comes to the control plane.

Red Forest – not NOT recommended 

It is worth noting that while formal guidance to deploy the red forest has been retired, on the flip side the red forest isn’t necessarily not recommended. If customers have particularly stringent requirements and the budget to match, the red forest still provides an effective control within the boundaries of Active Directory; It simply no longer makes sense to assert it globally. If it makes sense for you, red forest is still an option.

Underscoring fundamentals

What often slides under the radar when we’re talking about cloud this, zero trust that, blurring boundaries and so on, is the fundamentals. What the EAM underscores is that we still need to care about privileged access. We still need to care about misconfiguration. When was the last time you reset the KRBTGT account?Are you storing sensitive credentials in Group Policy Objects? Can you detect, and even block golden ticket attacks? All these things which have been important since the day organizations started to use Active directory, and which continue to enable the attacks that bring us down.

Advocating modernisation, with sound fundamentals

It is possible to be an advocate of reducing reliance upon Active Directory in favour of approaches and controls that better suit the world we live in. But even then, Active Directory will remain the control boundary for any data or applications still secured by it. The process of migrating services may be glacial, possibly with even the most important left till last. So, for many organisations, Active Directory will continue to represent critical infrastructure for a very long time. With the length of that tail, managing risk and controlling threats is only becoming more important.

Features and capabilities found in tools like SteatlthAUDIT to identify misconfiguration and threats within our environment, StealthDEFEND to respond to attacks and even StealthINTERCEPT to actively block attacks are clearly a part of the picture. The ability to detect and respond to threats is crucial in a world where attacks are on the rise at such a pace.

These capabilities are relevant for any organisation with an AD footprint, but particularly so where organisations are managing the authentication into cloud resources through on-premises identity providers like ADFS. In that scenario, we are essentially binding control over both AD and Azure AD within AD, which makes control over AD all the more critical.

Wrapping up

We discussed what the new Enterprise Admin Model is, how that looks compared to the old model, and how it means embracing cloud methodologies.

The implications of this new model, with modern controls and approaches in how we manage access, are critical. Especially with the world having gone mobile during the COVID19 era, and the pervasive threats from ransomware. Underlining all of that with a reinforced message about the criticality of protecting sensitive data and systems, managing threats, and living by the principal of least privilege

Thank you for reading, and if you want to talk to us about how we can help you in this journey, find us at stealthbits.com and netwrix.com.

Featured Asset

Leave a Reply

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

Subscribe

DON’T MISS A POST. SUBSCRIBE TO THE BLOG!

 

Loading

© 2021 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.

FREE TRIAL