Data warehouses leverage underlying database technologies and therefore shall comply with the guidance of this IRM and other applicable IRMs for the specific database technology used. Security requirements and controls will be more important in a data warehouse environment because, by definition, a data warehouse contains data consolidated from multiple sources, and thus from the perspective of a malicious individual trying to steal information a data warehouse can be one of the most lucrative targets in the enterprise.

Deviations from this policy shall be submitted in accordance with IRM 10.8.1 and use Form 13125, as described in the deviation Standard Operating Procedures (SOPs) provided on the MITS Cybersecurity web site.

Refer to IRM 10.8.1 and the MITS Cybersecurity website for additional information.

Oracle 9i, Installation Guide, Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP9000 Series HP-UX, Linux Intel, and Sun Solaris, May 2002, Part No. A96167-01.

Oracle 9i, Database Installation Guide Release 2 (9.2.0.1.0) for Windows, May 2002, Part No. A95493-01.

Oracle 9i Enterprise Edition, Installation Guide, Release 1 (9.0.1) for OS/390, May 2001, Part No. A89900-01.

Oracle 9i Net Services, Reference Guide, Release 2 (9.2), October 2002, Part No. A96581-02.

Oracle 9i, Database Administrator’s Guide Release 1 (9.0.1) for Windows, June 2001, Part No. A90164-01.

Oracle 9i, Administrator’s Reference, Release 2 (9.2.0.1.0) for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris, May 2002, A97297-01.

Oracle 9i Enterprise Edition, System Administration Guide Release 2 (9.2.0.1.0) for OS/390, May 2002, Part No. A97313-01.

Oracle 9i, Security Overview, Release 1 (9.0.1), June 2001, Part No. A90148-01.

Hack Proofing Oracle, Howard Smith, Oracle Corporation UK Limited, Paper presented at the Oracle Open World Conference, San Francisco, CA, October 2000.

A Security Checklist for Oracle 9i, An Oracle White Paper, March 2001, Author: Rajiv Sinha.

IBM DB2 Universal Database, Administration Guide: Implementation, Version 8

IBM DB2 Universal Database, Installation and Configuration Supplement, Version 8.

IBM DB2 Universal Database, Federated Systems Guide, Version 8.

IBM DB2 Connect, Connect User’s Guide, Version 8.

The Center for Internet Security, Level Two Benchmark (Draft) SQL Server 2000, V0.6.

The Center for Internet Security, Oracle Security Benchmark, V1.1, May 2004.

SANS "Securing Oracle Step-by-Step" , January 2003.

The information contained in this appendix is specific to Oracle Versions 8.1.x (8i), 9.2 (9i) and 10.1.0 (10g). When version-specific information is presented, it shall be labeled with the version to which it specifically applies.

Any Oracle products installed shall be authorized by the Distributed Systems Software Branch (DSSB), which manages the IRS Enterprise-wide license. Oracle support is provided through this branch.

A default installation of Oracle includes the installation of several Oracle components. All of these components may not be required by your system. Review installed components and remove any components you do not need. For example, if you are not using JAVA, XML, InterMedia, Replication, etc., components, then remove them by using the Oracle installer. The Oracle components in the list below are required for standard Oracle database operation. Components other than those in the table below shall be removed unless specifically required to support the operation of any database applications. Oracle components listed below that are not required to support the operations of the specific Oracle instance shall be removed.

Assistant Common Files

Generic Connectivity Common Files

Generic Connectivity Using Open Database Connectivity (ODBC)

Oracle Net

Oracle Net Listener

Oracle Net Manager

Oracle Net Required Support Files

Oracle Core Required Support Files

Oracle Call Interface

Oracle9i/8i/10g

Oracle9i/8i/10g Database

Oracle9i/8i/10g Development Kit

Parser Generator Required Support Files

Programming Language / Structured Query Language (PL/SQL)

PL/SQL Embedded Gateway

PL/SQL Required Support Files

Platform Required Support Files

RDBMS Required Support Files

Required Support Files

Access controls of database objects are an integrated feature of the Oracle DBMS. Oracle defines two types of database accounts: administrative and non-administrative. Administrative database accounts are granted full privileges to manage the database structure, database objects, and other database accounts.

Privileges are divided into two types—system privileges and object privileges. System privileges permit the database account to exercise administrative functions. Object privileges permit the database account to read, modify, and delete data within already existing objects or execute application program objects. Access to data objects may be further controlled by use of database views. Views define a subset of stored data that may be accessed by database accounts. Database accounts may also be further restricted to updates and inserts on specific columns instead of entire rows. Also, using Oracle’s fine-grained access control, access policies may be defined and associated with tables and views that allow retrieval of subsets of rows. This eliminates the requirement to grant database accounts access to all rows in a table or view and is enforced at the database level as opposed to being controlled through the application. Oracle also provides the ability to define an application context. The application context activates access controls for only the specified application. The combination of fine-grained access and application context constitutes Oracle’s Virtual Private Database (VPD).

Database account access to resources is controlled through use of Oracle profiles. Profiles define database account resource quotas and password management guidelines.

Oracle supports the following authentication options:

Database authentication by the Oracle database requires use of a password. Oracle stores account passwords in encrypted format within the database. Oracle supports individual database accounts for each user. The table that stores database passwords is restricted from direct access by non-DBA database user accounts. The logon process to Oracle database accounts is encrypted by default.

Operating system authentication shall NOT be enabled via the network. When operating system authentication is specified, users shall be required to authenticate to the database host system prior to connecting to the database.

Windows authentication allows Windows domain accounts to access the database as locally authenticated users. However, in order to increase security, Oracle shall be configured to require use of the domain name to prevent users with the same account name in different domains to access the database as a shared account.

Users authenticated externally by Windows shall be identified with the domain name prefix.

The DBA shall configure the Oracle database to require the Windows domain prefix for database accounts authenticated externally by Windows.

The DBA shall set the registry value OSAUTH_PREFIX_DOMAIN in HKEY_LOCAL_MACHINE\/SOFTWARE\/ORACLE\/HOMEID to TRUE on Windows DBMS hosts for database versions prior to 8.1.x using Windows authentication.

The Oracle Advanced Security option enables secure authentication by external third-party network services such as Kerberos, token cards, smartcards, and biometric devices. Many network authentication services also offer integration with directory services. The DBA and SecSpec shall only permit the use of Network Service Authentication where strong identification and authentication is in place and individual user identities are maintained in the database audit process for such users.

Oracle defines global authentication as authentication via SSL and an external, centralized directory service. Database accounts are then defined as global users. These network authentication services provide a single sign-on capability that can authorize single user access to multiple systems and databases. Users authenticate themselves once to a central service, and may then connect to multiple applications or databases without providing additional credentials. The DBA and SecSpec shall only permit the use of Net Global Authentication where strong identification and authentication is in place and individual user identities are maintained in the database audit process for such users.

Users accessing a database through a middle-tier or web application server can authenticate in one of the following ways:

Although commonly in use, the first configuration listed above using a single logon for all users is the least secure because it does not allow for individual accountability within the database. To allow a middle-tier server to authenticate a user and preserve that user’s individual identity and authorizations within the database, Oracle provides the OCI.

Where connection pooling is desired to an Oracle database, the DBA shall only implement Oracle’s connection pooling. Connection pooling allows multiple users access to a database system across a shared connection. The use of a shared connection reduces the traditional amount of database server resources required to establish multiple individual connections. Oracle’s connection pooling facility is additionally able to preserve individual user accountability across the pooled connection.

Third-party connection pooling mechanisms shall not be implemented . Third-party connection pooling mechanisms require use of a single, specific database account connection. Use of a single account precludes any ability for the database to manage authorizations or provide individual accountability for actions taken within the database. Where connection pooling is required, Oracle’s connection pooling facility should be considered for use.

The DBA shall deny use of fixed user database links.

The DBA shall restrict access to the SYS.LINK$ table to authorized DBAs only.

Password file authentication shall not allow remote users access to the database as an administrative user. Password file authentication allows remote users to access the database as an administrative user. Prior to version 9i, Oracle allowed access to the SYS database account using the "connect internal" authentication. This access was granted to authenticated host accounts that were members of the host-specific operating system group (SYSDBA or ORADBA). Use of this account does not allow for individual accountability. Furthermore, actions performed as database account SYS or when administrators connect "AS SYSDBA" or "AS SYSOPER" are not audited by Oracle's auditing facility in Oracle versions earlier than 9.2.

Oracle administrative connections (SYS, "connect internal," as SYSDBAISYSOPER) shall only be used to perform administrative functions available exclusively to an administrative connection. The Oracle administrative connection shall not be used to perform everyday operations.

The use of administrative connections shall not be allowed for automated procedures or utilities that perform automated functions for the DBA. The ability to authenticate to the database with an administrative connection shall be restricted to authorized DBAs. Examples of appropriate operations requiring use of an administrative connection include installation, database creation, backup and recovery, database startup, and database shutdown.

A password file shall not be used unless remote database administration is required. In such cases, its use shall be authorized and documented by the SecSpec. If remote administration is required, the password file shall be used in exclusive mode. Exclusive mode requires individual account authentication and restricts assignment of database administrative privileges to accounts granted the SYSDBA privilege. Where remote administration is required, a password file shall be used in exclusive mode. The DBA shall ensure that Oracle administrative connections are used solely to perform administrative functions available only through an administrative connection. The DBA shall ensure that the ability to authenticate to the database with an administrative connection is restricted to authorized DBAs.

The SA shall ensure that only authorized DBAs are granted membership to the Oracle administrative OS group.

The SA shall ensure that only authorized DBAs are granted membership to the Oracle administrative OS group.

Access to the default Oracle accounts and their associated passwords shall be restricted to authorized DBAs only. Default accounts, particularly the SYS and SYSTEM accounts, shall be used only for database update and maintenance. Default accounts shall not be used for daily operations except for automated procedures that require use of the SYS or SYSTEM schema. Such automated procedures shall be documented with the SecSpec. Default accounts created for demonstration applications shall be removed.

The SYS account is the owner of all Oracle data dictionary objects. Oracle default accounts shall not be used as the owner of any non-default application schema. Administration personnel shall not use Oracle default accounts for daily operations. No individual accountability is provided when multiple users use shared accounts. Individual accounts with administrator privileges shall be maintained for each DBA for performing administrative functions on the database.

Each DBA shall log on using their individual account to perform everyday administrative functions on the database, thus providing an audit record of all activity. Oracle default accounts shall be locked and expired when not required for daily operation of the database.

Default accounts created for demonstration applications shall be removed.

The DBA shall:

ensure that access to the default Oracle accounts and their associated passwords is restricted to authorized DBAs.

ensure that default accounts are used only for database installation, update, and maintenance.

ensure that the default accounts are not used as the owner of any application schema outside their default function.

not use the Oracle default accounts for standard DBA operations.

ensure that an individual account with administrator privileges is maintained for each DBA performing everyday administrative functions on the database.

lock and expire Oracle default accounts when they are not required for regular operation of the database.

remove default database accounts and objects created for demonstration applications.

The default passwords for accounts created during Oracle database creation shall be changed after installation. A list of known default accounts is listed in B.3.7.4. A more complete list may be found in Exhibit F, Oracle Database IRM Compliance Configuration. A database may be created multiple times for the purposes of complete database reorganization. Default account passwords shall be changed each time a database is created.

Following is a list of Oracle accounts reported by Oracle to not allow password modification if product operation is to be maintained:

Please see Oracle Metalink Note 234712.1 for detailed information. Use of default passwords for these accounts does not require a deviation until Oracle updates the software to allow for modification of the passwords. Once Oracle allows the passwords to change for the accounts, then the passwords shall be altered.

ORACLE DEFAULT ACCOUNTS

The DBA shall change all default Oracle account passwords immediately after installation where changing the password will not disable database operations.

Oracle Version 8 and later provides password management capability. The default password management settings in Oracle do not meet IRS requirements; therefore password settings must be manually configured to meet IRS policy and the password specifications. See See IRM 10.8.4.5.1.2(1).Password Guidelines section of this IRM for further detail. The password management settings shall be applied to all database account profiles defined in the database.

The DBA shall use the most secure method to assign privileges by assigning a single object owner for all objects accessed by a single application as the default method. All procedures and functions supporting the application shall have the same owner and use definer's rights. This negates the requirement to assign a long and potentially complicated list of privilege assignments to the objects. If database objects referenced in a procedure or function have multiple owners, then the owner of the procedure must have all object privileges assigned directly to them. Frequently, these privileges require the WITH GRANT OPTION in addition to the simple access assignment such as in the case where a view references tables owned by multiple users. The alternative to procedures compiled using definer's rights is to specify use of invoker's rights. Invoker's rights use the rights assigned to the account executing the procedure or function. Both direct and indirect privileges are recognized. However, invoker's rights may become complicated when calls are made from one owner's procedure to procedures or functions owned by other accounts.

The application designer will coordinate with the DBA during the design phase of any database application to ensure proper privileges are allotted to the application before implementation. The privileges required for application users to successfully execute an application must be designed at application development time. If privilege assignment is not taken into account during the design phase, there may be no solution to privilege assignments at variance with the requirements of this IRM. These cannot be rectified at the database assignment level without disabling the application.

A role groups several privileges together so that they can be granted and revoked simultaneously from database accounts. Oracle creates by default several predefined roles. These roles are created and maintained by Oracle and should not be used to assign privileges to custom database accounts with the exception of the DBA role. Oracle may at their discretion assign privileges to default roles that are not required by custom roles. It is the responsibility of the DBA to ensure that no unnecessary privileges are granted to custom database accounts. Therefore, assignment of Oracle predefined roles shall be restricted to Oracle default accounts with the exception of the DBA role.

Following is a list of Oracle predefined roles:

Oracle system privileges are used to grant elevated privileges within the database. The system privileges in question are listed in Section B.13.6.3, and relate to the creation and modification of DBMS system-wide resources such as procedures, libraries, roles, and tablespaces. The DBA shall ensure that these privileges are only granted to database administrators unless a deviation is requested and approved. Application administrators and non-interactive application processing accounts may be granted the minimum privileges to create and maintain application user database accounts and resources (such as indexes) essential to the proper functioning of an application. Oracle system privileges shall not be granted to PUBLIC under any circumstances. Refer to IRM 10.8.1 for production environment requirements.

The alter, index, and references object privileges are the only object privileges that grant permissions to make system-wide modifications to database objects. The alter, index, and references object privileges shall not be granted to any application user account, application administrator account or application role. No application object privileges shall be granted to PUBLIC. Oracle recommends that unnecessary default privileges assigned to PUBLIC be revoked. All object privileges shall be revoked from PUBLIC and granted as necessary to custom application roles.

The DBA shall restrict assignment of the alter, index, and references object privileges to DBAs, object owners, and predefined roles.

The DBA shall ensure that alter, index, and reference privileges are not granted to application developer accounts in a production database.

The DBA shall ensure that application object privileges are not granted to PUBLIC.

The DBA shall revoke the following object privileges assigned to PUBLIC:

Application user database accounts, application administrator accounts, application developer accounts, or application roles shall not have the administration option of any system privilege.

Application user database accounts, application administrator accounts, application developer accounts, or application roles shall not have the grant option of any object privilege.

Application user database accounts, application administrator accounts, application developer accounts, or application roles shall not have the administration option of any Oracle predefined role.

The administration option of any role shall be granted only to DBAs and application administrator accounts.

Oracle replication configuration requires that a specific database account (usually named REPADMIN) be created and granted specific system privileges. This account is used to manage and administrate the replication functions. Other roles of the replication account include Propagator and Receiver. The DBA shall ensure that only a single replication administration account shall be used to perform all roles. The REPADMIN account may be directly granted the system privileges listed below on the master site database. A replication administration account must be created for each database involved in replication. The privileges required by the REPADMIN to configure and administrator the entire replication environment are automatically assigned via the DBMS_REPCAT_ADMIN.GRANT_ADMIN_ANY_SCHEMA.

Access to the REPADMIN account shall be restricted to authorized DBAs. The REPADMIN account shall not be granted system privileges other than the following:

The DBA shall restrict access to the REPADMIN to authorized DBAs.

The DBA shall configure a single replication administration account to be used to perform all replication functions.

Oracle password information in a connection request shall be encrypted. This is automatically handled when transmitting over a network by Oracle version 9.02 and later. In versions earlier than 9.02 were set to FALSE resulting in failed logon attempts being retried and passwords being sent in the clear. In versions earlier than 9.02, the DBA shall set the following parameters on each client and database server:

The DBA shall ensure that integrity and confidentiality protections of network communication are employed. As mentioned elsewhere in this document, administrative connections that may contain confidential information such as account password changes and shall be protected by encryption.

Financial data such as credit card information, personnel data such as social security number and birth date, or other sensitive information requires increased protection when being transmitted across the network. Whenever such data is transmitted, it shall be encrypted in accordance with IRM 10.8.1.

The sensitivity of the data should be reviewed and network communication protection configured in accordance with IRM 10.8.1.

If the network is not protected commensurate with data sensitivity requirements, the DBA shall work with the SA and they shall work with Enterprise Networks to implement an appropriate encryption solution.

The default configuration of Oracle listener software is a major source of vulnerabilities on current and previous versions of the Oracle DBMS. The following configuration changes shall be applied to IRS Oracle installations and are detailed in the following sections:

The DBA shall control the two settings for administrative access to the listener -the Security setting (the PASSWORDSJistener_name parameter in the listener.ora file), which indicates a password must be provided in order to perform administrative functions shall be set to ON; and the ADMIN_RESTRICTIOND_listener_name listener.ora parameter that enables/disables the ability to modify the listener.ora file from the LSNRCTL utility while the listener is running shall be disabled and enabled by the SA only as required.

No password is set on the listener by default. A listener password shall be set. Failing to set a password on the listener could result in unauthorized users starting, stopping, and configuring the listener service. The password shall be stored in encrypted format within the listener.ora file. This is accomplished by using the change_password function of the LSNRCTL utility.

The Oracle listener by default allows dynamic configuration via the LSNRCTL utility. Dynamic configuration leaves the listener vulnerable to unauthorized modification should the listener not be protected by a password or should the password be compromised. Dynamic configuration shall be disabled by specifying the parameter ADMIN_RESTRICTIONS = ON in the listener.ora file for all listeners. This shall require that any configuration changes be made to the listener through direct edits to the listener.ora file.

Oracle provides access to executables run by the host OS by means of the Oracle EXTPROC component. The EXTPROC component has a known vulnerability that allows unauthenticated access via the Oracle Listener. If not required, the EXTPROC component shall be disabled. This may be done through removal of the executable from the host system or by configuration of the listener. If required, a separate, dedicated listener shall be created for exclusive use of the EXTPROC and network address restrictions to it shall be strictly enforced. Use of the EXTPROC component shall be justified in lifecycle documentation.

In a Windows and UNIX environment, access to the database from the network can be restricted based on TCP/IP network address. This restriction is defined in the SQLNET.ORA (PROTOCOL.ORA file for Oracle 8i) file. The parameter tcp.validnode checking=YES enables address restrictions. The parameter tcp.invited_nodes defines TCP/IP addresses that are allowed to connect and tcp.excluded_nodes defines TCP/IP addresses that are refused connections to the database. TCP/IP address restrictions shall be defined on systems unless such restrictions are not feasible.

Network connections made to databases using privileged database accounts including DBAs and other accounts with system privileges shall be encrypted using DBMS-provided functionality. The remote privileged users should configure a separate, dedicated Oracle listener to restrict and provide remote access to administrators. Refer to the NSA Guide to the Secure Configuration and Administration of Oracle 9i Database Server for more information on configuring encrypted network access to the database. An alternative for UNIX systems is to access the database server via SSH and access the database via a local session on the host.

IRS requires standard port usage to better support firewall and intrusion detection monitoring. Therefore, Oracle default ports shall be used to support Oracle network communications when traversing network firewalls.

By default, Oracle random ports may be assigned to individual network connections when shared server or multi-threaded server is used on UNIX platforms for Oracle versions earlier than 9i. Oracle always assigns random ports unless specifically disabled on both 8i and 9i versions of Oracle for Windows. Random port assignment shall be disabled. This may be accomplished in the UNIX environment by either specifying DISPATCHERS=’’ in the init.ora file or by listing specific ports in the DISPATCHERS parameter in the init.ora file. In the Windows environment, random port assignment is disabled by adding the value HTLM\/Software\/Oracle\/Home<ID#>\/use_shared_socket=TRUE where ID# is the ID number assigned to a specific Oracle Home on the Oracle host system.

The listener.ora parameter INBOUND_CONNECTION_TIMEOUT_listener in Oracle version 9i and later and CONNECT_TIMEOUT_listener in Oracle 8i and earlier, control the amount of time the listener waits for a network client to complete the connection request. This limit prevents the listener from consuming and holding resources for client connection requests that do not complete. A malicious user could use this to flood the listener with requests that result in a denial of service to authorized users. The DBA shall ensure a connection timeout limit with the minimum appropriate for the application shall be specified in the listener.ora and the database server stentorian I only) files. The expertism stentorian parameter probes for dead connections and terminates them when found. This setting does cause a slight increase in network traffic. The stentorian expertism shall be set to greater than 0.

On Unix hosts, the OS account that runs listener processes shall be changed from its default account owner (the Oracle software installation OS account) to a different OS account. Additional guidance on this topic is provided in Section B.16.1.2.1.

The Oracle XML DB Protocol Server offers access to the Oracle XML DB resources using the standard Internet protocols FTP, HTTP, and WebDAV. This allows direct access to Oracle XML resources without the need for special or additional software. The Oracle XML DB Protocol Server is a specific type of Oracle shared server dispatcher and is specified in the Oracle database initialization parameter file for startup. Other Oracle XML DB Protocol Server configuration parameters are specified in the XML schema based XML resource named xdbconfig.xml. If access to the XML DB Protocol Server via the Internet protocols is not required, then they shall be disabled. If access via the Internet protocols is required, logging shall be enabled by setting the log-level for all enabled protocols to log, at a minimum, unsuccessful logins.

The Oracle Intelligent Agent is used by the Oracle Enterprise Manager (OEM) to provide centralized database management both locally and remotely. Remote administration of databases is not prohibited, however, the enabling of remote administrative connections to the database introduces vulnerabilities to local databases, and hence requires mitigating controls. Administrative connections across the network are required to be encrypted (see See Exhibit 10.8.4-2. B.6.3.6) in order to protect sensitive information such as passwords from being disclosed. The Oracle Intelligent Agent, because it offers administrative action on the local database and is available via the network, is vulnerable to attack and therefore shall be disabled on all Internet-accessible IRS DBMS systems. Remote administration may still be performed using allowed protected local sessions such as VPN or protected dial-up connections to a local host account that has DBA privileges to the database.

Oracle accounts shall be so that system tablespace are restricted to use by the Oracle database system operation and maintenance. Oracle database accounts, with the exception of Oracle default accounts, shall not specify the system tablespace as their default or temporary tablespace. In Oracle versions 9i and later, a default temporary tablespace shall be defined and used. Such a default temporary tablespace ensures that objects identified as temporary objects are automatically removed from the database upon database session termination. Application user and application administration database accounts shall have all tablespace quotas set to 0, for the reasons explained in the Application User Database Accounts section of this IRM (namely, that these accounts are prohibited from creating database objects).

In Oracle, the session inactivity time shall be set through profiles by specifically setting the idle time within the profile ( See IRM 10.8.4.5.4.7. Database Session Inactivity Time Out, for time out requirements). This means that every Oracle database account shall be assigned to a profile and the idle time setting within each profile shall be set to 15 minutes or less.

Oracle automatically creates the default profile and assigns all Oracle database accounts to this profile, unless they are manually assigned to another profile at creation. The default profile shall be modified so the idle time setting is set to 15 minutes or less. If any other profiles are created, they, too, shall be set to 15 minutes or less unless required for operation of specific functions. Specific functions requiring an extended idle time shall be documented in the life cycle. c. The ALTER PROFILE SQL statement shall be used to change the idle_time resource under the default profile. The initialization parameter, RESOURCE_LIMIT, shall be set to TRUE, and the database restarted, before the resource values for any profiles shall affect any and all database accounts.

The DBA shall configure all idle time limits to a max 15 minutes unless authorized otherwise

Current policy does not require a DBA to limit the number of sessions that a database account has open at any time. The SESSIONS_PER_USER setting can be a valuable way to control the number of connections that any particular database account has open at anyone time. The DBA shall consult with the application owner and fix a limit on the open sessions allowed on any database. This parameter shall be set in the profile of all application user database accounts and modified in the default profile. Setting this parameter too low for a database application that requires multiple sessions can prevent it from functioning properly. In the case of an application that allows multiple users to connect with a single database account, too Iow a value for SESSIONS_PER_USER could prevent subsequent application users from connecting. The DBA shall consult with the application owner to determine an appropriate number of connections to be open in light of user experience. Hence, the value of SESSIONS_PER_USER shall be selected appropriately to support the application.

The Oracle ARCHIVELOG mode allows databases to be recovered after failure to a specific point in time by archiving redo log files. If ARCHIVELOG mode is not enabled, then recovery of Oracle databases may only be recovered to the time when the database was last backed up. ARCHIVELOG mode is appropriate for dynamic or transaction oriented database systems, but not necessarily so for databases that store relatively static data. The DBA shall enable ARCHiVELOG mode.

The Oracle SQLPlus application provides a means to enter SQL statements directly to the Oracle database. Accounts with access to this application may connect to the database and exercise their full privileges as granted to their database account. Oracle offers a way to limit access to SQL commands entered in the SQLPlus application by establishing the Product User Profile. The SYSTEM account shall create the PRODUCT_USER_PROFILE table by running the pupbld.sql script. At a minimum, the SQLPlus HOST command that allows access to the database host system commands shall be restricted to authorized DBAs.

Oracle provides the WRAP Utility to encrypt the source code of stored PL/SQL procedures and functions. However, the utility does not encrypt string or numerical literals, variable names, or table and column names. It does not encrypt passwords stored in these procedures or functions. The WRAP utility shall be used to encrypt custom and GOTS application code stored in the database. Variable values shall be obscured by using concatenated values. Account names and passwords and other sensitive data shall not be hard coded in the PL/SQL code. Instead, store usernames and passwords in encrypted form within a protected database table.

The Oracle Trace Utility, otrace, is used to collect performance and resource utilization data. Such data collection can have a negative impact on database performance and disk space usage. Use of the utility shall be restricted to the DBAs responsible for the database(s) on the system.

This section describes how to enable auditing on an individual database. The minimum level of auditing shall be enabled for every database on all machines. Minimum auditing shall include:

The following Oracle audit and error log files shall be reviewed in accordance with the audit monitoring requirements listed in the Audit Data Review section of this IRM. Information found in the v_$resourcelimit table shall be monitored with the audit monitoring requirements listen in the Audit Data Review section of this IRM.

The database table AUD$ is owned by the SYS account by default and shall be used to capture and store audit information. Privileges to delete, update, or insert directly into the audit table shall be restricted to auditors and DBAs. Access to this table shall be restricted to DBAs or security auditors. The DBA or security auditor may delete information from this table after performing maintenance backups. When stored externally to datafiles, the datafiles shall be protected by the operating system. Access to the external audit files shall be granted in accordance with the applicable operating system IRM.

By default, the AUD$ table resides inside the SYSTEM tablespace and is owned by SYS. Although not supported by Oracle, the DBA shall move the AUD$ table to a dedicated tablespace and onto a separate disk which improves security and can improve Oracle performance. The DBA shall move the AUD$ audit data table, please do so as prescribed in Oracle Document ID 72460.1. It may be necessary to move the audit table back to the SYSTEM tablespace to support upgrades or backup and recovery operations. Ownership of the AUD$ table shall be restricted to a protected database account such as SYS or SYSTEM. Access to the protected account shall have the same restrictions as the SYS and SYSTEM accounts.

The DBA shall enable Oracle auditing. The initialization parameter AUDIT_TRAIL shall be set to TRUE, DB, or OS depending on the operating system and the target storage area.. Setting the initialization parameter to TRUE or DB shall store audit records in the AUD$ table within the database. Setting the initialization parameter to OS shall store records in an operating system audit file. The directory name for this OS file shall be specified in the AUDIT _FILE_DEST initialization parameter on host systems other than Windows. On Windows hosts, the audit trail data directed to the OS is stored in the Windows event logs.

The DBA shall set the Oracle audit trail parameter to AUDIT _ TRAIL=TRUE or AUDIT _ TRAIL=DB or AUDIT _ TRAIL=OS.

Once auditing is enabled at the database level, the following system privilege and object auditing shall be enabled. All auditing shall be done BY ACCESS. Access auditing means that audit records are generated each time an audited privilege is used or an audited statement is issued. Auditing by access may generate more audit records than audit by session; however, it does not impact database performance as much since each audit event does not trigger a search through the audit trail for the same action as does audit by session. The mandatory auditing requirements are meant to capture only changes to the data dictionary or database structure or privilege assignment events. Please note that in production systems, few actions that generate audit records should occur. Database objects and structure are typically static. Data access and modification auditing should be decided during application design and implemented as an application requirement.

The statement auditing options specified in the list below titled "Oracle Statement Audit Requirements" shall be implemented in production DBMS systems that process sensitive taxpayer data. The audit options shall be enabled by issuing the following SQL audit statements:

The following SQL statements shall disable audits set by the commands above that are not required:

ORACLE STATEMENT AUDIT REQUIREMENTS

Object auditing audits events related to a specific object. The following auditing option applies to specific objects and shall be enabled by a DBA. Some applications may require additional object auditing options as specified by the application.

In addition to auditing for specific events, Oracle provides the capability of setting a default audit option for all objects. All objects created after a default has been defined, shall be audited for the default audit event. All application objects shall be audited for RENAME. The RENAME audit option shall be set as the default for all objects. The RENAME audit option shall be set for all existing application objects.

The DBA shall audit the permissions to issue data definition language data definition language (DDL) statements that modify the data dictionary and effect system wide changes. The DBA shall audit these privileges:

The Oracle audit trail shall be maintained periodically. The audit data shall be exported and then purged routinely. The SYSTEM table space where the audit trail is located shall be checked routinely to ensure that free space is available for the audit trail table to grow. If space is not available (the AUD$ table has consumed all of it), then all activity upon the DBMS shall stop until space is made available by the DBA. The sizing of the audit trail tablespace and the maintenance of the audit trail shall be specific to each database instance.

Online redo log files contain records of all changes made to the database as they occur. They are critical to the recovery of a failed database instance. In order to protect online redo log files from disk failures, redo log files shall be multiplexed by defining a minimum of two redo log file groups configured with a minimum of two file members each. The file members for each redo log file group shall be located on separate physical disks. For example, the first file member from each group shall be placed on one physical disk and the second file member from each group shall be placed on a separate physical disk.

Datafiles contain the actual database data. Placing datafiles on separate physical disks isolates disk contention between applications as well as allows for discrete OS file protections. Additionally, they shall be placed on separate physical disks from redo log files to allow for recovery in the event of disk failure. However, when redo logs are multiplexed, this is not necessary.

File location and host system file structure is configured by default at Oracle installation to comply with Oracle’s Optimal Flexible Architecture (OFA). The OFA defines naming conventions and file structures for housing the three types of Oracle files— administrative files (configuration files, export files, and script files), product or software files (database executables), and database files (datafiles, control files, and redo log files). The OFA structure provides a foundation for a more manageable, more efficient, better performing, and more reliable database system. All Oracle installations shall conform to the OFA unless a deviation is filed for a particular instance.

Oracle does not provide OFA guidelines for Oracle installations on the OS/390 platform; however, instance naming standards, database file naming standards, and tablespace naming standards shall still be followed.

The system identifier of a database using the Oracle DBMS is referred to as the Oracle SID. To allow for portability of the applications across multiple operating systems, Oracle recommends that the instance name be between four and eight characters long. Unless technically infeasible because of third party or COTS software, this convention shall be implemented. If third-party or COTS software recommends a certain naming standard, follow their recommendation, however, when possible change the default SID of third party software from the default which may be well known.

Production database instance names or Oracle SIDs shall not include a version number, Oracle-related or otherwise. Production database instance names or Oracle SIDs shall not use the default of ORCL.

The use of dedicated tablespaces for different applications reduces the possibility of contention of disk storage. The USER tablespace or similar tablespace should be designated as the default tablespace for DBA’s and developers. Application objects shall be located in separate, dedicated tablespaces created for each application.

Optial Flexible Architecture (OFA) is a clear set of standards for handling multiple databases and multiple versions of Oracle on the same machine. This standard naming convention shall be used by IRS DBAs.

Oracle files may be categorized into three types of files—administrative, product/software, and database files. These categories of files require specific storage and access requirements on the host system. Administrative files include database initialization and configuration files, log files, export files, and other types of database output files. Product/software files include database server executables and executables for other applications that support the DBMS . Database files include the database control, redo log, and datafiles. On UNIX systems, a minimum of four mount points shall be defined. One mount point is for the administration and application software and three are for database files.

Database file mount points are used to separate datafiles based on I/O contention, backup requirements, and lifespan considerations. Mount point names shall follow the format of /pm where p is a fixed string constant and m is a unique identifier such as sequential numbering. No Oracle files shall be located on the same OS file system as the core OS itself.

The ORACLE_BASE directory, defined by a UNIX account environment variable, is used as the parent directory for all Oracle product installations. The OFA-compliant ORACLE_HOME directory naming follows the format /mount-point/standard directory name/oracle/version where the standard mount-point is as described above and the standard directory name is a UNIX standard directory name like "app." The ORACLE_HOME directory is used to store specific database version software. On OFA-compliant installations, it is a subdirectory under the ORACLE_BASE directory. The OFA-compliant ORACLE_HOME directory naming follows the format ORACLE_BASE/product/version where product denotes the database server product and version denotes the Oracle Database version. Full pathnames shall only be referenced in the files meant to store them such as the /etc/passwd and Oracle oratab files. Database-specific administrative files in an OFA-compliant system are stored under the $ORACLE_BASE/admin/database name directory.

OFA guidelines currently are not supported in the Defense Information Infrastructure Common Operating Environments (DII COE) guidelines for UNIX. The directories to support the OFA guidelines can be established as soft links. The system can meet both OFA and DII COE requirements by placing a symbolic link or file stub in the default location that points to the OFA file locations. Site-specific (application specific) data should be located on separate mount points.

All database files associated with a database instance shall reside in a directory structure, similar to the examples provided below. Site-specific (application-specific) datafiles shall be located on a separate mount point and these mount points shall be located on separate disk drives.

OFA standards for Oracle on Windows and UNIX have the same main subdirectory structure and filenames. They differ in the root directory level names and in the method for defining variables. The ORACLE_BASE directory is located by default directly under the root of a disk partition and named X:\/ORACLE. The ORACLE_HOME directory, which supports a specific version or release of Oracle, is located directly under the ORACLE_BASE directory, for example, ORACLE_BASE\/ora90. Under the ORACLE_BASE directory are the ADMIN, ORACLE_HOME, and ORADATA directories. No Oracle files shall be stored on the same partition as the Windows operating system.

On Windows, Oracle variables are defined in the registry rather than in environment variables. Also, Windows does not support symbolic links that allow UNIX systems to support an apparent single directory structure even though files may be on different physical disks.

Oracle’s Operating System Dependent Interface (OSDI) shall be configured on the OS/390 platform as described below.

Under Oracle’s Operating System Dependent Interface (OSDI) architecture, a single subsystem may support multiple instances. The OSDI subsystem must have a unique one to four-character name. The subsystem name shall be used as the command prefix for OSDI commands. Oracle recommends that the subsystem name also be used as the OSDI command prefix.

OSDI service names are used as the OS/390 jobname for the service unless otherwise specified. To ensure that the OSDI services are run under JES and not the master subsystem, OSDI service names shall be unique from any OS/390 subsystem names. OSDI jobnames shall use the OSDI service name. OSDI database service names shall be used as the Oracle system identifiers (SID) and must follow requirements for Oracle instance naming. A single OSDI network service may support all connections to and from all from all database services on the host system. The network service name should indicate that it is a network and not a database service.

This section covers Oracle Initialization parameters that have security impacts and the parameters that shall be set for security to operate. This section is not intended to cover all Oracle Initialization parameters. All initialization parameters listed below must be specified for all Oracle instances.

The AUDIT_TRAIL parameter specifies where the Oracle database writes the audit trail information. The valid values are TRUE, DB, and OS. This parameter may be placed anywhere in the parameter file after the parameter.

The RESOURCE_LIMIT parameter specifies whether or not enforcement of resource limits is enabled. If not enabled, the required idle time limits would not be enforced. The default value for this parameter is FALSE, the required value for this parameter is TRUE.

The parameter REMOTE_OS_AUTHENT, when set to TRUE, allows the authentication of remote clients by the host operating system. The default value for this parameter is FALSE. This parameter shall remain set to FALSE because of the risk of an impersonation attack (impersonating a valid OS node), otherwise known as spoofing. The required value for this parameter is FALSE.

The parameter REMOTE_OS_ROLES, when set to TRUE, allows operating system roles to be used from remote clients. The required value for this parameter is FALSE. Roles on a DBMS shall be locally defined and shall implement specific business purposes defined by the ELC documentation of the ELC project that uses the DBMS.

The parameter OS_ROLES, when set to TRUE, allows operating system roles to be used. The required value for this parameter is FALSE. Role information must be stored, managed, and protected in the database rather than files external to the DBMS.

The parameter DBLINK_ENCRYPT_LOGIN, when set to TRUE, prevents unencrypted passwords from being sent to remote servers. This parameter is supported only for backwards compatibility to Oracle database versions 6 and 7. All attempts between later versions are always encrypted. This parameter has been unsupported as of Version 9, Release 2 (9.2). The default value for this parameter is FALSE, the required value for this parameter is TRUE.

The initialization parameter SQL92_SECURITY when enabled or set to TRUE, specifies that SELECT privileges are required during an UPDATE or DELETE function when a where clause specifying column values is present. When set to false, UPDATE and DELETE privileges allow SELECT actions in such cases. Distinct SELECT privileges shall be required on all tables where select statements are performed. The SQL92_SECURITY parameter shall be set to TRUE.

The parameter UTL_FILE_DIR was added to support Oracle packages that allow the reading and writing of external text files to an operating system file. This parameter, if used, shall be set to a specific operating system directory where application procedures/programs can read and write files. This means the directory shall exist and have the permissions correctly set to allow Oracle background processes to write to the directory. Errors shall result if this initialization parameter is used on a directory to which Oracle cannot read/write. If this parameter is set to a "*" value, then all directories are allowed read/write access. The UTL_FILE_DIR parameter shall not be set to a "*" value. Use of a OS mount point, reserved for third party application data and separate from the mount points used for DBMS data files, is recommended when Oracle UTL_FILE_DIR functionality is used.

The Oracle software OS account will require read and write access to any directories used for UTL_File_DIR access. Note that the UTL_FILE_DIR parameter may be set to multiple values. Privileges for the UTL_FILE package in the database shall not be granted to PUBLIC.

The 07_DICTIONARY_ACCESSIBILITY parameter controls SYSTEM privileges. If the parameter is set to TRUE, access to objects in the SYS schema is allowed. If this parameter is set to FALSE, SYSTEM privileges that allow access to objects in other schemas do not allow access to objects in the dictionary or SYS schema. When the 07_DICTIONARY_ACCESSIBILITY=FALSE, then the SELECT ANY TABLE privilege allows access to views or tables in any schema except the SYS schema.

The system privilege EXECUTE ANY PROCEDURE would allow access to procedures in any schema except the SYS schema. If you need to access objects in the SYS schema, then you must be granted the explicit object privilege. The following roles that can be granted to the DBA also allow access to dictionary objects:

The REMOTE_LOGIN_PASSWORDFILE initialization parameter specifies whether Oracle uses a password file and, if in use, how many databases can use the password file. Setting the parameter to NONE signifies that Oracle should ignore any password file meaning that administrative access is granted by virtue of membership in the specified operating system Oracle DBA group. Setting the parameter to EXCLUSIVE signifies that the password file can be used by only one database. The password file requires remote DBAs to use their own individual DBA accounts to authenticate to the database for administrative database operations. Setting the parameter to SHARED allows more than one database to use the password file, however, the only account recognized by the password file is the SYS account.

You can create a password file using the password file creation utility ORAPWD, or for selected operating systems you can create this file as part of your standard installation. You can also reference your operating system-specific Oracle documentation for information on using the installer utility to install the password file. The types of filenames allowed for the password file are operating system specific. Some platforms require the password file to be a specific format and located in a specific directory. Other platforms allow the use of environment variables to specify the name and location of the password file. See your operating system-specific Oracle documentation for the names and locations allowed on your platform.

The AUDIT_SYS_OPERATIONS initialization parameter introduced with Oracle version 9.2 enables auditing of actions performed by the SYS, SYSDBA, or SYSOPER accounts. When set to TRUE, actions performed as SYS or with a SYSDBA or SYSOPER connection are audited regardless of the AUDIT_TRAIL setting. The audit records generated are stored in the OS audit file in the $ORACLE_HOME/rdbms/admin directory or in the Windows event log. The AUDIT_SYS_OPERATIONS parameter shall be set to TRUE.

The global names parameter value of TRUE requires that database links be defined with the same name as the database to which they connect. This prevents inadvertent connections to the wrong database and simplifies management of database links.

This parameter is an internal Oracle DBMS parameter. The setting of _TRACE_FILES_PUBLIC = TRUE allows all database accounts access to trace files. TRACE_FILES_PUBLIC shall be set to FALSE.

The MAX_ENABLED_ROLES parameter specifies the number of roles that may be active for a single database session at one time. Setting this parameter may provide additional assurance that application roles are being enabled and disabled in accordance with design. The default value of this parameter is 30. Consider adjusting this to a lower value if it is appropriate for your application or environment.

The REMOTE_LISTENER parameter causes the database to register with a listener located on a separate host machine. The configuration and management of the remote listener would be outside the security domain of the database host system. Remote listeners shall not be used.

The AUDIT_FILE_DEST parameter specifies the directory where the Oracle database audit trail shall be written on the host system. The AUDIT_TRAIL=OS must be specified for this parameter to take effect.

The USER_DUMP_DEST parameter specifies the host directory where database session trace files are written. The USER_DUMP_DEST parameter shall be set to a valid and protected directory.

The BACKGROUND_DUMP_DEST parameter specifies the host directory where the Oracle alert log and trace files for the Oracle background processes are written. The BACKGROUND_DUMP_DEST parameter shall be set to a valid and protected directory.

The CORE_DUMP_DEST parameter specifies the host directory where the Oracle core files are written. This parameter is applicable only for UNIX systems. The CORE_DUMP_DEST parameter shall be set to a valid and protected directory.

The LOG_ARCHIVE_START parameter when enabled, starts redo log archiving at the time of instance startup. The database must be in archive log mode for this parameter to take effect.

This parameter requires that ARCHIVELOG mode be enabled on the database. If applicable, the DBA shall set this parameter to a valid and protected directory.

This parameter requires that ARCHIVELOG mode be enabled on the database. If applicable, the DBA shall set this parameter to a valid and protected directory.

The OS_AUTHENT_PREFIX by default is set to the value ‘OPS$’. If OPS$ is used as the OS_AUTHENT_PREFIX, then accounts created with the IDENTIFIED BY clause may authenticate to the database using either OS authentication (connect /) or using database authentication (connect username/password). Setting the OS_AUTHENT_PREFIX to a value other than ‘OPS$’ prevents an OS account from being able to access a database account by the same name without providing a password. The OS_AUTHENT_PREFIX parameter shall set to a value other than ‘OPS$’.

The Oracle software is developed with a generic Oracle Kernel without regard for the target operating system. This ideology allows Oracle to be the same across all platforms with the only uniqueness being in the operating system specific shell code to provide access to the operating system. This section describes any and all deviations from published OS IRMs as well as OS-specific Oracle security guidance. All OS IRM issues shall not be addressed initially, but shall be added as discovered in testing and implementation of all operating systems.

This section describes Oracle required deviations from the published IRS UNIX IRM. Reference the IRS UNIX IRM for additional guidance.

The installation of Oracle on a UNIX host requires that a unique UNIX userid be created and configured. This account becomes the owner of all Oracle application and datafiles and shall be used only for the update and maintenance of the Oracle software. This account shall be locked when not in use. Individual DBAs shall use their individually assigned OS accounts for daily DBMS administration activities, and shall not use the Oracle software installation account for such activities. This allows auditing of all operations from an OS perspective and allows the Oracle auditing to audit actions performed with the correct OS account. Access to the Oracle OS account shall be restricted to site-authorized DBAs only. The Oracle software installation account shall not be a member of the root group.

Individual accounts created for the individual Oracle component processes allow for the separation of security controls on directories and files and accountability for events. Separate accounts shall be created for and used by the Oracle Listener, and the database process as well as the Intelligent Agent, if the Intelligent Agent is implemented in the instance.

Heading B.16.1.2 mandates that Oracle listener processes be run from a different OS account than the OS account that owns Oracle database processes. This is not the default installation behavior of Oracle software products, so configuration modifications are required by the SA and DBA to accomplish this requirement.

If Oracle Intelligent Agent software is run on a Unix DBMS host, the OS processes for the agent shall be run from a different OS account than the OS account that owns Oracle database processes.

Every database user’s .profile file may be owned by the individual’s OS userid. The IRS UNIX IRM specifies this as an option. For database accounts, it may be advisable that the .profile be owned by the individual’s OS userid to allow the OS user to customize the DBMS required environment variables.

Access to database accounts used for non-interactive and automated processing frequently requires that the username and password be stored and transmitted. Any storage of database account passwords on any system shall be encrypted. On UNIX systems, the preferred method for encryption of a password within a file is by means of an application call such as the C language crypt function. Use of the UNIX crypt command to encrypt a file is not considered sufficiently secure, as the means to decrypt these files is widely known. If use of the crypt application function is not possible, then the UNIX crypt command shall be made more secure by compressing the file and encrypting it several times.

In all cases, storage of the encryption key to the file and the application or batch file that encrypts the data shall be protected from unauthorized access by the operating system. Access to these files and keys shall be restricted to SAs and DBAs.

Passwords shall not be stored unencrypted in UNIX environment variables.

If possible, non-interactive/automated processing accounts shall use Oracle "identified externally" accounts (accounts that are authenticated by the host operating system) to connect to the database. These accounts eliminate the requirement to provide a separate username and password to authenticate to the database. These accounts may not be used for remote connections to the database.

The Oracle software owner shall have a umask setting of 022. SAs/DBAs shall change their umask settings to 022 when performing database operations. This allows for all actions performed by the DBA to inherit the correct umask setting for the underlying DBMS. The IRS UNIX IRM specifies the umask to be set at 077. Application user database accounts, application administrator accounts, or application developer accounts shall not be members of the UNIX DBA group(s).

All files stored in the $ORACLE_HOME/bin directory shall be owned by the Oracle software installation account.

All permissions to files and directories that are created as the result of an installation of Oracle or stored in the $ORACLE_HOME directory shall be set to the recommended security settings of the Oracle installation guide or more restrictive. Accounts other than the Oracle software owner account and the DBA group should be denied access except to executables under the $ORACLE_HOME/bin directory as specifically required. These files and directories shall be secured by using access control methods native to the operating system.

Some Oracle database files require that the suid bit be set. The suid bit must be set on the following files as required by the successful operation of Oracle. This requirement is in accordance with the IRS UNIX IRM.

Oracle files shall not have the setgid bit enabled. Enabling the setgid bit on an executable file causes the file to execute using the permissions of the file’s group rather than the permissions of the OS account executing the file. Enabling the setgid bit on a directory causes all files created within the directory to be created with the group of the directory.

Enabling the setuid bit on an executable file causes the file to execute using the permissions of the file owner rather than the permissions of the OS account executing the file and can cause the creation of unsecured files and unauthorized access. Oracle files with the setuid bit enabled shall be restricted to administrator usage only. Only the following executable files are required by Oracle to have the setuid bit enabled—dbsnmp, oidldapd, and oracle.

Access to the Oracle initialization parameter files including INIT.ORA, INIT<SID>.ORA, and/or SPFILE.ORA shall be restricted to the Oracle owner and DBAs.

Oracle stores the internal SYS password and the password of accounts granted the SYSDBA or SYSOPER role in the orapw<SID> file. Although the passwords are encrypted, access to this file shall be restricted to authorized DBAs. Read access to this file could allow someone to determine the internal or SYS password and would allow an unauthorized user access to Oracle.

The permissions of the operating system file listener.ora, which houses listener configuration parameters and the listener password, shall be restricted to the Oracle software owner or the DBA OS user group. Read access to this file could allow someone to determine the listener service password and would allow an unauthorized user to start, stop, and configure the listener service. If a password has been set, the following entry shall be found in the file:

The SA/DBA shall restrict access to the listener.ora file to the Oracle owner account, the Oracle TNSLISTENER service/process account, and authorized DBAs.

The SNMP_RW.ORA file contains the password for the DBSNMP database account in cleartext. The SNMP_RO.ORA file contains configuration information for the Oracle Intelligent Agent. Access to these files shall be restricted to the Oracle software owner account and DBAs. The lines in the DBSNMP_RW.ORA that present a security risk are the following:

The SA/DBA shall restrict access to the dbsnmp_rw.ora and dbsnmp_ro.ora files to the Oracle software owner account and authorized DBAs.

The SQLNET.ORA file contains network configuration information for the host database and listener. Unauthorized access to this file could result in compromised access to the database and/or the listener. Access to the database server SQLNET.ORA file shall be restricted to the Oracle software owner account and DBAs.

SQLNet and Listener log and trace files may contain information useful for accomplishing unauthorized database access. Access to these files shall be restricted to the Oracle software owner account and DBAs.

The SQLNET.ORA parameters 10g_directory_client, log_directory_server, trace_directory_server, and trace_directory_c1ient shall be set to a valid, protected directories.

The LISTENER.ORA parameters log_file_listener and trace_directory_<listener name> shall be set to valid, protected directories. The LISTENER.ORA parameter logging_listener shall be set to the value ON. Access to the file designated in the LISTENER.ORA parameter trace_file_<listener name>_n shall be restricted to the Oracle software owner account and DBAs.

Access to the Oracle critical files listed below shall be restricted to the Oracle owner account and DBAs.

This section describes Oracle required deviations from IRS Microsoft Windows IRM security guidance. Reference the Windows IRMs for additional guidance.

The following guidance shall be observed when installing Oracle on Microsoft Windows platforms:

The Oracle Windows Services are configured upon installation to use the Windows local SYSTEM account. Oracle recommends that Full Control access permissions to Oracle data and file directories be granted only to the Windows service account (SYSTEM). However, SAs, and DBAs may also require additional access to Oracle database files and directories for maintenance and update. Therefore, Full Control permissions may be granted to DBAs on Oracle directories and files. Application user OS accounts may be granted read access permissions to required Oracle application executables. The Everyone group shall not be granted access permissions to any Oracle database files or directories.

The Oracle Windows service account (SYSTEM) shall be granted Full Control to the Oracle registry keys under HKEY_LOCAL_MACHINE\/SOFTWARE\/ORACLE.

If the database is created through the Oracle Database Assistant client application and the typical option is chosen, the Server Manager reports all activities to a log file called SPOOLMAIN.LOG. This log file contains the passwords in plain text and has file permissions that allow anyone to view it. This file shall be permanently deleted after a database install.

Access to database accounts used for non-interactive and automated processing frequently requires that the username and password be stored. Any storage of database account passwords on any system shall be encrypted. On Windows systems, passwords for these accounts may be stored in text or application files or in the Windows registry. These passwords stored in host system files of any type or the Windows registry must be stored in encrypted format using a FIPS 140-2 or later compliant encryption algorithm.

In all cases, the encryption key, the encrypted password file or registry key, and the application or batch file that encrypts the data shall be protected by the operating system from unauthorized access. Access to these files and keys shall be restricted to the DBAs.

Passwords shall not be stored unencrypted in Windows environment variables. If possible, non-interactive/automated processing accounts shall use Oracle "identified externally" accounts (accounts that are authenticated by the host operating system) to connect to the database. These accounts eliminate the requirement to provide a separate username and password to authenticate to the database. These accounts may not be used for remote connections to the database.

This section describes Oracle required deviations from the published IRS OS/390 IRM as well as OS/390-specific security requirements. Reference the IRS OS/390 IRM for additional guidance.

The DBA shall conform to the deviations contained in sections B.16.3.1 through B.16.3.5.

Deviations other than those listed in B.16.3.1 through B.16.3.5 shall not be implemented.

Access to Oracle libraries shall be restricted to three types of users—the Oracle software installer who is typically a Systems Programmer; Oracle DBAs who are OS/390 user accounts with special privileges to Oracle resources; and general database accounts for OS accounts that require access to specific Oracle utility executables. Following is the list of the minimum access restrictions. Oracle Corporation provides a host based Resource Access Control Facility (RACF) access level recommendation for each partioned data set (PDS) used by the Oracle subsystem. Equivalent ACP authorization levels should be set for non-RACF installations.

The SA/DBA shall restrict access to Oracle libraries according to the list in 10.8.4-3 B16.3.1 at a minimum.

The systems programmer shall own the Virtual Storage Access Method (VSAM) system data sets used by the Oracle subsystem. These data sets contain the control files, database files, and redo log files. Other access to these files shall be restricted to the Oracle database service userid.

This section describes Oracle required deviations from IRS Microsoft IBM IRM security guidance. Reference the IBM IRMs for additional guidance.

Oracle commands reside in the Oracle oran.orav.CMDLOAD library where oran is the high-level qualifier and orav is the secondary qualifier for the installed Oracle product version.

Access to the following MPM commands shall be restricted to System Programmers and DBAs by removing them from the CMDLOAD library and move them to a restricted library or use program control to restrict access to the command procedures in the CMDLOAD library:

The SA shall restrict access to command procedures CRTCNV, MPMCMD, or SVRMGRL systems programmers and DBAs.

The Oracle user logon exit point uses the operating system to authenticate users to the Oracle database. When configured, the Oracle server invokes the user logon exit point each time a user attempts to log on to Oracle. Protection of authentication credentials (username and password) by exit logon modules requires verification with encryption.

Current Oracle database security guidelines as set forth in this document prohibit the assignment of database role membership outside of the database. Thus the DBA retains the sole authority and responsibility for assigning database authorizations. In accordance with this, user role exit points shall not be used by Oracle databases.

Oracle integration with OS/390 security features includes use of OS/390 resource profiles, Program Properties and APF authorizations, and association of OS/390 account identification with OSDI-defined services. Resource profiles for Oracle bind and administrative access protections shall be defined in a dedicated resource class named ORAB. Resource profiles for Oracle OSDI command access protections shall be defined in a separate dedicated resource class named ORAO.

Access to OSDI Subsystem commands is controlled by resource profiles defined during Oracle installation. Oracle resource profiles for OSDI subsystem commands shall be defined the ORAB dedicated resource class. Access to OSDI subsystem commands shall be restricted to system programmers (or consoles), DBAs, accounts by these resource profiles. The level of authorizations for OSDI commands shall be set as shown in the following table where ssn is the Oracle OSDI subsystem name selected at installation:

Two services are defined within the Oracle OSDI architecture: the database service or instance and the Oracle network service. Connections to these services are accomplished using OSDI bind processing that performs an authorization check when the connection is requested. Authorization permission is verified by checking the OSDI bind resource profiles. If resource profiles have not been defined for a service, then all binds from all address spaces are allowed. Resource profiles shall be defined for all Oracle OSDI services to a Security Access Facility (SAF)-compliant security server. Two profiles shall be created for each service. One profile is managed binds (used by CICS, IMS, and other Oracle services), and the other is for binds by normal applications (TSO, batch Oracle tools or Oracle applications). The name format for these profiles shall be ssn.service.UBIND and ssn.service.ABIND where ssn is the OSDI subsystem name defined at installation, service is the Oracle database or Oracle Net service name, the constant UBIND indicates application binds, and the constant ABIND indicates managed binds. Resource profiles that protect binds to Oracle services shall be created in the dedicated Oracle resource class.

Access to the Oracle database with database administration privileges SYSDBA and SYSOPER is controlled by SAF-defined resources. OS accounts granted Read authorizations to these resources are granted the privilege to connect to the Oracle database with administrative privileges. Read access to the SYSDBA and SYSOPER resources shall be restricted to authorized DBAs and systems programmers. If the SYSDBA and SYSOPER resource profiles are not defined, then any userid may connect to the database service with these privileges. The SYSDBA and SYSOPER resource profiles shall must therefore be defined in dedicated Oracle resource profiles. These profiles shall be named ssn.service.OPER and ssn.service.DBA, where ssn is the OSDI subsystem name and service is the database service name.

The userid associated with the database service must be granted authorization to create and delete Oracle VSAM linear data set (LDS) files. Oracle invokes the OS/390 IDCAMS utility to perform data set creation and deletion operations. Authorization to create and delete Oracle data sets shall be restricted to the associated Oracle service name userid, DBAs, and systems programmers.

The userid associated with the database service must be granted authorization to create and delete Oracle VSAM linear data set (LDS) files. Oracle invokes the OS/390 IDCAMS utility to perform data set creation and deletion operations. Authorization to create and delete Oracle data sets shall be restricted to the associated Oracle service name userid, DBAs, and systems programmers.

The Oracle service requires update-type access to the VSAM LDS datafiles and write access to the database alert and diagnostic logs. It also requires read access to files including database parameter and SQL files. Access to Oracle data sets shall be restricted to the Oracle service userid and systems programmers.

OSDI binds initiated by OSDI services are used to establish database links. Database links are used to connect one database instance to another or to connect the Oracle Net service to an instance. OSDI bind authorizations are used to restrict which address spaces may connect to the local database service. OSDI bind authorization between OSDI databases and network services shall be restricted to authorized database and network services.

The Oracle backup and recovery utility and the External Data Mover (EDM) services require authorization to operate. If in use, the EDM services userid must be granted authorization to open sequential backup data sets for backup (output) and recovery (input). It may also be granted authorization to delete backup datasets for maintenance operations. The EDM services userid does not require access to Oracle VSAM LDS files to function.

In order to grant authorization to Oracle Net OSDI services, an OS/390 userid must be associated with the Oracle Net service. See the Oracle9i Enterprise Edition Installation Guide for instructions on associating OS/390 userids with OSDI services.

Oracle user connections to the database may be authorized by the host operating system. Host authorization may be used to authenticate users accessing the database from a local host session or a remote host session. Oracle provides host OS authentication by use of a built-in SAF check or an external logon exit module. If the customer selects host authentication, the built-in Oracle SAF check shall be used. Logon exit modules shall not be used. The LOGIN_AUTH OSDI service parameter shall be set to NONE or SAF. This setting applies only to database accounts that are IDENTIFIED EXTERNALLY.

Oracle Access Manager allows applications running under CICS or IMS/TM to issue industry standard SQL statements against an Oracle server. No coding for proprietary application program interfaces (APIs) is required. Mainframe programs can execute distributed transactions spanning both OS/390 and Oracle data. Distributed transactions can be coordinated using CICS or IMS/TM to ensure the integrity of the entire transaction.

To prevent static storage of passwords in CICS and IMS/TM Oracle connect strings, CICS and IMS/TM connections to the database shall use Oracle database accounts authenticated by the OS/390 host system.

The LOGIN_AUTH initialization parameter shall be set to SAF and the CICS application id username be created within Oracle as IDENTIFIED EXTERNALLY.

The IBM System Management Facility (SMF) provides a facility for users to monitor, collect, and record a variety of system and job related information. The Oracle subsystem uses the standard SMF interface to write user records and the Oracle audit trail, if specified, to the SMF data sets. User records may contain Oracle subsystem accounting data and other Oracle information allowing Oracle installation sites to charge individual users for the resources they use.

Audit trail data must be protected in accordance with security policy. Access to any SMF data set storing Oracle audit data shall be restricted to systems programmers and database security officers.

The information contained in this appendix is specific to Microsoft (MS) SQL Server Versions 7 and 8. MS SQL Server Version 8 is marketed as SQL Server 2000. When version-specific information is presented, it shall be labeled with the version to which it specifically applies.

SQL Server versions shall be updated with hotfixes and service packs to address product bugs as well as to provide fixes for published security bulletins. MS Support Services has defined a "product support lifecycle." When a product is selected for support expiration, Microsoft provides a six-month notice. Microsoft publishes the list of hotfix availability end dates on its web site. Products that have been expired under standard support no longer receive published updates from Microsoft to address discovered security problems.

To protect your SQL Server environment, the DBMS version shall not be an expired product. The SQL Server software service pack shall be no earlier than the current service pack version minus one.

SQL Server Version 8 (SQL Server 2000) is capable of being fully C2 compliant. The policies and information in this appendix incorporate most configuration settings that set SQL Server to meet the C2 specifications.

The DBA shall ensure that only the host-based authentication method is implemented since only that method meets C2 requirements. Windows and Windows Active Directory provide a Windows security identifier (SID) to SQL Server that provide the ability to audit activity by individual database accounts.

Mutual authentication of databases enables secure distributed transactions between application servers, web servers, and database servers without compromising the user’s credentials. Mutual database authentication and strong user authentication may be accomplished by using industry-standard X.509 certificates or passwords. Microsoft refers to these systems as Linked Servers that specify an OLE DB provider and an OLE DB data source.

The DBA shall ensure that SQL Server’s auditing is enabled, the auditing requirement of C2 is to be met in the following ways:

The DBA shall ensure that Server Access Controls are assigned to promote maximum security consistent with operational requirements. To that end the DBA will configure the SA Connection, the OS DBA Group, the SYSADMIN Role, the Default SQL Server Passwords, and the Default SA Password,as follows

The SQL Server SA pseudo database account shall not be used. Only trusted connections shall be used to access the SQL Server database.

The installation of MS SQL Server does not create any Windows OS groups. A DBA OS group shall be created and the authorized DBA accounts assigned as members to this group.

All DBA activities shall be performed as an account within the SYSADMIN role. The SYSADMIN fixed server role provides full system privileges as well as allows the account to perform all database administration functions including:

The DBA shall assign only authorized DBAs the SYSADMIN role.

The DBA shall deny the Windows BUILTIN\/Administrators group the assignment to SYSADMIN role.

The DBA shall ensure that DBA accounts are only used to support DBA activities.

Any default passwords for database accounts created during an SQL Server installation shall be changed after installation.

The default SA password, used to connect as administrator, shall be changed from the default installation value. Leaving the default password unchanged could result in unauthorized accounts accessing the server as sa, which provides them full database administration privileges.

The MS SQL Server Agent services, MSSQLServer or MSSQL$Instancename for a named instance and SQLServerAgent, shall not be run under the administrator or system accounts. A service account shall be defined and shall be a local Windows account unless a Windows domain account is required to support replication, remote procedure calls, or SQLMail. The SQL Server Agent services shall use the same account. The service account shall not be a member of the local or domain administrators group. The service account shall be denied the interactive logon right. The service account must be added to the SQL Server SYSADMIN role. The SQL Server Agent service account requires the following rights:

The SA/DBA shall configure the SQL Server services to run under accounts other than a Windows administrator or system account

The SA/DBA shall configure the SQL Server services to run under a single local Windows account or a Windows domain account if required

The SA/DBA shall configure the SQL Server services account so that it is not a member of a local or domain administrators group

The SA/DBA shall deny the SQL Server services account the interactive logon right

The DBA shall ensure there is a matching of SQL Server database accounts and Windows OS accounts. This contributes to a secure environment by limiting confusion over user identity. Limiting confusion of identity lessens the risks of improper permission assignments and aids in the monitoring of auditing logs. It is recommended that the DBA maintain SQL Server security account names in accordance with Windows account names. Windows groups may also be used to assign SQL Server roles and thereby eliminate the maintenance requirements for individual SQL Server account names altogether.

The SQL Server guest account allows Windows accounts without direct SQL Server authorization that have been authenticated to the Windows OS to access the database. It cannot be removed from the master and tempdb databases. The guest account shall be deleted from all databases except the master and tempdb databases.

Linked or remote servers shall only be configured to use Windows authentication. The capability to preserve a user’s identification, and, therefore, maintain DAC integrity, is currently available only in a Windows 2000 or later environment where the connections can be protected with Kerberos and account delegation can be used. When linking SQL Server databases, the connection shall be authenticated using the current user’s identification and passwords or certificates.

SQL Server authentication is dependent upon the underlying Windows platform. Password requirements shall be implemented according to the Windows NT/2000/XP Addendum.

SQL Server contains two different default role types—fixed server roles and fixed database roles. Fixed server roles are used for database administration and are applied system wide. The fixed server roles exist within the database and are granted to Windows local or global groups or to individual Windows accounts. These roles shall only be used to support DBA activities.

Fixed database roles apply only within a particular database. A database account assigned a fixed database role has those privileges only in the database where they have been assigned.

Fixed server and database roles shall not be granted to application user database accounts, application administrator accounts, or application roles. Fixed server and database roles shall not be granted to PUBLIC. Fixed server and database roles shall not be granted to GUEST. The BUILTIN\/Administrators group should be removed from the SYSADMIN role. The DBA OS group shall be added to the SYSADMIN role.

Fixed server roles:

Fixed database roles:

The DBA shall ensure that SQL Server fixed server roles are only used to support DBA activities.

The DBA shall not grant SQL Server predefined roles to PUBLIC or GUEST.

The DBA shall not grant the above-listed SQL Server predefined roles to application user database accounts, application administrator accounts, application developer accounts, or application roles.

The DBA shall ensure that the SYSADMIN role is not granted to the BUILTIN\/Administrators OS group.

The DBA shall grant the SYSADMIN role to the DBA OS group.

The DBA shall ensure that SQL Server access privileges are granted to database accounts, Windows groups, or database roles in accordance with sections C.3.12.1 and C.3.12.2 below. Data may be protected down to the column level. Privileges to fixed roles cannot be modified.

The DBA shall ensure that SQL Server statement privileges shall not be granted to PUBLIC or GUEST. The following list of SQL Server statement privileges shall not be granted, directly or indirectly through the use of roles, to any application user, application administrator, application developer, or application role.

The DBA shall ensure that SQL Server statement privileges are not granted to PUBLIC or GUEST.

SQL Server object privileges include SELECT, INSERT, UPDATE, DELETE, REFERENCES, and EXECUTE. The references object privilege shall not be granted to any application user, application administrator, or application role. No object privileges shall be granted to PUBLIC or GUEST. Access to system tables is granted by default to PUBLIC in each database. Careful attention must be paid to ensure that these permissions have been removed from PUBLIC.

Jobs can be used to automate administrative procedures as well as T-SQL procedures. CmdExec and Active Scripting job steps issue or can issue operating system commands and shall be restricted to use by DBAs. Access to the host operating system poses a security risk.

Application user database accounts, application administrator accounts, application developer accounts, or application roles shall not have the grant option of any object privilege. PUBLIC and GUEST shall not have the grant option of any object privilege.

SQL Server automatically listens on all net-libraries installed on the server.

The DBA shall restrict Installed libraries to only those necessary to provide access to the intended client base. Where available, the Multi-Protocol net-library, is the most secure protocol without the availability of Kerberos in a Windows 2000 Active Directory environment as it allows for encryption of all network communications and shall be used by the DBA.

The DBA shall ensure that SQL Server executables are created with specific system permissions in accordance with the requirements in Sections C.3.14.1 to C.3.14.2 below. These permissions are critical to the correct operation of the software. Likewise, file ownership is designed to run as it is installed and should not be modified.

All directories that are created as the result of an installation of SQL Server, including file permissions and groups, shall not be modified to be more permissive from the initial installation. The SQL Server software owner shall own all directories and files created by the installation of SQL Server. These files are located in the root directory on the server and include executable, parameter, and datafiles. Changing the permission or ownership values may impact the operation of the SQL Server software. These files should be secured by using access control methods native to the operating system.

Windows Registry keys pertaining to the SQL Server shall be protected in accordance with the Windows NT/2000/XP Addendum and according to the following specifications:

Logon audit data is stored in both the Windows event log as well as the SQL Server 2000 error log. Logon auditing is configured at the SQL Server configuration level. The SQL Server logon audit level shall be set to Failure or ALL to record unsuccessful logon attempts at a minimum. Event auditing may be turned on by setting the C2 trace flag or by defining a trace using SQL Profiler and configuring it for autostart. The C2 flag setting ensures that all required event auditing is set and that event auditing begins at database startup. This section describes how to configure custom event auditing on an individual database. Remember that at least the minimum level of auditing shall be enabled for every database on all machines.

If appropriate, the SQL Server auditing should be configured to direct audit trail data to protected trace files and not to the system event logs. Unlike event log data, which can be viewed by SAs, trace file data is stored in binary format and can only be read by DBAs using SQL Server stored procedures. Audit data is also stored in the SQL Server error logs.

SQL Server audit data shall be protected from loss. The audit log rollover capability shall be configured for all audit traces on the database. This capability prevents audit data from being overwritten and halts the database when there is a failure in creating a new rollover file. SQL Server and SQL Server Agent error logs should be prevented from being overwritten before they have been backed up. The default number of error logs is six. Use of the error logs should be monitored and the number of logs adjusted as necessary to prevent data loss.

Once auditing is enabled at the database level, specific auditing instructions shall be issued from a DBA account. To activate required audit options, a DBA shall enable the C2 audit option or define a trace to be run upon server startup configured with selected audit events as follows:

The DBA shall enable all auditing options presented above.

SQL Server does not supply a value based auditing capability. If value based auditing is required, the application must include this in its design. All audit data collected shall be protected by access controls and maintained according to IRM 10.8.1 and IRM 10.8.3.

The SQL Server audit trail requires periodic maintenance. The audit trail data shall be backed up and then purged routinely. The disk where the audit trail is located must be checked routinely to ensure that free space is available for the audit trail table to grow. If space is not available, then all activity upon the DBMS shall stop until space is made available by the SA. The sizing of the audit trail disk space and the maintenance of the audit trail are specific to each application.

SQL Server shall not maintain passwords. The Windows OS platform shall maintain passwords in accordance with the Windows NT/2000/XP Addendum. Logon session information is encrypted through the standard Windows logon process. This process also applies to connections for distributed/replicated SQL servers.

Replication allows for partial or full copies of the Publisher database to Subscriber databases that are maintained on remote servers. Snapshot replication updates the subscriber databases to defined points in time by applying an image of the Publisher database. Transaction replication updates the subscriber databases by applying transactions made on the Publisher database to subscriber databases. Merge replication allows updates to the subscriber databases that are applied in coordination with updates to the Publisher database.

The replication agents (Snapshot, Merge, Distribution, Log Reader, Queue Reader, and others) run under the SQL Server Agent service account. For replication purposes, this account must be a Windows domain account and, as specified earlier in this document, shall not be a local or domain administrator or system account. The replication agents connect to one or more remote servers or instances run under the security context of the SQL Server Agent service account when using trusted connections.

Permissions to support and administrate replication functions are automatically assigned to the sysadmin, db_owner, or replmonitor SQL Server roles at installation time. Replication administration permissions shall not be modified from their default assignments. Replication administration permissions shall be granted only to authorized application administrators and DBAs.

The distributor database may reside locally on the SQL Server publisher database system or on a remote server. Both publisher and subscriber databases require connections to the distributor database. All database connections for replication agents shall use Windows authentication logons. This requirement is not compatible with some replication configurations.

Snapshot folders must be stored on a protected network share. The network share may be located on the distributor database system or on another server. The snapshot folder shall be located on an explicit share and not a Windows administrative share. The snapshot folder permissions shall be set to system, administrator, OS DBA group Full Control, SQL Server Agent domain account Read, Write. Subscribers shall also be granted read permissions on the snapshot folder in a replication pull configuration.

Permissions to publications for replication are maintained in the Publication Access List (PAL). All replication agent logon accounts must have entries in the PAL in order to participate in the replication process. Therefore, the SQL Server Agent service domain account must be entered in the PAL.

All replication agents, as mentioned previously, shall use Windows authentication and run under the security context of the SQL Server Agent service Windows domain account.

Virtual Private Network (VPN) offers the most secure connection for establishing replication between databases over the Internet. Replication may also occur via a proxy server. The configuration of replication over the Internet must be in compliance with the IRS Enclave Security IRM. Care should be taken to protect the data by employing replication filters and locating the distribution database and snapshot files in protected and audited locations as appropriate.

By default, SQL Server installs software and datafiles to subdirectories under \/Program Files\/Microsoft SQL Server\/Mssql. Instance names, introduced in SQL Server 2000, must be unique to the servers running multiple instances and are limited to 16 characters.

The multiple instance capability was introduced in SQL Server 2000. This allows the naming of an instance that is reflected in the SQL Server service name, associated file directories, and registry hives. Unlike Oracle DBMS architecture, SQL Server allows only one instance for one or more databases, but allows many databases per instance.

There should be a separate datafile for each database within the instance. Datafiles associated with a database shall contain the database name or prefix identifying the database and a sequence number representing each additional datafile needed to support the database.

Following are the SQL Server datafile file types and their recommended naming conventions:

Databases shall be named in accordance with IRM 2.5.7,Data Name Standards, using a name descriptive enough to identify the function of the data contained within the database.

The system database MASTER.MDF shall be located in a separate database and should be named MASTER. The MASTER.MDF database shall reside within in its own unique datafile(s). The system database MODEL.MDF shall be located in a separate database and should be named MODEL. The MODEL.MDF database shall reside within in its own unique datafile(s). The system database MSDB.MDF shall be located in a separate database and should be named MSDB. The MSDB.MDF database shall reside within in its own unique datafile(s). The system database TEMPDB.MDF shall be located in a separate database and should be named TEMPDB. The TEMPDB.MDF database shall reside within its own unique datafile(s). Application databases shall be located in separate databases and shall reside within their own datafiles. When applicable, the database shall have Backup Transaction Log selected. NOTE: This is dependent on the database's functionality.

This section covers SQL Server configuration options that have a security impact on the database and how these parameters are required to be set. This section is not intended to cover all SQL Server configuration options.

The ALLOW UPDATES parameter specifies whether direct updates may be made to the system tables. When "allow updates" is disabled, database accounts cannot make updates to the system tables.

The C2 AUDIT MODE parameter specifies whether or not automatic auditing of security events is enabled. The C2 AUDIT MODE shall be used if a custom audit trace that meets this IRM ’s audit requirements is not defined and enabled.

The parameter REMOTE ACCESS, when set to 1, allows logons from remote servers running SQL Server. It is used with remote stored procedures and replication. For a more secure database environment, this parameter shall be set to 0 unless replication is in use on the database or the requirement is fully justified and documented in appropriate ELC documentation.

The parameter SCAN FOR STARTUP PROCS, when set to 1, sets SQL Server to scan for startup procedures at startup time. Startup procedures may be planted by intruders to take effect at the next startup time. The SCAN FOR STARTUP PROCS parameter shall be set to 0 unless fully justified and documented in appropriate ELC documentation.

Access to system-defined stored procedures, like all other database objects, shall be restricted to authorized users only. Access to object linking and embedding (OLE) stored procedures (sp_OA<name>) and registry access procedures (xp_REG<name>) shall be restricted to DBAs unless fully justified and documented in appropriate ELC documentation.

User-defined stored procedures shall be stored in encrypted format for additional protection. It is recommended that system-defined stored procedures be reviewed on a regular basis to discover if any unauthorized modifications have been made. Modification of system stored procedures is one method used by Trojan horses.

Extended stored procedures run under the host operating system with full security rights. This allows for the potential for unauthorized users to gain access to the operating system. User-defined extended stored procedures shall not be used. System-defined extended stored procedures shall be limited to use by authorized DBAs only, unless fully justified and documented with the SecSpec. Extended stored procedures that are not required shall be removed from the system. The XP_CMDSHELL extended stored procedure shall be removed from the system unless fully justified and documented with the SecSpec. This extended stored procedure provides direct access to the host operating system.

SQL Server provides the capability to encrypt stored procedures, triggers, and views. Encrypting these objects provides an extra layer for security by preventing the viewing of the source for these objects and, therefore, the underlying structure of data objects they access. While experienced hackers easily defeat the added protection of object encryption, it does prevent the revealing of unnecessary information by less sophisticated attempts. Custom and GOTS stored procedures in the database shall be encrypted.

To ensure backup file protection, access permissions to backup files shall be restricted to SAs. Restore permissions on databases shall be restricted to DBAs and database owners.

All services provide a mechanism for potential security vulnerabilities. Installed services shall be limited to those required for the operation of the SQL Server database and to those services required to support the application. By default, SQL Server requires the SQL Server database engine (MSSQLServer or MSSQL$InstanceName) and the SQL Server Agent (SQLServerAgent service). Optional SQL Server services required by the application shall be justified and documented with the SecSpec.

SQL Server provides interaction to e-mail in two ways. SQL Mail is the process used by the MSSQLServer Service. This process uses a MAPI connection to a mail host.

SQL Mail can introduce many vulnerabilities into a system. Incoming mail commands can contain malicious code or viruses.

All guidance listed in Appendix C, Microsoft SQL Server Specific Policy and Implementation, of this Database Security Technical Implementation Guide, shall be applied to the MSDE environment. The following sections C.15.1 through C.15.1.4 include MSDE specific issues and security policy changes to the Database for MSDE.

In cases where the MSDE supports distributed clients, the SecSpec shall ensure that the distributed MSDE installations are configured in compliance with the policies outlined. Otherwise, the local DBA is responsible for these configurations unless stated specifically otherwise.

MSDE shall be updated with hot fixes and service packs to address product bugs as well as to provide fixes for published security bulletins.

To protect your environment, the MSDE version shall not be an expired product.

DBAs shall review security bulletins and install appropriate hotfixes as soon as possible.

MSDE supports two choices for user authentication:

This IRM requires host-based authentication for SQL Server. There may be cases in a distributed application environment where host based security is not desirable. A shared MSDE environment must use host-based authentication. A standalone installation MSDE may use SQL Server based authentication if documented by the SecSpec. If this documentation is complete, there is also no need to maintain a DBA Windows OS Group. SQL logons should be created and added to the appropriate role. The built in SA logon shall be password protected and not used for routine DBA duties. It is the responsibility of the SecSpec to ensure that the MSDE environment for each installation is clearly understood and documented and that the DBA responsibilities for each installation of MSDE are assigned. In some cases, configuration of the MSDE is the responsibility of a workstation/application configuration support personnel. In these cases, DBA configuration responsibilities belong to that person.

Logon audit data is stored in both the Windows event log as well as the MSDE error log.

The following policy issues, which are required otherwise in this IRM, are optional within a standalone MSDE environment if documented with the SecSpec:

Microsoft SQL Server ships with two sample databases: Northwind and Pubs. These databases contain many default permissions that do not conform to policy. Additionally, sample items can be used as an entry point into systems.

Following is a list of Microsoft SQL Server components that were not researched in time for inclusion in this document. Any security considerations for these components shall be reviewed and included in an updated version of this document.

The information contained in this appendix is specific to DB2 Universal Database (UDB) Version 8 installations on Windows and UNIX servers. General DB2 concepts and requirements described in this Appendix, such as the "DB2 Database Privileges," "DB2 Object Privileges, " and "Auditing in DB2" sub-sections below, also apply to the IRS z/OS platform. See the IBM web site, http://www-306.ibm.com/software/data/db2/zos/db2zosv8.html for OS-specific guidance pertaining to DB2 version 8 on the z/OS platform.

The DBA shall verify the configuration of DB2 in accordance with the material in this appendix. DB2 is installed on several configurations of operating systems and hardware and attention to the configuration is critical to security.

The DBA shall ensure that the versions of DB2 operating in the IRS environment are supported versions. Versions that are not supported shall be upgraded to a supported version. Any expections shall be noted and reported as deviations by the DBA. The table below includes the latest Fixpaks for the supported versions and the dates of their release are listed below. The build level for the installed version is listed in the DB2 Control Center 1 Help IAbout window.

The SecSpec shall ensure that unsupported DBMS software is removed or upgraded prior to a vendor dropping support.

The SecSpec shall ensure that the site has a formal migration plan for removing or upgrading DBMS systems prior to the date the vendor drops security patch support.

The DBA shall ensure that the latest FixPak has been installed for the installed version.

The DBA shall ensure that Component Services are selected and operationalized in accordance with sections D.2.1 and D.2.2 below. Component Services are optional components that provide additional capability to administer or operate the database. Component services are listed below along with any required security configurations necessary to protect them and their access to the database. Coverage in this section applies only to DB2 UDB on UNIX/Windows/Linux platforms. Coverage for components on the z/OS platform shall be covered in a future release.

The DB2 Administration Server (DAS) provides job scheduling, remote administration of DB2 instances and databases, DB2 Discovery services, and alert notification via email and pagers to selected administrators. The SecSpec shall ensure that DAS access is available only to the DBA.

The DAS runs as a service/daemon under a dedicated OS account name on the database server. The SecSpec shall ensure that the OS privileges assigned to the DBA are only those listed in the DB2 Operating System Accounts section of this exhibit.

Privileges to administer the DAS are granted to members of the DAS administrative OS group. The default name for this group is dasadm1, but may be customized. The group name is specified to the DAS in the DAS configuration parameter dasadm_group. DAS administrative access shall be restricted to authorized DBAs.

DB2 Data Links provides DBMS access and some DBMS management capabilities to files stored locally on the database sever. Access to files registered with Data Links by users via the DB2 database is controlled by data links authorizations. Access to data links files may be controlled by data links authorizations. The data links security setting shall be set to ON to enable access control to data links files. Access to data links files via the database server OS shall be restricted to authorized users. Accounts granted access to data links directories are granted access to all files in the directory. The data links services or processes shall be granted only the privileges required by other DB2 processes as defined elsewhere in this appendix.

This section discusses DB2 authentication and authorization methods. DB2 uses OS authentication services to identify and validate users requesting access to the DB2 databases. DB2 also uses OS group membership to provide DB2 internal role-based assignment of database privileges.

DB2 does not provide an independent authentication facility. Instead, it depends upon the database host operating system to provide user authentication. The DBA shall ensure that access to a DB2 database is controlled by an approved method selected from the following potential authentication methods:

Administrative or privileged access to the database is controlled at the database server operating system level. The administrative privileges are defined for three groups and are called authorities. Below is a list of the authorities and the privileges assigned to them:

SYSADM – This authority has full privileges at both the instance and database levels to perform all activities including instance and database configuration and maintenance as well as full access to the data level including INSERT, UPDATE, DELETE on all data objects.

SYSCTRL – This authority has full privileges to maintain the instance and databases, but cannot access data. This authority also does not include the privilege to mirate a database, change instance configuration parameters, nor grant DBADM authority.

SYSMAINT – This authority has access to maintain the instance and databases, but does not include privileges to update the database, node, or distributed connection services (DCS) directory, force users off the database, create or drop a database, drop, create or alter a tablespace, or restore a new database. This privilege also does not include access to the data level.

Other authorities and privileges are defined and managed within the DB2 database.

The operating system group names may be specified within the DB2 instance configuration parameters (called database manager parameters). On Windows, the default value of NULL assigns the local Administrator group to all authority groups. On UNIX, the default value of NULL assigns the primary group of the DB2 software installation account to all authority groups.

In order to preserve separation of duty, the database manager parameters specifying the SYSADM, SYSCTRL, and SYSMAINT operating system groups shall be set to a custom group name. The SA or DBA shall create Windows groups to be used specifically for this purpose. Please see See Exhibit 10.8.4-4. for detailed configuration parameter requirements located in the DB2 Configuration Parameters section.

Please note that, on Windows systems, group membership is verified by DB2 at the domain or local level depending upon the users login. That is, if the user logs into a domain, DB2 shall search only domain groups for membership. To force DB2 to search for membership on the local machine, specify the global and/or instance registry value DB2_GRP_LOOKUP=local. This can be set using the DB2set command line utility.

The DBA shall ensure that the operating system accounts listed in this section, D.3.3, are given only those privileges and permissions required for DB2 operations of support and maintenance. The operating system privileges and permissions required are described below.

During installation, DB2 prompts for OS account names and passwords for use by the DB2 database system. The default account names are db2inst1, db2fenc1, and db2as. Default passwords are not assigned. Custom passwords must be assigned at installation time

DB2 separates database privileges into two separate types: Authorities and Privileges. Authorities are groups of privileges that allow the grantee access to certain system commands and are assigned at one time. Privileges are further divided into two types: database privileges and object privileges.

DB2 authorities are granted to users by means of operating system group membership assignment (SYSADM, SYSCTRL, SYSMAINT) and are described in detail in the DB2 Administrative OS Groups section. DB2 authorities granted to users with the DB2 GRANT command include DBADM and LOAD.

Privileges assigned by GRANT statements including all object privileges, database privileges, and the DBADM and LOAD authorities, may be granted to individual OS accounts or groups identified to the database. Both individual users accounts and groups are created on the operating system. Group membership is assigned using database server OS commands. Individual users and groups are defined separately for each DB2 database. Privileges are required to be assigned to groups to provide secure administration of privileges. However, in the case of DB2, this requires that the database server SA be responsible for defining group membership unless the DBA has SA privilege on the database server. OS Group membership for groups defined within DB2 shall be reviewed a minimum of every 30 days by the DBA or SecSpec to discover unauthorized user assignment.

The DBADM authority shall be granted only to authorized DBAs and application owner accounts. The DBADM authority includes the privileges allowing the execution of the following types of actions:

The SecSpec shall ensure that only authorized DBAs and application owner accounts are assigned the DBADM authority. The LOAD authority allows the grantee to load data in a database table to which they have been granted INSERT privileges. This authority also allows the grantee to issue QUIESCE TABLESPACES FOR TABLE, RUNSTATS, and LIST TABLESPACES commands.

The DBA shall review the DB2 Database Privileges listed here and ensure that only minimal privileges are assigned within the database. Database privileges grant the user the ability to create, modify, or drop database objects within the database. Following is the list of available database privileges:

The connect database privilege is required to allow access to the database. If the connect privilege is assigned to groups, the SA has the ability to grant connect privilege to the database by means of OS group membership assignment without approval by the DBA. In order to preserve separation of duties, connect privilege shall not be granted to groups unless justified and documented in appropriate ELC documentation.

The connect privilege is assigned to PUBLIC by default upon database creation. The connect privilege shall be revoked from PUBLIC upon database creation to prevent unauthorized access to the database. PUBLIC is also granted the CREATETAB, BINDADD, IMPLICIT_SCHEMA, USE database privileges at database creation time. These privileges should be restricted to application owner and DBA accounts. The DBA shall revoke the CREATETAB, BINDADD, IMPLICIT_SCHEMA database privileges from PUBLIC at database creation time.

The CREATE_NOT_FENCED privilege allows the grantee to create procedures or functions that are processed within the DB2 database address or memory space. Applications run inside the database process may access database resources directly and inadvertently or maliciously corrupt database files or otherwise disrupt the database. Fenced procedures run outside the database process and within the security context of the OS account specified as the Fenced User operating system account. Unfenced procedures shall not be defined within the database. The CREATE_NOT_FENCED database privilege shall not be granted to any user.

The CREATE_EXTERNAL_ROUTINE allows the grantee to define a FENCED THREADSAFE routine. FENCED_THREADSAFE routines share a single process and may inadvertently or maliciously interfere with other FENCED THREADSAFE routines sharing the process. FENCED THREADSAFE routines should be tested carefully to ensure integrity. Use of FENCED THREADSAFE routines is left to the discretion of the application designer.

The DBA shall review the DB2 Object Privileges listed here and ensure that only minimal privileges are assigned within the database. Object privileges grant the user the ability to read, add, modify, or delete data within existing database objects. Some object privileges also modify the structure of existing database objects. Following is the list of DB2 object privileges separated into those that alter object structure and those that do not. Object types accessed by these privileges are listed in parentheses.

Allow object structure alterations:

Privileges to modify data only:

Privileges that create, modify, or delete database objects constitute a change to the database design and can effect operation of the database. To protect the integrity of the database, privileges that alter data structures shall be restricted to DBAs and application object owners.

The DBA shall ensure that assignment of the following object privileges are restricted to DBAs and application object owners:

The IMPLICIT_SCHEMA database privilege allows users to create schemas implicitly by referencing an undefined schema. Whenever a schema is defined implicitly, PUBLIC is automatically granted the CREATEIN object privilege to the schema. The DBA shall ensure that PUBLIC is not granted CREATEIN object privileges within any database.

The USE privilege to tablespaces is granted automatically to PUBLIC upon tablespace creation. This privilege shall be revoked from PUBLIC in order to prevent usage of tablespace resources by unauthorized users.

When privileges are assigned with the CONTROL object privilege, several individual object privileges are granted with the WITH GRANT OPTION. The WITH GRANT OPTION allows the grantee to assign the granted privilege to other database users. Privilege assignment shall be restricted to DBAs and application object owners. The CONTROL object privilege shall not be granted to application user database accounts. Object privileges shall not be granted to application users with the WITH GRANT OPTION.

By default, PUBLIC is granted select privileges to 238 system catalog tables and views during a typical installation. These privileges should be reviewed to determine what is required by supported applications. Required permissions should be removed from PUBLIC and assigned to the appropriate application user role. At a minimum, access to the following system catalogs tables and views shall be revoked from PUBLIC:

The DBA shall revoke access from PUBLIC to the system catalog tables and views listed above.

The DBA shall ensure that creators of database objects, schemas, or tablespaces have their privileges locked when not in use for updating or maintenance. Creators of database objects, schemas, or tablespaces receive CONTROL privileges to the created object, schema, or tablespace. Control privileges include all object privileges available for that object type granted with the WITH GRANT OPTION. Creators of views only receive CONTROL privilege to the created view if they also have CONTROL on all the objects referenced in the view definition. Creation of views requires SELECT or CONTROL privileges on all the underlying tables or views.

By virtue of these implicitly assigned privileges, database object owner accounts are highly privileged accounts and shall be locked when not in use for application update or maintenance.

The DBA shall ensure that only Read and Write access is enabled to the instance owner account. DB2 does provide an audit facility to record events as they occur within the database. Auditing is configured at the instance level meaning that all configured audit events are similarly recorded for actions in all databases belonging to the instance. Audit records are stored in the db2audit.log file located in the DB2 instance/security subdirectory where the audit configuration file, db2audit.cfg, is also stored. By default, access to the audit log files is restricted to Read and Write actions by the instance owner account. These permissions are assigned at audit log file creation time.

Access to the db2audit utility used to configure auditing is restricted to users with the SYSADM authority. Auditing is not started automatically at system or instance startup. It operates independently of the other DB2 processes. The db2audit start command must be entered manually or submitted by the system. DB2 auditing shall be configured to start at system startup. The DBA shall configure audit options as follows or more inclusive:

The DBA/SA shall ensure that DB2 auditing is enabled at database server startup

The DBA/SA shall ensure that access to the db2audit.log and db2audit.cfg files is restricted to the authorized users

The DBA shall ensure that DB2 audit options are configured to the required settings or more inclusive

The DBA shall set the value of the database manager parameter auditObuCsz to 0 at the time of instance generation. The database manager parameter audit_buf_sz shall cause audit records to be written at the time of generation. A value greater than 0 indicates the number of 4KB pages that shall be used to create an internal buffer used to store audit records before writing a group of them to disk. Holding the audit records in a buffer before writing them to disk creates the potential of lost audit records during a system interruption – precisely the time when it is most advantageous to have them available. An audit_buf_sz of 0, however, can have a negative impact on system performance. It is recommended that the audit_buf_sz be set to 0.

The errortype database manager parameter shall be set to the following values with the listed result:

The DBA shall consult with the data owner to ensure the setting of the parameter complies with privacy, security classification, and other sensitivity considerations. Required auditing shall be performed by the database auditing facility or designed into the capabilities of the application used to access the data.

The DBA shall ensure that the audit-buf-sz parameter is set to 0.

The authoritative source for OS/390-specific DB2 configuration details is Chapter 18 (DB2) of the IBM Systems Standards Manual, published by the IBM Systems Software Branch (ISSB) staff of the IRS. Security-relevant portions of Chapter 18 (DB2) of the IBM Systems Standards Manual are provided here for reference.

On June 18, 2002, the PRIME Program Systems Engineering Office published the "IRS & PRIME Technical Directive 11, DB2 Naming Standards and Guidelines" . The Technical Directive applies to all IRS Modernization projects and all other projects required to comply all or in part with the IRS Enterprise Architecture. Technical Directive 11 is important for DB2 security in that it provides means of maintaining configuration management of IRS DB2 databases. The DBA shall comply with the requirements of this technical directive.

The following DB2 naming standards, as quoted from Chapter 18 of the IBM Systems Standards Manual, shall be observed:

DBAs are the only individuals authorized to bind packages and plans on the OS/390 DB2 platform. Refer to Chapter 18 of the IBM Systems Standards Manual for additional detail.

The DBA shall ensure that user written DB2 exit routines are made available to DB2 only by the following procedures:

Refer to Chapter 18 of the IBM Systems Standards Manual for additional detail.

All files and subdirectories located in the directories listed below shall have world or others permissions removed. All files and subdirectories located in instance owner account home directory shall have their ownership set to the instance owner account. All files and subdirectories located in the DAS OS account home directory shall have their ownership set to the DAS OS account. All files and subdirectories located in the DB2 fenced user OS account home directory shall have their ownership set to the DB2 fenced user OS account. These restrictions shall prevent DB2 daemons being run under the Root account and protect the files and directories by requiring discrete (group membership required) assignment of privileges for access. DB2 executable files shall not have the SUID or GUID.

Permissions to the directories cited above in D.7.2.1 can be accomplished by setting the current directory to the directory to be configured and using the following commands:

The DBA/SA shall set DB2 file and directory ownership to the DB2 instance owner, DB2 fenced user, and DAS account as appropriate.

The DBA/SA shall revoke all world privileges from DB2 files and directories.

The DBA/SA shall ensure that no DB2 executable files have the SUID or GUID bit set.

DB2 authorities and DAS administrative authority are by default granted to the UNIX db2iadm1 group. If the SYSADM, SYSCTRL, SYSMAINT, and DASADM authorities require separation for your site, custom groups shall be created and membership assigned appropriately to accommodate this.

The SA/DBA shall ensure that access to the DB2 directories Disk:\/Program Files\/ and Disk:\/DB2 is limited to Full Control permissions granted to Administrators and the DB2 software installation account, and Modify, Read & Execute, List Folder Contents, Read, and Write permissions granted to DB2 service accounts.

The SA/DBA shall ensure that access to the DB2 registry keys and values located under the registry hives HKLM\/Software\/IBM\/DB2 and (services beginning with DB2) is limited to Read and Full Control permissions granted to Administrators, the DB2 software installation account, and DB2 service accounts.

DB2 authorities and DAS administrative authority are by default granted to the Windows Administrators group. If the SYSADM, SYSCTRL, SYSMAINT, and DASADM authorities require separation for your site, custom groups must be created and membership assigned appropriately to accommodate this.

DB2 configuration parameters are used to define or manage DB2 use of server resources as well as determine operation of the instance and databases. Parameter values cannot be modified directly. The DBA shall ensure that DB2 configuration parameters are defined or modified using the DB2 Control Center, the Command Line Processor (CLP) utility, Application Programming Interfaces (API’s), used via custom programs to modify the parameter values, or using the DB2 Configuration Assistant.

The Database Manager configuration parameters configure a DB2 instance. These parameters primarily affect system resources allocated to the DB2 instance. The parameter values are stored in the db2systm file that is found in the /sqllib subdirectory for the instance in UNIX and in the \/sqllib\/<instance-name> directory in Windows where instance-name is the name of the instance. On either system, if the DB2INSTPROF environment variable is set, the database manager configuration file is found in the directory named by that environment variable. The following parameters affect the security posture of the DB2 instance. The DBA shall ensure that the database manager configuration parameters are defined in accordance with this section, D.8.1, for each instance of the database server.

The DBA shall ensure that the audit-buf-sz parameter is set to 0. When set to 0, audit records are written as soon as they are generated. Setting this value to other than 0 allows the audit records to be cached in a buffer to be written at a more optimized performance time. Setting the value to 0 potentially decreases database performance.

The smp_log_path parameter is used to specify alternate locations for log files generated by the Sync Point Manager (SPM). Access to the SPM log file directories shall be restricted to authorized users. The default spm_log_file directory is /sqllib/spmlog.

The DBA shall ensure that access to the directory specified by the smp_log_path parameter is restricted to SAs, DBAs, the DB2 software installation account, and DB2 service/daemon accounts.

Data Links provides access to external host files. If set to YES, then Data Links are supported on the database. If not required, Data Links shall be disabled on the database.

The DBA shall set the datalinks value to NO unless Data Links are required by a database application.

This parameter is used to enable or disable the DB2 client’s method for determining access to DB2 information on the local or remote instances/databases. Setting this value to ENABLE allows the client to send broadcast requests on the network for response by any available DB2 servers on the server that are configured to respond. A response to a discovery request contains information on all instances and databases on the server. This could lead to unauthorized access attempts to a remote instance or database. While less convenient, clients and other servers should be required to have connection information manually defined for them or use LDAP for retrieving database catalog information. The DBA shall ensure the discover parameter value is set to DISABLE.

This parameter is used to define the communications protocols on which discovery searches are listened for and responded to. The discovery service should be disabled to protect the database server from unauthorized access attempts. The DBA shall ensure the discover_comm parameter value shall be set to DISABLE.

The DBA shall ensure that the discover_comm parameter is set to DISABLE.

This parameter is used to enable or disable the database server’s response to discovery requests by this instance. A response to a discovery request contains information on all instances and databases on the server. This could lead to unauthorized access attempts to the instance and databases. While less convenient, clients and other servers should be required to have connection information manually defined for them or use LDAP for retrieving database catalog information. The DBA shall ensure that the discover_inst parameter value is set to DISABLE.he DBA shall ensure that the discover_inst parameter is set to DISABLE.

The diaglevel parameter determines what diagnostic messages are written to the db2diag.log file. Aside from assisting in regular database server maintenance, these messages may indicate possible security breaches or unauthorized access attempts. When using diagnostic messages for a security investigation, the DBA shall set the following values to capture the types of diagnostic messages indicated:

The diagpath parameter value defines the directory path where the db2diag file containing the diagnostic messages generated by the database server is written. The path should specify a protected directory on the host system. If no path is specified, the sqllib\/<instance-name> is used for Windows and the sqllib/db2dump directory is used for UNIX. Access to the directory path specified in the diagpath parameter shall be restricted to authorized users.

The DBA shall ensure that access to the directory specified in the diagpath parameter is restricted to SAs, DBAs, the DB2 software installation account, and DB2 service/daemon accounts.

The notifylevel parameter indicates the types of notify messages written to the notification file. On Windows, notification messages are written to the Event Logs. On UNIX, notifications are written to the instance.nfy text file. The levels and corresponding types of messages captured are listed below:

The setting specified indicates that all messages of a lower value shall also be written to the notification file. Notification messages, in addition to providing database server status, may also indicate possible security breaches. The DBA shall ensure that the notifylevel is set to a minimum value of 3.

This parameter, when set to a value of YES, indicates that the instance supports requests to remote databases in a distributed environment. Access to remote databases initiated by the local database requires special security considerations. If use of federated databases is not required, the federated parameter shall be set to NO. If required, this requirement shall be documented with the SecSpec.

The DBA shall ensure that the federated parameter is set to a value of NO unless required and documented with the SecSpec.

This parameter specifies the operating system group name assigned sysadm authority within the instance. By default, this group is set to NULL. On a Windows platform, a null value defaults to assignment of sysadm authority to the local administrator group. On UNIX platforms, a null value assigns sysadm authority to the primary group of the DB2 software owner/installer account. Separation of duties is promoted on a Windows platform by reassigning the sysadm group value to a custom created group. On a Windows platform the sysadm_group parameter shall not be NULL. On a Windows platform, the sysadm_group parameter shall be assigned to a custom group.

The DBA shall assign the name of a custom local group to the sysadm_group parameter on a Windows platform.

This parameter specifies the operating system group name assigned sysctrl authority within the instance. By default, this group is set to NULL. On a Windows platforms, a null value defaults to assignment of sysctrl authority to the local administrator group. On UNIX platforms, a null value assigns sysadm authority to the primary group of the DB2 software owner/installer account. Separation of duties is promoted on a Windows platform by reassigning the sysctrl group value to a custom created group. On a Windows platform the sysadm_group parameter shall not be NULL. On a Windows platform, the sysctrl_group parameter shall be assigned to a custom group.

This parameter specifies the operating system group name assigned sysmaint authority within the instance. By default, this group is set to NULL. On a Windows platforms, a null value defaults to assignment of sysmaint authority to the local administrator group. On UNIX platforms, a null value assigns sysmaint authority to the primary group of the DB2 software owner/installer account. Separation of duties is promoted on a Windows platform by reassigning the sysmaint group value to a custom created group. On a Windows platform the sysmaint_group parameter shall not be NULL. On a Windows platform, the sysmaint_group parameter shall be assigned to a custom group.

The authentication type parameter defines the method of authentication used to connect users to the database. Available options are SERVER, SERVER_ENCRYPT, CLIENT, KERBEROS, and KRB_SERVER_ENCRYPT. For a more in-depth discussion on the requirements of this parameter, please see See Exhibit 10.8.4-4. the DB2 Authentication exhibit in this IRM. To protect passwords from being sent in clear text within a database connection request, the authentication parameter shall be set to SERVER_ENCRYPT, KERBEROS, or KRB_SERVER_ENCRYPT.

This parameter allows users to connect to the database if they have already authenticated to SNA. This requires that they be using the SNA protocol to communicate to the database. Use of this authentication mode requires that the instance authentication mode be set to SERVER. Since an authentication mode of SERVER allows passwords to be transmitted across the network in clear text, the SNA authentication shall not be used.

The DBA shall ensure that the sna_auth parameter value is set to NO.

The fed_noauth enables or disables the requirement to authenticate to the instance when the federated parameter is enabled and the authentication mode is either SERVER or SERVER_ENCRYPT. The fed_noauth shall be set to NO.

The catalog_noauth parameter when set to YES or 1 allows users without SYSADM authority to catalog databases. Unauthorized changes to the database catalogs could result in errors in access to local and remote databases. The catalog_noauth parameter shall be set to NO or 0.

The DBA shall ensure that the catalog_noauth parameter is set to No or 0.

The value of dftdbpath parameter determines the default file storage location of newly created databases. Access to the path indicated by this parameter shall be restricted to authorized users.

The DBA shall ensure that access to the path indicated in the dftdbpath parameter is restricted to SAs, DBAs, the DB2 software installation account, and DB2 service/daemon accounts.

The DBA shall ensure that access to the path indicated in the dftdbpath parameter is a valid path on the server operating system.

This parameter is used in conjunction with an authentication mode of CLIENT to allow or disallow all clients to be authenticated at the client operating system for DB2 access. This parameter is only effective when the authentication mode is set to CLIENT. Since the requirement for authentication mode is that it be set to a value other than CLIENT, the value of this parameter must be left to YES.

This parameter specifies whether trusted clients are authenticated at the client or at the server. This parameter is not considered unless the authentication mode is CLIENT. If the client presents a username and password when a database connection is requested and the trust_clnauth parameter is set to SERVER, then the client shall be authenticated by the server. Since the requirement for authentication mode is that it be set to a value other than SERVER, the value of this parameter must be left to CLIENT.

Database configuration parameters configure a single DB2 database within an instance. Each database has its own database configuration file named SQLDBCON that stores the values assigned for each parameter. The SQLDBCON file is stored with other database control files in the SQLnnnn subdirectory where nnnn is the number assigned to the database at database creation time. This directory is found under the \/DB2 directory in Windows and the /home/db2inst1/dbinst1 directory under UNIX. If the database is partitioned, a SQLDBCON file is created for each partition. Like the database manager configuration file, the SQLDBCON file cannot be edited directly. The database parameters listed below affect the security posture of the database. These database parameters must be defined as required for each database on the database server.

This parameter is not configurable, but is used to store the value for the current path of the log files. It can be changed only after the new value specified in the newlogpath parameter takes effect. By default, log files are stored in the SQLOGDIR under the database directory. In addition to log files being necessary to recover a database after an uncontrolled shutdown, for example, a disk or power failure, log files may include sensitive information. The directory specified in the logpath parameter shall be a protected directory. For UNIX, access to the logpath directory shall be restricted to 750 or more restrictive. For Windows, access to the logpath directory shall be restricted to Administrators, SYSADMS, and the DB2 service account.

This parameter is also not configurable, but instead stores the name of the log file currently in use. Log files, in addition to being required to recovery a database after an uncontrolled shutdown, may contain sensitive information. Access to log files shall be restricted to authorized users.

The newlogpath parameter is used to store the path where the log files shall be stored upon next database restart. Access to the directory specified in the newlogpath directory shall be restricted to authorized users.

The mirrorlogpath specifies a directory where a mirror copy of the log file is written. Specifying a directory on a separate physical disk ensures that recovery of the database to a point in time can be made after a disk failure that houses the logpath directory is lost. The mirrorlogpath parameter shall specify a directory on a physical disk separate from the logpath directory unless the logpath directory is already housed on a mirrored or RAID 5 disk. The mirrorlogpath, if specified, shall be restricted to authorized users.

The overflowlogpath parameter specifies a directory path for storage of log files used for a ROLLFORWARD database recovery or to store active log files retrieved from the archive logs. This parameter should specify a protected directory restricted to authorized users only.

The logretain parameter specifies whether log files are retained as archive log files to be used in a database recovery operation. The DBA shall set this value to RECOVERY to enable log file retention unless the SecSpec approves recovery only to the time of the last full database backup. Retaining log files is appropriate for dynamic data that is modified on a frequent basis. For databases housing only static copies of data, this capability may be unnecessary and the parameter value may be set to NO.

The userexit parameter that has the same effect as the logretain parameter and to be effective both must be set.

The userexit parameter is used to specify whether log retention is enabled. The value may be set to YES or NO. When set to YES, regardless of the logretain setting (see See Exhibit 10.8.4-4. D.8.2.6, Logretain - Log Retention Logging), log retention is enabled. The userexit parameter shall be set to YES unless the SecSpec approves no log retention.

This parameter is used to store the password for the Tivoli Storage Manager (TSM). The password is displayed in clear text upon entry and is stored encrypted in the configuration file. There are no password management features such as complexity or length requirements for the password. The DBA shall ensure that the value entered for tsm_password follows all possible IRS password requirements.

This parameter is used to enable or disable the database’s response to Discovery requests. A response to a discovery request contains information on all instances and databases on the server. This could lead to unauthorized access attempts to the instance and databases. While less convenient, clients and other servers should be required to have connection information manually defined for them or use LDAP for retrieving database catalog information. The discover_db parameter value shall be set to DISABLE.

The DB2 Administration Server (DAS) provides administrative access to the DB2 instances and databases on the local server. Only one DAS is defined per server. The configuration parameters below provide enhanced security to the DB2 instances and databases accessed by the DAS.

The discover parameter value determines the how the DAS responds to discovery requests issued by DB2 clients. When set to SEARCH, the DAS responds to SEARCH and KNOWN requests issued by DB2 clients by providing all information about instances and databases available on its local database server. When set to KNOWN, the DAS provides the local instance and databases only when a KNOWN discovery request is received from a client. A KNOWN request indicates that the client was configured with connection information for a specific DB2 instance and/or databases. When set to DISABLE, the DAS ignores discovery requests. The DISABLE setting helps to protect the local instances and databases from unauthorized access attempts. Discovery is only available when the DAS is configured for TCP/IP communication.

This parameter defines the database server OS group name granted DAS administrative authority (DASADM). When set to NULL on a Windows server, the local Administrators group is used. When set to NULL on a UNIX server, the primary group assigned to the DB2 instance account is used. To maintain separation of duties, a custom group shall be assigned to the dasadm_group Parameter

The exec_exp_task parameter defines whether the DAS executes upon startup any tasks found in the task scheduler that have passed their scheduled start time. To protect against unauthorized tasks being run upon startup of the DAS, this parameter shall be set to NO. This setting requires that the task schedule be reviewed upon startup and authorized tasks manually started after a DAS restart.

The sched_userid names the userid used to connect to by the DAS to connect to a remote tools database that stores the DAS schedule data. This parameter is only referenced if the tools database is remote to the DAS server. If this parameter is required, access to the userid specified should be restricted to the DAS server. The userid specified in the sched_userid parameter shall be restricted to authorized DAS use.

Like the database manager authentication mode, the DAS authentication parameter specifies the accepted authentication modes for accessing the DB2 database. Both available authentication modes for the DAS, SERVER_ENCRYPT and KERBEROS_ENCRYPT, encrypt passwords transmitted over the network.

DB2 UDB Version 8.1 offers no network communication encryption services. This function shall be available in the ″Stinger″ version of DB2 that has not yet been released for production as of the date of this IRM. Database communications requiring encryption must be configured to use VPN or some other method available via the network or database server operating system.

Replication supports multiple copies of database objects on remote databases. This requires that databases participating in replication authenticate to remote databases to receive or share copies of database objects with the remote databases. These activities are accomplished using standard database client to server connections using the authentication mode defined for the database. A single OS account shall be used to support replication connections.

To check the database version:

See http://otn.oracle.com/deploy/security/alerts.htm for a list of current security alerts and patches required to resolve associated vulnerabilities.

Install available patches according to patch instructions.

Using any text editor, edit the .ORA file usually located at ORACLE_BASE\/admin\/<dobbins>/INIT<SID>.ORA file.

Add or edit to include the following lines:

Use OS file permissions to protect the directories. Permissions require that the Oracle process have permissions or privileges to write to files and change permissions on files in the directory. Only SAs and DBAs should have full permissions to the directory. Please note that all database accounts have read and write access from within the database to all files in the UTL_FILE_DIR directory by virtue of the Oracle process OS permissions.

Stop and restart the database after these parameters have been set.

From the Windows desktop:

Use REGEDT32 to verify the value for the key that specified use of the Windows domain to identify OS-authenticated database accounts is set to TRUE.

From REGEDT32:

If a REMOTE_LOGIN_PASSWORDFILE is in use (=EXCLUSIVE), then list database accounts assigned SYSDBA and SYSOPER database privileges and review for appropriate authorization as follows:

To revoke SYSDBA or SYSOPER from unauthorized database accounts:

If a REMOTE_LOGIN_PASSWORDFILE is NOT in use, the SYSDBA and SYSOPER are being authorized by virtue of membership to an OS Group. Consult the installation guide for your version and platform to determine the name of the OS Groups. Review memberships for authorized OS accounts.

Review the status of Oracle default accounts. Only accounts required for daily operation should be Open. All other accounts should be removed if possible or locked and/or expired. Following is a list of Oracle recommended status for default accounts.

From SQLPLUS, enter:

Change any and all default passwords. Following is a list of many default accounts created during the installation of an Oracle database. If the following default accounts or any others exist in your database, change their passwords immediately:

From DBA Studio or Security Manager:

From SQLPLUS:

The SYS password may also be set with the ORAPWD utility. To enable authentication of an administrative user using password file authentication you must do the following:

Demo applications should be removed from the database. The default demo accounts provided during installation of the database include SQL scripts to remove them. Following is a partial list of these demo applications and the scripts to remove them. The scripts may be found in the ORACLE_HOME/demo/schema/demo_name directory.

Other demo applications that may be installed after database installation may be found in other $ORACLE_HOME directories. Similarly, they may also be provided with scripts to remove them. If not, then they may effectively be removed with the SQL command: drop user username cascade; where the username is the name of the account that owns the demo’s objects. The default user SCOTT must be removed in this way.

The Listener password must be set on all listeners running on the system. The password may be set either by editing it directly into the listener.ora file or by command in the LSNRCTL utility. Using the LSNRCTL enters the password in encrypted format into the listener.ora file. Because this file does contain the password, permissions to this file should be restricted and verified.

Prevent remote administration of the listener by enabling ADMIN_RESTRICTIONS in the listener.ora file. Edit the file to include the following line:

Create the password verify function (available from the IASE web site and printed below):

Assign the password verify function to the all profiles:

For a list of existing profiles:

The user profiles are used to restrict system resource uses as well as define some security parameters. The DEFAULT profile is used when no other profile is specified for the database account. The Default profile should be modified to secure database accounts that are not assigned a specific profile. Any custom profiles created in the database should also have the following the security parameters set

Using OEM/DBA Studio, select security, select profiles, and select Default. Under the general tab, enter/verify the following settings:

From SQLPLUS:

Repeat the above steps replacing DEFAULT with the target profile name for any other profiles in use within the database.

Consider defining security policy for other account profile parameters such as sessions per user. These parameters help further reduce the potential for database account compromise.

One method to accomplish database account time restrictions from within the database is to lock and unlock the target account at specified intervals using the Oracle job queue. To restrict account access this way, follow the procedures below:

Enable the database job queue by setting job_queue_processes in the init.ora file to a value greater than 0.

Create a procedure to enable/disable the target database account: Create or replace procedure restrict_db_user (usrname varchar2, onoff varchar2) as begin execute immediate ‘alter user’||usrname||’ account ‘||onoff; end;

Submit the job at 5PM to enable the account at midnight each night: Variable :jobno; Begin Dbms_job.submit (:jobno, ‘restrict_db_user(‘’joe’’,’’unlock’’);’, sysdate+(7/24), ‘sysdate + 1+(7/24)’); end; / print jobno

Submit the job at 5PM to disable the account at 1:00 am each night: Variable :jobno;

To view the jobs in the queue:

All files and directories installed by Oracle should be owned by the installation account and, for UNIX, group. On UNIX this is typically user Oracle and group OINSTALL although it is recommended by security experts that a different user name be used. One exception for this requirement is the Oracle listener, which should be changed to a different process owner account per Section B.16.1.2.1 (which, on some Unix platforms, may require changing file ownership or group membership of the listener executable).

For Windows, Oracle files and directories are typically installed and owned by the BUILTIN\/Administrators group.

For UNIX, use chmod OWNER:GROUP FILENAME. Example: chmod oracle:oinstall *

For Windows, use the Windows Explorer. Right-click on the file name, select Properties, select the Security tab, select the Advanced button under the Permissions section, select the Owner tab. Files and directories should be owned by the BUILTIN\/Administrators group.

OS file permissions are granted to individual OS accounts or OS groups. In the case of an Oracle DBMS, the OS accounts we are interested in are the Oracle installation account, the SAs, the DBAs, and the application user OS accounts. The Oracle UNIX Inventory Group or ORAINVENTORY, typically named oinstall, is the owner of the Oracle Universal Installer directory. Any accounts used to install Oracle software must be a member of this group. If system backups are performed by separately defined OS accounts, then these accounts are also included. If the application user OS accounts shall not be running the Oracle application software from the server, then they require no access rights of their own to any Oracle directories or files.

On Windows systems, Oracle is installed using the local administrator account. This account is a member of the local BUILTIN\/Administrators group on the server. The BUILTIN\/Administrators group should be listed as the owner of all Oracle software files and directories. A custom, dedicated, and restricted local administrator account should be used as the service account for all Oracle services on the host. If necessary, the account may be a Windows domain account. Under no circumstances should the account be a domain administrator account.

No OS accounts outside of these groups should have any permissions to any directories or files related to the Oracle database.

SAs/DBAs shall consult the installation guide for the version of Oracle that is being used for correct settings. These permissions are configured by default during installation. On a UNIX system, the umask must be set to 022 for the Oracle installation account during the Oracle software installation.

Verify that all oracle files have as their group the oracle dba group. Use chgrp to change group ownership of all files in the current directory:

For example, if ORACLE_HOME = /u01/app/oracle/product/9.2.0.1.0, then the directories…

If they are less restrictive then modify them with the command:

Verify that the only Oracle executables with the SETUID bit set are oracle.exe, oradism.exe, and dbsnmp.exe. If Oracle Internet Directory is in use, then oidldapd.exe also requires the SETUID bit.

Confirm that the following executables show permissions as follows:

If necessary to correct the ownership or permissions of any entries, use the following as an example:

The following Windows file permission specifications for Oracle directories and files is from the Oracle 9i Database Installation Guide Release 2 for Windows:

The $ORACLE_BASE/dbs/Orapwd<sid> file stores passwords for privileged database users in encrypted format. Restrict access to the ORAPWD<sid>.ORA file to the appropriate users.

UNIX: chmod 640 $ORACLE_HOME/dbs/ORAPWD<sid>.ora

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/dbs\/ORAPWD<sid>.ora, select Properties, Security tab, remove all access privileges except those assigned to local Administrators, and DBAs.

The $ORACLE_HOME/network/admin/listener.ora file contains the password for the Oracle listener. If the password has been defined by editing this file, the password is stored in clear text rather than in encrypted format. Restrict access to the listener.ora file to the appropriate users.

UNIX: chmod 640 $ORACLE_HOME/rdbms/admin/listener.ora

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/rdbms\/admin\/listener.ora, select Properties, Security tab, and remove all access privileges except those assigned to local Administrators, and DBAs.

The $ORACLE_HOME/network/admin/Dbsnmp_rw.ora and Dbsnmp_ro.ora files support the Oracle Intelligent Agent. They may contain the password of the DBSNMP database account if the password has been changed from the default. Restrict access to these files to the appropriate accounts.

UNIX: chmod 640 $ORACLE_HOME/rdbms/admin/dbsnmp_rw.ora

UNIX: chmod 640 $ORACLE_HOME/rdbms/admin/dbsnmp_ro.ora

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/rdbms\/admin\/dbsnmp_rw.ora, select Properties, Security tab, and remove all access privileges except those assigned to local Administrators, and DBAs.

The $ORACLE_HOME/network/admin/sqlnet.ora (and protocol.ora file for Oracle database version 8i and 8) file contains network configuration parameters for the listener. Restrict access to the sqlnet.ora file to the appropriate users.

UNIX: chmod 640 $ORACLE_HOME/rdbms/admin/sqlnet.ora

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/rdbms\/admin\/sqlnet.ora, select Properties, Security tab, and remove all access privileges except those assigned to local Administrators, and DBAs.

The $ORACLE_HOME/network/log directory contains the log files produced by the Oracle listener, the Intelligent Agent, and other network components. Restrict access to these files in this directory to the appropriate users.

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/network\/log\/listener.log, select Properties, Security tab, and remove all access privileges except those assigned to local Administrators, and DBAs.

Following is a list of possible log and trace file directories all found under ORACLE_HOME:

UNIX: chmod 640 $ORACLE_HOME/*/log-trace-directory/*.log and *.trc

WINDOWS: From Windows Explorer, right click on $ORACLE_HOME\/*\/log-tracedirectory\/*. log or *.trc, select Properties, Security tab, and remove all access privileges except those assigned to local Administrators, and DBAs.

Restrict access to the HKEY_LOCAL_MACHINE\/SOFTWARE\/ORACLE keys to Full Control to local Administrators and the Oracle DBA group. Grant only Read permissions to local groups of users that may require it. To remove/adjust permissions:

The following security steps must be completed to secure an Oracle installation on OS/390 systems. For details on completing these steps, please refer to Oracle’s Oracle9i Enterprise Edition Installation Guide Release 1 for OS/390 or Oracle’s Oracle8i Enterprise Edition for OS/390 Installation Guide.

There are three (3) types of auditable events — use of system privileges, use of object privileges, or issuance of statements. Activating some auditing options sometimes activates others. For example, the use of a system privilege requires the issuance of a system command. Auditing for use of the privilege also audits for the statement.

This IRM requires auditing of the use of all auditable system privileges.

This IRM additionally requires auditing of the SQL statements enabled by the following commands with the exceptions listed afterwards:

The following SQL statements shall disable audits set by the commands above that are not required:

The only application object auditing required is RENAME. This option must be applied by default to any newly created objects.

If application objects have already been created, then the audit rename on object statement should be issued for all application objects.

If the audit table has been created in the database, auditing for update and delete must be enabled whether or not the table is currently in use. Old records may exist or auditing could be redirected to the database tables. If you do not wish to maintain auditing on these tables, then drop the table from your database.

For an audit trail stored within the database:

For audit trails stored in external OS files, verify with the SA that these files are being audited for the same audit items as audits stored within the internal DB files.

PUBLIC is a default system role to which every database account is granted membership automatically. While convenient, use of this role to grant privileges to database accounts bypasses the responsibility to assign privileges with discrimination.

At a minimum, revoke the following:

From SQLPLUS:

For each privilege returned, issue:

The DBA shall locate and revoke any custom roles granted to PUBLIC (No roles are assigned to PUBLIC by default.).

For each role listed, issue: Revoke <role> from PUBLIC;

The DBA shall revoke custom object privileges from PUBLIC. To discover the custom privileges invoke the following code:

For each privilege returned, issue:

You shall need to connect as the user that granted the privilege in order to revoke it. DBA may create scripts to remove all default object privileges assigned to PUBLIC. This is not a current requirement, however, it may be implemented to ensure the concept of least privilege is applied to your database. Make sure that you create custom roles and assign any necessary privileges to system objects to those roles.

The UTL_FILE capability in Oracle, allows users to gain access to host system files and directories. Applications may take advantage of this capability for a variety of reasons. However, this capability may be exploited and grant unauthorized access to the host system file structure. The following SQLPlus command shall list any procedures that use this feature. Verify that any use of this package is justified.

DBA, application owner, and application administrator accounts should be the only database accounts with the privilege to assign permissions to other users. While object owners gain this privilege automatically, in a secure environment, only the DBAs carry the privilege to create objects in a production environment. Application objects are created only during application installation and maintenance operations. The following SQLPlus statements shall list all users and roles that have been assigned these administrative privileges.

Check for roles granted with the administrative option:

Check for system privileges granted with the administrative option:

Find and disable object privileges to ensure custom users/roles or PUBLIC do not have administrative privileges:

Predefined roles are those roles defined by default during an Oracle installation. Depending upon which options were selected, the list of predefined roles within an environment can vary. Default roles are assigned privileges based on Oracle’s default user group types and are not appropriate for most general application usage. For example, the CONNECT default role has the privilege to create several object types including tables, views, and database links. Custom roles should be used that limit privileges to those specifically needed for the user to perform the assigned function.

Application Administration roles are determined by the granting of create user, alter user, and drop user privileges. These roles should not be enabled by default upon connection to the database, but should be enabled/disabled as required by the application administration function.

For each role assignment returned, issue:
Alter user username default role all except role;
If the user has more than one application administration role assigned, then you shall have to remove assigned roles from default assignment and assign individually the appropriate default roles.

Efficient administration of privileges improves system security. The categorization of user privilege requirements by function and the use of roles to assign these privileges improve the efficiency of privilege administration.

Check for any system privileges assigned to non-default users and roles or PUBLIC.

System privileges should not be granted directly to any user nor should they be granted to application user roles. From the listing of users and roles produced from the following SQL statement, verify that roles granted system privileges are authorized and are not assigned directly to database accounts or PUBLIC.

Check for any object privileges granted directly to users. Object privileges should be granted to roles and the roles granted to the appropriate users. Any results of the command below indicate direct assignment of object privileges.

Review the list of GRANTEEs to see if any are not Oracle predefined accounts. For any custom accounts, connect as the grantor of the privilege and:

Revoke privilege on owner.object from username/role;

No users or roles should have the Alter or Reference privilege on any database objects.

Revoke privilege on owner.object from username/role;

Verify that users do not have access to DBA data.

Revoke privilege on owner.object from role/username;

Verify that any object owner accounts have been disabled.

Object owners are implicitly assigned special privileges to their objects by virtue of their ownership.

If the EXTPROC module is not in use, then it should be removed and/or disabled. Edit the listener.ora and tnsnames.ora files in the ORACLE_HOME/network/admin directory and remove one of the following entries from each of the configuration files (depends upon the OS and release of the Oracle Database server installed):
* icache_extproc, or
* PLSExtproc, or
* extproc

Remove the EXTPROC executable from the $ORACLE_HOME/bin directory.

To protect the listener from casual access do not use the well-known default port of 1521. To change the default port edit the LISTENER.ORA file to specify a different available port. Following is an example:
MYLISTENR =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.122.67)(PORT = 1527))
)

When the default name and port assignment for the listener are not used, then the listener must be defined in the INIT<SID>.ORA file using the LOCAL_LISTENER parameter. An example of this parameter seeing follows:
LOCAL_LISTENER= (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.122.67)(PORT = 1527))