IT Controls Part II,Security and Access:Controlling Database Management Systems

Controlling Database Management Systems

Controls over database management fall into two general categories: access controls and backup controls. Access controls are designed to prevent unauthorized individuals from viewing, retrieving, corrupting, or destroying the entity’s data. Backup controls ensure that in the event of data loss due to unauthorized access, equipment failure, or physical disaster, the organization can recover its files and databases.

ACCESS CONTROLS

Risks to corporate databases include corruption, theft, misuse, and destruction of data. These threats originate from both unauthorized intruders and authorized users who exceed their access privileges. Several database control features that reduce these risks are reviewed in the following sections.

User Views

The user view or subschema is a subset of the total database that defines the user’s data domain and restricts his or her access to the database accordingly. Figure 16-1 illustrates the role of the user view. The database administrator typically is responsible for defining user views. The auditor is concerned that such access privileges are commensurate with the users’ legitimate needs.

Although user views can restrict user access to a limited set of data, they do not define task privileges such as read, delete, or write. Often, several users may share a single user view but have different author- ity levels. For example, users Smith, Jones, and Adams in Figure 16-1 all may have access to the same set of data: account number, customer name, account balance, and credit limit. Let’s assume that all have read authority, but only Jones has authority to modify and delete the data. To achieve this level of restriction requires additional security measures, discussed next.

Database Authorization Table

The database authorization table contains rules that limit the actions a user can take. Each user is granted certain privileges that are coded in the authority table, which is used to verify the user’s action requests. For example, the authorization table in Figure 16-2 shows that of the three users, only Jones has the authority to modify and delete the data.

User-Defined Procedures

A user-defined procedure allows the user to create a personal security program or routine to provide more positive user identification than a password can. For example, in addition to a password, the security procedure asks a series of personal questions (such as the user’s mother’s maiden name), which only the legitimate user is likely to know.

Data Encryption

Many database systems use encryption procedures to protect highly sensitive data, such as product formulas, personnel pay rates, password files, and certain financial data. Data encryption uses an algorithm to scramble selected data, thus making it unreadable to an intruder browsing the database. In addition to protecting stored data, encryption is used for protecting data that are transmitted across networks. We discuss various encryption techniques later in this chapter.

Biometric Devices

The ultimate in user authentication procedures is the use of biometric devices, which measure various personal characteristics such as fingerprints, voiceprints, retina prints, or signature characteristics. These user characteristics are digitized and stored permanently in a database security file or on an identification card that the user carries. When an individual attempts to access the database, a special scanning device captures his or her biometric characteristics, which it compares with the profile data stored internally or on the ID card. If the data do not match, access is denied.

Audit Objectives Relating to Database Access

The auditor’s objectives are (1) to verify that individuals who are authorized to use the database are limited to accessing only the data needed to perform their duties, and (2) that unauthorized individuals are denied access to the database.

Audit Procedures for Testing Access Controls

RESPONSIBILITY FOR AUTHORITY TABLES AND SUBSCHEMAS. The auditor should verify that database administration personnel retain sole responsibility for creating authority tables and designing user views. Evidence of compliance can come from three sources: (1) by reviewing company policy and job descriptions, which specify these technical responsibilities; (2) by examining programmer authority tables for access privileges to data definition language (DDL) commands; and (3) through personal interviews with programmers and database administration personnel.

APPROPRIATE ACCESS AUTHORITY. The auditor can select a sample of users and verify that their access privileges stored in the authority table are consistent with their organizational functions.

BIOMETRIC CONTROLS. The auditor should evaluate the costs and benefits of biometric controls. Generally, these would be most appropriate when a very limited number of users may access highly sensitive data.

ENCRYPTION CONTROLS. The auditor should verify that sensitive data, such as passwords, are properly encrypted. This can be done by printing the file contents to hard copy.

BACKUP CONTROLS

Malicious acts from external hackers, disgruntled employees, disk failure, program errors, fires, floods, and earthquakes can corrupt and destroy data. To recover from such disasters, the organization needs to reconstruct the database to prefailure status. This can be done only if the database was properly backed up in the first place. Organizations must, therefore, implement policies, procedures, and techniques that systematically and routinely provide backup copies of critical data. This section examines backup controls used in the database environment. Legacy systems that use a flat-file structure present a different set of issues that are discussed in Section B of the appendix to this chapter.

Large-scale database management systems employ a backup and recovery procedure similar to that illustrated in Figure 16-3. This system provides four backup and recovery features: database backup, a transaction log, checkpoints, and a recovery module. Each of these is described in the following section.

DATABASE BACKUP. The backup feature makes a periodic backup of the entire database. This is an automatic procedure that should be performed at least once a day. The backup copy should then be stored in a secure remote area.

TRANSACTION LOG (JOURNAL). The transaction log feature provides an audit trail of all processed transactions. It lists transactions in a transaction log file and records the resulting changes to the database in a separate database change log.

CHECKPOINT FEATURE. The checkpoint feature suspends all data processing while the system reconciles the transaction log and the database change log against the database. At this point, the system is in a quiet state. Checkpoints occur automatically several times an hour. If a failure occurs, it is usually possible to restart the processing from the last checkpoint. Thus, only a few minutes of transaction processing must be repeated.

RECOVERY MODULE. The recovery module uses the logs and backup files to restart the system after a failure.

Audit Objectives Relating to Database Backup

The auditor’s objective is to verify that database backup controls are adequate to facilitate the recovery of lost, destroyed, or corrupted data.

Audit Procedures for Testing Backup Controls

Database backup should be a routine activity.

• The auditor should verify from system documentation that production databases are copied at regular intervals (perhaps several times an hour).

• The auditor should verify through documentation and observation that backup copies of the database are stored off-site to support disaster recovery procedures.