Oracle Database 12c Security Technical Implementation Guide

U_Oracle_Database_12c_STIG_V1R11_Manual-xccdf.xml

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: [email protected]
Details

Version / Release: V1R11

Published: 2018-09-18

Updated At: 2018-11-03 13:49:04

Actions

Download

Filter

Vuln Rule Version CCI Severity Title Description
SV-75899r1_rule O121-BP-021100 CCI-000366 MEDIUM Audit trail data must be retained for at least one year. Without preservation, a complete discovery of an attack or suspicious activity may not be determined. DBMS audit data also contributes to the complete investigation of unauthorized activity and needs to be included in audit retention plans and procedures.
SV-75901r1_rule O121-BP-021200 CCI-000366 MEDIUM Access to default accounts used to support replication must be restricted to authorized DBAs. Replication database accounts are used for database connections between databases. Replication requires the configuration of these accounts using the same username and password on all databases participating in the replication. Replication connections use fixed user database links. This means that access to the replication account on one server provides access to the other servers participating in the replication. Granting unauthorized access to the replication account provides unauthorized and privileged access to all databases participating in the replication group.
SV-75903r1_rule O121-BP-021300 CCI-000366 MEDIUM Oracle instance names must not contain Oracle version numbers. Service names may be discovered by unauthenticated users. If the service name includes version numbers or other database product information, a malicious user may use that information to develop a targeted attack.
SV-75905r2_rule O121-BP-021400 CCI-000366 MEDIUM Fixed user and public database links must be authorized for use. Database links define connections that may be used by the local database to access remote Oracle databases. These links provide a means for a compromise to the local database to spread to remote databases in the distributed database environment. Limiting or eliminating use of database links where they are not required to support the operational system can help isolate compromises to the local or a limited number of databases.
SV-75907r3_rule O121-BP-021500 CCI-000366 LOW A minimum of two Oracle control files must be defined and configured to be stored on separate, archived disks (physical or virtual) or archived partitions on a RAID device. Oracle control files are used to store information critical to Oracle database integrity. Oracle uses these files to maintain time synchronization of database files as well as at system startup to verify the validity of system data and log files. Loss of access to the control files can affect database availability, integrity and recovery.
SV-75909r1_rule O121-BP-021600 CCI-000366 MEDIUM A minimum of two Oracle redo log groups/files must be defined and configured to be stored on separate, archived physical disks or archived directories on a RAID device. The Oracle redo log files store the detailed information on changes made to the database. This information is critical to database recovery in case of a database failure.
SV-75911r2_rule O121-BP-021700 CCI-000366 MEDIUM The Oracle WITH GRANT OPTION privilege must not be granted to non-DBA or non-Application administrator user accounts. An account permission to grant privileges within the database is an administrative function. Minimizing the number and privileges of administrative accounts reduces the chances of privileged account exploitation. Application user accounts must never require WITH GRANT OPTION privileges since, by definition, they require only privileges to execute procedures or view / edit data.
SV-75915r1_rule O121-BP-021900 CCI-000366 HIGH The Oracle REMOTE_OS_AUTHENT parameter must be set to FALSE. Setting this value to TRUE allows operating system authentication over an unsecured connection. Trusting remote operating systems can allow a user to impersonate another operating system user and connect to the database without having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only information a remote user needs to connect to the database is the name of any user whose account is setup to be authenticated by the operating system.
SV-75917r1_rule O121-BP-022000 CCI-000366 HIGH The Oracle REMOTE_OS_ROLES parameter must be set to FALSE. Setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles. The default value of FALSE causes roles to be identified and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user could impersonate another operating system user over a network connection.
SV-75919r1_rule O121-BP-022100 CCI-000366 MEDIUM The Oracle SQL92_SECURITY parameter must be set to TRUE. The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges are required to execute an update or delete that references table column values. If this option is disabled (set to FALSE), the UPDATE privilege can be used to determine values that should require SELECT privileges. The SQL92_SECURITY setting of TRUE prevents the exploitation of user credentials with only DELETE or UPDATE privileges on a table from being able to derive column values in that table by performing a series of update/delete statements using a where clause, and rolling back the change. In the following example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on the scott.emp table is able to derive that there is one employee with a salary greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from attempting to derive a value. SQL92_SECURITY = FALSE SQL> delete from scott.emp where sal > 3000; 1 row deleted SQL> rollback; Rollback complete SQL92_SECURITY = TRUE SQL> delete from scott.emp where sal > 3000; delete from scott.emp where sal > 3000 * ERROR at line 1: ORA-01031: insufficient privileges
SV-75921r2_rule O121-BP-022200 CCI-000366 MEDIUM The Oracle REMOTE_LOGIN_PASSWORDFILE parameter must be set to EXCLUSIVE or NONE. The REMOTE_LOGIN_PASSWORDFILE setting of "NONE" disallows remote administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of "EXCLUSIVE" allows for auditing of individual DBA logons to the SYS account. If not set to "EXCLUSIVE", remote connections to the database as "internal" or "as SYSDBA" are not logged to an individual account.
SV-75923r3_rule O121-BP-022300 CCI-000366 MEDIUM System privileges granted using the WITH ADMIN OPTION must not be granted to unauthorized user accounts. The WITH ADMIN OPTION allows the grantee to grant a privilege to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBAs, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.
SV-75925r1_rule O121-BP-022400 CCI-000366 MEDIUM System Privileges must not be granted to PUBLIC. System privileges can be granted to users and roles and to the user group PUBLIC. All privileges granted to PUBLIC are accessible to every user in the database. Many of these privileges convey considerable authority over the database and should be granted only to those persons responsible for administering the database. In general, these privileges should be granted to roles and then the appropriate roles should be granted to users. System privileges must never be granted to PUBLIC as this could allow users to compromise the database.
SV-75927r3_rule O121-BP-022500 CCI-000366 MEDIUM Oracle roles granted using the WITH ADMIN OPTION must not be granted to unauthorized accounts. The WITH ADMIN OPTION allows the grantee to grant a role to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBAs, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.
SV-75929r3_rule O121-BP-022600 CCI-000366 MEDIUM Object permissions granted to PUBLIC must be restricted. Permissions on objects may be granted to the user group PUBLIC. Because every database user is a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the database access to that object. In a secure environment, granting object permissions to PUBLIC must be restricted to those objects that all users are allowed to access. The policy does not require object permissions assigned to PUBLIC by the installation of Oracle Database server components be revoked.
SV-75931r2_rule O121-BP-022700 CCI-000366 HIGH The Oracle Listener must be configured to require administration authentication. Oracle listener authentication helps prevent unauthorized administration of the Oracle listener. Unauthorized administration of the listener could lead to DoS exploits; loss of connection audit data, unauthorized reconfiguration or other unauthorized access. This is a Category I finding because privileged access to the listener is not restricted to authorized users. Unauthorized access can result in stopping of the listener (DoS) and overwriting of listener audit logs.
SV-75933r1_rule O121-BP-022800 CCI-000366 MEDIUM Application role permissions must not be assigned to the Oracle PUBLIC role. Permissions granted to PUBLIC are granted to all users of the database. Custom roles must be used to assign application permissions to functional groups of application users. The installation of Oracle does not assign role permissions to PUBLIC.
SV-75935r2_rule O121-BP-022900 CCI-000366 MEDIUM Oracle application administration roles must be disabled if not required and authorized. Application administration roles, which are assigned system or elevated application object privileges, must be protected from default activation. Application administration roles are determined by system privilege assignment (create / alter / drop user) and application user role ADMIN OPTION privileges.
SV-75937r2_rule O121-BP-023000 CCI-000366 MEDIUM Connections by mid-tier web and application systems to the Oracle DBMS from a DMZ or external network must be encrypted. Multi-tier systems may be configured with the database and connecting middle-tier system located on an internal network, with the database located on an internal network behind a firewall and the middle-tier system located in a DMZ. In cases where either or both systems are located in the DMZ (or on networks external to DoD), network communications between the systems must be encrypted.
SV-75939r3_rule O121-BP-023100 CCI-000366 MEDIUM Database job/batch queues must be reviewed regularly to detect unauthorized database job submissions. Unauthorized users may bypass security mechanisms by submitting jobs to job queues managed by the database to be run under a more privileged security context of the database or host system. These queues must be monitored regularly to detect any such unauthorized job submissions.
SV-75941r1_rule O121-BP-023200 CCI-000366 MEDIUM Unauthorized database links must not be defined and active. DBMS links provide a communication and data transfer path definition between two databases that may be used by malicious users to discover and obtain unauthorized access to remote systems. Database links between production and development DBMSs provide a means for developers to access production data not authorized for their access or to introduce untested or unauthorized applications to the production database. Only protected, controlled, and authorized downloads of any production data to use for development may be allowed. Only applications that have completed the configuration management process may be introduced by the application object owner account to the production system.
SV-75943r2_rule O121-BP-023300 CCI-000366 MEDIUM Sensitive information from production database exports must be modified before import to a development database. Data export from production databases may include sensitive data. Application developers do not have a need to know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure. See DODD 8500.1 for a definition of Sensitive Information.
SV-75945r1_rule O121-BP-023400 CCI-000366 MEDIUM Application user privilege assignment must be reviewed monthly or more frequently to ensure compliance with least privilege and documented policy. Users granted privileges not required to perform their assigned functions are able to make unauthorized modifications to the production data or database. Monthly or more frequent periodic review of privilege assignments assures that organizational and/or functional changes are reflected appropriately.
SV-75947r1_rule O121-BP-023500 CCI-000366 MEDIUM Audit trail data must be reviewed daily or more frequently. Review of audit trail data provides a means for detection of unauthorized access or attempted access. Frequent and regularly scheduled reviews ensure that such access is discovered in a timely manner.
SV-75949r2_rule O121-BP-023600 CCI-000366 MEDIUM Only authorized system accounts must have the SYSTEM tablespace specified as the default tablespace. The Oracle SYSTEM tablespace is used by the database to store all DBMS system objects. Other use of the system tablespace may compromise system availability and the effectiveness of host system access controls to the tablespace files.
SV-75951r3_rule O121-BP-023700 CCI-000366 MEDIUM Application owner accounts must have a dedicated application tablespace. Separation of tablespaces by application helps to protect the application from resource contention and unauthorized access that could result from storage space reuses or host system access controls. Application data must be stored separately from system and custom user-defined objects to facilitate administration and management of its data storage. The SYSTEM tablespace must never be used for application data storage in order to prevent resource contention and performance degradation.
SV-75953r1_rule O121-BP-023800 CCI-000366 MEDIUM The directories assigned to the LOG_ARCHIVE_DEST* parameters must be protected from unauthorized access. The LOG_ARCHIVE_DEST parameter is used to specify the directory to which Oracle archive logs are written. Where the DBMS availability and recovery to a specific point in time is critical, the protection of archive log files is critical. Archive log files may also contain unencrypted sensitive data. If written to an inadequately protected or invalidated directory, the archive log files may be accessed by unauthorized persons or processes.
SV-75955r1_rule O121-BP-023900 CCI-000366 MEDIUM The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to FALSE. The _TRACE_FILES_PUBLIC parameter is used to make trace files used for debugging database applications and events available to all database users. Use of this capability precludes the discrete assignment of privileges based on job function. Additionally, its use may provide access to external files and data to unauthorized users.
SV-75957r4_rule O121-BP-024000 CCI-000366 MEDIUM Application object owner accounts must be disabled when not performing installation or maintenance actions. Object ownership provides all database object permissions to the owned object. Access to the application object owner accounts requires special protection to prevent unauthorized access and use of the object ownership privileges. In addition to the high privileges to application objects assigned to this account, it is also an account that, by definition, is not accessed interactively except for application installation and maintenance. This reduced access to the account means that unauthorized access to the account could go undetected. To help protect the account, it must be enabled only when access is required.
SV-75977r1_rule O121-BP-024100 CCI-000366 MEDIUM DBMS production application and data directories must be protected from developers on shared production/development DBMS host systems. Developer roles must not be assigned DBMS administrative privileges to production DBMS application and data directories. The separation of production DBA and developer roles helps protect the production system from unauthorized, malicious or unintentional interruption due to development activities.
SV-75979r1_rule O121-BP-024200 CCI-000366 MEDIUM Use of the DBMS installation account must be logged. The DBMS installation account may be used by any authorized user to perform DBMS installation or maintenance. Without logging, accountability for actions attributed to the account is lost.
SV-75981r1_rule O121-BP-024300 CCI-000366 MEDIUM The DBMS host platform and other dependent applications must be configured in compliance with applicable STIG requirements. The security of the data stored in the DBMS is also vulnerable to attacks against the host platform, calling applications, and other application or optional components.
SV-75983r1_rule O121-BP-024400 CCI-000366 MEDIUM Remote administrative access to the database must be monitored by the ISSO or ISSM. Remote administrative access to systems provides a path for access to and exploit of DBA privileges. Where the risk has been accepted to allow remote administrative access, it is imperative to instate increased monitoring of this access to detect any abuse or compromise.
SV-75985r1_rule O121-BP-024500 CCI-000366 MEDIUM The database must not be directly accessible from public or unauthorized networks. Databases often store critical and/or sensitive information used by the organization. For this reason, databases are targeted for attacks by malicious users. Additional protections provided by network defenses that limit accessibility help protect the database and its data from unnecessary exposure and risk.
SV-75987r1_rule O121-BP-024600 CCI-000366 MEDIUM The ISSM must review changes to DBA role assignments. Unauthorized assignment of DBA privileges can lead to a compromise of DBMS integrity. Providing oversight to the authorization and assignment of privileges provides the separation of duty to support sufficient oversight.
SV-75989r1_rule O121-BP-024700 CCI-000366 MEDIUM Plans and procedures for testing DBMS installations, upgrades and patches must be defined and followed prior to production implementation. Updates and patches to existing software have the intention of improving the security or enhancing or adding features to the product. However, it is unfortunately common that updates or patches can render production systems inoperable or even introduce serious vulnerabilities. Some updates also set security configurations back to unacceptable settings that do not meet security requirements. For these reasons, it is a good practice to test updates and patches offline before introducing them in a production environment.
SV-75991r1_rule O121-BP-024800 CCI-000366 MEDIUM Procedures and restrictions for import of production data to development databases must be documented, implemented and followed. Data export from production databases may include sensitive data. Application developers may not be cleared for or have need-to-know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure.
SV-75993r1_rule O121-BP-024900 CCI-000366 MEDIUM Sensitive data stored in the database must be identified in the System Security Plan and AIS Functional Architecture documentation. A DBMS that does not have the correct confidentiality level identified or any confidentiality level assigned is not being secured at a level appropriate to the risk it poses.
SV-75997r1_rule O121-BP-025200 CCI-000366 MEDIUM Credentials stored and used by the DBMS to access remote databases or applications must be authorized and restricted to authorized users. Credentials defined for access to remote databases or applications may provide unauthorized access to additional databases and applications to unauthorized or malicious users.
SV-75999r1_rule O121-BP-025300 CCI-000366 MEDIUM The DBMS must not share a host supporting an independent security service. The Security Support Structure is a security control function or service provided by an external system or application. An example of this would be a Windows domain controller that provides identification and authentication that can be used by other systems to control access. The associated risk of a DBMS installed on a system that provides security support is significantly higher than when installed on separate systems. In cases where the DBMS is dedicated to local support of a security support function (e.g. a directory service), separation may not be possible.
SV-76001r1_rule O121-BP-025400 CCI-000366 MEDIUM Access to DBMS software files and directories must not be granted to unauthorized users. The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration or planting of operational executables. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.
SV-76003r1_rule O121-BP-025500 CCI-000366 MEDIUM Replication accounts must not be granted DBA privileges. Replication accounts may be used to access databases defined for the replication architecture. An exploit of a replication on one database could lead to the compromise of any database participating in the replication that uses the same account name and credentials. If the replication account is compromised and it has DBA privileges, the database is at additional risk to unauthorized or malicious action.
SV-76005r2_rule O121-BP-025600 CCI-000366 MEDIUM Network access to the DBMS must be restricted to authorized personnel. Restricting remote access to specific, trusted systems helps prevent access by unauthorized and potentially malicious users.
SV-76009r1_rule O121-BP-025800 CCI-000366 MEDIUM Changes to configuration options must be audited. The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of actions taken by the user SYS. The SYS user account is a shared account by definition and holds all privileges in the Oracle database. It is the account accessed by users connecting to the database with SYSDBA or SYSOPER privileges.
SV-76013r3_rule O121-BP-026000 CCI-000366 MEDIUM Remote DBMS administration must be documented and authorized or disabled. Remote administration may expose configuration and sensitive data to unauthorized viewing during transit across the network or allow unauthorized administrative access to the DBMS to remote users. For the purposes of this STIG, "Remote" means "outside the DoDIN." However, use of an approved and properly configured VPN counts as inside the DoDIN.
SV-76015r1_rule O121-BP-026100 CCI-000366 MEDIUM DBMS symmetric keys must be protected in accordance with NSA or NIST-approved key management technology or processes. Symmetric keys used for encryption protect data from unauthorized access. However, if not protected in accordance with acceptable standards, the keys themselves may be compromised and used for unauthorized data access.
SV-76017r4_rule O121-BP-026200 CCI-000366 MEDIUM Changes to DBMS security labels must be audited. Some DBMS systems provide the feature to assign security labels to data elements. If labeling is required, implementation options include the Oracle Label Security package, or a third-party product, or custom-developed functionality. The confidentiality and integrity of the data depends upon the security label assignment where this feature is in use. Changes to security label assignment may indicate suspicious activity.
SV-76019r1_rule O121-BP-026300 CCI-000366 MEDIUM Remote database or other external access must use fully-qualified names. The Oracle GLOBAL_NAMES parameter is used to set the requirement for database link names to be the same name as the remote database whose connection they define. By using the same name for both, ambiguity is avoided and unauthorized or unintended connections to remote databases are less likely.
SV-76021r2_rule O121-BP-026400 CCI-000366 MEDIUM The /diag subdirectory under the directory assigned to the DIAGNOSTIC_DEST parameter must be protected from unauthorized access. /diag indicates the directory where trace, alert, core and incident directories and files are located. The files may contain sensitive data or information that could prove useful to potential attackers.
SV-76023r1_rule O121-BP-026500 CCI-000366 MEDIUM Remote administration must be disabled for the Oracle connection manager. Remote administration provides a potential opportunity for malicious users to make unauthorized changes to the Connection Manager configuration or interrupt its service.
SV-76025r2_rule O121-BP-026600 CCI-000366 MEDIUM Network client connections must be restricted to supported versions. Unsupported Oracle network client installations may introduce vulnerabilities to the database. Restriction to use of supported versions helps to protect the database and helps to enforce newer, more robust security controls.
SV-76027r1_rule O121-C1-004500 CCI-000366 HIGH DBA OS accounts must be granted only those host system privileges necessary for the administration of the DBMS. This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. DBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.
SV-76029r2_rule O121-C1-011100 CCI-001499 HIGH Oracle software must be evaluated and patched against newly found vulnerabilities. Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be addressed expeditiously. Anytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability. Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. Unsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.
SV-76031r1_rule O121-C1-015000 CCI-000199 HIGH DBMS default accounts must be assigned custom passwords. Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. DBMS default passwords provide a commonly known and exploited means for unauthorized access to database installations.
SV-76033r3_rule O121-C1-015400 CCI-000186 HIGH The DBMS, when using PKI-based authentication, must enforce authorized access to the corresponding private key. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. All access to the private key of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to the DBMS’s private key, an attacker could gain access to the primary key and use it to impersonate the database on the network. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76035r5_rule O121-C1-019700 CCI-002421 HIGH The DBMS must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures. Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. Alternative physical protection measures include Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. Inasmuch as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS. Information in transmission is particularly vulnerable to attack. If the DBMS does not employ cryptographic mechanisms preventing unauthorized disclosure of information during transit, the information may be compromised. SHA-1 is in the process of being removed from service within the DoD and it's use is to be limited during the transition to SHA-2. Use of SHA-1 for digital signature generation is prohibited. Allowable uses during the transition include CHECKSUM usage and verification of legacy certificate signatures. SHA-1 is considered a temporary solution during legacy application transitionary periods and should not be engineered into new applications. SHA-2 is the path forward for DoD.
SV-76043r1_rule O121-C2-001600 CCI-002186 MEDIUM The DBMS must ensure remote sessions that access an organization-defined list of security functions and security-relevant information are audited. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network and system access is accomplished by leveraging common communication protocols to establish a remote connection. These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN). Neither of these internetworking mechanisms is private or secure and they do not by default restrict access to networked resources once connectivity is established. Numerous best practices are employed to protect remote connections, such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations after a security incident. When organizations define security-related application functions or security-related application information, it is incumbent upon the application providing access to that data to ensure auditing of remote connectivity to those resources occurs in support of organizational requirements Remote access to security functions (e.g., user management, audit log management, etc.) and security-relevant information requires the activity be audited by the organization. Any application providing remote access must support organizational requirements to audit access or organization-defined security functions and security-relevant information. Database security features accessed through remote methods must be audited to ensure the access is authorized and appropriate.
SV-76045r1_rule O121-C2-001700 CCI-000366 MEDIUM The DBMS must support the disabling of network protocols deemed by the organization to be nonsecure. This requirement is related to remote access, but more specifically to the networking protocols allowing systems to communicate. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Some networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols. The DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations. Applications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements. In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance. Using protocols deemed nonsecure would compromise the ability of the DBMS to operate in a secure fashion. The database must be able to disable network protocols deemed nonsecure.
SV-76047r2_rule O121-C2-001800 CCI-000015 MEDIUM The system must employ automated mechanisms for supporting Oracle user account management. A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Enterprise environments make application user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements. Databases can have large numbers of users in disparate locations and job functions. Automatic account management can help mitigate the risk of human error found in manually managing database access. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76049r2_rule O121-C2-001900 CCI-000016 MEDIUM The DBMS must provide a mechanism to automatically identify accounts designated as temporary or emergency accounts. Temporary application accounts could be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. To address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Temporary database accounts must be identified in order for the system to recognize and terminate them after a given time period. The DBMS and any administrators must have a means to recognize any temporary accounts for special handling.
SV-76051r3_rule O121-C2-002000 CCI-000016 MEDIUM The DBMS must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period. Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. To address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Temporary database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being used beyond its original purpose or timeframe.
SV-76055r2_rule O121-C2-002200 CCI-000018 MEDIUM The DBMS must automatically audit account creation. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners that they exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. However, notwithstanding how accounts are managed, Oracle auditing should always be configured to capture account creation.
SV-76059r2_rule O121-C2-002300 CCI-001403 MEDIUM The DBMS must automatically audit account modification. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leveraging complementary technology providing this capability or a combination thereof. Automated account auditing processes greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. However, notwithstanding how accounts are managed, Oracle auditing should always be configured to capture account modification.
SV-76061r4_rule O121-C2-002400 CCI-001404 MEDIUM The DBMS must automatically audit account disabling actions, to the extent such information is available. When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. However, notwithstanding how accounts are managed, Oracle auditing must always be configured to capture account-disabling actions, to the extent such information is available. Note that some Oracle architectural details limit the ability to capture this information. There is a difference between actions taken by a user that generate an audit record and actions by the database itself, which do not generate an audit record. If an account is locked because of an expiration event, it is done by the database without involving the action of a user. Failed logins are logged user interactions, but the subsequent locking of the account, although initiated by user actions, is a function of the database.
SV-76063r2_rule O121-C2-002500 CCI-001405 MEDIUM The DBMS must automatically audit account termination. When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account terminating actions and notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. However, notwithstanding how accounts are managed, Oracle auditing should always be configured to capture account termination.
SV-76065r1_rule O121-C2-002700 CCI-000213 MEDIUM The DBMS must enforce approved authorizations for logical access to the system in accordance with applicable policy. Strong access controls are critical to securing application data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by applications, when applicable, to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system. Consideration should be given to the implementation of an audited, explicit override of automated mechanisms in the event of emergencies or other serious events. If the DBMS does not follow applicable policy when approving access it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and may be in conflict with applicable policy.
SV-76067r1_rule O121-C2-003000 CCI-002165 MEDIUM The DBMS must enforce Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both, limiting propagation of access rights and including or excluding access to the granularity of a single user. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). DAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly. Data protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization. When DAC controls are employed, those controls must limit sharing to named application users, groups of users, or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user. Databases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.
SV-76069r1_rule O121-C2-003400 CCI-000366 MEDIUM DBMS processes or services must run under custom, dedicated OS accounts. Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. The DBMS must run under a custom dedicated OS account. When the DBMS is running under a shared account, users with access to that account could inadvertently or maliciously make changes to the DBMS's settings, files, or permissions.
SV-76071r1_rule O121-C2-003500 CCI-000366 MEDIUM The DBMS must restrict grants to sensitive information to authorized user roles. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Unauthorized access to sensitive data may compromise the confidentiality of personnel privacy, threaten national security, or compromise a variety of other sensitive operations. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user.
SV-76073r1_rule O121-C2-003600 CCI-000366 MEDIUM A single database connection configuration file must not be used to configure all database clients. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Many sites distribute a single client database connection configuration file to all site database users that contains network access information for all databases on the site. Such a file provides information to access databases not required by all users that may assist in unauthorized access attempts.
SV-76075r1_rule O121-C2-003700 CCI-000366 MEDIUM The DBMS must be protected from unauthorized access by developers. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Developers granted elevated database and/or operating system privileges on production databases can affect the operation and/or security of the database system. Operating system and database privileges assigned to developers on production systems must not be allowed.
SV-76077r1_rule O121-C2-003800 CCI-000366 MEDIUM The DBMS must be protected from unauthorized access by developers on shared production/development host systems. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Developers granted elevated database and/or operating system privileges on systems that support both development and production databases can affect the operation and/or security of the production database system. Operating system and database privileges assigned to developers on shared development and production systems must be restricted.
SV-76079r2_rule O121-C2-003900 CCI-000366 MEDIUM The DBMS must restrict access to system tables and other configuration information or metadata to DBAs or other authorized users. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Administrative data includes DBMS metadata and other configuration and management data. Unauthorized access to this data could result in unauthorized changes to database objects, access controls, or DBMS configuration.
SV-76081r3_rule O121-C2-004000 CCI-000366 MEDIUM Administrative privileges must be assigned to database accounts via database roles. Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Privileges granted outside the context of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.
SV-76083r2_rule O121-C2-004100 CCI-000366 MEDIUM Administrators must utilize a separate, distinct administrative account when performing administrative activities, accessing database security functions, or accessing security-relevant information. This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. When privileged activities are not separated from non-privileged activities, the database can be subject to unauthorized changes to settings and data that a standard user would not normally have access to, outside of an authorized maintenance session.
SV-76085r2_rule O121-C2-004200 CCI-000366 MEDIUM All use of privileged accounts must be audited. This is intended to limit exposure, by making it possible to trace any unauthorized access, by a privileged user account or role that has permissions on security functions or security-relevant information, to other data or functionality.
SV-76087r1_rule O121-C2-004210 CCI-000366 MEDIUM Owners of privileged accounts must use non-privileged accounts for non-administrative activities. Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts, if used for non-administration application development or application maintenance, can lead to excessive privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.
SV-76089r2_rule O121-C2-004300 CCI-000366 MEDIUM The DBA role must not be assigned excessive or unauthorized privileges. This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. Audit of privileged activity may require physical separation employing information systems on which the user does not have privileged access. To limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. If feasible, applications must provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. DBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.
SV-76091r2_rule O121-C2-004400 CCI-000366 MEDIUM OS accounts utilized to run external procedures called by the DBMS must have limited privileges. This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications. External applications called or spawned by the DBMS process may be executed under OS accounts with unnecessary privileges. This can lead to unauthorized access to OS resources and compromise of the OS, the DBMS or any other services provided by the host platform.
SV-76093r2_rule O121-C2-004900 CCI-002236 MEDIUM The DBMS must verify account lockouts persist until reset by an administrator. Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a logon attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76095r2_rule O121-C2-005000 CCI-000044 MEDIUM The DBMS must limit the number of consecutive failed logon attempts to 3. Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a logon attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. More recent brute force attacks make attempts over long periods of time to circumvent intrusion detection systems and system account lockouts based entirely on the number of failed logons that are typically reset after a successful logon. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Note also that a policy that places no limit on the length of the timeframe (for counting consecutive invalid attempts) does satisfy this requirement.
SV-76097r2_rule O121-C2-005200 CCI-000366 MEDIUM The DBMS, when the maximum number of unsuccessful logon attempts is exceeded, must automatically lock the account/node until released by an administrator. Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. To defeat these attempts, organizations define the number of times a user account may consecutively fail a logon attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76103r1_rule O121-C2-005600 CCI-001849 MEDIUM The DBMS must have its auditing configured to reduce the likelihood of storage capacity being exceeded. Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs. During the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient to meet storage requirements. Logging must be configured appropriately. If the logs generated outstrip the amount of space reserved for those logs, the system may shut down or take other measures to stop processing in order to protect transactions from continuing unlogged.
SV-76105r1_rule O121-C2-005700 CCI-001849 MEDIUM The DBMS must have allocated audit record storage capacity. Applications need to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs. During the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient to meet storage requirements. When insufficient space in directories is allocated for audit records, database audit logs can fill up and begin to overwrite earlier logs, database activity can stop altogether, or auditing could fail and crucial tracking data could be lost.
SV-76107r1_rule O121-C2-006600 CCI-002165 MEDIUM Databases utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights. Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects. When applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights. The DBMS must ensure the recipient of permissions possesses only the access intended. The database must enforce the ability to limit rights propagation if that is the intent of the grantor. If the propagation of access rights is not limited, users with rights to objects they do not own can continue to grant rights to those objects to other users without limit. This is default behavior for Oracle.
SV-76109r1_rule O121-C2-006700 CCI-002165 MEDIUM A DBMS utilizing Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user. DAC is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. Including or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single user basis. Databases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.
SV-76111r1_rule O121-C2-006800 CCI-000169 MEDIUM The DBMS must provide audit record generation capability for organization-defined auditable events within the database. Audit records can be generated from various components within the information system. (e.g., network interface, hard disk, modem, etc.). From an application perspective, certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked). Organizations define which application components shall provide auditable events. The DBMS must provide auditing for the list of events defined by the organization or risk negatively impacting forensic investigations into malicious behavior in the information system. Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked). Organizations may define the organizational personnel accountable for determining which application components shall provide auditable events. Auditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability. The Department of Defense has established the following as the minimum set of auditable events. Most can be audited via Oracle settings; some - marked here with an asterisk - cannot, and may require OS settings. - Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). - Successful and unsuccessful logon attempts, privileged activities or other system level access - Starting and ending time for user access to the system, concurrent logons from different workstations. - Successful and unsuccessful accesses to objects. - All program initiations. - *All direct access to the information system. - All account creations, modifications, disabling, and terminations. - *All kernel module loads, unloads, and restarts.
SV-76113r1_rule O121-C2-006900 CCI-000171 MEDIUM The DBMS must allow designated organizational personnel to select which auditable events are to be audited by the database. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked). If the list of auditable events is not configurable, events that should be caught by auditing may be missed. This may allow malicious activity to be overlooked.
SV-76115r3_rule O121-C2-007000 CCI-000172 MEDIUM The DBMS must generate audit records for the DoD-selected list of auditable events, to the extent such information is available. Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked). Organizations may define the organizational personnel accountable for determining which application components shall provide auditable events. Auditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability. The Department of Defense has established the following as the minimum set of auditable events. Most can be audited via Oracle settings; some - marked here with an asterisk - cannot, and may require OS settings. - Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). - Successful and unsuccessful logon attempts, privileged activities or other system level access - Starting and ending time for user access to the system, concurrent logons from different workstations. - Successful and unsuccessful accesses to objects. - All program initiations. - *All direct access to the information system. - All account creations, modifications, disabling, and terminations. - *All kernel module loads, unloads, and restarts.
SV-76117r1_rule O121-C2-007400 CCI-000130 MEDIUM The DBMS must produce audit records containing sufficient information to establish what type of events occurred. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Database software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly what actions were performed. This requires specific information regarding the event type an audit record is referring to. If event type information is not recorded and stored with the audit record, the record itself is of very limited use.
SV-76121r1_rule O121-C2-007500 CCI-000131 MEDIUM The DBMS must produce audit records containing sufficient information to establish when (date and time) the events occurred. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Database software is capable of a range of actions on data stored within the database. It's important, for accurate forensic analysis, to know exactly when specific actions were performed. This requires the date and time an audit record is referring to. If date and time information is not recorded and stored with the audit record, the record itself is of very limited use.
SV-76123r2_rule O121-C2-007600 CCI-000132 MEDIUM The DBMS must produce audit records containing sufficient information to establish where the events occurred. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.
SV-76125r1_rule O121-C2-007700 CCI-000133 MEDIUM The DBMS must produce audit records containing sufficient information to establish the sources (origins) of the events. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes, but is not limited to: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control or flow control rules invoked. Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable.
SV-76127r1_rule O121-C2-007800 CCI-000134 MEDIUM The DBMS must produce audit records containing sufficient information to establish the outcome (success or failure) of the events. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, but is not limited to: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control, or flow control rules invoked. Success and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Without knowing the outcome of audit events, it is very difficult to accurately recreate the series of events during forensic analysis.
SV-76129r1_rule O121-C2-007900 CCI-001487 MEDIUM The DBMS must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Database software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly who performed a given action. If user identification information is not recorded and stored with the audit record, the record itself is of very limited use.
SV-76131r1_rule O121-C2-008000 CCI-000135 MEDIUM The DBMS must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. In addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. An example of detailed information the organization may require in audit records is full-text recording of privileged commands or the individual identities of shared account users. Some organizations may determine that more detailed information is required for specific database event types. If this information is not available, it could negatively impact forensic investigations into user actions or other malicious events.
SV-76133r2_rule O121-C2-008200 CCI-001855 MEDIUM The DBMS itself, or the logging or alerting mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If audit log capacity were to be exceeded, then events subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity.
SV-76135r2_rule O121-C2-008300 CCI-001858 MEDIUM The system must provide a real-time alert when organization-defined audit failure events occur. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. If audit log capacity were to be exceeded, then events subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity. If Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an alert can be sent to a designated administrator.
SV-76137r2_rule O121-C2-008500 CCI-000139 MEDIUM The system must alert designated organizational officials in the event of an audit processing failure. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. If Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an alert can be sent to a designated administrator.
SV-76139r2_rule O121-C2-008900 CCI-000158 MEDIUM The system must provide the capability to automatically process audit records for events of interest based upon selectable event criteria. Before a security review, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. An audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents. It is important to recognize audit reduction does not alter original audit records. Audit reduction and reporting tools do not alter original audit records. To leverage the complete capability of audit reduction, the application must possess the ability to specify and automatically process certain event criteria that are selectable in nature. In other words, a system administrator (SA) may be performing a manual review of audit data to identify a particular problem. The SA has determined that backup activity and network connections from a particular host comprise the bulk of the events. However, these events are not related to the activity being investigated. The application must be able to automatically process these audit records for audit reduction purposes rather than making the administrator manually process them. The lack of audit reduction and reporting in a database can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed. Oracle offers the choice of storing audit data internally in database tables, or in external files. The WHERE clause in the SELECT statement provides the necessary functionality for a table-based audit. For an audit based on external files (or for a table-based audit trail archived to external files) Oracle Database does not provide tools for retrieving and managing the data once written. Therefore, an external tool is needed.
SV-76141r1_rule O121-C2-009000 CCI-000158 MEDIUM Attempts to bypass access controls must be audited. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes: timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Detection of suspicious activity, including access attempts and successful access from unexpected places, during unexpected times, or other unusual indicators can support decisions to apply countermeasures to deter an attack. Without detection, malicious activity may proceed without hindrance.
SV-76143r2_rule O121-C2-009300 CCI-000162 MEDIUM The system must protect audit information from any type of unauthorized access. If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. Additionally, applications with user interfaces to audit records must not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.
SV-76145r1_rule O121-C2-009400 CCI-000163 MEDIUM The system must protect audit information from unauthorized modification. If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Modification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.
SV-76147r1_rule O121-C2-009500 CCI-000164 MEDIUM The system must protect audit information from unauthorized deletion. If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Deletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.
SV-76149r1_rule O121-C2-009600 CCI-001493 MEDIUM The system must protect audit tools from unauthorized access. Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. If an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.
SV-76151r1_rule O121-C2-009700 CCI-001494 MEDIUM The system must protect audit tools from unauthorized modification. Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. If the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. Audit tools include, but are not limited to, OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. If an attacker were to gain access to audit tools he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.
SV-76153r1_rule O121-C2-009800 CCI-001495 MEDIUM The system must protect audit tools from unauthorized deletion. Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. If an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.
SV-76155r1_rule O121-C2-010000 CCI-001348 MEDIUM The DBMS must support the requirement to back up audit data and records onto a different system or media than the system being audited on an organization-defined frequency. Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto media separate from the system being audited on an organizational-defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained.
SV-76157r2_rule O121-C2-010100 CCI-001350 MEDIUM The DBMS must protect audit data records and integrity by using cryptographic mechanisms. Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry-established standard used to protect the integrity of audit data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. Non-repudiation protects individuals against later claims by an author of not having performed a particular action, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document.
SV-76159r1_rule O121-C2-010200 CCI-000366 MEDIUM The DBMS must protect the audit records generated, as a result of remote access to privileged accounts, and the execution of privileged functions. Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an information system which the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges. Reducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access or by using storage media that cannot be modified (e.g., write-once recording devices). If an attacker were to gain access to audit tools he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.
SV-76161r1_rule O121-C2-010300 CCI-000345 MEDIUM The DBMS must support enforcement of logical access restrictions associated with changes to the DBMS configuration and to the database itself. When dealing with access restrictions pertaining to change control, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals must be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. Modifications to the DBMS settings, the database files, database configuration files, or the underlying database application files themselves could have catastrophic consequences to the database. Modification to DBMS settings could include turning off access controls to the database, the halting of archiving, the halting of auditing, and any number of other malicious actions.
SV-76163r2_rule O121-C2-011000 CCI-001499 MEDIUM Database objects must be owned by accounts authorized for ownership. Within the database, object ownership implies full privileges to the owned object including the privilege to assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of objects can lead to unauthorized object grants and alterations, and unauthorized modifications to data. If critical tables or other objects rely on unauthorized owner accounts, these objects can be lost when an account is removed. It may be the case that there are accounts that are authorized to own synonyms, but no other objects. If this is so, it should be documented.
SV-76165r1_rule O121-C2-011400 CCI-000366 MEDIUM The DBMS must enforce requirements for remote connections to the information system. Applications that provide remote access to information systems must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Examples of policy requirements include, but are not limited to, authorizing remote access to the information system, limiting access based on authentication credentials, and monitoring for unauthorized access. If databases allowing remote connections do not enforce requirements for remote access, an attacker may gain access to the database and may, through the database, gain access to other components of the information system.
SV-76167r3_rule O121-C2-011500 CCI-000381 MEDIUM Default demonstration and sample databases, database objects, and applications must be removed. Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission. Applications must adhere to the principles of least functionality by providing only essential capabilities. Demonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system.
SV-76169r2_rule O121-C2-011600 CCI-000381 MEDIUM Unused database components, DBMS software, and database objects must be removed. Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission. Applications must adhere to the principles of least functionality by providing only essential capabilities. Demonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system. Unused and unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.
SV-76171r2_rule O121-C2-011700 CCI-000381 MEDIUM Unused database components that are integrated in the DBMS and cannot be uninstalled must be disabled. Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission. Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused, unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled.
SV-76173r1_rule O121-C2-011800 CCI-000381 MEDIUM Use of external executables must be authorized. Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission. Applications must adhere to the principles of least functionality by providing only essential capabilities. DBMS's may spawn additional external processes to execute procedures that are defined in the DBMS, but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than the DBMS and provide unauthorized access to the host system.
SV-76175r2_rule O121-C2-011810 CCI-000381 MEDIUM Access to external executables must be disabled or restricted. The Oracle external procedure capability provides use of the Oracle process account outside the operation of the DBMS process. You can use it to submit and execute applications stored externally from the database under operating system controls. The external procedure process is the subject of frequent and successful attacks as it allows unauthenticated use of the Oracle process account on the operating system. As of Oracle version 11.1, the external procedure agent may be run directly from the database and not require use of the Oracle listener. This reduces the risk of unauthorized access to the procedure from outside of the database process.
SV-76177r1_rule O121-C2-011900 CCI-000382 MEDIUM The DBMS must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services. Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Additionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services), but doing so increases risk by constraining the ability to restrict the use of functions, ports, protocols, and/or services. To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. Database Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and through the database to other components of the information system.
SV-76179r1_rule O121-C2-012000 CCI-000553 MEDIUM Recovery procedures and technical system features must exist to ensure recovery is done in a secure and verifiable manner. Application recovery and reconstitution constitutes executing an information system contingency plan comprised of activities that restore essential missions and business functions. Database management systems and transaction-based processing systems are examples of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery. A DBMS may be vulnerable to use of compromised data or other critical files during recovery. Use of compromised files could introduce maliciously altered application code, relaxed security settings or loss of data integrity. Where available, DBMS mechanisms to ensure use of only trusted files can help protect the database from this type of compromise during DBMS recovery.
SV-76183r2_rule O121-C2-012200 CCI-000535 MEDIUM Oracle must back up user-level information per a defined frequency. Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Databases that do not backup information regularly risk the loss of that information in the event of a system failure. Most databases contain functionality to allow regular backups; it is important that this functionality is enabled and configured correctly to prevent data loss.
SV-76185r1_rule O121-C2-012300 CCI-000535 MEDIUM Database backup procedures must be defined, documented, and implemented. Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Database backups provide the required means to restore databases after compromise or loss. Backups help reduce the vulnerability to unauthorized access or hardware loss.
SV-76187r1_rule O121-C2-012400 CCI-000535 MEDIUM Database recovery procedures must be developed, documented, implemented, and periodically tested. Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Problems with backup procedures or backup media may not be discovered until after a recovery is needed. Testing and verification of procedures provides the opportunity to discover oversights, conflicts, or other issues in the backup procedures or use of media designed to be used.
SV-76189r1_rule O121-C2-012500 CCI-000535 MEDIUM DBMS backup and restoration files must be protected from unauthorized access. Information system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Lost or compromised DBMS backup and restoration files may lead to not only the loss of data, but also the unauthorized access to sensitive data. Backup files need the same protections against unauthorized access when stored on backup media as when online and actively in use by the database system. In addition, the backup media needs to be protected against physical loss. Most DBMS's maintain online copies of critical control files to provide transparent or easy recovery from hard disk loss or other interruptions to database operation.
SV-76191r1_rule O121-C2-012600 CCI-000537 MEDIUM DBMS must conduct backups of system-level information per organization-defined frequency that is consistent with recovery time and recovery point objectives. Information system backup is a critical step in maintaining data assurance and availability. System-level information includes: system-state information, operating system and application software, and licenses. Backups shall be consistent with organizational recovery time and recovery point objectives. Databases that do not back up information regularly risk the loss of that information in the event of a system failure. Most databases contain functionality to allow regular backups; it is important that this functionality is enabled and configured correctly to prevent data loss.
SV-76193r2_rule O121-C2-012900 CCI-000765 MEDIUM The DBMS must use multifactor authentication for network access to privileged accounts. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). The lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76195r2_rule O121-C2-013000 CCI-000766 MEDIUM The DBMS must use multifactor authentication for network access to non-privileged accounts. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). The lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76197r2_rule O121-C2-013100 CCI-000767 MEDIUM The DBMS must use multifactor authentication for local access to privileged accounts. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. The lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76199r2_rule O121-C2-013200 CCI-000768 MEDIUM The DBMS must use multifactor authentication for local access to non-privileged accounts. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Local Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. The lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76201r1_rule O121-C2-013300 CCI-000770 MEDIUM The DBMS must ensure users are authenticated with an individual authenticator prior to using a shared authenticator. To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated. A shared authenticator is a generic account used by multiple individuals. Use of a shared authenticator alone does not uniquely identify individual users. An example of a shared authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account. For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a shared authenticator. Some applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a shared authenticator, this requirement will apply. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization. When shared accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.
SV-76203r4_rule O121-C2-013600 CCI-001941 MEDIUM The DBMS must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. Replay attacks, if successfully used against a database account, could result in unfettered access to the database settings and data. A successful replay attack against a privileged database account could result in a complete compromise of the database. Oracle Database enables you to encrypt data that is sent over a network. There is no distinction between privileged and non-privileged accounts. Encryption of network data provides data privacy so that unauthorized parties are not able to view plaintext data as it passes over the network. Oracle Database also provides protection against two forms of active attacks. Data modification attack: An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack. Replay attack: Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000. AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode. The DES algorithm uses a 56-bit key length. SHA-1 is in the process of being removed from service within the DoD and it's use is to be limited during the transition to SHA-2. Use of SHA-1 for digital signature generation is prohibited. Allowable uses during the transition include CHECKSUM usage and verification of legacy certificate signatures. SHA-1 is considered a temporary solution during legacy application transitionary periods and should not be engineered into new applications. SHA-2 is the path forward for DoD.
SV-76205r4_rule O121-C2-013700 CCI-001942 MEDIUM The DBMS must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. Replay attacks, if successfully used against a database account, could result in access to database data. A successful replay attack against a non-privileged database account could result in a compromise of data stored on the database. Oracle Database enables you to encrypt data that is sent over a network. There is no distinction between privileged and non-privileged accounts. Encryption of network data provides data privacy so that unauthorized parties are not able to view plaintext data as it passes over the network. Oracle Database also provides protection against two forms of active attacks. Data modification attack: An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack. Replay attack: Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000. AES and Triple-DES operate in outer Cipher Block Chaining (CBC) mode. The DES algorithm uses a 56-bit key length. SHA-1 is in the process of being removed from service within the DoD and it's use is to be limited during the transition to SHA-2. Use of SHA-1 for digital signature generation is prohibited. Allowable uses during the transition include CHECKSUM usage and verification of legacy certificate signatures. SHA-1 is considered a temporary solution during legacy application transitionary periods and should not be engineered into new applications. SHA-2 is the path forward for DoD.
SV-76207r2_rule O121-C2-013800 CCI-000795 MEDIUM The DBMS must disable user accounts after 35 days of inactivity. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Unused or expired DBMS accounts provide a means for undetected, unauthorized access to the database. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76209r1_rule O121-C2-013900 CCI-000205 MEDIUM The DBMS must support organizational requirements to enforce minimum password length. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Weak passwords are a primary target for attack to gain unauthorized access to databases and other systems. Where username/password is used for identification and authentication to the database, requiring the use of strong passwords can help prevent simple and more sophisticated methods for guessing at passwords. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76211r2_rule O121-C2-014000 CCI-000200 MEDIUM The DBMS must support organizational requirements to prohibit password reuse for the organization-defined number of generations. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Password reuse restrictions protect against bypass of password expiration requirements and help protect accounts from password guessing attempts. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76213r1_rule O121-C2-014100 CCI-000192 MEDIUM The DBMS must support organizational requirements to enforce password complexity by the number of upper-case characters used. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76215r1_rule O121-C2-014200 CCI-000193 MEDIUM The DBMS must support organizational requirements to enforce password complexity by the number of lower-case characters used. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76217r1_rule O121-C2-014300 CCI-000194 MEDIUM The DBMS must support organizational requirements to enforce password complexity by the number of numeric characters used. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76219r1_rule O121-C2-014400 CCI-001619 MEDIUM The DBMS must support organizational requirements to enforce password complexity by the number of special characters used. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Use of a complex password helps to increase the time and resources required to compromise the password. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76221r1_rule O121-C2-014500 CCI-000195 MEDIUM The DBMS must support organizational requirements to enforce the number of characters that get changed when passwords are changed. Passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements. Changing passwords frequently can thwart password-guessing attempts or re-establish protection of a compromised DBMS account. Minor changes to passwords may not accomplish this since password guessing may be able to continue to build on previous guesses, or the new password may be easily guessed using the old password. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76223r2_rule O121-C2-014600 CCI-000196 MEDIUM The DBMS must support organizational requirements to enforce password encryption for storage. Applications must enforce password encryption when storing passwords. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Database passwords stored in clear text are vulnerable to unauthorized disclosure. Database passwords must always be encoded or encrypted when stored internally or externally to the DBMS. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76225r1_rule O121-C2-014900 CCI-000199 MEDIUM Procedures for establishing temporary passwords that meet DoD password requirements for new accounts must be defined, documented, and implemented. Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. New accounts authenticated by passwords that are created without a password or with an easily guessed password are vulnerable to unauthorized access. Procedures for creating new accounts with passwords should include the required assignment of a temporary password to be modified by the user upon first use. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76227r3_rule O121-C2-015100 CCI-000199 MEDIUM DBMS passwords must not be stored in compiled, encoded, or encrypted batch jobs or compiled, encoded, or encrypted application source code. Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. The storage of passwords in application source or batch job code that is compiled, encoded, or encrypted prevents compliance with password expiration and other management requirements, as well as provides another means for potential discovery. This requirement applies equally to those accounts managed by Oracle and those managed and authenticated by the OS or an enterprise-wide mechanism. This requirement should not be construed as prohibiting or discouraging the encryption of source code, which remains an advisable precaution. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76229r2_rule O121-C2-015200 CCI-000199 MEDIUM The DBMS must enforce password maximum lifetime restrictions. Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. Passwords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. The “PASSWORD_LIFE_TIME” parameter defines the number of days a password remains valid. This can, but must not be, set to “UNLIMITED”. Further, the “PASSWORD_GRACE_TIME” parameter, if set to “UNLIMITED”, can nullify the “PASSWORD_LIFE_TIME”. “PASSWORD_GRACE_TIME” must be set to “0” days (or another small integer). Note: User authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
SV-76231r3_rule O121-C2-015300 CCI-000185 MEDIUM The DBMS, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be for example a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Database Management Systems that do not validate certificates to a trust anchor are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76233r2_rule O121-C2-015500 CCI-000187 MEDIUM The DBMS must map the authenticated identity to the user account using PKI-based authentication. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information. When including the DBMS in the Private Key Infrastructure, the authenticated user must map directly to a user account in the DBMS. If the user account is not directly tied to the authenticated identity, there is no way to know which, if any, database user account has been authorized. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76235r2_rule O121-C2-015501 CCI-000366 MEDIUM Processes (services, applications, etc.) that connect to the DBMS independently of individual users, must use valid, current DoD-issued PKI certificates for authentication to the DBMS. Just as individual users must be authenticated, and just as they must use PKI-based authentication, so must any processes that connect to the DBMS. The DoD standard for authentication of a process or device communicating with another process or device is the presentation of a valid, current, DoD-issued Public Key Infrastructure (PKI) certificate that has previously been verified as Trusted by an administrator of the other process or device. This applies both to processes that run on the same server as the DBMS and to processes running on other computers. The Oracle-supplied accounts, SYS, SYSBACKUP, SYSDG, and SYSKM, are exceptions. These cannot currently use certificate-based authentication. For this reason among others, use of these accounts should be restricted to where it is truly needed.
SV-76237r2_rule O121-C2-015700 CCI-000803 MEDIUM The DBMS must use NIST-validated FIPS 140-2-compliant cryptography for authentication mechanisms. Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. Applications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules. Authentication modules with weak encryption could allow an attacker to gain access to data stored in the database and to the administration settings of the DBMS.
SV-76239r1_rule O121-C2-016000 CCI-002890 MEDIUM The DBMS must employ cryptographic mechanisms to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. If the communication channel is not adequately protected authentication information, application data, and configuration information could be compromised.
SV-76241r1_rule O121-C2-016100 CCI-000877 MEDIUM The DBMS must employ strong identification and authentication techniques when establishing nonlocal maintenance and diagnostic sessions. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. If the communication channel is not adequately protected, authentication information, application data, and configuration information could be compromised.
SV-76243r2_rule O121-C2-016300 CCI-000366 MEDIUM Databases employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media. When data is written to portable digital media, such as thumb drives, floppy diskettes, compact disks, magnetic tape, etc., there is risk of data loss. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. The decision whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. When the organization has determined the risk warrants it, data written to portable digital media must be encrypted. When information written to digital media is not encrypted, it can be compromised.
SV-76245r2_rule O121-C2-016400 CCI-002262 MEDIUM The DBMS must support organizational requirements to encrypt information stored in the database and information extracted or derived from the database and stored on digital media. When data is written to digital media, such as hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and/or compromise. An organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The decision whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is commensurate with the classification and sensitivity of the information. Information at rest, when not encrypted, is open to compromise from attackers who have gained unauthorized access to the data files.
SV-76247r2_rule O121-C2-016500 CCI-001133 MEDIUM The DBMS must terminate the network connection associated with a communications session at the end of the session or 15 minutes of inactivity. Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. When applications provide a remote management capability inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed. When network connections are left open after the database session has closed, the network session is open to session hijacking. The Oracle Listener inherently meets most of this SRG requirement. When a user logs off, or times out, or encounters an unrecoverable network fault, the Oracle Listener terminates all sessions and network connections. The remaining aspect of the requirement, the timeout because of inactivity, is configurable.
SV-76249r3_rule O121-C2-016600 CCI-002450 MEDIUM The DBMS must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Use of cryptography to provide confidentiality and non-repudiation is not effective unless strong methods are employed. Many earlier encryption methods and modules have been broken and/or overtaken by increasing computing power. The NIST FIPS 140-2 cryptographic standards provide proven methods and strengths to employ cryptography effectively. Detailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html Note: this does not require that all databases be encrypted. It specifies that if encryption is required, then the implementation of the encryption must satisfy the prevailing standards.
SV-76251r1_rule O121-C2-016700 CCI-002450 MEDIUM Database data files containing sensitive information must be encrypted. Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. Data files that are not encrypted are vulnerable to theft. When data files are not encrypted they can be copied and opened on a separate system. The data can be compromised without the information owner's knowledge that the theft has even taken place.
SV-76253r1_rule O121-C2-017100 CCI-000366 MEDIUM The DBMS must protect the integrity of publicly available information and applications. The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls. Databases designed to contain publicly available information, though not concerned with confidentiality, must still maintain the integrity of the data they house. If data available to the public is not protected from unauthorized modification, then it cannot be trusted by those accessing it.
SV-76255r2_rule O121-C2-017600 CCI-001185 MEDIUM The DBMS must terminate user sessions upon user logoff or any other organization or policy-defined session termination events, such as idle time limit exceeded. This requirement focuses on communications protection at the application session, versus network packet, level. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session. Database sessions must be terminated when no longer in use in order to prevent session hijacking.
SV-76259r3_rule O121-C2-018200 CCI-001665 MEDIUM The DBMS must preserve any organization-defined system state information in the event of a system failure. Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.
SV-76261r2_rule O121-C2-018300 CCI-001199 MEDIUM The DBMS must take needed steps to protect data at rest and ensure confidentiality and integrity of application data. This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User-generated data and application specific configuration data both need to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. If the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification.
SV-76265r1_rule O121-C2-018500 CCI-001084 MEDIUM The DBMS must isolate security functions from nonsecurity functions by means of separate security domains. Security functions are defined as "the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based". Developers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles. Database Management Systems typically separate security functionality from non-security functionality via separate databases or schemas. Database objects or code implementing security functionality must not be commingled with objects or code implementing application logic. When security and non-security functionality is commingled, users who have access to non-security functionality may be able to access security functionality.
SV-76267r1_rule O121-C2-018600 CCI-001682 MEDIUM The DBMS must automatically terminate emergency accounts after an organization-defined time period for each type of account. Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left. In the event emergency application accounts are required, the application must ensure accounts that are designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. If it is possible for any temporary emergency accounts to be created and managed by Oracle, then the DBMS or application must provide or utilize a mechanism to automatically terminate such accounts after an organization-defined time period. Emergency database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being misused.
SV-76269r1_rule O121-C2-018800 CCI-001274 MEDIUM The DBMS must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications. Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application. This information can then be used for diagnostic purposes, forensics purposes, or other purposes relevant to ensuring the availability and integrity of the application. While it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner, so they are able to respond to events as they occur. Solutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications. If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability. Database management systems that do not automatically alert security personnel of unusual activities run the risk of security incidents going unnoticed for long periods of time. This can allow security breaches to be ongoing and more serious.
SV-76271r1_rule O121-C2-018900 CCI-001090 MEDIUM The DBMS must prevent unauthorized and unintended information transfer via shared system resources. The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse. Data used for the development and testing of applications often involves copying data from production. It is important that specific procedures exist for this process, so copies of sensitive data are not misplaced or left in a temporary location without the proper controls.
SV-76273r1_rule O121-C2-019100 CCI-002385 MEDIUM The DBMS must protect against or limit the effects of organization-defined types of Denial of Service (DoS) attacks. A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks. Employing increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks. Some of the ways databases can limit their exposure to DoS attacks are through limiting the number of connections that can be opened by a single user and database clustering.
SV-76275r2_rule O121-C2-019500 CCI-001310 MEDIUM The DBMS must check the validity of data inputs. Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application. All applications need to validate the data users attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76277r1_rule O121-C2-019600 CCI-002716 MEDIUM The system must verify there have not been unauthorized changes to the DBMS software and information. Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes), and to use tools to automatically monitor the integrity of the information system and the applications it hosts. The DBMS opens data files and reads configuration files at system startup, system shutdown, and during abort recovery efforts. If the DBMS does not verify the trustworthiness of these files, it is vulnerable to malicious alterations of its configuration or unauthorized replacement of data.
SV-76279r1_rule O121-C2-019800 CCI-000366 MEDIUM The DBMS must identify potentially security-relevant error conditions. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Database logs can be monitored for specific security-related errors. Any error that can have a negative effect on database security should be quickly identified and forwarded to the appropriate personnel. If security-relevant error conditions are not identified by the DBMS, they may be overlooked by the personnel responsible for addressing them.
SV-76281r2_rule O121-C2-019900 CCI-001312 MEDIUM The DBMS must only generate error messages that provide information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited. Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Sensitive information includes account numbers, social security numbers, and credit card numbers. Databases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for troubleshooting but very useful to someone targeting the system. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76283r2_rule O121-C2-020000 CCI-001314 MEDIUM The DBMS must restrict error messages so only authorized personnel may view them. If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. Some default DBMS error messages can contain information that could aid an attacker in, among others things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that error messages are displayed only to those who are authorized to view them. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76285r1_rule O121-C2-020300 CCI-001670 MEDIUM The DBMS must support taking organization-defined list of least disruptive actions to terminate suspicious events. System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action the application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system operation. In order to preserve availability, it is important for the DBMS to terminate suspicious events with the least disruptive action possible. If suspicious events are not terminated, an attacker may gain entry into the system; however, if the system overreacts to a suspicious event and takes an overly disruptive action, a Denial of Service (DoS) may occur.
SV-76287r2_rule O121-C2-020400 CCI-001683 MEDIUM The DBMS must notify appropriate individuals when accounts are created. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle. Notwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account creation within Oracle. Indeed, in a configuration where accounts are managed externally, the creation of an account within Oracle may indicate hostile activity.
SV-76289r2_rule O121-C2-020500 CCI-001684 MEDIUM The DBMS must notify appropriate individuals when accounts are modified. Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account for later use. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners that they exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle. Notwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account modification within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.
SV-76291r2_rule O121-C2-020600 CCI-001685 MEDIUM The DBMS must notify appropriate individuals when account disabling actions are taken. When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle. Notwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon the disabling of an account within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.
SV-76293r2_rule O121-C2-020700 CCI-001686 MEDIUM The DBMS must notify appropriate individuals when accounts are terminated. When application accounts are terminated, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where accounts are directly managed by Oracle. Notwithstanding how accounts are normally managed, the DBMS must support the requirement to notify appropriate individuals upon account termination within Oracle. Indeed, in a configuration where accounts are managed externally, the manipulation of an account within Oracle may indicate hostile activity.
SV-76299r3_rule O121-C3-003300 CCI-000366 LOW The DBMS must implement separation of duties through assigned information access authorizations. Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. Additionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles. Privileges granted outside the context of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.
SV-76303r1_rule O121-C3-008700 CCI-001875 LOW The system must provide an audit log reduction capability. Audit reduction is used to reduce the volume of audit records in order to facilitate manual review. Before a security review, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents. The lack of audit reduction in a database can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed.
SV-76305r4_rule O121-C3-019200 CCI-001094 LOW The DBMS must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks. When it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by DoS attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76307r3_rule O121-C3-019300 CCI-001095 LOW The DBMS must manage resources to limit the effects of information flooding types of Denial of Service (DoS) incidents. In the case of application DoS incidents, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. The methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application-related DoS incidents. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS problems. Databases are particularly susceptible to SQL-related DoS issues. Databases that do not protect against resource-intensive SQL queries may experience dramatic slowdowns from malicious attacks or accidental DoS incidents related to SQL queries. What constitutes a resource-intensive query has to be determined locally, taking into account the purpose of the database and the needs of the various classes of user.
SV-76309r2_rule O121-C3-019400 CCI-002394 LOW The DBMS must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority. Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority. The DBMS is often running queries for multiple users. If lower-priority processes are utilizing a disproportionately high amount of database resources, this can severely impact higher-priority processes.
SV-76333r2_rule O121-N1-015601 CCI-000366 HIGH Applications must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information. Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76335r2_rule O121-N1-015602 CCI-000366 HIGH When using command-line tools such as Oracle SQL*Plus, which can accept a plain-text password, users must use an alternative logon method that does not expose the password. The SRG states: "To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism." "Obfuscation of user-provided information when typed into the system is a method used in addressing this risk." "For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information." "Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing." SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot be configured not to accept a plain-text password. Since the typical SQL*Plus user is a database administrator, the consequences of password compromise are particularly serious. Therefore, the use of plain-text passwords must be prohibited, as a matter of practice and procedure. Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including 'SSL', such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
SV-76339r1_rule O121-N2-004701 CCI-000366 MEDIUM DBMS default accounts must be protected from misuse. The Security Requirements Guide says, "Default accounts are usually accounts that have special privileges required to administer the database. Well-known DBMS account names are targeted most frequently by attackers and are thus more prone to providing unauthorized access to the database. "If default account names are not changed, an attacker has a predefined list of accounts to target. Since most default accounts are administrative in nature, the compromise of a default account can have catastrophic consequences, including the complete loss of control over the information system." However, Oracle does not provide for changing user names directly. Workarounds to achieve the effect of a name change are cumbersome. In addition, names of essential system accounts such as SYS are "baked into" the product, with thousands of dependencies involved. Making such a change would risk making the DBMS inoperative, and would interfere with getting support from Oracle. The Check and Fix, therefore, relate to good practices for protecting the essential system accounts from misuse.
SV-76343r1_rule O121-N2-008601 CCI-000366 MEDIUM Disk space used by audit trail(s) must be monitored; audit records must be regularly or continuously off-loaded to a centralized log management system. It is critical when a system is at risk of failing to process audit logs as required; it detects and takes action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Applications are required to be capable of either directly performing or calling system-level functionality performing defined actions upon detection of an application audit log processing failure. The Security Requirements Guide says, "A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. The database must be capable of taking organization-defined actions to avoid either a complete halt to processing or processing transactions in an unaudited manner." This STIG requirement mandates the implementation of a method to mitigate Oracle's inability to automatically reuse audit trail space on a first-in, first-out basis.
SV-76355r2_rule O121-OS-004600 CCI-000366 HIGH Use of the DBMS software installation account must be restricted. This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications. The DBMS software installation account may require privileges not required for database administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them. This requirement is particularly important because Oracle equates the installation account with the SYS account - the super-DBA. Once logged on to the operating system, this account can connect to the database AS SYSDBA without further authentication. It is very powerful and, by virtue of not being linked to any one person, cannot be audited to the level of the individual.
SV-76357r2_rule O121-OS-010700 CCI-001499 MEDIUM Database software, applications, and configuration files must be monitored to discover unauthorized changes. Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Unmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.
SV-76359r1_rule O121-OS-011200 CCI-001499 MEDIUM The OS must limit privileges to change the DBMS software resident within software libraries (including privileged programs). When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. If the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable as in the case of interpreted languages. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.
SV-76361r1_rule O121-P2-008100 CCI-001844 MEDIUM The DBMS must provide the ability to write specified audit record content to a centralized audit log repository. Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes but is not limited: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control or flow control rules invoked. Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as, the backup and archiving of those records. When organizations define application components requiring centralized audit log management, applications need to support that requirement. Database audit records not stored in a centralized audit log management tool may be overlooked during investigation of a security incident or may be subject to intentional or accidental manipulation by privileged users of the database.
SV-76363r1_rule O121-P2-010800 CCI-001499 HIGH The DBMS software installation account must be restricted to authorized users. When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. If the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. DBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a greater impact on database security and operation. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them. This requirement is particularly important because Oracle equates the installation account with the SYS account - the super-DBA. Once logged on to the operating system, this account can connect to the database AS SYSDBA without further authentication. It is very powerful and, by virtue of not being linked to any one person, cannot be audited to the level of the individual.
SV-76365r1_rule O121-P2-010900 CCI-001499 MEDIUM Database software directories, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications. When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens and is threatened by other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.
SV-76367r1_rule O121-P2-012700 CCI-000537 MEDIUM The DBMS software libraries must be periodically backed up. Information system backup is a critical step in maintaining data assurance and availability. System-level information includes: system-state information, operating system and application software, and licenses. Backups shall be consistent with organizational recovery time and recovery point objectives. The DBMS application depends upon the availability and integrity of its software libraries. Without backups, compromise or loss of the software libraries can prevent a successful recovery of DBMS operations.
SV-76369r1_rule O121-P2-012800 CCI-000764 MEDIUM The DBMS must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication.
SV-76371r1_rule O121-P2-015800 CCI-000804 MEDIUM The DBMS must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Non-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server. Accordingly, a risk assessment is used in determining the authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.
SV-76373r1_rule O121-P2-017300 CCI-001082 MEDIUM The DBMS must separate user functionality (including user interface services) from database management functionality. Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. If administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.
SV-76375r1_rule O121-P2-017400 CCI-001083 MEDIUM The DBMS must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users. Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. If administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.
SV-76377r2_rule O121-P3-006200 CCI-000166 LOW The DBMS must protect against an individual who uses a shared account falsely denying having performed a particular action. Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. Authentication via shared accounts does not provide individual accountability for actions taken on the DBMS or data. Whenever a single database account is used to connect to the database, a secondary authentication method that provides individual accountability is required. This scenario most frequently occurs when an externally hosted application authenticates individual users to the application and the application uses a single account to retrieve or update database information on behalf of the individual users. When shared accounts are utilized without another means of identifying individual users, users may deny having performed a particular action. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
SV-76453r1_rule O121-BP-025100 CCI-000366 MEDIUM The DBMS data files, transaction logs and audit files must be stored in dedicated directories or disk partitions separate from software or other application files. Protection of DBMS data, transaction and audit data files stored by the host operating system is dependent on OS controls. When different applications share the same database process, resource contention and differing security controls may be required to isolate and protect one application's data and audit logs from another. DBMS software libraries and configuration files also require differing access control lists.
SV-76455r3_rule O121-BP-025101 CCI-000366 MEDIUM The directory assigned to the AUDIT_FILE_DEST parameter must be protected from unauthorized access and must be stored in a dedicated directory or disk partition separate from software or other application files. The AUDIT_FILE_DEST parameter specifies the directory where the database audit trail file is stored (when AUDIT_TRAIL parameter is set to ‘OS’, ‘xml’ or ‘xml, extended’ where supported by the DBMS). Unauthorized access or loss of integrity of the audit trail could result in loss of accountability or the ability to detect suspicious activity. This directory also contains the audit trail of the SYS and SYSTEM accounts that captures privileged database events when the database is not running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE).
SV-76457r2_rule O121-C2-000100 CCI-000054 MEDIUM The DBMS must limit the number of concurrent sessions for each system account to an organization-defined number of sessions. Application management includes the ability to control the number of users and user sessions utilizing an application. Limiting the number of allowed users, and sessions per user, is helpful in limiting risks related to Denial of Service attacks. This requirement addresses concurrent session control for a single information system account and does not address concurrent sessions by a single user via multiple system accounts. Unlimited concurrent connections to the DBMS could allow a successful Denial of Service (DoS) attack by exhausting connection resources. The organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to take into account the work requirements of the various types of user. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session.
SV-76459r1_rule O121-C3-008800 CCI-001878 LOW The system must provide a report generation capability for audit reduction data. In support of Audit Review, Analysis, and Reporting requirements, audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Before a security review is conducted, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. In order to identify and report on what (repetitive) data has been removed via the use of audit reduction, the application must provide a capability to generate reports containing what values were removed by the audit reduction. Audit reduction does not alter original audit records. An audit reduction capability provides support for near real-time audit review and analysis based on policy-based requirements and after-the-fact investigations of security incidents. Reporting tools employing audit reduction methods must not alter the original audit data. An example of a tool employing audit reduction methods is the Windows Event Viewer tool which is used to view and analyze audit logs on Windows systems. The lack of reporting tools for audit reduction can require the DBA, or others responsible for reviewing audit logs, to sort through large amounts of data in order to find relevant records. This can cause important audit records to be missed.
SV-83467r1_rule O121-OS-010710 CCI-001499 MEDIUM Logic modules within the database (to include packages, procedures, functions and triggers) must be monitored to discover unauthorized changes. Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. This includes the logic modules implemented within the database, such as packages, procedures, functions and triggers. If the DBMS were to allow any user to make changes to these, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Unmanaged changes that occur to the database logic modules can lead to unauthorized or compromised installations.