First published on TechNet on Mar 14, 2016
Hi All. This Jerry Devore a Midwest PFE back after a long hiatus from blogging. If you thumb through the owner's manual of your car you will find a maintenance schedule section. There you can see how often the manufacture suggests you should change your engine oil, flush your radiator fluid and replace various filters. Any well trained auto mechanic will whole heartily agree with those recommended intervals. However, if you can get one to be completely honest you will likely find his own engine is currently a quart low on oil and his check engine light has been on for the last year. IT Pros can be the same way when it comes to security. We know all of the best practices and are quick to tell others how they need to change their habits in the name of security. In reality though it is easy to let our guards down and occasionally take shortcuts which can put our systems at risk. That is why your elevated accounts should be restricted to logging on to Privileged Administrative Workstations (PAW). With the correct hardening setting applied to a PAW, credential protection is not dependent on personal discipline. Before we get into how a PAW should be configured it helps to put into context where a PAW fits in with the other devices on your network. One of the key principles promoted in the Microsoft Pass the Hash whitepapers is that accounts and devices should be grouped into a Tier Model so that the trust level of the device is consistent with privileges used to operate that device. In other words, you should not log on to a device that is less trustworthy that than the account you are using. While you could easily get carried away with defining multiple levels of trust, Microsoft uses a three tier approach which is often sufficient and is easy to visualize. - Tier 0 is the top of hierarchy and is where control of the environment resides. The most obvious Tier 0 resources are the domain controllers because once they are acquired, an adversary has everything needed to access all other resources. Tier 0 also includes anything that can be used to gain control of those domain controllers such as the SCCM servers or other agent based management tools. - Tier 1 encompasses the applications and data. This is truly where the adversaries want to get to because it contains the information which can be sold or otherwise used for nefarious purposes. The credentials use to manage Tier 1 should be contained to that tier so if they fall into the wrong hands elevation to Tier 0 is not possible. - Tier 2 is the bottom of the hierarchy and contains your least trusted devices. This is the level where your everyday workstations live. The accounts used to administer this level should not have admin access to the servers. The sad reality is that every organization can pretty much expect that an adversary will gain control of a few of these devices. That is why the PtH whitepapers include several mitigations to prevent lateral movement at this level. So since a PAW is a workstation does that mean it is a Tier 2 device? Not at all. Because highly privileged accounts will be used on them they must be regarded as a Tier 0 devices for domain administrator accounts and as a Tier 1 device when used by application server administrators. If you understand the nature of a Pass the Hash (PtH) attack, then you know that an interactive logon can leave password hashes resident in LSASS memory. Thanks to publically available tools a very low skilled hacker can harvest and utilize those hashes regardless of the password length or complexity. But what about the highly disciplined administrator who launches all management tools with "Run As" and never logs on interactively with an elevated account? I hate to break it to you but Run As also places a hash of your NTLM credential in LSASS memory. Beyond credentials stored in LSASS memory, we also need to be vigilant against malware based keyboard loggers. Therefore, we should not get caught up on where the credential is stored but rather focus on the trustworthiness the entire device. We sometimes refer to this as having a “clean keyboard”. Getting Started So now that we have defined the purpose of a PAW, how do you get one? Simple. Microsoft Consulting Services (MCS) has an offering which will design, document and build you a PAW environment. The end result will be a turnkey solution which encompasses the latest Microsoft best practices. If letting MCS lighten your load is not in the budget for this year then you will want to check out the PAW documentation Microsoft recently published. It does an excellent job of explaining the concepts and configuration steps. However, it is not a quick read so here are my Cliff Notes to get you started. 1. Use verified media to ensure a clean build - I know what you are thinking… but I am not wearing a tinfoil hat as I type this. The creation and deployment of your PAW could require hundreds of man-hours and we are approaching it from an "Assumed Breach" position. All of that effort would be of no value if you used media or downloads which have been compromised. To ensure your bits are pure, acquire them from different sources then compare their hashed values and make sure they match. 2. Apply a hardening security baseline from Microsoft Security Compliance Manager (SCM) . SCM templates contain a plethora of information based on Microsoft best practices. The "Security Compliance" template will let you implement all of those recommendations with a few clicks. It can also be used to quickly compare your general workstation and server GPOs to the documented best practices 3. Enable Secure Boot . This will ensure that "bootkit" software cannot modify your system and allow malicious code to operate at a level too low to be detect by common AV products. Keep in mind that Secure Boot requires UEFI which needs to be enabled on the machine before installing the OS. 4. Impose Software Restrictions using AppLocker. Once you deploy the PAWs you want their configuration to remain unchanged. AppLocker can help enforce that by blocking malicious or unapproved applications 5. Enable Full Disk Encryption . This will ensure that offline manipulation of the device is not feasible. It will also protect any local data if the computer ended up in the wrong hands 6. Impose restrictions on USB ports . I have witnessed this being achieved by physically damaging the USB ports. A more refined approach is to use policies to disable USB for media use. That will allow you to continue to utilize other types of USB devices such as keyboards, mice and headsets. 7. Implement Network Isolation via host firewall . Start by blocking all inbound connections and make exceptions only if absolutely necessary 8. Install and configure the Enhanced Mitigation Experience Toolkit (EMET) . EMET stops zero-day exploits by blocking many of the functionalities utilized by malicious code. While implementing EMET can cause application capability issues, a PAW should have very little software installed on it. You should be able to enable all of the default protections offered by EMET without any negative impacts 9. Windows 10. A good description of the Windows 10 security features can be found at https://technet.microsoft.com/en-us/library/mt601297(v=vs.85).aspx . Many organizations have not adopted Windows 10 yet so there may be a tendency to stick to the officially standard client OS. The PAW will not be supported in the same manner as your regular desktops and the security enhancement in Windows 10 are too important to pass up. This is not a time to hang back in order to be compliant with company standards. 10. No Internet access from a browser. While PAWs are hardened and patched devices there is no need to play with fire by using them to browse web pages. Highly managed environments might be able to impose this limitation at the proxy servers. Those who don't have that amount of control can simply configure a bogus proxy server address in the browser. 11. Minimal Software. Each installed product introduces the opportunity for vulnerabilities and blurs the lines between the purpose of your regular workstation and your PAW. Keep focused on the fact that a PAW exists as a way to securely logon with elevated credentials and access equally secure devices. It is not intended to be used for documentation, reading email or updating change control records. The use limited to administrative tools (i.e. RSAT) and support scripts however is considered acceptable. 12. Minimal Administrative Accounts . For obvious reasons a PAW should not be operated with an account which is a member of local administrators. Additionally, the PAW owner should not have a secondary account with administrative access. Having such a back door makes it too tempting for the owner to "fix" flaws they perceive in the PAW configuration. 13. Hardened OU. The PAW computer accounts should be segregated into their own OU. The security applied to that OU needs to be strictly limited and audited to ensure access to the PAWs cannot be gained by anyone not responsible for PAW support. In addition to the PAW documentation, Microsoft has also published scripts to implement and harden these OUs. Support model Developing and deploying a PAW will look nothing like your standard workstations. In order to maintain them as Tier 0 devices the management tools and staff used use support the normal workstations cannot be leveraged for the PAW. Without a well-planned strategy it would be easy for the PAWs to end up in a state of limbo when it comes to support. While designing your solution make sure have carefully considered: · Patching strategy · Anti-virus updates and monitoring · Auditing and event forwarding · Hardware Repairs If you have a limited number of PAWs it is difficult to justify implementing a comprehensive management solution. Relying on manual support processes might need to be used. Just make sure you are not neglecting the maintenance required to preserve their integrity. Form Factor In an ideal world the PAW devices would only reside in a secure room and never be exposed to the general network let alone leave the building. However, in the real world we are rather fond of work from home arrangements and being able to provide on-call support without spending the weekend in the office. As a result, form factor should be considered when designing your solution. Here some options to consider: · Secondary laptop - The most isolated approach is to provide your administrators with a second device. Given this results in them lugging around two laptops it would be best to use compact hardware for the PAW. A Surface device would be great fit given they are very portable and provide the necessary security features (UEFI, TPM, Bitlocker, etc). · PAW with Hyper-V - In this approach Hyper-V would be installed on the PAW and it would host a VM which is used for standard workstation purposes (Email, Web browsing, etc). Hosting a PAW VM on a standard workstation is not considered a viable alternative because a keyboard logger resident on the standard workstation could capture credentials when logging on to the PAW VM. · PAW with VDI - This is very similar to the Hyper-V model except the standard workstation VM is hosted in your data center. This might not be as convenient when working remotely given a connection to the data center will be required in order to utilize standard workstation functions. However, it might be much easier to support than running a VM on top of a laptop. · PAW with Jump Server – This approach closely parallels the VDI solution and is often used where network segmentation exists. Jump servers allows you to consolidate the management of support tools so the PAW configuration can remain simplified. Keep in mind that these hardened servers are Tier 0 resources and would not be supported in the same manner as other terminal servers. Enforcing Use Once PAWs have been deployed to all administrators you are done and ready to close out the project… right? Nope. We have not solved the original problem of shortcuts being taken. Without enforcement you are still depending on personal discipline to protect privileged credentials. So what are some ways to add teeth to the design? I am glad you asked. Here are a few things you can implement to make sure PAWs are used for their intended purpose: 1. Impose "Deny log on" polices via User Rights Assignment in a GPO. This should be applied anywhere the account should not be used to log on. For Domain Admins, you should apply this restriction to all devices other than Tier 0 computers such as Domain Controller and the PAWs. Keep in mind that if these setting are managed in a local policy and a domain GPO, the GPO will overwrite rather than merge. 2. Use IPSEC to impose device level restrictions that are otherwise not feasible using host or network firewalls. For example, place the PAWs in a domain group then configure IPSEC polices so that only Domain Admins logging from a PAW can make an RDP connection to the domain controllers. Such policies can be configured via GPO so they are easy to centrally manage and enforce. Just make sure to test your policies in a lab because misconfigured IPSEC settings will take devices off the network in a blink of an eye. Once that happens backing out the GPO will not undue your RGE (resume generating event). 3. Restrict where privileged accounts can interactively logon by defining devices in the “Log On To” field of the account properties. As computer names are added they are written to the User-Workstation attribute of the user account This feature has been with us since the beginning of Active Directory and it has some considerable limitations: · The field only accepts NetBIOS names so there is a 15 character limit · By default, the field only accepts 64 names. As explained in KB938458 it is possible but not recommended to expand that limit. · While the restriction applies to Kerberos and NTLM, both protocols rely on the workstation to provide its NetBIOS name. A malicious user could manipulate the device to spoof the response and defeat the restriction · This restriction must be managed per user account. Even if you leverage scripting it could quickly get difficult to manage. · Implement Authentication Policy Silos . Authentication Policy Silos were introduced with 2012 R2. They restrict where accounts can be used by disabling NTLM and blocking the ability to acquire a Kerberos Service Ticket unless the policy allows it. The prerequisites are a Domain Functional Level of 2012 R2 and Window 8 / 2012 or higher operating systems. Authentication Policy Silos are the way of the future when it comes to restricting where accounts can be used. Unfortunately, it will be some time before many organizations will be able to raised their DFL to 2012 R2. Now that you have the basics I hope you check out the published PAW documentation and start designing your solution. This would also be a great time to review both Pass the Hash whitepapers to make sure your plan is comprehensive in addressing current day threats to privileged credentials. Jerry Devore, PFE
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.