One of our clients is a Tier 1 PCI company, and their auditors have made a suggestion with regards to us as System Administrators and our access rights.
We administer their entirely Windows based infrastructure of roughly 700 Desktops/80 servers/10 Domain Controllers.
They are suggesting that we move to a system where we have three separate accounts:
DOMAIN.CO.UK\UserWS
DOMAIN.CO.UK\UserSRV
DOMAIN.CO.UK\UserDC
- Where WS is the account that logs on to only WorkStations, is a Local Administrator on WorkStations
- Where SRV is the account that logs on to only Non DC Servers, is Local Administrator on Servers
- Where DC is the account that logs on to only Domain Controllers, effectively a domain administrator account
Policies are then in place to prevent logon to the wrong type of system from the wrong account (that includes removing interactive logon for domain administrator accounts on non DC machines)
This is to prevent the situation where a compromised workstation can expose a Domain Administrators logon token and re-use that against the Domain Controller.
This appears to not only be a very intrusive policy for our day to day operations but also a considerable amount of work, to address what is a relatively unlikely attack/exploit (this is my understanding anyway, perhaps I misunderstand the feasibility of this exploit).
I am interested to hear other administrators views, especially those here who have been involved in a PCI registered company and you experiences with similar recommendations. What are your policies regarding administrator logons.
For the record, we currently have a Domain User account that we use normally, with a Domain Administrator account that we elevate too when we need the additional rights. In all honesty we are all a bit lazy and often just use the Domain Admin account for day to day operations, although this is technically against our company policies (I'm sure you understand!).
Best Answer
I'm at a Tier 1 PCI vendor. We have something like this in place, with a few differences.
The auditors are actually attempting to describe a very real problem, but doing an incredibly poor job explaining the implications and needs analysis.
It is now more effective to compromise a system by using a hash of a password or an existing token. Put plainly, your attacker no longer needs your username and password. There are now easier ways to attack a system. Under no circumstances should you assume or conclude that this type of attack is unlikely. Hash attacks are now the defacto attack vector.
Hash attacks are actually worse with smart card accounts, which is ironic, because most people expect that implementing smart cards would increase the security of a system.
If an account is compromised due to a pass-the-hash attack, the usual response is to change the account's password. This changes the hash that is used to authenticate. Also, a normal password expiration/change may surface an incursion, due to the attacker's hash would begin to fail. However, with smart cards, the password is 'system-managed' (the user never enters the password to authenticate), so the hash never changes. That means with smart card accounts, an incursion may go unnoticed for much longer than with an account that uses a password.
Here are mitigations I would consider:
For smartcard-enabled accounts, which many large companies use for highly-privileged accounts, change the password of the account on a frequent interval. This changes the hash. You can also change the hash by un-smartcard enabling the account, then re-smartcard enabling it. Microsoft does this every 24 hours, but you need to evaluate the potential impact this may cause in your environment, and establish a sane schedule so that you don't create additional problems.
For workstations, I would not use domain accounts for admin purposes at all, if possible. We have a local account that can be used to elevate for UAC type operations. This satisfies 99.9% of most elevation requirements. Workstations tend to be hot attack vectors, due to the lack of regimented change control, and the existence of Java JRE and Flash.
This approach works for us due to we have a formal mechanism for managing and enforcing the password for the local accounts and that the password is unique on each system, and that a secure method exists for someone to request the password. There are also commercial applications that can perform this function.
If you cannot provide a local account solution for workstations, then yes, a separate domain account should be used for administrative access to workstations, and that account should not be used for administrative access to servers. Another option may be to use remote, non-interactive support management tools that use LocalSystem to perform activities, and an authentication mechanism that is separate from Windows.
For the highest privileged accounts (Enterprise Admin, Domain Admin, etc), use only a jump server. This server would be subject to the most restrictive security, change control, and auditing. For all other type of administrative type functions, consider having a separate administrative account. The jump server should be restarted daily restarts to clear the process tokens from the LSA process.
Do not perform administrative tasks from your workstation. Use a hardened server or a jump server.
Consider using easily resetting VMs as your jump boxes, which can be reset to clear out memory after each session.
Further reading:
https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx
Microsoft Security Intelligence Report, Volume 13, January - June 2012
http://www.microsoft.com/security/sir/archive/default.aspx
Read the section: "Defending against Pass-the-Hash attacks".
Defeat dreaded pass-the-hash attacks
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753