Security Advisor

5 Steps to Certificate Bliss

Whether you decide to build your own PKI for security or use a third party, planning is paramount.

• By Roberta Bragg
• 10/01/2004

Today we're inundated with sermons evangelizing certificates as the universal answer to all things security. Want to get rid of the risk of password-based logon? Use certificates and/or smart cards. Want to protect communications over the Internet? Use SSL certificates or IPSec-based VPNs. And when using IPSec, you'd better use certificates for authentication, because that's more secure. And the list goes on.

To adopt these solutions you need to either purchase certificates from a public Certification Authority (CA), or build your own Public Key Infrastructure (PKI). Both options are now incredibly easy—so easy, even your boss could do it. But purchasing certificates can be rather expensive, as can hiring a consultant to assist you with an in-house PKI, or purchasing and implementing your own third-party CA products.

Microsoft Makes It Easy
Enter Microsoft certificate services. Microsoft is very good at making the incomprehensible simple by virtue of the wizard. If you're running Windows 2000 Server or Windows Server 2003 it'll take you just a couple of minutes to bring up a CA and start issuing certificates. If you have a Win2K or Windows 2003 domain, make sure that server is a domain member, and you've instantly empowered easy use of certificates throughout the domain. Before you know it you'll have more certificates crawling around in your network than there are ticks on a red-bone coon hound. So what's wrong with that? More certificates equals more security, right?

Wrong. Certificates could eventually become as maligned in the IT community as passwords. When correctly implemented, they can provide rock- solid security; done wrong, they'll be as weak as a three-character password. Given the deceptive ease of implementation, you may not think a certificate project requires major planning. That would be a mistake. Here are five planning steps to follow before implementing a certificate structure.

1. Determine if Certificates Are the Best Solution
In some cases, certificates may be the only solution to your security problem. If, for example, you want to implement 802.1x authentication using Protected Extensible Authentication Protocol (PEAP) and Microsoft's Internet Authentication Service (IAS) server, you'll need, at minimum, a certificate for IAS. Likewise, you can't outfit your Web server for SSL without a server certificate. You'll also need certificates—lots of them—in order to use the native smart card support built into Windows 2003 and Win2K.

But certificates are most definitely not the solution for every security need. Before rushing in, determine what's driving the call for certificates, so you can decide whether they are the best solution. If it's a management initiative, for example, have a talk with the manager who wants changes. I can imagine such a conversation going something like this:

C-Level Decision-Maker John: "I'm tired of hearing about how weak Windows passwords are. We need to implement smart cards."

IT Manager Sven: "That will improve security, but I have a limited IT budget. Investing in smart cards will pretty much kill other IT initiatives for the year."

John: "Well, what are our options? You know as well as I do that Microsoft products need all the help they can get. I don't want to have to notify our customers that their credit-card numbers may have been exposed."

IT Pro Diane: "The issue of customer data security can be better addressed by implementing my proposal from three months ago. Microsoft passwords and password policies can be strengthened beyond the capabilities of the password cracking schemes available today and into the near future. We just need some policy changes, user training and password auditing capabilities. This will cost far less than implementing smart cards across the board."

Sven: "Diane's right, John. We can do a better job of managing password-based authentication. But we need to start with sound security policies and practices, and we need the teeth to enforce them. Will you help us there?"

John: "Well, I'm not convinced, but I'm willing to consider your proposals. I want a report on my desk tomorrow on how to bolster password security. Send me another copy of your prior proposal on customer information security as well."

Whatever the ultimate decision, at least the reasons for the proposal are being discussed. How else can you determine the best course of action if you don't know what the goals are?

2. Buy or Build?
Several items must be considered when deciding whether to purchase or produce certificates. Make the right decision based on:

• Budget
  
• Certificate requirements
  
• Current network infrastructure
  
• Number of certificates required
  
• Current deployments
  
• Future plans

If you need only one certificate, you may be tempted to buy one. But if you've already invested in PKI, shouldn't you just issue one of your own? Not necessarily. A public Web site, for example, should have a commercial CA as its signer, while an intranet site usually works better with one from your in-house CA.

If you need multiple certificates, you may decide it's time to deploy your own PKI. It's certainly easy and cheap enough to do with Microsoft products, but are you ready to devote the time and energy into learning how to do it securely? What if you have an immediate need to secure wireless access? Properly implementing a PKI will take time. In this case you may want to purchase the certificate(s) in the near-term, while at the same time developing and hardening your PKI plan for the future.

3. Planning
Whatever you decide, you'll need to do some serious planning.

Purchased Certificates
Should you go the commercial route, there's a host of procedures you'll need to implement, including assigning responsibility for:

• A comprehensive certificate management plan that includes the reasons certificates are purchased, how they're actually used and who has responsibility for their management.
  
• Certificate purchase and hand-off for implementation.
  
• Certificate distribution and installation, using automated methods where possible and keeping accurate records.
  
• Tracking certificate expiration dates, renewing certificates, or expiring them and recording changes.
  
• Certificate revocation.

In-House Rollout
The development of in-house certificates services using your own PKI should be 80 percent planning and 20 percent implementation. The steps you'll need to take include:

• A detailed analysis of certificate use within your organization. Determine the use that provides the most benefit and implement that first.
  
• An analysis of available PKI skills among your personnel.
  
• Create a committee—representing IT, general management and employees—to develop policies and procedures for design, implementation and maintenance.
  
• Review committee work to make sure it covers areas including protecting root and subordinate CAs, how certificates will be issued, revoked and renewed, and whether a CA hierarchy will be used.
  
• Specify an audit methodology and practice before deploying.
  
• Research best practices for hardening both CA computers, processes and certificate usages—then build them into the architecture of your PKI.

4. Select the CA Vendor
If you decide to buy third-party certificates, return to the analysis and planning stage. Yes, this step is in the correct order. You should thoroughly study your needs and requirements concerning certificates before selecting a vendor. Whether you're purchasing a single certificate, third-party CA or implementing Microsoft's CA, you should be looking for the vendor that suits you—not for the solution that a specific vendor supplies. Then determine the securest path possible for deployment and maintenance.

5. Deploy and Maintain
Once you've planned your work, work your plan. You've got a number of steps to do, all of which must be done in the correct order—and don't forget that security is iterative. Maintenance is the most important phase of the process, after planning.