When good recommendations go bad

Let me ask a question: Does your job include implementing official security guidelines that tell you step-by-step which security features to enable? And let me ask a telling follow-up question: If you followed all those guidelines, would they not irretrievably break the asset that it must be applied to?

I can already tell you I’ll get dozens of letters from readers saying yes to both. If you’ve ever been involved in applying the security settings from official recommendation guides, you have, like me, come across settings that don’t work on the computer you’re applying it against -- or worse, they'd “break” the computer.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

I was recently reminded of this problem by my friend, Mark Burnett. He is a longtime respected security expert on many topics. Mark was venting his frustration over the Defense Information Systems Agency (DISA) recommendations for Microsoft computer hosts. Mark recently ran the DISA gold disk scanner against some of his very secure Windows systems and discovered that many of findings were absurd. Here are his first examples:

1 accounts [sic] have the User Right: Act as part of the operating system. No accounts should have this right.

The accounts that have this right are: SYSTEM

Unauthorized accounts have the User Right: Back up files and directories.
Accounts [are]: Backup Operators

Unauthorized accounts have the User Right: Manage auditing and security log.
Accounts [are]: Administrators

Mark says, "The list goes on and on with recommendations that are really pointless."

Flawed logic

Most industry-accepted computer security guidelines contain flaws. Not all -- but most of them. Sometimes the flaws are just ignorant and don’t cause any harm, such as the government’s frequent recommendation of turning on Directory Service auditing on Windows end-user workstations. The setting works on only Windows domain controllers. That fact doesn’t stop it from being recommended.

Other government-mandated document standards, if implemented, would irrevocably break the servers they are supposed be installed on. For example, they recommend disabling NetBIOS/SMB in environments that clearly rely on it. They recommend changing permissions that are clearly not going to be supported by the vendor. They tell you to delete key vendor settings and objects that, although they could convey some additional risk, have never been used in a published exploit.