Copyright © 2003 Information Systems Audit and Control Association. All rights reserved. www.isaca.org.

Auditing OS and Database Controls

By S. Anantha Sayana, CISA, CIA

has controls designed to enforce all the validations and busi-

T
o secure information effectively, it needs to be secured
from all perceivable threats. The standard approach to ness rules relating to who interacts with which elements of the
information security has been to build layers of securi- data and how. As long as the user stays within such an applica-
ty that aim to control specific risks related to different compo- tion, the user’s actions are well controlled. Most application
nents of a system. users log directly onto an application and, on exiting the appli-
Figure 1 is a representation of a computer system, deliber- cation, are automatically logged out of the system.
ately simplified to facilitate easier understanding of certain However, if a user is able to bypass the application and gain
concepts. access to the operating system, then all the rules and controls
The next few paragraphs may seem quite basic, but they are in the application software become irrelevant.
written with an audit and control focus, and the topic’s under- The OS views data not as basic pay, balance amount or stock
standing is important to the article. value, but as a series of bits in a file. Once a user or an intruder
Essentially the data physically reside on a hard disk, which gains access to the data through the operating system, the con-
is a part of the hardware and is closely coupled with the trols in the application software do not have any value—what
processor and memory. The operating system envelops the the intruder can do to the data is dependent on the controls in
hardware and interacts with all the input/output devices and the operating system only. Therefore, it is necessary to review
connections outside of the computer. The operating system is whether adequate controls have been enabled in the OS.
the primary link between the software and the physical data
and all attempts to read, write or manipulate the data must Auditing OS
pass through the operating system. Every operating system includes a set of security features
However, most end users of enterprise systems rarely inter- and vulnerabilities, which varies from OS to OS and some-
act with the operating system—not by choice, but by good times between versions. The security features are designed in
design. The users interact with the applications, e.g., the cus- such a way that they can be turned on or off and set to high
tomer of a bank logs in directly to a screen that prompts for security or low security, depending on the purpose for which
inputs required for withdrawal of monies or other transactions, the user intends to use the OS. In most cases, the default set-
and the store keeper logs into a menu that allows receipt of
goods or issue of stocks. Application software—such as enter-
prise resource planning, inventory management system, retail Figure 1—S-OX Resources
banking, financial accounting and invoicing—are what users
log into depending on their roles in the organization.
Application software sits on top of the operating system (with
T I ON SO
a database management system, also on top of the OS). A user A FT
does not need to know what OS is being used, and the user’s C E M G M T
only interaction is with the application software. LI AS I N G S WA
Notwithstanding all of this, the IS auditor needs to be con- P B AT SY YS R
cerned about the operating system for the following reasons.
P A R S T E
T E
The operating system sees all data on the disk as streams of
A T P E
bits in the records inside the files and folders. The operating E
system does not see the data relating to the basic pay of an A O CPU D
I M M
employee as being significantly more or less sensitive than the D RAM S
employee’s telephone number. It is the application software K
that understands the data from the business perspective; all X
business rules relating to the way the data can be manipulated WI I
N E Y
are enforced through programs in the application software. For N U
M / CL R
PA S Q R A TO
example, the application software does not allow a banking
customer to modify the balance in the account, but only dis-
YR L O
plays it and accepts a transaction. Good application software
OL L V EN
IN

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 3, 2003

tings are not designed for high security. It is up to the user to
enable the security features to the desired level of security for
that installation.
The process of auditing OS security includes evaluating
whether the security features have been enabled and parame-
ters have been set to values consistent with the security policy
of the organization, and verifying that all users of the system
(user IDs) have appropriate privileges to the various resources
and data held in the system.
The audit of OS security requires the auditor to have a good
knowledge of the various features of the operating system’s
security in detail. The better an auditor knows the system
administration details for the OS, the more effective the audit
will be. The audit of the evaluation of security parameters in
the OS involves logging into the system and seeing the values
on the system or running a few commands to find these values.
Some of the most common security parameters that can be
evaluated are password rules, such as minimum password
length, password history, password required, compulsory pass-
word aging, lock-out on unsuccessful logins, login station and
time restrictions. The other areas of scrutiny are whether the
logging of certain events, such as unsuccessful login attempts,
has been enabled or whether the superuser password is held by
the appropriate person. Other OS/version-specific parameters
also have to be verified.
Another area of scrutiny is to ascertain whether access priv-
ileges given to various users are appropriate. The first step is to
ascertain what data/systems are on the server and how critical
and sensitive they are. From this information, the auditor can
get an idea of who should have access to what. Next, the audi-
tor should obtain the list of user IDs in the system and map
these with actual users. Then, the auditor has to determine for
each user what the permissions and privileges to the different
resources/data are in the system. There are different methods,
for example, commands for ascertaining this from the system
for different OS. Another way is to determine for a given criti-
cal piece of data who the users with access are, and whether
their access is appropriate.
Besides application systems, many servers are used as file
and print servers acting as a common repository for data for
many users. In such cases, a review of the OS security to deter-
mine appropriate access for each user to his/her data is very
important.
Another point for examination pertains to the network. With
all computers intricately connected to the internal and external
networks, the network-related vulnerabilities of such systems
also need to be covered in reviews, although they are even
more specialized. Through suitable use of tools, the auditor
should determine whether the services that are open and run-
ning in the server (such as FTP, Telnet, HTTP) or ports are
only those that really are required. If the review is being done
on a system that is hosting a web server or a firewall, the
evaluation must be done by an expert.
The purpose of this article is to focus on the concepts and
need for the audit of OS and not to provide detailed guidelines
or checklists for doing the same. Such guidelines or checklists
are specific in technical detail to different OS. Many profes-
sional audit firms develop, through their own research, guide-
INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 3, 2003
lines and work procedures for such technical audits. However,
such checklists also have been published on various web sites
by other professionals, and today it is very simple to download
audit checklists for a variety of platforms using a search
engine. Some books specific to OS have been published by
ISACA; articles on the subject also are available in some back
issues of this Journal. Some checklists are available in K-NET,
ISACA’s global knowledge network, at www.isaca.org/knet.
When doing such audits for the first time, it is good to take
the system administrator into confidence and keep him/her
informed while running the commands and queries. Other tools
are available to perform such audits. These tools take as inputs
the security policy definitions, run commands to extract the
parameter values from the system, perform a comparison and
issue a draft report.
Auditing Databases
The current trends in application software design include
frequent use of a database management system that actually
handles data manipulation inside its tables, rather than it being
done by the OS itself in files. The DBMS acts as a layer
between the application software and the OS. The application
passes on the instructions for manipulating data, which are
executed by the DBMS following the integrity rules and con-
straints built into the database definitions.
However, using a utility such as a text editor in the OS, the
data in the DBMS can be manipulated directly, without the
application. This can be done by using DBMS utilities and
features, such as SQL (Structured Query Language)—if the
user can gain access to the DBMS.
Hence, it is necessary to review security in the DBMS
through a review of user IDs, the privileges associated with
each ID and factors such as whether default-shipped passwords
that are common knowledge have been modified/disabled.
The procedures and exact commands to be used for carrying
out the reviews will be specific to DBMS, and it is possible
to obtain such checklists from the web and through books
published by ISACA.
Client-server and Web-based Applications
There has been a significant change in the design of appli-
cations as well as their interaction directly with the OS since
the advent of client-server and web-based applications. In such
cases, users do not need to log in as users of the OS directly,
but only need to connect to the database as a predefined user.
While reviewing the OS in such systems, the auditor is likely
to find there are just one or two user IDs created in the OS or
in the database. While the user executes an icon in the desktop,
a string containing the database user ID and password is com-
municated to the database, and a connection is made. It is nec-
essary for the auditor to examine such scripts and evaluate
their security. The way web-based applications connect to data-
bases also is slightly different. The auditor should know that,
in such scenarios, the older methods of audit do not remain
fully effective, and therefore, he/she needs to adopt more cur-
rent and appropriate methods.
 Conclusion
Auditing OS and database security is a key element of the
total IS audit. Any deficiencies in OS and database security can
nullify all of the security and controls that have been designed
carefully in the applications. Hence, it is necessary to carry out
reviews of the OS and database for all critical applications and
the servers that hold sensitive information.
S. Anantha Sayana,
CISA, CIA
is deputy general manager, corporate IT, with Larsen & Toubro
Limited in Mumbai, India. Sayana has more than 13 years of
experience in IS audit and internal audit in the banking, manu-
facturing and services industries, spanning a wide variety of
applications and technical platforms. He is a past president of
the ISACA Mumbai Chapter. He can be contacted by e-mail at
sas-pia@powai.ltindia.com.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the Information Systems Audit and Control Association, Inc.. Membership in the association, a voluntary
organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit
and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal
does not attest to the originality of authors' content.

© Copyright 2003 by Information Systems Audit and Control Association Inc., formerly the EDP Auditors Association. All rights reserved. ISCATM Information Systems Control AssociationTM

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the
association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles
owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume,
and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the
association or the copyright owner is expressly prohibited.

www.isaca.org

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 3, 2003