COPYRIGHT AND CITATION CONSIDERATIONS FOR THIS THESIS/ DISSERTATION

Transcription

1 COPYRIGHT AND CITATION CONSIDERATIONS FOR THIS THESIS/ DISSERTATION o Attribution You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. o NonCommercial You may not use the material for commercial purposes. o ShareAlike If you remi, transform, or build upon the material, you must distribute your contributions under the same license as the original. How to cite this thesis Surname, Initial(s). (2012) Title of the thesis or dissertation. PhD. (Chemistry)/ M.Sc. (Physics)/ M.A. (Philosophy)/M.Com. (Finance) etc. [Unpublished]: University of Johannesburg. Retrieved from: (Accessed: Date).

2 metrefile Fie Labels F

3 RANDSE AFRIKAANSE UNIVERSITEIT UNIVERSITEITSBIBLIOTEEK Tel VERVALDATUM it 1-7 i A u ett 2 06-c4-18 ON -a- 2 1 S 5 13 APR 200[ 1 4 APR MAR 2001 APR 200i P.h

4 Packaged Software : Security and Controls Audit Review by Chris van Heerden SHORT DISSERTATION submitted in partial fulfilment of the requirements for the degree MASTER OF COMMERCE in COMPU I ER AUDITING in the FACULTY OF ECONOMIC AND MANAGEMENT SCIENCE at the RAND AFRIKAANS UNIVERSITY STUDY LEADER: PROF A du Toit Cape Town January 1994

5 INDEX CHAPTER PAGE NO. OPSOMMING IN AFRIKAANS. ( I ) SYNOPSIS ( VI ) INTRODUCTION 1 LITERATURE SURVEY 7 A FRAMEWORK FOR THE EVALUATION OF PACKAGED SOFTWARE INTEGRITY CONTROLS AND SECURITY FEATURES 51 CONCLUSION 64 BIBLIOGRAPHY 65

6 OPSOMMING PROGRAMMATUUR PAKKETTE: SEKURITEIT EN KONTROLE OLTDITOORSIG deur Chris van Heerden OP SOMNITNG VAN SKRIPSIE INGEDIEN VIR DIE GRAAD M_AGISTER CONfMERCII IN REKENAAROUDITERING IN DIE FAKUL _LETT EKONOMIESE EN BESTUURSWETENSKAPPE AAN DIE RAND SE AFRTKAANSE UNIVERSITEIT STUDTELEIER: PROF A du Toit Kaapstad Januarie 1994

7 Die doel van die opsomming is om die agtergrond, metodiek en gevolgtrekking van die navorsing oor die beheerprosedures en selcuriteitmaatreels van programmatuurpakkette weer te gee. Hierdie opsomming is as volg ingedeel : PROBLEEMOMSKRYW1NG EN DOEL VAN HIER= NAVORSING NAVORS1NGSONTWERP EN METODIEK RESULTA 1 E EN GEVOLGTREKKLNG 1. PROBLEEMOMSKRYW1NG EN DOEL VAN HIERDEE NAVORS1NG Gedurende die afgelope jare vervang maatskappye eie ontwikkelde stelsels met programmatuurpakkette. Hierdie gevorderde pakkette sluit gewoonlik 'n hoe mate van stelselintegrasie in, wat beheermaatreels en prosedures insluit am die sekuriteit en integriteit van toevoer, verwerking, afvoer en berging te verseker. Deesdae word dit dikwels van rekenaarouditeure verwag om hierdie gevorderde programmatuurpaldcette te evalueer om te verseker dat die sekuriteitsmaatreels en beheerprosedures voldoende is om aan die organisasie se behoeftes en standaarde te voldoen. Verder moet daar doeltreffende integriteits- en selcuriteitsmaatreels wees om te verseker dat die rekenaarstelsel deurgaans beskikbaar is, en die sekuriteit en integriteit van die stelsel behoue bly. Dit is 'n besondere uitdaging wat aan die rekenaarouditeur gestel word wanneer hy 'n programmatuurpakket se beheerprosedures en sekuriteitmaatreels moet evalueer. Die programmatuur is grotendeels volledig en word aangepas volgens die maatskappy se behoeftes deur die gebruik van tabelle en parameters. Die beheerprosedures en sekuriteitmaatreels van die pakket word nie ontwikkel volgens die organisasie se spesifikasies the, maar deur die ontwildcelaar van die stelsel. Die ouditeur moet daarvolgens die bestaande integriteit-en sekuriteitbeheermaatreels identifiseer en evalueer am te bepaal tot welke mate hy daarop kan steun en indien nodig, tot welke mate bykomende beheermaatreels nodig is. 11

8 Die doel van die skripsie is om 'n raamwerk te ontwikkel wat gebruik kan word in die evaluasie van die beheerprosedures en sekuriteitsmaatreels van programmatuurpakkette. 2. NAVORSINGSONTWERP, METODIEK EN BEPERKINGE. Die benadering van die navorsing is am 'n raamwerk op te stel wat gebaseer is op die generiese prosesse van gevorderde gekoppelde rekenaarstelsels, naamlik toevoer, verwerking, afvoer en stoor. Vir elke proses is daar kontroles geidentifiseer om te verseker dat die integriteit, beskikbaarheid en sekuriteit van die stelsel behoue bly. Die benadering is om algemene integriteitsprosedures en sekuriteitsmaatreels van gevorderde rekenaarstelsels te identifiseer wat gebruik kan word am programmatuurpalckette daarvolgens te evalueer. Metodiek: 'n Literatuurstudie is gedoen van die mees onlangse gesaghebbende literatuur op die gebied van rekenaarouditeuring, wat deur organisasies wat erken word as leiers op die terrein, gepubliseer is. Die resultate van die studie was genoegsaam om die generiese geoutomatiseerde beheerprosedures en sekuriteitsmaatreels te identifiseer. Beperkinge: Ten einde die studieveld af te baken en sodoende betekenisvolle studie te kon doen, is die volgende beperkings en uitsluitsels gespesifiseer: Slegs aangeleenthede wat direk verband hou met stelselbeheerprosedures en selcuriteitsmaatreels is oorweeg. Ander studievelde soos selektering van die paldcet, beoordeling van stelselfunksies, stelseltoetsing, aanvaardingstoetsing en naimplementeringsouditoorsig is uitgesluit van die studie. Aangeleenthede toepaslik op die oorhoofse sekuriteitsmaatreels en beheerprosedures soos algemene beheermaatreels toepaslik op die rekenaaromgewing, stelselontwerprisiko's, stelselontwerpbeheermaatreels, 111

9 stelselprogammatuur en gebruikerstoepassingsbeheermaatreels is nie in aanmerking geneem nie. 3. RESULTATE EN GEVOLGTREKK1NG Die volgende generiese elemente van gevorderde gekoppelde stelsels is geidentifiseer tydens die literatuurstudie: 3.1 Verwerkingsmetodes, synde gekoppelde intydse, gekoppelde bondel en gekoppelde memo bywerkirig ; 3.2 Generiese transaksievloei naamlik toevoer, verwerking, berging en afvoer; 3.3 Inligtingstelselbeheerprosedures - geldigheid, volleciigheid en akkuraatheid van toevoer, verwerking, berging en afvoer ; 3.4 Identifisering van foute, regstelling en hertoevoerbeheermaatreels, 3.5 Noodsaaklike selcuriteitsmaatreels ; 3.6 Ouditspoor ; 3.7 Verdeling van pligte ; en 3.8 Magtiging. Die volgende tabelle is opgestel gebaseer op die vraag " wat verkeerd kan gaan? " - benadering en welke kontroles in plek behoort te wees om dit te voorkom. Tabel Titel Gekoppelde / intydse toevoer ; Gekoppelde / bondel toevoer ; Eksterne stelselkoppelvialcke ; Verwerking ; BerginOcontroles ; Afvoerkontroles (insluitende ouditspoor) ; en Sekuriteit (insluitende verdeling van pligte). iv

10 Gevolgtreklcing Die navorsing verskaf 'n basis waarvolgens gevorderde gekoppelde programmatuurpakkette se beheerprosedures en sekuriteitsmaatreels geevalueer kan word. Dit het die algemene elemente van groot kommersiele inligtingstelsels geidentifiseer en die beheerprosedures en sekuriteitsmaatreels wat nodig is om die integriteit, beskikbaarheid en selcuriteit van stelsels en data te verseker. Die tabelle behoort nie as 'n kontrolelys gebruik te word nie, maar eerder as 'n gids van moontlik beheerprosedures en sekuriteitsmaatreels aangesien elke organisasie sy eie vereistes het wat nagekom moet word, wat normaalweg verskil van die een organisasie tot die volgende.

11 SYNOPSIS 1.1 PROBLEM DESCRIPTION AND OBJECTIVE OF THIS RESEARCH In recent years large organisations that developed mainframe application software in-house are now purchasing software packages to replace these applications. These advanced packages incorporate a high level of integration and include security and control features to ensure that the integrity of input, processing, output and storage are maintained. Computer auditors are required to evaluate these advanced packaged software to ensure that the security and control features are adequate and comply with organisational standards. Furthermore, they must ensure that the integrity of information systems programs and data are maintained. The auditor faces a unique challenge when evaluating the security and control features of software packages as they are substantially complete and are tailored to organisational requirements by the use of parameters and tables. The security and control features within a package are not developed according to the organisation's specifications but are determined by the developer of the software package. The auditor, therefore, has to identify and evaluate the available integrity controls and security features of the package to determine to what etent he may rely on these controls and if they must be supplemented by other control procedures. The objective of this dissertation is to develop a framework that can be used in evaluating the security and control features of advanced packaged software. 1.2 RESEARCH APPROACH The approach consist of the development of a framework based on the generic processes of advanced on-line systems such as input, edit, processing, update and storage. For each process controls are identified to ensure that the integrity, availability and security of the information systems, programs and data are maintained. 1.3 RESEARCH METHODOLOGY A literature survey was conducted on the latest authoritative publications from organisations who are recognised and acknowledged as the leaders in the field of computer auditing. vi

12 From the results of the literature survey it was possible to identify the generic processes and to identify the automated security and control features that should be in place to ensure that the integrity, availability and security of the system are maintained. 1.4 LIMITATIONS AND EXCLUSIONS Only issues relating to security and control were considered. Other areas such as the assessment of available packages, selection of the package, acceptance testing, system testing, and post implementation review were ecluded Only security and control issues directly related to security and controls for information systems were considered. User controls that form an integral part of any system have not been considered as they are largely dependant on specific organisational requirements Areas that have a direct impact on the overall system of internal control such as general information system controls, system development and related risks, and system software were also ecluded from consideration. 1.5 CONCLUSION The research study resulted in the development of the following tables that will assist the auditor in evaluating security and control features of software packages. Table Name On-line / real time input On-line batch update Eternal system interfaces Processing Storage controls Output controls (including audit trails) Security (including segregation of duties) vii

13 1.6 SUMMARY This research has provided a basis for identifying controls in an advanced on-line information system. It has identified the common elements of major commercial information systems and controls that should be in place to ensure that the integrity, availability and security of the system and data are maintained. The tables should not be used as a checklist to evaluate packaged software but rather as a guideline as to what security and control features should normally be in place. Every organisation's security and control requirements may differ depending on the importance of the application and to what etent the business is dependent on its ongoing availability. viii

14 CHAPTER 1. INTRODUCTION In this chapter the background, methodologies and conclusions of this research study on packaged software integrity and security features are eplained. The issues are discussed under the following headings: 1.1 PROBLEM DESCRIPTION AND OBJECTIVE OF THIS RESEARCH 1.2 RESEARCH APPROACH 1.3 RESEARCH METHODOLOGY 1.4 LIMITATIONS AND EXCLUSIONS 1.5 CONCLUSION 1.6 SUMMARY 1.1 PROBLEM DESCRIPTION AND OBJECTIVE OF THIS RESEARCH Problem description Internal and eternal auditors usually have the opportunity to review the integrity controls and access security features incorporated in the design and development of in-house applications. Where necessary it will be recommended that additional controls and security features be included in the application design to ensure compliance with the required standards. In recent years large organisations who developed their own mainframe application software are now purchasing software packages to replace these applications, for eample, general ledger, accounts payable, accounts receivable, sales, stocks and distribution systems. Vendor supplied system and application software, also referred to as "off-theshelf' software is available for most mainframe applications today. System software required for the functioning of computer hardware function has been available for the last three decades. These packages include applications such as operating systems, communication software, teleprocessing software and data base sytems. Very few companies (if any) develop their own system software because of the compleity of these systems and resources required in such developments. Furthermore, vendor supplied software has proven reliable with adequate support provided by major suppliers.

15 Murphy and Parker (1989) give the following reasons why organisations are now buying application packages in preference to developing their own application software: Cost effectiveness "Most of the widely used applications for business are available as packaged software, since packaged software is usually more cost-effective than inhouse developments of software programs to accomplish common tasks. Packaged software is so widely used that consideration for its acquisition have been added as a procurement portion to many system development methodologies, to provide control over the selection and implementation process" (Murphy & Parker, 1989:1-3). Economy "The major advantage of purchased software is the economy it can offer, compared to designing and implementing systems internally. Further, software maintenance can be assigned to the vendor, helping to lessen the epense incurred by many organisations that keep a staff of programmers to maintain their systems." (Murphy & Parker, 1989:1-7). Etensive Integration "... the etensive integration between systems in most purchased software packages has been one of the major reasons for the rapid growth of their use. The packages normally divide the information recording system into a number of applications or modules that can be used either individually or as part of an integrated system. This allows the users the fleibility to implement the systems that meet their particular requirements while still enjoying the advantages of integration." (Murphy & Parker, 1989:8-23). Software packages are substantially complete and are customised by system parameters and tables according to the organisation's requirements. The auditor therefore does not participate in the development process that results in the incorporation of the security and control deemed necessary for the organisation. These advanced packages incorporate a high level of integration and include controls to ensure the integrity of input, processing, output and storage. Consequently the auditor has to identify and evaluate the available integrity controls and access control features of the package to determine to what etent 2

16 he may rely on these controls. Where weaknesses and deficiencies are identified, compensating integrity controls and user controls should be considered. At the time of evaluating packages it is not possible to check the security and control features in detail due to a number of reasons such as system compleity, unique design concepts and a lack of security - and control-related documentation. Although security and controls are important factors to consider when a package is evaluated, these factors are usually not the primary reasons why organisations purchase a particular package. Therefore, the auditor is faced with an unique challenge when evaluating the security and control features of software packages. He or she is required to identify and evaluate these controls to determine to what etent reliance can be placed on them to satisfy the organisations' requirements, and if necessary, where those security and control features should be supplerriented by user controls. While the literature discusses the difference between in-house and packaged software and refers to the auditor's role in the reviewing packages for security and control features, none of the publications surveyed indicate how the auditor should carry out such a review OBJECTIVE OF THIS RESEARCH The objective of this study is to develop a guideline / framework on how to identify and evaluate the automated controls and security features of purchased on-line software packages. 1.2 RESEARCH APPROACH Integrity controls and security features for advanced information systems may vary from one system to another. However, on-line systems do have certain generic features such as input, edit, processing, update and storage processes. A study was done of advanced on-line information systems to identify the generic on-line processing methods, processing cycles and the transactions processing flow within these cycles. The relevant security and control features that should be in place to ensure the integrity, availability and security of information systems were then identified. 3

17 1.3 RESEARCH METHODOLOGY A literature survey was conducted on the latest authoritative publications from organisations who are recognised and acknowledged as the leaders in the field of computer auditing and who are representative of the organisations that conduct ongoing research in this field. From the results of the literature survey it was possible to identify the generic automated security and controls features that should be in place to ensure that the integrity of on-line information systems is maintained. 1.4 LIMITATIONS AND EXCLUSIONS For the purposes of this research study only information system integrity controls and access control security features were considered. The following issues have been ecluded Auditor's involvement in system developments The auditor's main responsibility regarding system developments is to ensure that the integrity controls, application controls and security features are incorporated in the design and development of the application. Depending on the organisation the auditor may also be required to assist in areas such as: package assessment ; package selection ; acceptance testing ; system testing ; and post implementation review. The emphasis was specifically on audit risk, and not on the broader involvement of the auditor System,software controls General information systems controls System development controls. 4

18 1.4.5 Risks involved in system developments. The risks involved in system development and the implementation of software are of paramount importance to the auditor and should be considered and addressed during the auditor's review. However, this area is a research topic on its own and is not addressed in this dissertation. In his research essay: "Risks in Traditional Computer Development", Du Toit (1989) discusses the primary and secondary risks and the cause for these risks very comprehensively User controls. User controls are an important and integral part of most information systems. These controls have not been considered in the evaluation of packaged software integrity controls as they are largely dependant on the specific environment in which the application is being used. 1.5 CONCLUSION The research study identified the following generic elements as being necessary for advanced on-line systems integrity, availability and security features : Processing methods : on-line real time, on-line batch and on-line memo update ; On-line transaction processing flow : input, processing, storage and output ; Information system processing controls validity, completeness and accuracy of input, processing, storage and output ; Error identification, correction and re-submission controls ; Security features ; Audit trails ; Segregation of duties ; and 5

19 1.5.8 Authorisation. From the above, various tables were developed that can be used in the evaluation of packaged software. These tables deal with on-line system processing methods and transaction processing flows : data preparation, input and edit, processing, storage and output. For each processing method the input, processing, storage and output controls are depicted in the tables based on "what can go wrong", indicating the relevant controls necessary to prevent errors, omissions and possible fraudulent transactions. The indicated control is not necessarily the only control but is based on an available integrity control ; where no satisfactory integrity controls eit, user controls are suggested. The following tables have been developed: Table Name On-line / real time input On-line batch update Eternal system interfaces Processing Storage controls Output controls (including audit trails) ), Security (including segregation of duties) 1.6 SUMMARY This research has provided a basis for identifying controls in an on-line information system. It has identified the common elements of major commercial information systems and controls that should be in place to ensure that the integrity of the system and data are maintained. Although the framework developed was not applied to a specific software application it provides the theoretical foundation that will encourage future research and application in the area of packaged software. 6

20 CHAPTER 2. LITERATURE SURVEY The literature survey is set out under the following headings: 2.1 OBJECTIVES, NATURE, SCOPE AND DEFINITIONS 2.2 ANALYSIS OF REFERENCES 2.3 CONCLUSIONS 2.4 BIBLIOGRAPHY 2.1 OBJECTIVES, NATURE, SCOPE AND DEFINITIONS OBJECTIVES To derive the maimum benefit from the literature survey, the objectives were defined to facilitate a comparative analysis of references. This allows for the identification of the relevant manual and automated control elements and security features that are important to ensure that advanced on-line information systems integrity is maintained. The objectives are: To obtain authoritative views on the on-line systems processing methods, processing functions and the transaction flow within these functions to identify areas that should be subjected to security and controls To obtain authoritative views on information systems control objectives in order to identify the required security and control features that should be present to ensure that these objectives are met To obtain authoritative views on manual and automated aspects of online information system security and control To obtain authoritative views on non-processing controls that should be considered in formalising the security and control requirements. 7

21 2.1.2 NATURE A literature survey was conducted on the latest authoritative publications in the area of computer auditing. Publications from the following organisations were eamined: American Institute of Certified Public Accountants (AICPA), The EDP Auditors Foundation (EDPAA) ; The Institute of Chartered Accountants in England and Wales (ICAEW), The Institute of Internal Auditors (IA); Chartered Institute of Public Finance and Accountancy (CIPFA), International Federation of Accountants (IFA) ; International Chartered Accountant firms ; and Rand Afrikaans University (RAU). The above institutions are recognised as leaders in the field of computer auditing and represent organisations that conduct ongoing research in this field The literature survey was restricted to these publications to ensure acceptance and credibility of the findings of this research essay SCOPE The emphasis of this short dissertation is on the automated security aspects and processing controls that should be considered when advanced on-line packaged software are evaluated. To achieve the objectives of the literature survey it was necessary to eamine the generic computer control aspects and security features applicable to on-line systems Restrictions The following restrictions were placed on the scope of the literature survey. * Only issues that have a direct impact on information systems control and security kssues were considered ; * Control procedures and control techniques are referred to but not dealt with in any great detail ; 8

22 * Hardware and system software availability and reliability were ecluded ; and * Risks involved in the computer system development process were not considered DEFINITIONS Packaged software Jenkins, Cooke and Quest (1992 : 221) define software packages as follows: " Packages are systems developed by computer manufacturers or software houses for the more common and widely used applications such as payroll, sales, purchases and general ledger. The facilities available within each package are fied, but the purchaser can frequently select between available facilities and vary the way in which they are used by means of parameters specified when the system is first set up." 2.2 ANALYSIS OF REFERENCES The analysis is done in the following sections and sub sections: ON-LINE SYSTEMS PROCESSING METHODS GENERIC ON-LINE SYSTEMS TRANSACTION PROCESSING FLOWS INFORMATION SYSTEM CONTROLS CONTROL DESCRIPTION Interface and dependency of manual and automated controls Control identification Data preparation controls Input controls Processing controls 9

23 Processing interruption controls Storage controls Output controls Error identification, correction and re-submission Control evaluation Control testing SECURITY CONSIDERATIONS OTHER CONSIDERATIONS ON-LINE S YS lem PROCESSING METHODS Modern computer systems are often referred to as "on-he real time" or "online batch systems". This distinction has a direct bearing on data input and processing features of the system. The International Federation of Accountants (EFA) identifies the following main categories of processing methods in use : On-line / Real Time Processing. "In an on-line / real time processing system, individual transactions are entered at terminals devices, validated and used to update related computer files immediately." (1989: JAG 20.08). This processing method places a very high demand on computer resources such as memory requirements and disk space and is therefore more epensive than on-line batch processing On-line / Batch Processing "In a system with on-line input and batch processing, individual transactions are entered at a terminal device, subjected to certain validation checks and added to a transaction file that contains other transactions entered during the period. Later, during a subsequent processing cycle, the transaction file may be validated further and then used to update the relevant file." (1989: IAG 20.09). 10

24 On-line / Memo update (and subsequent Processing). "On-line input with memo update processing, also known as shadow update, combines on-line / real time processing and on-line / batch processing. Individual transactions immediately update a memo file containing information which has been etracted from the recent version of master file. Inquiries are made from this memo file. These same transactions are added to a transaction file for subsequent validation and updating of the master file on a batch basis" (1989: IAG 20.10). On-line / batch processing and on-line / memo update processing systems are the most widely used commercial systems because of the lesser demand on computer resources. The processing method has a direct impact on the nature, timing and etent of the data input, processing, storage and output controls GENERIC FLOW OF ON-LINE SYSTEM PROCESSING \ Data capture Data entry Edit / validation Processing Storage Output Fig 2-1 Data processing cycle with data entry via a terminal (adapted). (Davis, Adams and Schaller, 1983 : 136) Fig 2-1 clearly identifies the generic processing cycle of data input, edit, processing, storage and output. 11

25 2.2.3 INFORMATION SYSTEM CONTROLS Information system controls. Gallegos, Richardson and Borthick (1987:155) categorise controls over individual applications as follows: "- Input controls cover authorisation, conversion, completeness of data, and procedures for rejection or re-entry of data. - Programmed, or processing controls deals with actual computer processing and are applied by equipment and software. - Output controls deal with completeness and reasonableness of processing results, as well as the distribution of computer output only to authorised users. - Transmission controls deal with actual transmission of data and information over communication channels." Murphy and Parker (1989:chapter 14 and 15) define the control objectives as: completeness of input and update ; accuracy of input and update ; validity ; and maintenance (storage) Classification The control objectives have been classified as follows to facilitate the identification and defining of the essential control procedures : * Input, processing, storage and output procedures Control objectives: - Validity (authorisation); 12

26 Accuracy; and Completeness. * Security Control objectives: Integrity; - Confidentiality; and Availability. * Other considerations - Segregation of duties; Authorisation; and - Audit trails CONTROLS DESCRIPTION Davis, et al. (1983 : 134) describe processing controls as procedures to prevent, detect and correct errors as the application transactions flow through data preparation, input, processing, storage and output Interface and dependency of manual and automated controls Application controls are a combination of programmed procedures (integrity) and user (manual) controls. "From a software perspective, application controls should be considered as complementary to vendor controls in that, in combination, they should provide a complete picture of information processing operations as they take place within the computer. The application controls that are relevant to information system processing are those that interface or report to the operators of the system." (Gilhooley, 1991:255). The combination of manual and automated application controls will differ from one system to the net, depending on the processing method. Application controls for an on-line real time system will be different to an on-line / batch processing system. The norm is that the more comple the system, the less likely manual intervention becomes. 1-3

27 Boshoff (1985) has proven the interface, relationship and dependency between application controls and integrity controls. The following observations can be deduced from his research study "The interface between application controls and integrity controls in modern computer systems" : The audit objectives for information systems remain the same regardless of how these software applications are developed ; In any computer system there is a combination of integrity and application controls ; Integrity and application controls are a useful classification of control techniques needed to achieve the control objectives ; The techniques used to achieve these control objectives for information systems may change depending on the system that is evaluated ; and Integrity controls may in certain circumstances be regarded as a primary control and application controls as secondary controls depending on the effectiveness of the integrity control. The interface and dependency of integrity controls and application controls in any given system will depend on the following factors : system compleity ; absence of input documentation ; lack of management or audit trail ; lack of control evidence ; electronic authorisation ; application controls not evidenced by output from the computer ; internally (computer) generated transactions ; single source transaction with multiple update tasks ; and record keeping in electronic format. The manual and automated aspects of the transaction processing flows are input, processing, storage and output. For each process flow there should be an adequate combination of manual and automated controls in place to ensure validity, accuracy and completeness of processing. 14

28 Control Identification Controls may be classified as follows: Hardware controls (H) ; System software controls (S) ; Manual controls (M) ; and Application system controls (A). A chart prepared by the U.S. Government Accounting Office based on the System Auditability and Control Study by Stanford Research Institute (January 1977) is used to identify the manual and automated aspects of data processing controls for advanced on-line information systems (Gallegos, et al : ). Modifications and changes to the chart are indicated by an asterisk (*). The transaction processing flow is depicted under the following headings: Transaction origination; Data processing transaction entry; Data communication control; Computer processing; Data storage and retrieval; and Output processing. These are set out in table 2.1 below. 15

29 (a) Transaction origination Control description (*) H * S MA * * * (1.0) Source document origination (1.1) Written procedures Contract (*) Agreement (*) Control documentation User procedures and manuals On-line help (*) On-line data capture procedures (*) (1.2) Source Document Special purpose forms design Source document numbers Transaction identification Cross reference Sequence log Pre-formatted input screens (*) (1.3) Source Document storage Restricted access Accountable source document storage Intermediate storage and transportation Electronic storage (*) (1.4) Source document Dual custody handling (1.5) System generated Access control (*) transactions(*) Contracts (*) Agreements (*) Programmed procedures(*), 16

30 (2.0) Authorisation H S MA (2.1) Source document Access control (*) preparation Segregation of duties Signature On-line verification (*) (2.2) Written procedures Written authorisation (2.3) Approval of source Access control (*) documents Evidence of approval Transaction conflict matri On-line verification (*) On-line authorisation (*) (3.0) Data processing input preparation (3.1) Transaction Transaction numbering identification User identification Schedule desk (3.2) User review of input Manual review (3.3) Batching Batch serial number Limit the number of transactions in batch Batch and balance source data at point of origin (3.4) Logging Logs of source documents Transmittal between organisations (3.5) Transmittal Transmittal document (continue) Mail and message carrier Physical security input 17

31 (4.0) Source document retention H S MA (4.1) Source document retention characteristics Source turnaround Retention dates on source documents Source document storage inde Electronic media storage (*) (4.2) Filing of source File of source documents. document Batch storage Source document maintained at origin Electronic media storage (*) (4.3) Retention storage Filing in user area Limited access to retention facilities Removal from retention Electronic media storage (*) (5.0) Source document error handling (5.1) Error procedures Written error handling procedures Source document correction procedures Responsibility for error correction On-line help (*) (5.2) Error detection Error logging Visual review of source document Programmed procedures (*), 18

32 H S MA (5.3) Error correction Error notification processing Identification of error correction (5.4) Corrected data Verification of re-entered data resubmitted Monitoring of error corrections (b) Data Processing Transaction Entry (1.0) Transaction batch H S M A data entry (1.1) Written procedures Control documentation User procedures (1.2) Physical hardware Location of data conversion operations Simultaneous recording 2.0 Terminal data entry (2.1) Terminal software Security of data entry terminals features Pre-formatting Interactive display Computer aided instruction User application system access Terminal authority levels Data access matri Master commands Terminal sign-on procedures Review of terminal assignments. (2.2) Hardware control Terminal features features Intelligent terminals 19

33 (3.0) Transaction data verification H S MA (3.1) Transaction Key verification verification techniques Pre-programmed keying formats (3.2) Data content Editing and validation routines validation Transaction data cut-off techniques Passwords (4.0) Batch proof and balancing (4.1) Data input controls Processing schedule Turnaround documents Cancellation of source documentation Logging (4.2) Proof and balancing methods Manual check of control figures Batch control Batch header records (4.3) Error detection Error display Unauthorised access attempts Error listings (5.0) Transaction entry error handling (5.1) Error correction Corrective action Warning messages Error messages 20

34 (c) Data communication controls (1.0) Message input HS MA (1.1) Hardware related Electronic identification code (1.2) Software and procedure related Secure phone equipment rooms Network configuration polling table Sending message identification Security table Communication system control log (2.0) Message transmission (2.1) Hardware related Communication line routing Line conditioning Automatic store and forward Automatic dial backup Modern loop back switch Forward error correction Validity checks Echo checking Message interrupt function Packet switching networks Local loop security Encryption techniques Multipurpose modems Backup modems Backup lines (2.2) Software and Transmission batch controls procedure related 21

35 (3.0) Message reception and accounting HS MA (3.1) Hardware related Detection with re-transmission Backup electrical power (3.2) Software and Validation procedure related Line usage records Message sequence number Input / output message log Dialup modems Message backup log Error recording Error correction procedures (d) Computer processing (1.0) Computer process integrity H S MA (1.1) Transaction identification Transaction codes Monitoring computer generated transactions (1.2) Computation and Control totals logic Default options Anticipation control Dual fields Arrhythmic accuracy Eception reporting File control totals File completion checks (1.3) File maintenance Balancing the computer file, Dummy records 22

36 H S MA (1.4) Computer operations personnel Operator instructions Computer program run book Computer console Display messages (2.0) Computer processing error handling (2.1) Error reporting Batch control header balancing Production report of rejected conditions (2.2) Error correction Automated error suspense file Discrepancy report Error serial number (2.3) Corrected data Destructive update re-submission Error suspense re-entry (e) Data storage and retrieval (1.0) File handling H S M A (1.1) Library Operating procedures On-line library Source program statement library (1.2) File access Conflict prevention features Group files File classification Database control table 23

37 Passwords Program linkage control table Header / trailer labels System inquiries System logging Manual authorisation of security table H S MA (1.3) File maintenance, Folio number Before and after looks Masterfile changes Dormant files Ecessive activity Scanning of critical files (1.4) Backup Activity tape Separate computer Copy master files Backup procedures Disaster plan Recovery procedures (1.5) Electronic source document retention Restricted access (2.0) File error handling (2.1) Error reporting Operator intervention Comparison Programs (2.2) Error correction Restart procedure Backup file usage (2.3) Correction re-entry Job stream log, 24

38 (f) Output processing: (1.0) Data processing balancing and reconciliation H S MA (1.1) Data processing Reconciliation transaction log control group Computer console log System output logs Record of output reports (1.1) Data processing Monitoring process flows control group Job control card review Graphical charts (2.0) Output distribution (2.1) Output handling Handling procedures for computer output Output report distribution Report copies (3.0) User balancing and reconciliation (3.1) Monitoring procedures User departments changes in master files Report heading Transaction tracing list Internally generated transactions Control totals (3.2) Testing procedure, Statistical sampling of final report List of all transactions 25

39 (4.0) Record retention H S MA (4.1) User retention and disposal methods Waste disposal procedures Elimination of unused reports (5.0) Accountable documents (5.1) Accountable document handling Negotiable document storage Printing of additional sequence number on pre-printed forms On-line storage (6.0) Output error handling (6.1) Error reporting Independent history file of errors Ageing open items Error logging by control groups Output activity review (6.2) Error correction Identification of error Error correction processing Correction procedures Responsibility for error correction 6.3) Correction re-entry Error logging Verification re-entered data Monitoring of error conditions Table 2.1 Internal Controls for automatic data processing. (Gallegos, et al., 1987: ). 26

40 Data preparation controls The nature and etent of data preparation controls depends on the technology used in data capture. * Data capture activities Data preparation techniques are normally applied to batch processing systems where data is recorded on documents and then converted to a machine readable form. Davis, et al. (1983: 38) define data preparation activities as follows: The manual review of source documents, if necessary, corrections, additions and deletion of data ; - Preparation of documents for processing controls, using techniques such as batches and batch control totals ; Transcription to machine readable format, verification of the correctness thereof and validation of some data items ; and - Conversion from one machine readable form to another. * On-line data capture and on-line help facilities Most advanced on-line systems have data capture and on-line help facilities that users of the system can refer to during on-line data capture. This information is based on the system parameters defined in tables and system files Input controls The main objective of input controls is to identify and correct errors as early as possible in the processing cycle. Davis, et al. (1983 :171) relate the input method to the control technique and the relevant data validation techniques as follows: 27

41 Direct terminal entry and immediate processing of transactions with immediate data validation ; Immediate terminal entry of transactions, which are stored for subsequent processing with immediate data validation or / and delayed validation processing ; and Periodic preparation of batched transaction documents and periodic processing of the batched transactions. (a) On-line systems Jenkins, etal. (1992 : ) classify these controls as follows: * Edit and validation checks Edit and validation routines are used to ensure the accuracy and completeness for on-line input. The main edits checks are: - Format checks Format checks are designed to ensure the data format is valid and accurate, for eample, correct date format and alphabetic or numeric character fields only. - Screen checks Interactive programmed processing techniques reduce the likelihood of transactions being incorrectly recorded. Eamples of screen checks are formatted input screens, the electronic equivalent of pre-printed input documents, program prompts for the net logical input by moving to the appropriate part of the screen and echo checks whereby the operator verifies the information as it is punched into the system. - Eistence checks 28

42 Programmed routines that prevent processing of input data unless the information matches related standing data or tables such as valid company number, customer number and product code. - Check digit verification This is a programmed technique to detect transcription and disposition errors. A redundant number is added to the permanent data record such as a general ledger account number. * Reasonableness checks Programmed procedures to check ranges and limits of input data based on pre-defined parameters or tables. * Dependency checks Dependency tests detei mine if there is a logical relationship between two or more data elements in an input data record, for eample customer number and customer name. Linked to dependency tests are default options that alleviate further input, that is based on the customer number the customer name is automatically entered in the required input fields. Gilhooley (1991:271) identifies a further category namely: * Mandatory input fields Mandatory input fields ensure completeness and accuracy of input by not allowing any further processing unless the required input is made. Normally an error message is displayed indicating the nature of the error for eample when a transaction code is entered that is not defined to the system it will display an error message: "invalid transaction code". 29

43 * Duplicate recording of transaction data Programmed routines that match current input data to historic data is one way of detecting duplicate recording of transaction data. On identification of a duplicate transaction the system should prevent further data input. * Eception reporting Entries that do not pass the editing rules in the application system should be listed in an eception report and followed up by the users of the system. (b) Batch systems On-line real time processing is used in combination with batch processing to ensure maimum utilisation of hardware and software. "On-line input with memo update processing, also known as shadow update, combines on-line / real time processing and on-line / batch processing. Individual transactions immediately update a memo file containing information which has been etracted from the recent version of master file. Inquiries are made from this memo file. These same transactions are added to a transaction file for subsequent validation and updating of the master file on a batch basis" (1989: JAG 20.10). Gilhooley (1991:271) categorises input validations and edit checks applicable to batch systems as follows: * Batch header Every batch should have a batch header with details of the application and summary details on how the completeness and accuracy of processing will be assured. * Control total reconciliation 30

44 There should be a reconciliation process in place to ensure the integrity of processing. Hash total checks This is a common and effective control to ensure accuracy and validity of processing. Crossfoot and balance checks All batches should have crossfoot and balance checks in place that will enable users to balance input to output. Record count There should be a record count of the number of transactions in the batch which is used for input and output balancing. In a batch only environment the validation and editing techniques as defined for on-line editing will be applied during the processing stage. Eternal system interfaces Eternal interfaces are data output from one system required as input for the net system. An eample is data from the payroll system that is required as input for the cost centre epense analysis system. Control techniques are run to run control totals and record count totals., data edit and validation routines and eception reporting to ensure the accuracy and completeness of processing. System generated transactions Transactions can be generated by the information systems based on predefined conditions, for eample the generation of a purchase order when stock levels go below a certain level. 31

45 Control techniques to maintain validity, accuracy and completeness are access control and strong user controls that ensure that the conditions on which the transaction generations are based, remain valid in times of changing circumstances Processing controls * On-line systems On-line systems consist of the following components that enable users to access data and programs: Telecommunication software ; Transaction processing software ; Application system software ; Data base management systems ; and Operating system software. Should components (a), (b), (d) or (e) fail it will affect all on-line applications. Controls applicable to this scenario are not dealt with in this research dissertation. The application system software component (point c above) should have automated and manual controls in place to ensure that processing is carried out accurately and completely. Eamples of controls are daily reports produced by the system that states successful completion of the update tasks and user controls such as balancing system output to input. * Batch systems Sufficient manual and automated controls should be incorporated into the application systems to ensure accuracy and completeness of processing. Gallegos, et al (1987: ) give the following eamples of batch system controls: 32

46 Tape header and trailer labels Header and trailer labels are records containing information about the tape such as identification, control and retention details. This control prevents accidental changes to, or destruction of the tape. File verification The verification of the file version is crucial for reliable processing. This checks that the correct generation of the file is used for processing. File labelling This procedure identifies the tape or disk which must reconcile with the application control details before processing can continue. Run to run controls These totals should be maintained to ensure that no records are added, deleted or lost during processing. Warning and error messages Depending on the nature of the error detected during processing, warning / error messages will be printed. In the case of warning messages processing will normally continue, allowing for subsequent follow up by the user. In the case of an error condition, processing of the records will not be completed until the record has been corrected. Eception reports listing the errors in input. All records that do not pass the validation process should be logged and printed on a report for the users to follow up, correct and resubmit for processing. 33

47 * Computer processing operation controls Computer resources should be used in such a way that the organisation derives the maimum output from its investment in information technology such as hardware, software and human resources. Adequate controls and procedures should be in place to ensure that processing is done in an orderly manner to ensure validity, accuracy and completeness during data input, edit, processing, storage and output. The major elements of computer processing operations are: Access control features ; Library management ; File management ; Operations ; Input / output controls ; Performance monitoring ; and Backup and recovery. All advanced on-line real time systems will have these elements in place but may handle them differently depending on the organisation's requirements. Generally there are procedures and controls in place for the following: Access control features Eternal security software ; and System software security components. Library management On-line library system ; Test and production libraries ; Source and object program code ; and Change control procedures. File management Header and trailer labels ; File classification ; 34

48 File completion checks ; Checks built into programs to prevent processing the incorrect volume ; Dormant files ; Monitor ecessive activity ; and Scanning critical files. Operations Operating scheduling manual ; Thorough operators training ; and Check of operators log. Input / output controls Values of internal tables ; Wrong default values ; and Incorrect program parameters. Performance monitoring System logging ; and Capacity. Backup and recovery System software ; Application software ; Data ; Retention policies ; and Contingency planning Processing interruption Processing interruptions may occur because of hardware, system or application software failure. 35

49 Recovery procedures and controls should be in place to ensure the minimum information loss in the event of a processing interruption. The accuracy and completeness of processing should be ensured to prevent any transaction from getting lost or processed more than once. If anything goes wrong during processing, error messages should be displayed and eception reports printed to notify the users that a system failure has occurred and the impact on data processing. * On-line processing interruption and operating controls Breakpoint in processing Checkpoint and restart techniques allow the application system to be restarted from a defined point in the run. These controls minimise business disruption in the event of a system failure. - Backup provisions This includes aspects such as hardware, system software, application software and data backup procedures. Important issues to consider are the number of generations, generation data groups (GDA), backup copies and off-site storage. File usage controls These are procedural controls that include aspects such as eternal labels and access controls to ensure that only authorised users have access to the files. Database access controls Data base access controls prevent accidental and unauthorised disruption of processing facilities. - Recovery and restart techniques In the event complete system failure, adequate backup and recovery procedures enable the organisation to recover from the event and resume processing without any data loss. 36

50 * Batch systems Disruption during batch processing results in abnoinial program termination. In the event of an interruption during a batch run, processing, is normally stopped and restarted. However, in the case of long batch runs checkpoints and restart techniques that allow the application system to be restarted from a defined point in the run should be in place Storage controls The control objective of storage controls is to ensure that the application data is securely controlled between and during eecution of the application system. Data may be stored on paper, tape, cartridge or on disk. It is imperative that storage controls maintain system integrity. Brown (1989 :16) defines integrity as data, software and data base integrity. * Data integrity Controls to ensure that the data is complete and correct. * Software integrity Controls to ensure that only authorised changes are made to software and that the software meets the requirements for reliability, availability and confidentiality. * Data base integrity Controls to ensure the overall integrity of data maintained by the data base management software Output controls Distribution Controls Only authorised personnel should have access to reports printed by the application. 37

51 Output reviews Prior to distribution the output should be scrutinised for completeness and accuracy. * Output balancing Output from the system should be balanced and reconciled to input. This is important process to ensure the accuracy and completeness of the update process Error identification, correction and re-submission * Timing of errors Errors may occur during input, processing, storage and output stages. On identification, procedures at each processing stage should ensure that errors are corrected and resubmitted for processing. This process may be manual, automated or a combination of both. Display of errors An error message should be displayed upon error detection and further processing should be prevented until the error has been corrected. Warning messages A message should be displayed upon detection of an invalid condition. This normally allows users to override the warning message and carry on with the task. Error logging All errors should be logged to ensure that they are followed up, corrected and re-submitted for processing. Error notification, correction and re-submission for processing Davis, et al. (1983:161) describe the process as follows: 38

52 The way erroneous transactions are corrected and re-submitted for processing depends on the type of transaction and other control considerations. These are: to return the transaction to the originator ; to hold on to a common error suspense file for correction ; to process the data with an error flag ; and to write a suspense record in an application file. * Errors follow up reporting An age analysis report of the error log should be printed on a regular basis for follow up by the users Control evaluation Identified controls must be evaluated to determine adequacy in terms of preventing, detecting and correcting errors, therby reducing business risk and eposure Control testing After the identification and evaluation process, the controls need to be tested to ensure that they operate as designed and implemented Security considerations Auditors are often required to evaluate the adequacy and effectiveness of online systems security features. It is not always clear how information systems security fits in with the auditor's overall responsibility and why it is important for him to eamine this. This section will address information systems security and eamine aspects such as: 39

53 the relevance of information security to the auditor; the meaning of information security; the role of logical access security as part of the overall security policy; how logical access security impacts on the information system; what logical access control intends to protect ; and manual and automated aspects of access control software Relevance to the auditor Jenkins, et al. (1992:511) summarise the relevance of information systems security to the auditor as follows: "In recent years the rapid improvement in computer facilities have led to an unprecedented increase in use of automated systems to communicate, process and store information. Today data processing and information systems have become critical components in ensuring the continued operation of an organisation's business activities as well as being used for processing and storage of financial data. Businesses are more and more dependent on the availability of their computer resources for their daily operations, and in many cases could not continue to operate if deprived of them." Definition Information technology security can be defined as the control structure established to manage the integrity, confidentiality and availability of information systems, data and resources. It encompasses a wide range of measures that are intended to control the broad spectrum of data security elements in organisations. These measures may be manual, automated or a combination of manual and automated procedures Security model Jenkins, et al. (1992:516) refer to a model for information systems security. This consists of the following four elements: (a) The foundation 40

54 The basis for good security is the attitude of an organisation's senior management. This can be demonstrated in practice by: a statement of policy on security; the allocation of responsibilities for security; and high levels of awareness of security issues. Baseline controls These are control procedures generally accepted as standard good practice. System specific controls Certain controls are system specific such as logical access control. Management process Management commitment and involvement are significant factors in the establishment of the level of control consciousness that is the basis for the system of internal control and the framework within which the organisation operates. The four elements are essential for an effective and efficient security policy Security policy. The information system security control objectives being integrity, confidentiality and reliability are met through the implementation of an effective information system security policy. An organisation's security policy may include some of the following main elements: Personnel policies ; Physical access controls ; Logical access controls ; Application system development ; Change management; 41

55 Business resumption plans ; Microcomputer security ; Telecommunications security ; and. Installation management. These policies ensure that the organisation is managed and safeguarded against security threats, risk and eposures Security threats, risks and eposures Jenkins, et al. (1992:517) identify the following threats to computer security: Hardware damage or breakdown ; Fraud ; Theft ; Misuse of information ; Sabotage ; Pervasive or significant data or programming errors ; Operating errors ; Personnel problems ; and Hacking and computer viruses. The Institute of Internal Auditors (IA) (1991, module 9, 9-4) identifies the following information system risks: Human errors, accidents and omissions ; Dishonest employees ; Disgruntled employees ; Outside individuals ; Environmental damage ; Electrical fluctuations and outages; Natural disasters and other physical threats ; Civil disruption ; and Introduction of harmful code. 42

56 Gilhooley (1991:93) identifies the following types of computer system eposures: Erroneous record keeping ; Unacceptable accounting ; Business interruption ; Erroneous management decisions ; Fraud ; Statutory sanctions ; Ecessive cost / deficient revenue ; Loss or destruction of assets ; and Competitive disadvantage. Gilhooley (1991:93) identifies the following causes of eposure: Loss of data ; Distortion of data ; Unavailability of data ; Outdated information ; and Human error. Each threat, risk and eposure needs to be evaluated to determine the probability of the event and the impact that it may have on the information systems in operation. The control requirements to prevent, detect and to correct the event must be identified, the control identified and the effectiveness thereof evaluated Security controls There are two basic types of security controls to prevent, detect and correct against threats, risks and eposure namely: Physical security Physical security includes all measures to protect information systems such as environmental controls, operating controls, organisational controls, policies and procedures, education program and physical access controls. Eamples are terminal access security and backup and recovery procedures. 43

57 * Logical security. Logical access controls consist of programmed procedures that allow authorised users of information systems access to resources and data. Access procedures normally consist of a user identification, user authentication and a control that allows the user access to the system. This control is normally in the form of a password. These access rights are based on pre-defined access rules based on what the users need to perform their daily tasks. Normal access rights are: General system access ; Direct access to specific items of data ; and Access to specific items of data that are application specific. Access is further defined as read, write, update and delete. It is important that application access controls are adequate to ensure that the overall information system control objectives are met. When an advanced information system is evaluated for security purposes logical access control, being an integral part of the application, will be the most important security feature to consider. Logical access control is one of the most effective techniques available to prevent unauthorised access to information systems resources and data. Properly designed system access control can protect against unauthorised access and limit the potential for error by restricting a user to his area of responsibility. To implement an effective system of access control, it is necessary to identify what resources need to be protected and who needs access to those resources. In section conflicting and restrictive user access rights are defined. 44

58 Logical access control identification User Application users Application programmers System programmer Computer operation Resource s Application Prod Yes (1) No No No data Application Test No Yes (1) No No data Application Prod No Yes (1) No No program libraries Application Test No Yes (1) No No program libraries Job libraries Prod No No Restricted (3 ) Restricted (4) Job libraries Test No Yes (1) Restricted Yes (1) (3 ) Utilities No Restricted (2) Yes (1) No System libraries No No Yes (1) No Access allowed but restricted on a need to know basis Use of sensitive utilities should be logged All access is logged Eecute only for operators and update logged for job scheduling Prod = Production system Test = Test system Table 2-2 User / resource access authorisations. (Murphy & Parker, 1989:31-17) Sound access control software characteristics The NA (1991, module 9: 9-48) lists the following guidelines for good systems access control : 45

59 "* Access to the system is restricted to authorised individuals ; Access to the processing functions of application software is controlled in a manner that permits authorised users to gain access only for the purposes of performing their assigned duties and precludes unauthorised persons from gaining access ; * The access rules or profiles are established in a manner that restricts departmental employees from performing incompatible fiinctions or functions beyond their responsibility and that enforces a separation of duties ; Procedures are enforced so that application programmers are prohibited from making unauthorised program changes ; Users / application programmers are limited to the specific types of data access ( e.g. read, update) required to perform their functional responsibilities ; Security profiles or tables are protected from unauthorised access and modifications. Access to these profiles or tables is restricted to certain access paths ; Security profiles or tables are encrypted in order to restrict unauthorised use ; Security profiles override capabilities are restricted ; Security data and resources access audit trails including audit trails of the use of the access control software, are protected from unauthorised modification ; and Modification or changes to access control software itself is restricted to the appropriate personnel, and those changes are made according to authorised procedures." Logical access control testing and evaluating The effectiveness and efficiency of a system must be tested to ensure that it operates as defined. 46

60 2.2.6 Other considerations Segregation of duties Division of duties may be imposed using access control features. The effective enforcement thereof will be largely dependant on how sophisticated the access control features are in the given system and how strictly they are enforced. An access control conflict matri should be used to identify incompatible transactions in user profiles Authorisation Logical access control can also be viewed as an authorisation control. Users are authorised by management to use information systems in a prescribed manner to perform their required tasks. This type of authorisation is also referred to as implicit authorisation. The reliability of this control will largely depend on the effectiveness of the information system environment where adequate general controls, integrity and application controls are strictly adhered to. Some advanced systems have certain on-line verification and approval capabilities. Users are allocated functionality's that enable them to verify or approve a transaction on-line as part of their job requirement. The validity and effectiveness of using access control features as an authorisation control or to enforce division of duties does not form part of this research and are not further dealt with in this paper Audit trails * Purpose and format It is imperative for software applications to have an adequate audit trail. The format of the audit trail may be in hardcopy or electronic format. Gallegos et al. (1987 : 632) describe the purpose of audit trails, also referred to as management trails as to trace transactions from origination to summarisation and visa verse. In advanced 47

61 systems the audit trails are mainly in electronic media such as tape and disk. Eamples of audit trails in advance systems are: System generated transactions ; - Comple computations ; and Eception reports. * Transaction identification Every transaction in the system should have a unique identity by assigning a serial number, sequence number or a transaction code. * Transaction numbering and cross reference Every update transaction (new, change or delete) that is entered into the system should be assigned a unique reference number and logged as part of the audit trails of the system. The document should be cross referenced to the transaction. * Transaction data cut-off To ensure accuracy and completeness of data cut-off, on-line systems have the capabilities to allocate the transaction to the correct accounting month based on the data format. Controls should be in place to restrict the posting to prior or future accounting periods. * Detection of missing transaction Advanced on-line systems should have programmed routines to check that all document numbers are accounted. Missing document numbers should be logged and an eception report printed for subsequent follow up by the users. The errors should not only be corrected but the reason why the errors occurred in the first place should be determined and rectified. 48

62 2.3 CONCLUSION In the writers opinion the objectives of the literature survey have been achieved. In the net chapter the controls for each processing flow will be summarised in the format of matrices that will enable the auditor to evaluate the security and controls for advanced on-line systems. 2.4 BIBLIOGRAPHY BOSHOFF, WH 1985: The interface between application controls & integrity controls in modern computer systems. Johannesburg : Rand Afrikaans University. BROWN, N 1989: Securing and controlling on-line systems ; Auerbach, article number Boston : Auerbach EDPAuditing. DAVIS, GB; ADAMS, DL & SCHALLER, CA 1983 : Auditing & EDP ; second edition. New York : American Institute of Certified Public Accountants. DU TOIT, A 1989: Risks in traditional computer system development. Johannesburg : Rand Afrikaans University. GALLEGOS, F; RICHARDSON, DR & BORTHICK, AF 1987: Audit and control of information systems. Ohio: South-Western Publishing. GILHOOLEY, IA 1991: Information systems management control and audit. Florida: The Institute of Internal Auditors (USA). INTERNATIONAL STATEMENT ON AUDITING 1989: IAG 20 - EDP environments - on-line computer systems. New York : International Federation of Accountants. JENKINS, B; COOKE, P & QUEST, P 1992: Audit approach to computers; fourth edition. London: The Institute of Chartered Accountants in England and Wales. MURPHY, A & PARKER, XL 1989: Handbook of EDP auditing ; second edition New York: Warren, Gorham & Lamont. 49

63 THE INSTITUTE OF INTERNAL AUDITORS RESEARCH FOUNDATION 1991: System auditability and control report. Orlando: The Institute of Internal Auditors (USA). 50

64 CHAPTER 3. A FRAMEWORK FOR THE EVALUATION OF PACKAGED SOFTWARE INTEGRITY CONTROLS AND SECURITY FEATURES. In this chapter, various matrices are presented on how packaged software integrity controls and security features can be evaluated. This is dealt with under the following headings: 3.1 INTRODUCTION 3.2 MATRICES 3.3 CONCLUSION 3.1 INTRODUCTION The research study in chapter two identified the generic computer control aspects and security features to ensure that the integrity, availability and security of online information systems are maintained. These are: Appropriate processing method being used depending on the requirements of the system ; Identifiable on-line transaction processing flows such as input, eternal interfaces, processing, storage and output ; Adequate information system controls : validity, completeness and accuracy of input, processing, storage and output ; Error identification, correction and re-submission controls ; Adequate security features ; Adequate audit trails ; Segregation of duties ; and 51

65 3.1.8 Authorisation. For each processing flow that is on-line real time input, on-line batch input, eternal system interfaces, processing, storage and output matrices have been prepared listing the controls that should be in place to ensure that the integrity and availability of the system are maintained. A matri was prepared listing the essential security features that should be in place to ensure the security elements of a system is secured. 3.2 MATRICES The matrices are based on the question - "what can go wrong? "in the left hand column and the relevant automated control that may be in place to prevent or detect anything from going wrong in the net column. Where applicable, the relevant corrective controls that should be in place are indicated. In the last column, reference is made to the relevant section in chapter two where the control was discussed. The matrices are: Table Name 3-1 On-line input 3-2 On-line batch input 3-3 Eternal system interfaces 3-4 Processing 3-5 Storage 3-6 Output (including audit trails) 3-7 Access security (including segregation of duties) The matrices are mainly directed at automated control and security features. In all commercial systems there will be a certain amount of user controls. The emphasis should however, be firstly on identifying the integrity control in place that can be relied on, and if necessary, the required user control. Where user intervention is required, reference is made to 'user controls'. These have not been dealt with in any detail as user controls are dependent on a specific environment in which the application is used. 52

66 What can go wrong? Control Reference 1.1 Unauthorised data input or changes to eisting data Terminal access control On-line access control (a) (b) On-line verification On-line authorisation Segregation of duties Incorrect or incomplete recording of a transaction Mandatory input fields Edit and validation routines Reasonableness checks Dependency checks Check digit verification (a) (a) (a) (a) (a) On-line help On-line data capture procedures Pre-formatted input screens Echo checks Interactive processing (a) (a) (a) Transaction identification Transaction numbering Transaction data cut-off Default options (a) Cross reference

67 What can go wrong? 1.3 Duplicate recording of transactions data 1.4 Erroneous system generated transactions Control Programmed routines that match input data to prior data input. Sequence log Transaction numbering Eception reporting Access control Reasonableness checks User controls Eception reporting Reference (a) (a) System interruption Error message display Recovery and restart techniques Loss of transaction entry Automatic numbering of input transactions Programmed routines to check that all document numbers are accounted. Error logging Eception notification Insufficient error correction procedures Error logging Ageing of data error log Table 3-1 On-line / real time input 54

68 What can go wrong? Integrity control Reference 2 I Unauthorised access Access control Incorrect or incomplete recording of a transaction Reasonableness checks Dependency checks (a) (a) On-line help On-line data input procedures Pre-formatted input screens Echo checks Interactive processing (a) (a) (a) (a) Transaction numbering Cross reference Error display Error listing Eception reporting Transaction not processed or processed more than once. Batch serial number Processing schedule Batch header record Sequence test Control total reconciliation (b) (b) (b) (b) 55

69 What can go wrong? Integrity control Reference 2.3 Transaction not processed or Hash total checks (b) processed more than once (continue) Crossfoot and balancing (b) Record count (b) Transaction numbering Reasonableness checks (b) 2.4 System interruption Error message display Recovery and restart techniques Insufficient errors detection and correction mechanism Eception listing Error listing Error log Ageing of error log Table 3-2 On-line input / batch update 56

70 3.1 Omission of a batch for processing Batch header Clearly documented operating scheduling (b) Delays in processing Operators scheduling Incomplete processing Program to program controls (b) File verification File labelling Run to run controls Warning and error messages Invalid data (eternal interfaces) Data edit and validation routines (a) Eception reporting Inadequate error identification, correction and re-submission input procedures Error identification Error notification Error correction and resubmission Eception reporting Table 3-3 Eternal system interfaces 57

71 What can go wrong? Control Reference 4.1 Use of incorrect version of program On-line library Source statement program library Use of the wrong file or record in Access control processing Conflict prevention features Group files File classification Database control table Program linkage control table Header! trailer labels System logging Before and after looks Masterfile changes Dormant files Monitor ecessive activity Scanning of critical files Use of an incorrect value in internal tables Input validation procedures Eception reports Wrong default values Output controls

72 What can go wrong? Control Reference 4.5 Input of incorrect program Input validation parameters Output controls Precision and rounding errors Adequate testing of programs Data integrity controls Incorrect or incomplete processing logic ContrQ1 totals Default options Arrhythmic accuracy File control totals File completion checks Insufficient processing errors Limited number of transactions in batch identification Batch control header balancing Production report of rejected conditions Error identification Error logging Error notification Error correction , Error re-submission Monitor error corrections

73 What can go wrong? Integrity control Reference 4.9 Processing interruptions Checkpoint and restart techniques Backup procedures Disaster plan Recovery procedures Computer operator errors Thorough operators training Clearly documented operating procedures Checks built into programs to prevent processing the incorrect volume Frequent check of operators log Undetected errors Data integrity controls Table 3-4 Processing 60

74 What can go wrong? Control Reference 5.1 Unauthorised access to confidential information Access control Unauthorised changes Access control Destruction of data Access control Retention policies Backup and recovery Disaster and recovery plan Table 3-5 Storage controls What can go wrong? Control Reference 6.1 Unauthorised changes to source documents 6.1 Unauthorised access to confidential information Access control over electronic storage Access control Inaccurate output Output balancing and reconciling Usability of output - Voluminous of output Eception reports Loss of output medium: - printed report - tapes - disks - cartridges Retention policies Backup and recovery procedures Disaster and recovery plan , System interruption: - incomplete audit trails - inaccurate audit trails Input / output controls Table 3-6 Output controls (including audit trails) 61

75 What can go wrong? Control Reference 7.1 Unauthorised access to the information system programs and data Logical access control User identification User authentication User passwords User access profiles Unauthorised access to security Access control software Audit trails Unauthorised access to production Access control and test data Unauthorised access to application program libraries (production and test) 7.5 Unauthorised access to job, libraries (production and test) Access control Access control Unauthorised access to utilities or the inappropriate use thereof Access control Audit trails Unauthorised access to system libraries Access control 2.2, Access to incompatible Access control transactions 7.9 Access to incompatible transactions Access control Transaction conflict matri Table 3-7 Security (including segregation of duties) 62

76 3.2 CONCLUSION The matrices developed may be used to evaluate packaged software controls and security features. The auditor should however guard against looking for every possible control aspect to be in place as this may lead him to conclude that the package is not properly controlled and secured. All controls should be based on a cost benefit factor, that is what is the cost compared to the value derived from the controls in place.. 63

77 CHAPTER 4 CONCLUSION A framework consisting of various matrices have been developed that may assist the auditor in identifying and evaluating controls and security features of purchased software packages. It is important to note that the auditors objectives and responsibilities do not change with the implementation of packaged software but rather impact on the approach and methods implemented to achieve his audit objectives. Although the matrices developed was not applied to a specific software application it provides the theoretical foundation that will encourage future research and application in the area of packaged software. 64

78 BIBLIOGRAPHY BOSHOFF, WH 1985: The interface between application controls & integrity controls in modern computer systems. Johannesburg : Rand Afrikaans University. BROWN, N 1989: Securing and controlling on-line systems ; Auerbach, article number Boston : Auerbach EDPAuditing. DAVIS, GB; ADAMS, DL & SCHALLER, CA 1983 : Auditing & EDP; second edition. New York : American Institute of Certified Public Accountants. DU TOIT, A 1989: Risks in traditional computer system development. Johannesburg : Rand Afrikaans University. GALLEG-OS, F; RICHARDSON, DR & BORTHICK, AF 1987: Audit and control of information systems. Ohio: South-Western Publishing. GILHOOLEY, IA 1991: Information systems management control and audit. Florida: The Institute of Internal Auditors (USA). INTERNATIONAL STATEMENT ON AUDITING 1989: TAG 20- EDP environments - on-line computer systems. New York : International Federation of Accountants. JENKINS, B; COOICE, P & QUEST, P 1992: Audit approach to computers; fourth edition. London: The Institute of Chartered Accountants in England and Wales. MURPHY, A & PARKER, XL 1989: Handbook of EDP auditing ; second edition. New York: Warren, Gorham & Lamont. 65

79 A57r4'; VAN HI=PP :7:0 0! ,17.77