AIX > Administrator > Security

Tokenized Encryption: Connecting Docs

Encryption Documentation

This third and final article on documentation examines the information necessary to support a cryptographic interface oriented to CICS Transaction Server and MVS. While the focus 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.

The first article introduces PCI compliance documentation, a mandatory, vital component due to the plethora of forms that must be created and maintained. Though it's seen as a tedious task, documentation is critical. It's especially helpful to new or inexperienced employees or contractors. Partly because it’s reviewed in a PCI audit, and partly because it’s the glue that keeps PCI compliance infrastructure and function operational, first rate documentation is extensive and detailed. Well-written documentation eliminates time spent in research, testing, and investigation during breaches and outages as well as normal activities, and in the case of a PCI Compliance implementation, simplifies and assures the security of cardholder data (CHD), checking account data (CAD) and social security number (SSN).

The remainder of the first article covers the Cryptographic and PCI Compliance Interface (CPCICI) User’s Guide structure and its first four sections.

The second article focuses solely on section five, which is devoted to error handling, coding considerations, programming guidelines and suggestions, sample code, copy books, and various programming tips. It also discusses underlying error handling methodology while providing a list of software product messages (z/OS, CICS TS, ICSF, etc.) built into copy books, as well as guidance on how to construct user messages. A comprehensive error handling architecture is vital to the PCI compliance implementation.

This article delineates section six, Compendium of PCI Compliance Documentation. The notions of compendium and document server are important ones. A compendium is more than just a table of contents, and it’s different than abstracts; these were designed to describe a document’s utility and illuminate what a document was to be used for. A document server provides multiple advantages: thorough and comprehensive security, quick and easy access, search and display capabilities, customizable print and download utilities, even Q&A facilities. Section six’s primary purposes are twofold:

  1. Provide information on PCI compliance and internal programming documents. These documents not only have names, but often alphanumeric identifiers of Category, Requirement and Sub-Requirement number. Using those identifiers as secondary document names simplified the PCI compliance audit.
  2. The description included links to the current version of a specific document. Anyone who needed document access needed only to click on it. If it was secured, a signon was required. Public documents immediately came up. Some CPCICI User’s Guide links were for general programming topics; those links went to local document servers on client premises.

All PCI compliance documents—and as time passed, numerous other IT documents—were stored on a document server accessible to IT staff, PCI compliance auditors and staff, and members of the mainframe service provider’s staff. The document server was owned, administered and managed by an accredited third party, and security authorizations and standards were strictly defined and enforced. Specific procedures had to be followed and approvals were needed to move or access documents.

User’s Guide, Compliance and Documentation

PCI compliance documents had a specific, mandatory header format at the beginning of each document, and many documents were reviewed as part of the annual PCI compliance audit. Documents needing review were determined in the audit’s initial step. Review and completion of a PCI audit checklist that identified requirements that had changed during the prior year or were an annual imperative. All documents related to PCI compliance standards had to be reviewed annually; if no changes had been made, only the date of most recent review had to be updated. Templates, samples and guidelines were provided in PCI Data Security Standard (DSS) documentation regarding how specific documents should be structured. Here’s how most document headings were structured.

Document title – A name that describes a document’s purpose and includes PCI requirement and sub-requirement where appropriate.

Document description – A relatively detailed explanation of the document’s subject. For example, “This document identifies the specific steps that must be taken in order to create a new private encryption key for use in encryption, decryption, and other cryptographic functions that are performed by all online and batch systems on the mainframe.”

Document owner – Initially the document author, but over time, either the last person who modified the document or the person who replaced the originator in the case of departure or reassignment.

Document type – Documents can take the form of written material, audio, video, or audiovisual media, or forms of media.

Jim Schesvold is a technical editor for IBM Systems Magazine. Jim can be reached at jschesvold@mainframehelp.com.



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 Disqus

Advertisement

Advertisement

2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Hardening the Cloud

Security considerations to protect your organization

Verify System Integrity

AIX 6.1 and Trusted Execution help ensure secure systems

A Bankable Solution

AIX Cryptographic Services improves security while simplifying administration

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
AIX News Sign Up Today! Past News Letters