There's no way to compile a comprehensive list of all the ways you might let a well-protected system's security slip through your fingers, of course. The kind of mistakes you can make are innumerable. The following list offers just a few all too common examples of how security is accidentally compromised from within, by someone somewhere, every day in this world.
- Misplaced trust: Don't enter your online banking password on someone else's computer. Don't trust a brand. Don't trust security systems that don't trust you. Don't trust the government farther than you can throw it. Don't even trust yourselves too much -- because trusting in the infallibility of something you create can prove fatal to security.
- Security through ignorance: Most of us are probably aware that obscurity is not security. That doesn't mean we don't try to use obscurity for security, sometimes without even knowing we're doing it. A great example of this is the effects of Google and Yahoo! indexing Flash content. This indexing is showing that a lot of sensitive information is naively encoded in Flash objects, and has been available to people with the know-how to harvest it all along. Many of the people who created these security sieves never realized that they were essentially relying on obscurity for their security, though. The problem in many cases is that they didn't really understand the technology they were using, and as a result they never thought things through enough to realize that the only thing "protecting" such information was a veil of obscurity. Don't make that same mistake; understand the security implications of the technologies you use.
- Unsecured e-mail: Do you send business secrets through e-mail? Does your Web site offer a way to recover passwords via e-mail? If those e-mails aren't encrypted, you're basically handing the keys to the kingdom to anyone who cares to get them. A particularly egregious example of this kind of blunder was the case of unencrypted embassy emails sent through the Tor network.
- Unsecured encryption: Just like the anonymity provided by Tor, encryption itself is not a magical cure-all. In order for OpenPGP encryption to be usable and useful for protecting communications, you have to be able to decrypt any encrypted messages you receive. In order for it to be secure, you have to keep your private key private, as well as the passphrase you use to access it. If the computer on which you maintain your private key, and where you decrypt and read messages you receive, isn't properly secured, that means your encryption isn't properly secured either. Some systems are more prone to problems that compromise the security of your private key than others -- things like unauthorized access that might allow someone to copy your private key and launch an offline brute force attack on your passphrase, and keyloggers that can capture your passphrase as you type it in. It's even worse when you use encryption on someone else's computer, where you may have little idea what security measures have been taken by those who have administrative access, or even whether they themselves can be fully trusted. Ultimately, you may be better off communicating via plain text than encrypting messages, if the security of your encryption keys is too weak. At least if you communicate in plain text you know whether it's effectively protected against eavesdropping.
- Unwinnable battles: Choose your fights wisely. Don't focus a lot of energy trying to protect what can't be protected effectively. If securing the unsecurable is necessary to your business model, you may want to rethink that business model -- not only because of the inherent flaw in a business model like that, but also because all that effort put into securing the unsecurable is diverted from securing everything else. Don't take the easy way out, blaming everything on anyone except yourself when your business model is built to fail, giving yourself excuses to squander time and energy on a quixotic quest for the unattainable. It's not my fault your business model sucks.
Don't make these mistakes. Think about them, though, and if any of them are problems that hadn't occurred to you, think about what else you might be missing. Learn to think like a security professional, always looking for the way unintended consequences might arise from innocent actions.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.