Security Advisor
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?
- By Roberta Bragg
- 06/01/2002
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.