IT AUDIT - Computer Operations

Chapter 2: Computer Operations

2IT Auditing & Assurance, 2e, Hall & Singleton

STRUCTURING THE IT FUNCTION

Centralized data processing [see Figure 2-1]

Organizational chart [see Figure 2-2]

Database administrator Data processing manager/dept.

Data control Data preparation/conversion Computer operations Data library


Segregation of incompatible IT functions Systems development & maintenance

Participants End users IS professionals Auditors Other stakeholders



Segregation of incompatible IT functions Objectives:

Segregate transaction authorization from transaction processing

Segregate record keeping from asset custody Divide transaction processing steps among

individuals to force collusion to perpetrate fraud



Segregation of incompatible IT functions

Separating systems development from computer operations [see Figure 2-2]



Segregation of incompatible IT functions Separating DBA from other functions

DBA is responsible for several critical tasks: Database security Creating database schema and

user views Assigning database access authority to users Monitoring database usage Planning for future changes




Segregation of incompatible IT functions Alternative 1: segregate systems analysis

from programming [see Figure 2-3] Two types of control problems from this approach:

Inadequate documentation Is a chronic problem. Why? Not interesting Lack of documentation provides job security Assistance: Use of CASE tools

Potential for fraud Example: Salami slicing, trap doors


Segregation of incompatible IT functions Alternative 2: segregate systems

development from maintenance [see Figure 2-2] Two types of improvements from this

approach:1. Better documentation standards

Necessary for transfer of responsibility2. Deters fraud

Possibility of being discovered



Segregation of incompatible IT functions Segregate data library from operations

Physical security of off-line data files Implications of modern systems on use of data

library: Real-time/online vs. batch processing Volume of tape files is insufficient to justify full-time

librarian Alternative: rotate on ad hoc basis

Custody of on site data backups Custody of original commercial software and licenses



Segregation of incompatible IT functions Audit objectives

Risk assessment Verify incompatible areas are properly

segregated How would an auditor accomplish this objective?

Verify incompatible areas are properly segregated

Verify formal vs. informal relationships exist between incompatible tasks Why does it matter?



Segregation of incompatible IT functions Audit procedures: Obtain and review security policy Verify policy is communicated Review relevant documentation (org. chart, mission

statement, key job descriptions) Review systems documentation and maintenance

records (using a sample) Verify whether maintenance programmers are also

original design programmers Observe segregation policies in practice Review operations room access log Review user rights and privileges



The distributed model Distributed Data Processing (DDP)

Definition [see figure 2-4] Alternative A: centralized Alternative B: decentralized / network



The distributed model Risks associated with DDP

Inefficient use of resources Mismanagement of resources by end users Hardware and software incompatibility Redundant tasks

Destruction of audit trails Inadequate segregation of duties Hiring qualified professionals

Increased potential for errors Programming errors and system failures

Lack of standards



The distributed model Advantages of DDP

Cost reduction End user data entry vs. data control group Application complexity reduced Development and maintenance costs reduced

Improved cost control responsibility IT critical to success then managers must

control the technologies Improved user satisfaction

Increased morale and productivity Backup flexibility

Excess capacity for DRP



Controlling the DDP environment Need for careful analysis Implement a corporate IT function

Central systems development Acquisition, testing, and implementation of

commercial software and hardware User services

Help desk: technical support, FAQs, chat room, etc.

Standard-setting body Personnel review

IT staff



Controlling the DDP environment Audit objectives:

Conduct a risk assessment Verify the distributed IT units employ entity-

wide standards of performance that promotes compatibility among hardware, operating software, applications, and data



Controlling the DDP environment Audit procedures:

Verify corporate policies and standards are communicated

Review current organization chart, mission statement, key job descriptions to determine if any incompatible duties exist

Verify compensating controls are in place where incompatible duties do exist

Review systems documentation Verify access controls are properly

established



Computer center controls Physical location

Avoid human-made and natural hazards Example: Chicago Board of Trade

Construction Ideally: single-story, underground utilities,

windowless, use of filters If multi-storied building, use top floor (away from

traffic flows, and potential flooding in a basement) Access

Physical: Locked doors, cameras Manual: Access log of visitors

THE COMPUTER CENTER


Computer center controls

THE COMPUTER CENTER

Air conditioning Especially mainframes Amount of heat even from a group of PCs

Fire suppression Automatic: usually sprinklers

Gas, such as halon, that will smother fire by removing oxygen can also kill anybody trapped there

Sprinklers and certain chemicals can destroy the computers and equipment

Manual methods Power supply

Need for clean power, at a acceptable level Uninterrupted power supply


Computer center controls Audit objectives Verify physical security controls are reasonable Verify insurance coverage is adequate Verify operator documentation is adequate in

case of failure Audit procedures Tests of physical construction Tests of fire detection Tests of access control Tests of backup power supply Tests for insurance coverage Tests of operator documentation controls

THE COMPUTER CENTER


PC operating systems PC systems risks & controls

In general: Relatively simple to operate and program Controlled and operated by end users Interactive data processing vs. batch Commercial applications vs. custom Often used to access data on mainframe or

network Allows users to develop their own applications

Operating Systems: Are located on the PC (decentralized) O/S family dictates applications (e.g., Windows)

PERSONAL COMPUTER SYSTEMS


Control environment for PCs Controls

Risk assessment Inherent weaknesses Weak access control Inadequate segregation of duties Multilevel password control – multifaceted access control

Risk of physical loss Laptops, etc. can “walk off”

Risk of data loss Easy for multiple users to access data End user can steal, destroy, manipulate Inadequate backup procedures

Local backups on appropriate medium Dual hard drives on PC External/removable hard drive on PC



Control environment for PCs

Risk associated with virus infection Policy of obtaining software Policy for use of anti-virus software Verify no unauthorized software on PCs

Risk of improper SDLC procedures Use of commercial software Formal software selection procedures



PC systems audit Audit objectives

Verify controls are in place to protect data, programs, and computers from unauthorized access, manipulation, destruction, and theft

Verify that adequate supervision and operating procedures exist to compensate for lack of segregation between the duties of users, programmers, and operators

Verify that backup procedures are in place to prevent data and program loss due to system failures, errors

Verify that systems selection and acquisition procedures produce applications that are high quality, and protected from unauthorized changes

Verify the system is free from viruses and adequately protected to minimize the risk of becoming infected with a virus or similar object



PC systems audit Audit procedures

Verify that microcomputers and their files are physically controlled Verify from organizational charts, job descriptions, and

observation that the programmers of applications performing financially significant functions do not also operate those systems.

Confirm that reports of processed transactions, listings of updated accounts, and control totals are prepared, distributed, and reconciled by appropriate management at regular and timely intervals.

Determine that multilevel password control or multifaceted access control is used to limit access to data and applications, where applicable.

Verify that the drives are removed and stored in a secure location when not in use, where applicable.

Verify that backup procedures are being followed. Verify that application source code is physically secured (such as

in a locked safe) and that only the compiled version is stored on the micro computer.

Review systems selection and acquisition controls Review virus control techniques.



Operating system security Definition

Translates high-level languages Compilers and interpreters

Allocates IS/IT resources to users, groups, applications

Manages the tasks of job scheduling and multiprogramming

Five imperative control objectives Protect itself from users Protect users from each other Protect users from themselves Be protected from itself Protected from its environment

OPERATING SYSTEM


Operating system security Logon procedure Access token [who] Access control list [what, when, where] Discretionary access control [delegated

authority]

Threats to operating system integrity

OPERATING SYSTEM


Controlling access privileges

Audit objectives

Audit procedures

SYSTEM-WIDE CONTROLS


Password control Definition Common forms of contra-security

behavior Reusable passwords One-time passwords Password policy Audit objectives Audit procedures



FIGURE 2.8 – Password Policy

Proper Dissemination – Promote it, use it during employee training or orientation, and find ways to continue to raise awareness within the organization.

Proper Length: Use at least 8 characters. The more characters, the more difficult to guess or crack. Eight characters is an effective length to prevent guessing, if combined with below.

Proper Strength: Use alphabet (letters), numbers (at least 1), and special characters (at least 1). The more non-alpha, the harder to guess or crack. Make them case sensitive and mix upper and lower case. A “Strong” password for any critical access or key user. Password CANNOT contain a real word in the content.

Proper Access Levels or Complexity: Use multiple levels of access requiring multiple passwords. Use a password matrix of data to grant read-only, read/write, or no access per data field per user. Use biometrics {such as fingerprints, voice prints}. Use supplemental access devices, such as smart cards, or beeper passwords in conjunction with remote logins. Use user-defined procedures.

Proper Timely Changes: At regular intervals, make employees change their passwords.

Proper Protection: Prohibit the sharing of passwords or “post-its” with passwords located near one’s computer.

Proper Deletion: Require the immediate deletion of accounts for terminated employees, to prevent an employee from being able to perpetrate adverse activities.


E-mail risks Spoofing Spamming Chain letters Urban legends Hoax virus warnings Flaming Malicious attachments (e.g., viruses)



Malicious objects risk Virus Worm Logic bomb Back door / trap door Trojan horse Potential control procedures Audit objective Audit procedures



Controlling electronic audit trails Keystroke monitoring (keystroke log) Event monitoring (key events log) Audit trail objectives

Detecting unauthorized access Reconstructing events Personal accountability

Implementing an audit trail



Controlling electronic audit trails Audit objective

Verify adequate audit trails and logs

Audit procedures O/S audit log viewer ACL extraction of log data (see list) Sample organizational security group’s

records



Disaster recovery planning

Types of disaster




Definition




Critical applications identified and ranked

Create a disaster recovery team with responsibilities



Disaster recovery planning Site backup

“Hot site” – Recovery Operations Center

“Cold site” – empty shell Mutual aid pact Internally provided backup Other options



Disaster recovery planning Hardware backup

(if NOT a hot site) Software backup: operating system

(if NOT a hot site) Software backup: application

software(based on critical application step)



Disaster recovery planning Data backup Supplies (on site) Documentation (on site)

User manuals System and software technical

manuals

Test!



Disaster Recovery Plan

1. Critical Applications – Rank critical applications so an orderly and effective restoration of computer systems is possible.

2. Create Disaster Recovery Team – Select team members, write job descriptions, describe recovery process in terms of who does what.

3. Site Backup – a backup site facility including appropriate furniture, housing, computers, and telecommunications. Another valid option is a mutual aid pact where a similar business or branch of same company swap availability when needed.

4. Hardware Backup – Some vendors provide computers with their site – known as a hot site or Recovery Operations Center. Some do not provide hardware – known as a cold site. When not available, make sure plan accommodates compatible hardware (e.g., ability to lease computers).

5. System Software Backup – Some hot sites provide the operating system. If not included in the site plan, make sure copies are available at the backup site.

6. Application Software Backup – Make sure copies of critical applications are available at the backup site

7. Data Backup – One key strategy in backups is to store copies of data backups away from the business campus, preferably several miles away or at the backup site. Another key is to test the restore function of data backups before a crisis.

8. Supplies – A modicum inventory of supplies should be at the backup site or be able to be delivered quickly.

9. Documentation – An adequate set of copies of user and system documentation.

10. TEST! – The most important element of an effective Disaster Recovery Plan is to test it before a crisis occurs, and to test it periodically (e.g., once a year).


Disaster recovery planning Audit objectives

Verify management’s DRP is adequate Audit procedures

Verify a second-site backup is adequate Review the critical application list for completeness Verify backups of application software are stored off-

site Verify that critical data files are backed up and

readily accessible to DRP team Verify resources of supplies, documents, and

documentation are backed up and stored off-site Verify that members listed on the team roster are

current employees and that they are aware of their responsibilities



Fault tolerance Definition 44% of time IS unavailable is due to system failures! Controls

Redundant systems or parts RAID

UPS Multiprocessors

Audit objective To ensure the organization is employing an appropriate

level of fault tolerance Audit procedures

Verify proper level of RAID devices Review procedures for recovery from system failure Verify boot disks are secured


Chapter 2: Computer Operations

IT AUDIT - Computer Operations

Documents

Transcript of IT AUDIT - Computer Operations