Blasting away security myths

During my nearly two-decade computer security career, I've always been amazed by how many security myths are propagated as fact by readers, instructors, leaders, and writers.

Just because most people say it's so doesn't make it correct.

Because of this, I have a new rule: You should not teach, lead, or write about something until you've at least tried it once yourself. Don't just repeat the same things as mantra without testing to see if the statement holds water.

For instance, I often hear security by obscurity doesn't work, when it so clearly does! This is the most often perpetuated myth of them all. The myth says that security that relies only on obscurity (when the malicious hackers cannot launch a successful attack only because they do not know all the pertinent facts) isn't real security. The rationale is that if the attacker learns the pertinent information, the "fake" veil of security falls quickly and the victim succumbs to the subsequent attack.

Examples of security by obscurity include renaming the Administrator or root account, moving service ports to nondefault port numbers, installing software to nonstandard locations, and more.

The myth would have you believe that security by obscurity has no value and any scheme using it should be immediately discounted. But the fact of the matter is that security by obscurity works, and works well. It is among the least expensive security defenses you can employ. It should be considered a part of anyone's defense-in-depth plan.

The second biggest misconception is that of the dedicated human attacker. Nothing captures our attention like a malicious human hacker -- the emotional, visceral mental picture of caffeine-high attackers just waiting to break into your business. And in many cases hackers are breaking in; it's just that 99.99 percent of the real attack threat to any business is automated malware (viruses, worms, Trojans, etc.).

Too many computer defenses and books concentrate on the wrong problem -- the hackers instead of the malware. How can anyone give you the correct defense if you don't understand the correct problem?

Should a defender prepare and defend differently based on malicious mobile code versus the dedicated attacker? Yes. Simple security by obscurity works well against automated threats.

For instance, two of my honeypots run Microsoft SQL server. Microsoft SQL servers typically run on ports 1433 UDP and 1434 TCP. The MS-SQL honeypot that runs on those ports gets scanned and attacked dozens to thousands of times a day. The other honeypot runs on a high non-default port (say, 30143 TCP) with a blank sa password, but it never gets attacked. Or, I should say, almost never -- in the 22 months that it has been up, it has been scanned once on the correct port, and even that hacker or bot didn't attack it.

No sa password guesses and no buffer overflow attempts in almost two years: One simple security by obscurity trick defeated almost all of the risk. And even if the attacker guesses the correct port on a production SQL server, they'll face the default security inherent in all the regular installs.

Today, the biggest threat to any environment is client-side attacks, specifically attacks being launched against normal end-users via e-mail and through the browser. Attackers rarely beat up on Internet-facing hardened super servers. Instead, just send a little spam to less-protected workers and let the social engineering aspects do the rest. All it takes is one weak end-user to ruin the whole network.

What does this mean? Network administrators need to concentrate significantly more effort on preventing client-side attacks than building the next battle-hardened server. We almost have the latter issue won, yet our end-users keep opening ever-worsening spam and phish attacks.

Trying to prevent malicious e-mail attacks by blocking a small number of file types isn't going to work, either. Most corporate e-mail file block lists I encounter cover 10 to 20 file types, including files with the following extensions: .exe, .zip, .com, .bat, and .pif. The truth is I've counted more than 150 file types that have been used maliciously -- you can download my list of potentially malicious file types from my blog (http://weblog.infoworld.com/securityadviser/archives/2006/05/100_potentially.html).

A better security defense tool is to block all file types by default and only allow a few legitimate types. If your defense tool only supports deny-by-exception, however, you can use my table to populate your defense tool with a more inclusive list.

The single best thing you can do to prevent malicious e-mail attacks is to force all incoming e-mail to be converted to plain text, removing all HTML code, embedded links, and active content. Pulling out the HTML coding easily reveals the phishing links, removes many automated attacks, and renders most malicious e-mail harmless. If the user wants to view a legitimate e-mail in its original form, many e-mail clients, including the newer versions of Outlook, allow the HTML to be added back in with a click of the mouse.

Testing and revealing computer security myths like these was the basis for my just-released fifth book on computer security, Professional Windows Desktop and Server Hardening. It examines all the conventional wisdom about how to defend a Windows system, finds the strengths and the flaws in each approach, and recommends practical advice that really works.

It also contains dozens of important information tables, like the one that shows more than 180 places where Windows malware can hide (http://weblog.infoworld.com/securityadviser/archives/2006/05/where_windows_m.html), and contains more than a hundred specific security recommendations, ranked by criticality. But you don't have to buy my book to get the security recommendations -- you can download the table for free from my blog (http://weblog.infoworld.com/securityadviser/archives/2006/05/how_to_secure_w.html) and put it to use right away.