eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
More than a dozen people had crowded into the meeting room—employees from a business unit, from IT operations and from information security. The technical project leader was presenting the architecture he had designed for the business units e-business initiative.
The company was planning to share product information with its business partners through an Internet portal. The architecture included one of the best directory servers on the market that came equipped with a CA (certificate authority) module. “We will use the CA to issue digital certificates,” the presenter said. “It is part of the package, so we thought wed use it.”
Not all PKI (public-key infrastructure) pilot projects get off to such a bad start—with the emphasis on the technology rather than the process and with the decision to use digital certificates made just because they are there—but this scene exemplifies many of the mistakes that an organization can make when putting a PKI system in place.
The biggest challenge in implementing PKI is not technological; it is organizational and operational. The technology of public-key cryptography is, after all, more than 20 years old. The real challenges are to identify and measure the value added by a PKI and to design and manage the certificate life cycle.
Most mistakes are consequences of a decision to confine PKI pilot projects to the IT department. It is, instead, vital to choose a business case where PKI can make a difference as a business enabler or can fulfill legal and regulatory requirements. A clear business case is needed to define goals and agree on measurable success criteria for the PKI pilot.
The early involvement of the business units—as well as of all other stakeholders in the pilot—ensures its support during critical periods. I participated in one pilot in the financial industry where the executive management team supported PKI deployment as a cornerstone of the companys security infrastructure.
This support proved fundamental throughout the pilot, in particular when the vendor of an Internet banking application tried to push aside the PKI pilot. The vendor had never integrated its application with a PKI and was trying to minimize its own risk. Eventually, the pilot met all the predefined success criteria without affecting the planned Internet banking rollout. Today, that PKI deployment project is in its second year, and its scope is expanding.
The design of a certificate life cycle is an interdisciplinary endeavor involving the whole enterprise. It is essential to involve all stakeholders in the PKI pilot at an early stage, before choosing a PKI product.
The legal department defines the authorized uses of a digital certificate and the issuers liability. It also has a say in whether distinct classes of certificates will be needed and, if so, what they should be.
The identification of certificate applicants and the verification of their eligibility should be done in conjunction with processes already in place in a companys human resources department or customer service department or with the processes in place at an external business partner.
A companys Certificate Policy and its CA Certification Practice Statement should be developed in parallel with the PKI system, not after it is in place. And, obviously, the business unit that is pilot-testing the PKI is a key player.
Finally, the choice of a PKI system should be made keeping in mind the future requirements of the enterprise. If those conducting a PKI pilot fail to analyze a companys medium- and long-term requirements, the company may find that the limitations of the chosen PKI system keep it from being of use as the companys PKI deployment expands.