Paranoid Penguin - Mental Laziness and Bad Dogma to Avoid

Peer pressure is no substitute for common sense.

Gentle readers, I try not to rant at you, really I do. You turn to my column for practical, reliable tips on getting complex security-related tools to work, and judging from the e-mail messages you send me, most of the time I deliver that.

But, I'm human, and now and then, I get really tired of dealing with mental laziness and dogma. It's not because I'm some sort of purist—quite the contrary. Rather, it's because it's impractical. Each of us security geeks has a limited amount of energy and political capital, and we can't afford to squander it on positions we can't back up with compelling, plausible risk and threat drivers.

Similarly, although I've got tremendous sympathy for nongeeks who strictly use computers as tools, and who find it (rightly) unreasonable to have to know as much as a system administrator just to be able to print their spreadsheets, Internet use has its price. If you're going to comingle your data with that of practically the entire rest of the world, you need to think about risks now and then, and you need to take the time to learn some simple precautions.

So this month, I need to vent just a little bit about some nagging bits of information security dogma to which security practitioners sometimes cling, and some examples of mental laziness in which end users (especially “power users”) sometimes indulge. Your opinions may differ (widely) from mine, and if you take strong exception to any of this, I encourage you to post comments to the Web version of this article or e-mail me directly.

In Defense of Dogma

Before I begin the rant proper, let me acknowledge that to a point, dogma can be useful, in the same way that a parent may now and then find it useful to tell a cantankerous child “the answer is no, because I said so”.

Life is short, information security is complicated, and we don't always have the luxury of explaining every rule to every user's satisfaction. Sometimes, it seems to me, it's perfectly appropriate to say, “You can't do that because it violates corporate security policy.” The real question is, “Is that a defensible policy?”

So, perhaps my point is not that there is no place in the world for information security dogma, but rather it's that dogma existing only for its own sake is useless. If we can't back up a policy, practice or other security requirement with compelling, risk-based justification, we will fail.

This month's column, therefore, is about some wrong ideas that have somehow ended up being treated as immutable truth among some of my peers, but whose rationales are questionable and tend to cause more harm than good. And, because I don't want anyone to think I'm unduly biased against my colleagues, I'll give equal time to the aforementioned examples of end-user mental laziness as well.

Bad Dogma 1: Changing All Your Passwords Monthly Is Really Important

Consider hapless Hapgood, a typical corporate computer user. At work, Hapgood has to keep track of six different user accounts, each with slightly different password-complexity rules: system A requires a minimum of eight characters containing uppercase and lowercase, punctuation and numbers; system B allows only seven-character passwords, doesn't allow punctuation and so forth.

Due to corporate security policy, within any given 60-day period, Hapgood must change all six passwords—a couple of them twice. If Hapgood starts choosing passwords that are easy for him to remember but not very hard to guess (for example, his own name with a capital H and zeroes instead of Os), can you really blame him?

I wouldn't. But, which do you suppose is more dangerous: choosing a bad password, or leaving a good password alone for, say, 90 days instead of 30?

Naturally, that depends on what you're worried about. If you're worried about brute-force password attacks in which an attacker cycles through all possible passwords for a given user account, then the more randomized the password, the less likely it will turn up in the password “dictionaries” many attackers employ. In that scenario, short password lifetimes will lower the chance that any given password will be cracked before it expires. But, the password shouldn't be very easily cracked if it's sufficiently complex to begin with. So as it happens, enforcing good password complexity rules is a better protection against brute-force password attacks.

What if you're worried about Hapgood being fired, but connecting back into the network via a VPN connection and logging back in to his old accounts, in order to exact revenge? Won't a 60-day password lifetime minimize the amount of havoc Hapgood can wreak?

This question is best answered with two other questions. First, why should Hapgood still have access for even one day after being fired? Second, if Hapgood's accounts haven't all been de-activated within 60 days, what's to stop him from simply changing his passwords once they expire?

Obviously, in this scenario, password aging is the wrong control on which to fixate. The terminated-employee conundrum can be addressed only by good processes—specifically, the prompt and universal disabling of every terminated employee's account.

There's a third risk people hope will be mitigated by password lifetimes—that a password may be eavesdropped over the network, read off the sticky note attached to someone's monitor or keyboard or otherwise intercepted. This risk is probably more credible than brute-force attacks and user attrition combined.

But even here, if attackers can abuse someone else's access privileges for 29 days without fear of detection, there's probably something seriously wrong with how you're doing things. Furthermore, it may be possible for such attackers to install a keylogger, rootkit or other malware that allows them to intercept the new password, once the intercepted one expires and its rightful owner changes it.

Passwords should, of course, have finite lifetimes. User name/password authentication is a relatively weak form of authentication to begin with, and requiring people to refresh their passwords from time to time certainly makes the attacker's job a little harder. But, compared to password complexity rules and good walkout procedures, password aging achieves less and affects end-user experience more negatively.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState