Following was contributed by (Rey LeClerc) at rey@mass-usa.net Part 2 of 2 other fields which can be used to provide authentication of User-IDs not using passwords. They are: PROGRAM - a certain program is issuing the job and inserting a User-ID. SUBAUTH - the program submitting the job must be an APF authorized program. This assumes APF authorization is adequately controlled, because if it is not, ACF2 cannot be relied upon. SOURCE - the physical location the job is submitted from may be an appropriate control. The most desirable control is to use a PROGRAM and SUBAUTH. The program may be masked, provided the mask is specific enough not to include programs which should not be used. PROGRAM without SUBAUTH is practically useless, because any program can be renamed or copied to a personal library to be used for job submission. SUBAUTH without PROGRAM is equally ineffective, since there are many APF authorized programs which could be used for job submission (i.e. IEBCOPY, WAAPSPLT). SOURCE could be a good control, provided the SOURCE is a physically secured location. SOURCE is only as good as the physical controls to that source. An example of a situation where SOURCE may be practical would be an RJE station, where jobs submitted from a single line or terminal is physically separate from the rest of the system. Some examples of poor controls would be INTRDR or STCINRDR, the system internal readers. These are the sources used for by all batch jobs or started tasks for submitting other jobs. These can be used by any job or STC and should never be considered a controlled SOURCE. Another commonly misused source is READER1. This is a card reader, normally in the computer room. Anyone with physical access to this reader can initiate jobs on it. Review a listing of User-IDs with RESTRICT to ensure that controls are adequate to ensure on valid usage of the User-IDs. Note that User-IDs used for STC although they do not have a password, do not need the RESTRICT attribute, and if it exists, it is ignored. Pay special attention to the programs specified. The program should insert the User-ID in the JCL based on some pre-defined criteria. It should not allow the user to insert his own /*LOGONID card. The listing can be generated by using an ACFRPTSL against the backup files as follows: IF(NOT STC AND RESTRICT AND NOT CANCEL AND NOT SUSPEND) SF(SUBAUTH,PROGRAM,SOURCE) 3. Using the "LIST IF" command or the SL report, determine who has the SECURITY or the ACCOUNT privilege. These powers should be restricted to 2 or 3 persons, or else limited by the person's DSNSCOPE, UIDSCOPE, or SCPLIST if the unit has decentralized administration. Systems programmers should never have either attribute. Verify users with SECURITY and/or ACCOUNT privileges are responsible for daily administration of Data Security. SECURITY privilege allows the User-ID to change certain fields of the User-ID record, make changes to the dataset rules and change the information storage database. SECURITY privilege does not allow adding or deleting User-IDs. ACCOUNT privilege allows the User-ID to change certain fields of the User-ID record and allows for adding and deleting User-IDs on the User-ID database. ACCOUNT privilege does not allow for writing rules or changing info storage. Generally, Data Security users are given both privileges to perform their job function. These privileges can be given to users outside of Data Security provided they are adequately controlled to limit the changes made to only their scope of responsibility. A SCPLIST reference can be attached to any user with SECURITY or ACCOUNT privilege. The SCOPE includes a limitation of LOGONIDs, UIDs, DATASET rules, and/or INFO STORAGE records. Any combination of these can be used to limit what a user can do with these privileges. Make sure that all User-IDs with these privilege belong to users with a data security responsibility. Also ensure that any users outside of Data Security have been appropriately scoped to limit their privilege. 4. Using the "LIST IF" command or the SL report, determine which User-IDs have the NON-CNCL attribute. No more than 3 or 4 such users should be found, and these should be used for emergency purposes (e.g. started task ids) only. In addition, their usage should be reviewed. Determine how NON-CNCL and READALL is being used. These should not be used except on an emergency basis only. Emphasis should be placed on evidence of review of activity of these privileges rather than on numbers. ACF2 has a couple of privileges which can override the recommendation to prevent an access due to a violation. The privileges have in the past been abused and distributed without consideration to what the significance of the privileges granted are. The NON-CNCL privilege is the most powerful of these privileges. It tells ACF2 that regardless of the violation, no access is to be prevented. A log is generated for each situation which would have caused a violation, but no prevention will ever be invoked. Although this is normally only considered in the dataset environment, any resource validation such as CICS or IMS transaction, will also be allowed and logged. Similarly, the READALL privilege grants the user the authority to open any file for READ or EXEC regardless of the rules. This privilege also logs any use of datasets which would not have been allowed by rules. READALL, unlike NON-CNCL privilege only applies to dataset rules. The use of READALL by any user with NON-CNCL privilege, should never be criticized. The advantage of giving a user with the NON-CNCL privilege, the READALL privilege to, is that the resulting logs can be split based on what was done. If the access was a READ, the report would describe the reason as, READALL, while all others would be NON-CNCL. This would provide for more emphasis being placed on the more significant logs (changes). One more privilege which should be considered is the SECURITY privilege. Security is described by ACF2 as being able to change any rule or User-ID and as such could give itself access to any dataset or resource without external intervention or approval. For this reason, early releases of ACF2 gave the SECURITY privilege a power equal to NON-CNCL. Some time later, requests were made to control SECURITY so that it had to follow the rules like any other id. The rational behind this was based on the idea that SECURITY officers can make mistakes like anyone else. By having to follow the rules, any inappropriate access made by the SECURITY officer, had to be intentional and an overt action had to be made, but any accidental access would be prevented as normal. To do this a new privilege was added, the RULE-VLD privilege, which forced SECURITY to be like any other id where dataset access was involved. Unfortunately, SECURITY is still NON-CNCL implicitly for any other resource. It is important to review the justification for and the use of NON-CNCL, SECURITY without RULE-VLD and READALL. These privileges must be approved by the data center manager, the users' manager and the system owner. The reason should be specific. The privilege should seldomly be on the primary User-ID and reports generated by their use should be reviewed daily to ensure compliance with the defined need for the privilege. There should be evidence that the reports are run on a timely basis and that they are reviewed by the user's manager for appropriateness. A periodic cursory review should also be performed by Data Security to ensure that the intended purpose of the privilege is not being abused. 5. Using the "LIST IF" command or the SL report, examine all User-ID records to determine that no user has a "SYS1" prefix, as this would allow them complete access to all system files, including ACF2 files. Similarly determine that no user has asterisks specified. Review User-IDs with a PREFIX different from the User-ID. Verify that no user has a PREFIX of "********", "ACF*" or "SYS*". The PREFIX field is one of the most powerful privileges available to ACF2. This field describes to ACF2 the high-level index which you own. ACF2 will not validate any access to datasets which begin with a high-level equal to the high-level defined in your PREFIX. No logging will be generated. No violations will occur, regardless of the rules. This field is of concern, because it can contain a mask. If the mask is all "*" then the User-ID is NON-CNCL with NO logging. If the mask is for some sensitive datasets, such as ACF* or SYS*, the integrity of the system is in question. If the mask is for anything other than the User-ID, it should be closely examined, to identify what can be accessed without rules. Some valid reasons for the mask to be different from the User-ID include: o the user has 2 User-IDs and the PREFIX points the second to the datasets generated by the first; o the PREFIX may be blank, indicating that nothing is OWNED by this User-ID. Rules are required for all access; o groups of users may share a single high-level, but don't want the overhead of rule writing and logging. The listing can be generated by using an ACFRPTSL against the backup files as follows: IF(PREFIX NE LID AND PREFIX NE " ") SF(PREFIX) 6. Using the "LIST IF" command or the SL report, determine which User-IDs have the RESTRICT attribute. Verify that these User-IDs have SUBAUTH specified, as well as, the PGM and LIB parameters, to ensure that their usage is via an APF-authorized program from a controlled library. 7. Using the "LIST IF" command or the SL report, examine which users have the REFRESH attribute. These users are allowed to dynamically activate GSO options. Determine how the REFRESH attribute is controlled. User-IDs with this privilege may have their password exposed when using the privilege. The REFRESH privilege is used to cause changes to the GSO records to be invoked dynamically, without requiring an IPL. The privilege does not grant any authority to change any parameters, simply to invoke parameters already defined. When a modify command is issued, the system requests a User-ID and password be entered on the console issuing the modify command. ACF2 then verifies the User-ID has the REFRESH attribute before allowing the modify to be performed. The main concern that we should have with the REFRESH privilege is that it can invoke any GSO record which has been previously defined. So if there is a record with a MODE of quiet, any user with the REFRESH capability could invoke that GSO record dynamically. The secondary concern with REFRESH is that the User-ID and password are entered in a displayable field and can be seen by anyone in the vicinity. The password for User-IDs with REFRESH privilege are more subject to being observed than any other password, because when entered, it cannot be entered in a non-display field. Any User-ID whose password cannot be relied upon should never have any powerful privileges attached to them. For these reasons, the most practical way of controlling the REFRESH privilege is to assign it to a single User-ID and given to the Operations manager to control. It's his system and REFRESH controls when ACF2 operating parameters are changed. The id should have NO other privileges, such as NON-CNCL, SECURITY, TAPE-BLP, or READALL. The id should not have any other system authority, such as TSO, IMS, CICS, or JOB. The UID should not match any file access (i.e.. the UID fields should all be blank). A listing can be generated by using an ACFRPTSL against the backup files as follows: IF(REFRESH AND NOSUSPEND AND NOCANCEL) SF(REFRESH,UID) 8. Using the "LIST IF" command or the SL report, examine all User-ID records to determine which users have the MAINT attribute. These users are allowed to execute any program defined in MAINT GSO. 9. Using the "LIST IF" command, examine all User-ID records to determine which users have the TAPE-BLP attribute. These users are allowed to a tape data set without rule verification. Determine if TAPE-BLP is used to gain access to tape files. Only the Tape librarian has an ongoing need for this privilege. The ability to use LABEL=(,BLP) is controlled by ACF2 to ensure that only users with this privilege can use the privilege. The TAPE-BLP privilege is assigned to individuals. Earlier in this handbook, the BLPPGM was described. In this area, the individual's authority to use BLP to access any tape, using any program is reviewed. >From a listing of all User-IDs with the TAPE-BLP privilege, determine the appropriateness of the privilege, by referring to the authorization maintained by data security. Each occurrence of the privilege is to be approved by the Operations Manager of the data center, with a reason for its need. In most facilities, the Tape Librarian has a justifiable need for the privilege. Often the Software groups, especially, the Tech Support groups feel they need the privilege because they are constantly receiving files from vendors and have no way of knowing the filenames on these tapes. The files received from the vendor should be quite limited and may be handled with a short term request for TAPE-BLP privilege. In most cases, TAPE-LBL, which is a limited TAPE-BLP privilege will suffice. TAPE-LBL allows the user to use BLP, but if the label is a Standard label, will validate the user's authority to use the file anyway. The listing can be generated by using an ACFRPTSL against the backup files as follows: IF(TAPE-BLP AND NOSUSPEND AND NOCANCEL) SF(TAPE-BLP,NON-CNCL,UID) 10. Determine the appropriateness of users with the OPERATOR privilege. This privilege on its own has little implications, but many products like SDSF, and JES2 use the OPERATOR authority to give higher authority within their product. Originally, OPERATOR privilege was a TSO attribute which allowed users to issue Status commands and Cancel commands. Very little significance could be attached to users with this privilege. Determine the appropriateness of the user's with OPERATOR privilege. Verify that each occurrence of the privilege has been properly authorized. Verify that all users with OPERATOR are system software people, or have data center operations responsibility. Note that there is no limitation as to what can be canceled by the users. Messages showing the cancellation of jobs do not include the User-ID of who did the cancel. If a review of SDSF and/or JES2 is not being conducted during this audit, it is important to evaluate the additional privilege provided by these products. Both products usually give any user with OPERATOR full console authority, with the ability to issue most console commands, including starting started tasks and issuing modify commands. These are some of the main reasons for limiting physical access to the computer room in the past. By requiring people in the software groups be escorted in the Computer Room, the Operations manager has control of commands issued on the console which could effect the operation of his system. In the near future NetView will have similar capabilities. Some of these may not even need the user to have OPERATOR! The listing can be generated by using an ACFRPTSL against the backup files as follows: IF(OPERATOR AND NOSUSPEND AND NOCANCEL) SF(OPERATOR) 11. Generally, IMS and CICS User-IDs have no need to run in batch. Review the User-IDs defined as IMS or CICS User-IDs with the JOB attribute. These User-IDs can be used in batch jobs if rules are written to give access to data. The JOB attribute is the privilege comparable to the TSO, IMS or CICS attributes which determine if the User-ID is allowed to run TSO, IMS or CICS. JOB determines whether you are authorized to use the batch environment. JOB is validated only if JOBCHK has been initialized in the OPT parameter in the GSO. JOB is particularly important in an environment where there are a large number of users requiring access in an on-line environment only. These users can be prevented from using their User-ID in batch jobs if they do not have the JOB attribute. If the JOB attribute is not being used, we do not necessarily have a problem. Determine if the organization depends on users not being able to use batch, as a control. An environment which claims to have ACF controls to prevent access in batch, but do not use JOB with JOBCHK, is not fully controlled. 12. Review User-IDs with the JOBFROM attribute. Verify that these User-IDs are also defined as MUSASS. Determine how User-IDs are inserted in the jobs submitted by these regions. User-IDs are used to identify users of the system to ACF2. ACF2 verifies the identity of each user by requesting a password known only to the valid user. Sometimes, when production jobs are being submitted, a password is impractical. In these cases, the identity is verified, by determining the program used and the authorization of the program (SUBAUTH). On rare occasion, SOURCE may also be used to verify that the User-ID is appropriate. In a multi-user environment (MUSSAS), there is another unique requirement to have a User-ID approved for use by ACF2. In a MUSASS like CICS, ACF2 only knows the identity of the region. If a job is submitted by a user of the region, ACF2 has to be told by the region which User-ID is to be used. It is impractical to require each user to include a password when submitting a job. A feature has been designed to allow a MUSSAS to pass a User-ID to jobs using the JOBFROM statement. FORMAT: /*JOBFROM T2HJWJV Since anyone could insert this in their JCL, an additional privilege was added to allow a MUSSAS to use this (JOBFROM). JOBFROM tells ACF2 that this User-ID has already been validated within the region or job. This review, is intended to verify the appropriateness of the JOBFROM attribute. Only User-IDs with the MUSSAS attribute should have the JOBFROM attribute. Review how the JOBFROM User-ID is determined. If the user is allowed to insert his own /*JOBFROM, there is a significant exposure. Imagine, a TEXT user being allowed to insert a JOBFROM User-ID of any User-ID he wishes. ACF2 would assume the User-ID is okay since the CICS region has the JOBFROM attribute. NOTE, TEXT has an appropriate job submission routine which inserts the user's own User-ID only, in the JOBFROM record. TEXT should only be a concern if the region is not controlled by ACF2. If JOBFROM is on an id which is not a MUSSAS, review the source of the job doing the job submission to determine how the /*JOBFROM record is generated, and how the User-ID is validated. 13. Review User-IDs with the NO-SAF attribute. Verify these User-IDs are also defined as MUSASS and STC or RESTRICT. User-IDs with the NO-SAF attribute can access data via program products using SAF (e.g. DFDSS, DFHSM, BDT) without validating dataset rules. Products using explicit ACF2 interfaces like CICS or IMS will call ACF2 for dataset rule validations, unless NON-CNCL or MAINT was also granted. Compensating controls for MUSASS User-IDs such as STC or RESTRICT (with SUBAUTH and PGM, or SOURCE) should be used. Rules for System Software Purpose: To review the ACF2 access rules for system software. 1. Use the DECOMP command to decompile the SYS1 rule set. Review the ACF2 access rules to determine that the ACF2 distribution libraries can only be accessed by the system programmer(s) assigned to ACF2 support. The integrity of ACF2 among other things depends on the adequacy of rules over the ACF2 distribution files. These datasets need to be protected against unauthorized modification and only people with a business need to know should be able to read them. The MACRO libraries contain file definitions (SYS1.ACFMAC). These file definitions give enough information to give users with access to APF libraries the ability to bypass ACF security. Note that many of the datasets have 2 versions of the information. SYS1.ACFMAC and SYS1.ACFAMAC are identical versions of each other. Access to both should be strictly limited and should be similar. 2. Determine that libraries containing ACF2 load modules are adequately protected. Write and Allocate access to the production version should be logged and restricted to emergency situations only. This aspect of the ACF2 program need not be reviewed if MVS is also being reviewed. The ACF2 load libraries are in 'SYS1.LPALIB' and 'SYS1.LINKLIB'. If this review is a stand-alone review of ACF2, it is important to determine the adequacy of controls over the programs running ACF2. Review the rules to determine who can modify the system datasets and 'SYS1.ACFMOD' and 'SYS1.ACFAMOD'. Only the system program responsible for the MVS system and the ACF2 software should be able to change these libraries. Only the ACF2 systems person should have write authority to the MOD libraries (these would also be reviewed in question 1 of this section). ACF2 security is only as good as the software used to run it. If the software can be indiscriminately modified, ACF2 cannot be relied upon. 3. Determine if any user other than Data Security can change the rules for SYS1 or ACF2 by the use of %CHANGE and %RCHANGE. The rules for SYS1 or ACF2 are reviewed in this section to ensure that current controls are adequate to ensure the integrity of the ACF2 system. When ACF2 is controlled Centrally, only SECURITY privilege can change rules, unless the %CHANGE record is present in the rule. If current controls are adequate and the %CHANGE is present, there is no assurance that they will stay adequate. If it is not present, only SECURITY users can change the rules, and adequacy of change controls over rules are covered later in this review. In reviewing the rules for %CHANGE, its existence does not imply there is a problem. The User-ID mask should be reviewed to determine the appropriateness of users with the ability to make rule changes for system and ACF2 files. Normally, only Data Security can change rules. No other group has a job responsibility to do so. 4. Determine that the System Management Facility (SMF) files (SYS1.MAN*) used for ACF2 logging are adequately protected. WRITE and ALLOCATE permission should be limited to emergency situations only. Allocate permission should be logged and restricted to the system programmers responsible for SYSGENs. Ensure that the same level of protection is present for the dump datasets, both tape and disk. ACF2 uses the System Management Facility (SMF) files to store information used for an audit trail. All ACF2 logging is stored on the SMF files. The information needed to restore the current database is stored on the SMF files. The change history is stored on SMF. All reports produced by ACF2 come from information stored on SMF. As a result the information here must be carefully controlled to ensure that no one can change this information. Keep in mind that if there are system problems relative to SMF data, someone has to be able to fix it. The backup files or the files used to store SMF after it is dumped should be as closely controlled as the live files. Ask the system programmers to identify the datasets names for all versions of the SMF data. Review the rules for all of these. If SMF is covered in MVS review, it may not be necessary to cover it here. Ensure that the files reviewed in MVS, include all collected SMF. 5. Ensure that ACF2 rules grant access on a need to know basis. ACF2 rules are generally written based on the data owner's requests. Data Security should always write access rules as requested. However, if a customer requests access which is obviously not limited to only user's with a defined need to know, Data Security has an obligation to inform the customer of the consequences of the general access granted. Data Security also writes rules for new TSO users. A default set of rules is written unless otherwise specified. Review these default rules to determine if access to user's libraries is limited on a "need to know" basis. 6. Determine the names of the production systems libraries, APF libraries, IMS and other production program product libraries, and production JCL libraries. Ensure that controls over these resources are adequate. This is normally covered in the MVS review, but should be covered here if MVS is not being reviewed. The adequacy of ACF2 depends on the integrity of MVS to be intact. MVS integrity has been assured by IBM provided mechanisms under the users control are adequately controlled. APF authorization is one of the main bypass mechanism under the users control. Other powerful libraries (normally APF authorized) include IMS and production load libraries. Determine that the ACF rules limiting access to these authorized libraries are reasonable. The libraries used to contain JCL for production jobs should also be closely reviewed to ensure the appropriateness of production jobs being used. 7. Check the GSO OPTS record, NOSORT fields. If NOSORT is in effect, verify that all rule sets containing a $NOSORT control card accurately reflect access permissions. If NOSORT=NO is in effect, there should not be any $NOSORT entries. ACF2 ADMINISTRATION Purpose: To review the adequacy of ACF2 administration. 1. Review the controls over changes to the ACF2 databases. Ensure that all changes are properly authorized. Verify that a management review of changes to ACF2 is conducted to ensure only authorized changes are performed. The ACF2 database can be updated only be user's with the SECURITY privilege. Data Security requires all changes to be supported by an authorization from the owner. The intent of this audit step is to perform a review of changes made to the ACF2 databases to ensure that all changes are authorized. To do this, perform the following: o Determine what change controls are in place to ensure only authorized changes are included. Specifically, if changes are made to the rules (dataset or resource), using a stored copy of source rather than a decompile just previous to the change, determine what controls are in place to ensure: o there is only one copy of the source; o no other changes were made to the source by some other user (trojan horse); o no changes were made to the database using ACFNRULE command or decomp and store; o only authorized users can write to the source file. In essence, if a PDS containing original source is being used, there should be a change control procedure similar to that used for production program change controls for all changes to the ACF2 rules. o If all changes have been properly authorized, there should be a way of referencing the authorization when the change occurs. Take a sample of changes (explained below) and request the Data Security administrator to provide you with the authorizations. o Determine if there is a management review of ACF2 change reports conducted. There should be a daily review by management or an independent party to ensure changes to the databases are authorized. It doesn't make sense to review all changes daily, but a reasonable sample of changes made should be done, at least weekly. This would be even more significant if during the sample done above, any situation was identified which did not have supporting authorization. The reports that should be reviewed by an independent person includes: ACFRPTLL - User-ID Modification Log - identifies the fields that were changed, if DETAIL was requested. ACFRPTRL - Rule-id Modification Log - identifies the rules that were changed and by who. Currently, no detail is available in this report (Planned for a future release). However, ACFRPTIX can be run to show full detail resulting from a given modification. ACFRPTEL - Info Storage Update Log - identifies the resource rules, ENTRY's, GSOs, SCOPEs, and SHIFTs changed. If DETAIL is requested the fields changed will be displayed were possible. To sample the changes, run each of these reports using the collected SMF for a sample period. One week, just prior to the review period should be sufficient. Additionally, the Data Security group should be reviewing the following reports: ACFRPTJL - Restricted User-ID Job Log - identifies usage of User-IDs without passwords. Should be examined to determine appropriateness of usage; ACFRPTPW - Invalid Password Authority - identifies invalid attempts to sign-on. Should be used to identify any attempts to hack the system. 2. Determine that Data Security is reviewing and actively following up potential problems with ACF2 logging and violation reports for: o abuse of privileges; o attempted hacking; and o conversion to ABORT mode. Data Security has a responsibility to review the reports caused by logging or violations. Primarily, logging should be reviewed to determine if there is an abuse of privileges granted, such as EID, NON-CNCL, READALL, or SECURITY. Additionally, if the logs are as a result of a conversion, these logs should be reviewed to ensure the timely completion of such plans. The violations should also be reviewed by the Data Security group for several reasons. Violations are the result of failed attempts to access information. Data Security should be using this as an indication of problems in ACF2 administration, to determine their effectiveness. They should also use these to determine if there was a breech of security. Trends in attempted access should be observed. A series of violations on sensitive datasets indicate a possible fishing expedition. It should be noted however, that the violations are accesses which did not happen, while the logging are for things that did happen. User Exits Purpose: To review ACF2 user exits. 1. Using the SHOW ACTIVE command, determine which exits are in use on each system. Review the source code for each. Cross reference compile date and load module size with SYS1.LPALIB contents. Note any discrepancies. There are now 19 exits available for a site to alter the way in which ACF2 works. Each of these exits can be used to bypass the security mechanisms in the system if inappropriately written. The auditor should review the source for each module and verify that the source matches the load module. EXIT usage can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST EXITS END 2. Review the source for any exits in use to verify they perform as intended. Verify the exit usage is well documented as to the purpose and effect on the system. If any exits are in use and the source listing has been verified to be the original source, review the source to ensure that it is functioning as intended. Any exit in use should be explicitly documented as to the purpose of the exit and what the exit does. If it isn't, the site cannot be assured of the integrity of their security system. Remember, any exit can be used to circumvent the controls in ACF2. Other Products Under ACF2 Purpose: To review other products that relate to ACF2. 1. If Innovation Data Processing's Fast Dump Restore (FDR) is used, determine if the ACF interface is being used to verify authority to access information. FDR and FDRDSF are products which are used to dump and restore information at a volume level and/or a dataset level. When a disk is dumped at a volume level, FDR bypasses normal open. This gives the user the ability using FDR to dump onto a tape he has access to any file on any volume. The Dataset Facility allows any user to restore any file previously dumped, to any file he has write access to. ACF2 validation only occurs on the file being written to. This facility therefore gives the user the ability to get READ access to any file regardless of ACF2 rules preventing it. The ACF2 vendors recognized this weakness some time ago, and have developed an interface which provides additional levels of control. Before allowing the user to dump a volume, the interface determines the users authority, by calling ACF2 to validate access to VOLUME.@volser (or @volser.VOLUME, depending on options selected). When restoring a dataset, the interface verifies the user's authority to read the original dataset name given in the control parameters, before allowing the file to be restored. To determine if the ACF2 interface has been implemented, BROWSE the load modules for the FDR.... programs, looking for references to ACF. If they don't exist, the interface has not been installed. It may also be prudent to look for rules for VOLUME or @volser. If these are not present, the interface should be questioned (determine how access is allowed). However, similar rules are used in other interfaces, so the existence of them does not imply the interface is installed. Some installations have protected the FDR programs using an exit to validate usage of programs. Others have put the FDR programs in a fully protected library to limit their use to only appropriate DAMART users. This may be an acceptable alternative to using the exit provided the controls prevent copying to another name and library. 2. If Cambridge Systems Group's ASM2 is used determine if the ACF$AUTH code is present. Verify that only authorized ASM2 commands are present. Cambridge Systems Group (now Computer Associates) have developed a Space Management System which provides archive and retrieval mechanisms to make maximum use of storage space. ASM2 performs tasks on behalf of the user, bypassing user authentication. ASM2 was distributed by the same group as ACF2 and has been distributed with an ACF2 interface which performs additional ACF2 calls to ensure the user is authorized to perform the tasks requested. The ASM2/ACF2 interface is distributed as a Selectable Unit and must be installed to make it work. If ASM2 is being used, interview the MVS group, the Utilities group and the DAMART group to determine if the ACF2 interface was installed during the last distribution implementation. 3. If Sterling's Disk Management System (DMS/OS) is used, determine if the vendor supplied ACF2 interface has been applied. Sterling's Disk Management System is designed to provide programs to archive and restore datasets on the system, making more efficient use of the disk space available. To do this, DMS/OS runs as a sub-system or Started Task and needs access to all data on the system. When a dataset is aged sufficiently, DMS/OS programs remove the dataset from the disk and store it on a tape file. If the dataset is required, DMS/OS programs retrieve the data from the tape and restore it on disk. Some additional features allow for a dataset to be renamed during the retrieval process. Since DMS/OS does all of these functions on the user's behalf, the user's authority to access these dataset names is never validated by ACF2. This allows a user to access a file which has been archived and restore it to his high-level, even if he does not have access to the original file. Sterling has recognized this weakness in their product and has created an additional Selectable Unit. The site must specifically install the SU to take advantage of this feature. The SU performs some additional ACF2 calls to ensure the user's authority to access both the original and final datasets before any action is taken by DMS/OS to archive or restore files. 4. If IBM's Hierarchical Storage Manager (DFHSM), Data Set Services (DFDSS), or Bulk Data Transfer (BDT) are installed and not protected by PGM resource rules, verify SAFPROT entries are present. These three IBM program products require a SAFPROT record for dataset rule validation to occur (regardless if SAF VALIDATION = ON and no generically masked SAFSAFE record exists). The SAF PROTLIST entries can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST LIKE(SAF-) END Entries should resemble the following: SAFPROT.DFDSS CLASS(-) CNTLPT(ADR-) SUBSYS(ADR-) SAFPROT.DFHSM CLASS(-) CNTLPT(ACR-) SUBSYS(ACR-) SAFPROT.BDT1 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC019) SAFPROT.BDT2 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC099) SAFPROT.BDT3 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC109) SAFPROT.BDT4 CLASS(-) CNTLPT(BDT-) SUBSYS(BDT-)