IMS AUDIT OBJECTIVE - To ensure that the use of IMS database Management System by individual application systems is controlled and provides control over the application. DATABASE ORGANISATION 1. Determine which databases are accessed by the particular application from discussion with IS personnel and examination of available documentation. 2. Determine the organisation of each database. If the organisation is HDAM, ensure that there is no need to process data sequentially as HDAM databases cannot be processed in this way. 3. Determine why the particular organisation of the database was chosen. Has account been take of the level of volatility of the database (i.e. number of segments added and deleted on a regular basis). HSAM databases are better suited to highly volatile applications. 4. Is use made of GSAM. Normal sequential files can be defined as GSAM databases. This allows IMS to control rollback and recovery in the event of failure. Are there any sequential files feeding IMS jobs where this facility would be useful. 5. Are any databases defined as MSDB (main storage database). These are resident in memory and have the advantage of fast access times. However, if the machine goes down, data will be lost resulting in a failure to recover updates. Some logging does occur, but there is no update on disk. Are these databases being used for reference purposes only? Are there any reference type databases which would benefit from being MSDBs and has this option been considered. 6. Are DEDBs (data entry databases) being used. If they are, determine how many copies are being maintained (up to 7 are allowed) to allow for restart and recovery. Is this adequate. 7. For HISAM databases, determine the number of secondary indexes being used. Determine the reasons for the secondary indexes and ensure that all access routes are justified. Determine is additional routes are required. Increasing the number of secondary indexes reduces performance and increases storage requirement. 8. Is any use made of logical databases. These define the logical relationship between non-physically related segments (e.g. across different databases). This definition can be used to maintain structural integrity for a database. DATABASE DEFINITIONS (DBD) A DBD is a definition of the physical database. 1. Determine where DBD source macros are held and ensure that they reside in a library which is protected by RACF. Review access lists to ensure that they can only be updated by DBA. 2. Determine which DBD macros apply for the databases used by the application under review. 3. Determine the IMS access method from the DBD macro. If this is not VSAM, determine the reasons from DBA and evaluate.
4. Determine the dataset names of each database and ensure that the physical dataset is adequately protected with RACF. The ddname can be determined from the DATASET macro in the DBD. It should be noted that IMS databases are effectively VSAM file which can be accessed via normal methods and utilities when not under the control of IMS. They must therefore be protected by RACF to prevent changes being made outside the control of IMS. 5. Map out the hierarchical structure of the database and review the data contents of each segment. Do any segments contain data items which should not be accessed together for any reason (e.g. would impact level of control). IMS can only control at the segment level. The IBM utility DMAP can be used to draw the hierarchy automatically. Also ensure that segment contents do not conflict with business entities or requirements. 6. Determine which fields are search fields. These are defined within the FIELD macro as NAME=(abc,SEQ,U) where abc is the data field name. Defining search fields no longer represents a major overhead to the system. Determine if all defined search fields are valid and if others are required. 7. When key sequence fields are defined as "U" in the FIELD macro, IMS ensures that they contain unique values. For root segments this means that the field will be unique across the database. For siblings, the uniqueness is maintained only within the particular parent. When "M" is specified, multiple occurrences of a particular value are allowed. This is mainly useful where dates are used as search fields. Determine whether the specification of search fields as unique or multiple is based on valid business requirements remembering that specification of M for data which requires to be unique may lead to unrequired duplication. 8. IMS stores data in ascending sequence. Where dates form part of the key sequence, the latest data will be the last read. Where performance is an issue, it is a valid technique to subtract the date from 999999 in order to invert the date sequence and ensure that the latest data is first in the database sequence. Where this type of access is required, ensure that this technique is used or has been taken into account. 9. The RULES parameter on the SEGM macro defines where to insert a duplicated segment. This can be inserted FIRST (before other duplicates), LAST (after other duplicates) or HERE (wherever the application program decides). This could be manipulated to perpetrate fraud. Evaluate the effect of inserting a duplicated segment and determine whether the RULES will help prevent misuse or error, especially when RULES=HERE is specified. 10. Determine if there are any secondary indexes associated with the database. This can be determined by the presence of a LCHILD and corresponding XDFLD macros in the DBD. NB to ensure the use of the secondary index during a search the XDFLD name must be used not the original field name. Determine that all applications make use of the secondary indexes where necessary and determine if additional indexes are required. 11. Determine if any logical relationships have been defined by review of DBD for LCHILD macro with no associated XDFLD macro. Determine what RULES are set up for ADD, DELETES and INSERTS. Are these rules realistic. For example, when a "logical" parent is deleted, should the physical parent be deleted as well. PSBs and PCBs A PSB (Program Specification Block) is a definition of the applications view of the data and terminals. The PSB contains PCBs (Program Communication
Blocks). 1. Determine which PSBs are used within the application by review of the //EXEC statement on the relevant program JCL. 2. Determine where PSBs source is maintained and ensure that libraries are protected with RACF. Ensure that update access is limited to those persons responsible for maintenance of PSBs. Who is responsible for maintaining PSBs. Does this provide for division of duties. 3. Determine what type of PCB is contained within the PSB. A terminal will be defined with a TYPE=TP and a database will be defined with a TYPE=DB. 4. TERMINAL type allows output to be sent to another terminal (for example, to send messages to a security terminal). If this type of PCB is used, determine why and identify the terminal in question. This can also be used to route error messages to a particular terminal or printer rather than abending. This enables a controlled abend under IS control to be carried out depending on the severity of the problem. 5. If the MODIFY=YES parameter is used, the program can determine the destination. If this is set, determine why and evaluate. If output is sensitive, ensure that destination is not modifiable. 6. If EXPRESS=YES parameter is specified, output is sent to terminals even if a program abends. This could cause problems where the output is sensitive (e.g. cheques) as duplicated output could result when program is restarted or rerun. Ensure that this is taken into account where this parameter is specified. 7. DATABASE type allows definition of the segments which can be accessed by a program. Ensure that the program can only access those segments which are appropriate for its processing and that no inappropriate data can be accessed. 8. Ensure that the processing options (PROCOPT) are appropriate for the program (e.g. enquiry programs should not be allowed to add, delete etc.). Note that a global PROCOPT can be defined on the PCB macro, but will be overridden by a PROCOPT entry for an individual segment (on SENSEG macro). 9. Ensure that there is one PSB specified for each program. If multiple programs use a single PSB there is a danger that if the PSB is changed, programs may acquire inappropriate privileges over data. 10. Determine the value of the POS= parameter on the PCB macro. This determines the number of "positions" within the database which can be maintained by IMS. POS=S means that only the current position can be recorded, POS=M allows multiple positions to be maintained. This allows a program to access multiple segments. Is this parameter appropriate for the method of processing. 11. If the SENFLD macro is used, this defines the only field which can be accessed within a segment. It can also be used to prevent changes being made to a particular field by combining it with the REPL=NO parameter. Multiple SENFLD macros can be specified within a single segment. Do any of the programs require such a level of security and, if so, is the PCB defined to allow for it. APPLICATION CONTROL BLOCKS An ACB is unique for every on-line program and can be generated for a batch program. It is a combination of the appropriate DBDs and PSBs for the relevant
program and speeds up processing. IMS will look for an ACB first before looking at DBDLIB or PSBLIB for batch jobs. The ACB is generated via the ACBGEN processing. 1. Database definitions can differ between the ACB and the DBD if the DBD is changed and the ACBGEN is not repeated. If this occurs the program will pick up the wrong versions which could result in error. Check the ACBLIB definition to the DBD and PSB to ensure that they are in line. APPLICATION CONTROL MACRO The application control macro (APPLCTN) is part of each IMS system Generation (SYSGEN). There is one macro for each PSB. This defines the PSB name, the program type (batch, bmp, mpp) etc. There is also one or more associated transaction control macro (TRANSACT) which defines transaction codes for the PSB in the APPLCTN. 1. Determine from review of the APPLCTN macro which PSBs are active. 2. Determine from the TRANSACT macro a list of on-line transactions which use the PSB. 3. Review the parameters specified on the TRANSACT macro. If the MODE=MULTIPLE parameter is set this specifies that the unit of recovery is set to multiple transactions. This increases the risk of loss of data and is not recommended where the data being entered is sensitive. In this case, MODE=SNGL is recommended. 4. Where RESPONSE is specified in the MSGTYPE parameter the transaction will respond to the terminal on completion. This is recommended for all sensitive data entry to accidental prevent duplication of input. MESSAGE FORMAT SERVICE This IMS function allows screen formats to be defined independently of the application programs. It is not mandatory, but can speed up processing. 1. Determine where screen format source code is maintained and ensure that the datasets are protected with RACF. 2. Determine which screen formats are used for the application under review and determine which is associated with each program. 3. Certain fields can be defined as "non display" or "protected". This provides a certain degree of security. Ensure that all use of this protection is appropriate and that there are no other fields which should be protected in this fashion. 4. MFS contains 256 exits where user written code can be inserted to manipulate data inserted into a field. Use of exit code can be detected by the existence of the EXIT= parameter on a field definition. Where exits are used, determine what is being done by the exit code. Also determine where the exit source code is maintained and how it is protected. APPLICATION PROGRAMS 1. Review each application program for compliance with the following simple rules. 2. Ensure that each program has only a single entry point. This can be determined by scanning the code for the statement ENTRY 'DLITCBL'.