AIX > Administrator > Security

Tokenized Encryption: Real-Time System Control

Encryption
 

Because sensitive data like cardholder data (CHD), checking account data (CAD) and Social Security Numbers (SSN) is so critically important to organizations, when this data is breached it’s vital that enterprises react quickly to the emergency. Detection mechanisms must instigate near-instant actions to stem the invasion and theft, if still underway. Intruders must be identified and disconnected (if advisable), and breached data must be re-secured. Any number of other actions may need to be taken to mitigate the damage, including shutting down processing systems that could worsen the situation.

This article discusses a mainframe-based encryption interface oriented to CICS Transaction Server (TS) and MVS, but the principles and concepts apply to all processing platforms. Function and implementation may vary.

Organizations must act quickly to restore system stability – which may or may not include resumption of normal operations. Having a richly functional online interface in place to facilitate system changes – especially the encryption interface – is a vital component of rapid intrusion response. A sound online interface is characterized by the facilitation of speed in action while providing simplicity and accuracy. It minimizes keystrokes and simplifies access to procedures, which in turn determines decisions to be made. Enterprises need screen-driven procedures and a recovery process consisting of straightforward and descriptive steps and supported with online documentation. Direct and senior management must be notified immediately. In most cases a senior security manager is charged with situation management. The senior security manager's first task is to notify and engage a recovery team of specialists in implementing system and application level changes.

For this reason, I designed and implemented within the cryptographic interface an online transaction that's capable of modifying encryption software as well as interacting with the mainframe’s master console. We nicknamed this transaction "WZRD," a byproduct of a planning session joke: “the wizard can make the world right.” Granted, that's a bit of overstatement, but it does embody the intent of and powerful function built into this transaction. WZRD was tightly authorized and limited to a select group trained in function and control of cryptographic products and emergency procedures. WZRD’s function was based on existing procedures and specifically designed to deal with sensitive data breaches or intentional disruptions.

Some of WZRD’s capabilities follow, along with descriptions of the roles they play in dealing with security breaches. Also listed are some normal business functions that are also limited to only select individuals due to potential misuse.

Step 1: Issue Breach Notifications to All Relevant Parties
Since a breach may be detected by almost anyone in various ways, procedures were developed, tested and distributed to virtually every employee and contractor. Given a breach's disastrous consequences, there was no such thing as a false alarm or specious report. Every alert was treated as genuine, and involved a number of steps:

  • All procedures and how-to documentation was available via WZRD.
  • The security coordinator’s phone number was ubiquitously posted throughout the company, replete with instructions to immediately contact the coordinator over anything suspicious. The coordinator collected all available information and keyed it into a "Notes" WZRD option, available to the entire security team.
  • The coordinator used the Notify selection to trigger texts and emails to every security staff member–replete with notes–so they could immediately begin their investigation.
  • A conference call was set up immediately for all participants to determine whether the breach was real and still underway.
  • If the breach was underway, all steps possible were taken to identify the source of the hack and stop the intrusion via network facilities.
  • If the breach was still underway and unstoppable, a vote was taken whether to take the file offline or to shut down the system.

Step 2: Shutting Down the System and/or Taking Sensitive Data Offline.
In the unlikely event the breach is still underway (most breaches are detected after the fact, often long after), the first priority is to stop the downloading or destruction of data. WZRD provided two options to accomplish this:

  • Take the file offline. MVS VARY and IOACTION commands (other operating systems have similar commands) can take disk storage devices and I/O paths offline, making them inaccessible to any program or operating system. WZRD, using an automated operations product, was able to do this directly without console operator intervention.
  • Perform a full system shutdown. This is a very disruptive action that takes a substantial amount of time and requires console operator involvement and management approval. A full shutdown should be viewed only as a last-ditch, desperation move, and it must be done in an orderly fashion to avoid even more problems. But when all else fails…..

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