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

 Conclusion S. Anantha Sayana,
Auditing OS and database security is a key element of the CISA, CIA
total IS audit. Any deficiencies in OS and database security can is deputy general manager, corporate IT, with Larsen & Toubro
nullify all of the security and controls that have been designed Limited in Mumbai, India. Sayana has more than 13 years of
carefully in the applications. Hence, it is necessary to carry out experience in IS audit and internal audit in the banking, manu-
reviews of the OS and database for all critical applications and facturing and services industries, spanning a wide variety of
the servers that hold sensitive information. applications and technical platforms. He is a past president of
the ISACA Mumbai Chapter. He can be contacted by e-mail at
[email protected].

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