A Cry for Help

Public Key Infrastructure is at the core of most e-commerce and, therefore, must be done properly. You can do it yourself—or turn to some outside pros. Which option is for you?


For years I’ve struggled with the dual problem of being very “work” busy and, at the same time wanting to do my own cooking, cleaning, gardening, landscaping, repairs and remodeling. As my boys can attest, the result is a home that’s a cross between Lady Athena’s Curio Shoppe and a recently burglarized apartment on any of the TV cop shows. It’s even gotten so bad that when I returned recently from a long trip, I couldn’t find my spare laptop. So last week I gave in and hired an “organizer”—you know, someone who comes in and gets your house back in order so it looks great, but you can’t find anything at all.

Home—and Network—Improvement
We were about halfway through (anyone who suggests that all the work is done by the organizer is lying) and, yes, we found the laptop. We also found another window in the house (it was hidden behind cheap paneling at the back of a closet—you’d have to see my house to know why I never realized the number of windows on the outside didn’t match those on the inside). This experience changed my mind about outside help, and I’m looking forward to re-assessing my priorities and hiring regular assistance—not to do the things I love and can do well, but to provide the expertise I lack. Just because I can buy or rent the right tool for the job doesn’t mean I’m the right person to use it.

Networks, like homes, should be managed with the ultimate result in mind. Sometimes we forget that. For example, in the rush to implement state-of-the-art security, it’s easy to seize on the free tools provided with Windows 2000 and forget that improperly applied security is worse than no security at all. To do it correctly, you have to have wisdom, knowledge and the ability to choose the right tool for the job. Now I’m all for in-house, homegrown solutions to problems and issues. Usually those most familiar with a company’s systems, policies, goals and business are the most qualified to design the solution. Sometimes, however, it’s not the best way to go. Sometimes you have to take a step back and get a little help.

Implementing a Public Key Infrastructure (PKI) may be one of those times you should at least ask the question. Until recently, designing and deploying PKI required a hoard of outside expertise and expensive products. A long ramp-up time was guaranteed, and there were many failures. Now, because Win2K provides certificate services at no additional charge, PKI is within any company’s grasp. Win2K certificate services is easy to install and configure, and documentation abounds; but, even without it, any idiot can point and click their way to success. Or can they?

Like most of you, I pride myself on being able to learn new technology quickly and see its relevance and possibilities. I enjoy letting others know of my discoveries and opinions. I’ve been a champion of smart cards; warned you about using EFS without establishing certificate service-based PKI; and painted glowing pictures of the great new features of PKI in Windows .NET. I’ve watched like a proud mom when others have taken up the banner.

I was wrong.

Oh, not wrong in advising you on the benefits of PKI, nor in my implementation details. Rather, I was wrong not to caution you more strongly about the inherent pitfalls of point-and-click PKI. You see, sometimes when something is difficult and expensive, we tend to respect it just a wee bit more. We get help. We have to justify its expense. We plan and test. We learn all we can about it. But when that same something becomes a commodity item; when it becomes as easy to do as it is to pronounce; when it appears to have no extra cost; when its mechanics are explained in terms we immediately understand—well, we don’t think it through. I fear that’s how you may perceive PKI.

Here, then, is a missing part of your PKI education, along with some reasons not to roll your own PKI—or, at least, to question it.

Sources of Outside Help
So, if I’ve convinced you that you need some outside help, where can you go? There are several good possibilities. I’m sure you’re all aware of the public CAs that will sell you certificates. I’ve listed a few below, and many consulting firms can assist you in discovering the best route to take:

What if you feel you don’t have the ability to manage in-house PKI, yet your requirements go beyond a Web server certificate or a few e-mail certs? Managed PKI is a growing industry; determine your requirements and purchase PKI like you would other IT services. A simple Google search will point you to dozens of firms that specialize in this field. Here are a few:

E-Commerce: Don’t Trust Yourself
Secure Sockets Layer technology has long been the accepted method for protecting Web transactions. An SSL certificate is issued to the company that owns the Web site, which effectively binds the domain name to the server. The issuing Certificate Authority (CA) signs the certificate. When you or I make a purchase, the appropriate programmed Web server switches to HTTPS and can be authenticated by the browser, which has a copy of the CA’s server certificate. The ensuing transaction is encrypted, thus protecting the private information (such as credit card numbers).

There’s a temptation on the part of small businesses to issue themselves a certificate for this purpose. Because the certificate is signed by their CA, no copy of the CA certificate is in the browser’s store. Any prospective purchaser can be prompted to accept the connection anyway, and the transaction will be encrypted. However, this is not an acceptable solution.

A public e-commerce site should always purchase and use a public CA certificate. While a certificate issued by any CA—in-house or commercial—can do the technical duties of this transaction, consumer trust isn’t so easily gained.

The issues consumers have with purchasing on the Web are: Is the company reputable? Does this server belong to the company? Is my data safe? The answer to the first question can’t be derived from the existence of a certificate purchased from a public CA. Public CAs aren’t policing forces on the Internet, nor can they be expected to make judgment calls on a company’s trustworthiness. They may do some checking before issuing a certificate, but can you imagine the brouhaha if they revoked it because they believed the company was untrustworthy? I’m afraid consumers will have to find other resources to answer that question. (Interestingly enough, I’ve seen users of homegrown certificates claim this as the only thing a public CA-obtained certificate offers that they don’t. They also claim that they’re respected entities and, thus, a public certificate isn’t necessary. Hmmm.)

The second question is the main reason to look for a public CA’s certificate. A public CA can (and does) verify that the purchaser of a server certificate is authorized to do so for the company. When an e-commerce server presents a certificate from a known public CA, we accept the server as belonging to the company. The server has authenticated itself. We trust the public CA’s validation process and that the company has secured the certificate. However, when a company chooses to use a homegrown CA to produce a server certificate, we don’t have this luxury. Anyone could easily produce a certificate and claim its Web site represented any company it chooses. (That it could be charged with committing fraud is little deterrent to the criminal mind.) Savvy consumers won’t shop sites that don’t use public CA certificates, and savvy site builders will always offer them.

The third question, keeping data safe, isn’t a problem that certificates can completely solve. Yes, using certificates allows encryption of private consumer information as it travels across the Internet. What happens to the data after that is up to the site designers; hosting unencrypted databases of private information, using flawed applications, or even printing out and carelessly handling credit card numbers is outside of the scope of SSL certificates.

Business-to-Business PKI
Third-party trust may be established by purchasing certificates from a public CA. Mutual trust may be established via distribution of root certificate copies to involved parties or the building of cross-trust relationships.

Companies traded goods and services electronically long before the Internet. These exchanges were made based on the setup of trusted access via the distribution of passwords and client software, and many of them are still used. Today, business-to-business e-commerce sites incorporate technologies that are easier to deploy and rely on PKI. While public CA-provided certificates may serve to authenticate servers and clients, many of these exchanges desire the greater control offered by developing their own PKI. In addition to producing and installing an SSL certificate, trust is established in one of two ways.

In many cases, a single company is controlling the exchange. For example, an automobile manufacturer accepting bids from parts suppliers and placing orders might provide suppliers with client certificates to be used in authenticating the suppliers, as well as a copy of the company’s root certificate to be used in server authentication.

In the other method, two or more companies in more of a partnership wish to issue their own certificates. In this case, they may both choose to purchase root certificates for their own internal CA from a public CA. Because both ultimately can be traced back to the same source of trust, certificates issued by each company can be trusted by the other—at least for the purposes assigned them. Alternatively, should their CA trust model allow, they might develop a cross-trust relationship whereby each company’s root CA is trusted by the other. In this case, each company may host its own internal CA with its own self-signed root certificate. The choice here might depend on the convenience and ease of starting with a public CA vs. establishing trust through other means. Leaving the third party (the public CA) out of the picture can allow for greater control, more flexibility and better security. (They’re operating under the theory that the fewer people involved, the more control and security they can have—assuming appropriate security on their part.)

Protection Down to the Root
Using PKI is a good way to provide better protection for your network. If users use smart cards instead of passwords, the problems and vulnerabilities associated with passwords are gone. If VPNs require machine certificates instead of shared, viewable passwords, security is tighter. In many places, in many ways, security is improved.

The danger here is that this increased security depends on the security of the root CA. Should this become compromised, the entire security structure crumbles. Current Microsoft best practices include limiting the root CA to the signing of subordinate CA certificates and keeping the root CA offline. This makes physical security of the root CA paramount. Where will you store it? Who can obtain access? What are the procedures for obtaining a new subordinate CA certificate for renewing the root CA certificate or for obtaining the Certificate Revocation List (CRL), for backup and recovery?

If the root CA is only used to sign subordinate certificates, its private key can be removed and securely stored. When new certificates or renewals are necessary, the key can be returned to the root CA. In this arrangement, subordinate CAs issue keys to users, computers and other devices. In this arrangement, the private key can be securely stored.

While Win2K makes configuration of its CAs simple, requiring less knowledge to implement PKI, it can’t remove the necessity of training and maintaining knowledgeable staff. If in-house staff doesn’t understand PKI, how will it troubleshoot problems? If it doesn’t realize the critical nature of private keys, CAs, recovery agents, enrollment agents and certificates, how will it protect them?

Policies, Not Process, Should Rule
Here’s the real issue: Without strong security policies, PKI is like seatbelts not secured to the car body—using either offers a false sense of security. You need polices that determine how many CAs you’ll have and whether they’ll be standalone or Active Directory-integrated. Who can approve the creation of the new CA or the addition of a new PKI-based product? Who can administer and back up the CA? How is it backed up? How and when are certificates enrolled, approved, expired, revoked or renewed? If enrollment agents and/or recovery agents are used, who are they? What are the processes and procedures used? All these issues and more can affect the security of your PKI, as well as your network.

Get them right, and PKI assists you in strong security. Get them wrong, and you have less than you started with. I’m not saying that getting outside help will ensure proper thought and development of these policies, but properly chosen outside help can direct your efforts. PKI isn’t some technological challenge to be wrestled into operation; just making it work isn’t sufficient here. Indeed, there’s a learning curve that goes way beyond the technical.

Get Help; Do It Right
So, outside of public e-commerce sites, when would I advise asking for help? I don’t think there’s a checklist you can count on to give you that answer, but here are some general rules.

Get help if:

  • You don’t have in-house expertise.
  • You can’t see why PKI requires study and careful implementation via management-approved policies.
  • You’re tempted to manage your PKI by a single PKI CA.
  • You believe that PKI will solve all your security issues.

What Matters— And What Doesn’t
Now that the organizer has left, I’m faced with the responsibilities of running this household, office and expanding test network. I’ve got to make those vital decisions about the type of help I need and whom I should get to provide it. Interestingly enough, I found that, when needed, I really do like managing and organizing and hiring expertise. In the long run it gives me more time to spend on learning, implementing and understanding technology. The only problem, as I see it, is in determining when I need to hire the experts and whom I should hire. I hope I’ve given you some reasons to pause in your race to implement PKI, as well as the ability to think through a few more of the issues surrounding it. After all, it doesn’t really matter if I can find a laptop or two (there was no critical or sensitive data on them) or whether my cooking is any good (it is); it does matter that you make sound decisions about your use and implementation of PKI.

Featured

Most   Popular