- Email: [email protected]
RACF 1.9 enhancements
May 1991
For example, formal software distribution (E2), secure maintenance (E2) and the start up process (E2) are causing some concern with the vendors. Such operational requirements are usually carried out by trusted personnel with trusted procedures. Inclusion in criteria extends ITSEC to embody many routine organizational aspects in the commercial IT shop. Conclusion
It is o b v i o u s that the recognition of assurance as being equal to or more important than just basic functionality, will change the ways in which information technology will be exploited. Issues of speed, economy, etc. will be reconciled with the ability to maintain service availability, service/data integrity and confidentiality, under adverse operational conditions. Evaluation criteria for products, and increasingly systems, will become a cornerstone of both vendor and user policy. The historic investment in specific evaluation criteria and the existing certified products will generate a period of confrontation by the various technical players in the early 1990s. Each vested interest, whether national or sectorial, will debate their intellectual and administrative credentials. Public interpretation of the various forms of the Orange Book/Rainbow Books will become commonplace in the early 1990s. The increasing vocal user community will define operational requests. These may fragment the existing evaluation guidelines. The skill will be to m a i n t a i n an o v e r a l l administrative/technical framework that can accommodate the plethora of security options. ITSEC, as a flexible, cross-sectorial White Book, is a good basis for such disciplined effort. 'White light' is made up of the spectrum of colours of the Rainbow, the final ITSEC approach will be to consolidate and harmonize the many international, security evaluation programmes, no matter what their coloud
O1991 Elsevier Science Publishers Ltd
Computer Audit Update
Clive W.Blatchford has recently completed seven years with STC/ICL as corporate officer for security strategy. He is currently executive consultant to Panacea Ltd and a senior advisor on information security to the European Community through EEC-DGXlII/F, where he has played a significant role in defining an EEC funded Information Security p r o g r a m m e (INFOSEC).
RACF 1.9 ENHANCEMENTS Alan S Oliphant RACF release 1.9 represents a considerable improvement in the mechanisms available to provide security. The enhancements allow IBM to claim the US Department of Defense, Orange Book B1 standard for security. While this level of security is probably more than the average commercial installation would ever want to implement, there are features that will make a positive contribution to security. This article does not provide a detailed description of these new features, but provides an overview and suggests some of the auditing implications. New database structure
The basic structure of the RACF database has changed. More information can now be stored within it. This new restructured database is not necessary to run RACF 1.9, it will still support the previous unstructured database, but this will be the last release of RACF that does support it. This enhancement is purely performance related. Different segments within the database are used to contain different information (e.g. TSO related data) and RACF only retrieves the segment containing the required information. In addition, the new database allows for resource and profile names up to 246 characters long. This 'Long Name' enhancement is discussed later.
11
Computer Audit Update
Group Tree The Group Tree can now be maintained in main storage. This improves processing time for r e q u e s t s from users p o s s e s s i n g group authorities. As with the new database structure, this enhancement is performance related.
Security labels Perhaps one of the most important ideas introduced with release 1.9 is the concept of the security label (SECLABEL). Previous releases introduced the security level and category. The security label combines these two concepts into a single facility. This is essentially a mechanism to classify data based on category and level. A security label is defined in the new SECLABEL class and can contain multiple security categories within a particular security level. Individual resources will be defined as being within categories at a specific level. Users are permitted to the particular security label with READ access. Users can be permitted to one or many security labels. Access to the security label does not permit automatic access to the protected resources. The resource profile would still govern access by particular users. However, to access a resource the associated security label of a user session or batch job must cover the contents of the resource security label. The user security label level must be equal to or greater than the resource security level and the user security label categories must contain all the categories in the resource security label. The user security label does not have to be the same label assigned to the resource, but must at least cover all the resource's label categories and be at least the same level. At sign on time users must specify which security label is to be associated with their interactive session. A default security label can be assigned if no alternative label is entered. This facility is one that is required to obtain a B1 rating as it can control access based on c l a s s i f i c a t i o n . H o w e v e r , there will be circumstances in a commercial environment where this type of security control can be
12
May 1991
beneficial. The security label facility is really an additional layer of security that can be used when the sensitivity of the data or resources demands strong control.
Output control The concept of the security label now allows better control over printed output. This increased control is in two areas. Firstly, it is now possible to direct output to particular output devices based on the label and s e c o n d l y a s e c u r i t y c l a s s i f i c a t i o n m e s s a g e can be printed automatically on all pages of output. In the commercial environment, the more important of these is the ability to control the device for output. This is achieved by the use of a new class 'WRITER'. Printers can be protected by setting up a WRITER profile and having a security label assigned. If this control is active, JES will carry out a check of the WRITER profile before sending output to a printer. For the output to be printed the user creating the output must be permitted to the profile protecting the printer and the label associated with the printer must match the label associated with the output. If different printers do not have similar labels a strong control can be implemented to ensure that the most sensitive output can only be printed at a specific printer and can then be physically protected. Examples of where this could be used include situations where negotiable documents including cheques are printed on local printers. Besides this control over where output is printed, it is also possible to define a security classification overlay that will be printed automatically on all output pages. This helps to identify sensitive output easily allowing it to be separated from other output and afforded special treatment. This is done by defining an overlay that is associated with a security label. When output is created the resultant SYSOUT assumes the security label of the user of the job that created the output. The printed output will then contain the contents of the overlay associated with the label.
O1991 Elsevier Science Publishers Ltd
May 1991
This facility is one that will probably not be used e x t e n s i v e l y within the commercial environment. However, all companies must have at least one type of printed output that can be regarded as company confidential and this is certainly a useful feature to help identify such material. JES SYSOUT datasets Until RACF 1.9, sharing of individual SYSOUT datasets was only possible by use of a JES exit. RACF 1.9 now allows this sharing to be controlled more easily via a profile in the JESPOOL class. Individual users will still be allowed access to their own SYSOUT datasets even when no profile is set up. This will allow other users to view the contents of SYSOUT datasets in a controlled manner without having to print them.
Computer Audit Update
submitted under this convention, the owner's user ID is specified in the JCL (without the password) and RACF will check to ensure that this is authorized. The job will execute with the identity of the original user. This allows responsibility to be delegated while accountability is retained. A possible example of the need for this is where the original user is unavailable to run a particular job, and has authorized someone else to run it. One point to remember is that the concept of surrogacy does not infer all the original user's privileges on the surrogate. There may be circumstances where a job needs to be run that is a secure job, which needs particular access rights ttlat should not be given to everyone who uses the job. Surrogacy is possibly one answer to this situation. JES networking
Job submission and cancel RACF now provides the facility to control who can submit or cancel a particular job by job name. The new class JESJOBS is used to define the jobs a user can submit and cancel. Previously this level of control was only possible by use of user written exit code. This new control could be particularly useful in an environment where there is extensive end user programming that is not subjected to the level of control normally exerted over system development staff. For this type of control to be effective, it is vital that the installation defines and strictly enforces standard naming conventions over jobs. Otherwise the number of profiles necessary will proliferate to a point where it is next to impossible to maintain.
Surrogate user IDs A n o t h e r new class in RACF 1.9 is SURROGAT. This allows a user to submit a job for another user without having to enter the other user's password (which is clearly a breach of normal security conventions). The 'surrogate' user is defined with the user whose job the surrogate is allowed to submit. When a job is
@1991 Elsevier Science Publishers Ltd
Control over NJE (Network Job Entry) jobs is improved. The receiving node in a JES network can now define the level of trust associated with a sending node and can define what will happen when work is received from that node. This ranges from not accepting any NJE work, through requiring password verification, to accepting all work with no further verification. This is controlled by profiles in the new NODES class. In any event, user IDs, groups and security labels can be defined as necessary entries in NJE headers received from particular nodes. It is also possible to define which specific user IDs, groups and security labels will be acceptable for particular nodes. User IDs can be different at sending and received nodes. A translation facility is available to associate the two user IDs. This level of control is particularly welcome with the increasing use of EDI (Electronic Data Interchange) that can involve the use of NJE between different organizations.
Operator commands IBM appears to have accepted that consoles are now moving out of physically protected computer rooms and are being located
13
Computer Audit Update
increasingly within unprotected offices. There also seems to have been a realization that operators have different levels of knowledge and that division of duties can provide a control over the operation of computer systems. RACF 1.9 now contains the facility to control which MVS and JES commands can be entered, based on user ID, console ID and node ID. A new O P E R C M D S class controls this. Use of commands can be audited by specifying implicitly, or by use of the new LOGOPTIONS (discussed below). HIPERBATCH support HIPERBATCH allows datasets to be stored in HIPERSPACE that is a type of storage that allows many jobs to share the same dataset at the same time. A new resource class DLFCLASS controls which datasets can be used in this way. HIPERBATCH improves performance because batch jobs can execute quicker due to reduced I/O. Although performance can be improved, users should be wary of this facility where datasets are sensitive and some of the batch jobs require exclusive control of the dataset for their correct processing.
May 1991
execute) them using the RALTER command to set the auditing options in the resource profile.
Profile variables Variable qualifiers can now be specified within resource profile names. Another new class, RACFVARS, allows specific names to be defined within a particular variable qualifier. This allows similar resources with radically different names to be protected with the same level of protection using only two profiles. One profile for the resource protection and the other to define the particular qualifier names under a single variable qualifier profile. This enhancement allows for the installation where dataset names are not subjected to stringent naming conventions and allows space saving on the RACF database by reducing the number of profiles required. There is a danger however that the RACVARs variable is not being maintained properly and that the list of possible names is not kept up to date. This could result in access being granted to inappropriate resources, or to resources not being given the correct level of protection.
Global logging options Two new global logging options are available. These are concerned with the logging of all changes and accesses to security labels and to control logging based on class rather than profile. All activity associated with a particular security label or with all resources within a particular resource class can now be logged. This is done using the SETROPTS command. This expands the options for auditing activity.
Auditing of controlled programs Auditing of who executes controlled programs now works! It is now possible to define auditing options on controlled programs to record an audit trail of which users execute (or fail to
14
Long name support The number of characters allowed for a general resource name has been increased from 39 to 246. This will allow more specific protection of JES spool files and other resources where dataset names are particularly long.
Generic profiles There are several changes in the area of generic profile support. In particular, the introduction of a generic owner, restriction of resource access to RACF-defined users and the ability to list catalogued datasets protected by a particular generic profile. Owners can now be specified for generic resources. If this support is active and a user with CLAUTH, who is not the generic owner, attempts
©1991 Elsevier Science Publishers Ltd
May 1991
to create a more specific profile, RACF will prevent this. However, this will be allowed if the user has SPECIAL attributes. This enhancement prevents the creation of more specific profiles where CLAUTH authority is granted. Prior to RACF 1.9, the universal access (UACC) applied to all users of a system, not just to those who were defined to RACF. With RACF 1.9, it is possible to use the ID(*) keyword of t~e PERMIT command to give RACF-defined users the access required while limiting undefined users to the access defined by the UACC. This will allow a UACC of NONE to prevent access by non RACF-defined users while allowing a 'pseudo' universal access to users who have logged on and been authenticated by RACF. Thus a tighter control over universal access can be implemented. Finally, it is now possible, using the DSNS keyword on the LISTDSD command to list all datasets that are protected with a particular generic profile. Qualified general resource names The generic qualifier character (*) can now appear anywhere within a profile name. This character was previously restricted to the end of a profile name. This allows a lot more flexibility in profile naming.
Computer Audit Update
of DOS without having to learn the (sometimes) complex syntax of the operating system commands. This review looks at two different utility packages. These both come under the general heading of hard disk m a i n t e n a n c e and management tools. They can be used to repair damage at a low level, recover from error and can detect potential problems and provide solutions.
MACE UTILITIES V e n d o r - Riva Ltd Price - - £139.00 Mace is delivered on six 5.25 inch diskettes ul~d takes up around 1.7 Mb of disk space. An install program is supplied which copies the software to hard disk and makes changes to the AUTOEXEC.BAT and CONFIG.SYS system files (if required). It also allows the user to group the various utility programs into user levels (e.g. Universal, Intermediate and Advanced) and assign passwords to each level. This can be used to limit particularly powedul utilities to specific users. Unfortunately, there does not seem to be any mechanism for changing passwords. Any auditor will therefore discount such access control as being ineffective.
Alan S Oliphant is the Computer Audit Manager with the Standard Life Assurance Company. Any views expressed are the author's own and not necessarily those of the Standard Life Assurance Company.
All the utility programs supplied can be run as stand-alone programs or can be run from a front end menu. It is this front end menu program which provides the access control via the password controlled user groups. Individual utility programs are not subjected to control when run as stand-alone programs.
PRODUCT REVIEWS
There are basically six groups of utility programs grouped by type of function. In addition, software is also supplied for disk caching (speeding up hard disk access). The six types of utility are described (on the front end menu) as, info/edit, performance, format, solutions, protection and DOS.
Utility software Previous product reviews have looked at the type of utility software generally referred to as file managers or DOS shells. These allow the non-expert user to make use of all the facilities
©1991 Elsevier Science Publishers Ltd
15
For example, formal software distribution (E2), secure maintenance (E2) and the start up process (E2) are causing some concern with the vendors. Such operational requirements are usually carried out by trusted personnel with trusted procedures. Inclusion in criteria extends ITSEC to embody many routine organizational aspects in the commercial IT shop. Conclusion
It is o b v i o u s that the recognition of assurance as being equal to or more important than just basic functionality, will change the ways in which information technology will be exploited. Issues of speed, economy, etc. will be reconciled with the ability to maintain service availability, service/data integrity and confidentiality, under adverse operational conditions. Evaluation criteria for products, and increasingly systems, will become a cornerstone of both vendor and user policy. The historic investment in specific evaluation criteria and the existing certified products will generate a period of confrontation by the various technical players in the early 1990s. Each vested interest, whether national or sectorial, will debate their intellectual and administrative credentials. Public interpretation of the various forms of the Orange Book/Rainbow Books will become commonplace in the early 1990s. The increasing vocal user community will define operational requests. These may fragment the existing evaluation guidelines. The skill will be to m a i n t a i n an o v e r a l l administrative/technical framework that can accommodate the plethora of security options. ITSEC, as a flexible, cross-sectorial White Book, is a good basis for such disciplined effort. 'White light' is made up of the spectrum of colours of the Rainbow, the final ITSEC approach will be to consolidate and harmonize the many international, security evaluation programmes, no matter what their coloud
O1991 Elsevier Science Publishers Ltd
Computer Audit Update
Clive W.Blatchford has recently completed seven years with STC/ICL as corporate officer for security strategy. He is currently executive consultant to Panacea Ltd and a senior advisor on information security to the European Community through EEC-DGXlII/F, where he has played a significant role in defining an EEC funded Information Security p r o g r a m m e (INFOSEC).
RACF 1.9 ENHANCEMENTS Alan S Oliphant RACF release 1.9 represents a considerable improvement in the mechanisms available to provide security. The enhancements allow IBM to claim the US Department of Defense, Orange Book B1 standard for security. While this level of security is probably more than the average commercial installation would ever want to implement, there are features that will make a positive contribution to security. This article does not provide a detailed description of these new features, but provides an overview and suggests some of the auditing implications. New database structure
The basic structure of the RACF database has changed. More information can now be stored within it. This new restructured database is not necessary to run RACF 1.9, it will still support the previous unstructured database, but this will be the last release of RACF that does support it. This enhancement is purely performance related. Different segments within the database are used to contain different information (e.g. TSO related data) and RACF only retrieves the segment containing the required information. In addition, the new database allows for resource and profile names up to 246 characters long. This 'Long Name' enhancement is discussed later.
11
Computer Audit Update
Group Tree The Group Tree can now be maintained in main storage. This improves processing time for r e q u e s t s from users p o s s e s s i n g group authorities. As with the new database structure, this enhancement is performance related.
Security labels Perhaps one of the most important ideas introduced with release 1.9 is the concept of the security label (SECLABEL). Previous releases introduced the security level and category. The security label combines these two concepts into a single facility. This is essentially a mechanism to classify data based on category and level. A security label is defined in the new SECLABEL class and can contain multiple security categories within a particular security level. Individual resources will be defined as being within categories at a specific level. Users are permitted to the particular security label with READ access. Users can be permitted to one or many security labels. Access to the security label does not permit automatic access to the protected resources. The resource profile would still govern access by particular users. However, to access a resource the associated security label of a user session or batch job must cover the contents of the resource security label. The user security label level must be equal to or greater than the resource security level and the user security label categories must contain all the categories in the resource security label. The user security label does not have to be the same label assigned to the resource, but must at least cover all the resource's label categories and be at least the same level. At sign on time users must specify which security label is to be associated with their interactive session. A default security label can be assigned if no alternative label is entered. This facility is one that is required to obtain a B1 rating as it can control access based on c l a s s i f i c a t i o n . H o w e v e r , there will be circumstances in a commercial environment where this type of security control can be
12
May 1991
beneficial. The security label facility is really an additional layer of security that can be used when the sensitivity of the data or resources demands strong control.
Output control The concept of the security label now allows better control over printed output. This increased control is in two areas. Firstly, it is now possible to direct output to particular output devices based on the label and s e c o n d l y a s e c u r i t y c l a s s i f i c a t i o n m e s s a g e can be printed automatically on all pages of output. In the commercial environment, the more important of these is the ability to control the device for output. This is achieved by the use of a new class 'WRITER'. Printers can be protected by setting up a WRITER profile and having a security label assigned. If this control is active, JES will carry out a check of the WRITER profile before sending output to a printer. For the output to be printed the user creating the output must be permitted to the profile protecting the printer and the label associated with the printer must match the label associated with the output. If different printers do not have similar labels a strong control can be implemented to ensure that the most sensitive output can only be printed at a specific printer and can then be physically protected. Examples of where this could be used include situations where negotiable documents including cheques are printed on local printers. Besides this control over where output is printed, it is also possible to define a security classification overlay that will be printed automatically on all output pages. This helps to identify sensitive output easily allowing it to be separated from other output and afforded special treatment. This is done by defining an overlay that is associated with a security label. When output is created the resultant SYSOUT assumes the security label of the user of the job that created the output. The printed output will then contain the contents of the overlay associated with the label.
O1991 Elsevier Science Publishers Ltd
May 1991
This facility is one that will probably not be used e x t e n s i v e l y within the commercial environment. However, all companies must have at least one type of printed output that can be regarded as company confidential and this is certainly a useful feature to help identify such material. JES SYSOUT datasets Until RACF 1.9, sharing of individual SYSOUT datasets was only possible by use of a JES exit. RACF 1.9 now allows this sharing to be controlled more easily via a profile in the JESPOOL class. Individual users will still be allowed access to their own SYSOUT datasets even when no profile is set up. This will allow other users to view the contents of SYSOUT datasets in a controlled manner without having to print them.
Computer Audit Update
submitted under this convention, the owner's user ID is specified in the JCL (without the password) and RACF will check to ensure that this is authorized. The job will execute with the identity of the original user. This allows responsibility to be delegated while accountability is retained. A possible example of the need for this is where the original user is unavailable to run a particular job, and has authorized someone else to run it. One point to remember is that the concept of surrogacy does not infer all the original user's privileges on the surrogate. There may be circumstances where a job needs to be run that is a secure job, which needs particular access rights ttlat should not be given to everyone who uses the job. Surrogacy is possibly one answer to this situation. JES networking
Job submission and cancel RACF now provides the facility to control who can submit or cancel a particular job by job name. The new class JESJOBS is used to define the jobs a user can submit and cancel. Previously this level of control was only possible by use of user written exit code. This new control could be particularly useful in an environment where there is extensive end user programming that is not subjected to the level of control normally exerted over system development staff. For this type of control to be effective, it is vital that the installation defines and strictly enforces standard naming conventions over jobs. Otherwise the number of profiles necessary will proliferate to a point where it is next to impossible to maintain.
Surrogate user IDs A n o t h e r new class in RACF 1.9 is SURROGAT. This allows a user to submit a job for another user without having to enter the other user's password (which is clearly a breach of normal security conventions). The 'surrogate' user is defined with the user whose job the surrogate is allowed to submit. When a job is
@1991 Elsevier Science Publishers Ltd
Control over NJE (Network Job Entry) jobs is improved. The receiving node in a JES network can now define the level of trust associated with a sending node and can define what will happen when work is received from that node. This ranges from not accepting any NJE work, through requiring password verification, to accepting all work with no further verification. This is controlled by profiles in the new NODES class. In any event, user IDs, groups and security labels can be defined as necessary entries in NJE headers received from particular nodes. It is also possible to define which specific user IDs, groups and security labels will be acceptable for particular nodes. User IDs can be different at sending and received nodes. A translation facility is available to associate the two user IDs. This level of control is particularly welcome with the increasing use of EDI (Electronic Data Interchange) that can involve the use of NJE between different organizations.
Operator commands IBM appears to have accepted that consoles are now moving out of physically protected computer rooms and are being located
13
Computer Audit Update
increasingly within unprotected offices. There also seems to have been a realization that operators have different levels of knowledge and that division of duties can provide a control over the operation of computer systems. RACF 1.9 now contains the facility to control which MVS and JES commands can be entered, based on user ID, console ID and node ID. A new O P E R C M D S class controls this. Use of commands can be audited by specifying implicitly, or by use of the new LOGOPTIONS (discussed below). HIPERBATCH support HIPERBATCH allows datasets to be stored in HIPERSPACE that is a type of storage that allows many jobs to share the same dataset at the same time. A new resource class DLFCLASS controls which datasets can be used in this way. HIPERBATCH improves performance because batch jobs can execute quicker due to reduced I/O. Although performance can be improved, users should be wary of this facility where datasets are sensitive and some of the batch jobs require exclusive control of the dataset for their correct processing.
May 1991
execute) them using the RALTER command to set the auditing options in the resource profile.
Profile variables Variable qualifiers can now be specified within resource profile names. Another new class, RACFVARS, allows specific names to be defined within a particular variable qualifier. This allows similar resources with radically different names to be protected with the same level of protection using only two profiles. One profile for the resource protection and the other to define the particular qualifier names under a single variable qualifier profile. This enhancement allows for the installation where dataset names are not subjected to stringent naming conventions and allows space saving on the RACF database by reducing the number of profiles required. There is a danger however that the RACVARs variable is not being maintained properly and that the list of possible names is not kept up to date. This could result in access being granted to inappropriate resources, or to resources not being given the correct level of protection.
Global logging options Two new global logging options are available. These are concerned with the logging of all changes and accesses to security labels and to control logging based on class rather than profile. All activity associated with a particular security label or with all resources within a particular resource class can now be logged. This is done using the SETROPTS command. This expands the options for auditing activity.
Auditing of controlled programs Auditing of who executes controlled programs now works! It is now possible to define auditing options on controlled programs to record an audit trail of which users execute (or fail to
14
Long name support The number of characters allowed for a general resource name has been increased from 39 to 246. This will allow more specific protection of JES spool files and other resources where dataset names are particularly long.
Generic profiles There are several changes in the area of generic profile support. In particular, the introduction of a generic owner, restriction of resource access to RACF-defined users and the ability to list catalogued datasets protected by a particular generic profile. Owners can now be specified for generic resources. If this support is active and a user with CLAUTH, who is not the generic owner, attempts
©1991 Elsevier Science Publishers Ltd
May 1991
to create a more specific profile, RACF will prevent this. However, this will be allowed if the user has SPECIAL attributes. This enhancement prevents the creation of more specific profiles where CLAUTH authority is granted. Prior to RACF 1.9, the universal access (UACC) applied to all users of a system, not just to those who were defined to RACF. With RACF 1.9, it is possible to use the ID(*) keyword of t~e PERMIT command to give RACF-defined users the access required while limiting undefined users to the access defined by the UACC. This will allow a UACC of NONE to prevent access by non RACF-defined users while allowing a 'pseudo' universal access to users who have logged on and been authenticated by RACF. Thus a tighter control over universal access can be implemented. Finally, it is now possible, using the DSNS keyword on the LISTDSD command to list all datasets that are protected with a particular generic profile. Qualified general resource names The generic qualifier character (*) can now appear anywhere within a profile name. This character was previously restricted to the end of a profile name. This allows a lot more flexibility in profile naming.
Computer Audit Update
of DOS without having to learn the (sometimes) complex syntax of the operating system commands. This review looks at two different utility packages. These both come under the general heading of hard disk m a i n t e n a n c e and management tools. They can be used to repair damage at a low level, recover from error and can detect potential problems and provide solutions.
MACE UTILITIES V e n d o r - Riva Ltd Price - - £139.00 Mace is delivered on six 5.25 inch diskettes ul~d takes up around 1.7 Mb of disk space. An install program is supplied which copies the software to hard disk and makes changes to the AUTOEXEC.BAT and CONFIG.SYS system files (if required). It also allows the user to group the various utility programs into user levels (e.g. Universal, Intermediate and Advanced) and assign passwords to each level. This can be used to limit particularly powedul utilities to specific users. Unfortunately, there does not seem to be any mechanism for changing passwords. Any auditor will therefore discount such access control as being ineffective.
Alan S Oliphant is the Computer Audit Manager with the Standard Life Assurance Company. Any views expressed are the author's own and not necessarily those of the Standard Life Assurance Company.
All the utility programs supplied can be run as stand-alone programs or can be run from a front end menu. It is this front end menu program which provides the access control via the password controlled user groups. Individual utility programs are not subjected to control when run as stand-alone programs.
PRODUCT REVIEWS
There are basically six groups of utility programs grouped by type of function. In addition, software is also supplied for disk caching (speeding up hard disk access). The six types of utility are described (on the front end menu) as, info/edit, performance, format, solutions, protection and DOS.
Utility software Previous product reviews have looked at the type of utility software generally referred to as file managers or DOS shells. These allow the non-expert user to make use of all the facilities
©1991 Elsevier Science Publishers Ltd
15