Following was contributed by (Rey LeClerc) at rey@mass-usa.net Part 1 of 2 ACF2/MVS (Access Control Facility) Security System Purpose: Determine whether the ACF2 software has been appropriately installed in the MVS environment. Determine if access to system software, files and commands is controlled and appropriately restricted. Determine if chosen exits permit circumvention of intended controls. Overview ACF2 was developed by Schrager Klemens and Krueger, Inc. (SKK) for large IBM computers. Computer Associates currently markets the product. (Cambridge Systems Group, Inc. originally marketed ACF2. UCCEL Corporation bought them out and were, in turn, bought out by Computer Associates in 1987.) ACF2 supports the MVS, VS1, VM, and VSE operating systems and the TSO, JES, CICS, IMS, and IDMS subsystems. The current ACF2 version is release 5.0 for MVS environments. ACF2 acts as an interface between users, programs and data, and "defined resources" to provide a mechanism by which data access and manipulation take place in a controlled environment. Defined resources are those components under ACF2 control, such as programs, Customer Information Control System (CICS) transactions, and Information Management System (IMS) transactions. ACF2 protects all data by default. This means that access to the system by anyone besides the "owner" is only possible when authorized by the data owner or by a security officer. Each system user is identified to ACF2 by a unique "User-ID." The User-ID provides individual accountability for all system activities. ACF2 also creates a User-ID record, which contains information about the user--such as name, privileges, type of user and statistics about the user's activities on the system. In this way, ACF2 can play an important role in implementing controls over access to programs and data files. ACF2 also provides audit trails and reports on who accessed what data and on the maintenance of the security system. These can be supplemented by other types of information retrieval software. ACF2 places intercepts in the MVS and VS1 operating systems and in the subsystems. Requests for access to resources is evaluated using ACF2 access and resource rules. Access is either allowed or denied and a SMF record is created if logging is specified. Control is then passed back to the operating system and subsystem originating the request for access. There are three ACF2 data bases (VSAM key sequenced data sets): User-IDs, Access Rules, and Information Storage. The User-ID data base controls system access validation. Users are defined to ACF2 via a unique User-ID record that specifies the user's privileges, TSO attributes, and access history. User-ID record fields are defined in the ACF2 Field Definition Record (ACFFDR). Fields can point to records in the Information Storage data base. The Access Rule data base contains one record (rule set) per high-level index (qualifier) for each data set. The rule set defines the conditions for access to data within that high-level index. The levels of access allowed are READ, WRITE, ALLOCATE, and EXECUTE. Each type of access may be allowed (A), allowed but logged (L), or prevented (P). The default is prevent. The Information Storage data base identifies input sources (terminals), identifies privileged user scopes, contains rules to control access to resources (i.e.., IMS, CICS, and IDMS), and contains Global System Option (GSO) records. GSO records specify all system-wide options except those defined in the ACFFDR. Source of ACF2 information: Coopers & Lybrand Software Newsletter, Volume 4, No. 1, Spring 1984, "Exploring ACF2", pp. 15-17. ACF2 Auditors Guide ACF2 Administrators Guide MIS Training Institute The 7th Annual Conference on Control, Audit and Security of IBM Systems, "Reviewing the Implementation and Administration of ACF2," Session 38, presented by James Richardson, Senior Internal Review Analysis, Ford Aerospace & Communications Corporation. Components of ACF2 Purpose: To ensure that components of ACF2 are adequately installed. 1. Review the catalog entry for the primary ACF2 databases. Use TSO "LISTC ENT(dsn) ALL" to determine that each component is: o uniquely named; o adequate size; o periodically reorganized; and o NOT VSAM password protected. The dataset names for the databases can be found by issuing a SHOW DDSN or SHOW ACF command under TSO on any of the shared systems. To view the condition of the VSAM files it may be advisable to put the results of the LISTC into a dataset. To do this do the following: o create a dataset using TSO ISPF 3.2 o RECFM=VBA o LRECL=255 o BLKSIZE=6250 o DSN=acf.listc (any dataset you choose) o In function 6 of ISPF, allocate the file as follows: o ALLOC FI(DD1) DA(acf.listc) MOD o Perform the catalog list for each of the Primary Databases o LISTC ENT('ACF2.RULES') ALL OF(DD1) o LISTC ENT('ACF2.LOGONIDS') ALL OF(DD1) o LISTC ENT('ACF2.INFOSTG') ALL OF(DD1) By Uniquely named, we mean: o The DATA and INDEX components should be explicitly defined with a explicit name; o The high-level of the databases should be different from any other VSAM files; and o The definition of the VSAM files should have specified the attribute UNIQUE. The need for a unique name comes from the ability to control access to the VSAM files. If the DATA and INDEX components are not explicitly defined, access to the databases can be attained by the VSAM default names beginning with Z9999992 or Z9999996. If the high-level of the dataset name is the same as some other VSAM files, the access controls become very difficult to administer. If the VSAM file was not defined with the UNIQUE attribute, the VSAM cluster may be shared by other VSAM datasets and the possibility exists that data sharing could also exist. The adequacy of the size of the database is very subjective and should be evaluated using the following formula: From the LISTC for each file, get: o HI-ALLOC-RBA assign it to A o HI-USED-RBA assign it to B o CISIZE assign it to C Formula is (A - B) / C ___________ = # of unused tracks 11 if the database is on 3350 disk replace 11 with 4 in the formula. If the database is not large enough, the database will have to be reorganized more frequently. An indication of size problems will be a high number of CA/CI splits. This is also an indication that the database is not reorganized frequently enough. The CI split number can be significantly higher without concern than the CA splits. CI splits over 1000 or CA splits over 100 should raise some concern. However, the numbers alone should only be an indication of a problem. If a database is reorganized regularly and these numbers are still high, the problem is either a very high volume of activity, or the database may need to be differently defined. Regular reorganization if important to ensure the availability of ACF2. VSAM errors have been shown to increase significantly if CA and CI splits are high. Without reorganization, the possibility exists that a user may not be able to be added. This problem occurred frequently when NETIDS were all being added as ids. The VSAM keyed dataset was evenly distributed among all User-IDs. When a large number of ids are added in the same range, there are a number of CA splits which occur. After a number of splits, no more splits can occur, resulting in some specific ids not being able to be added. VSAM passwords are a valuable feature to enhance the security controls of a VSAM space. VSAM passwords are frequently used to control access to files that are not always in an ACF2 controlled environment. There is a tendency to try password protecting the ACF2 VSAM files to ensure they are protected when ACF2 is not active. However, if a password is used, the recoverability of a database, may be severely impacted if the password is not known by the operations staff. If the password is known by the operations staff, the desired effect of controlling access is lost as the potential accessors are the operations staff. 2. Repeat the above review for the Alternate databases. The Alternate databases should be identical to the Primary, with the following exceptions: o The Alternate files could be allocated with less free space than the primary, since the Alternate should never be used productively for long periods of time in which many inserts are processed; o The Alternate file names should be different from the Primary. The high-level index should be different and on a different catalog. This would allow the alternate files to be used in the event that a catalog error occurred. o The Alternate files should reside on a different volume than the Primary. This volume should ideally also be attached to a different controller. This would ensure the availability of ACF2 in the event of either a Volume error or a controller error. o If the files either Primary or Alternate are being backed up using FDR, it is advisable for the catalog to be on the same Volume as the VSAM space. The catalog entry for a VSAM space much be in sync with the file itself, otherwise, the VSAM file may not be usable. Alternative clusters may include SYS1. ACF2. ALTLIDS, SYS1.ACF.ALTRULES, and SYS1.ACF2.ALTRULES. (Note that they may be under a different high level index). 3. Examine the SYS1 (or appropriate high level index) rule set to determine if the three non-VSAM backup data sets (SYS1.ACF.BKLIDS, SYS1.ACF.BKRULES, and SYS1.ACF.BKINFO) are accessible only to ACF2 and the ACFRECVR recovery job (which would be controlled by operations). Verify that the BACKUP and alternate BACKUP files exist. Determine if an automatic backup is performed at about the same time as SMF is dumped. The BACKUP file names used by ACF2 for backup procedures can be found by issuing a SHOW DDSN sub-command of ACF under TSO. These files should exist or the backup procedures may not be effective. ACF2 provides for the ability to automatically backup the ACF2 databases at any time of the day. The GSO BACKUP records describe to ACF2 when to perform the backup and on which machines. BACKUP parameters can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST BACKUP END The recovery procedures for an ACF database requires a reload of the backup file to the VSAM file, and a restore of activity since the last backup using the SMF data collected since the backup. If the SMF data is not dumped at about the same time as the ACF database, the backup procedure will become very cumbersome as some of the recovery information may be on the live SMF files while the rest is on a disk or tape file. This could cause a significant delay in system availability. 4. Determine if the Alternate Clusters are recreated and maintained current using the results of the nightly backup. Verify the automatic procedures exist on a procedure library and are only initiated on one machine per set of databases. The procedure defined in the GSO BACKUP record should exist. Review the system Procedure libraries for this procedure. If it doesn't exist, determine how the site keeps its Alternate files current? If the Alternate files are not kept current, how do they plan to get the system back if a fatal error occurs on the ACF Databases? If an old copy of the primary file has been kept on the Alternate, the site may have a problem using it. Say for example that the Alternate is 2 months old, ask, "what was your password 2 months ago". This normally drives the point home. If it doesn't, suggest that even if they know what their password is, would the hundreds of user's trying to get on know theirs? Review the procedure used to keep the Alternate Clusters current. If the procedure simply restores the backup files into the Alternate Cluster, without first deleting and recreating the datasets, review the contents of the Alternate files (there will be old ids which have been deleted from the Primary). When a VSAM restore is performed, using a backup file, records found on the backup will be replaced. Records on the Alternate files not found on the backups will remain on the Alternates. Therefore, any deletes performed on the primary files will not be deleted from the Alternates. Verify that the backup is performed on only one system. If the backup is performed on multiple systems at about the same time a contention problem may cause problems with system availability. 5. Use the DECOMP command or the cross reference report to check the rules for the ACF2 system files. Verify that the rules allow only full scoped security officers to access the primary ACF2 files, and that write access is not allowed. Review the ACF2 rules for the databases. Ensure that only the ACF2 system support people have access to the above stated files. The system programmers responsible for ACF2 should have WRITE and ALLOCATE access to the Primary and Alternate VSAM files. But, all access should be logged and justified when such logging occurs. They are the ones who will have to recreate the databases when more space is required or when a recovery is required. The procedure used to recreate the Alternate clusters, needs similar access to the Alternate files. Data Security does not need access to these files under any circumstances. When updating the databases, ACF2 accesses the files on their behalf, so they don't need access. ACF2 does not need access either, as ACF2 opens the file before it is fully active and therefore no validation is performed. Access to the databases should be tightly controlled, as the system availability may be compromised. If a user has allocated the databases, ACF2 cannot access them, as ACF2 needs to have exclusive access. 6. Examine the SYS1 rule set to determine that the SYS1 rule set to determine that the ACF2 distribution libraries may only be accessed by the system programmer assigned to ACF2 support. Files included are SYS1.ACFMAC, SYS1.ACFMOD, and SYS1.ACFOBJ. 7. Review the ACF2 rules for the backup files. Ensure that only the recovery procedure (from a controlled library) can update the files. Allocate access should be limited to only the ACF2 system support people. Access to the backup files can be much more loosely controlled than access to the databases, as the system availability is not in question. WRITE or ALLOCATE access should be strictly controlled to ensure that the integrity of the backup files cannot be compromised. The backup and recovery procedures need this kind of access and the system programmer(s) responsible for ACF2 also needs it. When individuals have WRITE access all such access should be logged and strictly reviewed. READ access may be allowed to any user with the need to scan the user User-IDs and some information about users of the system. 8. Review the ACF2 FDR compile listing. Verify that the listing being reviewed matches the current SHOW ACF. Differences indicate the FDR listing is not the one currently in use. This feature is intended primarily to ensure that the listing used in the next series of questions is in fact the actual source used in the generation of the current ACF2 system. If the site has kept the original compile listing of FDR (most desirable), the only check that is needed here is to compare the SHOW STATE or SHOW ACF sub-commands to the compile date/time and compile size to the listing. If this is identical, no further check is required. Otherwise, use the SHOW ACF & SHOW FIELDS sub-commands to list all the features and parameters currently active. Several of these include: o UID string content; o Fields defined (SHOW FIELDS); o SVCs used; o Dataset names used for databases & backups; o contents of header line in User-ID list; o SMF record types; If there are any discrepancies in any of these areas, the listing you are looking at is not the one being used. 9. Using the "SHOW STATE" command, verify that started tasks are controlled by ACF2 (i.e. STC=ON). 10. Using the "SHOW STATE" command, verify that access to tape datasets is controlled by ACF2 (i.e. TAPEDSN and TAPEBLP in the OPTS GSO record). 11. Using "SHOW STATE", determine that all disk dataset names are protected by ACF2 (i.e. specified as ******). 12. Using "SHOW STATE", check the appropriate GSO option to determine if passwords are adequately controlled by ACF2. For example MINPSWD(5) to enforce that all User-ID passwords have a minimum of 5 characters. 13. Determine which fields are being used to make up the UID string. Verify that these fields may only be changed by SECURITY personnel. Use the ACF2 sub-command SHOW STATE or SHOW ACF to list the fields which make up the UID string. The results will include a line entitled "UID STRING=". Each field name described here should be reviewed specifically in the listing of the FDR compile reviewed earlier. The fields are being reviewed to identify who can change each of these fields ( look for ALTER= ). Only users with SECURITY or ACCOUNT should be able to change any of these fields. Additionally, the RESTRICT attribute should be on each of the definitions. If any of the fields can be changed without the SECURITY and/or ACCOUNT privilege, the integrity of the system is questionable. The UID string is the backbone of access authorization in an ACF2 system. Anyone who can change the content of any part of the UID string can change the access given to a user. The RESTRICT attribute in this situation requires the SECURITY or ACCOUNT User-ID making the change to be FULL SCOPE, meaning that this id cannot be limited in any way. 14. Examine the @CFDE entries in the FDR comparing to the vendor supplied defaults. Determine that local modifications do not materially weaken security or control. Note any exceptions. A difference may not necessarily be a concern. Evaluate the impact of the difference by referring to the ACF2 Administrator's Guide for a definition of the field and it's purpose. The areas of most concern in the CFDE definitions are: o field name defines how it is referenced in the User-ID record; o ALTER= defines who can change the contents; o FLAGS= defines any restrictions. A definition of the various FLAG restrictions can be found in the ACF2 System Programmers manual. The most commonly used FLAG is the RESTRICT flag which requires the Changer to be FULL SCOPE. 15. Determine if ACF2 PTFS, TUMS and other maintenance is performed using SMP. Verify that distributed fixes for integrity exposures are applied in a timely manner. The vendor periodically issues program fixes which are identified as fixes for integrity exposures. Normally, there is little or no more explanation about the fix. 16. Determine how distribution and maintenance files (tapes) are controlled. Is the information designated as critical and adequate physical security applied? Each site will get the ACF2 software distributed to them in a different manner. Some get it direct from the Vendor, others get it transmitted to them. The purpose of this review is to determine how the site has established control over the distributed software to ensure that the integrity of the original files remain intact and to ensure recoverability if the down-loaded files are damaged. The software should be considered a proprietary product and appropriately controlled to ensure no copies of the software are left around where it could be copied. Access controls for the files should be adequate to ensure only the system programmer(s) responsible for the product can access it. ACF2 Settings Purpose: To review settings of ACF2 to ensure that ACF2 has been adequately installed. 1. Review the GSO records to determine if any disk volumes are omitted from ACF2 control (RESVOL). ACF2 allows for a partial control to be invoked by specifying a parameter which allows you to control only certain volumes of disk. The parameter is the RESVOL parameter, specifying a mask or series of masks which are to be controlled at a dataset name level. RESVOL parameters can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST RESVOLS END It could be necessary to exclude some disk volumes from dataset name validation if, the dataset names on that volume are not standard MVS dataset names. ACF2 verifies that MVS dataset naming conventions are adhered to. Some products exist which do not conform to MVS dataset names. For example, some products use 10 position level names. ACF2 does not allow this. For the product to run on an ACF2 controlled environment, the volumes that these dataset reside on must not be protected at a dataset level. However, no dataset on those volumes are controlled. Review the content of any volumes that are excluded from the RESVOL list. The datasets on the volumes are free for all users of the system. Any production datasets on these volumes are uncontrolled and should be criticized. 2. Review the GSO records to verify that Started Tasks are controlled by ACF2 (STC=ON). When ACF2 is installed, only disk datasets in a batch or TSO environment are controlled unless ACF2 is explicitly told otherwise. Operator Started Task Commands (STCs) are not controlled until the option is turned on in the GSO. The STC parameter can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST OPTS END The OPTS parameter will either have STC or NOSTC. If NOSTC, any started task can be run. No access validation will be performed for any STC. In most environments, an operator will initiate any STC upon request without any questions asked. Anyone with write access to any of the PROC libraries can insert or change any started task. In any ACF2 controlled environment, dataset integrity depends on the STC option being used. 3. Review the GSO records to determine if tape access is controlled at a dataset level (TAPE-DSN=YES). When ACF2 is installed, only disk datasets in a batch or TSO environment are controlled unless ACF2 is explicitly told otherwise. Tape datasets by default are not initially controlled until the option is turned on in the GSO. The TAPEDSN parameter can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST OPTS END The OPTS parameter will either have TAPEDSN or NOTAPEDSN. If NOTAPEDSN is invoked on any system, then tapes will not be ACF2 protected. Any user will be able to read or write any tape file. 4. Review the GSO records to determine if ACF2 is in ABORT mode on all systems. (Optionally, RULE,ABORT,ABORT may be acceptable). ACF2 allows for progressive control of the resources. To do this a MODE has been established. This MODE should not be confused should not be confused with the MODE operand in the User-ID record. The User-ID MODE defines the option which causes ACF to return a "?" or "ACF, LID, RESOURCE, etc." when awaiting input. The system MODE determines what ACF2 does when a violation is encountered. The possible system MODEs are: QUIET No dataset access will be denied or reported; LOG All dataset access will be allowed and violations will be logged; WARN All dataset access will be allowed, violations will be logged and a message sent to the user informing him of future failure; RULE,x,y Selective mode. "x" could be either QUIET, LOG, WARN or ABORT. It determines what action is to be taken if no rule exists with the KEY specified. "y" could be either QUIET, LOG, WARN or ABORT. It determines what action is to be taken if no $MODE card is found in the rule. ABORT All dataset access which is not allowed by a rule is prevented and a log of the attempt is generated. The desirable MODE is ABORT, however, a MODE of RULE,ABORT,ABORT may be acceptable is no critical keys have the $MODE card allowing access. The MODE parameter can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST OPTS END 5. Review the GSO records to determine if Quick Logon is not permitted for TSO (QLOGON=NO). TSO can optionally allow a user to sign-on using a quick logon. This means that the user can specify his/her User-ID and password on the same line. The problem with this is that the password is in clear text and can be observed by anyone watching. Since ACF2 depends on individual accountability, password integrity must be above reproach. The TSO parameters can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST TSO END The options are QLOGON or NOQLOGON. QLOGON is the default. NOQLOGON is the desirable option. The TIME parameter specifies the default CPU time allowed per session. A TIME of 1440 is a key time which causes the SMF time-out parameter to be ignored. If 1440 is the default, users without a TSOTIME parameter will never be logged off because of inactivity. Review the compensating controls before criticizing the unit for this feature. Limited access to the physical terminal may be a compensating control. 6. Determine if any programs have been identified as able to use BLP. If so determine if they could be used to circumvent normal controls. (BLPPGM=) ACF2 controls the use of LABEL=(,BLP) or Bypass Label Processing. When BLP is specified in a DD statement of JCL, MVS is instructed to not compare the FILENAME on a tape file to the DSN in the JCL. When BLP is used, no validation of actual dataset name occurs, and therefore no ACF2 rules are examined. Anyone using BLP can access any tape file on the system in any way he wants without control or audit trail. ACF2 provides the option to verify an individual's authority to use BLP, but it also provides the ability to allow any user to use BLP depending on the program being used. This is not necessarily a bad feature provided the programs function does not allow the user to get access to information not normally allowed. An example of a program which should be given this authority, may be one which dumps the header records from all files on a tape. An example of a program which should not be given this authority, is a program that copies a tape to another file with a different name. The BLPPGM parameter can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST BLPPGM END The purpose of any program identified here should be closely examined. General utilities like IEBGENER or WAAPDSUT should never be defined here. Ask the utilities group to define the functions programs defined here can perform. 7. Review the libraries defined in any of the GSO records as LINKLIST. Verify that these libraries are controlled at least as well as "SYS1.LINKLIB". Program pathing is a feature introduced by ACF2 during early releases of the product. It was unique to ACF2, and provided an added level of control which no other security product had incorporated. During early releases of ACF2, program pathing had some technical problems which were difficult to overcome. These problems related to identifying the library a program was executed from when STEPLIB or JOBLIB was used by the user. ACF2 would lose track of which library in the concatenation the specific program was executing from. To overcome these problems, ACF2 program pathing rules were generally written to use 'SYS1.LINKLIB' as the library source for programs. This implied to ACF2 any library defined in the system LINKLIST. Later releases of ACF2 allowed the Security Officer to add additional libraries to ACF2's list of libraries to be considered as members of the LINKLIST, even though MVS did not. This introduced an exposure, when libraries defined here were not as well controlled as the system libraries. Each library added to this list degraded the intended control of program pathing by introducing additional libraries that the programs could come from. The LINKLST parameter can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST LINKLST END Examine this list. Determine the controls over modification of each library. Ensure that each is at least as well protected as the SYS1.LINKLIB dataset. Ideally, only SYS1.LINKLIB will be defined here. It is likely that all members of the system linklist are defined also. Any more should be strongly discouraged. 8. Determine that the PASSWORD control options in place are consistent with suggested parameters below. Investigate discrepancies. o minimum length is 5 (MINPSWD=5); o standard encryption is used (ENCRYPT=XDES); o 3 retries per session (MAXTRY=3); o suspended after 6 violations (PASSLMT=6); o forced after password reset by SECURITY (PSWDFRC); o batch attempts are counted (PSWDJES). PASSWORD control is one of the best features available in ACF2. For the first time, users can be required to be responsible in their choice of passwords and in maintaining them. The features described above include: MINPSWD - The minimum length a user can use when providing a new password to ACF2. ENCRYPT - Which encryption technique to be used when encoding the password on the User-ID database. In releases prior to version 2.2.1, the vendors of ACF2 were using their own encryption routine for storing the password. In later versions, the Data Encryption Standard was incorporated. But the old version was still supported. ACF2 has continued to support the old version. MAXTRY - The maximum number of times a password can be entered incorrectly before having to start the sign-on process over. PASSLMT - The number of invalid password attempts allowed in a single day. If this number is exceeded, the User-ID will be suspended until reactivate by a SECURITY user. PSWDFRC - This parameter forces a user to change the password if it has been changed or observed by a SECURITY User-ID. PSWDJES - Optionally, an ACF2 system can be allowed to not count password violations if they are encountered in the batch environment. The PASSWORD parameters can be determined by reviewing the GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST PSWD END Verify these standards are being observed to ensure users are being responsible in the administration of passwords. 9. Determine MAINTENANCE programs are appropriate for the user's job responsibilities. Verify that only controllable programs are used. General utilities such as IEHPROGM, IDCAMS, and IEBCOPY should never be included. One mechanism which can be used to allow system software or data center users to perform their job without giving them NON-CNCL privilege or requiring access rules to be written for every dataset in the shop is MAINTENANCE. The MAINT parameters of the GSO describe programs, libraries and User-IDs which are allowed to access any data without rules, because the programs have been identified as maintenance programs which perform a specific controlled function. The functions are normally for archival and retrieval of data or reorganization of space. It is very appropriate for system software to have MAINT records defined for them. In this review, we are looking at the programs defined as MAINT programs to verify that they are for a specific purpose and cannot be used to manipulate information for other purposes. For this reason, programs like IEHPROGM, IDCAMS, and IEBCOPY or any other general utility program should not be used as MAINT programs. This is not to say they cannot be used, but should not be used as MAINT. Additionally, it is important that other accounts are not given the MAINT privilege to avoid writing rules. MAINT gives total access to all data for read or write. An account like Florida Title XIX was given WAAPMCOP as a MAINT privilege. This is a general copy utility which gave them the ability to copy any file to any other file without logs. This should not have been allowed. Another situation to look for, is the existence of MAINT programs in libraries which are not well protected. If the user with the privilege has write or allocate access to the library identified in the MAINT record, then the desired control is lost. 10. Determine JOBCK is defined to ensure that each user must have the JOB parameter to be able to use their User-ID in the batch environment. This may not be significant if all users should be able to run in batch. The JOBCHK is a parameter comparable to the TSO LOGONCHK which determines if the checking is to be done to determine if a User-ID can be used in batch jobs. 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 JOBCHK parameter 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. The JOBCHK parameter can be determined by reviewing the OPTS GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) LIST OPTS END The record will either contain JOBCHK or NOJOBCHK. 11. Determine SAF VALIDATION is ON to ensure program products using SAF will validate dataset rules. The SAF VALIDATION establishes if User-IDs calling a program product using SAF will verify ACF2 dataset rules for access. The SAF VALIDATION parameter can be determined by reviewing the ACTIVE GSO records for all systems. The commands to do so are: ACF SET CONTROL(GSO) MSYS(-) SHOW ACTIVE END The record will either contain SAF VALIDATION = YES or NO. Account Privileges Purpose: To review the account privileges for ACF2 and system software. 1. Using either the LIST command or the Super List (ACFRPTSL) report generator, display a sample of User-ID records. Verify that the password expiration parameter (MAXDAYS) of the password group is used and is no greater that 90 days. Review the User-IDs required to use a password. Verify that each must change the password at least every 90 days (normally 30). Recognizing that the Account Manager likely has many other important things to remember, and that it is possible for the manager to forget, procedures should exist which would identify those situations which indicate that a User-ID is not being used. User-IDs which have not been used in more than 3 months are not likely needed. 2. Review User-IDs not requiring a password. Verify that each is controlled by the SUBAUTH and PROGRAM parameters. Determine the effectiveness of PROGRAM masks used. Alternatively a controlled SOURCE may be acceptable (NEVER STCINRDR or INTRDR). ACF2 depends on individual accountability to authorize any access to the resources it protects. To do this it must have some way of ensuring that a user is who he claims to be. For people using on-line applications, it is practical to request a password known only to them. For batch applications, some other means of verifying the authority is required. ACF2 has currently 3