Controls, Auditing, and Security Analysis
CHAPTER SYNOPSIS
Security of data, physical plant, and processing controls are the major areas which affect business systems. They may make the difference between acceptable and unacceptable systems proposals, and between successful and unsuccessful systems. Additionally, any development project analysis must examine current security procedures and determine the need for any enhancements to them.
This chapter discusses the concepts of security and controls, the areas where they are most needed, the determination of security and control requirements, and their impact on the final system proposal. The chapter also includes discussions of configuration management, change management, system administration and disaster preparedness.
Security
The topics of security, auditing, and controls analysis are usually overlooked during the analysis process. The logical relationship between the three topics is sufficiently tight that they can be treated in one unit; however, they are also different in many respects. Security is the more all-inclusive topic, with auditing and controls being the tools used to ensure that security is maintained. Many areas of security have already been treated in previous chapters, and much of the information gathered during the functional, process, and data analysis phases applies to the evaluation of security requirements of the firm and of specific applications.
Although security should be an ongoing concern for the firm, most firms do not address these issues until the information systems environment has migrated to the third stage of the data processing growth curve and often it is well into the third stage. Thus an analyst working within a first or second stage environment, or even in an early third stage environment, should pay careful attention to this area of analysis (Figure 21.1), since it is in these early stages that security is most likely to be minimal or lacking altogether.
The analyst should also remember that the firm may not be in the same place on the growth cycle in all areas (especially in the personal computer area), and thus each security analysis should be undertaken with the particular growth stage of the particular user and implementation environment in mind.
What Is Security?
Security relates to protecting the firm's records and resources from unauthorized access, modification, or other interference. It includes an analysis of ownership, access, modification, and use, as well as a determination of what protective or restrictive measures must be taken to ensure adequate protection of the firm's files. Whereas the bulk of systems analysis concentrates on determining which processing activities are being done and which should be done, security analysis concentrates on who should or should not be doing those processing activities and when those activities should or should not be done. This examination should not necessarily be carried out from the perspective of functional needs, although they obviously play a critical part in this area of analysis.
We tend to think of security in terms of preventing physical entry; however, by extension it can also be viewed as preventing logical entry as well. In the business environment this determines who should be allowed to access, modify, and remove business records. It is immaterial whether these records are physical or automated. Security is also concerned with record retention and safekeeping. Generally any analysis of security requirements involves answering a series of questions relating to "who can do what with what."
Securing the firm's data and information resources may also entail examining the physical resources which allow access to those data. These resources include printer facilities, data storage (both machine readable and hardcopy), and data access facilities (the most obvious of these being terminals and personal computers).
Generally speaking, security can be said to include (see Figure 21.2)
Security Analysis
Security analysis thus involves making a determination of what must be done, when it must be done, how it must be done, what is needed to do it, and who should be doing it. Security analysis also includes an examination of the physical access points to data.
Security analysis usually begins with an evaluation of securable resources. This is done on the assumption that the more sensitive, valuable, or irreplaceable the resource, the greater the effort which should be expended securing it.
The first set of questions thus involves the material to be secured. Generally this involves an inventory of the firm's files and the records within those files. Included in this inventory should be
This inventory should be as complete as possible, and most of the information should already be available from the environmental analysis documentation. Each item in the inventory should be annotated as to
In some cases there may be more than one person or unit involved in each of the above; in this case, all names should be listed.
Once such an inventory has been completed, the next step is an examination of each of these files and records to determine if they need to be secured. Not everything within the files of the firm needs to be secured, and security may not be needed all the time. For instance, quarterly financial reports need to be secured before publication but not afterward. Likewise, prior to publication, manuscripts should be secured from non-employees, but not after.
This determination of security needs should be done on an item-by-item basis and should evaluate
The answers to these questions should provide the analyst and the user manager with enough information to determine and classify those documents which need to be secured. The classification scheme can be as simple or as complex as is necessary to obtain the desired level of security awareness.
Once the classification process is complete, the analyst needs to determine how to achieve the desired level of security. Since most of the firm's resources, especially its data resources, should be used in conjunction with legitimate, that is, authorized, activities, the analyst should next cross-reference the documents and resources to the activities and procedures which use them and make a determination as to whether those uses agree with the security profiles established for the documents. For instance,
For each activity which includes a secured document, have procedures been established to ensure that the security of the documents are both known and maintained? Are there procedures established to ensure that document security classification is clearly established? Have all procedures which use secured documents been modified to ensure that they include actions which ensure that the security of the documents is maintained when they are not actively being used?
The actions to be taken with respect to these questions may include any or all of the following:
Physical Access Security
It is not enough just to secure the data. The analyst must also determine whether access to the terminals which provide access to the data has also been secured.
In many firms employees are assigned sign-on codes and passwords. Many times these codes and passwords are simple and easy to remember. In many cases these codes are written on the terminals themselves or in plain view. For those applications which require access security, these items should be examined carefully and more stringent procedures should be initiated where necessary.
Personal Computer Security
Because of the great ease with which data can be loaded into or unloaded from these machines and because of the extreme portability and small size of floppy disks, data security becomes a grave issue in those environments where user systems are developed for the personal computer.
The issue becomes even more critical in a network environment where the ability to download or upload data to and from a mainframe and transfer data, files and documentation form machine to machine, from network to network, and country to country, is as easy as retrieving data from the machine’s own hard drive. Although much of the software for personal computers is copy-right protected by the vendors, the simplicity of the data access methods offered by the machines allows almost anyone with even a limited amount of knowledge to read and copy data and software. The copy protection mechanism of the software does not extend to the files the software resides on and anyone with a version of the baseline software can access any user file.
Some packages permit the data files to be secured, but here again, the protection is often rudimentary at best. Although encryption of data (the scrambling and encoding of the data so that it is unreadable without the decryption mechanism or code key) is possible, many firms do not insist upon it, and the difficulty of using these techniques is such that many users dispense with it altogether even where it is available.
The ability of many personal computer users to bypass the protection mechanisms of the vendor software packages, and the ease with which they do so, makes any data security mechanism seem almost transparent.
Aside from these issues, a firm's lack of standards and its inability to enforce those standards compound the problems of personal computer data security.
System Administration
System administration is that set of processes and activities designed to ensure that the network systems operate efficiently. System Administration is responsible for the following actions:
Controls
Unlike security analysis, which seeks to determine the importance of the firm's files and to determine what protective measures, if any, must be applied, controls analysis seeks to determine what measures are needed to ensure that the protective measures are being followed and that the necessary work of the firm is completed accurately. Controls serve two functions:
Whereas security analysis and its resulting measures are administrative in nature, controls analysis is mainly an accounting function.
Controls are used to ensure that
In all of the above cases, the goal is to ensure that what is actually done matches expectations and that the information upon which actions are predicated is accurate.
Normally, controls are applied to actions which
Controls are very similar to quality assurance tests in that the intent is to ensure that all actions have been taken correctly. Normally controls are built into the actual processing steps of an activity; they usually involve verification of manual or automated actions by persons other than those who performed the original actions.
Controls may be applied item by item, such as rechecking order or invoice line item extensions and totals, or they may be applied to groups of documents together, such as generating a grand total of order totals and checking them against a manually generated total.
In our discussion of batch processing, we talked of batch controls (Figure 21.3). These are control totals, which may be in the form of total dollars, total items, total documents, or some other procedure. These totals are accumulated before the data are processed and are compared to the totals from the machine-generated reports. If the totals agree, the batch is assumed to be in balance; if they do not agree, the individual items are examined to determine whether an item was missed or entered incorrectly. When the error is found, the item is corrected and the entire batch is then resubmitted for processing.
Totals are also generated across batches to ensure that all batches are entered. Since most systems generate large reports, financial or otherwise, most reports have one or more levels of totals. They may be totals of numeric columns, total items, etc. If the report is exceptionally large, there may be several levels of subtotals within the body of the report. These are usually at logical breaks in the data and are usually taken at some change in the major report sequence field. Aside from providing information to the report recipient, they also provide a mechanism for checking the report's accuracy and completeness, either on a manual or automated basis.
This type of totaling procedure is also used when files are processed to ensure that the proper number of transactions of each type have been processed, and that records have not been either added to or deleted from the file erroneously.
Controls may also take the form of checklists and signature sheets, where certain information is recorded as steps are completed. This might include start and stop times, item counts, operator or clerk initials, batch numbers, machine meter readings, verifier or checker initials, supervisor initials, etc. Figure 21.4 is a sample batch header form.
The analyst, working with the user and with the work and process flow analysis documents, as well as with the documents themselves, must determine where errors can originate and must devise procedures which can prevent the errors from or detect those errors that do occur.
In other instances, the analyst may have to determine methods for controlling the process themselves. This may entail the creation of control logs or carrier documents which will accompany the documents being processed. Figure 21.5 shows a sample batch control form.
The process of determining which controls to impose is very similar to a checks and balances operation. For instance, controls should ensure that the people who perform a certain activity are not the same ones who check it or that testing or sampling procedures are devised which check work in progress. In some cases, separate subsystems or activities may have to be devised for ensuring that proper controls are in place. These controls could entail summary reports, comparison reports, variance reports, exception reports, statistical analysis, or in extreme cases duplication of processing.
Controls may also take the form of "audit trails" (Figure 21.6), which are reports or files generated from the business transactions of the firm. Each transaction and activity is recorded as it is processed. Each file add, change, and delete, each file access, each program execution, and each document processed is recorded or logged. This ensures that if there were a need to re-create a portion of the work, there would be sufficient information, i.e., a "trail," to do so. It also ensures that if there were a need to determine whether an activity was performed, who performed the activity, or when the activity was performed, there would be sufficient information available to make such a determination.
Most, if not all, DBMS products offer optional logging of transactions to the databases which they maintain. Many make this type of logging mandatory, in that the DBMS will not operate without logging files. Most telecommunications systems also offer logging of the on-line transactions processed by them, as well as logs of all file accesses and changes. Most products offer security facilities, and access violations are logged to these files as well.
The type and extent of the controls to be imposed will often depend upon the nature and sensitivity of the work being performed, on the ability to reproduce the work should it prove to be defective or in error, or on the impact on the firm if any error should continue to be undetected.
To illustrate, it may be acceptable for errors to appear on internal documents, but totally unacceptable for the same type of error to appear on a document which is to be sent to the customer. Again, it may be acceptable for costs to be slightly in error when work is being done internally (such as is common with internal information systems charge-back systems) but unacceptable when pricing an item for sale to a customer.
Aside from the above reasons for establishing control mechanisms, one of the major reasons for controls is improvement of the auditability of the firm's operations by both internal and external accounting functions. These types of controls are usually applied to all activities
Auditing and Auditability
All firms and organizations, both publicly and privately owned, governmental, charitable, profit making, or not-for-profit, must maintain books of accounts which record all business activities; transactions of a monetary nature; and acquisition, use, and disposal of inventory, raw materials, work in process, machinery, buildings and land, furniture and other supplies, stock, etc. In short all assets and liabilities. Periodically the status of these accounts must be reported to the various governmental entities for purposes of tax assessment, licensing, etc. In the case of corporations, partnerships, etc., stockholders and regulatory bodies must receive reports on the financial status of the firm on a periodic basis.
The books of accounts or other records are normally prepared for the firm either by the management of each user area or by the internal accounting areas, although in some cases outside accounting firms may perform this work. Regardless of who prepares the account books, the work of verifying and validating their accuracy and the related accounting functions is usually performed by external or "public accounting" firms, or by certified public accountants (CPAs) who are charged with the responsibility of making sure that such reporting is complete and accurate. These certifications are required by and are acceptable to the various agencies to whom the reports must be made.
These accountants or auditors use various techniques to perform this verification and validation, in most cases relying on the records which result from the controls imposed by the firm for these purposes. In many cases they will run their own tests, reports, etc., to ensure that their results match those provided by the firm.
If in their examination they determine that the controls or records are unacceptable or insufficient to properly verify or validate the business transactions, the auditors may ask that certain additional controls be imposed to assist them in their activities. These controls may take the form of new reports or additions to existing reports. Auditors may also impose requirements on the firm to retain original records for certain periods of time, to retain copies of critical transactions, to generate duplicates of various files and to undertake similar activities, and the analysts may be required to assist the auditors in this work. The analyst must be sure that any statements of requirements include the system verification requirements of the auditors.
The Concept of Time
Time is a vital concept which must be kept in mind during the analysis process, more specifically the changes which occur over time, time dependencies, and the concept that certain things while changing over time may need to be retained as of a certain point in time. The passage of time implies changes in state and in conditions. Things which are valid now may not be valid a few moments from now. These effects of time are incorporated into the data which are stored as a result of business activity and are also incorporated into the things which trigger certain business activities.
Examples of the importance of time are
That same invoice, once mailed, begins to age. The firm needs certain follow-up procedures, at the 10-day point, the 30-day point, the 60-day point (when the invoice is past due), at the 90-day point, etc. Payments against the invoice may be received at any time after invoice mailing. That payment may reflect discounted price, the net price, or the net price plus penalty charges (if any) for late payments. The firm must be able to determine what payment is expected, at what times, and how to evaluate payments received. At each of these points different actions need to be taken, all of which depend upon remembering two points in time: invoicing date and today's date.
Time must be factored into data storage considerations, processing considerations, and most schedules. These time equations must be incorporated into how long it takes to perform an action, how much time can be expected to pass before a response is forthcoming, and when the final action must be taken.
The analyst must determine just how critical the time factor is in the user area and to the user work schedule. The time factor can be measured in terms of seconds, minutes, hours, days, weeks, months, etc. Some schedules are fixed, others are highly flexible. The clerk on the phone with the customer needs information instantaneously, but the correspondence secretary may have information response times of hours and perform in a perfectly satisfactory manner.
Another area where time is relevant is in the controls and audit trails of the firm. Each transaction should be stamped with the date and time as it enters the firm. All changes to the books and records of the firm should also be dated to reflect when the change was made. All reports and documents should be dated, and in some cases time stamped to indicate when they were created or received into the firm.
In some cases only the item itself need be dated; in others it may be necessary to date the entire record with "from" and "to" effective dates and to store those records in historical files or archive files.
The analyst should determine the existence of, and the need for, any historical files or archiving of records as the firm's procedures and activities are analyzed. In many cases new history files may be needed or the procedures for updating old ones may need to be revised. In all cases the analyst should pay attention to these filing systems and to the material stored in them.
Some of the questions which should be asked when analyzing existing filing and archiving procedures are
Configuration Management
Configuration management is that set of processes and procedures which track and manage the structure of things, specifically hardware, software and documentation. Configuration management when applied to information systems manages hardware, software (system and applications) and documentation. In short all items which are subject to change and all items where knowledge of version, interoperability, interconnectivity or simple replacement or repair becomes important.
A Definition:
A configuration is a specific arrangement of items assembled for a particular purpose.
On a very simplistic basis all things are composed of elemental items, components and final assemblies. For instance, a tire, a wheel, a car.
Elemental items should be meaningful within a given context. For instance: within the context of automobile manufacture, the meaningful elemental item is the tire, not the rubber, metal mesh and other chemicals which were used to manufacture the tire. Within the context of tire manufacture the metal mesh, chemicals and rubber are meaningful elemental items.
Components, or assemblies are groups of elemental items assembled in a specific manner to accomplish a specific purpose. Components may be designed or assembled for use within a single context, or may be designed or assembled for use in many different contexts. Components may be combined into larger more complex components.
Final assemblies consist of all components in the completed product. A final assembly is the sum total of the specific versions of the specific elemental items, grouped into specific components, and assembled in a particular manner. This final assemble may also be referred to as a Configuration Item.
Final assemblies decompose into components. Components decompose into other components and finally into elemental items. The lowest level of a configuration is an elemental item
A Configuration Item may or may not include hardware, but it should always include requirements analysis, design, production and operational documentation.
A Configuration Item may be frozen in time, usually after review, approval and implementation. This frozen configuration is referred to as a baseline. A baseline is a known is a frame of reference against which to measure all subsequent change, and may be used to determine if a change has been made. The baseline forms a known starting point for beginning additional change, for making repairs and for assessing problem causes.
Configuration management helps assure that a known operational program was generated from an identified piece of source code, and that a specific version of the product is supported by a specific version of the documentation. Configuration management ties all products across the life cycle to each other and ensures that the final product can be traced back to the original requirements. It also ensures that what is produced is what was agreed to at each review point.
A configuration is associated with a specific product or item, and an item may have many separate configurations. Configurations are maintained at many different levels and almost every item from the elemental unit to the final assembly should be supported by a configuration.
To Illustrate:
It is imperative that all occurrences or copies of an item conform to the same configuration, such as a specific version of package software, or a particular set of application programs. Each user must see the same screens, have the same documentation, manuals and procedures and the software must perform the same way for each user.
In building a fleet of ships or planes, or even cars, each car is slightly different from its siblings, these differences are due to engineering changes made by the manufacturer, design changes requested by the customer, changes in raw material and component sources, or a wide variety of other reasons. Each car, plane or ship functions in a similar manner but each is unique in its construction. It is critical for the maintenance and repair personnel to know exactly what variations are incorporated in a particular instance, from the formula for the exterior paint, to the dimensions of the built in items, location of the bolt holes, wiring differences, model or version differences in electrical or mechanical components, etc. It is for this reason that most physical items where variations can occur carry both model and serial number. This identifies the unique item and can be used to determine its exact configuration if and when required.
There are many levels of configurations and configurations can be documented at many points in the item life cycle. Some configuration points are:
Each configuration from design to installation can be slightly different from its predecessor. At some point, usually after installation a configuration is selected as a baseline.
A Definition
A baseline is an item or collection of items of a particular shape and form used as a reference. A baseline configuration is a reference point for evaluating modifications and enhancements and a starting point for making those changes. This baseline is normally considered the “official” version of an installed and operational Configuration Item.
Software Configuration Item information can include any or all of the following:
Configuration management can be restricted documentation only in which case the configuration manager will maintain strict control of each version of each documentation item. Documentation configuration management can include each separately identifiable and traceable version of each:
Change Management
Change management is closely associated with configuration management. Change management is that set of controls and processes designed to ensure that:
“Checking out” from a baseline, entails flagging the item (e.g. piece of code, documentation, component) such that no other person may used it for purposes of changing it. This ensures that concurrent changes are not made to the same component by different unrelated projects. It also alerts other projects that a change is being made to a specific component and that they must expect those changes, and not plan other changes until the item is “checked in” to the configuration. Once a changed item is “checked in” a new configuration is established. and this new configuration replaces the previous configuration as the official baseline.
Change management is also responsible for maintaining a change history for every component. For each change the following information should be recorded:
Each proposed change should be preceded by a notification to all users that the change has proposed. It should request users to submit a statement describing the impact (or lack of impact) of the change on them. Copies of all user impact statements should be included in the change documentation package. Copies of all user notifications and distribution lists should also be included.
Disaster/Emergency Preparedness
Disaster/emergency preparedness is that set of processes, activities and plans designed to ensure that the firm is prepared for events that are disruptive to the conduct of the business. Business disruptions can be minor or major. Disaster plans must accommodate any type of disruption and have a plan in place to ensure that business activities resume as normally as possible in the minimum amount of time.
The following events constitute business disruptions:
A Business Recovery plan should be in place containing the following information: