Unit 4

Auditing IT General Controls (ITGC)

Introduction Unit Learning Outcome

This chapter looks at IT general controls from an IT By the end of this unit you should be
auditor’s perspective. ITGCs cover broad areas of the able to:
overall IT environment, such as computer operations,
access to programs and data, program development ✓ Prepare the basic IT General
and program changes, network controls, and many Controls audit working papers.
others. In order for specific application controls to be
effective, there must also be strong overriding effective
IT general controls in place.
Ready? Let’s get learning!

Timing

This unit is good for 2 weeks. You can devote three hours per day on the subject. Don’t worry, the
content is abridged, which means it only includes the most salient points you need to know.
For easier monitoring of your progress, you can view the TO DO LISTS in CANVAS. Be sure to make
use of CANVAS to have a more organized and orderly studying. Plus, the CANVAS LMS is a
PROCRASTINATION-beater!

Getting Started!

IT General Controls Overview

Enterprise Information Technology (IT) processes and systems cover many areas, ranging
from an IT application to control an enterprise’s accounting general ledger, file server devices to
manage enterprise data, and connections to the all-pervasive Internet.

An IT auditor should have a strong understanding of IT internal control techniques

covering many of these technologies and processes.

Although the lines of separation are sometimes difficult, we generally think of IT controls on
two broad levels: application controls that cover a specific process, such as an accounts payable
system to pay invoices from purchases, and what are called IT general controls. IT general controls
cover all aspects of IT operations and are necessary in order for specific application controls to be
effective.

IT general controls review attempts to gain an overall impression of the controls that are
present in the environment surrounding the information systems. These include the organizational
and administrative structure of the Information System (IS) function, the existence of policies and
procedures for the day-to-day operations, availability of staff and their skills and the overall control
environment.

In addition, ITGC would also include the infrastructure and environmental controls. A review
of the data center or information processing facility should cover the adequacy of air conditioning
(temperature, humidity), power supply (uninterruptible power supplies, generators) and smoke
detectors/fire suppression systems, a conducive clean and dust free environment, protection from
floods and water seepage as well as neat and identifiable electrical and network cabling.
1
Why do you think we care about ITGCs?
• They support IT dependent controls and processes
• The provide controls around financial data

Why are they important in a financial audit?

• Provide an efficient means of relying on IT dependent controls and processes
• Provide assurance that the integrity of financial data remains intact throughout the audit
period

What could go wrong if ITGCs are not functioning properly?

• Financial audit team can’t rely on IT dependent controls
• Financial data may not be complete and accurate

Why are they important?

• ITGCs are the foundation upon which an accounting system operates
• ITGCs help ensure the integrity, accuracy, and completeness of financial data in the systems
• Without strong ITGCs, reliance upon IT-dependent controls and processes within a business
process would be difficult
• ITGCs are pervasive across all business processes using IT systems

Figure 4.1 IT General and Application Controls Hierarchy

As another and perhaps more appropriate way of looking at IT general and application
controls, Figure 4.1 describes an IT controls hierarchy. At the top of this triangle configuration are IT
policies defining the overall enterprise IT organization. Moving down the hierarchy are general
controls for IT standards, organization of the IT function, and physical and environmental controls.

2
 The next level down in the hierarchy brings two categories of technical-level general controls:
systems software and systems development general controls, followed by application-based controls
at the base of the controls hierarchy.

Scoping Information Technology General Controls

The auditor’s understanding of the information system includes the IT environment relevant
to the flows of transactions and processing of information in the entity’s information system
because the entity’s use of IT applications or other aspects in the IT environment may give rise to
risks arising from the use of IT.

So we need to obtain certain information to allow us to do this and to develop our

understanding of how transactions are processed, including:

✓ Which application systems the client has

✓ What operating systems the applications use
✓ How systems are networked
✓ How security is managed
✓ Whether there is reliance on reports and/or spreadsheets
✓ Indicators of issues in the systems, e.g. known problems

How do I audit the IT Environment?

This is where IT general controls (ITGC) come in. They can be defined as:

“auditable policies and procedures put in place by a business to help ensure the
confidentiality, integrity and availability of its IT systems and data”.

Figure 4.2 ITGC Domains (PricewaterhouseCoopers LLP)

3
 I. System/Program Development
To ensure that systems are developed, configured, and implemented to achieve management's
application control objectives.

Which means: Systems that are developed actually work as required.

II. Program Change

To ensure that changes to programs and related infrastructure components are requested,
authorized, performed, tested, and implemented to achieve management's application control
objectives.

Which means: Changes to systems and data do not adversely affect their integrity, availability
or confidentiality.

III. Computer Operations

To ensure that production systems are processed completely and accurately in accordance
with management's control objectives, and that processing problems are identified and
resolved completely and accurately to maintain the integrity of financial data.

Which means: Systems process data as intended, and where they don’t, this is identified and
corrected.

IV. Access to Programs and Data

To ensure that only authorized access is granted to programs and data upon authentication of
a user's identity”.

Which means: Systems and data are protected from unauthorized access and invalid changes.

ITGC 4.1 Audit of System/Program Development

It is often much more efficient for an IT auditor to review an IT application for its internal
controls while it is being developed and implemented rather than after it has been placed into
production. The role of the IT auditor here is similar to that of a building inspector reviewing a new
construction project:

4
 It is difficult to make constructive recommendations regarding the completed building. Even
if some problems were found, the inspector would be under considerable pressure not to identify
ones that would require significant portions of the building to be torn down and rebuilt. Rather, the
building inspector identifies problems during construction and suggests how they can be corrected
before completion.

Similarly, the effective IT auditor should suggest corrective actions to improve system controls
along the way. It is easier to implement changes during an application implementation process
than after it has been completed and the system has been placed into production.

To continue with the analogy, an IT auditor must be careful not to take responsibility for
designing the new application’s controls. The building inspector points out problems but certainly
does not take responsibility for fixing them.

The discussion in Chapters 1 & 2 emphasizes that it is the IT auditor’s task to review and
recommend but not to design or build the controls in any area reviewed. When reviewing new
applications under development, an IT auditor should point out internal control weaknesses to the
application developers but only recommend that they implement those recommendations.

The scope of a systems development audit can include an evaluation of the software
development life cycle or an evaluation of the quality of the deliverables from each system
development and implementation phase (e.g., an evaluation of the controls design and audit trails, systems
test plan and results, user training, and systems and program documentation).

Activity Audit Considerations

Project • Project initiation is the process by which systems proposals are
Initiation assessed for consistency with the strategic systems plan and evaluated
in terms of their feasibility and cost-benefit characteristics.

• The systems project proposal provides management with a basis for

deciding whether to proceed with the project. The formal proposal
serves two purposes.

a) First, it summarizes the findings of the study conducted to this

point into a general recommendation for a new or modified
system. This enables management to evaluate the perceived
problem along with the proposed system as a feasible solution.

b) Second, the proposal outlines the linkage between the objectives

of the proposed system and the business objectives of the firm. It
shows that the proposed new system complements the strategic
direction of the firm.

• For the system implementation project in question, inspect evidence of

project proposals/plans, feasibility analyses, and budgets prepared
at the onset of the project and maintained throughout.

Analysis & a) Analysis - In this phase, the users and systems analysts define the
Design system requirements in terms that can be measured.

Possible contents of System Requirements

• Processes
• Data elements and Structure
• Inputs and Outputs
• Controls
• Documentation

5
 Auditor Interests in the System Requirements
• You should obtain a list of detailed requirements. The accuracy of
the requirements can be verified by a combination of desktop
review of documentation and interviews with appropriate
personnel.

• Program flowchart diagrams should be reviewed to ensure that

they address the needs of the user.

• The auditor should observe that the primary responsibility is not

to develop a product but to satisfy the user. Often, the user does
not understand what is truly needed. Only by understanding the
user’s business, its problems, goals, constraints, weaknesses, and
strengths can the project team deliver the product the user needs.

• Auditors can participate by reviewing requirements, and

verifying user understanding and sign-off.

b) Design - In this phase, the systems analyst defines all system interfaces,
reporting, and screen layouts, and specific program logic. At this time,
controls should also be defined for input points and processing.

Screen layouts, controls, and reports should be reviewed and approved

by the user before moving on to the next phase. Programmers will use
the detailed specifications from the design phase for the construction
phase.

Auditor Interests in the System Design

• The auditor may review the design work to make sure that the
user’s requirements are met. The system’s design may also be
reviewed for any possible exposures or forgotten controls and for
adherence to company standards.

• If an exposure is found, the auditor should recommend the

appropriate controls or procedures. A technique that brings users
and project team members together for an intensive workshop in
which they create a system proposal into a detail design is called
Joint Application Design (JAD).

• The result of the JAD session is a user view of the system for
further development. This is an excellent setting for the
discussion of the advantages and cost effectiveness of controls.

Construction • The main goal of the construct phase is to design and build working
software that is ready to be tested and delivered to its user
community. This phase involves modeling the system, programming the
applications, and application testing.

• Prototyping is a technique for providing users a preliminary working

version of the system. The prototype is built quickly and
inexpensively with the intention that it will be modified.

• The objective of this technique is for the prototype to represent ‘‘a clear-
cut functional specification, serve as a vehicle for organizing and
learning, and evolve ultimately into a fully implemented’’ system.

6
 • The auditor may review the new system’s programs to verify compliance
with programming standards.

These standards help ensure that all the code has a similar structure,
tracking dependencies and making maintenance easier.

• The auditor may review a sample of programs to verify that the

standards are being followed and that the programs conform to
systems design.

• In addition, programs may be checked for possible control exposures and

for the placement of proper controls per design.

Testing • During the testing phase, the system is tested to verify that it works as
intended and meets design specifications.

• An overall testing strategy should be developed to define the individual

test events, roles and responsibilities, test environment, problem
reporting and tracking, and test deliverables.

Types of Testing

a) Unit Testing - verifies that stand-alone programs match

specifications. Test cases should exercise every line of code.

b) Integration testing - verifies that all software and hardware

components work together. Data is passed from one program to the
next. All programs and subroutines should be tested during this
phase. Test cases should cover all components (e.g., hardware and
software).

c) Functional/Validation testing - verifies that the application meets

user requirements. Test cases should cover screens, navigation,
function keys, online help, processing, and output (reports, files, and
screens).

d) Technical testing Technical testing verifies that the application

works in the production environment. Test cases should include
error processing and recovery, performance, storage requirements,
hardware compatibility, and security (e.g., screens, data, and
programs).

e) Acceptance testing - verifies that acceptance criteria defined during

the project definition stage are tested. Test cases should include
system usability, management reports, performance measurements,
documentation and procedures, training (e.g., users, help desk,
production support, and operations), and system readiness
(operations/systems sign-off).

• The auditor may be called on to assure management that both developers

and users have thoroughly tested the system. If the level of testing does
not meet standards, the auditor must notify the development team or
management who will then take corrective action.

7
Implementation • The final step to implementing the system includes conversion,
documentation, training, and support.

• A data conversion plan is developed to migrate existing data into the new
system. Great care needs be taken to prevent loading garbage data into
the new system.

• To ensure smooth implementation, it is important that users and

technical support people receive adequate training. To facilitate this
training, both system and user documentation need to define the
functionality of the system.

Typical Controls:
a) Approval from the project sponsor(s) and stakeholders is
required in order to go live.

b) During go-live, access to source code in the production and

staging/test environments is restricted from developers.

c) A post-implementation review is performed to ensure that

system is functioning as intended.

User Acceptance Testing (UAT)

a) User acceptance testing is a key to a successful system
implementation. It ensures that the application fulfills the
agreed-upon functional expectations of the users, meets
established usability criteria, and satisfies performance
guidelines before being implemented into production.

b) Acceptance testing minimizes the risks that the new application

will cause business interruptions or be disjointed with business
processes. Acceptance testing should include all components of
the system (facilities, application software, procedures, etc.).

Auditor Interests in the Implementation

• The system should be installed and fully operational by the
Implementation phase. Support documentation must be in place
prior to the system entering production use.

• All of the appropriate personnel will have been trained to fulfill

their roles. The system has completed a final user acceptance
test.

• The auditor may review the implementation strategy,

communication and training material, documentation,
conversion procedures, and production readiness.

• You need to verify that appropriate quality control procedures

have been executed in support of these objectives. You also need
to verify that formal management approval was obtained before
the system entered production use. Any deficiencies in
management approval should be reported to the audit committee
or project oversight.

8
 Roles and Responsibilities in the System Development Life Cycle

Role Description of Responsibility

User Community • Help define business objectives and requirements
• Participate in User Acceptance Testing (UAT)
Business Owner/ • Approve initial request, as well as timelines and deliverables
Sponsor associated with project milestones
• Approve requirements, formal test criteria and test results
• Authorize implementation of the program
System/Business • Act as a liaison between the user community and IT
Analyst • Participate in testing the new system from a functional
perspective
• Provide training for new system functions
Application Developer • Develop the new program code
• Perform data conversion activities
• Perform unit and system testing
Production Control/ • Move code between environments
Librarian • Update system specifications
Project Manager/ • Perform project management functions
Application • Communicate with stakeholders
Development Manager • Manage the implementation of the new system.

ITGC 4.2 Audit of Program Change

The domain objective is: "To ensure the changes to programs and related infrastructure components
are requested, authorized, performed, tested, and implemented to achieve management's application
control objectives."

The entity is to demonstrate, with reasonable assurance, that sufficient program change controls
are applied consistently to all programs, applications or data that are relevant to the audit. In
order to demonstrate this, the typical subcomponents of program change are considered:

• Specification, authorization and tracking of change requests

• Construction
• Testing and quality assurance
• Program implementation
• Segregation of duties

9
 Monitoring and testing that all relevant program changes have been subjected to the entity's
program change controls can be made easier when the entity's IT systems produce reliable evidence
(i.e., an "audit trail") of the full population of program changes. If a reliable report of all compilation
dates of all programs placed in production is available, management can more readily demonstrate
that every program change went through its controlled process.

However, not all IT systems are designed to produce reliable, automated information about
the population of changes. Some will log only the date of last modification. Others may be able to log
all changes, but perhaps those logs can be circumvented or overwritten by those with direct access to
the program's production environment.

A lack of system-generated program change data does not in itself preclude

management from being able to demonstrate, with reasonable assurance, that the entity's
program change controls are applied consistently to relevant program changes.

Some factors to consider in evaluating whether there can be reasonable assurance that all such
changes have been dealt with appropriately might include:

• The types of applications used, whether the entity has access to the source code, and the
nature and volume of routine program changes

• Whether changes are rigorously tracked, electronically or manually, by parties who are
independent from those requesting or making the changes, using data that cannot be
altered by those requesting or making the changes

• Whether separate environments are maintained for development, testing and production,
and only the appropriate individuals have access to each of those environments

• Whether responsibilities are segregated appropriately such that the person responsible for
identifying, tracking, and reporting on the status of change requests does not have
accounting or finance responsibilities

• Whether "auditing" is enabled for any of the applications

Program Change Process (PWC)

1. Change Requests:
a) Documentation to support a modification of a system. (Change Request Form)

b) Can be initiated by the business user community or IT support personnel.

c) Can pertain to different types of changes:

• Source code / New version of the application
• Reports
• Vendor supplied patches
• Configuration

d) Reasons for system changes.

• To enhance functionality: everyday system users may not be content with the
functionality of the system like the system response time. Users may also identify bugs
in programs which cause the system to produce erroneous results.

• To make systems operations easier, more efficient for database administrator and
network management personnel.

10
 • Capacity planning: the system may require additional resources or increased capacity
components e.g. A more powerful CPU to cope with increased processing demand, or
additional disk drives as the existing drives fill up.

• Problem rectification

• To improve security: IT security personnel: identified weaknesses in system security

may result in requests for change which should improve security.

• Changes in requirements: changes in legislation, business requirements or business

direction may require the financial system to be amended.

e) Formal documentation allows management to manage multiple requests in accordance

with policies.

f) Depending on the type of change, authorization from a business user manager, IT manager,
or both is required before work can begin on the change.

g) There are circumstances that don’t require authorisation, which occur when the change
has little to no financial impact (minor), or when it is an emergency.

Typical Control Test Procedures

Change requests must be authorized • Obtain a system generated list of
by an appropriate level of business changes to program source code
and, if necessary, IT management. objects. Determine the frequency and
select a population of changes.

• Ensure that for each change an

authorized change request is
present.

Figure 4.2 Sample of Change Request Form Template

11
2. Construction:
a) Changes are made to the application source code in an environment separate from that of
production. Application developers should ensure that only one developer is working on a
piece of code at one.

b) Prior versions of source code should be saved in case the company needs to revert back to
the old code. Source code control software can achieve both the retention of prior versions
and prevent more than one developer from editing code simultaneously.

Typical Control Test Procedures

a) The production environment is • Inspect a system architecture
logically separated from that of diagram and/or the configuration
development and test. of the source code control tool to
ensure multiple environments are
in use.

b) Source code control ensures that • Observe a programmer attempt to

source code is not modified edit a program object when it is
simultaneously. currently being for edited by
another programmer.

c) Version control ensures that prior • Inspect the configuration of the

versions of source code are source code control tool (or the
retained. manual versioning process) to
ensure that prior versions of
source code are being saved.

3. Testing and Quality Assurance:

a) Changes are first tested by the developer in the Development environment to ensure the
change works as he/she intended (unit testing).

b) Changes should then be tested in the Test environment by a member of the user community
that owns the application and underlying data (user acceptance testing or UAT). The
user “accepts” the change when the change made meets requirements documented in the
change request.

c) Test plans and results should be retained to evidence performance of the control.

Typical Control Test Procedures

a) Changes are unit tested by the • Using the same sample of source
developer performing the change. code changes selected for testing the
authorization of change requests,
inspect relevant program change
documentation for evidence of
developer unit testing (i.e. test
plans, test results, and/or developer
sign-off).
b) User acceptance testing is • Using the same sample of source
performed by the user(s) code changes selected for testing the
requesting the change. authorization of change requests,
inspect relevant program change
documentation for evidence of user
acceptance testing (i.e. test plans,
test results, and/or user sign-off).

12
 4. Program Implementation:
a) A process is needed to move the approved changes into the production environment.
Process is often facilitated by a change control tool. Source code control tools can also
move changes to production.

b) Segregation of logical environments and associated segregation of duties must be

considered.

c) Change control meetings are often used to coordinate changes among various departments
(business users and IT). Because testing can never fully anticipate all possible issues,
backout procedures are critical.

d) “Emergency” changes should not bypass significant controls, even if those controls are
formalized after the change is completed.

An emergency change shall be defined as any action that is necessary for the immediate
and continued operation of essential department functions and required to be
implemented before the business owners/program sponsors are able to review and
approve.

The requestor will submit the Change Control Request (CCR) after the affected system
has been modified, and will be approved post change by the business owners.

In the judgment of the requestor, if the incident is a major incident, there should be
attempts made to contact the business owners to alert them to the incident and its
resolution, either by phone or, failing that, email. Documentation from the business
owners/program sponsors that approved the emergency action is to be included in the
change request system.

Typical Control Test Procedures

a) Change control meetings are • Using the same sample of source
conducted in order to prioritize code changes selected for testing the
and approve the migration of authorization of change requests,
changes to production. inspect program change
documentation for evidence that
change control meetings were
conducted and that each change was
approved prior to migration to
production.

b) Backout procedures are • Using the same sample of source

documented. code changes selected for testing the
authorization of change requests,
inspect relevant program change
documentation for evidence that
backout procedures were
documented.

Segregation of Duties

The following abilities must be segregated:

• The ability to request and approve a change should be segregated.
• The ability to perform development activities and migrate changes to production should be
segregated.

13
Lack of segregation of duties
• Monitoring controls must be in place if segregation of duties is not.
• If there is unauthorized access to production, changes to production should be monitored on
a periodic basis.

Development Environment
• Programmers have read/ write/ execute
• Programmers make modifications
• End-users do not have any access
• Unit and system testing by developers

Test Environment
• Programmers have read/execute access only
• No modifications made to code
• End-users have read/execute access to data and programs
• Integration and user acceptance testing are performed here

Production Environment
• Programmers have no access (or read only)
• No modifications made to code
• Live use by end-user community
• End user has no access to program code. End users should only modify data via approved
program functions appropriate to their job functions.

Roles and Responsibilities

Role Description of Responsibility

User Community • Initiate change requests
• Participate in User Acceptance Testing (UAT)
Business Owner • Approve and prioritize change requests
• Approve testing performed
• authorize transfer to the live environment
Application Developer • Modify program code
• Perform unit and system testing
Production Control/ • Move code between the development, test and production
Librarian environments
Application Support • Manage the activities of application developers as
Manager (i.e. program code is modified
Programming Mgr.)
System Programmer/ • Identify, test and apply updates to system software
System Administrator • Coordinate system software changes with business areas

Self-Check

1. Why is ITGC important in the financial

statements audit?

2. What are the risks involved if system/program

development and program change controls are
not effective?

14
ITGC 4.3 Audit of Information System Operations - “Computer Operations”

Computer operations are in charge of the daily support of an organization's Information

System hardware and software environment. This function is particularly important when very
large and centralized computing tasks are regularly executed for business purposes, producing
output or updating situations.

Activities in computer operations often present operational risk, not a risk of material
misstatement, depending on the entity's specific circumstances. Some elements of computer
operations may be relevant to the audit, particularly when they serve not only as ITGCs, but also as
application controls that directly support relevant financial statement assertions.

For example, job scheduling is an IT activity that could directly impact the completeness and
accuracy of financial data if it were to break down. Similarly, backup and recovery procedures may
be important to the risk of financial misstatement if data recoveries are frequent, such as when
systems are unstable.

Operating Standards and Procedures

Every computer installation should have specific standards and procedures manuals covering
operations. Although most operations have some type of standards and manuals covering them,
having policies and procedures in place is much easier than actively enforcing policies and
procedures. The weakness with many operations policy and procedures manuals is their lack of use.

The manager or auditor should regard operating standards and procedures manuals as
highly important controls. Accordingly, these controls should be tested periodically. This can be
done through observation to determine if the standards and procedures described in the manuals
actually are being followed in the day-to-day operation of the computer center.

An important element of any set of standards or manuals should be the requirement that
operators maintain logs on which any unusual events or failures are recorded, according to time and
in detail. If such logs do not exist or are not kept faithfully, a major control weakness is indicated.

Computer operations include the following:

1. Transaction Processing Activities

a) Interface Processing

Risks to financial data

• Unauthorized or inappropriate changes to interfaces are implemented
• Processing errors occur leading to incomplete or inaccurate financial data

Controls
• Authorize changes to interfaces and management review of changes to interfaces
• Restrict access to the functionality used to modify interfaces
• Monitoring of interface processing

b) Batch or Job Scheduling - a job is normally a process or sequence of batch processes

which are run overnight or in background and which update files etc. Jobs are normally
run periodically, either daily, weekly, monthly.

15
 Risks to financial data
• Unauthorised or inappropriate changes to the scheduler are implemented resulting
in production processing errors

Controls
• Restrict access to the functionality used to modify the batch schedule
• Periodic review of who is able to access the batch schedule
• Changes to the schedule are authorised
• Management review of changes to the schedule

c) Monitoring of Transaction Processing

Risks to financial data

• Errors in production processing are not identified and resolved in a timely manner
resulting in inaccuracies in, or loss of data.

Controls
• Control access to processing functionality
• Formalized procedures for processing failure identification & resolution

2. Data Center Operations

a) Service Continuity Management & Backups - is the set of activities that is concerned
with the ability of the organization to continue providing services, primarily in the event
that a natural or manmade disaster has occurred.

Disaster Recovery Planning - a disaster recovery plan is a comprehensive statement of all

actions to be taken before, during, and after a disaster, along with documented, tested
procedures that will ensure the continuity of operations.

During the 1980s, the term disaster recovery became popular as a definition for rebuilding
and recovery following a natural disaster. The entire focus of disaster recovery could be
summed up with a one-word definition: rebuilding.

The approach to any risk should be to try to remove the threat by considering business
locations, building materials and duplication of key functions at remote sites. However
modern business is, it cannot avoid all forms of corporate risk or potential damage. A
realistic objective is to ensure the survival of an organization by establishing a culture that
will identify and manage those risks that could cause it to suffer.

16
 Examples of these corporate risks include:
• Inability to maintain critical customer services
• Damage to market share, image, reputation or brand
• Failure to protect the company assets, including intellectual properties and
personnel
• Business control failure
• Failure to meet legal or regulatory requirements

Once the risk exposures have been identified, a disaster recovery plan can be assembled
that details a plan for hardware, software, data, and personnel. The plan should identify
various levels of recovery, from an isolated event to a widespread disaster. The timeliness
of recovery will depend on the loss exposure for the particular application.

When the plan is completed, it should be tested to identify problems in the plan.
Testing should be conducted on a periodic basis to validate assumptions and update the
plan based on the changing environment. It also provides the opportunity to practice the
recovery procedures and identify missing elements that need to be added.

Essential features of a Disaster Recovery Plan include:

i. Providing Second-Site Backup for replacement data processing capabilities.

• The Empty Shell “cold site” - involves two or more user organizations that buy
or lease a building and remodel it into a computer site, but without computer
equipment. It must be carefully negotiated and enforced. Otherwise, longer
recovery time and possible lower access than promised.

• The Recovery Operations Center “hot site” - a completely equipped site; very
costly and typically shared among many companies. It must be up within a few
hours. Same “actual versus promised” access risks as cold site.

Types of Backup:

• Full backup - A full backup is the most basic of all backup types. And as its name
suggests, it’s also the most comprehensive. In a full data or system backup, all
data is copied to another location.

• Incremental backup - This type only backs up the information that has changed
since the last backup occurred.

• Differential backups - Similar to an incremental backup, a differential backup

copies all data changed since the last full backup every time it is run.

ii. Identifying Critical Applications

• What affects the completion of short-term obligations and cash flow?
• Priorities change over time and should be reviewed regularly.
• Teams of users, accountants and auditors need to be involved.

iii. Creating a Disaster Recovery Team - Traditional control segregations, access

restrictions, and supervision typically do not apply in the event of a disaster.

iv. Testing the DRP

• Measure the preparedness of the planned sites, files, programs, and personnel.
• Identify potential bottlenecks, omissions, and problems before the disaster.
• Make sure that the test is a surprise.
• Test results to benchmark on future performances.
• Carry out the test as far as is economically feasible.

17
 Business Continuity Planning (BCP)

The auditor should ensure that there are adequate plans to resume processing in the event
of failure of computer operations. The degree of continuity planning will depend on the
size of the IT department and the involvement on computer processing. A significant and
prolonged loss of IT capability in a mission critical system may increase the risk of the
financial statements being unavailable or materially misstated.

Unlike DR, business continuity (BC) focuses on revenue. As long as the organization has
time and money at its disposal, the organization can continue to function. Money can take
the form of capital, credit lines, investors, and payments from customers. Business
continuity focuses on putting more money in the bank, even if the business is not
delivering a product.

The first step of preparing a new Business Continuity Plan is to identify the business
processes of strategic importance, which are those key processes that are responsible
for both the permanent growth of the business and for the fulfilment of the business goals.

Ideally, the BCP should be supported by a formal executive policy that states the
organization's overall target for recovery and empowers those involved in developing,
testing and maintaining the plans

BCP is primarily the responsibility of senior management, as they are entrusted with
safeguarding the assets and the viability of the organization, as defined in the BCP policy.

b) Media Management - includes the control of disks and tapes, CD ROMs, etc. Technology
assets should be inventoried and tracked. Proper ownership labels or property tags
should be in use. Tagging and labeling are preventative controls. The audit of inventory
tags is a detective control. Media containing software and data should be managed under
a data library a.

Each computer installation should have a data library and procedures that control
access to programs, data files, and documentation. Library procedures should assure that
only authorized persons receive files, programs, or documents, and that these persons
acknowledge their responsibility at the time of each issuance.

Control is enhanced by the practice of maintaining an inventory of file media within the
data library. That is, an inventory record should exist for each tape cartridge or disk pack.
The record should note any utilization or activity. After a given number of users, the file
medium or device is cleaned and recertified. Further, if any troubles are encountered in
reading or writing to the device, maintenance steps are taken and noted.

Ideally, a full-time person independent of computer operations will be assigned as

the data librarian. In smaller installations, however, such assignment might not be
economically feasible. When an installation cannot afford a full-time librarian, this
custodial duty should be segregated from operations.

c) Environment Controls - All network equipment operates under daily office conditions
(e.g., humidity, temperature, smoke, and electrical flow). However, a specific office
environment may not be suited to a microcomputer because of geographical location,
industrial facilities, or employee habits. A primary problem is the sensitivity of
microcomputer equipment to dust, water, food, and other contaminants. Water and other
substances cannot only damage the keyboard, CPU, disk drive, and diskettes but also may
cause electrocution or a fire. To prevent such occurrences, the network manager should
adhere to a policy of prohibiting food, liquids, and the like at or near the microcomputer.

18
Although most offices are air-conditioned and temperatures and humidity are usually
controlled, these conditions must nonetheless be evaluated by the network manager. If for
any reason the environment is not controlled, the network manager should take
periodic readings of the temperature and humidity. If the temperature or humidity is
excessively high or low, the microcomputer equipment and the network should be shut
down to prevent loss of equipment, software, and data.

Airborne contaminants can enter the equipment and damage the circuitry. Hard disks
are susceptible to damage by dust, pollen, air sprays, and gas fumes. Excessive dust
between the read/write head and the disk platter can damage the platter or head or cause
damage to the data or programs.

If there is excessive smoke or dust, the microcomputers should be moved to another

location. Small desktop air filters can be placed near smokers’ desks to reduce smoke, or
the responsible manager can limit smoking to specific locations, away from
microcomputer equipment.

Static electricity is another air contaminant. Using antistatic carpeting can reduce static
electricity as well as pads placed around the microcomputer area, antistatic chair and
keyboard pads, and special sprays that can be applied to the bottoms of shoes. Machines
can also be used to control static electricity in an entire room or building.

Major causes of damage to network equipment are power surges, blackouts, and
brownouts. Power surges, or spikes, are sudden fluctuations in voltage or frequency in
the electrical supply that originates in the public utility. They are more frequent when the
data center is located near an electrical generating plant or power substation. The sudden
surge or drop in power supply can damage the electronic boards and chips as well as cause
a loss of data or software.

If power supply problems occur frequently, special electrical cords and devices can be
attached to prevent damage. These devices are commonly referred to as power surge
protectors.

Blackouts are caused by a total loss of electrical power and can last seconds, hours, or days.
Brownouts occur when the electrical supply is diminished to below-normal levels for
several hours or days. Although brownouts and blackouts occur infrequently, they are
disruptive to continuing operations.

If microcomputer use is essential and the organization’s normal backup power is limited
to necessary functions, special uninterruptible power supply (UPS) equipment can be
purchased specifically for the microcomputer equipment.

UPS equipment can be either battery packs or gas-powered generators. Battery packs
are typically used for short-term tasks only (e.g., completing a job in progress or
supporting operations during a transition to generator power).

Gas-powered generators provide long-term power, and conceivably, could be used

indefinitely.

i. To prevent loss of or damage to equipment, services, or facilities, safeguards to power

supply and physical access to machine rooms and other critical areas have to be
restricted to authorized personnel. Specialized equipment has to be installed to:
• Restrict access to authorized personnel using badges and password controls
• Avoid transient surges and outages in power supplies
• Provide alternative sources of power in the event of extended power failures

19
 ii. To reduce the risk of services being disrupted by loss of power or deterioration of
ambient conditions, critical computer equipment and facilities have to be protected
from transient surges and outages in power supplies and extended power failure by:
• Installing devices that stabilize power supplies
• Providing backup generators
• Protecting power cables

d) Capacity Planning - ensuring that the computer systems will continue to provide a
satisfactory level of performance in the longer term. This will involve IT operation staff
having to make estimates of future CPU requirements, disk storage capacity and network
loads capacity.

e) Performance & Network Monitoring - monitoring the day to day performance of the
system in terms of measures such as response time. The IT operations function is also
given the responsibility for ensuring that communication links are maintained.

3. Helpdesk and Problem Management

Helpdesk/Service Desk

Helpdesks are the day-to-day link between users with IT problems and the IT department. They
are the ones users call when they have a printer problem or they forget their password. Problems
may be encountered with individual programs (applications and system), hardware, or
telecommunications.

People may call in for help with a variety of computing problems. It is the help desk’s responsibility
to escalate trouble tickets in a timely manner. Some trouble tickets might be escalated to the
system administrator or application support programmer.

The help desk tracks call metrics so that trends can be analyzed. As an IT auditor, you should
understand the help desk function. It would be beneficial to conduct a review of the staff on the
help desk to determine their level of competency. An audit trail should exist, documenting the
process for logging and tracking service requests. You should evaluate the level of documentation
for help desk activities and troubleshooting procedures.

Problem Management

When several incidents have occurred that appear to have the same or a similar root cause, a
problem is occurring. The overall objective of problem management is the reduction in the
number and severity of incidents.

Examples of problems include:

• A server that has exhausted available resources that result in similar or multiple errors
• A software bug in a service that is noticed by and affecting many users
• A chronically congested network that causes the communications between many IT
components to fail

Self-Check

1. What is the objective of Computer Operations

controls?

2. List risks to financial reporting associated with

operations

20
ITGC 4.4 Audit of Information System Operations - “Access to Programs and Data”

Information and information systems are critical assets in most organizations today. Without
reliable and properly secured information and information systems, organizations would quickly go
out of business. Likewise, the preservation and enhancement of an organization’s reputation is
directly linked to the way in which both information and information systems are managed.
Maintaining an adequate level of security is one of the several important aspects of both information
management and information systems management.

Information Security Management

Information security management is the collection of policies, processes, and procedures that
ensure an organization’s security policy is effective. Security management is composed of a number
of distinct and interrelated processes, including policy development and enforcement, security
awareness training, user access management, security incident management, vulnerability
management, service provider management, encryption, network access management, and physical
access controls. Ongoing executive support is key to the success of a security management program.

These and other processes should be periodically audited to confirm their effectiveness.
Control failures and exceptions should be documented, and actions plans developed to improve
processes and systems.

The purpose of information security is to help ensure that the organization’s strategic
business objectives are met. The three fundamental objectives for information are confidentiality,
availability, and integrity. Each of these has associated risks that would prevent achieving these
objectives.

a) Confidentiality is the protection of information from unauthorized access. This is important

in maintaining our company image and complying with privacy laws. Possible risks associated
with confidentiality include:
• Security breaches allow unauthorized access or disclosure of sensitive or valuable
company data, such as policyholder information or corporate strategic plans, to
competitors or public.

b) Availability is maintaining information systems in support of business processes. This is

important in maintaining operational efficiency and effectiveness. Possible risks associated
with availability include:
• Significant disruption or failure of information systems, including loss of our ability to
process business.
• Crash of systems due to a variety of sources, such as catastrophes, viruses, or sabotage

c) Integrity is the correctness and completeness of information. This is important in maintaining

the quality of information for decision making. Possible risks associated with information
integrity include:
• Security breaches allow unauthorized access to information systems, resulting in
corrupted information.
• Security breaches allow unauthorized access to information systems, resulting in fraud
or misuse of company information or systems.

Key Elements of Information Security Management

1. Senior management, leadership, commitment and support
2. Policies and support
3. Organization
4. Security awareness and education
5. Monitoring and compliance
6. Incident handling and response

21
Identifying the Perpetrators
There is one fundamental difference between a victim and a perpetrator. The victim did not
act with malice. The perpetrators of crime may be casual or sophisticated. Their motive may be
financial, political, thrill seeking, or a biased grudge against the organization. The damage impact is
usually the same regardless of the perpetrator’s background or motive.

A common trait is that a perpetrator will have time, access, or skills necessary to execute the
offense. A person with mal-intent needs little more than access to launch their attack. For this reason,
strong access controls are mandatory. So, who is the attacker?

Hackers
The term hacker contains a double meaning. The honorable interpretation of hacker refers to
a computer programmer who is able to create usable computer programs where none previously
existed. The criminal hacker focuses on a desire to break in, take over, and damage or discredit
legitimate computer processing.

The first goal of hacking is to exceed the authorized level of system privileges. This is why it is
necessary to monitor systems and take swift action against any individual who attempts to gain a
higher level of access. Hackers may be internal or external to the organization. Attempts to gain
unauthorized access within the organization should be dealt with by using the highest level of
severity, including immediate termination of employment.

Crackers
The term cracker is a variation of hacker with the analogy equal to a safe cracker. Some
individuals use the term cracker in an attempt to differentiate from the honorable computer
programmer definition of hacker. The criminal cracker and criminal hacker terms are used
interchangeably. Crackers attempt to illegally or unethically break into a system without
authorization.

Script Kiddies
A script kiddie is an individual who executes computer scripts and programs written by others.
Their motive is to hack a computer by using someone else’s software.

Examples include password decryption programs and automated access utilities. Internal
controls must be put in place to restrict the possession or use of administration utilities. Violations
should be considered severe and dealt with in the same manner as hacker violations.

Employee Betrayal
A person within the organization has more access and opportunity than anyone else. Few
persons would have a better understanding of the security posture and weaknesses. In fact, an
employee may be in a position of influence to socially engineer co-workers into ignoring safeguards
and alert conditions. This is why it is important to monitor internal employee satisfaction. The great
medieval fortresses fell by the betrayal of trusted allies.

Third Parties
External persons are referred to as third parties. Third parties include visitors, vendors,
consultants, maintenance personnel, and the cleaning crew. These individuals may gain access and
knowledge of the internal organization.

Ignorance
The term ignorance is simply defined as the lack of knowledge. An ignorant person may be a
party to a crime and not even know it. Even worse, the individual may be committing an offense
without realizing the impact of their actions.

Fortunately, ignorance can be cured by training. This is the objective of user training for
internal controls. By teaching the purpose of internal security controls, the organization can reduce
their overall risk.

22
Active Attacks
The active attack is designed to execute an act of theft or to cause a disruption in normal
computer processing. Following is a list of active attacks:

1. Social engineering - Criminals can trick an individual into cooperating by using a technique
known as social engineering. The social engineer will fraudulently present themselves as a
person of authority or someone in need of assistance. The social engineer’s story will be woven
with tiny bits of truth. All social engineers are opportunists who gain access by asking for it.
For example, the social engineer may pretend to be a contractor or employee sent to work on
a problem. The social engineer will play upon the victim’s natural desire to help.

2. Phishing - A new social engineering technique called phishing (pronounced fishing) is now in
use. The scheme utilizes fake emails sent to unsuspecting victims, which contain a link to the
criminal’s counterfeit website. Anyone can copy the images and format of a legitimate website
by using their Internet browser.

Phishing criminal copies legitimate web pages into a fake email or to a fake website. The
message tells the unsuspecting victim that it is necessary to enter personal details such as US
social security number, credit card number, bank account information, or online user ID and
password. Phishing attacks can also be used to implement spyware on unprotected computers.
Many phishing attacks can be avoided through user education.

3. Dumpster diving - Attackers will frequently resort to rummaging through the trash for
discarded information. The practice is also known as dumpster diving. Dumpster diving is
perfectly legal under the condition that the individuals are not trespassing. This is the primary
reason why proper destruction is mandatory. Most paper records and optical disks are
destroyed by shredding.

4. Virus – Computer viruses are a type of malicious program designed to self-replicate and spread
across multiple computers. The purpose of the computer virus is to disrupt normal processing.
A computer virus may commence damage immediately or lie dormant, awaiting a particular
circumstance, such as the date of April Fools’ Day. Viruses will automatically attach themselves
to the out-going files.

The first malicious computer virus came about in the 1980s during prototype testing for self-
replicating software. Antivirus software will stop known attacks by detecting the behavior
demonstrated by the virus program (signature detection) or by appending an antivirus flag to
the end of a file (inoculation, aka immunization).

New virus attacks can be detected if any program tries to append data to the antivirus flag. Not
all antivirus works by signature scanning, it can also be by heuristic scanning, integrity
checking, or activity blocking. These are all valid virus detection methods.

5. Worm – Computer worms are very destructive and able to travel freely across the computer
network by exploiting known system vulnerabilities. Worms are independent and will actively
seek new systems on their own.

6. Logic bomb - The concept of the logic bomb is designed around dormant program code that is
waiting for a trigger event to cause detonation. Unlike a virus or worm, logic bombs do not
travel. The logic bomb remains in one location, awaiting detonation.

Logic bombs are difficult to detect. Some logic bombs are intentional, and others are the
unintentional result of poor programming. Intentional logic bombs can be set to detonate after
the perpetrator is gone.

7. Trapdoor - Computer programmers frequently install a shortcut, also known as a trapdoor,

for use during software testing. The trapdoor is a hidden access point within the computer
software. A competent programmer will remove the majority of trapdoors before releasing a
production version of the program.
23
 However, several vendors routinely leave a trapdoor in a computer program to facilitate user
support. The commercial version of PGP encryption software contained a trapdoor designed
to recover lost encryption keys and to allow the government to read the encrypted files, if
necessary. Trapdoors compromise access controls and are considered dangerous.

8. Brute force attack - Brute force is the use of extreme effort to overcome an obstacle. For
example, an amateur could discover the combination to a safe by dialing all of the 63,000
possible combinations. There is a mathematical likelihood that the actual combination will be
determined after trying less than one-third of the possible combinations.

Brute force attacks are frequently used against user logon IDs and passwords. In one particular
attack, all of the encrypted computer passwords are compared against a list of all the words
encrypted from a language dictionary. After the match is identified, the attacker will use the
unencrypted word that created the password match. This is why it is important to use
passwords that do not appear in any language dictionary.

9. Denial of service (DoS) - Attackers can disable the computer by rendering legitimate use
impossible. The objective is to remotely shut down service by overloading the system and
thereby prevent the normal user from processing anything on the computer.

10. IP fragmentation attack - One of the common Internet attack techniques is to send a series
of fragmented service requests to a computer through a firewall. The technique is successful if
the firewall fails to examine each packet. For this reason, firewalls are configured to discard IP
fragments.

11. Crash-restart - A variation of attack techniques is crash-restart. An attacker loads malicious

software onto a computer or reconfigures security settings to the attacker’s advantage. Then
the attacker crashes the system, allowing the computer to automatically restart (reboot). The
attacker can take control of the system after it restarts with the new configuration. The
purpose is to install a backdoor for the attacker.

12. Maintenance accounts - Most computer systems are configured with special maintenance
accounts. These maintenance accounts may be part of the default settings or created for
system support.

An example is the user account named DBA for database administrator, or tape for a tape
backup device. All maintenance accounts should be carefully controlled. It is advisable to
disable the default maintenance accounts on a system.

13. Salami technique - The salami technique is used for the commission of financial crimes. The
key here is to make the alteration so insignificant that in a single case it would go completely
unnoticed, e.g., a bank employee inserts a program into the bank’s servers that deducts a small
amount of money from the account of every customer. No single account holder will probably
notice this unauthorized debit, but the bank employee will make a sizable amount of money
every month.

14. Email spamming and spoofing - You are probably aware of email spamming. Spamming
refers to sending a mass mailing of identical messages to a large number of users. The current
laws governing email allow a business to send mass emails as long as the recipient is informed
of the sender’s legitimate address and the recipient is provided a mechanism to stop the
receipt of any future emails. Email spamming is a common mechanism used in phishing
attacks.

The term spoofing refers to fraudulently altering the information concerning the sender of
email. An example of email spoofing is when an attacker sends a fake notice concerning your
eBay auction account. The spoofed email address appears as if it were sent by eBay.

24
Other Computer Attacks
1. File alteration - occurs when the defrauder revises specific data or manipulates data files. For
example: Fraudulently changing the rate of pay of an employee in the payroll master file via a
program instruction Transferring balances among dormant accounts to conceal improper
withdrawals of funds.

2. Data theft - Data theft can be accomplished by data interception or smuggling out computer
data files or hard copies of reports/files. Data transmitted by data communication lines can be
tapped or intercepted. Magnetic devices can be smuggled out in briefcases, employees'
pockets, etc.

3. Sabotage - The physical destruction of hardware or software.

4. Eavesdropping - A computer can be used to eavesdrop on electronic messaging, such as e-

mail, instant messaging, and even voice over IP (VoIP).

5. Espionage - An individual or group obtains information considered a military, political, or

industrial secret.

6. Masquerading or impersonation – is gaining access to the system by pretending to be an

authorized user. This approach requires a perpetrator to know the legitimate user’s ID number
and password.

7. Cyber-extortion – fraud perpetrators threaten to harm a company if it does not pay a

specified amount of money. For example, the owner of a small company that processed credit
cards for online businesses received an unsolicited e-mail listing the names of his clients, as
well as the names and credit card numbers of customers the client had done business with
over the weekend. The email told him to pay P500,000 in six equal payments or the data would
be sent to his clients.

8. Software piracy – copying software without the publisher’s permission.

Asset Inventory and Classification

Information assets fall into two basic categories: information and information systems.
Information consists of software, tools, and every type of data. Information system is an inclusive
term that encompasses servers, workstations, mobile devices, network devices, gateways, appliances,
and almost every other kind of IT hardware that is used.

Hardware Asset Inventory

An IT organization that is responsible for the management of information and information
systems must have a means for knowing what all of those assets are. More than that, IT needs to
acquire and track several characteristics about every hardware asset, including:

1. Specific identification of the asset

2. Relative value to the organization
3. Loss implications and recovery priority
4. Location
5. Security/Risk classification
6. Asset group
7. Owner
8. Designated custodian

Information Assets
Sometimes overlooked because it is intangible, the information that is stored in systems
should be treated as an asset. In almost all cases, information such as software and databases have
tangible value and should be included in the list of IS assets.

25
 In most organizations, various types and sets of information will have varying degrees of
sensitivity. These levels of sensitivity will implicitly dictate that information in different levels should
be handled somewhat differently.

For instance, the most sensitive information should be encrypted whenever stored or
transmitted and should be accessible to only those individuals who have a justified need to use it.

Information classification program can be defined in detail in less than a dozen pages, and the
practical portions of it could almost fit on a single page. For many organizations, a simple four-level
classification program is a good place to start. The four levels could be: secret, restricted,
confidential, and public. Any information in the organization would be classified into one of these
four levels.

Handling procedures for each of these levels is found in Table 4-1 below.

Secret Restricted Confidential Public

Password; Credit card System Brochures;
merger & numbers; bank documentation; press releases
acquisition account end-user
Examples plans and terms numbers; documentation;
detailed internal memos
financial
records
Storage on Must be Must be Access controls No restrictions
server encrypted; store encrypted required
only on servers
labeled
sensitive
Storage Must never be Must be Access controls No restrictions
on mobile stored on encrypted required
device mobile
device
E-mail Must never be Must be Authorized No restrictions
e-mailed encrypted recipients only
Web site Must never be Must be Access controls No restrictions
stored on any encrypted required
web server
Hard copy Double locked Double locked Locked No restrictions
storage in authorized
locations only
Hard copy Only with To authorized To authorized No restrictions
distribution owner parties only; parties only
permission; only with owner
must permission
be registered
Hard copy Cross-cut shred; Cross-cut shred Cross-cut shred No restrictions
destruction make record of or secure waste
destruction bin

Access Controls
Access controls are the technology-based methods of controlling access to an information-
based resource. Access controls must be actively managed by staff members who are authorized to
perform this function and trained to perform it properly.

26
Access Control Management
The management of access controls requires that processes and business rules be established
that govern how access controls are managed. These processes and rules are used to decide which
persons will be permitted to access which data and functions in the organization. The processes to
manage access controls are:

• Access control request - Any new request for access must be formally made via an
established request procedure. The request should be approved by the subject’s manager, as
well as by the owner of the resource to which access is being requested.

• Access control review - A periodic review of all users’ access to systems must be performed
to verify that everyone who has access is still entitled to that access and to verify that all access
for terminated employees has been removed.

• Segregation of duties review - A periodic review of each user’s access rights in all systems
must be performed to verify that each employee does not have a combination of access
privileges that would constitute a violation of segregation of duties.

• Employee transfer - When an employee is transferred from one position to another, the
access rights associated with the departed position must be removed and any new access
rights for the new position established.

• Employee termination - When an employee is no longer employed by the organization, all

access rights for that employee must be terminated immediately.

All of these processes must have a robust recordkeeping plan so that all requests, reviews,
transfers, and terminations are well documented. These records must themselves be restricted so
that only authorized persons may view them. These records also must be protected against
tampering.

In addition to these processes, there are several audit and monitoring procedures to verify
correct operation of these procedures.

Privacy
Privacy is the protection of personal information from unauthorized disclosure, use, and
distribution. Personal information refers to a variety of elements about a private citizen, some of
which are not well known, including their name in combination with one or more of the following:

• Date and place of birth

• Place of residence
• Fixed and mobile telephone numbers
• Social insurance (e.g., Social Security) number
• Driver’s license number
• Passport number
• Financial account (e.g., credit card, bank account, retirement account) numbers

More recently, the worry about privacy has concerned the rise in identity theft, which is made
possible from the proliferation of private information and the failure to adequately secure that
information. Cybercriminals have had an easy time discovering and stealing this information in order
to conduct wide-scale identity theft.

Access Control Models

Several access control models have been developed since the 1970s. These models are simple
mechanisms that are used to understand and build access control systems. The early models include
Biba, Bell-La Padula, Clark-Wilson, Lattice, Brewer and Nash, Take-Grant, and Non-Interference. The
models that are of interest to the IS auditor include:

27
 • Mandatory Access Control (MAC) - This access model is used to control access to objects
(files, directories, databases, systems, networks, and so on) by subjects (persons, programs,
etc.). When a subject attempts to access an object, the operating system examines the access
properties of the subject and object to determine if the access should be allowed. The operating
system then permits or denies the requested access. Access is administered centrally, and
users cannot override it.

• Discretionary Access Control (DAC) - In this access model, the owner of an object is able to
determine how and by whom the object may be accessed. The discretion of the owner
determines which subjects will be permitted access.

Internal Controls

1. Operating System Controls

The operating system allows users and applications to share and access common computer
resources. The larger the operating system, the greater the risks involved. Operating systems
themselves contain weaknesses and flaws that may be exploited by knowledgeable perpetrators to
either browse, modify data/programs, or add viruses.

These exposures come from three sources:

a) Privileged personnel who abuse their authority

b) Individuals who browse the operating system in order to identify and exploit security flaws
c) Individuals who insert a virus or other form of destructive program into the operating system.
• Viruses are replicable code parasites that infect many different types of files (.exe, .com, .olv,
etc.), book sectors and device driver programs.
• Worms fill work memory so system slows or stops
• Logic Bombs are virus-triggered by an upcoming event, like a date or an employment
termination.
• Back Doors open operating system passwords (guest, etc.)
• Trojan Horses capture passwords from unsuspecting users by copying them into a separate
file each time they are typed by users. This is typically accomplished by bypassing the
traditional log-on procedures.

Operating System Security

a) Log-On Procedures with lock-outs after a few tries with wrong password.
b) Access Tokens that record detailed user information and provide access authorizations.
c) Access Control Lists capture all directories, files, records, printers accessed during user
sessions.
d) Discretionary Access Control allows administrator override for specific authorizations.
e) Operating system integrity can be preserved by: Controlling Access Privileges (need to be
closely monitored and maintained) and Password Control

• Reusable Passwords: entered once and then the system accepts it each time the user
comes back to log in. (make them complex, with frequent changes, don’t write them
down and store the notes in obvious places, and use lock-out procedures)

• One-Time Passwords and smart-card technologies combined with a reusable PIN, or

with a challenge/response approach where the network generates a code, and the
smart card uses a private algorithm to create a one-time password.

• Controlling Against Malicious and Destructive Programs: Administrative and

technological controls that are recommended:

✓ Purchase software from reputable vendors in sealed packages.

✓ Establish corporate-wide policy for of copyrighted, licensed software only.
✓ Test all upgrades and all public-domain software before installation.
28
 ✓ Establish corporate policies for system development and program changes.
✓ Establish educational programs.
✓ Test all new applications and programs on a stand-alone computer with current
virus detection software.
✓ Routine backups of key files.
✓ Limit users to read and execute privileges as much as possible. Deny write
privileges unless needed for job description.
✓ Require log-on protocols to avoid Trojan Horses.

2. Data Security Controls

Authority Roles over Data

To implement policies, standards, and procedures, it is necessary to identify persons by their
authority. Three levels of authority exist in regard to computers and data.

Three Levels of Authority

a) Data Owner - The data owner refers to executives or managers responsible for the data
content. The role of the data owner is to do the following:
• Assume responsibility for the data content.
• Specify the information classification level.
• Specify appropriate controls.
• Specify acceptable use of the data.
• Identify users.
• Appoint the data custodian.

b) Data User - The data user is the business person who benefits from the computerized data.
Data users may be internal or external to the organization. For example, some data is delivered
for use across the Internet. The role of the data user includes the following tasks:
• Follow standards of acceptable use.
• Comply with the owner’s controls.
• Maintain confidentiality of the data.
• Report unauthorized activity.

c) Data Custodian - The data custodian is responsible for implementing data storage safeguards
and ensuring availability of the data. The custodian’s role is to support the business user. If
something goes wrong, it is the responsibility of the custodian to deal with this promptly. The
duties of the data custodian include the following:
• Implement controls matching information classification.
• Monitor data security for violations.
• Administer user access controls.
• Ensure data integrity through processing controls.
• Back up data to protect from loss.
• Be available to resolve any problems.

Database systems involve much more integration and sharing across users, leading to risks
of data corruption, theft, misuse, and destruction, from unauthorized users and abusive authorized
users. Database features that reduce these risks include:

a) User Views restrict the actions a user can take through authority table privileges.
b) Database Authorization Table contains the authorizations for read and write privileges.
c) User-Defined Procedures to add more specific security (mother’s maiden name).
d) Data Encryption is coded data for storage and transmission security.
e) Biometric Devices includes finger, voice and retina prints, and signature characteristics.

29
User Security and Administration
• Process of granting access to systems and data
• Often standard process that is common to all applications

Risk: Access is not adjusted for changes in employee status (i.e. terminations, transfers) in a timely
fashion

Consequence: Unauthorised access or segregation of duties conflicts.

Typical Control Procedures:

a) IT Security Administrator grants access to datasets as requested on a request form from the
business unit.
b) Permissions for Group Profiles (e.g. AP Manager, AP Clerk levels) are reviewed quarterly to
ensure they enforce “Segregation of Duties”.
c) Security administrators review an HR Terminations Report weekly and remove operating
system access for terminated users.

3. Application Security
• Unique to each application
• Often controlled with user id and password
• Responsibility of business and IT

Risk: Users are given access rights that allow them to perform tasks outside their normal duties

Consequence: Segregation of duties is not enforced; unauthorised transactions could be initiated and
processed

Typical Control Procedures:

a) Business unit management request user access based on their job function
b) Business unit management periodically reviews who has access to perform certain functions
within a particular application.
c) Access to amend standing data is restricted to a small number of authorised personnel

4. Internal Network - SecurityManagement implements and configures the following to enable

internal network security:
✓ Domains and trust relationships
✓ VLAN’s
✓ Routers and other internal network components
✓ Monitoring tools

Note: As auditors, we need to assess whether the design of the internal network gives rise to risks
over the applications and data in it. For example, the security and integrity of financially significant
spreadsheets reliant on internal network security.

5. Network Perimeter Security - Management can implement and configure the following to enable
perimeter network security:
✓ Firewalls (e.g. Checkpoint, Cisco PIX, Symantec)
✓ DMZ
✓ Intrusion Detection Systems (e.g. Cisco, ISS, Axent)
✓ VPN (for remote user access)

a) Network level firewalls

✓ low cost and low security access control
✓ does not explicitly authenticate outside users
✓ mainly for filtering out junk or improperly routed messages
✓ hackers can easily penetrate the system

30
 b) Application level firewalls
✓ a high level of customizable network security, but can be extremely expensive
✓ performs sophisticated functions such as logging or user authentication

• Digital signature: electronic authentication technique that ensures that the transmitted
message originated with the authorized sender and that it was not tampered with after the
signature was applied

• Digital certificate: like an electronic identification card that is used in conjunction with a
public key encryption system to verify the authenticity of the message sender

6. Privilege Accounts
• All applications, operating systems and databases (and other IT components such as firewalls)
will have “administrator” or privileged accounts e.g.:
✓ Windows = Domain Administrator
✓ UNIX = Root
✓ OS/400 = QSECOFR
✓ SQL Server database = DBA

• Requires additional security measures and limited distribution as they can circumvent normal
security restrictions.

Risk: Depending on what the privileged account is for, there’s a potential for data to be accessed
directly or for unauthorised transactions to be initiated, recorded, processed and reported

Controls: Access to and usage of privileged accounts is restricted

7. Logical Security Configuration

• Enforces security criteria for user accounts and application restrictions, commonly:
- Minimum password parameters
- Server auditing
- Domain trust relationships
- File and directory default security settings
- Firewall rules

• Connection protocols and encryption

Risk: Unauthorised access to data and applications by unauthorised internal and external sources.

Control: Clients have configuration policies in place across all their applications and operating
systems to restrict unauthorised access

8. Physical Security
• Securing building and data centre, this could be through key code, keycard or biometric control
system (or a combination)
• Important to establish where hardware running audit significant OS, applications and
databases are located.

9. Controlling Audit Trails

Access Logging
Operating systems and database management systems should be configured so that all access
to files and directories is logged. This practice promotes accountability and provides a trail of
evidence in the event that a forensic investigation should be conducted in the future.

Access logs themselves must be highly protected - ideally, they should be stored in a different
storage system than the data whose access they are logging.

31
 Access logs should not be alterable, even by database administrators and system
administrators, so that no one will be able to “erase their tracks” should they decide to
tamper with sensitive information and then attempt to hide the evidence afterward.

Access logging is only effective if someone actually examines the logs. Because this can be a
time-consuming activity, many organizations utilize alert-generating tools that send e-mail or
pager alerts to key personnel when certain audit log entries (such as unauthorized access
attempts) appear. These alerts permit personnel to act upon anomalous events when they occur.

Audit trails can record activity at the system, application and user levels. Operating system
options let management choose the level of auditing to be recorded into the log:

a) Keystroke Monitoring records both the user’s keystrokes and the system’s response.
Consider possible legal, ethical, and behavioral implications of this surveillance.

b) Event Monitoring records who logged on when, for how long, and with which files and
programs.

Audit Trail Objectives support security objectives by detecting unauthorized access, by

facilitating event reconstruction, and by promoting personal accountability. Implementing an
Audit Trail involves cost-benefit analysis in deciding several issues:

a) How much should you log? All transactions or only significant transactions?

b) How is “significant” defined (by process, by account, by nature)?

Self-Check

1. Why is IT security important?

2. What are the IT processes and activities

required to secure systems and data?

Unit Summary

• IT General Controls (ITGC) are a critical component of business operations and financial
information controls. They provide the foundation for reliance on data, reports, automated
controls, and other system functionality underlying business processes. The security, integrity,
and reliability of financial information relies on proper access controls, change management,
and operational controls.

• ITGCs affect almost all financial audits by virtue of their reach and significance. Due to their
nature, the ultimate risk of material misstatement is often affected when a potential control
deficiency around financial data or processing changes the inherent risk of multiple areas.

• As auditors, we tend to think of inherent and control risks related to expertise, outside forces,
reconciliations, board oversight and many mitigating controls. Often auditors fail to notice this
information is controlled, processed and reported through various applications and databases.
What becomes difficult is knowing what controls should apply to an audit. As a result, ITGCs
require some type of review in all financial audits. (https://www.moore-na.com/news/april-
2019/how-it-relates-to-the-audit)

32