Problem solve Get help with specific problems with your technologies, process and projects.

Worst practices: Encryption conniptions

Through the years,'s expert contributors have no doubt spent much of their time pointing out a variety of security best practices. But what about the worst practices? In honor of April Fools' Day, network security expert Mike Chapple continues a month-long series that highlights the industry's most common mistakes. One of the major bad habits: a lack of encryption.

Here at, we writers spend a great deal of time and energy helping information security professionals explore new security technologies and understand industry best practices. But this month, in the spirit of April Fools' Day, I'd like to instead focus on some common enterprise habits that can really mess things up and cause security problems. After all, if we can't learn from our own mistakes, we're doomed to repeat them.

Here's a list of five worst practices that I'd like to share with you:

1. Using Wired Equivalent Privacy (WEP) encryption. Frequent readers of this site know that I beat the WEP drum often. In fact, the protocol's weaknesses were the subject of a best practices article that I wrote a few months ago: Lessons learned from TJX: Best practices for enterprise wireless encryption. If you're still running WEP encryption in your organization, it's time to face the brutal facts: the simplistic encryption techniques used by WEP may be broken in seconds using freely available tools. As the TJX data breach proved, WEP's inherent flaws provide little real security. If you're looking for a secure alternative to WEP, try WPA2.

2. Practicing "security theatre". Some of you recognize this as a borrowed phrase from well-known security pundit Bruce Schneier's famous essay, In Praise of Security Theater. Essentially, "security theatre" is the practice of implementing complex, expensive security measures solely for the sake of making people notice that you're spending a lot of time and energy on security, despite the fact that your controls are easily defeated and largely ineffective. For example, consider the recent FFIEC federal requirement that banks use two-factor authentication for sensitive transactions. In an effort to skirt this rule, banks added a series of "security questions" to their standard password-based login processes. As any security professionals know, the use of two "something-you-know" factors is not the true intent of two-factor authentication. So in this case, security theatre provides an illusion of security while avoiding the implementation of new IAM technologies.

3. Encrypting email attachments only to include the encryption key in the message. It happens to me about once a month. Someone sends me a sensitive document by email and, meaning well, uses the encryption feature of Microsoft Office to preserve the confidentiality of the document while in transit. The person then proceeds to praise himself in the body of the message saying something like, "Mike, I know you're always telling me about the security problems with email, so I encrypted this confidential file. The password is football." I wince and gently explain that this doesn't really solve the problem. The simple solution is to use an out-of-band transmission method for the password. For example, send the email and then pick up the phone and call the recipient to provide the password. The likelihood of the same individual intercepting both your email and telephone call is remote.

Avoid security disasters. Know the basics.

Ed Skoudis explains how to develop a patch management policy for your third-party apps.

Learn encryption strategies for preventing laptop data leaks.

See why last year's WEP crack revealed a need for WPA2 encryption.
4. Failing to patch. We all know that applying security updates is a critical component of secure system and application administration, but why don't we do it? Consider Oracle databases as an example. A recent survey showed that two-thirds of Oracle DBAs have never applied a Critical Patch Update. This is despite the fact that Oracle essentially begs DBAs to apply the patches, sometimes warning of such dire consequences as "a severe flaw…[that] could lead to system crashes, remote execution of code and privilege escalation". Remember, hackers read the same security patch announcements that we do. Leaving networks, databases and third-party applications unpatched is asking for trouble.

5. Failing to encrypt laptops. Many of us have been through it at least once in our security careers: someone loses a laptop containing sensitive information about your employees or customers, and you're forced to send out embarrassing notifications and purchase identity theft protection for thousands of people. Fortunately, there's an easy way to avoid this altogether: use disk encryption products to render mobile data unusable if a device is stolen. It's worth noting that in February 2008 alone, the Chronology of Data Breaches listed five significant breaches that resulted from the theft of unencrypted laptops. These took place at high-profile organizations that should know better. The list includes the likes of Kraft Foods, Blue-Cross Blue-Shield and the National Institutes of Health.

It's also interesting to note that more than half of these worst practices come from the same technology domain: encryption. There's a lesson in that fact: as a community, we either don't understand encryption well enough, or we tend to plow ahead with full knowledge that we're perpetuating some of the items on this list of no-nos.

There's an obvious question springing from all of these examples: why do we, as professionals, keep repeating the same mistakes? There's not one "worst practice" in the list above that's recent news. Even flaws in WEP encryption have been around for over five years. The lesson for all of us is to always keep the basics of information security in mind. It's great to go out and implement new, complex security systems, but don't do so to the detriment of implementing time-honored best practices.

About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.

This was last published in April 2008

Dig Deeper on Data security strategies and governance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.