Accounts created for and used by non-interactive/automated processing are subject to special consideration. These database accounts may be used for a variety of functions such as activity log storage by remote or local devices, unattended database maintenance batch jobs, etc. These accounts shall not be shared with interactive (i.e., human user) database users. The primary vulnerability associated with the use of non-interactive database accounts is a frequent requirement to store the account name and password within application code or external files and the possibility of exposure of this information during the logon process. The mechanisms for protecting the username and password vary by operating system and database system. Accounts used for automated processing should be further protected by restricting the account used to appropriate hours of access where possible. Additional policy for securing these accounts is located in specific database and OS-specific sections.

Many databases require the use of a single account to support multiple tier or "N-Tier" application connections from an application server to a backend database. Such connections rely upon the degree of security applied to the network connection and the authentication method used between the middle-tier server and the database server. Also, the ability to audit at the individual user level may be lost at the database level. It becomes the responsibility in this scenario of the application level to audit individual activities as required. The access to the N-Tier connection account shall be restricted by network configuration and authentication method to the connecting middle-tier server. Acceptance of risk for the limited auditing capability of the database in this configuration shall be documented and filed with the SecSpec.

Application user database accounts are used to provide access to application database objects to perform a particular application function. Privileges granted to application user database accounts shall follow the principle of least privilege and include only those privileges required to perform the assigned function. Privileges shall not be granted directly to application user database accounts. Privileges shall be granted to application user database accounts only through the use of database roles.

Database applications that are installed on the DBMS host system and are accessed from the DBMS host by application users may require a specific security configuration. Specific details for any OS account configuration requirements are located in the DBMS-specific sections of the Exhibits.

Database administration OS accounts required for operation and maintenance of the DBMS shall be configured in accordance with the security requirements as specified by the specific DBMS. Details for the DBA account configurations are located in the specific DBMS appendix.

Each database application user database account shall be granted object access to the appropriate database objects through application specific roles. These roles shall be based on the function being performed. Object privileges shall not be assigned directly to individual application user database accounts. Object privileges shall not be granted to PUBLIC (a DBMS defined mandatory all-user role) except those explicitly required by the DBMS vendor. Note that not every role defined by the vendor is required by IRS database applications. Whenever possible, minimize the access by limiting the role even if it is a predefined role. Access to DBA views and tables, which contain access to all data dictionary object information, shall be restricted to DBAs, SecSpecs, application administrators (if required), and batch processing accounts that have been documented within the lifecycle documentation.

Object ownership grants full privileges to owned objects. All database objects shall be owned by the database system, DBAs, or by an account created especially for application object ownership. It is recommended that for each application a custom database account is created and that this account is used to own all of the database objects accessed by the application. The application user shall not own any database objects. Only the application owner shall have the ability to grant object privileges to the application roles. At no time shall an application user log on to the database account that is the application object owner. The application object owner database account shall be used only for update and maintenance of the application objects within the database. To help protect this account, the custom application owner account shall be disabled when not in use. The default DBMS database accounts shall not be used as the owner of an application’s objects or schema.

A database role allows database privileges to be defined and assigned by application function. Individually required privileges and other database roles may be granted to a single database role thus allowing required privileges to be simultaneously granted to and revoked from database accounts. An example of such roles would be DBA roles, application administrator roles, and specific application user roles for financial applications, sales support applications, inventory applications, etc. All application user roles shall be granted the most limited set of privileges that allows the user to accomplish the specific job function required of their position. No roles shall be granted to PUBLIC. No permissions shall be granted directly to application user database accounts with the following exceptions: 1) accounts created and maintained by default during the installation and maintenance of the database system, and 2) a single application user database account on a database with only one such account.

Auditing shall be configured and implemented on all DBMS systems. Auditing shall be capable of capturing all database operations. This includes both events that occur within the database and affect modification to database parameters and resources as well as modifications to the database catalog (object creation, deletion, alteration) and events performed on or by the host system such as database shutdown and startup. Database audit data shall be maintained in accordance with IRM 10.8.1. The audit data is not required to be local to the database for the period of retention, but shall be available for historical analysis if needed. Audit data shall only be readable by personnel authorized by the SecSpec.

The following minimum set of operations shall be audited for successful and unsuccessful execution. In the event of intrusive or anomalous activity, more detailed auditing shall be performed. (Reference the DBMS specific appendixes for specific minimum database auditing requirements.) The DBA shall ensure that the following minimum audit requirements are met:

All connections performed to maintain or administer the database shall be audited. All DBA operations shall be audited. At a minimum, the DBA connection shall be audited and the following list of DBA activities shall be reported:

The SA shall protect database audit files so that they cannot be modified by the DBA.

The DBA shall ensure that all database connections used to perform the above listed DBA actions are audited.

Value-based auditing is performed on the individual data element. It provides a before and after look of changes to data values. Value-based auditing is required for any system that requires a before and after look of changes to data values. Most databases accommodate this basic requirement by default by recording transactions in log files available for restoration of data prior to an uncommitted transaction. Transaction logs shall be reviewed on a rotating basis, but at a minimum once a quarter, if there have been no reported or suspected security events on that database instance. Transaction logs shall be reviewed when security events occur for sensitive data. Users shall be notified of the last time and date of modification to sensitive data. Ensuring review of the DBMS transaction logs is the responsibility of the SecSpec.

Unauthorized users often target auditing data in order to hide evidence of unauthorized activity. The audit data shall be reviewed for the following types of operations.

This level of auditing applies to the actions of all users, including DBAs.

Audit data shall be maintained in accordance with IRM 10.8.1, IRM 10.8.3, applicable operating system specific policies (e.g., the Unix IRM), and this IRM. IRS practice has been to retain archived audit logs/trails for the remainder of the year they were made plus six years. The audit data is not required to reside within the database or reside on local disk storage, but can be available on off-line storage if needed. If an application is not capable of maintaining this amount of audit information, the deficiency shall be documented and a deviation requested.

The audit data shall be stored in a format readable by analysis programs or scripts, and comply with international standards for interchange. This shall enable the SecSpec to perform a historical analysis if intrusive or anomalous behavior is discovered.

When the audit data is archived (backed up) to a historical format, the archived audit information shall be deleted from the database or host system. The deletion of audit records may be the responsibility of the DBA and requires the generation of an audit record. (This means that after the audit data has been archived, only one record shall remain in the active audit trail. This will be the record of deletion of audit information.) This allows the SecSpec and/or the DBA to monitor the audit information and verify that the audit data has been archived.

The collection of user account actions and process activities in the audit files is only part of the process of system monitoring. Collected data shall be examined and analyzed at least weekly to detect any compromise or attempted compromise of system security in accordance with IRM 10.8.1.

The database audit data shall be reviewed at a minimum bi-weekly. This review process shall check for any intrusive activity and any anomalous activity.

At a minimum, the DBA or security administrator shall do the following:

The ability to grant access to database audit data shall be limited to the DBA and SecSpec. This access control shall be strictly enforced. Any access to database audit data beyond that held by the DBA and SecSpec shall be granted only to other personnel who are responsible for reviewing and acting upon audit reports. The SA and data owner shall be notified whenever such access is granted. The DBA and the SecSpec shall maintain a record of such access which shall include the identification of the individual granted access and the period of such access. Select, insert, delete, or update operations on audit information shall be restricted to DBAs or security auditors. Privileges to disable auditing shall be restricted to DBAs or security auditors.

In addition to reviewing audit data collections, unauthorized database activity may also be discovered by actively monitoring the status of database objects. The DBA shall review the DBMS job queues daily to ensure that no unauthorized batch jobs or database scripts are being run against the database. The DBA shall monitor the creation, reload, and compilation of database objects to ensure no unauthorized changes have been made. Where possible, DBAs shall review what applications are being used to access the database to ensure that only authorized applications are allowed access to the database and to discover unauthorized database access attempts.

DBAs shall review what applications are being used to access the database to ensure that only authorized applications are allowed access to the database and to discover unauthorized database access attempts.

The DBA shall regularly and routinely monitor database accounts for expiration and inactivity. Accounts not in use shall be removed in accordance with IRM 10.8.1.

Database parameters such as instance identifiers, network addresses, and database host names may aid unauthorized users in finding and accessing databases. This information should never be published publicly such as via mailing lists or news groups and should be protected from unauthorized access where possible. Database information for specific databases shall be restricted to authorized database users and administrators of that particular database and not disseminated to all users in the network or environment.

When a database connection is requested via the network to a database server, the client shall provide an individual account name and authentication credentials to access the database. The database account name and any password transmission from a client to a database server over a network shall be protected in accordance with IRM 10.8.1.

Remote connections to the database by administrative users to perform administrative functions including database account password resets and account management shall be encrypted. Without encryption, such activity performed during these connections could provide information useful to gain unauthorized access to the database.

ODBC, an application programming interface (API), provides another method besides native database methods to connect to a database and issue standard SQL commands. Many popular COTS applications provide connectivity to databases using ODBC drivers. These applications may be easily configured to access the database by a savvy user who can provide authentication information directly to the database. These types of connections emphasize the importance of defining database object access authorizations within the database itself and not solely within the application. ODBC tracing, a function used for debugging applications and connections, shall be disabled or tightly controlled. This will prevent sensitive data from being stored in trace files on disk during debugging activities. Where its use is not justified, the ODBC tracing executable shall be deleted from the system to ensure the function is unavailable. The removal of the executable may require periodic review as some upgrades or other application installations may re-install it. User account privileges defined at the DBMS level are the only privileges guaranteed in effect via ODBC connections. Database account passwords shall not be stored in unencrypted format within ODBC connection definitions or data set names (DSN).

Wireless encryption key sizes shall be at least 128 bits in strength as defined by NIST SP 800-57, Recommendation for Key Management.

Encryption being used shall be based on the expected security life of the data being protected. See NIST 800-57, for specific guidance on encryption algorithm selection and key length.

The databases and database information stored or transmitted through a wireless network or device must be assessed to determine the sensitivity of the information and determine the necessary security controls.

Wireless laptops shall encrypt sensitive database files and/or directories in accordance with IRM 10.8.26, Enterprise Laptop Security Strategy.

JDBC, another application programming interface (API), provides a method for connection to a database from a Java application. JDBC drivers may connect to a database by bridging to ODBC drivers or by using the database native SQL API such as Oracle’s Net (Net8) or Microsoft’s DB library. JDBC connection information, specifically database account passwords, shall not be stored in unencrypted format.

The availability requirements for the application served by the database and the sensitivity of the data being served determine the appropriate network architecture for web or middle-tier connections to DBMSs. Systems requiring greater assurance for availability should have the DBMS located on a host server separate from the serving web or middle-tier server. This helps limit any security events to the compromised system. Encryption requirements for data transmitted between these systems are dependent on the sensitivity of the data being transmitted, the sensitivity level assigned to the network being traversed, and any differences in need-to-know between the data and the users on the network. Login credentials to the DBMS and web/middle-tier servers shall always be encrypted. Connections to the database shall be protected per IRM 10.8.1.

Connection pooling is a technique for improving the response time of database applications, which is accomplished by establishing a group or "pool" of databases connections which are then shared by applications on an application server. Connection pooling between web or middle-tier servers and databases that support individual identification and authentication of database users shall be used. Individual identification and authentication shall be complied when used to enter an IRS database. Oracle databases support this by means of the Oracle Call Interface (OCI). IBM DB2 databases support connection pooling through JDBC, and Microsoft SQL Server supports connection pooling through ODBC.

Inactive database sessions are typically construed as an indication of unattended interactive account connections. While workstation and OS policy already require terminal lock requirements to protect unattended workstations from unauthorized access, an idle database session still uses database and host system resources and may lead to denial of service or session hijacking. Database session inactivity time outs shall be set to a system-wide (in this case, a database-wide) inactivity time out of 15 minutes. Databases requiring user session inactivity timeouts greater than 15 minutes shall be justified and documented in deviation requests.

A distinct database account and password for the replication administrator and replication system database accounts shall be used to secure replication procedures and facilities (e.g., disk space). Replication account passwords shall be protected when transmitted over a network. Access to replication procedures and facilities shall be restricted to authorized DBAs and designated replication accounts.

Replication data may be stored temporarily in specific OS locations for retrieval by database replication partners. This data must be securely stored and access to it restricted to the DBA and authorized replication software components. This protection is controlled by OS file and directory permissions as well as database security controls.

Databases may be configured to share data across remote database systems. Such linked databases may be part of federated or distributed database architectures. Authentication between linked databases may rely upon the credentials of the requesting database session or upon a statically defined username and password. Generally, it is best to use a current user’s network-based security credentials provided by means of a directory service to authenticate to the remote system, as this is the only way to maintain a clear auditable identity across all systems. When distributed databases are required to share or transmit data through database links via network connections, the database initiating the link shall use the credentials of the current database session to connect to the remote database.

Database link access shall be restricted to authorized users when possible. Applications shall not create or use public database links (with the exception of database links required for replication), unless justified and documented in a deviation request. It is possible to create a private database link and establish a public synonym to the database link. This protects the details about the database link, while providing the same capabilities as a public link.

To protect sensitive production database data, database links shall not be defined between production and development databases. This restriction helps to prevent sensitive data from being accessed or downloaded by developers or other unauthorized personnel on a remote database.