CS302: Software Engineering

Guidelines for Security, Recovery, and Audit Control Planning 

The three issues in this section-security, recovery, and controls-all are increasingly important in software engineering. The threat of data compromise from casual, illegal acts, such as viruses, are real and growing. These topics each address a different perspective of data integrity to provide a total solution for a given application. Security is preventive, recovery is curative, and controls prove the other two. Having one set of plans, say for security, without the other two is not sufficient to guard against compromise of data or programs. Trusting individuals' ethical senses to guide them in not hurting your company's applications simply ignores the reality of today's world. Morally, not having planned for attempts to compromise data and programs, you, the SE, are guilty of ethical passivity that implicitly warrants the compromiser's actions. Therefore, design of security, recovery, and controls should become an integral activity of the design of any application. 

The major argument against security, recovery, and audit controls is cost, which factors in all decisions about these issues. The constant trade-off is between the probability of an event and the cost of minimizing its probability. With unlimited funds, most computer systems, wherever they are located, can be made reasonably secure. However, most companies do not have, nor do they want to spend, unlimited money on probabilities. The trade-off becomes one of proactive security and prevention versus reactive recovery and audit controls. Audit controls, if developed as part of analysis and design, have a minimal cost. Recoverability has on-going costs of making copies and of off-site storage. Each type of security has a cost associated with it. Keep the cost issues in mind during this discussion, and try to weigh how you might balance the three methods of providing for ABC's application integrity.

Security plans define guidelines for who should does not use chemicals near computer have access to what data and for what purpose. equipment. Access can be restricted to hardware, software, and data. There are few specific guidelines for limiting access since each application and its context are different. Those guidelines are listed here:

1. Determine the vulnerability of the physical facility to fire. Review combustibility of construction. Determine adjacent, overhead, and underfloor fire hazards. Determine the status of current fire detection devices, alarms, suppression equipment, emergency power switches, extinguishers, sprinklers, and smoke detectors. Determine the extent of fire-related training. If the facility is shared, evaluate the risk of fire from other tenants.

Plan for fire prevention and minimize fire threats by using overhead sprinklers, C02, or halon. Develop fire drills and fire contingency plans. If no emergency fire plans exist, develop one, reviewing it with the local fire department, and practicing the procedures.

2. Consider electrical/power facilities. Review electrical routing and distribution of power. Review the means of measuring voltage and frequency on a steady-state or transient basis. Determine whether operators know how to measure electrical power and can determine both normal and abnormal states. Define electrical and power requirements for the new application hardware and software. Determine power sufficiency for the computing environment envisioned.

Correct any deficiencies before any equipment is delivered. For instance, install a universal power supply (UPS) if warranted by frequent power fluctuations or other vulnerabilities.

3. Review air-conditioning systems and determine environmental monitoring and control mechanisms. Evaluate the 'housekeeping' functions of the maintenance staff.

Correct any deficiencies before any equipment is delivered. For instance, make sure the maintenance staff cleans stairwells and closets, uses fireproof waste containers, and does not use chemicals near computer equipment.

4. Determine the capability of the facility to withstand natural hazards such as earthquakes, high winds, and storms. Evaluate the facility's water damage protection and the facility's bomb threat reaction procedures.

Design the facility without external windows and with construction to withstand most threats. To minimize bomb and terrorist threats, remove identifying signs, place equipment in rooms without windows, and do not share facilities. To minimize possible storm damage, do not place the facility in a flood zone or on a fault line.

5. Evaluate external perimeter access controls in terms of varied requirements for different times of day, week, and year. Determine controls over incoming and outgoing materials. Evaluate access authorization rules, identification criteria, and physical access controls.

Plan the security system to include perimeter lights, authorization cards, physical security access, etc. as required to minimize the potential from these threats. Establish procedures for accepting, shipping, and disposing of goods and materials. For instance, shred confidential reports before disposal. Only accept goods for which a purchase order is available.

6. Evaluate the reliability and potential damage from everyday use of terminals and remote equipment from unauthorized employees.

Plan physical locking of equipment, backup copies of data, reports, etc. to minimize potential threats. Design remote equipment to minimize the threat of down-loaded data from the central database except by authorized users. Usually this is done by having PCs without any disk drives as terminal devices.

7. Evaluate the potential damage from unauthorized access to data and programs.

Protect programs and data against unauthorized alteration and access.

8. Evaluate the potential damage to the database from unwitting errors of authorized employees. 

Design the application to minimize accidental errors and to be fault tolerant (i.e., recovers from any casual errors).

In general, we consider internal and external physical environment, plus adequacy of data and program access controls. Security evaluation is a common enough event in many organizations that checklists of items for security review are available. 3 An example of general topics in such checklists follows:

Physical Environment

Electrical Power

Environment

Computer Facility Protection

Physical Access

An example of a detailed checklist for building access is provided next.

Facility type: Mainframe, LAN, PC, RJE, Remote, Communications

1. Are entrances controlled by

__ locking devices

__ guard force

__ automated card-key system anti-intrusion devices

__ sign-in/out logs

__ photo badge system

__ closed circuit TV

__ other ___________

2. Are controls in effect 24 hours per day? If

not, why?

___________

3. Are unguarded doors

__ kept locked (Good)

__ key-controlled (Better with above)

__ alarmed (Best with both of above)

4. If guard force, is it

__ trained (Good)

__ exercised (Better)

armed

5. Are visitors required to

__ sign in and out be escorted

__ wear distinctive badges

__ undergo package inspection

6. If building is shared, has security been

__ discussed (Good)

__ coordinated (Better)

__ formalized (Best)

7. Sensitive office areas, media storage, and computer areas 

__ Does access authority for each area require management review?

Is access controlled by

__ locking devices

__ guard force

__ automated card-key system anti-intrusion devices

__ sign-in/out logs

__ photo badge system closed circuit TV

__ other ___________

__ Are unique badges required?

__ Do employees challenge unidentified strangers?

8. Control Mechanisms

__ Do signs designate control/restricted areas?

If locks are used

__ is key issuance controlled?

__ are keys changed periodically?

9. Administration

__ Does management insist on strict adherence to access procedures?

Are individuals designated responsibility

for

__ access control at various control points

__ authorizing visitor entry

__ establishing and maintaining policy, procedures, and authorization lists

__ compliance auditing

__ follow-up on violations 

The probability of total hardware and software loss is low in a normal environment. In fact, the probability of occurrence of a destructive event is inversely related to the magnitude of the event. That is, the threat from terrorist attack might be miniscule, but the damage from one might be total. Each type of threat should be considered and assigned a current probability of occurrence. High probability threats are used to define a plan to minimize the probability. If the company business is vulnerable to bomb threats, for instance, buildings without external glass and without company signs are more anonymous and less vulnerable. Having all facilities locked at all times, with a specific security system for authorizing employees and screening visitors, reduces vulnerability even further.

The major vulnerability is not related to the physical plant in most cases; it is from connections to computer networks. The only guaranteed security against telecommunications invasion is to have all computers as stand-alone or as a closed network with no outside access capability. As soon as any computer, or network, allows external access, it is vulnerable to invasion. There are no exceptions, contrary to what the local press might have you believe. Data and program access security protection reduce the risk of a casual break-in to an application. Monitoring all accesses by date, time, and person further reduces the risk because it enables detection of intruders. Encrypting password files, data files, and program code files further reduces the risks; it also makes authorized user access more complex and takes valuable CPU cycles.

The most common security in an application is to protect against unwanted data and program access. Data access can be limited to an entire physical file, logical records, or even individual data items. Possible functions against data are read only, read/write, or write only. Users and IS developers consider each function and the data being manipulated to define classes of users and their allowable actions. Allowable actions are to create, update, delete, and retrieve data. A hierarchy of access rights is built to identify, by data item, which actions are allowed by which class of users. A scheme for implementing the access restrictions is designed for the application.

Backup and recovery go hand-in-hand to provide correction of errors because of security inadequacies. A backup is an extra copy of some or all of the data and software, made specifically to provide recovery in the event of some disaster. Recovery is the process of restoring a previous version of data or application software to active use following some damage or loss of the previously active copy. 

Research by IBM and others has shown that companies go out of business within six months of a disaster when no backup copies of computer data and programs are kept. In providing for major disasters, such as tornadoes, off-site storage, the storing of backup copies at a distant site, is an integral part of guaranteeing recoverability. Off-site storage is usually 200+ miles away from the computer site, far enough to minimize the possibility of the off-site facility also being damaged. Old salt mines and other clean, underground, environmentally stable facilities are frequently used for off-site storage.

The disasters of concern in recovery design are user error, unauthorized change of data, software bugs, DBMS failure, hardware failure, or loss of facility. All these problems compromise the integrity of the data. The most difficult aspect of recovery from the first three errors is error detection. If a data change is wrong but contains legal characters, such as $10,000 instead of $1,000 as a deposit, the only detection will come from audit controls. If a data change is wrong because it contains illegal characters, the application must be programmed to detect the error and allow the user to fix it. Some types of errors, such as alteration of a deposit to a bank account or alteration of a payment to a customer, should also have some special printout or supervisory approval required as part of the application design to assist the user in detecting problems and in monitoring the correction process. DBMS software frequently allows transaction logging, logging of before and after images of database changes and assisted recovery from the logs for detected errors.

DBMS failure should be detected by the DBMS and the bad transaction should automatically be 'rolled-back' to the original state. If a DBMS does not have a 'commit/roll-back' capability, it should not be used for any critical applications or applications that provide legal, fiduciary, or financial processing compliance. Commit management software monitors the execution of all database actions relating to a user transaction. If the database actions are all successful, the transaction is 'committed' and considered complete. If the database actions are not all successful, the commit manager issues a rollback request which restores the database to its previous state before the transaction began, and the transaction is aborted. Without commit and roll-back the entire database or software library. An incremental backup is a copy of only changed portions of the database or library. A week's worth of backups are maintained and rotated into reuse after, for example, the fifth day. To minimize the time and money allocated to backup, incremental procedures are most common. A full backup is taken once each week with incremental backups taken daily. An active database would be completely backed-up daily with one copy on-site for immediate use in event of a problem. Regardless of backup strategy, an extra copy of the database is created at least once a week for off-site storage. The extensiveness of backup (and recoverability) is determined by assessing the risk of not having the data or software for different periods (see Table 10-4). The less the tolerance for loss of access, the more money and more elaborate the design of the backup procedures should be. The severity of lost access time varies, depending on the availability of human experts to do work manually and the criticality of the application. In general, the longer a work area has been automated, the less likely manual procedures can be used to replace an application, and the less time the application can be lost without TABLE 10-4 Backup Design Guidelines for Different Periods of Loss Length of Loss 1 Week or longer 1 Day 1 Hour Type of Backup Weekly Full with Off-site storage Above + Daily Incremental/Full Above + 1 or more types of DBMS Logging capabilities, partial transactions might compromise 15 Minutes or less Above + All DBMS Logging Capabilities: database integrity.

Other data and software backup procedures are either full or incremental. A full backup is a copy of the entire database or software library. An incremental backup is a copy of only changed portions of the database or library. A week's worth of backups are maintained and rotated into reuse after, for example, the fifth day. To minimize the time and money allocated to backup, incremental procedures are most common. A full backup is taken once each week with incremental backups taken daily. An active database would be completely backed-up daily with one copy on-site for immediate use in event of a problem. Regardless of backup strategy, an extra copy of the database is created at least once a week for off-site storage. The extensiveness of backup (and recoverability) is determined by assessing the risk of not having the data or software for different periods (see Table 10-4). The less the tolerance for loss of access, the more money and more elaborate the design of the backup procedures should be. The severity of lost access time varies, depending on the availability of human experts to do work manually and the criticality of the application. In general, the longer a work area has been automated, the less likely manual procedures can be used to replace an application, and the less time the application can be lost without severe consequences. The less important an application is to the continuance of an organization as an on-going business, the less critical the application is for recovery design. An application for ordering food for a cafeteria, for instance, is not critical if the company is an oil company but is critical if the company is a restaurant.

TABLE 10-4 Backup Design Guidelines for Different Periods of Loss Length of Loss 1 Week or longer 1 Day 1 Hour Type

Length of Loss	Type of Backup
1 Week or longer	Weekly Full with Off-site storage
1 Day	Above + Daily Incremental/Full
1 Hour	Above + 1 or more types of DBMS Logging
15 Minutes or less	Above + All DBMS Logging Capabilities: Transaction, Pre-Update and Post-Update Logs

To define backup requirements, then, you first define the criticality of the application to the organization, and the length of time before lost access becomes intolerable. Based on those estimates, a backup strategy is selected. If the delay until recovery can be a week or more, only weekly full backups with off-site storage are required. If the delay until recovery can be one day or less, then, in addition to weekly backups, daily backups should be done. If the recovery delay can be only an hour, the two previous methods should be supplemented with one or more types of DBMS logging scheme. Finally, if a I5-minute recovery delay is desired, all types of DBMS logging, plus daily and weekly backups should be done.

Last, we consider audit controls which provide a record of access and modification, and prove transaction processing for legal, fiduciary responsibility, or stakeholder responsibility reasons. Audit controls allow detection and correction of error conditions for data or processing. As new technologies, greater dependence on ITs, and interrelated systems that are vulnerable to telecommunications attacks all increase, business emphasis on controls also increases. In manual systems of work, control points are easily identified; procedures are observable, errors can be reconstructed, and controls applied by humans. In automated applications, the application is the solution, nothing is directly observable, and complexity of functions makes identification of control points increasingly complex.

A control point is a location (logical or physical) in a procedure (automated or manual) where the possibility of errors exists. Errors might be lack of proper authorization, misrecording of a transaction, illegal access to assets, or differences between actual and recorded data. Control points are identified during design because the entire application's requirements should be known in order to define the most appropriate control points. Controls are specified by designers in the form of requirements for program validation. For instance, controls for the validity of expense checks might be as follows: 

1. Only valid, preauthorized checks can be written. 

2. Check amounts may not exceed authorized dollar amounts. 

3. Checks may not exceed the expense report total amount.

Application audit controls address the completeness of data, accuracy of data, authorization of data, and adequacy of the audit trail. Detection of processing errors is either through edit and validation checks in programs, or through processing of redundant data. Examples of controlled redundancy of data include double entry bookkeeping, cross footing totals and numbers, dual departmental custody of replicated critical data, transaction numbering, and primary key verification. Edit and validation rules are designed to identify all logical inconsistencies as early in the process as possible, before they are entered into the database.

ABC Video Example Security, Backup/ Recovery, and Audit Plans 

To design ABC's security, we first review the physical plant and recommend changes to the planned computer site to provide security. The six threats are considered, but the byword from Vic in discussing the possibility of changes is "be reasonable." So, if there is a 'reasonable' chance that a problem will occur, we will recommend a reasonable, and low cost, solution to the problem.

Moving from most to least serious, we consider the six types of threats to application security: location failure, hardware failure, DBMS failure, software failure, hacker change, and user error. For each threat, we consider the potential of occurrence for ABC, then devise a plan to minimize the potential damage. All threats and responses are summarized in Figure 10-21.

FIGURE 10-20 ABC Current Physical Plant

First, we review the physical plant and relate it to location and hardware failures. ABC Video is located in suburban Atlanta, Georgia, 300 miles from the ocean and 25 miles from the nearest large lake. The company is located in a mall, the Dunwoody Village, a clustering of small shops and offices in open-square buildings containing a plaza in the middle of the square. The company occupies 3200 square feet of 80' x 40' space in the southeast corner of Building A. The adjoining spaces are occupied by Cheap's Drugs and Ra-Dan Hair Salon. A schematic of the space is shown in Figure 10-20.

The northeast corner of the area (abutting Ra-Dan's) contains a 12' x 16' office which contains two desks, one supply closet, and a bathroom. The office has no windows and can be locked, although it is frequently empty and unlocked. The supply closet has double doors which do not currently have a lock. 

The clerk's checkout counter is near the customer doors on the south side of the building in the western corner. The counter is an 'L' shape with the entry on the short side. A fire door, equipped with an alarm bar, is located in the northwest corner of the area and opens on a short alley behind the building.

Location failure usually results from violent weather, terrorist attacks, or government takeover. The chance of violent weather is the only potential major problem in the area. Tornadoes occur in the area regularly. The expectation is that there is a 20% chance of tornado damage some time in the next 10 years (see Figure 10-21). Tornadoes also imply strong thunderstorms which are common to the area. The chance of damage from a storm is about 30% within five years to the windows, and about 65% within two years for lightning to cause electrical spikes.

The response to location threats is to provide offsite backup of all information, with the site far enough away that it is unlikely to be affected by the same storm (see Figure 10-21). Vic should investigate the possibility of closing in the window wall in the southeast side of the building to minimize storm damage. He can also install lightning rods on the roof of the building to dissipate lightning when it hits. 

The next category of problems relate to the hardware selected for the rental/return application. Vendor-cited reliability is 99 years mean time between failure (MTBF) for individual components. When the components are considered as a whole, the probability of component failure is once in two years (see Figure 10-21). The current plan is to have an extra PC in the office that could be moved to the front desk if needed. A hardware service contract with a local company to provide response within 24 hours is recommended. 

The planned server location is near the bathroom in the northeast corner of the area. The toilet has a history of overflows during wet spring months. Because of the way the office was constructed, the water is confined to a small area but almost always runs into the supply closet and has been as high as one foot. The probability of component failure to file server and/or disks from water due to toilet overflow is 50% in two years. The answer to this problem is simple, but expensive: Build a new area, specifically for the computer, away from the toilet area to reduce this probability to near zero. Ideally, if the windows are closed in, the office could be moved to the front of the building and the old office removed. A new enclosure for the toilet facilities could be added or the toilet could also be rebuilt in the new location with whatever precautions are needed to preclude the spring overruns. 

There is another problem with the planned server location. The planned location-the supply closet has no ventilation. If the closet doors are open, ventilation for the office is sufficient for the planned equipment, but, ideally, the server closet doors should be locked. If the doors were locked, the probability of server failure due to lack of ventilation is 50% in two years. The solutions possible are to build a new area for the server equipment, or to add ventilation to the planned area to reduce this probability to near zero. Both solutions should be presented to Vic for his decision.

Less serious problems stem from the building location. Glass windows that run along 60' of the external front wall and the drop ceiling are accessible from neighboring companies. Theft and break-ins are somewhat common in the area, but the probability of a break-in is 50% in 10 years. Most burglars are looking for money, but some might maliciously tamper with the computer equipment. Therefore, the probability of computer damage during a break-in is 60% according to police estimates. 

The recommendations to minimize theft have to address the easy access to the company through windows and ceiling. If the office remains in its current location, a security system with movement sensors in the ceiling and glass-breakage sensors on all windows should be added (whether or not the computer is installed). Long-term, Vic should investigate the possibility of closing-in some or all windows to improve security of the company.

Next, because of the location of the checkout desk at the front of the building, the ability of clerks to monitor approaches to the office is low due to limited visibility. Further, theft of tapes is possible because clerks cannot see down all aisles without moving away from the desk area. For application security, we are concerned with office access; but, as professionals, we can make recommendations that will improve Vic's ability to reduce general theft as well. An easy, but somewhat expensive solution is to move the checkout desk to the center of the floor and assign surveillance duties to clerks. Even if the desk is not moved, mirrors installed in the corners of the room would allow clerks to monitor customers' actions. Both recommendations are made with the understanding that the mirrors should be installed whether or not the desk is moved.

Finding

Recommendation

Location failure-Probability of tornadoes 10% in 10 years. Probability of strong storms causing damage to windows is about 15% within two years. Probability of lightning causing electrical spikes is 15% within two years. Hardware failure-Vendor-cited reliability is 99 years MTBF for each component. The probability of component failure is once in two years for some network components. Hardware failure from external reasons-Planned server location is near bathroom with history of periodic overflows. Probability of component failure to file server and/or disk is 50% in two years. Hardware failure from external reasons-Planned server location is a closet in the office area without any ventilation. Probability of server failure is 50% in two years. Hardware failure from external reasons-Current location has glass windows along 60' of external front wall and a drop ceiling accessible from neighboring companies. Probability of break-in is 30% in 10 years; probability of computer damage during a break-in is 60%. Physical location vulnerabilities-Ability of clerks to monitor approaches to the office is low because of desk location and limited visibility. DBMS failure-Vendor-stated reliability is two years MTBF. This is one of the best on the market, but each new release is unstable for at least six months. DBMS failure-Other reasons (e.g., electrical spike). Probability is 100% that electrical surges will occur, since they are common in the summer months. Probability of brownouts with reduced power are 30% in two years. Software failure-Application failure due to software defects should be less than once in 15 years after the first three months. During the first three months of operation, the probability of application failure is about 75%; no more than one is expected. Hacker change-Outside user access to the system should be zero since no telecommunications capabilities are planned. However, the untended server and occasional lack of clerks at the desk area may provide a local hacker enough time to access and modify the system. User error-The use of computer novices as clerks guarantees user error. Probability is 100% within one week of system operation.

Select off-site storage facility no closer than 200 miles. Investigate closing in the front windows, at least the contiguous 40 feet of windows on the southeast corner. Install lightning rods on the roof. Move the extra PC in the office to the front desk if needed. A hardware service contract with a local company to provide response within 24 hours is recommended. Build a new area to reduce this probability to near zero.  Build a new area or add ventilation to the planned area to reduce this probability to near zero. If the office remains in its current location, add security system with movement sensors in the ceiling and glass-breakage sensors on all windows. Long-term, investigate the possibility of closing-in some or all windows, moving the office to the front of the building (away from plumbing). Move the clerks' desk to the center of the floor and assign surveillance duties to clerks. Install mirrors in corners of room to allow monitoring of customers' actions. Do not install latest releases until thoroughly tested using regression test package. Negotiate with vendor for data access software in event of DBMS failure. Include this software access in the vendor contract. Install a surge protector on the entire ABC electrical system to accommodate spikes (cost is about $100). Install surge protectors on each individual outlet used by computer equipment to further protect the equipment since whole system protectors do not guarantee integrated chip safety in any devices. Install a limited, inexpenSive, UPS to provide emergency power in event of electrical failure and for limited use during brownouts (cost about $1,000). The application is designed for 15-minute recovery of all data and programs. Loss of transactions in process will always occur with any failure; they will have to be reentered. Program problems will be fixed within one business day. Any lost transactions will be reentered free of charge by Software Engineers Unlimited. Install security precautions listed above: security mirrors, move desk, assign clerks monitoring responsibility. Always lock office door; always lock file server door. Restrict data and process access to those required to perform each job. Design application to withstand any casual error-hitting any key on keyboard, scanning any barcode type, etc. A report of such errors can be created and printed on demand by Vic to allow retraining (or other action) for repeated errors by one user. Application design also includes validation of all fields such that only valid data can be in the database. On-demand reports of new customer and video entries will allow Vic to monitor the typing skills of employees. New-hire orientation and new-hire mentors should be used to stress the importance of data accuracy.

FIGURE 10-21 Security Review Findings and Recommendations (Continued)

After physical issues are evaluated, we next look at software security and reliability. Vendor-stated reliability for the planned DBMS is two years MTBF. This SQL software is one of the best on the market, but each new release is unstable for at least six months, and those instability figures are not in the MTBF estimates. The company routinely disclaims any responsibility for new release errors and loss of data or processing to using companies. The DBMS does stabilize and is usually reliable after a six-month trial period for each new release. The simple solution to this problem is that unless a feature of a new release is needed, no change from the current stable version should be made. In addition, no software, whether vendor package or customer designed, should be allowed into production use until it is thoroughly tested using the application regression test package that will accompany the system.

A secondary problem with DBMS errors is that, if the DBMS fails, there is no other way to access the data. Part of the contract negotiation should include discussion of such software for the vendor to provide in event of DBMS failure. Other companies have successfully received such commitments from this vendor, although not voluntarily. Such data access software should be included in the vendor contract. 

Additional problems that might cause DBMS failure are electrical surges and brownouts due to uneven service in the area. Surges generally occur during the summer months when equipment comes on-line to service air-conditioning in the area. The probability of surges is 100% based on local electrical company history. The probability of brownouts with reduced power is 30% within two years, also using electrical history as the basis for the estimate. Problems from both causes can be minimized by a surge protector on the entire ABC electrical system which shuts down power if a particularly large surge is experienced. In addition, one surge protector for each outlet should be installed to further protect the equipment since whole system protectors do not guarantee integrated chip safety. Finally, a limited, inexpensive, uninterrupted power supply (UPS) should be installed to provide emergency power in the event of electrical failure and for limited use during brownouts to supplement reduced electricity from the local provider.

We consider application software failures next. Failure due to software defects should be less than once in 15 years after the first three months of operational use. During the first three months of operation, the probability of application failure is about 75%; no more than one is expected. The application is designed for IS-minute recovery of all data and programs. Loss of partial transactions will always occur with any failure; they will have to be reentered. Program problems will be fixed within one business day. Any lost transactions will be reentered free of charge by Software Engineers Unlimited (Mary's company). 

Outside user access to the system should be zero since no telecommunications capabilities are planned. However, the untended server and occasional lack of clerks at the desk area may provide a local hacker enough time to access and modify the system. If the physical security precautions recommended above are provided, such hacker break-ins would be nearly impossible. Therefore, at a minimum the precautions for security mirrors, assigning clerks monitoring responsibility, and locking the office and file server doors should be implemented (see Figure 10-21). 

Finally, the use of computer novices as clerks guarantees user errors. The probability of user errors is 100% within one week of system operation. To prevent any application or DBMS damage from user errors (inadvertent or otherwise), the first line of defense is to restrict what users may do and the data they may access as a way to prevent errors. Each job should be defined and a security access scheme developed to allow access to all processes and data required for the job, and nothing more.

Second, the application should withstand any casual error-hitting of any key on the keyboard, scanning any barcode type, and so on. If required, a report of such errors can be created and printed on demand by Vic to allow retraining (or other action) for repeated errors by one user. Application design also includes validation of all fields such that only valid data can be in the database. Such checks are not possible for alphanumeric data, however, so on-demand reports of new customers and video entries will allow Vic to monitor the typing skills of employees. 

Application training will use computer-based training (CBT) in entering application data. The CBT will use simulated transactions and should minimize the user errors if taken seriously by clerks. \ New-hire orientation should include discussion of the importance of accuracy of work, especially with the computer. Further, new hires should be assigned a more senior 'mentor' for learning the application after training.

After disaster recovery is planned, application security must be developed. From the recovery plan, we know that each job should be evaluated to determine the data and processing requirements of the position. ABC jobs evaluated include clerks, owner, and accountant. The owner should be allowed to do any functions on the application and system that he desires. However, many owners do not want to become the chief user of the computer. When asked, Vic's reaction is, "Does this mean I can never take a vacation? Do I have to be here in the morning and at night? If so, define a new position that can do most of my functions, just not delete data!" So the position of chief clerk is also considered.

FIGURE 10-22 ABC Data Security Hierarchy of Access Rights

The owner should be the lead person and still be allowed to perform all functions, access all data, and provide security password changes, and so on (see Figure 10-22). The chief clerk, according to Vic's wishes, has all of those functions except deleting information (see Table 10-5). If there were sensitive data in the system, more discussion of the chief clerk's duties and access rights might take place. The clerks have access rights to rent and return videos, and to create and update customers and videos. Finally, the accountant has limited read-only access to several files.

Backup and recovery are considered next. First we decide the maximum tolerable time loss for a computer outage, then select the backup scheme that best fits the time loss maximum. The rental/return application is critical to ABC's ability to conduct business. Vic knows that when he moves all production work to the computer that the clerks will quickly forget the manual way of conducting business. Also, we know that if the databases are not kept up to date, the system is next to useless because the clerks won't know whether to look at manual or automated files for returns, fees, and so on. Therefore, the maximum outage should be less than 15 minutes with recovery of all fully complete transactions. Even at 15 minutes, if an outage were to occur during a peak time, as many as four transactions could need to be reentered and as many as 15-20 transactions would be queued for entry upon system return to production. Ideally, the system should be functional during all business hours. 

The recovery requirements imply the most backup protection possible. From Table 10-4, a 15-minute recovery requirement means the use of weekly full backups with off-site storage, daily backups, and logging for transactions, preupdate data items and postupdate data items. Therefore, these are the backup and recovery requirements.

Requirements: Application and system availability during all store open hours, with no more  than 15 minutes of down-time from failures of any type.

Backups: Transaction, preupdate, and postupdate logs

Transaction logs maintained one week until weekly backups are verified. Pre- and post-update logs maintained for 72 hours.

Daily complete database backups with onsite copy plus off-site storage at owner's

home. 

Paper copy of transactions maintained for one calendar year in accountant's office.

Weekly complete disk backups with on-site copy plus off-site storage at owner's home and a

third copy at

TABLE 9-5 ABC User Classes and Access Rights

FilelFunction	Owner	Chief Clerk	Clerk	Accountant
Customer Create Retrieve Update Delete	X X X X	X X X	X X X	X
Video  Create  Retrieve  Update Delete	X X X X	X X X	X X X	X
Open Rentals Create Retrieve Update Delete	X X X X	X X X	X X X	X
Video History Create  Retrieve  Update	X X	X	X	X
Customer History Create  Retrieve  Update	X X	X	X	X
Startup	X	X
Shutdown	X	X
End Of Day Create Retrieve Delete	X X X	X X X		X
Initiate End of Month Process	X	X

If ABC's application processed millions of transactions each day, we would do further analysis of the cost of backup and recovery, but here that is not necessary. 

Finally, we need to decide about audit controls as summarized here: 

Data accuracy and completeness – All edit checks possible will be used as data are entered to prevent errors from entering the system. Sight verification by clerks and customers will be used to verify alphanumeric information.

Rental transaction accuracy can be verified by customers' signing for all monetary transactions. In case of discrepancy, transaction logs and historical paper copies of transactions can be consulted.

Data authorization-Security controls will provide sufficient authorization for data processing. Only the owner is authorized to perform any delete functions on customer, video, and open rental data. No delete functions for history records are provided. 

User ID, date, and time of user to last change data will be maintained in Customer, Video, and Open Rental databases.

Audit trail – A paper trail of receipts should be maintained by the accountant for each calendar year. This is a sufficient trail since ABC is a cash business without any accruals. Nonmonetary transactions (e.g., return of on-time tapes), have no paper audit trail. If a question about a tape return arises, the database can be checked to verify the information.

All edit checks possible should be used as data are entered to prevent errors from entering the system. To ensure complete editing, we review the data dictionary to check that all non-alphanumeric fields have edit and validation criteria. 

On names, addresses, and other alphanumeric fields, little verification can be performed automatically. What cannot be done automatically should be done manually. Procedures for operators should be developed to document clerical 'sight verification' and customer verification standards. An example of such a procedure that would be part of the user manual is shown as Figure 10-23. Sight verification means that the person entering information into the computer reads the monitor to verify the accuracy of the information he or she entered. The user, then, is responsible for data integrity of items that cannot be computer verified.

These paragraphs would be part of the user procedures:
Customer Maintenance
...
When customers are being added to the system, the clerk should read back all information as shown on the screen to verify its accuracy, as the computer cannot verify mixed alphabetic and numeric information.
...
Video Maintenance
...
When videos are being added to the system, the clerk should compare all information shown on the screen with the original printed information to verify its accuracy, as the computer cannot verify mixed alphabetic and numeric information.
...
Rent/Return Processing
...
Users should be encouraged to check the information on the printed rental before they sign it to verify that it is correct.
...

FIGURE 10-23 User Sight Verification Procedure

Rental transaction accuracy will be verified by customers' signing for all monetary transactions. In case of discrepancy, transaction logs and historical paper copies of transactions can be consulted. If many discrepancies persist (more than one per week), a special history file of transactions can be added to the application to speed the transaction look-up process. 

Security controls can be designed to provide sufficient authorization for data processing. The security scheme should be developed to serve two goals: to provide data access and to provide function access to those who need it. To require several layers of security checking for a simple application does not make sense and wastes clerical time. So, once again the KISS (Keep It Simple, Stupid) method of one security access scheme is best. User ID, date, and time of user to last change data will be maintained in Customer, Video, and Open Rental databases. These attributes are added to affected database relations.

To minimize the extent to which damage can be done to data, only ABC's owner should be authorized to perform any delete functions on customer, video, and open rental data. No automated delete functions for history records are provided without circumventing the application completely. Changes to files will always be somewhat traceable because the historical record will reflect activity. If unauthorized file changes are thought to be a problem, Vic can always request a browsing capability for any of the transaction logs to check on problems. 

A manual audit trail should be used for ABC to conserve computer resources. All monetary transactions can be reconstructed through a paper trail of receipts maintained by the accountant. The receipt form is a two-ply preprinted form on which all monetary transactions are printed. For rentals, customers sign the form as proof of rental responsibility. Paper records should be maintained for one calendar year in the accountant's office; this is sufficient since ABC is a cash business without any accruals. If a tape audit trail were to be necessary at some time in the future, it can be added to the system easily.

Nonmonetary transactions (e.g., return of on-time tapes), have no paper audit trail. If a question about a tape return arises, the user ID, date, and time of the return will be on the database and can be checked to verify the information.