Following was contributed to AuditNet LLC by (Rey LeClerc) rey@mass-usa.netACF2/VM ReviewPurpose: Determine whether the ACF2 software has been appropriately installed. Determine if access to system software, files and commands is controlled and appropriately restricted. Determine if chosen exits permit circumvention of intended controls.Components of ACF2Purpose: To ensure that components of ACF2 are adequately installed.1. Examine the rule set to determine if the three backup data sets (BKLIDS, BKRULES, and BKINFO) are accessible only to appropriate personnel. Determine if an automatic backup is performed.The BACKUP file names used by ACF2 for backup procedures can be found by issuing a SHOW DDSN sub-command of ACF. 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.2. 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 logonid 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.3. 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 logonid passwords have a minimum of 5 characters.4. 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 logonid making the change to be FULL SCOPE, meaning that this id cannot be limited in any way. 5. 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 logonid 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.6. Determine how ACF2 PTFS, TUMS and other maintenance is performed. 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. 7. 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 SettingsPurpose: To review settings of ACF2 to ensure that ACF2 has been adequately installed.1. 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 logonid record. The logonid 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.2. 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);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 logonid 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 logonid 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 logonid.Verify these standards are being observed to ensure users are being responsible in the administration of passwords.3. Determine MAINTENANCE programs are appropriate for the user's job responsibilities.One mechanism which can be used to allow 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 MAINTENANCE 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 various organizations in the technical support group to have MAINTENANCE records defined for them. In this review, we are looking at the programs defined as MAINTENANCE programs/logonids to verify that they are for a specific purpose and cannot be used to manipulate information for other purposes. Additionally, it is important that other accounts are not given the MAINTENANCE privilege to avoid writing rules. MAINTENANCE gives total access to all data for read or write.Another situation to look for, is the existence of MAINTENANCE programs in machines which are not well protected. If the user with the privilege has write or allocate access to the library identified in the MAINTENANCE record, then the desired control is lost. 4. Review the GSO parameters for VMCHK. This operand provides additional validation when a user goes through log-on. If the user does not have the appropriate attribute turned on in the logon if record, then the logon will be denied. The default is VMCHK=NO. When VMCHK=NO, only standard logon validation is done. It is recommended that VMCHK=NO be used in environments without shared ACF2 databases.Account PrivilegesPurpose: 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 logonid 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 logonid is not being used. Logonids which have not been used in more than 3 months are not likely needed. 2. 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 logonid to change certain fields of the logonid 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 logonid to change certain fields of the logonid record and allows for adding and deleting User-IDs on the logonid 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.3. 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 logonid 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 logonid 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.4. Using the "LIST IF" command or the SL report, examine which users have the CONSULT and AUDIT attribute. These users are allowed to decompile access rulesRules for System SoftwarePurpose: To review the ACF2 access rules for system software.1. Determine that libraries containing ACF2 modules are adequately protected. Write and Allocate access to the production version should be logged and restricted to emergency situations only.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.2. Obtain a copy of the CP directory and identify all service machines. Use the DECOMP command to decompile the service machine rule set. Review the ACF2 access rules to determine that the service machines can only be accessed by the system programmer(s) assigned to ACF2 support. 3. Determine if any user other than Data Security can change the rules for system software 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 Logonid 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. 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 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. 5. 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 ADMINISTRATIONPurpose: 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 - Logonid 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 Logonid Job Log - identifies usage of logonids 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 ExitsPurpose: 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. Note any discrepancies.There are now 7 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.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.3. Review the ACF2 intercepts. These are ACF2/VM control routines that are invoked during installation. They function in the same manner of user exits.Consideration should be given to the following parameters:o LOGON, PASSWORD, LOGOFF, ACCESS VALIDATE = YES means that validation of user logonid is provided by the ACF/VM.o ATTACH = NO. If ATTACH is used the user of the virtual machine may then read or write to or from any area in the attach volume.o DIRMAINT = YES. DIRMAINT is used to allocate and deallocate disk space.