Paranoid Penguin - Mental Laziness and Bad Dogma to Avoid

Peer pressure is no substitute for common sense.
Bad Dogma 2: All Digital Certificates Should Expire after One Year

On a related note, consider the digital certificate, which consists of a couple key pairs (one for signing/verifying, another for encrypting/decrypting), identity information (such as your name and organization) and various Certificate Authority signatures. Conventional wisdom says that every digital certificate must have an expiration date, the shorter the better, in case the certificate's owner unexpectedly leaves your organization or the private key is somehow compromised. The consequences of either event could include bogus signatures, illicit logins or worse.

This worst-case scenario assumes two things. First, if the certificate's owner leaves your organization, it may take a while for the certificate to be revoked (and for news of that revocation to propagate to the systems that use certificates). Second, it assumes that the certificate's passphrase can be guessed or brute-force cracked easily.

But, both of these are solvable problems. If you're deploying a Public Key Infrastructure in the first place, you need to configure all systems that use certificates either to download automatically and use Certificate Revocation Lists (CRLs) from your Certificate Authority, or better still, configure them to use the Online Certificate Status Protocol (OCSP). Many events can lead to a certificate's need to be revoked besides reaching some arbitrary expiration date, and managing your certificates diligently and using CRLs or OCSP are the only reliable means of reacting to those events.

Regarding certificate passphrases, setting passphrase complexity requirements is generally no harder for digital certificates than for system passwords. The situation in which it can be most challenging to protect certificate passphrases is when machines use certificates (for example, Web server SSL/TLS certificates), which usually requires either a passphrase-less certificate or a certificate whose passphrase is stored in clear text in some file to which the certificate-using process has read-access privileges.

The bad news is, in that scenario, renewing the server's certificate every year doesn't solve this problem. If it's possible for people to copy a server's certificate once, it's probably possible for people to do so every year, every six months or as often as they need or like. The solution to this problem, rather, is to protect the certificate at the filesystem/OS level, especially its passphrase file, if applicable.

Does that mean certificates shouldn't have expiration dates? Of course not! I'm simply saying that, as with password aging, if this is your only protection against user attrition or certificate compromise, you're in big trouble anyhow, so why not employ a variety of protections that allow you to relax a little on expiration dates, as you ought to be doing those other things anyhow?

Bad Dogma 3: E-Mail Encryption Is Too Complicated for Ordinary People to Use

For as long as I've worked on information security in large corporations, I've been told that e-mail encryption is only for geeks, and that business users lack the technical skills necessary to cope with it. I've always found this sort of amusing, given that it's usually us geeks who accuse business people of having too-short attention spans.

But, is using PGP or S/MIME really that much more complicated than using, say, LinkedIn? I know which I would rather spend time on! (I am, however, an admitted geek.)

How much of the inconvenience in e-mail encryption really falls on end users? Nowadays, I would argue, very little, especially if your organization can support a PGP key server or can incorporate S/MIME certificates into an MS-Exchange Global Address List.

In practice, key management tends to be the biggest headache with e-mail encryption—specifically, getting a valid/current digital certificate or PGP key for each person with which you need to communicate. But, this need not be a big deal if you set things up carefully enough on the back end and give your end users local settings that allow their mail client software to search for, download and update their local copies of other people's keys transparently.

One can go too far, of course, in coddling end users. I've seen organizations issue keys without passphrases, which makes those keys trivially easy to copy and abuse. I've seen other organizations issue passphrase-protected keys, but then send people their new key's initial passphrase via unencrypted e-mail! Obviously, doing things like that can defeat the whole purpose of e-mail encryption.

My point, really, is that modern e-mail encryption tools, which typically support GUI plugins for popular e-mail readers, such as MS Outlook and Squirrelmail, are exponentially simpler to use than the command-line-driven tools of old. Given a modicum of written documentation—a two-page instruction sheet is frequently enough—or even a brief computer-based-training module, nontechnical users can be expected to use e-mail encryption.

This is too valuable a security tool for so much of the world to have given up on!

There, I'm starting to feel better already! But, I'm not done yet. On to some mental laziness that never fails to annoy and frustrate.

______________________

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