How Security Policies Fail (2)

Policy: Only support or development users may be admins of their own workstation.

Failure: Hard pressed support or development staff discover that applications can be fixed by making users into local admins. So they do.

This policy is not robust -- it's hard to rectify after the fact as users prefer working apps to non-working and you can't guarantee what's going to fail when you do fix it. The policy isn't lazy either -- it's easier for the desktop support person to make the change, move on to the next call and get rid of a troublesome issue than it is to obey the policy.

To make it lazy we have to make the people who break the policy prefer not to break it next time:

• Check membership of Administrators group on each WS -- review new entries
• Extract the username of the desktop staffer who made the change from the workstation security audit log.
• Make sure that the trouble ticket system shows a risk assessment and approval for that change
• or the person who made the unauthorised change has to get it undone.

To make it more robust this has to run every day, so that unapproved changes can be can be undone before they bed in. To make it really robust you need real time alerts for group membership events on your workstations, but that's not easy.

Oh, and you need a way to stop logons as the builtin local admin -- a random password for each WS should do it. But that user should be inacessible anyway.