Centrify and the Microsoft Enhanced Security Administrative Environment - The basics (FAQ)

This is an article I wrote for the Centrify community around Microsoft Red Forest (ESAE).  The goal of the article is to serve as an introduction to the topic.  For the full series, visit https://community.centrify.com 

FAQ: Microsoft Enhanced Security Administrative Environment and Centrify - The Basics
1. What's the MS Enhanced Security Administrative Environment?
It's a series of recommendations and technologies to prevent credential theft in Windows environments.

2. What is Red Forest?
Although the terms MS ESAE and Red forest are often interchanged, Red Forest refers specifically to ONE of the recommendations:  Set-up an administrative Active Directory forest exclusively for privileged accounts and connect it to the corporate forest by a selective one-way trust.  Note that this is an over-simplification.  For more info, click here.

3. What is Pass the Hash (PtH)?
PtH is a very commonly used attack used in Windows networks to harvest credentials, it's been around since early this decade (but may have been around earlier). The idea is that after a Windows system is compromised with a specific program running with Administrator rights, the NTLM password hash of a user can be captured once any of these things happen:

• A user logs in interactively to the infected system (remotely or using RDP).
• A user launches a program using the "Run As"  command.
• The user types-in a new credential to access a network resource that she is not authorized to use (or under a different realm).
• A Windows service configured with a credential is started.
• And many more.

Note that PtH is one (quite popular) way to harvest credentials to move laterally in an environment. There are many other techniques used to harvest credentials.
For more info about PtH, click here.
For more info about attractive credentials in Windows environments, click here.

4. What's the worse case scenario when PtH (and other related techniques) are used?
Total breach, including the ability to impersonate any user on an Active Directory-based infrastructure.

5. What is the goal of MS ESAE?
Although the ideal goal is to completely protect against techniques for credential theft, the more realistic goal is to take the credential theft techniques off the attacker's toolbox, like PtH. This will force them to use riskier techniques that increase the likelihood of detection.

6. What are the principles around ESAE?
Although any principles outlined in this section are likely to evolve as Microsoft adds newer technologies (and bad actors adapt to them), There have been several versions of the techniques to protect Windows Networks starting with some of the original "Securing Active Directory" whitepapers.

Assume Node Breach
Based on my research, the most basic principle is to operate under an assumed "node breach" - this is aligned with another assumption in a different stack: networking.  In this stack ideally you'll treat every network as if it were a public network. In the context of Windows systems, this is to assume all nodes can potentially be compromised unless you have deployed controls to provide the assurance otherwise.  This aligns as well with some of the concepts around our Zero Trust Model.
The pillars of the Zero Trust Model
Now, here's my attempt to consolidate the principles outlined by the different whitepapers that discuss the Microsoft Enhanced Security Model.  We will expand on each principle (as it relates to Centrify in the next posts in this series).

• Principle # 1 (P1)  Perform the basic steps to secure your Active DirectoryWhy?  Because any serious security shop makes this into their normal policy.  It's all about reducing the attack surface.
  Here are some of the "common-sense" practices (however, the reality is that even the most mature organizations struggle with these).
  • Reduce the number of Administrators and manage security group membership.
  • Establish administrative workstations (or servers).
  • Protect Domain Controllers and maintain them up-to-date.
  • Monitor your environment.

• Principle #2 (P2) Have a plan to migrate applications and services that depend on NTLM.Why? Because eliminates PtH outright.  If there's no NTLM hash to be harvested, the bad actor needs to move on and use other techniques.
  This is probably one of the hardest projects for any major enterprise.  Windows services and business apps "just work" in many instances because of the backwards-compatibility capability enabled by supporting NTLM. 
  The good news is that Centrify for UNIX, Linux and Mac does not need NTLM to work. You can disable it in favor of Kerberos-only, nonetheless, as stated, your mission critial application or service may not agree with you disabling NTLM.
  
• Principle #3 (P3)  Separate user accounts vs admin accounts.Why?  Malware has limited effect on regular user accounts.  Also, remember the preconditions for the common credential theft techniques:  Rogue software needs to be running with administrative rights.
  This one has been controversial over the years, especially because Centrify has always embraced least privilege. 
  
  At Centrify we are commited to making the best Administrative account management capability and this will be evident in a couple of months with our Infrastructure Service CPS; however, rest assured that Centrify supports Separation of Duties and Delegation in all its products.
  
• Principle #4 (P4)  Implement distinct admin passwords per workstation.
  Why?  Same as above:  to prevent lateral movement.  If the same "corporate password"  is used for local Administrators, you just enabled the bad actor to move laterally times all the workstations/servers that are available.
  At Centrify, with our vault we have attacked this problem on servers and desktops, last year we tackled the problem on OS X for laptop users, and we are working to bring this for laptop users on Windows.
  Centrify's LAPM for Mac offers a Self-Service capability
  
• Principle #5 (P5)  Use "Privilege Access Worksations" for administration (using the clean source principle).
  Why:  to limit the possibility of malware (or persistent malware).
  This is an enhanced versio of one of the common-sense Windows practices; but now with how pervasive VDI technologies are, it's possible to almost eliminate the possibility of malware.   For example, a computer with Windows administrative tools (or Centrify's) can be launched as a non-persistent VDI session from a clean source.  This provides the assurance that this is a "clean" system.  Centrify does offer additional capabilities to enhance the use of PAWs:
  • MFA
  • Conditional Access
  • Centrify Zone-based access control (this layers an additional access model to Windows leveraging AD)
  • Secure Privilege Elevation (use token manipulation instead of password replay)
  • Audit Trail to enrich security operations
  • Session Capture and Replay
  • Attestation for Access and Privileges
    We will dedicate a post only to discuss how we can enhance Microsoft's PAW recommendation.

• Principle #6 (P6)  Control the privileges of service accounts.Why:  control privileges, reduce the attack surface.
  This is another hard goal to achieve because it's deeply tied to how applications are written.  In the subsequent articles we'll discuss how we can discover, manage and secure Windows Services, Scheduled Tasks and IIS Application pool identities.
  Service Discovery in Infrastructure ServicesThese principles have been in Centrify products for a while.  We use a reduced number of service accounts and we guide you with exactly what's required for least privilege when those are needed.
  
• Principle #7 (P7)  Don't allow regular users to have administrative rights in endpoints (desktops, laptops, etc.)
  Why:  the attack surface in an organization where all users have admin rights is: all users and workstations.  It's about reducing the attack surface.
  Unfortunately, organizations struggle with this concept because the security industry has not embraced temporary access in a way that makes it easy to request spot administrative rights in Windows workstations. 
  
  We have some capabilities already and are working focused in this area.  In the next few articles we'll discuss in-depth.
  
• Principle #8 (P8) Embrace Temporary Access Controls (JIT, on-demand).
  Why:  Because once a credential is used, if it's no longer privileged, lateral movement and the effects of compromise can be limited.
  Organizations must declare war to permanent privileged accounts; however, this problem is not about technology but around workflow. 
  
  This is why we are investing in areas like faster and simpler workflow, mobile approvals, ServiceNow integration and fast communication to our clients.  The idea is to eliminate some of the "business dynamics" that challenge the implementation of just in time access and privileges.  Just in time access is another pillar of our implementation of the Zero Trust Model.
  
• Principle #9 (P9)  Deploy an administrative forest (Red Forest) with a selective one-way trust and limit upwards administration in the corporate side.
  Why:  To proctect privileged accounts and set new rules.
  Although we are of the opinion that Red Forest adds a lot of complexity, it comes from Microsoft and many organizations will deploy the model or components of it.
  Depending on the data classification of the information on systems secured by Centrify; administrative accounts need to adhere to the principles; and we can provide administrative privileges to accounts coming from the red forest.  This is something our competitors (especially on the UNIX/Linux side, have a tough time achieving).  Ultimately this works in conjunction with all the principles outlined here.
  
• Principle #10 (P10) Use critical thinking - MS ESAE is complex and may not work in all instances
  Why:  Because the principles of security need to be maintained.  This is all about risk mitigation or management and due-diligence. 
  At Centrify we specialize in Access Controls and have always preached the maximization of "what you have" and the use in non-Windows systems on premises and in IaaS.  Follow the principles of controls stacking (spend more on prevention and correction than detection). 
  For example, our Identity Broker capability on Linux allows for AD (LDAP, Google, etc) users to be authenticated to AD without the need of using Domain Controllers nearby.  There is no NTLM hash.

7. I see Centrify has a Password Vault, can it protect me against Windows Credential Theft techniques like PtH?
I think no security vendor with regards to their credibility will pitch a password vault as the sole mechanism against Windows credential theft.  It can't... just use privilege session or replay the password and that's it!  Compromised credential; and most likely, since you had it vaulted, it will be very useful to move laterally or escalate privileges.   
A vault can, however:

• Help you separate user vs. administrative accounts
• Help you rotate passwords automatically
• Be used to in conjunction with a Privilege Access Workstation
• Allow you to establish distinct local server/workstation passwords and help you rotate them
• Some vaults provide the ability to provide and enforce Temporary Access

The answer you want to hear here is:  A PV can help you as part of the toolset to implement controls against credential theft. The benefit here is that Centrify is the only vendor uniquely positioned to provide vault-based, system-based and IDaaS based security.  This helps in vendor consolidation and productivity.

8. I see Centrify provides MFA capabilities, can it protect me against Windows Credential Theft techniques like PtH?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  You have to replay your password!  If your system, group or policy allows for you to issue an NTLM hash, you are done (in the case of PtH). 

MFA can absolutely protect you against credential theft if the credential is being used interactively on a resource being protected by MFA.   The difference here is that most of the time, when a credential is harvested, it tends to be used programmatically.

9. I see Centrify supports Smart Card authentication, we are deploying it as a technique to prevent Windows Credential Theft techniques like PtH.  Am I in the right track?
Same response as above.  MFA can't help you against a compromised Windows system running malware.  In the case of Smart Cards, there is still a password generated for you by the AD domain controllers.  Great control to prevent interactive theft.

10. What are the Active Directory Capabilities that help against Credential Theft and how do they map to Centrify capabilities?
At this point there are dozens of capabilites in place, starting with stronger crypto in Windows Server 2008 Active Directory all the way to Shadow Groups in Windows Server 2016 AD.  We will dedicate a full community post just to go over these in the context of a Centrify deployment.

Resources

• Microsoft's PTH website: https://technet.microsoft.com/en-us/security/dn785092
• Microsoft's Securing Privilege Access: https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material#ESAE_BM
• Best practices for securing Active Directory: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
• Channel9:
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B213#fbid=
  • https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B359

Next Article:
MS ESAE - Principles Showcase: How Centrify aids, enhances or fits in this model.