This section details the process for deploying smart card technology in a large enterprise setting. Because the adoption of smart card technology is still limited, it’s not possible to offer a detailed “cookbook” for successful deployment. However, this section will offer recommendations and identify risks specific to smart card technology integrated with a process based on the Microsoft Solutions Framework (MSF) principles of infrastructure deployment. MSF specifies best practices and principles for managing software development and deployment distilled from internal practices at Microsoft.
The deployment process is organized into three phases:
- Envisioning Stage
- Planning Stage
- Development Stage
Each stage includes milestones that help your organization track progress and ensure that the deployment addresses your organization’s needs. For more information about MSF infrastructure deployment, see http://www.microsoft.com/technet/itsolutions/msf/default.mspx.
Some of the most common reasons for project failure include a lack of shared project goals and a lack of executive sponsorship. Therefore, before detailed planning starts, it is critical to ensure that a clear vision exists for how smart card technology will be implemented. It is also important to involve executive management. Achieving these steps is the goal of the envisioning phase.
Gather the Requirements
Frequently, organizations make the mistake of moving right into development without performing a thorough business requirements analysis. Anticipating the applications that the card must support in its lifetime is critical to good design. After the chips for the card are manufactured, the number and size of applications that can later be added to the card are set. Some applications might not be ready until months later, after the cards are already deployed in the organization.
For this reason, it’s important to identify and meet with the key stakeholders in the smart card deployment in the early development stage. Stakeholders include groups that intend to build smart card applications and groups that can approve (or block) the smart card deployment.
From these discussions, you can compile the requirements into a requirements document. Most organizations are initially interested in smart cards for security reasons. Other common requirements for smart cards include:
- Enhancing the security of user logons to the corporate network from the desktop
- Providing selective access to data, resources, and Web sites
- Providing employees enhanced security when remotely accessing the corporate network
- Enabling legally binding digital signatures
- Providing internal payment systems (or e.g. e-purse) within the organization
- Migrating toward elimination of passwords
- Enhancing asset tracking; who’s doing what, with what, and for how long?
- Ensuring access for employees with disabilities
After you compile a list of business requirements, consider the administrative tools that will be necessary to manage large numbers of smart cards, such as tools for:
- Resetting a user’s PIN remotely.
- Viewing a user’s card profile. What applications are on the card? How much memory is available?
- Performing first-time diagnostics on a card as it’s being issued.
- Allowing full access for security officers.
- Flashing new chips.
Document the Operating Environment
Identify the platform, network/server configuration, and hardware with which the smart card solution must integrate. A functioning PKI must be in production in the enterprise before you can deploy smart card technology.
In addition, be sure to document the user’s physical environment. Will users be swiping cards at doorways, next to cashiers, or at workstations? Will they be using cards with mobile devices? What accommodations must be made for people with disabilities?
Prioritize Requirements and Create a Version Strategy
The initial deployment should focus on a few top-priority features and establish the one-time elements of the system (e.g., cards, card readers, issuance process). If designed properly, you can add additional applications and features later to the same card over the course of its life cycle. It’s recommended that you implement the overall list of features in the requirements document in phases.
Build the Team
Getting the right resources on the project takes a long time, so this must begin early. Complete a skills assessment based on the technologies that will be needed. For example, if your company uses Windows 2000 or Windows Server 2003 for its server architecture, at least one developer on your team must have knowledge of PKI. During this time, you can interview and select a card vendor that will participate on the team.
Prepare a Vision/Scope Document
This document will identify the goals, value proposition, high-level features, and risks of the smart card deployment. Circulate this document to key decision-makers, IT managers, and managers of user groups that will be most affected. The vision/scope document must reduce the ideal list to a manageable list of features that can be implemented in a single project or series of projects.
Conduct a High-Level Vision/Scope Review
Present the vision/scope document to the key decision-makers and stakeholders. The review should include a rough cost estimate (not a fixed budget), approximate project time frame (not exact dates), and a preliminary risk assessment. It should also be clear that there are two choices available to the key decision-makers—they can approve and commit resources to proceed to the next milestone or disapprove and send the document back for revision.
After the vision/scope–approved milestone has been passed, detailed planning and specifications can begin.
Write Functional Specifications
The functional specifications must describe the architecture, design, and implementation details of the core system and custom applications that will use smart card technology. You should consider several key points when preparing the design and specifications.
Chip Design. Chip design should anticipate adding new applications during the 18- to 24-month life cycle of the card. Assume that interest in taking advantage of the smart cards for new applications will grow after people begin to use them. When planning file allocation tables (FATs) and storage space on the chip, allot space for applications that are still in the early phase of planning. Good communication is critical; for example, if an application requires 4KB of storage space on the chip, the space is reserved and reconciled against the storage needs of other applications.
Graphics. The chip can be screen-printed directly on a card or applied as a sticker, or “skin.” By using a skin, you can leverage existing corporate cardkeys or badges. Enterprises with existing card issuance processes and issuing stations and policies can save money by “piggybacking” these processes, stations and policies. Avoid issuing employees multiple cards and readers because to do so involves considerable cost. As more powerful card operating systems and memory become available, skins can be washed off by using special solvents, and new skins can be applied. Note that there’s a risk of damaging the chips with the solvent. For some organizations, such as the military, skins might be viewed as less secure than screen-printing because skins can also be peeled off and placed on a different card.
Cards and Readers. Some organizations have found that if the card-to-reader interface is too tight or abrasive, the cards deteriorate more rapidly. This situation can occur if the cards are too thick. Discuss this issue with your card and reader vendor or vendors. Include physical thickness of cards in your specifications, which is important when selecting vendors for manufacturing skins because the material thickness for skins varies. Also, some readers use USB ports. Some users might have all USB ports on their workstation occupied, and therefore need special accommodations to use the readers. You might need to obtain a mix of card reader connector types. In some companies, it’s appropriate to give users the option to choose the connector type. Some personal computer vendors provide alternative options that don’t occupy the USB port. Both Siemens and Compaq/HP offer corporate desktop computers with built-in card readers. Compaq/HP and Cherry Systems make a keyboard that includes a smart card contact reader at a reasonable cost.
Prepare Schedule and Budget
After the functional specifications are sufficiently detailed, developers and infrastructure IT personnel can prepare detailed task lists and time/cost estimates. The task lists and estimates can then be added to the project schedule and budget estimates. It’s sometimes helpful to create a master plan document that describes the overall strategy for completing the project.
Prepare Risk Assessment
Brainstorm the risks specific to the smart card deployment and document them in a spreadsheet. For each risk, make a determination regarding its probability and impact and decide what the response will be. Response options include avoiding the risk entirely (by doing something to eliminate its cause), mitigating the consequences of the risk, creating contingency plans should the risk occur, or accepting the consequences of the risk. For more information about MSF risk management, see the white paper “The Risk Management Model,” available at http://www.microsoft.com/technet/itsolutions/msf/default.mspx.
Plan Phase Deliverables
The deliverables of the planning phase are a set of planning documents, primarily consisting of the functional specifications, master schedule, budget estimate, risk assessment, and perhaps others. You can disseminate these deliverables to the key decision-makers for comments and input.
Conduct a Project Plan Review
Like the vision/scope review, the project plan review provides a checkpoint at which key decision-makers have an opportunity to evaluate the smart card deployment before committing further resources. However, this review includes much more specific information about how it will work, the cost, and how long it will take. As before, the review meeting should end with yes or no decisions about committing resources to the deployment. If the plan is approved, the deployment continues on to the development phase.
Most smart card deployments require a phase of solution development as custom features, application integration, and installation scripts are developed. Although the specifics depend entirely on the nature of your smart card solution, the following checklist contains some development best practices to ensure quality.
Proof of Concept
Build a proof of concept to test the smart card solution in a lab simulation setting.
- Use a version control tool, such as Microsoft Visual SourceSafe, for all custom components being developed.
- Set up a test environment that reflects the production environment as much as possible.
- Devise test cases and compile them into a test plan.
- Use issue-tracking software to track bugs.
- Take an iterative approach to testing, and retest bugs that have been fixed before closing them.
- Establish acceptance criteria for implementing a pilot with input from key stakeholders, such as IT management, security, and department leads of affected user groups.
The purpose of the pilot deployment is to stress the card technology in addition to the processes for issuance, management, and support of the card.
Decide on the size and the composition of individuals who will participate in the pilot. The number of participants determines how many cards and readers to order from the manufacturers. There should be enough participants to stress the deployment and support processes, in addition to the technology—perhaps 100–200.
In most cases, participants should be volunteers. Consider creating an internal Web page to explain what the pilot is about. This way, you can solicit additional volunteers and provide updates.
Consider using special programs and incentives to encourage the use of the cards during the pilot, because it’s unlikely that they’ll be required to use them at this stage to perform tasks such as logging on to the network.
Prepare for Production Deployment
While the pilot program is in progress, you can prepare and refine training materials for the production deployment process:
- Draft policies and procedures.
- Prepare the card issuance process.
- Train technical support and issuance staff.
- Determine the number of cards and readers needed.
To prepare for card issuance, you can map out the issuance process. Be sure to include physical variables, such as locations of issuance stations and the equipment required at each station.
Deploy Core Technology
You should first deploy the technology that’s centrally operated and managed. Again, the PKI servers are assumed to be operational. Production manufacturing of cards or skins takes place at this time. Arrange for secure delivery and storage throughout the distribution process for receiving from the vendor and sending cards or skins to the various issuance stations.
Deploy Readers and Begin the Issuance Process
During this phase, users receive their cards and readers, and then install the necessary drivers and components from the internal site. You can anticipate and plan for a heavy load of troubleshooting and escalation calls to your technical support staff.
The issuance process should be organized into phases by organizational or geographic units. Users of a given unit are notified that they can obtain their cards and receive instructions within a designated period of time. The implementation schedule should accommodate travel and setup time for security officers and issuance teams who are traveling from site to site.
Complete the Stabilization Process
The development team must work closely with IT personnel to track and resolve issues that are escalated from technical support staff. The development team and the operations staff must agree on the point at which the smart card deployment is considered stable enough to be completely transitioned to operations.