Chapter 6 (1) Auditing Operating Systems and Networks
Chapter 6 (1) Auditing Operating Systems and Networks
Auditing Operating
Systems and
Networks
1
Auditing Operating
Systems
3
Overview
The operating system is the computer’s control
program. It allows users and their applications to
share and access common computer resources,
such as processors, main memory, databases, and
printers. If operating system integrity is
compromised, controls within individual accounting
applications may also be circumvented or
neutralized. Because the operating system is
common to all users, the larger the computer
facility, the greater the scale of potential damage.
Thus, with an ever-expanding user community
sharing more and more computer resources,
operating system security becomes an important
internal control issue.
4
Operating System
Objectives
OS Tasks are as follows:
◦ Translate high-level language A high-level
language cannot be understood directly by a
computer, and it needs to be translated into
machine code.
◦ Allocate computer resources
◦ Manage tasks
5
Operating System
Objectives
Translate high-level language
◦ First, it translates high-level languages, such as
COBOL, C++, BASIC, and SQL, into the machine-
level language that the computer can execute.
The language translator modules of the operating
system are called compilers and interpreters.
6
Operating System
Objectives
Allocate computer resources
◦ Second, the operating system allocates computer
resources to users, workgroups, and applications.
This includes assigning memory work space
(partitions) to applications and authorizing access
to terminals, telecommunications links,
databases, and printers.
7
Operating System
Objectives
Manage tasks
8
Operating System
Objectives
Fundamental Control Objectives
9
Operating System
Security
10
Overview
Operating system security involves
policies, procedures, and controls that
determine who can access the operating
system, which resources (files, programs,
printers) they can use, and what actions
they can take. The following security
components are found in secure operating
systems: log-on procedure, access token,
access control list, and discretionary access
privileges.
11
Log-on Procedure
A formal log-on procedure is the
operating system’s first line of defense
against unauthorized access. When the user
initiates the process, he or she is presented
with a dialog box requesting the user’s ID
and password. The system compares the ID
and password to a database of valid users.
12
Access Token
If the log-on attempt is successful, the
operating system creates an access token
that contains key information about the
user, including user ID, password, user
group, and privileges granted to the user.
The information in the access token is used
to approve all actions the user attempts
during the session.
13
Access Control List
An access control list is assigned to each
IT resource (computer directory, data file,
program, or printer), which controls access to
the resources. These lists contain information
that defines the access privileges for all valid
users of the resource. When a user attempts
to access a resource, the system compares
his or her ID and privileges contained in the
access token with those contained in the
access control list. If there is a match, the
user is granted access.
14
Discretionary Access
Privileges
The central system administrator usually
determines who is granted access to
specific resources and maintains the access
control list. In distributed systems, however,
end users may control (own) resources.
Resource owners in this setting may be
granted discretionary access privileges,
which allow them to grant access privileges
to other users.
15
Threats to Operating
System Integrity
16
Overview
Operating system control objectives may
not be achieved because of flaws in the
operating system that are exploited either
accidentally or intentionally. Accidental
threats include hardware failures that cause
the operating system to crash. Errors in
user application programs, which the
operating system cannot interpret, also
cause operating system failures.
17
Overview
Accidental system failures may cause whole
segments of memory to be dumped to disks
and printers, resulting in the unintentional
disclosure of confidential information.
Intentional threats to the operating system
are most commonly attempts to illegally
access data or violate user privacy for
financial gain. However, a growing threat is
destructive programs from which there is no
apparent gain.
18
Sources of Exposures
1. Privileged personnel who abuse their
authority. Systems administrators and
systems programmers require unlimited
access to the operating system to perform
maintenance and to recover from system
failures. Such individuals may use this
authority to access users’ programs and data
files.
19
Sources of Exposures
2. Individuals, both internal and external to
the organization, who browse the operating
system to identify and exploit security flaws.
20
Sources of Exposures
3. Individuals who intentionally (or
accidentally) insert computer viruses or other
forms of destructive programs into the
operating system.
21
Operating System
Controls and Audit
Tests
22
Overview
If operating system integrity is compromised,
controls within individual accounting
applications that impact financial reporting
may also be compromised. For this reason,
the design and assessment of operating
system security controls are SOX compliance
issues.
23
Controlling Access
Privileges
The way access privileges are assigned
influences system security. Privileges
should, therefore, be carefully administered
and closely monitored for compliance with
organizational policy and principles of
internal control.
24
Audit Objectives Relating to
Access Privileges
The auditor’s objective is to verify that
access privileges are granted in a manner
that is consistent with the need to separate
incompatible functions and is in accordance
with the organization’s policy.
25
Audit Procedures Relating to
Access Privileges
To achieve their objectives auditors may perform the following tests
of controls:
• Review the organization’s policies for separating incompatible
functions and ensure that they promote reasonable security.
• Review the privileges of a selection of user groups and individuals
to determine if their access rights are appropriate for their job
descriptions and positions. The auditor should verify that individuals
are granted access to data and programs based on their need to
know.
• Review personnel records to determine whether privileged
employees undergo an adequately intensive security clearance
check in compliance with company policy.
• Review employee records to determine whether users have
formally acknowledged their responsibility to maintain the
confidentiality of company data.
• Review the users’ permitted log-on times. Permission should be
commensurate with the tasks being performed. 26
Password Control
A password is a secret code the user enters
to gain access to systems, applications, data
files, or a network server. If the user cannot
provide the correct password, the operating
system should deny access. Although
passwords can provide a degree of security,
when imposed on non-security-minded users,
password procedures can result in end-user
behavior that actually circumvents security.
27
Password Control
The most common forms of contra-security
behavior include:
• Forgetting passwords and being locked out of
the system.
• Failing to change passwords on a frequent
basis.
• The Post-it syndrome, whereby passwords are
written down and displayed for others to see.
• Simplistic passwords that a computer criminal
easily anticipates.
28
Password Control
The most common method of password
control is the reusable password. The
user defines the password to the system
once and then reuses it to gain future
access. The quality of the security that a
reusable password provides depends on the
quality of the password itself. If the
password pertains to something personal
about the user, such as a child’s name,
pet’s name, birth date, or hair color, a
computer criminal can often deduce it.
29
Password Control
To improve access control, management
should require that passwords be changed
regularly and disallow weak passwords.
Software is available that automatically
scans password files and notifies users that
their passwords have expired and need to
be changed.
30
Password Controls
The one-time password was designed to
overcome the aforementioned problems.
Under this approach, the user’s password
changes continuously. This technology
employs a credit card–sized smart card that
contains a microprocessor programmed
with an algorithm that generates, and
electronically displays, a new and unique
password every 60 seconds. Another
example (capcha)
31
Audit Objectives Relating to
Passwords
The auditor’s objective here is to ensure
that the organization has an adequate and
effective password policy for controlling
access to the operating system.
32
Audit Procedures Relating to
Passwords
The auditor may achieve this objective by performing the
following tests:
• Verify that all users are required to have passwords.
• Verify that new users are instructed in the use of
passwords and the importance of password control.
• Review password control procedures to ensure that
passwords are changed regularly.
• Review the password file to determine that weak
passwords are identified and disallowed. This may involve
using software to scan password files for known weak
passwords.
• Verify that the password file is encrypted and that the
encryption key is properly secured.
33
Audit Procedures Relating to
Passwords
Assess the adequacy of password standards
such as length and expiration interval.
• Review the account lockout policy and
procedures. Most operating systems allow the
system administrator to define the action to be
taken after a certain number of failed log-on
attempts. The auditor should determine how many
failed log-on attempts are allowed before the
account is locked. The duration of the lockout also
needs to be determined. This could range from a
few minutes to a permanent lockout that requires
formal reactivation of the account.
34
Controlling Against Malicious
and Destructive Programs
Threats from destructive programs can be substantially
reduced through a combination of technology controls and
administrative procedures. The following examples are
relevant to most operating systems.
• Purchase software only from reputable vendors and
accept only those products that are in their original,
factory-sealed packages.
• Issue an entity-wide policy pertaining to the use of
unauthorized software or illegal (bootleg) copies of
copyrighted software.
• Examine all upgrades to vendor software for viruses
before they are implemented.
• Inspect all public-domain software for virus infection
before using.
35
Controlling Against Malicious
and Destructive Programs
Establish entity-wide procedures for making
changes to production programs.
• Establish an educational program to raise user
awareness regarding threats from viruses and
malicious programs.
• Install all new applications on a stand-alone
computer and thoroughly test them with antiviral
software prior to implementing them on the
mainframe or local area network (LAN) server.
• Routinely make backup copies of key files
stored on mainframes, servers, and workstations.
36
Controlling Against Malicious
and Destructive Programs
Wherever possible, limit users to read and
execute rights only. This allows users to extract
data and run authorized applications, but denies
them the ability to write directly to mainframe
and server directories.
Require protocols that explicitly invoke the
operating system’s log-on procedures to bypass
Trojan horses.
Use antiviral software (also called vaccines) to
examine application and operating system
programs for the presence of a virus and remove
it from the affected program.
37
Audit Objective Relating to Viruses
and Other Destructive Programs
The key to computer virus control is prevention
through strict adherence to organizational
policies and procedures that guard against
virus infection. The auditor’s objective is to
verify that effective management policies and
procedures are in place to prevent the
introduction and spread of destructive
programs, including viruses, worms,
backdoors*, logic bombs, and Trojan horses.
39
System Audit Trail Controls
System audit trails are logs that record
activity at the system, application, and user
level. Operating systems allow management to
select the level of auditing to be recorded in the
log. Management needs to decide where to set
the threshold between information and
irrelevant facts. An effective audit policy will
capture all significant events without cluttering
the log with trivial activity. Audit trails typically
consist of two types of audit logs: (1) detailed
logs of individual keystrokes and (2) event-
oriented logs.
40
System Audit Trail Controls
Keystroke monitoring involves recording
both the user’s keystrokes and the system’s
responses. This form of log may be used
after the fact to reconstruct the details of an
event or as a real-time control to prevent
unauthorized intrusion.
41
System Audit Trail Controls
Event monitoring summarizes key
activities related to system resources. Event
logs typically record the IDs of all users
accessing the system; the time and
duration of a user’s session; programs that
were executed during a session; and the
files, databases, printers, and other
resources accessed.
42
Setting Audit Trail
Objectives
Audit trails can be used to support security
objectives in three ways: (1) detecting
unauthorized access to the system, (2)
facilitating the reconstruction of events, and
(3) promoting personal accountability.
43