Tokenized Encryption: Getting Started
When I was engaged to implement cryptography and establish payment card industry (PCI) compliance, it was for a single division of a large conglomerate where each division had its own IT department with differing software, hardware, infrastructure and performed separate implementations. Although my client had the most processing platforms and data stores to integrate, and outsourced some processing to a vendor―further complicating infrastructure issues―we were the first to implement PCI compliance, winning a corporate award for leading the way.
I wasn’t surprised. I didn’t know much about other divisions’ implementations, but I knew that our effort had been thoroughly researched and carefully planned before any work was done, and that most clients I’ve worked with were much more casual about project planning. When I joined IBM early in my career, I learned about project planning from a consulting systems engineer who’d led a leading-edge customer through a number of first customer ship and early support programs. He promptly assigned me to be “keeper of the plan.” No project planning tools like those of today existed back then, so I created the plan from scratch using coding sheets that I filled in by hand, in pencil, so it could be erased and modified. And there was much erasing, along with endless modifications. At least we had copiers, thank goodness.
The most important project planning event was “the kickoff meeting.” This was a gathering of key implementation team members and other department representatives. We spent one to three days discussing the project and learning expectations from IBM Development, the System Center and Level 2 Support. We also learned how to interface with each other. We laid out a chronological plan of installation, testing, customization, move to production, user impact and various other upgrade-related activities. At night, I’d update and enhance the project plan for review and modification the next day by the entire group. Research projects were identified, then plotted in following days and forwarded to me for plan integration. After final review and feedback, the plan became a blueprint for an upgrade.
So I learned early that the essential elements of project planning remain the same regardless of process or venture. Tasks must be identified and sized, and individuals must be assigned to tasks. Task dependencies need delineation. Percent complete, where applicable, needs to be entered. Deadlines must be factored in and milestones need to be established. Realistic time estimates need determination to reflect other assignments project participants had. No single individual has the knowledge or authority to determine all project plan elements; it takes a team to make a plan.
Kicking Off a PCI Compliance Implementation
While this project describes the establishment of a mainframe-based cryptographic interface oriented primarily to CICS Transaction Server, COBOL and MVS, the principles and concepts apply to all IT platforms. In fact, many of the issues and tasks involved were also used in the client’s websites using different programming languages and software to enable cryptographic operations that securely protected cardholder data (CHD) and checking account data (CAD).
As noted, the kickoff meeting is the most important project planning event. But it’s not the beginning of a project. Substantial research, data collection and document assemblage must occur first, because a kickoff meeting involves many busy, important and spread-too-thin participants: management, senior staff, and security and technical specialists. It’s hardly the place to be looking up procedures, checking software levels or doing other clerical activities. Instead, it’s a time when everyone in the room can devote undivided attention to the project plan and express objections, suggestions, corrections or observations. As much as possible, the project plan is modified to participants’ abilities and availability.
Over time, I’ve built up a bank of project plans―mostly in MS Project―which I use as templates. They greatly shorten the time to create an initial plan―in this case PCI compliance implementation. These templates are easy to modify; for example, participant names can be changed to employees from placeholder names (e.g., John Doe, Jenny Day, etc.), and tasks are already linked (e.g., tasks 1, 2, 5 and 9 must be performed in that order), time estimates are assigned, task descriptions are filled out, etc. With most data entry already complete, creating a tailored project plan becomes a matter of modification. Of course the modifications are still substantial, but in most cases it comprises a quarter of the work required to create a new plan.
Once a list of necessary, desirable and optional project team members is compiled; an acceptable date and duration―two to three days―is determined; research and interviews are completed; and available facilities are procured, it’s time for a kickoff meeting. After introductions, first activity was presentation, revision and finalization of an agenda built from collected interviews, suggestions and issues, followed by a project plan overview. When projectors were available, the project plan was shown on a screen or display; otherwise, paper copies must suffice. It’s vital that every participant see the plan and that changes to its content are clear and accurate.
Once the agenda was set and determination of who has to attend and when they need to be there is complete, the project plan review started at task one. Team members chronologically worked way through the document, discussing each step in some cases and groups of tasks in others, and either approving the plan as is or making changes as necessary. Small changes were made immediately; larger changes―such as reassignment of sub-projects to different individuals―were thoroughly discussed with someone taking took detailed notes that captured sufficient information to make the larger changes that evening or after the kickoff meeting’s completion.
The next morning, or after kickoff meeting completion, the validation of project plan changes was the first activity. Corrections were made if identified; sometimes someone would change their mind overnight and modifications of that sort were made. Then individuals who’d been tasked to find information would report back, which would sometimes lead to further discussion and possibly project plan changes. When all open items were addressed, it was back to work on the project plan.
Alongside kickoff meetings, breakout meetings are held to address specific, usually arcane topics affecting only limited units or individuals. Kickoff team members may also discuss topics with peers outside the group, including vendors, end users, management personnel who are on the periphery of the project, or any individuals with pertinent information or whose responsibilities cross into the area affected by the project.
Finally, team members may determine recommendations by logging in and investigating setup, parameters or functions; discuss a topic with others; or test facilities or data. The sub-group reports back to the main group with findings or conclusions, which may instigate a larger discussion, and invoke project plan changes or additions. If modifications are minor, they will immediately be incorporated; if they’re more involved, they’ll be made off-hours.
The last couple meeting hours are usually organizational. Most important is the establishment of tracking activities, especially status meetings. The project plan is key to effective status meetings, because it’s where all project members report on activities and overall progress. Has a task been started? Is it complete? How close to completion? Has an obstacle been encountered? If so, how can it be resolved? And so forth. Other issues, like timesheet submission, contact lists, problem submission and resolution procedures, logon authorizations, sometimes even demonstrations of specific systems, standards manuals to adhere to, and other miscellaneous topics are covered to assure that project participants are fully qualified.
Then it’s time to go to work.
Planning and Tracking Means Success
Does a good PCI compliance project plan take a lot of time and effort? Absolutely. Does it pay off? Definitely. This PCI compliance implementation was finished before the projected completion date and cryptographic processing ran flawlessly. Encrypted website data was cleanly recrypted to mainframe, and mail order sensitive data was encrypted during data entry. Encryption cutovers and CHD/CAD were successfully recrypted. No performance issues were encountered, and there’s no evidence of any data breaches or attempts. Were there a few problems early on? Sure. But they were minor and soon fixed. Every audit went smoothly and successfully. Why? Careful and thorough project planning played a major role, and a kickoff meeting was what got the ball rolling.