Have you ever had one of those moments, while discussing security techniques with other clueful individuals, where one of you confesses to disagreeing with a common piece of advice? But the truth is, there are times where standard security advice can be safely bypassed when extra risk mitigation is applied, if special needs require you to do something typically “unsafe.” While it may be completely logical that you must account for context when giving appropriate advice, sometimes we may forget that we must also do this when we’re discussing security.
That being said, perhaps we should be asking ourselves more specific questions when we give others security decrees. For example:
1) How often do you change passwords? Passwords are a fact of life, and they provide us no end of controversy. You should use a passphrase. Or maybe you shouldn’t. You should use strong, unique passwords. Or maybe you shouldn’t. You should change them as often as you change your toothbrush. Or maybe you shouldn’t. A few things are important to consider when choosing a password or setting up a password change policy, or when deciding whether or not to freeze an account upon fraudulent attempts. Is the password just meant for logging purposes, or for access control? How upset would you be if someone got the information in that account? How likely is it that your users will be in a situation that would increase their likelihood of having their password snarfed, such as on public or unsecured Wi-Fi? If you’re unlikely to be eavesdropped upon, perhaps a strong password is more important than one that is frequently changed. If the information in the account has no value to you or others, maybe you can use a password that is less strong. If you only want to know whose account was used to access something, and you don’t need to limit access in any way, maybe you can forgo password resets or freezes.
2) Should you always use Two-Factor Authentication (2FA)? Generally speaking, when you have the option of adding extra security features, you should. But not all implementations are created equal. If losing your phone/email/token renders you totally unable to access the account, that’s a pretty compelling reason to avoid using 2FA for that service. If you’re protecting a group account, and the 2nd factor is tied to a single device like one person’s telephone, this could be also be too problematic. If the account recovery procedures totally negate any security measures, adding additional authentication may be a waste of time. Or if the site requires you to use a mobile phone for SMS, but only supports certain carriers, you may not be able to sign your account up anyway. In short, check a service out before committing.
3) Should you always use encryption? Intentionally obfuscating your data carries with it a certain amount of risk. With established and well-tested algorithms and apps, this is a minimal risk, and nothing that can’t be mitigated by performing regular backups. It’s sort of a Catch-22: To protect your data from theft or misuse, you should encrypt it. But if it’s absolutely essential that you be able to access that data, you may need to keep a copy somewhere, unencrypted (but hopefully hidden). Aside from that, I have a lingering concern when I hear how popular encryption is becoming – will poorly constructed apps appear, whose implementations give people a false sense of security? But on the other hand, that would be no less secure than the current implementations of email and IM.
4) Is it always best to have the latest OS or updates? I’ll admit it: I had a Windows XP box down to the very end of its support date. I knew it was unsafe, and I treated it as such. I started transitioning away from Windows shortly after XP was released, and it would not have been prudent to update a computer I was using with less frequency. A doctor friend of mine is using Windows 95 on one machine because he has proprietary software that cannot be run on anything more recent. But in a less extreme example, sometimes I wait a while to update the OS on my daily-use box, barring some glaring vulnerability that needs patched immediately. Let someone else shake out the bugs!
A lot of the advice security people give is in an absence of context; in these cases, we simply have to “round up” to the advice that works in the majority of circumstances. As long as we don’t ignore circumstances under which the relevant advice would be different, I don’t see that this needs to change. I recently heard someone request that security advocates seek out opportunities to attend and address events outside the traditional security conference itinerary. Having started to do this myself, I see this as a great potential opportunity to explore these exceptional circumstances where context is different and needs specialized recommendations.
Are there any common tips that you disagree with, or which you avoid giving in certain situations?
This article is published as part of the IDG Contributor Network. Want to Join?