Tokenized Encryption: Documentation Error Handling
This article examines the structure of a cryptographic interface oriented to CICS Transaction Server and MVS. While the focus of this article is on mainframe environments, the principles and concepts apply to all IT systems. Likewise, except for specific programming languages and software, this information applies to all platforms. Function and implementation may vary.
In my last article, I introduced Payment Card Industry (PCI) compliance documentation, listed the numerous forms that must be created and maintained, and explained that its importance stems from the fact that this practice isn’t only mandatory for compliance, but essential to enable a swift and efficacious response to a data breach and to insure consistent adherence to PCI standards. I also emphasized that well-maintained documentation is a vital asset for all of IT.
In addition, I reiterated the many forms of documentation, including: procedures, manuals, checklists, books, guides, audio and video, how-to information, specifications, Q&As, guidance, historical/archival data and step-by-step instructions. Documentation provides useful data that would otherwise have to be garnered through time-consuming research, testing, interviews, debugging, diagnostic information or other sources. This led to documentation I wrote for a PCI compliance cutover that included a cryptographic interface that insulated application programmers from cryptography and simplified programming to encrypt cardholder data (CHD), checking account data (CAD) and Social Security Numbers (SSN). It addressed programming, testing/debugging, encryption key generation, end-user guidance, encryption usage, security control, emergency procedures, cutover procedures and backup/recovery.
The remainder of the last article discussed the structure of the Cryptographic and PCI Compliance Interface (CPCICI) User’s Guide and the guide’s first four sections. This article picks up at that point.
CPCICI User’s Guide: Section III, Error Handling
While error identification and everything that goes into it–diagnosis, data gathering and handling–is vital, it–like documentation–is a distasteful chore for programmers. Writing code and seeing it work provides a sense of accomplishment, a thrill even, but intercepting or testing errors? What’s the fun in that? Errors aren't something you set out to do. You hope they never occur, but of course they do. Murphy’s Law reigns supreme, whether it be vendor-based or homegrown code. Error-handling logic is at least as important as mainline code, a painful lesson when something goes wrong. If the error is widespread, or causes system outages, code or logic errors can be extremely expensive.
A lot of shops take vendor defaults when errors occur, cleaning up the mess after the fact and taking actions to keep it from happening again. That’s OK to a point; the choice is certainly valid for many infrequently used OS or vendor utilities, and perhaps even for homegrown code that operates at an application’s periphery. The impact is minimal and error handling is time-consuming. However, the impact isn’t always minimal. I’ve seen situations where a software upgrade changes a default action, and a minor impact balloons into a disaster.
The PCI compliance cutover’s use of cryptography for all CHD, CAD and SSN data involved most online and batch business processes. This is the very heart of the business: marketing, order entry, order processing, shipping, customer service, security, accounts receivable. Most importantly, the ability to accept and process credit cards and electronic checks depended on it. Was a robust error handling and diagnosis methodology called for? Certainly. And the methodology couldn’t be efficacious unless it was clearly and thoroughly documented in the CPCICI User’s Guide.
The error handling logic was written to handle error messages and diagnostic information for these products:
- MVS–the OS
- JES2–job entry system
- DFP–data facility product
- VSAM–file and data handling software
- DFSMS–system managed storage
- ICSF–IBM cryptographic software using satellite processor
- MegaCryption–cryptographic software without satellite processor
- CICS TS–transaction processing software
- DB2–relational database
- User or application
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.
comments powered by