Database Security: Controlling Service Accounts
By: Mitchell H. Levine, CISA
Audit Serve, Inc.

The focus of the privileged account review in a Database Security Audit has been the assessment of the individual users which are assigned database privileges. Within most database technologies, full database administration rights does not provide the necessary separation of duties between database system operations, security administration and having complete update access to database tables. Therefore, database administrators have always been provided the 
“keys to kingdom”. Within some organizations, a control function was established to identify the changes made by the database administrator to ensure that all changes were authorized and proper. However, with full database administration rights granted to the DBA would allow them in most cases to alter these audit trails which are used to support these review processes.

An area not included in most audits is the control of IDs which are assigned to run system processes which are referred to as non-human IDs (also referred to as service accounts). These non-human IDs are used to run third party system software products such as scheduling 
system and performance tools or could be provided by the database vendor to run their own internal system processes. The other most common use of these non-human IDs is to allow the application to access the database. Most applications are designed in which all users are authenticated against the database using a single application ID. The alternative is a two-tier design in which each user is assigned their own database ID which is used for authentication against the database which is passed through by the application.

With the exception of the mainframe environment, these IDs require passwords. Therefore, database technologies running in a Windows or UNIX distributed environment such as Sybase SQL Server, DB2 UDB and Oracle, all require a password to be defined for each ID which includes non-human IDs. The audit concern is who has knowledge of the password. None of these database 
technologies provide controls to prevent an individual user who has knowledge of the password, from using these non-human IDs from their workstation.

The overall risk of the “Service Account ID hijacking” is based on the circumstances in which individual would acquire knowledge of the ID and password. For application IDs, which is the method to allow users controlled access to the database, the risk depends on the method used 
to handle the logon authentication to the database. In most cases, developers actually hardcode the ID and password into the application. In this case, the developers have knowledge of the service account’s ID and password and can use it themselves. Since these application IDs are used by the application to perform production processing they are defined in most cases to have update access to the database tables. Some organizations, have developed separate program modules to handle the logon authentication to the database which outside the control of the developers which partially mitigates the risk. As part of an audit, these application IDs need to be 
identified and researched to determine the logon authentication methods used. If the development group does not track this information it should be raised as an audit issue.

Another method deployed to mitigate this risk is to detect the usage of these application IDs when they are used outside the normal application processing. The normal application processing is when the application ID is initiated from an application server which is a three-tier design. Assuming, that all individuals, including the development group, are restricted from attaching to the application server, the origin of the application ID usage should only occur from the application server’s hostname or IP address. Within Oracle, listener logs can be established to monitor ID connections which also provide the hostname where the ID connection occurred from. If a connection to an application ID did not occur from the application server, then an unauthorized takeover of an application ID occurred. This control can be implemented as preventive control or a detective control. Unfortunately, this same control cannot be used with Sybase or SQL Server. Sybase audit trails do not provide IP address or hostname information of where the connection occurred from. Trace logs can be established within SQL Server to obtain the hostname
of where the connection occurred from but the integrity of this information cannot be preserved since the user prior to connecting to the database has the ability to change this hostname data that is tracked by SQL Server. Supposedly, this ability to change the hostname information has been fixed with the release of SQL Server 2005 which will be available the end of September, 2005. Within DB2 UDB, the IP address of ID connections is recorded in an audit trail. Therefore, the control described above could be implemented for DB2 UDB.

The risk of hijacking service account IDs used by internal database system processes and third party system tools is limited since these IDs are set-up by the database administrators and server administrators who have this level of access through their normal IDs. Overall, regardless of whether individual users have gained knowledge of these service accounts IDs and passwords, there is risk of the unauthorized takeover of these IDs because logon security settings are not set the same for these ID as the case with individual user ids. In order not to have a disruption based on an ID being suspended, most organization set-up these service account IDs not to suspend regardless of the number of invalid logon attempts. Within SQL Server environments, the capability does not even exist to lock an ID after a specified number of access attempts. Therefore, password cracker programs can be used to disclose these IDs. A critical control which needs to be 
established with all organization is to monitor for successive logon attempts to all service accounts.

--------------------------------------------------------------------------------

For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.

Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.