FDRERASE considerations

Why Erase DASD?

Your corporate data is a valuable resource. The data often includes information that you do not want to share with anyone outside your company, and sometimes not even with others in your company. Government regulations (for example, HIPAA, Sarbanes-Oxley, and others) as well as corporate standards may legally obligate you to protect the data from unauthorized access. You may have security procedures that limit access to data in your data center and control access when data must be sent out of the data center.

Yet, in many cases, little attention is paid to residual data left on DASD after data sets are deleted or moved to other locations. Deleting a data set from DASD does not erase the data from the DASD tracks, it just deletes the VTOC pointers to the tracks containing the data (there is a security system ERASE option that will actually erase deleted data sets but it is rarely used because of overhead).

When a DASD volume has been emptied of data, or is no longer needed, you may need to erase the DASD to be sure that no residual data remains on the DASD volume, so that no future user of the DASD can retrieve your data. This is especially true if the DASD will be removed from your data center and sold to a new owner or returned to the DASD vendor. You may wish to erase the DASD even if they will be reused within your data center, so that the new users cannot retrieve unauthorized residual data. Even if you plan to scrap the DASD subsystem, it may be safest to erase the data first.

At a disaster recovery center, at the end of your disaster test, and when leaving after a real disaster, you should erase the D/R DASD volumes to ensure that the next customer using the D/R DASD cannot access your data.

Erase Standards

The National Computer Security Center (NCSC), a former division of the US National Security Agency (NSA), has documented DoD (Department of Defense) guidelines for erasing computer DASD. These definitions are found in document NCSC-TG-025 A Guide to Understanding Data Remanence in Automated Information Systems, also called the “Forest Green Book”. You can find copies of this document online by searching the Internet for “NCSC-TG-025”.

The Department of Defense has also issued DoD 5220.22-M National Industrial Security Program Operating Manual with guidelines for erasing DASD. You can find copies of this document by searching for “5220.22-M”. In addition, there is a memorandum from the Assistant Secretary of Defense (ASD C3I), dated 4 Jun 2001, on Disposition of Unclassified DoD Computer Hard Drives.

The Computer Security Division of the US National Institute of Standards and Technology is has published Special Publication 800-66 Rev-1: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule that documents DASD overwriting requirements. You can read this publication on the Internet at http://csrc.nist.gov/publications/PubsSPs.html.

BSI, the German Federal Office for Information Security, has issued the IT Baseline Protection Manual that can be found on the Internet at www.bsi.bund.de. Section 2.167 “Secure deletion of data media” discusses requirements for overwriting DASD data.

The Australian Government Information Security Manual defines overwriting requirements for DASD data. This document can be found on the Internet at www.dsd.gov.au.

The Department of Defense requirements for media sanitization require an overwrite with a pattern, and then its complement, followed by another unclassified pattern (for example, “00110101” followed by “11001010” and then followed by “10010111”. This series is considered three cycles. For these government requirements, sanitization is not complete until six passes of three cycles are successfully completed.

There may be other data erasure requirements in other countries or industries.

Some government security and privacy requirements require that data be kept secure from outside access but do not specify compliance techniques in detail. FDRERASE can be used as part of the process to ensure that such requirements are met.

Data Threat Levels

There are three levels of threat of unauthorized access to your data that are addressed by the different types of erase functions performed by FDRERASE. Modern DASD subsystems use internal fixed-block architecture (FBA) DASD to store the count-key-data (CKD) data used by z/OS systems; this architecture is described in more detail later in this section:

1. The first threat level is that your count-key-data (CKD) data can be accessed by another z/OS program or another z/OS system. This threat might by a deliberate attempt to access unauthorized data. It also might be inadvertent access, for example, data left at a disaster/recovery site after a test or real disaster, accessed by a subsequent D/R customer.
2. A higher threat level is that the fixed-block architecture (FBA) DASD can be removed from the vendor's DASD subsystem, attached to another system (for example, a PC) as an FBA DASD (SCSI, Fibre, etc) and accessed by an FBA program with little special programming or hardware required. This could occur inadvertently if the FBA DASD from a decommissioned count-key-data (CKD) subsystem are removed and sold or reused, but it could also be a deliberate attempt to access your data.
3. The highest threat level is that the fixed-block architecture (FBA) DASD can be removed (as in #2 above) and special FBA access techniques or equipment are used to access previous versions of data on the DASD, even if the data has been overwritten. The write hardware of FBA DASD may rewrite data at slightly varying locations, leaving the possibility of residual magnetic signatures of the previous contents; this residual data can only be read with special hardware or programming, as used by data recovery companies. Using special hardware or programming to read the data is definitely a deliberate attempt to access your data.

Types of Erase

ERASE

The ERASE function of FDRERASE addresses threat level #1 and #2. By default, it writes a track-length record of binary zeros on every track, insuring that the data on the fixed-block architecture (FBA) DASD is completely overwritten. You can optionally request that this record be written multiple times (ERASEPASS=n) and you can specify the data byte to be used instead of zero for each such pass. If the data byte is zero (the default), then FDRERASE actually sends only a few bytes per track down the DASD channel (the control unit pads the record with additional zeros), so the default FDRERASE is quite fast. There are also options to write a random pattern, or to erase the track.

The default ERASE function meets the NCSC and DoD definition of “clearing” or “overwriting” the DASD.

The default ERASE function also meets the Australian guideline for sanitizing unclassified media.

SECUREERASE

The SECUREERASE function of FDRERASE addresses all three threat levels. SECUREERASE writes a minimum of three passes of data (track-length records) on each track with a varying pattern of data in each pass. SECUREERASE prevents even sophisticated recovery techniques from recovering data from the fixed-block architecture (FBA) DASD. Although this usually takes more time than other erase options, this can provide the highest assurance that your most sensitive data has been obliterated.

SECUREERASE meets the NCSC definition of “purging” the DASD and the DoD definition of “sanitizing” the DASD.

SECUREERASE meets the HIPAA requirements for disposal and reuse of DASD that contain protected health information.

SECUREERASE with ERASEPASS=4 or 6 meets the German BSI requirements for overwriting DASD.

SECUREERASE meets the Australian requirements for sanitizing In-Confidence and Restricted media, and SECUREERASE with ERASEPASS=5 meets their requirement for sanitizing Protected media.

SECUREERASE with ERASEPASS=18 meets the requirements for sanitizing media by completing six passes of three cycles of overwriting with a pattern, and then its complement, and finally with another unclassified pattern (for example, “00110101”, followed by “11001010”, and then followed by “10010111” (three cycles).

VERIFY

Some erasure guidelines require that the erasure be verified by checking a percentage of the erased DASD. The VERIFY function of FDRERASE can be used to meet this requirement. VERIFY will read selected tracks from the specified volumes and verify that the tracks contain either no records or a full-track record created by FDRERASE. By default, it samples the last track in every cylinder on the volume, but you can direct it to sample more tracks, up to the entire volume.

VERIFY meets the DoD requirement for “verifying” the DASD were actually erased.

Erasing Modern DASD

All modern DASD subsystems use internal fixed-block architecture (FBA) DASD to emulate the count-key-data (CKD) DASD that are used by z/OS systems. Every DASD vendor has a different scheme for storing the emulated CKD data onto the FBA DASD, but in most of them, there is a fixed FBA location for each emulated CKD track. FDRERASE is able to overwrite the emulated CKD tracks to make the original data unavailable.

However, there are some considerations:

• The fixed-block architecture (FBA) DASD are usually off-the-shelf DASD that can be removed from the count-key-data (CKD) DASD subsystem and attached to another system as an FBA DASD. Depending on how the DASD vendor has written your CKD data, it may be possible to recover your data directly from the FBA DASD. Running ERASE or SECUREERASE on the CKD volumes makes this difficult or impossible.
• Most modern DASD subsystems are reconfigurable, meaning that the mapping of the emulated count-key-data (CKD) DASD volumes onto the fixed-block architecture (FBA) DASD can be changed. If this mapping is changed, some of your old data may reside in areas of the FBA DASD that are no longer in use. This data may be recoverable if the FBA DASD are removed from the subsystem, so you should run FDRERASE on the CKD DASD volumes involved before reconfiguring the subsystem.
• Most modern DASD subsystems use “hot spares” for the fixed-block architecture (FBA) DASD. If an FBA DASD fails, the subsystem is able to assign an unused hot spare FBA DASD to replace the failed DASD, and recreate the data that was on the failed DASD. Usually the DASD vendor is automatically notified and the failed DASD will be promptly replaced and returned to the vendor for diagnosis and repair. However, your data may still be on that failed DASD, and may be recoverable. FDRERASE cannot access the failed FBA DASD even before it is replaced and cannot erase data on it.

The fixed-block architecture (FBA) DASD used in DASD subsystems usually have a capacity that far exceeds the capacity of the emulated count-key-data (CKD) DASD, so a single FBA DASD may contain many emulated DASD volumes. If the DASD subsystem is using RAID-5 or RAID-10 configurations, then a single emulated DASD is spread across several physical FBA DASD (usually called a “RAID rank”).

When many count-key-data (CKD) DASD that reside on the same physical fixed-block architecture (FBA) DASD or RAID rank are erased at the same time, the contention for the disk heads and data paths may severely degrade the total performance of the FDRERASE job. So, FDRERASE uses hardware queries (which vary by DASD vendor) to identify the underlying physical DASD or rank, and limits the number of active erase tasks on any one underlying DASD or rank (see “MAXEU=” in Section330.5). FDRERASE identifies the vendor, control unit serial number, SSID (Subsystem ID), and internal DASD disk/rank ID (see “Vendor Considerations for Erasing” in Section330.6).

If any of this information cannot be determined, FDRERASE simply uses the z/OS device address of the logical DASD as the ID.

To get the best elapsed time when erasing a large number of DASD, specify many DASD devices on a single MOUNT statement, so that FDRERASE can manage the erase tasks, spreading the activity across various subsystems and internal DASD.

Vendor Considerations for Erasing

EMC

EMC subsystems allow FDRERASE to determine if a given DASD is online to other systems. If the volume has a valid volume label, FDRERASE makes this check and does not allow the DASD to be erased unless it is offline to all systems (you can override this check by specifying ACTIVETARGET=PROCESS but you must be sure that the volume is truly not in use). This capability is not available on subsystems from other vendors.

If you use BCVs (Business Continuance Volumes under EMC TimeFinder), you must be sure that the BCVs are also erased. If the BCVs are ESTABLISHed at the time that FDRERASE is done, they are automatically erased as well. If the BCVs are SPLIT, then you need to run FDRERASE against the split BCVs. If you try to erase a BCV unit that is ESTABLISHed, you get an I/O error (either Intervention Required or SIM (time out)).

For mirrored (RAID-1) DASD, FDRERASE identifies the internal DASD by the physical disk ID for the online DASD and its mirrors. For RAID-10, the RAID group ID is used.

HDS

If you use HDS ShadowImage or FlashCopy to create duplicate volumes, you must be sure that the duplicate volumes are also erased. If the ShadowImage volumes are ESTABLISHed at the time that FDRERASE is done, they are automatically erased as well. If the volumes are SPLIT or SUSPENDed or created with FlashCopy, then you need to run FDRERASE against the duplicate volumes as well. If you try to erase a ShadowImage unit that is ESTABLISHed, you get an I/O error (either Intervention Required or SIM (time out)).

FDRERASE identifies the internal DASD by the RAID ID.

IBM

If you have used FlashCopy to create duplicate volumes, you must erase the FlashCopy target volumes as well. You should terminate any active FlashCopy sessions involving the DASD to be erased; otherwise, the elapsed time of the erase increases substantially.

FDRERASE identifies the internal DASD by the RAID rank ID.

PPRC/HRC/SRDF/z/OS Global Mirror (XRC)

There are special considerations for volumes that have remote copies created by an active PPRC, z/OS Global Mirror (XRC), HRC (Hitachi), or SRDF (EMC) session:

By default, FDRERASE does not erase volumes that have a valid volume label and are in an active PPRC, HRC, or SRDF session; they are bypassed with an explanatory message. An active remote copy may indicate that the data on the volume is still needed, so FDRERASE defaults to protecting those volumes. FDRERASE does not currently test for z/OS Global Mirror (XRC).

If you do want to erase this DASD, you can terminate the remote session and rerun the FDRERASE job.

If you also want to erase the remote copies of the DASD, there are two alternatives:

• If the remote copy session is still active at the time of the erase, you can specify ACTIVETARGET=PROCESS to allow the erase to proceed; both the local and remote DASD are erased. However, this may greatly slow down the erase process since each erase or overwriting track must be sent to the remote control unit.
• If the remote DASD also have a channel connection to the local processor or a remote processor, it is usually faster to terminate the remote sessions and erase the remote volumes directly with FDRERASE.

Verification and Auditing

The standards, regulations, or guidelines that require that the data be erased may also require that you verify that the data was truly erased; this verification may need to be done by another person. The VERIFY and PRINT functions of FDRERASE can be used to perform this verification. Depending on the requirements, it may be adequate to verify only a subset of the erased DASD and only a subset of the tracks on those DASD volumes. By default, VERIFY verifies one track in every cylinder on the selected volumes; this is 1/15th (6.7% of each volume).

Those standards, regulations, or guidelines may also require that records be kept of the DASD erased for a period of time, even after the DASD have been reused or removed, for auditing purposes. You should save the complete FDRERASE job outputs, including the job log (system messages), SYSPRINT (SWAP task messages), SYSPRTxx (subtask messages), and FDRSUMM (one-line summaries) DD statement output.

FDRSUMM contains sufficient detail of the DASD erased, including the type of ERASE function, device numbers, control unit manufacturer and serial number, volume size, and tracks erased or verified. The FDRSUMM output, by itself, may be adequate for record keeping purposes.

FDRPAS Users

With the default of CHECKTARGET=YES, FDRERASE erases DASD devices that were the source volumes of a successful swap, or the target devices of a successful SWAPDUMP. Do not specify CHECKTARGET=NO if only FDRPAS DASD volumes are to be erased.

FDRERASE and FDRPAS both check to be sure that the DASD is not already being used by the other program, so you cannot accidentally erase a DASD that is being swapped, or swap to a DASD that is being erased.

If you plan to erase DASD from a subsystem while swapping other volumes in the same subsystem, be aware that the FDRERASE I/Os may increase the FDRPAS swap elapsed time. We recommend that you only erase a few volumes at a time (MAXTASKS=n) in this case.

If the old DASD subsystem will be sold or returned to the vendor, you should run an ERASE or SECUREERASE to ensure that your corporate data is gone

When swapping volumes with FDRPAS, the source DASD serve as a backup in case of problems with the new hardware. Do not begin erasing data from the old DASD until you are sure that the new ones are operating without problems.

IBMTDMF Product

Users of IBMTDMF need an extra step before the old source DASD from a migration can be erased with FDRERASE. IBMTDMF sets the old source volumes offline but leaves a volume serial filled in the UCB. Validity checks within FDRERASE bypass these DASD volumes because of the volume serial. z/OS allows such a DASD volume to be allocated and used by a job, so FDRERASE cannot be certain that the DASD volume is not in use.

To clear the volume serial from the UCB, you must vary the DASD online to z/OS and then back offline with console commands such as:

{{id name="FDRERASEconsiderations-95_JCL_1010294"/}}

{{id name="FDRERASEconsiderations-1010294"/}}

VARY (3C00-3CFF),ONLINE\\{{id name="FDRERASEconsiderations-95_JCL_1187037"/}}

{{id name="FDRERASEconsiderations-1187037"/}}

VARY (3C00-3CFF),OFFLINE\\

After this operation, FDRERASE selects and erases the DASD. An IPL also clears the volume serials.

You must also specify CHECKTARGET=NO when erasing the source DASD since IBMTDMF leaves a valid VTOC on the DASD with all of the original data sets.

Securing FDRERASE

Since erasing DASD obviously offers the capability of accidentally destroying a great deal of valid data, you want to control who can execute FDRERASE.

If FDRERASE has been installed in a separate load library, you can use your security system to limit access to that library and use STEPLIB to access the library. This method is the simplest and most secure way of limiting the use of FDRERASE.

Whenever FDRERASE is executed, it checks for authority to this security resource:

If you have defined that FACILITY class resource, then only users who have at least READ authority to the resource are able to execute FDRERASE. If you have not defined the resource, then all users are able to erase DASD.

If the job specifies CHECKTARGET=NO, which allows any offline DASD to be erased, FDRERASE additionally checks for READ authority to:

If a user is authorized to FDRERASE.ERASE but not to FDRERASE.ERASEALL, then they are able to erase empty and FDRPAS DASD, but not other offline DASD (jobs that specify CHECKTARGET=NO receive a control statement error).

If the job specifies ONLINE=VARYOFF, which allows online DASD to be varied offline and erased, FDRERASE additionally checks for READ authority to:

If the user is not authorized and ONLINE=VARYOFF is specified, the job fails with a control statement error.

If any of these FACILITY resources are not protected in your security system, then the FDRERASE functions are allowed.

Console Commands for FDRERASE

While an FDRERASE job is running, you can stop it prematurely (before all DASD are erased) or modify the number of ERASE tasks (MAXTASKS=) dynamically with console commands. You can also display the status of running erase tasks.

To stop FDRERASE, issue the STOP(P) command with the name of the FDRERASE job:

FDRERASE terminates as soon as all DASD currently being erased have terminated; no new DASD is started.

To dynamically modify the value of MAXTASKS= (the number of concurrent ERASE tasks), issue the MODIFY(F) command:

If you are increasing the current value of MAXTASKS= (to a maximum of 64), FDRERASE starts new ERASE subtasks if it has DASD that have not yet started. If you are decreasing MAXTASKS=, FDRERASE eventually reduces the number of active ERASE tasks to the new value; this may take a few minutes.

To display the status of active erase tasks, issue the MODIFY(F) command

This responds with message on the console and in the job log of the FDRERASE job in a format similar to that displayed by the FDRERASE ISPF displays, for example,

Display Status of Active Erase Tasks (F job,STATUS)