Domain Administrators account policy (After PCI audit)

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.

Domain Administrators account policy (After PCI audit)

Related

Recent Posts