Auditing OS and Database Controls 

 
Download Article

To secure information effectively, it needs to be secured from all perceivable threats. The standard approach to information security has been to build layers of security that aim to control specific risks related to different components of a system.

Figure 1 is a representation of a computer system, deliberately simplified to facilitate easier understanding of certain concepts.

Figure 1

The next few paragraphs may seem quite basic, but they are written with an audit and control focus, and the topic's understanding is important to the article.

Essentially the data physically reside on a hard disk, which is a part of the hardware and is closely coupled with the processor and memory. The operating system envelops the hardware and interacts with all the input/output devices and connections outside of the computer. The operating system is the primary link between the software and the physical data and all attempts to read, write or manipulate the data must pass through the operating system.

However, most end users of enterprise systems rarely interact with the operating system—not by choice, but by good design. The users interact with the applications, e.g., the customer of a bank logs in directly to a screen that prompts for inputs required for withdrawal of monies or other transactions, and the store keeper logs into a menu that allows receipt of goods or issue of stocks. Application software—such as enterprise resource planning, inventory management system, retail 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 a database management system, also on top of the OS). A user does not need to know what OS is being used, and the user's only interaction is with the application software.

Notwithstanding all of this, the IS auditor needs to be concerned about the operating system for the following reasons. The operating system sees all data on the disk as streams of bits in the records inside the files and folders. The operating system does not see the data relating to the basic pay of an employee as being significantly more or less sensitive than the employee's telephone number. It is the application software that understands the data from the business perspective; all business rules relating to the way the data can be manipulated are enforced through programs in the application software. For example, the application software does not allow a banking customer to modify the balance in the account, but only displays it and accepts a transaction. Good application software has controls designed to enforce all the validations and business rules relating to who interacts with which elements of the data and how. As long as the user stays within such an application, the user's actions are well controlled. Most application users log directly onto an application and, on exiting the application, are automatically logged out of the system.

However, if a user is able to bypass the application and gain access to the operating system, then all the rules and controls in the application software become irrelevant.

The OS views data not as basic pay, balance amount or stock value, but as a series of bits in a file. Once a user or an intruder gains access to the data through the operating system, the controls in the application software do not have any value—what the intruder can do to the data is dependent on the controls in the operating system only. Therefore, it is necessary to review whether adequate controls have been enabled in the OS.

Auditing OS

Every operating system includes a set of security features and vulnerabilities, which varies from OS to OS and sometimes between versions. The security features are designed in such a way that they can be turned on or off and set to high security or low security, depending on the purpose for which the user intends to use the OS. In most cases, the default settings 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 parameters 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 password 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 privileges 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 auditor 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 critical 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 determine 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 running 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 professional audit firms develop, through their own research, guidelines 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 constraints 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 applications 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 communicated to the database, and a connection is made. It is necessary for the auditor to examine such scripts and evaluate their security. The way web-based applications connect to databases 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 current 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.