Security by obscurity: It works!

Have you ever repeated a fact over and over for years only to learn that what you believed was true actually wasn’t? I’m still slightly begrudging my mom for cheating my younger self out of sunny pool time with warnings that entering any body of water within 30 minutes of eating lunch would result in severe cramps and certain death. Years ago, a Reader’s Digest article revealed that warning wasn’t true.

Seeing as I’ve owned a pool most of my adult life, and none of my kids, neighbors, or loved ones have ever suffered a cramp in my pool after eating, the news shouldn’t have been such a surprise. I ignored the evidence right in front of me the entire time.

Security by obscurity is a lot like that. Almost every computer security "expert" alive repeats the mantra that security by obscurity is no security at all, despite overwhelming evidence to the contrary. I propose that it should be a valid part of any computer defense plan, and in fact, can be one of your best defenses.

Before writing angry hate mail to your new security columnist, let me explain further. First, I didn’t say security by obscurity was the only defense technique someone should use. I didn’t even say it was real security, but I am saying that it should be an important part of most computer defense strategies.

Security by obscurity can be accomplished several ways, but basically it means getting out of the default habit and taking certain steps:

   * Rename highly privileged admin accounts to less notable names.
   * Name servers with names that are not obvious to their support roles.
   * Run server services on non-default ports whenever possible.
   * Install high-risk software (such as Internet-facing Web servers) to nondefault directories.
   * Rename configuration files to nondefault names, if possible.

The idea is that if something doesn’t have to be installed to the worldwide known default name or location, don’t do it. Why give malicious hackers and automated malware a leg up on your environment?

For example, Windows administrators should rename their Administrator account to something less than obvious, such as PeterC. The Exchange Administrator account shouldn’t be called ExchangeAdmin and your tape backup service account should not be called Tapebackup.

Security experts will respond that in the Windows world, the Administrator account can always be easily identified by its well known SID (security identifier) number of 500, and that’s true. The reality, however, is that most attacks are automated and none of them have ever done SID enumeration. Hackers can do SID enumeration, but most of them don’t.

Think of how security by obscurity could have helped avoid the SQL Slammer worm. If you got compromised by Slammer, it meant you did three things wrong. First, your SQL box was unpatched, even though the patch had been out for more than half a year. Second, you connected your SQL to the dangerous world of the Internet without a protective VPN. Third, your SQL servers were running on the default port of 1434.

It's not easy to fix all of those problems. Keeping patches up-to-date can be hard in a large enterprise, especially when trying to thoroughly test a mission-critical application. And VPNs can be one of the most difficult things to establish between multiple points.