File and Object Storage

 View Only

Pervasive Encryption with zDMF: Taking steps toward information security's CIA triad

By Archive User posted Tue December 11, 2018 10:23 PM

In this article we discuss implementing pervasive encryption using zDMF, and how this effort enhances information security. We first provide a brief overview of information security and its objectives, the so-called CIA triad - Confidentiality, Integrity, Availability. We then look at how pervasive encryption contributes to these information security objectives. Finally we show how the data set migration product, zDMF, makes implementing pervasive encryption easy.

Information security objectives

In its publication An Introduction to Information Security the National Institute for Standards and Technology (NIST) defines Information Security as:
The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to ensure confidentiality, integrity, and availability.1

Indeed, embedded in this definition we find the three information security CIA objectives, which the publication goes on to define as follows:2, 3

Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Integrity: [is defined] as having two facets - data integrity and system integrity.

  • Data integrity - The property that data has not been altered in an unauthorized manner. Data integrity covers data in storage, during processing, and while in transit.

  • System integrity - The quality that a system has when it performs its intended function in an unimpaired manner, free from unauthorized manipulation of the system, whether intentional or accidental.

Availability: Ensuring timely and reliable access to and use of information.

We note here, and will expand upon this later, that data encryption helps maintain confidentiality and integrity.

There are at least three compelling reasons for a company to take the information security objectives serious:
  1. they are required by law.
  2. their data is valuable.
  3. their customers demand it.

When we think about information security, recent, or even memorably distant, computer hacking events and data breaches might come to mind. Indeed, that this is the case can be seen at a stunning website maintained by David McCandless, vizualising the rise of data breaches over time. And as we see in figure 1, while the number of actual data breaches remains relatively steady with some jumps, the numbers of records exposed steadily and dramatically increases (we can expect 2018 to continue the trend once the second half numbers come in).

Figure 1
Annual number of data breaches and exposed records in the United States from 2005 to 2018 (in millions)

Understandably then, when it comes to information security, the focus tends toward making strides in preventing intrusions; we want to stop people from hacking in and stealing data. There is a saying in the security industry that there are two kinds of companies; the companies that have been hacked and know they have been hacked, and the companies that have been hacked, but do not know they have been hacked. That sentiment may be a bit cynical. However, it points out that any company with a digital presence likely faces the prospect of cyber attacks with the potential of their data stolen and or altered. Adding data encryption to a company's arsenal of weapons against unlawful cyber intrusions reduces their risk of exposure to breaches of data confidentiality and integrity.

Of course, data encryption does not prevent hacking, does not prevent cyber attacks, does not prevent intrusions. However, data encryption renders stolen data virtually useless to the hacker; the data cannot be read, securing data confidentiality, and the data cannot be changed in any meaningful way, securing data integrity. Security expert Bruce Schneier calls this making the hacking problem harder: they have to steal the data and the key.4

Pervasive Encryption

How does a company decide what to encrypt? Pervasive encryption refers to the notion of encrypting everything, also referred to as bulk data set encryption. Why encrypt everything or almost everything? A company might encrypt just the important data sets, but then, as Schneier says, "if we only encrypt important data, encryption signals that that data is important".5 But doesn't a state of the art storage device like the IBM DS8880 provide bulk encryption for all the data on the device? Yes, it does (or it can6) and that is called data-at-rest or whole disk encryption. This type of encryption protects a company's data against the threat of theft or even simply careless disposal and replacement(e.g. data not scrubbed from disk). It is actually intended or at least most effective for storage devices on laptops or even desktop computers, which fall into the category of devices more likely subject to theft than a large DS8880. Data set level encryption provides data protection at a level above whole disk encryption. To that end, IBM added support for DFSMS z/OS data set encryption in z/OS 2.1 and 2.2 with APAR OA50569, released in 2016, and in z/OS 2.3 at general availability in 2017. With this new encryption function encrypted data sets are created using the KEYLABEL IDCAMS parameter or the DSKEYLBL JCL parameter. The KEYLABEL identifies the encryption key which is created and managed by the Integrated Cryptographic Services Facility (ICSF).7 Once an encrypted data set is created, an IDCAMS LISTCAT will show that the data set is encrypted along with the name of the encryption key. IEHLIST LISTVTOC also indicates that a data set is encrypted by displaying an 'N' in the SMS.IND field of its report. After a data set becomes encrypted the access method decrypts and encrypts the data as required by any application using the data set. At the time of this writing, only SMS extended format VSAM and SAM data sets can be encrypted.

Pervasive Encryption Using zDMF

zDMF migrates data sets from one volume to another transparently regardless of their 'in use' status. The migration of data sets is initiated and managed in a zDMF group. The group defines what data sets are to be included in the migration, to what volumes or storage class they are to be migrated, and specific migration parameters that affect how they are to be migrated. After definition, a zDMF group is 'activated' which verifies the group parameters and creates target data sets on the the new volumes where the source data sets will eventually reside. ZDMF then enters a COPY phase where all source data is copied to the new target data set. The next phase of zDMF migration is MIRROR when all update I/O to the source data set is kept in sync with the target. The next phase is the DIVERT phase where the source data set is swapped with the target dat set and any applications with existing allocations to the migrated source data set have their I/O diverted to the new target data set. The zDMF group is completed when all data sets in the group no longer have existing allocations to the original source volumes. The completion of diversion can happen in several ways: VSAM data set events such as EOV (end-of_volume) or EXTEND will cause a data set to complete, a CLOSE/OPEN sequence by the application will complete the data set and any recycle of the application will also complete the data set.

In support of data set encryption the zDMF group definition will include new parameters ENCRYPT(YES/NO) and KEYLABEL. The ENCRYPT parameter indicates that data sets in the group should be encrypted while they are being migrated. The encryption key for each data set is obtained in the same manner as DFSMS:
  1. If a RACF profile for the data set exists with a DFP segment that includes a DATAKEY it will name the encryption key that will be used.
  2. The KEYLABEL on the zDMF group will be used if RACF does not contain the key name.
  3. If there is no zDMF KEYLABEL and ENCRYPT(YES) has been specified then the data class of the source data set will be examined for a KEYLABEL.
  4. If no key is found the data set will not be encrypted.

The following example shows a zDMF group definition with the new KEYLABEL parameter.


) -

In this example all data sets that start with HLQ.ENCRYPT.MYDSN will be selected for migration with encryption. Once the group is activated the standard encryption key search order will be done for each data set. The group will then move to the COPY phase where the zDMF target data sets will be populated with encrypted data blocks. As the group moves to the MIRROR phase any application I/O will be encrypted in the new target data sets. zDMF's data set name masking capabilities can reduce the effort required to accomplish large bulk data set encryption tasks.

Initial support for zDMF data set encryption will prevent groups with encrypted data sets from moving to the DIVERT phase until all source data set allocations are freed. This initial support will be introduced with zDMF V3R4M0, announced 4 December 2018 and generally available 7 December 2018. Other features that will be supported in the future will include:
  • convert non extended format data sets to extended format with the option to encrypt during a zDMF migration.
  • the ability to convert data sets that are already encrypted to another key or to convert them back to non-encrypted data sets.


Every business with a digital presence that creates and/or use confidential or personal sensitive information bears the responsibility for protecting against unauthorized disclosure of that information. Encryption and its broad application of pervasive encryption reduces the chance of data disclosure or alteration. zDMF tackles the problem of bulk data set encryption of existing non-encrypted data sets.

1 Special Publication (NIST SP) - 800-12 Rev. 1, An Introduction to Information Security, p.2. Note that this is a recent revision to NIST's original 1995 publication, An Introduction to Computer Security: the NIST Handbook

2 IBID, pp.2-3

3 The publication notes that terms and definitions were retrieved from CNSSI 4009, Committee on National Security Systems (CNSS) Glossary, dated April 6, 2015.

4 Schneier, Bruce, CRYPTO-GRAM July 15,2010 at

5 Schneier, Bruce, CRYPTO-GRAM July 15,2015, see link in footnote 4.

6 Dufrasne, Brunson, Reinhardt, Tondini, Wolf, IBM DS8880 Data-at-rest Encryption, Seventh Edition, IBM Red Paper, IBM Corporation, 2018.
7 Cryptographic Services Integrated Cryptographic Service Facility Overview Version 2 Release 2, SC14-7505-06, IBM Corporation, 2016.

John Hogan and Richard Pace are software developers for the TDMF And zDMF products at 21st Century Software.