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.
More Information
Purchased
Certificate Considerations
I hope by now you're ensuring that your wireless LAN is secured and isolated
from your internal network. You should treat wireless connections to your network
as if they're coming from a hostile network (as indeed they may be). One way
to do this is to implement 802.1x authentication. Microsoft's Internet Authentication
Service (IAS) can become your 802.1x authentication server. If you choose PEAP-MS-CHAP
v2 as the EAP authentication protocol, clients don't need certificates—the
IAS server does.
If you've already implemented a Microsoft Public Key Infrastructure (PKI),
providing that certificate is easy. But what if you haven't? Should you invest
in installing a Microsoft Certification Authority (CA)? Installation is easy,
but doing so correctly isn't. It's not something you should blithely do without
careful consideration and consultation with your organization's policy makers
and others impacted by your decision. The path to PKI protection is fraught
with risks. PKI does, however, have huge benefits that make it well worth spending
the time to do it right.
Whether or not your ultimate decision is to develop your own PKI, it's not
going to happen overnight. To protect your wireless LAN in the meantime, a quick
alternative is to purchase a certificate from VeriSign or another third-party
CA. This may become your permanent solution or eventually be replaced by your
in-house PKI solution; the advantage is that it's available now.
Remember a couple of things if you take this route. First, the recommended
process is to use IAS to make the request to the CA vendor and, when your request
has been approved, return to the site using IAS to obtain and automatically
install the certificate. You may want to consider requesting and obtaining the
certificate from an administrative station and then manually installing the
certificate on IAS. This will avoid the security risk of allowing script processing
from IE on the server.
Second, the CA vendor certificate will point to one of its own servers for
certificate revocation information. When WLAN clients attempt to connect to
the protected WLAN access point, the IAS server will present the certificate
and the clients will check with the CA vendor's server to ensure the certificate
hasn't been revoked. This is good, since it prevents possible rogue servers
from impersonating your IAS server. The certificate is used to authenticate
the IAS server to the client; a secure channel is then established so that the
entire contents of the client-to-server authentication is encrypted. This is
important when using MS-CHAP v2, which is susceptible to offline password cracking
attacks. If the authentication conversation is encrypted, any captured packets
can't be attacked without a huge investment in first attempting a crack of the
packet encryption.
IAS also checks the revocation status of the certificate and must therefore
also have Internet access. If you're using a proxy server for Internet access,
you'll need to configure IAS to use the proxy server. You can't do it by using
the options pages of the IAS's IE. When you configure proxy settings in IE,
you do so for the currently logged-on user. Instead, you must configure proxy
settings for the local computer, since IAS runs within the security context
of the server. You can do this using the "at" command to open a command
prompt in the security context of the local system and then setting the configuration.
Here's the process:
- Check to see that the Scheduled Task service is enabled and started.
- Use a command prompt on the IAS server to enter the "time" command.
- The current time is displayed. At the Enter the new time:
prompt, press Enter. (This command is only used to determine the time;
you'll add one minute to that time and use it in the next command.)
- At the command prompt type
at [current time plus 1 minute] /interactive "cmd.exe"
and then press Enter. (An example command line might be "at 13:32/interactive
"cmd.exe"")
- Wait a minute, and then, when the new command prompt opens, open IE using
the command "%programfiles%\Internet Explorer\iexplore.exe"; press
Enter.
- In IE Open Tools\Internet Options; select the Connections tab, then
LAN Settings.
- In the Proxy server, select Use a proxy server for your LAN, then
enter the name or IP address of your proxy server and the Web port number
in Port.(Typical port numbers may be 80 or 8080; consult your proxy
server documentation).
- Click OK to save the settings, then click OK to close Internet
Options.
- Close IE and close the command prompt opened by the "at"command.
- If your policy is to disallow the Scheduled Task service to run scheduled
processes, disable the service.
—Roberta Bragg
More PKI
Resources
Below are links to additional Microsoft resources on this topic along with a
number of MCP Magazine articles that address PKI.
Microsoft PKI Resources:
- A Webcast on planning a PKI infrastructure
for Windows 2003.
- An overview of the PKI Design Process.
MCP Magazine articles:
About the Author
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.