 |
 |
 |
 |
| |
|||||
|
|
 |
For years, enterprises have been working towards an integrated security solution to solve the problems of authentication, single sign-on, and confidentiality across multiple resources. Public Key Infrastructures (PKI) hold the promise of being the underlying enabler and security foundation for protecting enterprise resources, such as desktop applications, information servers, and infrastructure elements. Demand for PKI is increasing as organizations recognize the benefits of maintaining a single security infrastructure for enterprise resources. As a result, MITRE has been actively involved with PKI engineering and deployment both to meet and anticipate corporate needs and to satisfy the specific requirements of our sponsors. This paper provides information and recommendations based on lessons learned from our ongoing PKI work. A PKI is a set of infrastructure components and services dedicated to managing keys and public key certificates in order to provide security services for enterprise resources. However, a PKI should not be viewed merely as technology, but as a security infrastructure that includes technology, policies, procedures, and people. A PKI typically includes one or more Certification Authorities (CA), Registration Authorities (RA), and directories. The CA is responsible for issuing certificates, managing them during their life cycle (including renewing and revoking them), publishing the certificates to a central repository, and publishing information about certificate validity. The RA registers users and is responsible for verifying the true identities of users who are requesting certificates before authorizing the CA to issue them. Directories provide the repositories for certificates, user information, and certificate validity for access by users and applications. The most mature and widely used PKI-enabled applications are secure electronic mail (using Secure/Multipurpose Internet Mail Extensions), secure Web server access (using Secure Sockets Layer or Transport Layer Security), Single Sign-On, and Virtual Private Networks (using Internet Protocol Security). PKIs are also being used to provide digital signatures for objects (e.g., forms and code) and to secure electronic commerce and business-to-business transactions. Organizations are deploying PKIs to support business drivers, such as cost savings (maintain a single security infrastructure for enterprise resources), interoperability (employ common mechanisms to promote secure interoperability across applications and with other enterprises), and enhanced security (provide security services for enterprise resources and uniform identity credentials for users). Organizations are also using PKI solutions to provide enhanced access control and community-of-interest separation for particular types of sensitive information. A fundamental requirement for PKIs is the development of supporting policies and procedures. A Certificate Policy (CP) should be developed that defines roles and responsibilities, together with a Certification Practice Statement (CPS) that defines how the PKI will be implemented and managed to support the CP. One of the major purposes of the CPS is to describe how the PKI will be managed securely, especially since the PKI will provide cryptographic keys for users and applications. Certificate profiles that define the content of particular certificates also need to be developed. These are living documents that reflect changes in policy, in the evolution of PKI, and in the capabilities supported by emerging products. When planning a PKI architecture, organizations may choose to outsource the operation and management of their PKI; they may also choose to implement their own PKI. In the former case, a commercial provider would be responsible for operating the PKI components; in the latter case, in-house personnel would manage and operate the PKI components. In either case, additional software may be required for PKI-enabled applications (e.g., plug-ins), and a help desk and appropriate guidance will be needed to respond to user questions and problems. Organizations should define and implement a PKI architecture that best supports their business needs, cost constraints, application environment, and security requirements. When an organization chooses to deploy a PKI, it is essential to ensure that the people maintaining the PKI components are appropriately trained and skilled. They need to be trained in PKI concepts, be knowledgeable about Web and directory servers, be experienced in systems administration with UNIX or Microsoft Windows servers, and possibly have experience with programming and scripting languages. Capitalizing on an existing infrastructure can minimize the additional special training required. We recommend several steps to ensure a successful deployment. First, establish a lab or testbed to validate the architecture, test for interoperability, and demonstrate the intended PKI environment prior to roll out. The lab can be used to assess installation and maintenance issues, validate vendor claims, test interoperability with existing or planned applications, and demonstrate the intended concept of operations. An important lab activity is the demonstration of the planned user enrollment and certificate validation process. Next, conduct a pilot test on a small set of the user population in order to learn about administering the PKI and about usability, training, and user support requirements. Wherever possible, incorporate into the pilot the existing organizational infrastructure that you will use during deployment. For example, security office personnel can issue certificates as well as badges. Pilot testing will ensure a smoother transition to full-scale deployment, refine user support requirements, and thereby increase the likelihood that the PKI will be acceptable to users. Finally, modify the PKI implementation and associated policies and set up your user support based upon the pilot testing results. One of the most underestimated costs of deploying a PKI is the user support required. Most commercially available products are targeted for corporate enterprises or intranets rather than for large scale or global PKIs. CA products offered by vendors differ in capabilities, conformance to standards, and integration with third party products. Also, CA products may require specific client software, toolkits, or application programming interfaces to work with those products. Although most CA products can issue and publish a Certificate Revocation List (CRL), a list of invalid certificates used as a check against unauthorized access, very few applications can retrieve and process a CRL. Third-party add-on software and plug-ins are becoming available for specific servers to process a CRL. In deploying a PKI, an enterprise should account for the current immaturity in products and standards and include sufficient budget for the upgrade of PKI components, applications, and the associated documentation. Critical for PKIs is the design and integration of directory services. A user may query a directory server to retrieve a certificate, or an application may retrieve a CRL from a directory for the purpose of certificate validation. A directory server may also be used to support access control or group management services. Some sites may design their PKI around their existing directory server, whereas other sites may build their PKI and associated directory server at the same time. A heterogeneous set of directory servers may be employed for a distributed enterprise environment. Meta directory solutions and synchronization tools are becoming available to provide uniform access to multiple, heterogeneous directory servers. Like PKI, directory services are an evolving technology area. Products may differ in maturity, interoperability with applications, and the versions of standards they support. Enterprises should select directory server solutions that are interoperable with their PKI environment, existing infrastructure, and business applications. In summary, PKI holds great promise as an enabler for securing distributed enterprise resources. However, PKI technologies are still maturing and will continue to evolve to reflect standards and business needs. Policies and procedures responsive to this evolution are as important to a successful deployment of PKI as the components. It is also important, when creating an enterprise security architecture, to implement PKI as only one part of an overall Defense in Depth strategy. With PKI, common security mechanisms and services can be applied across multiple enterprise resources; as more PKI-enabled solutions become available, enterprises will employ these solutions as multiple layers of defense. However, alternative security measures may be needed for enterprise resources that either will not make use of a PKI (e.g., a legacy system) or are still in the process of migrating towards PKI. For more information, please contact Beth Abramowitz using the employee directory. |
Solutions That Make a Difference.® |
|
|