IT Security audits

It’s in the interest of external security auditors to find as many flaws as possible.  They have to justify themselves somehow, after all.

So this leads to the farcical solution where I received a security audit on our client desktop systems.

“It’s got all these issues”
said the Service Delivery Manager.

“No it doesn’t.  They have blindly followed the NT4 C2 hardening guide, and if we fix these “”problems””, the customer will not have a working system and will complain”.

Case in point, cached logons.

“Windows NT 4.0 has the capability to cache logon information in short-term memory. If the domain controller cannot be found during logon and the user has logged on to the system in the past, it can use those credentials to log on. If the Administrator disables a user’s domain account, the user could still use the cache to log on by disconnecting the net cable. To prevent this, Administrators should disable the cache. This results in a somewhat longer logon time, but prevents hackers from tapping logon information from short-term memory.”
http://www.microsoft.com/technet/security/chklist/wrkstchk.mspx

The advantage in allowing people to use cached logons, is that the user can still use their computer when the domain controller is broken.  People like bank tellers and retail staff who connect to non-Windows networks (Mainframes generally).

But for 3 years running, the external security auditors would say “it’s a security issue”.
And the customer’s IT staff would say “disable it”.

“You’ll have problems”, we’d say.

“We don’t care, it’s a security issue.”

So we’d stop cached logons, and then the network failed, the customer would complain.
“Well we did warn you.”

In years 2 & 3, we got clever.
“Mr. Customer, you had problems when you last did this.  If you change your mind after we disable it, we’re going to bill you for the fix.”

Update October 2009: Raymond Chen wrote about Cached Credentials in the July Technet magazine.

Bookmark and Share