{"stig":{"title":"Oracle Database 19c Security Technical Implementation Guide","version":"1","release":"5"},"checks":[{"vulnId":"V-270495","ruleId":"SV-270495r1167748_rule","severity":"medium","ruleTitle":"Oracle Database must limit the number of concurrent sessions for each system account to an organization-defined number of sessions.","description":"Database management includes the ability to control the number of users and user sessions using a database management system (DBMS). Unlimited concurrent connections to the DBMS could allow a successful denial-of-service (DoS) attack by exhausting connection resources; and a system can also fail or be degraded by an overload of legitimate users. Limiting the number of concurrent sessions per user is helpful in reducing these risks. \n\nThis requirement addresses concurrent session control for a single account. It does not address concurrent sessions by a single user via multiple system accounts; and it does not deal with the total number of sessions across all accounts.\n\nThe capability to limit the number of concurrent sessions per user must be configured in or added to the DBMS by modifying user database profiles.\n\nNote that it is not sufficient to limit sessions via a web server or application server alone, because legitimate users and adversaries can potentially connect to the DBMS by other means.\n\nThe organization must to define the maximum number of concurrent sessions by user type, by account, or a combination thereof. In deciding on the appropriate number, it is important to consider the work requirements of the various types of users. For example, two might be an acceptable limit for general users accessing the database via an application; but three 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: An account associated with a connection pool might require hundreds or thousands.\n\n(Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.)","checkContent":"Retrieve the settings for concurrent sessions for each profile with the query:\n\nSELECT con_id, inherited, limit FROM sys.cdb_profiles WHERE resource_name = 'SESSIONS_PER_USER';\n\nIf the DBMS settings for concurrent sessions for each profile are greater than the site-specific maximum number of sessions (or the database maximum number of sessions) for the user type, this is a finding.\n\nThe reason for \"site-specific\" is because two different databases at different \"sites\" could have very different requirements.\nAlso, two different databases at the same \"site\" (data center) could have very different requirements.","fixText":"Limit concurrent connections for each system account to a number less than or equal to the organization-defined number of sessions using the following SQL. Create profiles that conform to the requirements. Assign users to the appropriate profile.\n\nThe user profile, ORA_STIG_PROFILE, has been provided with Oracle 19c to satisfy the STIG requirements pertaining to profile parameters. Oracle recommends that this profile be customized with requirements and assigned to all users through the creation of user type specific profiles such as (Single-Session, Administrators, Application Connection Pool) where applicable. \n\nNote: The ORA_STIG_PROFILE limit for SESSIONS_PER_USER is DEFAULT which is, on installation, not compliant and must be configured for each database and in a container database for CDB$ROOT and, potentially, for each PDB.\n\nSet concurrent sessions for each profile with the following SQL statement, as required.\n\nALTER PROFILE LIMIT SESSIONS_PER_USER ;","ccis":["CCI-000054"]},{"vulnId":"V-270496","ruleId":"SV-270496r1167727_rule","severity":"medium","ruleTitle":"Oracle Database must protect against or limit the effects of organization-defined types of denial-of-service (DoS) attacks.","description":"DOS attacks, more correctly characterized as \"Denial-of-Service Events\" as they most often the result of run-away processes and accidents, are the result of an excessive demand for a limiting resource.\n\nA 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 but within the database itself, Oracle provides the following mechanisms:\n\n1. Reduction of excessive concurrent connections from a single user (see STIG_ID O19C-00-000100).\n2. Limiting the database connection rate (LISTENER.ORA).\n3. Limiting the amount of CPU available to users with Profile kernel limits.\n4. Limiting the amount of I/O available to users with Profile kernel limits.\n5. Limiting the amount of storage space with tablespace quotas.\n6. Limiting idle time with profile kernel limits.\n\nOther best practices such as limiting the number of parallel handles available to users with Resource Manager Plans or using CMAN are also recommended as part of an overall plan for DoS prevention.","checkContent":"Review database management system (DBMS) settings to verify the DBMS implements measures to limit the effects of a DoS event.\n\nRate Limit:\n\nCheck the $ORACLE_HOME/network/admin/listener.ora to verify a Rate Limit has been established. A rate limit is used to prevent DoS attacks on a database or to control a logon storm such as may be caused by an application server or pool restart.\n\nIf a rate limit has not been set similar to one of the two examples in Listing 1, this is a finding.\n \nListing 1\nCONNECTION_RATE_LISTENER=10\nLISTENER= (\n ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n )\nLISTENER=\n (ADDRESS_LIST=\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12))\n (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n )\n\nDatabase Profiles:\nIf the database profiles, as shown in Listing 2 do not contain resource controls similar to those shown, but appropriate to the target database's infrastructure and utilization, that is a finding.\n\nListing 2\nSELECT cp.con_id, cp.profile, cp.resource_name, cp.limit\nFROM sys.cdb_profiles cp\nWHERE resource_name IN ('CPU_PER_CALL', 'IDLE_TIME', 'LOGICAL_READS_PER_CALL');\nORDER BY 1,2,3;\n\n\nTablespace Quota:\n\nListing 3\nSELECT ctq.con_id, ctq.tablespace_name, ctq.username, ctq.max_bytes, ctq.max_blocks\nFROM sys.cdb_ts_quotas ctq\nWHERE ((max_bytes = -1) OR (max_blocks = -1))\nAND (ctq.con_id, ctq.tablespace_name) IN (SELECT ct.con_id, ct.tablespace_name FROM sys.cdb_tablespaces ct)\nORDER BY 1;\n\nIf any rows returned have a MAX_BYTES or MAX_BLOCKS equal to minus one (-1) that is a finding.","fixText":"Implement measures to limit the effects of organization-defined types of DoS attacks.\n\nFor each of the three queries in the Check, if there are findings, make the changes required to bring the environment into compliance.\n\nFor Listing 1:\nModify the $ORACLE_HOME/network/admin/listener.ora to establish a Rate Limit.\nRestart the listener for changes to take effect.\n\nFor Listing 2:\nSet limits on all profiles for CPU_PER_CALL, IDLE_TIME, and LOGICAL_READS_PER_CALL.\n\nFor Listing 3:\nEnforce reasonable limits for tablespace consumption sufficient to prevent a DOS attack from impacting multiple applications or multiple services.","ccis":["CCI-000054"]},{"vulnId":"V-270497","ruleId":"SV-270497r1167730_rule","severity":"medium","ruleTitle":"Oracle Database must automatically terminate a user session after organization-defined conditions or trigger events requiring session disconnect.","description":"This addresses the termination of user-initiated logical sessions in contrast to the termination of network connections associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. \n\nSession termination ends all processes associated with a user's logical session except those batch processes/jobs that are specifically created by the user (i.e., session owner) to continue after the session is terminated. \n\nConditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\n\nThis capability is typically reserved for specific cases where the system owner, data owner, or organization requires additional assurance.\n\nSatisfies: SRG-APP-000295-DB-000305, SRG-APP-000296-DB-000306","checkContent":"Review system documentation to obtain the organization's definition of circumstances requiring automatic session termination. If the documentation explicitly states that such termination is not required or is prohibited, this is not a finding.\n\nIf no documentation exists or an automatic session termination time is not explicitly defined, assume a time of 15 minutes.\n\nTo check the max_idle_time set, run the following query:\n\nSELECT gp.inst_id, gp.con_id, gp.value\nFROM sys.gv_$parameter gp\nWHERE gp.name = 'max_idle_time';\n\nIf the value returned is \"0\" or does not match the documented requirement (or 15 when none is specified), this is a finding.","fixText":"Configure the database management system (DBMS) to automatically terminate a user session after organization-defined conditions, 15 minutes, or a trigger event requiring session termination.\n\nTo terminate a session after a certain amount of time independent of the consumed resources needed by other users, then set the MAX_IDLE_TIME initialization parameter. The MAX_IDLE_TIME parameter specifies the maximum number of minutes a session can be idle. After the specified amount of time, MAX_IDLE_TIME kills sessions.\n\nALTER SYSTEM SET max_idle_time = 15 \nCOMMENT = 'Altered for STIG compliance' -- self documenting\nSID = '*' -- required for RAC\nSCOPE = BOTH;","ccis":["CCI-002361","CCI-002363"]},{"vulnId":"V-270498","ruleId":"SV-270498r1167732_rule","severity":"medium","ruleTitle":"Oracle Database must associate organization-defined types of security labels having organization-defined security label values with information in storage.","description":"Without the association of security labels to information, there is no basis for the database management system (DBMS) to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. \n\nThese labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling, or distribution instructions, or support other aspects of the information security policy. \n\nOne example includes marking data as classified or CUI. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.\n\nSome 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.\n\nSatisfies: SRG-APP-000311-DB-000308, SRG-APP-000313-DB-000309, SRG-APP-000314-DB-000310","checkContent":"If no data has been identified as being sensitive or classified in the system documentation, this is not a finding.\n\nIf security labeling is not required, this is not a finding.\n\nIf security labeling requirements have been specified, but the security labeling is not implemented or does not reliably maintain labels on information in storage, this is a finding.","fixText":"Define the policy for security labels defined for the data. \n\nDocument the security label requirements and configure database security labels in accordance with the policy.\n\nTo provide reliable security labeling of information in storage, enable DBMS features; deploy third-party software; or add custom data structures, data elements, and application code.\n\nOracle recommends Oracle Label Security.\n\nFor additional information on Oracle Label Security:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/olsag/label-security-administrators-guide.pdf.","ccis":["CCI-002262","CCI-002263","CCI-002264"]},{"vulnId":"V-270499","ruleId":"SV-270499r1064775_rule","severity":"high","ruleTitle":"Oracle Database must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.","description":"Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization.\n\nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. \n\nExamples include, but are not limited to, using automation to act on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in noncentralized account stores, such as multiple servers. Account management functions can also include assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage.\n\nOracle Database must be configured to automatically use organization-level account management functions, and these functions must immediately enforce the organization's current account policy. \n\nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nIf an Oracle feature/product, an OS feature, a third-party product, or custom code is used to automate account management, this is not a finding.\n\nIf there are any accounts managed by the Oracle Database, review the system documentation for justification and approval of these accounts.\n\nIf any Oracle-managed accounts exist that are not documented and approved, this is a finding.","fixText":"Integrate database management system (DBMS) security with an organization-level authentication/access mechanism providing account management for all users, groups, roles, and any other principals.\n\nFor each Oracle-managed account that is not documented and approved, either transfer it to management by the external mechanism, or document the need for it and obtain approval, as appropriate.\n\nUtilize an Oracle feature/product, an OS feature, a third-party product, or custom code to automate as much account maintenance functionality as possible.","ccis":["CCI-000015"]},{"vulnId":"V-270500","ruleId":"SV-270500r1167734_rule","severity":"high","ruleTitle":"Oracle Database must enforce approved authorizations for logical access to the system in accordance with applicable policy.","description":"Authentication with a DOD-approved public key infrastructure (PKI) certificate does not necessarily imply authorization to access the database management system (DBMS). To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DOD-approved PKIs, all DOD systems, including databases, must be properly configured to implement access control policies. \n\nSuccessful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. \n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.\n\nThis requirement is applicable to access control enforcement applications, a category that includes database management systems. 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 in conflict with applicable policy.\n\nSatisfies: SRG-APP-000033-DB-000084, SRG-APP-000340-DB-000304","checkContent":"Check DBMS settings to determine whether users are restricted from accessing objects and data they are not authorized to access. If appropriate access controls are not implemented to restrict access to authorized users and to restrict the access of those users to objects and data they are authorized to verify, this is a finding.\n\nOne option to isolate access is by using the Oracle Database Vault. To check to verify the Oracle Database Vault is installed, issue the following query:\n\nSQL> SELECT * FROM sys.v_$option WHERE parameter = 'Oracle Database Vault';\n\nIf Oracle Database Vault is installed, review its settings for appropriateness and completeness of the access it permits and denies to each type of user. If appropriate and complete, this is not a finding.\n\nIf Oracle Database Vault is not installed, review the roles and profiles in the database and the assignment of users to these for appropriateness and completeness of the access permitted and denied each type of user. If appropriate and complete, this is not a finding.\n\nIf the access permitted and denied each type of user is inappropriate or incomplete, this is a finding.\n\nFollowing are code examples for reviewing roles, profiles, etc.\n\nFind out what role the users have:\n\nselect * from sys.cdb_role_privs where granted_role = ''\n\nList all roles given to a user:\n\nselect * from sys.cba_role_privs where grantee = '';\n\nList all roles for all users:\n\ncolumn grantee format a32\ncolumn granted_role format a32\nbreak on grantee\n\nSELECT con_id, grantee, granted_role\nFROM sys.cdb_role_privs\nORDER BY 1,2,3;\n\nUse the following query to list all privileges given to a user:\n\nSELECT LPAD(' ', 2*level) || granted_role \"User roles and privileges\"\nFROM (\n/* THE USERS */\nSELECT con_id, NULL AS grantee, username granted_role\nFROM sys.cdb_users\nWHERE username LIKE UPPER('')\n/* THE ROLES TO ROLES RELATIONS */\nUNION SELECT con_id, grantee, granted_role\nFROM sys.cdb_role_privs\n/* THE ROLES TO PRIVILEGE RELATIONS */\nUNION\nSELECT con_id, grantee, privilege\nFROM sys.cdb_sys_privs)\nSTART WITH grantee IS NULL\nCONNECT BY grantee = PRIOR granted_role;\n\nList which tables a certain role gives SELECT and READ access to using the query:\n\nSELECT * FROM sys.role_tab_privs WHERE role = ''\nAND privilege IN ('READ', 'SELECT');\n\nList all tables a user can SELECT and READ from using the query:\n\nSELECT * FROM sys.cdb_tab_privs\nWHERE grantee ='' AND privilege IN ('READ', 'SELECT');\n\nList all users who can SELECT on a particular table (either through being given a relevant role or through a direct grant, e.g., grant select on a table to Joe). The result of this query should also show through which role the user has this access or whether it was a direct grant.\n\nSELECT grantee,'Granted Through Role' as Grant_Type, role, table_name\nFROM CONTAINERS(sys.role_tab_privs) rtp, sys.cdb_role_privs crp\nWHERE rtp.role = crp.granted_role\nAND rtp.con_id = crp.con_id\nAND table_name = ''\nUNION\nSELECT grantee, 'Direct Grant' as Grant_Type, NULL AS role, table_name\nFROM sys.cdb_tab_privs\nWHERE table_name = '';","fixText":"If Oracle Database Vault is in use, use it to configure the correct access privileges for each type of user.\n\nIf Oracle Database Vault is not in use, configure the correct access privileges for each type of user using Roles and Profiles.\n\nOracle recommends using Database Vault.\n\nFor more information on the configuration of Database Vault, refer to the Database Vault Administrator's Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dvadm/database-vault-administrators-guide.pdf.","ccis":["CCI-000213","CCI-002235"]},{"vulnId":"V-270501","ruleId":"SV-270501r1167736_rule","severity":"low","ruleTitle":"Oracle Database must protect against an individual who uses a shared account falsely denying having performed a particular action.","description":"Nonrepudiation of actions taken is required 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.\n\nNonrepudiation 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. \n\nAuthentication via shared accounts does not provide individual accountability for actions taken on the database management system (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.\n\nWhen shared accounts are used without another means of identifying individual users, users may deny having performed a particular action.\n\nThis calls for inspection of application source code, which requires collaboration with the application developers. 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.\n\nSatisfies: SRG-APP-000080-DB-000063, SRG-APP-000815-DB-000160","checkContent":"If there are no shared accounts available to more than one user, this is not a finding.\n\nReview database, application, and/or OS settings to determine whether users can be identified as individuals when using shared accounts. \n\nIf the individual user of a shared account cannot be identified, this is a finding.\n\nIf Standard Auditing is used:\nTo ensure user activities other than SELECT, INSERT, UPDATE, and DELETE are also monitored and attributed to individuals, verify that Oracle auditing is enabled. To verify Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nOr run the following SQL query:\n\ncol display_value format a10\ncol default_value format a10\nSELECT inst_id, con_id, display_value, default_value, isdefault\nFROM sys.gv_$parameter WHERE name = 'audit_trail';\n\nIf the query returns the display_value \"NONE\", for any instance or container, this is a finding.\n\nIf Unified Auditing is used:\nTo ensure that user activities other than SELECT, INSERT, UPDATE, and DELETE are also monitored and attributed to individuals, verify that Oracle auditing is enabled. To verify Oracle is configured to capture audit data, enter the following SQL*Plus query:\n\ncol value format a10\nSELECT inst_id, con_id, value\nFROM sys.gv_$option\nWHERE parameter = 'Unified Auditing';\n\nIf the query returns something other than \"TRUE\", for any instance or container, this is a finding.","fixText":"Use accounts assigned to individual users. Configure DBMS to provide individual accountability at the DBMS level, and in audit logs, for actions performed under a shared database account.\n\nModify applications and data tables that are not capturing individual user identity to do so.\n\nCreate and enforce the use of individual user IDs for logging on to Oracle tools and third-party products.\n\nIf Oracle auditing is not already enabled, enable it.\n\nIf Standard Auditing is used:\nIf Oracle (or third-party) auditing is not already enabled, enable it. For Oracle auditing, use this query:\n\nALTER SYSTEM SET AUDIT_TRAIL= SID='*' SCOPE=SPFILE;\n\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nIf Unified Auditing is used:\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\n\"Auditing Database Activity\" in the Oracle Database 19c Security Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html\n\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html\n\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/\n\nOracle Database Upgrade Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/index.html\n\nIf the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation at the locations above.\n\nIf this level of auditing does not meet site-specific requirements, consider deploying the Oracle Audit Vault. The Audit Vault is a highly configurable option from Oracle made specifically for performing the audit functions. It has reporting capabilities as well as user-defined rules that provide additional flexibility for complex auditing requirements.","ccis":["CCI-000166","CCI-004045"]},{"vulnId":"V-270502","ruleId":"SV-270502r1167738_rule","severity":"medium","ruleTitle":"Oracle Database must provide audit record generation capability for organization-defined auditable events within the database.","description":"Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nAudit records can be generated from various components within the database management system (DBMS) (e.g., process, module). 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.\n\nDOD has defined the list of events for which the DBMS will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n(ii) Access actions, such as successful and unsuccessful login attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n(iii) All account creation, modification, disabling, and termination actions.\n\nOrganizations may define additional events requiring continuous or ad hoc auditing.","checkContent":"Using vendor and system documentation, if necessary, verify the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nIf Standard Auditing is used:\nTo verify Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nOr the following SQL query:\n\ncol display_value format a10\ncol default_value format a10\nSELECT inst_id, con_id, display_value, default_value, isdefault\nFROM sys.gv_$parameter WHERE name = 'audit_trail';\n\nIf Oracle returns the value \"NONE\", this is a finding.\n\nTo confirm Oracle audit is capturing information on the required events, review the contents of the SYS.AUD$ table or the audit file, whichever is in use. If auditable events are not listed, this is a finding.\n\nIf Unified Auditing is used:\nTo verify Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\ncol value format a10\nSELECT inst_id, con_id, value\nFROM sys.gv_$option\nWHERE parameter = 'Unified Auditing';\n\nIf the query returns something other than \"TRUE\", this is a finding.\n\nTo confirm Oracle audit is capturing information on the required events, review the contents of the SYS.UNIFIED_AUDIT_TRAIL view.\n\nIf auditable events are not listed, this is a finding.","fixText":"Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SID='*' SCOPE=SPFILE;\n\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\n\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nIf the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation at the locations below.\n\nIf Unified Auditing is used:\nUse this process to ensure auditable events are captured:\n\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\nFor more information on the configuration of auditing, refer to the following documents:\n\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html\n\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide: \nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html\n\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/\n\nOracle Database Upgrade Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/index.html\n\nIf the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation at the locations above.","ccis":["CCI-000169"]},{"vulnId":"V-270503","ruleId":"SV-270503r1064787_rule","severity":"medium","ruleTitle":"Oracle Database must allow designated organizational personnel to select which auditable events are to be audited by the database.","description":"Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events.\n\nSuppression of auditing could permit an adversary to evade detection.\n\nMisconfigured audits can degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.","checkContent":"Check database management system (DBMS) settings and documentation to determine whether designated personnel are able to select which auditable events are being audited. \n\nIf designated personnel are not able to configure auditable events, this is a finding.","fixText":"Configure the DBMS's settings to allow designated personnel to select which auditable events are audited.\n\nNote: In Oracle, any user can configure auditing for the objects in their own schema by using the AUDIT statement. To undo the audit configuration for an object, the user can use the NOAUDIT statement. No additional privileges are needed to perform this task.\n\nTo audit objects in another schema, the user must have the AUDIT ANY system privilege.\n\nTo audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/part_6.html","ccis":["CCI-000171"]},{"vulnId":"V-270504","ruleId":"SV-270504r1167741_rule","severity":"medium","ruleTitle":"Oracle Database must generate audit records for the DOD-selected list of auditable events, when successfully accessed, added, modified, or deleted, to the extent such information is available.","description":"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.\n\nThe 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).\n\nOrganizations may define the organizational personnel accountable for determining which application components must provide auditable events.\n\nAuditing provides accountability for changes made to the database management system (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.\n\nThe Department of Defense has established the following as the minimum set of auditable events:\n- When privileges/permissions are retrieved, added, modified or deleted.\n- When unsuccessful attempts to retrieve, add, modify, delete privileges/permissions occur.\n- Enforcement of access restrictions associated with changes to the configuration of the database(s).\n- When security objects are accessed, modified, or deleted.\n- When unsuccessful attempts to access, modify, or delete security objects occur.\n- When categories of information (e.g., classification levels/security levels) are accessed, created, modified, or deleted.\n- When unsuccessful attempts to access, create, modify, or delete categorized information occur.\n- All privileged activities or other system-level access.\n- When unsuccessful attempts to execute privileged activities or other system-level access occurs.\n- When successful or unsuccessful access to any other objects occur as specifically defined by the site.\n\nSatisfies: SRG-APP-000091-DB-000066, SRG-APP-000091-DB-000325, SRG-APP-000492-DB-000333, SRG-APP-000494-DB-000344, SRG-APP-000494-DB-000345, SRG-APP-000495-DB-000326, SRG-APP-000495-DB-000327, SRG-APP-000495-DB-000328, SRG-APP-000495-DB-000329, SRG-APP-000496-DB-000334, SRG-APP-000496-DB-000335, SRG-APP-000498-DB-000346, SRG-APP-000498-DB-000347, SRG-APP-000499-DB-000330, SRG-APP-000499-DB-000331, SRG-APP-000501-DB-000336, SRG-APP-000501-DB-000337, SRG-APP-000502-DB-000348, SRG-APP-000502-DB-000349, SRG-APP-000503-DB-000350, SRG-APP-000503-DB-000351, SRG-APP-000504-DB-000354, SRG-APP-000504-DB-000355, SRG-APP-000505-DB-000352, SRG-APP-000506-DB-000353, SRG-APP-000507-DB-000357, SRG-APP-000508-DB-000358","checkContent":"Check Oracle Database settings to determine if auditing is being performed on the DOD-required list of auditable events supplied in the discussion.\n\nIf Standard Auditing is used:\nTo verify Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nOr the following SQL query:\n\ncol display_value format a10\ncol default_value format a10\nSELECT inst_id, con_id, display_value, default_value, isdefault\nFROM sys.gv_$parameter WHERE name = 'audit_trail';\n\nIf Oracle returns the value \"NONE\", this is a finding.\n\nTo confirm Oracle audit is capturing information on the required events, review the contents of the SYS.AUD$ table or the audit file, whichever is in use. If auditable events are not listed, this is a finding.\n\nIf Unified Auditing is used:\nTo verify Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\ncol value format a10\nSELECT inst_id, con_id, value\nFROM sys.gv_$option\nWHERE parameter = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", this is a finding.\n\nUnified Audit supports named audit policies, which are defined using the CREATE AUDIT POLICY statement. A policy specifies the actions that should be audited and the objects to which it should apply. If no specific objects are included in the policy definition, it applies to all objects.\n\nA named policy is enabled using the AUDIT POLICY statement. It can be enabled for all users, for specific users only, or for all except a specified list of users. The policy can audit successful actions, unsuccessful actions, or both.\n\nVerifying existing audit policy: existing Unified Audit policies are listed in the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE column contains \"STANDARD ACTION\" for a policy that applies to all objects or \"OBJECT ACTION\" for a policy that audits actions on a specific object.\n\nSELECT policy_name\nFROM sys.audit_unified_policies\nWHERE audit_option = 'GRANT'\nAND audit_option_type= 'STANDARD ACTION';\n\n\nTo find policies that audit privilege grants on specific objects:\n\ncol policy_name format a20\ncol object_schema format a20\ncol object_name format a30\nSELECT policy_name, object_schema, object_name \nFROM sys.audit_unified_policies \nWHERE audit_option = 'GRANT'\nAND audit_option_type = 'OBJECT ACTION';\n\n\nThe view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the policy is enabled or \"ALL USERS\". The SUCCESS and FAILURE columns indicate if the policy is enabled for successful or unsuccessful actions, respectively.\n\ncol entity_name format a30\nSELECT policy_name, enabled_option, entity_name, success, failure\nFROM sys.audit_unified_enabled_policies;\n\nIf auditing is not being performed for all the events listed above, this is a finding.","fixText":"Both Standard and Unified Auditing are allowed in Oracle Database 19c.\nThe default is mixed auditing mode.\nThe predefined policy ORA_SECURECONFIG is enabled by default in mixed mode.\n\nConfigure the DBMS's auditing settings to include auditing of events on the DOD-selected list of auditable events.\n\n1. Successful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).\n\nTo audit granting and revocation of any privilege:\nCREATE AUDIT POLICY ACTIONS GRANT;\nCREATE AUDIT POLICY ACTIONS REVOKE;\n\nTo audit grants of object privileges on a specific object:\nCREATE AUDIT POLICY ACTIONS GRANT ON .;\n\nIf Oracle Label Security is enabled, this will audit all OLS administrative actions:\nCREATE AUDIT POLICY ACTIONS COMPONENT = OLS ALL;\n\n2. Successful and unsuccessful logon attempts, privileged activities or other system-level access.\n \nTo audit all user logon attempts:\nCREATE AUDIT POLICY ACTIONS LOGON;\n\nTo audit only logon attempts using administrative privileges (e.g., AS SYSDBA):\nAUDIT POLICY BY sys, sysoper, sysbackup, sysdg, syskm;\n\n3. Starting and ending time for user access to the system, concurrent logons from different workstations.\n\nThis policy will audit all logon and logoff events. An individual session is identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID, SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP of the logon and logoff events:\n\nCREATE AUDIT POLICY ACTIONS logon, logoff;\n\n4. Successful and unsuccessful accesses to objects.\n\nTo audit all accesses to a specific table:\nCREATE AUDIT POLICY ACTIONS select, insert, delete, alter ON .; \n\nDifferent actions are defined for other object types. To audit all supported actions on a specific object:\nCREATE AUDIT POLICY ACTIONS all ON .;\n \n5. All program initiations.\n\nTo audit execution of any PL/SQL program unit:\nCREATE AUDIT POLICY ACTIONS execute;\n\nTo audit execution of a specific function, procedure, or package:\nCREATE AUDIT POLICY ACTIONS execute ON .;\n\n6. All direct access to the information system.\n[Not applicable to Database audit. Monitor using OS auditing.]\n\n7. All account creations, modifications, disabling, and terminations.\n\nTo audit all user administration actions:\nCREATE AUDIT POLICY actions create user, alter user, drop user, change password;\n\n8. All kernel module loads, unloads, and restarts.\n[Not applicable to Database audit. Monitor using OS auditing.]\n \n9. All database parameter changes.\n\nTo audit any database parameter changes, dynamic or static:\nCREATE AUDIT POLICY ACTIONS alter database, alter system, create spfile;\n\nApplying the Policy:\n\nThe following command will enable the policy in all database sessions and audit both successful and unsuccessful actions:\nAUDIT POLICY ;\n\nTo audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\nAUDIT POLICY WHENEVER NOT SUCCESSFUL;\n\nEither command above can be limited to only database sessions started by a specific user as follows:\nAUDIT POLICY BY ;\nAUDIT POLICY BY WHENEVER NOT SUCCESSFUL;","ccis":["CCI-000172"]},{"vulnId":"V-270505","ruleId":"SV-270505r1167742_rule","severity":"medium","ruleTitle":"Oracle Database must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.","description":"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.\n\nIn 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.\n\nAn 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.\n\nSome 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.","checkContent":"Review the system documentation to identify additional site-specific information not covered by the default audit options, the organization has determined to be necessary. If there are none, this is not a finding.\n\nIf any additional information is defined, compare those auditable events that are not covered by unified auditing with the existing Fine-Grained Auditing (FGA) specifications returned by the following query:\n\nSELECT COUNT(*)\nFROM audsys.unified_audit_trail\nWHERE audit_type = 'FineGrainedAudit';\n\nIf any such auditable event is not covered by the existing FGA specifications, this is a finding.","fixText":"If the site-specific audit requirements are not covered by the default audit options, deploy and configure FGA. For details, refer to Oracle documentation, at the location below.\n\nFor more information on the configuration of fine-grained auditing, refer to the following documents:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-audit-policies.html#GUID-88DA3AF8-5F6A-4C6E-80EE-F65071E5BF46.","ccis":["CCI-000135"]},{"vulnId":"V-270506","ruleId":"SV-270506r1167744_rule","severity":"medium","ruleTitle":"Oracle Database must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","description":"To ensure sufficient storage capacity for the audit logs, Oracle Database must be able to allocate audit record storage capacity. Although another requirement (SRG-APP-000515-DB-000318) mandates audit data be off-loaded to a centralized log management system, it remains necessary to provide space on the database server to serve as a buffer against outages and capacity limits of the off-loading mechanism.\n\nThe task of allocating audit record storage capacity is usually performed during initial installation of the database management system (DBMS) and is closely associated with the database administrator (DBA) and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.\n\nIn determining the capacity requirements, consider such factors as: total number of users; expected number of concurrent users during busy periods; number and type of events being monitored; types and amounts of data being captured; the frequency/speed with which audit records are off-loaded to the central log management system; and any limitations that exist on the DBMS's ability to reuse the space formerly occupied by off-loaded records.","checkContent":"Review the DBMS settings to determine whether audit logging is configured to produce logs consistent with the amount of space allocated for logging. If auditing will generate excessive logs so that they may outgrow the space reserved for logging, this is a finding.\n\nIf file-based auditing is in use, check that sufficient space is available to support the file(s). If not, this is a finding.\n\nIf standard, table-based auditing is used, the audit logs are written to a table called AUD$; and if a Virtual Private Database is deployed, a table is created called FGA_LOG$. \n\nsqlplus connect as sysdba\n\nSELECT table_name, tablespace_name\nFROM dba_tables\nWHERE table_name IN ('AUD$')\nORDER BY table_name;\n\nTABLE_NAME TABLESPACE_NAME\n----------------------------- ------------------------------\nAUD$ SYSTEM\n\nThe AUD$ table should be in its own tablespace. If the tablespace name is SYSTEM, this is a finding.\n\nCheck the current location of the audit trail tables:\n\nSELECT inst_id, con_id, name, value\nFROM sys.gv_$parameter\nWHERE name IN ('audit_file_dest', 'unified_audit_systemlog');\n\nVerify adequate space is allocated for the audit trail location.\n\nIf Unified Auditing is used:\n\nAudit logs are written to tables in the AUDSYS schema. The default tablespace for AUDSYS is USERS, and it should be in its own tablespace.\n \nIf the tablespace name is USERS, this is a finding. \n\nInvestigate whether there have been any incidents where the DBMS ran out of audit log space since the last time the space was allocated or other corrective measures were taken. If there have been, this is a finding.","fixText":"Allocate sufficient audit file/table space to support peak demand.\n\nIf audit records are being written to the table sys.aud$, create a new tablespace dedicated to the AUD$ table and move AUD$ using the statement below:\n\nexec sys.dbms_audit_mgmt.move_dbaudit_tables('');\n\nEnsure that audit tables are in their own tablespaces and that the tablespaces have enough room for the volume of log data that will be produced.\n\nDetailed procedures for how to alter the tablespace for audit logs can be found here:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ALTER-TABLESPACE.html.","ccis":["CCI-001849"]},{"vulnId":"V-270507","ruleId":"SV-270507r1065200_rule","severity":"medium","ruleTitle":"Oracle Database must off-load audit data to a separate log management facility; this must be continuous and in near-real-time for systems with a network connection to the storage facility, and weekly or more often for stand-alone systems.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity. \n\nThe database management system (DBMS) may write audit records to database tables, files in the file system, other kinds of local repositories, or a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.","checkContent":"Review the system documentation for a description of how audit records are off-loaded.\n\nIf there is no centralized audit log management system, for the audit data to be written to, this is a finding.\n\nIf the DBMS has a continuous network connection to the centralized log management system, but the DBMS audit records are not written directly to the centralized log management system or transferred in near-real-time, this is a finding.\n\nIf the DBMS does not have a continuous network connection to the centralized log management system, and the DBMS audit records are not transferred to the centralized log management system weekly or more often, this is a finding.","fixText":"Configure the DBMS or deploy and configure software tools to transfer audit records to a centralized log management system, continuously and in near-real-time where a continuous network connection to the log management system exists, or at least weekly in the absence of such a connection.\n\nConsider deploying the Oracle Audit Vault, which is Oracle's centralized audit log management system. Oracle Audit Vault is a powerful enterprise-wide audit solution that provides centralized location and configuration of audit information that is captured in audit records which are generated by all databases including Oracle, or other databases (SQL Server, MySQL, etc.), and various components of the DBMS, as well as, operating systems, file systems, directory services, or custom audit data in either database tables or XML files.\n\nOracle Audit Vault consumes audit data from databases, which may be automatically purged from the target database after it has been moved to the Oracle Audit Vault Server, freeing up valuable space for business data. Oracle Audit Vault Server supports data retention policies on a per source basis, making it possible to meet internal or external compliance requirements. To prevent unauthorized access or tampering, Oracle Audit Vault encrypts audit and event data at every stage, in transmission and at rest. For Oracle Databases, Oracle Audit Vault can track changes to data, user entitlements, and stored procedures. Historical tracking of important data attributes allows users to quickly report on the lifecycle of a data attribute. User entitlements tracking enables easy reporting on which users have what privileges, along with differential reporting on what has changed since the last report. Maliciously modified stored procedures are a frequent vector for data theft-stored procedure tracking helps users quickly spot changes. With support for Oracle's unified audit, it is easy to implement best practices for auditing using preseeded audit policies.","ccis":["CCI-001851"]},{"vulnId":"V-270508","ruleId":"SV-270508r1065201_rule","severity":"medium","ruleTitle":"The Oracle Database, or the logging or alerting mechanism the application uses, must provide a warning when allocated audit record storage volume record storage volume reaches 75 percent of maximum audit record storage capacity.","description":"Organizations are required to use a central log management system, so, under normal conditions, the audit space allocated to the database management system (DBMS) on its own server will not be an issue. However, space will still be required on the DBMS server for audit records in transit, and, under abnormal conditions, this could fill up. Since a requirement exists to halt processing upon audit failure, a service outage would result.\n\nIf support personnel are not notified immediately upon storage volume usage reaching 75 percent, they are unable to plan for storage capacity expansion. \n\nThe appropriate support staff include, at a minimum, the information system security officer (ISSO) and the database administrator (DBA)/system administrator (SA).","checkContent":"Review OS or third-party logging application settings to determine whether a warning will be provided when 75 percent of DBMS audit log storage capacity is reached.\n\nIf no warning will be provided, this is a finding.","fixText":"Modify DBMS, OS, or third-party logging application settings to alert appropriate personnel when 75 percent of log storage capacity is reached.\n\nFor ease of management, it is recommended that the audit tables be kept in a dedicated tablespace.\n\nIf Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an email can be sent to a designated administrator.\n\nIf Enterprise Manager is unavailable, the following script can be used to monitor storage space; this can be combined with additional code to email the appropriate administrator so they can take action.\n\nsqlplus connect as sysdba\n\nset pagesize 300\nset linesize 120\ncolumn sumb format 9,999,999,999,999\ncolumn extents format 999999\ncolumn bytes format 9,999,999,999,999\ncolumn largest format 9,999,999,999,999\ncolumn Tot_Size format 9,999,999,999,999\ncolumn Tot_Free format 9,999,999,999,999\ncolumn Pct_Free format 9,999,999,999,999\ncolumn Chunks_Free format 9,999,999,999,999\ncolumn Max_Free format 9,999,999,999,999\nset echo off\nspool TSINFO.txt\nPROMPT SPACE AVAILABLE IN TABLESPACES\nselect a.tablespace_name,sum(a.tots) Tot_Size,\nsum(a.sumb) Tot_Free,\nsum(a.sumb)*100/sum(a.tots) Pct_Free, \nsum(a.largest) Max_Free,sum(a.chunks) Chunks_Free\nfrom\n(\nselect tablespace_name,0 tots,sum(bytes) sumb,\nmax(bytes) largest,count(*) chunks\nfrom dba_free_space a\ngroup by tablespace_name\nunion\nselect tablespace_name,sum(bytes) tots,0,0,0 from\ndba_data_files\ngroup by tablespace_name) a\ngroup by a.tablespace_name;\n\nSample Output\n\nSPACE AVAILABLE IN TABLESPACES\n\nTABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE CHUNKS_FREE\n----------------------------- -------------- -------------- --------------- ---------------- --------------------- \nDES2 41,943,040 30,935,040 74 30,935,040 1 \nDES2_I 31,457,280 23,396,352 74 23,396,352 1 \nRBS 60,817,408 57,085,952 94 52,426,752 16 \nSYSTEM 94,371,840 5,386,240 6 5,013,504 3 \nTEMP 563,200 561,152 100 133,120 5 \nTOOLS 120,586,240 89,407,488 74 78,190,592 12 \nUSERS 1,048,576 26,624 3 26,624 1","ccis":["CCI-001855"]},{"vulnId":"V-270509","ruleId":"SV-270509r1065202_rule","severity":"medium","ruleTitle":"Oracle Database must provide an immediate real-time alert to appropriate support staff of all audit log failures.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. \n\nThe appropriate support staff include, at a minimum, the information system security officer (ISSO) and the database administrator (DBA)/system administrator (SA).\n\nA 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.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).\n\nIf 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.","checkContent":"Review Oracle Database, OS, or third-party logging software settings to determine whether a real-time alert will be sent to the appropriate personnel when auditing fails for any reason.\n\nIf real-time alerts are not sent upon auditing failure, this is a finding.","fixText":"Configure logging software to send a real-time alert to appropriate personnel when auditing fails for any reason.\n\nOracle recommends the use of Oracle Enterprise Manager.","ccis":["CCI-001858"]},{"vulnId":"V-270510","ruleId":"SV-270510r1068294_rule","severity":"medium","ruleTitle":"The audit information produced by the Oracle Database must be protected from unauthorized access, modification, or deletion.","description":"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.\n\nTo 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.\n\nThis 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 using file system protections and limiting log data location.\n\nAdditionally, 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.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nModification or deletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.\n\nSatisfies: SRG-APP-000118-DB-000059, SRG-APP-000119-DB-000060, SRG-APP-000120-DB-000061","checkContent":"Review locations of audit logs, both internal to the database and database audit logs located at the operating system level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized access.\n\nIf appropriate controls and permissions do not exist, this is a finding.\n\n- - - - -\nFrom SQL*Plus or SQL Developer:\n\nselect value from v$parameter where name = 'audit_trail';\nselect value from v$parameter where name = 'audit_file_dest';\n\nIf audit_trail is set to OS, XML or XML EXTENDED, this means logs are stored at the operating system level.\n\nIf audit_trail is set to OS, but the audit records are routed directly to a separate log server without writing to the local file system, this is not a finding.\n\nIf audit_trail is set to DB or \"DB, EXTENDED\" this means logs are stored in the database.\n\nIf any logs are written to the database, DBA_TAB_PRIVS describes all object grants in the database. \n\nIf standard auditing is in use, follow the below, check permissions on the AUD$ table. \n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\nFROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\nIf Unified Auditing is used, check permissions on the AUDSYS tables.\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\nFROM DBA_TAB_PRIVS where owner='AUDSYS';\n\nIf appropriate controls and permissions are not implemented, this is a finding.\n\nIf audit logs located at the operating system level:\nOn Unix Systems:\n\n ls -ld [pathname]\n\nSubstitute [pathname] with the directory paths listed from the above SQL statements for audit_file_dest.\n\nIf permissions are granted for world access, this is a finding.\n\nIf any groups that include members other than software owner accounts, DBAs, auditors, oracle processes, or any account not listed as authorized, this is a finding.\n\nOn Windows Systems (from Windows Explorer):\n\nBrowse to the directory specified. Select and right-click on the directory >> Properties >> Security tab. On Windows hosts, records are also written to the Windows application event log. The location of the application event log is listed under Properties for the log under the Windows console. The default location is C:\\WINDOWS\\system32\\config\\EventLogs\\AppEvent.Evt.\n\nSelect and right-click on the directory >> Properties >> Security tab.\n\nIf permissions are granted to everyone, this is a finding.\n\nIf any accounts other than the administrators, software owner accounts, DBAs, auditors, Oracle processes, or any account not listed as authorized, this is a finding.\n\nCompare path to %ORACLE_HOME%. If audit_file_dest is a subdirectory of %ORACLE_HOME%, this is a finding.","fixText":"Add controls and modify permissions to protect database audit log data from unauthorized modification, whether stored in the database itself or at the OS level.\n\nLogs are stored in the database:\nFor Standard Auditing, Revoke access to the AUD$ table to anyone who should not have access to it.\nFor Unified Auditing, Revoke access to the tables with AUDSYS as the owner.\n\nUse the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects.\n\nREVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\nUse the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. Can also revoke one or more table privileges by specifying a privilege-list.\n\nUse the DELETE privilege type to revoke permission to delete rows from the specified table.\n\nUse the INSERT privilege type to revoke permission to insert rows into the specified table.\n\nUse the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns.\n\nUse the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table.\n\nUse the TRIGGER privilege type to revoke permission to create a trigger on the specified table.\n\nUse the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns.\n\nFor file-based/OS level auditing, establish an audit file directory separate from the Oracle Home.\n\nAlter host system permissions to the AUDIT_FILE_DEST directory to the Oracle process and software owner accounts, DBAs, backup accounts, SAs (if required), and auditors.\n\nAuthorize and document user access requirements to the directory outside of the Oracle, DBA, and SA account list in the system documentation.","ccis":["CCI-000162","CCI-000163","CCI-000164"]},{"vulnId":"V-270511","ruleId":"SV-270511r1065262_rule","severity":"medium","ruleTitle":"The system must protect audit tools from unauthorized access, modification, or deletion.","description":"Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.\n\nDepending 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.\n\nApplications 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.\n\nAudit 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.\n\nIf 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.\n\nSatisfies: SRG-APP-000121-DB-000202, SRG-APP-000122-DB-000203, SRG-APP-000123-DB-000204","checkContent":"Review access permissions to tools used to view or modify audit log data. These tools may include the database management system (DBMS) itself or tools external to the database.\n\nIf appropriate permissions and access controls are not applied to prevent unauthorized access, modification, or deletion of these tools, this is a finding.","fixText":"Add or modify access controls and permissions to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.","ccis":["CCI-001493","CCI-001494","CCI-001495"]},{"vulnId":"V-270512","ruleId":"SV-270512r1065305_rule","severity":"medium","ruleTitle":"Oracle Database must support enforcement of logical access restrictions associated with changes to the database management system (DBMS) configuration and to the database itself.","description":"Failure to provide logical access restrictions associated with changes to configuration may have significant effects on the overall security of the system. \n\nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals should be allowed to obtain access to system components for the purposes of initiating changes, including upgrades and modifications.","checkContent":"Review access restrictions associated with changes to the configuration of the DBMS or database(s).\n\nOn Unix Systems:\nls -ld [pathname]\n\nReplace [pathname] with the directory path where the Oracle Database software is installed (e.g., /u01/app/oracle/product/19.0.0/dbhome_1).\n\nIf permissions are granted for world access, this is a finding.\n\nIf any groups that include members other than the software owner account, database administrators (DBAs), or any accounts not listed as authorized, this is a finding.\n\nFor Windows Systems:\nReview the permissions that control access to the Oracle installation software directories (e.g., \\Program Files\\Oracle\\).\n\nIf access is given to members other than the software owner account, DBAs, or any accounts not listed as authorized, this is a finding.\n\nCompare the access control employed with that documented in the system documentation.\n\nIf access does not match the documented requirement, this is a finding.","fixText":"For Unix Systems:\nSet the umask of the Oracle software owner account to 022. Determine the shell being used for the Oracle software owner account:\n\n env | grep -i shell\n\nStartup files for each shell are as follows (located in users $HOME directory):\n\n C-Shell (CSH) = .cshrc\n Bourne Shell (SH) = .profile\n Korn Shell (KSH) = .kshrc\n TC Shell (TCS) = .tcshrc\n BASH Shell = .bash_profile or .bashrc\n\nEdit the shell startup file for the account and add or modify the line:\n\n umask 022\n\nLog off and log on, then enter the umask command to confirm the setting.\n\nNote: To effect this change for all Oracle processes, a reboot of the DBMS server may be required.\n\nFor Windows Systems:\nRestrict access to the DBMS software libraries to the fewest accounts that clearly require access based on job function.\n\nDocument authorized access controls and justify any access grants that do not fall under DBA, DBMS process, ownership, or system administrator (SA) accounts.","ccis":["CCI-001813"]},{"vulnId":"V-270513","ruleId":"SV-270513r1138543_rule","severity":"high","ruleTitle":"Oracle Database products must be a version supported by the vendor.","description":"Unsupported commercial and database systems should not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation.\n\nWhen maintenance updates and patches are no longer available, the database software is no longer considered supported and should be upgraded or decommissioned.","checkContent":"Review the system documentation and interview the database administrator.\n\nIdentify all database software components.\n\nReview the version and release information.\n\nFrom SQL*Plus:\nSelect version from v$instance;\n\nAccess the vendor website or use other means to verify the version is still supported.\nOracle Release schedule:\nhttps://support.oracle.com/knowledge/Oracle%20Database%20Products/742060_1.html\n\nIf the Oracle version or any of the software components are not supported by the vendor, this is a finding.","fixText":"Remove or decommission all unsupported software products.\n\nUpgrade unsupported DBMS or unsupported components to a supported version of the product.","ccis":["CCI-003376"]},{"vulnId":"V-270514","ruleId":"SV-270514r1064820_rule","severity":"medium","ruleTitle":"Database software, applications, and configuration files must be monitored to discover unauthorized changes.","description":"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.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Review monitoring procedures and implementation evidence to verify that monitoring of changes to database software libraries, related applications, and configuration files is done.\n\nVerify that the list of files and directories being monitored is complete. If monitoring does not occur or is not complete, this is a finding.","fixText":"Implement procedures to monitor for unauthorized changes to database management system (DBMS) software libraries, related software application libraries, and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement.\n\nFile hashes or checksums should be used for comparisons since file dates may be manipulated by malicious users.","ccis":["CCI-001499"]},{"vulnId":"V-270515","ruleId":"SV-270515r1065210_rule","severity":"medium","ruleTitle":"The OS must limit privileges to change the database management system (DBMS) software resident within software libraries (including privileged programs).","description":"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.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Review permissions that control access to the DBMS software libraries. The software library location may be determined from vendor documentation or service/process executable paths.\n\nTypically, only the DBMS software installation/maintenance account or system administrator (SA) account requires access to the software library for operational support such as backups. Any other accounts should be scrutinized and the reason for access documented. Accounts should have the least amount of privilege required to accomplish the job.\n\nBelow is one example for how to review accounts with access to software libraries for a Linux-based system:\ncat /etc/group |grep -i dba\n--Example output:\ndba:x:102: \n\n--take above number and input in below grep command\ncat /etc/passwd |grep 102\n\nIf any accounts are returned that are not required and authorized to have access to the software library location do have access, this is a finding.","fixText":"Restrict access to the DBMS software libraries to accounts that require access based on job function.","ccis":["CCI-001499"]},{"vulnId":"V-270516","ruleId":"SV-270516r1064826_rule","severity":"high","ruleTitle":"The Oracle Database software installation account must be restricted to authorized users.","description":"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 have significant effects on the overall security of the system. \n\nIf 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.\n\nAccordingly, only qualified and authorized individuals must be allowed access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nDatabase administrator (DBA) and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a great impact on database security and operation. It is especially important to grant privileged access to only those persons who are qualified and authorized to use them.\n\nThis 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.","checkContent":"Review procedures for controlling and granting access to use of the database management system (DBMS) software installation account.\n\nIf access or use of this account is not restricted to the minimum number of personnel required, or if unauthorized access to the account has been granted, this is a finding.","fixText":"Develop, document, and implement procedures to restrict use of the DBMS software installation account.","ccis":["CCI-001499"]},{"vulnId":"V-270517","ruleId":"SV-270517r1064829_rule","severity":"medium","ruleTitle":"Database software directories, including database management system (DBMS) configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.","description":"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.\n\nMultiple 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.","checkContent":"Review the DBMS software library directory and note other root directories located on the same disk directory or any subdirectories. If any non-DBMS software directories exist on the disk directory, examine or investigate their use.\n\nIf any of the directories are used by other applications, including third-party applications that use the DBMS, this is a finding.\n\nOnly applications that are required for the functioning and administration, not use, of the DBMS should be located on the same disk directory as the DBMS software libraries.\n\nFor databases located on mainframes, confirm that the database and its configuration files are isolated in their own DASD pools.\n\nIf database software and database configuration files share DASD with other applications, this is a finding.","fixText":"Install all applications on directories, or pools, separate from the DBMS software library directory. Relocate any directories or reinstall other application software that currently shares the DBMS software library directory to separate directories.\n\nFor mainframe-based databases, locate database software and configuration files in separate DASD pools from other mainframe applications.","ccis":["CCI-001499"]},{"vulnId":"V-270518","ruleId":"SV-270518r1064832_rule","severity":"medium","ruleTitle":"Database objects must be owned by accounts authorized for ownership.","description":"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. \n\nIf critical tables or other objects rely on unauthorized owner accounts, these objects can be lost when an account is removed.\n\nIt 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.","checkContent":"Review system documentation to identify accounts authorized to own database objects. Review accounts in the database management systems (DBMSs) that own objects.\n\nIf any database objects are found to be owned by users not authorized to own database objects, this is a finding.\n\n- - - - -\nQuery the object DBA_OBJECTS to show the users who own objects in the database. The query below will return all of the users who own objects.\n\nsqlplus connect as sysdba\n\nSQL>select owner, object_type, count(*) from dba_objects\ngroup by owner, object_type\norder by owner, object_type;\n\nIf these owners are not authorized owners, select all of the objects these owners have generated and decide who they should belong to. To make a list of all of the objects, the unauthorized owner has to perform the following query.\n\nSQL>select * from dba_objects where owner =&unauthorized_owner;","fixText":"Update system documentation to include list of accounts authorized for object ownership.\n\nReassign ownership of authorized objects to authorized object owner accounts.","ccis":["CCI-001499"]},{"vulnId":"V-270519","ruleId":"SV-270519r1112463_rule","severity":"medium","ruleTitle":"The role(s)/group(s) used to modify database structure (including but not necessarily limited to tables, indexes, storage, etc.) and logic modules (stored procedures, functions, triggers, links to software external to the DBMS, etc.) must be restricted to authorized users.","description":"If the database management system (DBMS) were to allow any user to make changes to database structure or logic, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Review accounts for direct assignment of administrative privileges. Connected as SYSDBA, run the query:\n\nSELECT grantee, privilege\nFROM dba_sys_privs\nWHERE grantee IN \n(\nSELECT username\nFROM dba_users\nWHERE username NOT IN \n(\n'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n'DVSYS', 'DVF', 'SYSMAN_RO',\n'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n'SYSMAN', 'APEX_040200', 'WMSYS',\n'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n'DIP', 'CTXSYS', 'AUDSYS',\n'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n'SYSMAN_TYPES', 'MGMT_VIEW',\n'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n)\n)\nAND privilege NOT IN ('UNLIMITED TABLESPACE'\n, 'REFERENCES', 'INDEX', 'SYSDBA', 'SYSOPER', 'CREATE SESSION'\n)\nORDER BY 1, 2;\n\nIf any administrative privileges have been assigned directly to a database account, this is a finding.\n\nThe list of special accounts that are excluded from this requirement may not be complete. It is expected that the database administrator (DBA) will edit the list to suit local circumstances, adding other special accounts as necessary, and removing any that are not supposed to be in use in the Oracle deployment that is under review.","fixText":"Create roles for administrative function assignments. Assign the necessary privileges for the administrative functions to a role. Do not assign administrative privileges directly to users, except for those that Oracle does not permit to be assigned via roles.","ccis":["CCI-001499"]},{"vulnId":"V-270520","ruleId":"SV-270520r1115964_rule","severity":"medium","ruleTitle":"Oracle Database must be configured in accordance with the security configuration settings based on DOD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.","description":"Configuring the database management system (DBMS) to implement organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DOD that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. Oracle Database must be configured in compliance with guidance from all such relevant sources, with specific emphasis on the database security standards of each organization.","checkContent":"Oracle Database Security Assessment Tool (DBSAT) provides prioritized recommendations on how to mitigate identified security risks or gaps within Oracle Databases.\n\nWith DBSAT, DISA STIG rules that are process-related, such as review system documentation to identify accounts authorized to own database objects, are now included, and marked as \"Evaluate\" and display details that help customers validate compliance. DBSAT automates the STIG checks whenever possible, and if the checks are process-related, DBSAT provides visibility so they can be tracked and manually validated.\n\nDownload the latest version of the Oracle Database Security Assessment Tool (DBSAT). DBSAT is provided by Oracle at no additional cost:\nhttps://www.oracle.com/database/technologies/security/dbsat.html\n\nDBSAT analyzes information on the database and listener configuration to identify configuration settings that may unnecessarily introduce risk. DBSAT goes beyond simple configuration checking, examining user accounts, privilege and role grants, authorization control, separation of duties, fine-grained access control, data encryption and key management, auditing policies, and OS file permissions. DBSAT applies rules to quickly assess the current security status of a database and produce findings in all the areas above. \n\nIn addition, to the Oracle database STIG checks, DBSAT helps identify areas where your database configuration, operation, or implementation introduces risks and recommends changes and controls to mitigate those risks according Oracle database security best practices.\n\nIf there is evidence that the DBSAT tool is not used with the output reviewed regularly (annually), this is a finding.","fixText":"For each finding, DBSAT recommends remediation activities that follow best practices to reduce or mitigate risk. Review the security status, provided by the DBSAT report, check the categories (sections) and review the findings by risk level and recommendations. For each recommendation, each organization must determine which remediation activities to implement according to their security policies.","ccis":["CCI-000366"]},{"vulnId":"V-270521","ruleId":"SV-270521r1112467_rule","severity":"medium","ruleTitle":"Oracle instance names must not contain Oracle version numbers.","description":"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.","checkContent":"If using a non-CDB database:\n\nFrom SQL*Plus:\n\nselect instance_name, version from v$instance;\n\nIf using a CDB database:\n\nTo check the container database (CDB):\n\nFrom SQL*Plus:\n\nselect instance_name, version from v$instance;\n\nTo check the pluggable databases (PDBs) within the CDB:\n\nselect name from v$pdbs;\n\nCheck Instance Name:\n\nIf the instance name returned references the Oracle release number, this is a finding.\n\nNumbers used that include version numbers by coincidence are not a finding.\n\nThe database administrator (DBA) should be able to relate the significance of the presence of a digit in the SID.","fixText":"Follow the instructions in Oracle MetaLink Note 15390.1 (and related documents) to change the SID for the database without recreating the database to a value that does not identify the Oracle version.","ccis":["CCI-000366"]},{"vulnId":"V-270522","ruleId":"SV-270522r1115956_rule","severity":"medium","ruleTitle":"Fixed user and PUBLIC Database links must be authorized for use.","description":"Database links define connections that may be used by the local Oracle database to access remote Oracle databases (homogenous links) and non-Oracle Databases (heterogeneous links). These links provide a means for a compromise to the local database to spread to remote databases and for a compromise of a remote database to the local database in a distributed database environment. Limiting or eliminating the use of database links, where they are not required to support the operational system, can help isolate compromises, mitigate risk, and reduce the potential attack surface.","checkContent":"If using a non-CDB database:\nUse the following query to get a list of database links.\n\nFrom SQL*Plus:\n\nselect owner||': '||db_link from dba_db_links;\n\nIf using a CDB database:\nUse the following query to get a list of database links.\n\nselect con_id_to_con_name(con_id) con_id, owner, db_link, username, host from cdb_db_links order by 1,2,3;\n\nCheck Results:\n\nIf no rows are returned from the first SQL statement, this check is not a finding.\n\nIf there are rows returned, verify the database links are required. If they are required and exist, this is not a finding.","fixText":"Document all authorized connections from the database to remote databases.\n\nRemove all unauthorized remote database connection definitions from the database.\n\nFrom SQL*Plus:\n\ndrop database link [link name];\nOR\ndrop public database link [link name];\n\nReview remote database connection definitions periodically and confirm their use is still required and authorized.","ccis":["CCI-000366"]},{"vulnId":"V-270523","ruleId":"SV-270523r1167746_rule","severity":"medium","ruleTitle":"The Oracle WITH GRANT OPTION privilege must be limited when granted to nondatabase administrator (DBA) or nonapplication administrator user accounts.","description":"Specifying WITH GRANT OPTION enables the grantee to grant the object privileges to other users and roles. 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 limit WITH GRANT OPTION privileges since, by definition, they require only privileges to execute procedures or view/edit data.","checkContent":"Execute the query:\n\nselect grantee||': '||owner||'.'||table_name\nfrom dba_tab_privs \nwhere grantable = 'YES' \nand grantee not in (select distinct owner from dba_objects)\nand grantee not in (select grantee from dba_role_privs where granted_role = 'DBA')\nand table_name not like 'SYS_PLSQL_%'\norder by grantee;\n\nIf any accounts are listed, verify accounts are documented and approved for the WITH GRANT option.\nIf non-DBA interactive user or application accounts have WITH GRANT without being documented and approved, this is a finding.","fixText":"Revoke privileges granted the WITH GRANT OPTION from non-DBA and accounts that do not own application objects or document the need for WITH GRANT OPTION and get approval.\n\nRe-grant privileges without specifying WITH GRANT OPTION.\n\nNote: Do not revoke the system-generated grants such as those found on SYS_PLSQL_% objects. They are system generated object types (aka ShadowTypes), created internally by Oracle when using the Pipelined Table Functions. This can result in (incorrect) compilation failures and/or invalidations when the users who are supposed to have access to the shadow types find themselves without access.","ccis":["CCI-000366"]},{"vulnId":"V-270524","ruleId":"SV-270524r1112471_rule","severity":"medium","ruleTitle":"The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.","description":"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. \n \nDOD requires the REMOTE_OS_ROLES to be set to FALSE.","checkContent":"To verify the current status of the remote_os_roles parameter use the SQL statement: \n\nIf using a non-CDB database:\n\nFrom SQL*Plus:\n \nCOLUMN name format a20 \nCOLUMN parameter_value format a20 \n\nSELECT name, con_id, value AS PARAMETER_VALUE \nFROM sys.v_$parameter \nWHERE vp.name = 'remote_os_roles' \nORDER BY 1; \n\nIf the PARAMETER_VALUE is not FALSE, that is a finding.\n\nIf using a CDB database:\n\nFrom SQL*Plus (in the CDB database):\n \nCOLUMN name format a20 \nCOLUMN parameter_value format a20 \n\nSELECT name, inst_id, con_id, value AS PARAMETER_VALUE \nFROM sys.gv_$parameter \t\nWHERE vp.name = 'remote_os_roles' \nORDER BY 1; \n\nIn the CDB database, if the PARAMETER_VALUE is not FALSE, that is a finding.","fixText":"Set the parameter to FALSE for all instances. If using Oracle Multitenant, set the value to FALSE for the container database and all pluggable databases will be set to FALSE as well. \n\nALTER SYSTEM SET remote_os_roles = FALSE scope=spfile; \n\nsid='container_name' is optional \n\nRestart the database for the change to take effect.","ccis":["CCI-000366"]},{"vulnId":"V-270525","ruleId":"SV-270525r1112473_rule","severity":"medium","ruleTitle":"The Oracle SQL92_SECURITY parameter must be set to TRUE.","description":"The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges are required to execute an update or delete those 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.\n\nThe 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.\n\nSQL92_SECURITY = FALSE\nSQL> delete from scott.emp where sal > 3000;\n1 row deleted\nSQL> rollback;\nRollback complete\n\nSQL92_SECURITY = TRUE\nSQL> delete from scott.emp where sal > 3000;\ndelete from scott.emp where sal > 3000\n*\nERROR at line 1:\nORA-01031: insufficient privileges","checkContent":"To verify the current status of the SQL92_SECURITY parameter use the SQL statement: \n\nIf using a non-CDB database: \nFrom SQL*Plus:\n\nselect value from v$parameter where name = 'sql92_security';\n\nIf using a CDB database:\nFrom SQL*Plus:\n\ncolumn name format a20\ncolumn parameter_value format a20\n\nSELECT name, inst_id, con_id, value AS PARAMETER_VALUE \nFROM sys.gv_$parameter \nWHERE name = 'sql92_security' \nORDER BY 1;\n\nCheck Result:\n\nThe CDB database and all PDBs must be checked.\n\nIf the value returned is set to FALSE, this is a finding.\n\nIf the parameter is set to TRUE or does not exist, this is not a finding.\n\nIn any instance or container, if the PARAMETER_VALUE is not TRUE, that is a finding.","fixText":"Enable SQL92 security.\n\nFrom SQL*Plus:\n\nalter system set sql92_security = TRUE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-270526","ruleId":"SV-270526r1115966_rule","severity":"medium","ruleTitle":"The Oracle password file ownership and permissions should be limited and the REMOTE_LOGIN_PASSWORDFILE parameter must be set to EXCLUSIVE or NONE.","description":"It is critically important to the security of the system to protect the password file and the environment variables that identify the location of the password file. Any user with access to these could potentially compromise the security of the connection. \n\nThe REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of \"EXCLUSIVE\" allows for auditing of individual database administrator (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.","checkContent":"To verify the current status of the REMOTE_LOGIN_PASSWORDFILE parameter: \n\nIf using a non-CDB database:\n\nFrom SQL*Plus:\n\nselect value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\nIf the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a finding.\n\nIf using a CDB database:\n\nFrom SQL*Plus:\n\nTo verify the current status of the remote_login_passwordfile parameter use the SQL statement:\n\ncolumn name format a25\ncolumn parameter_value format a25\n\nSELECT name, inst_id, con_id, value AS PARAMETER_VALUE \nFROM sys.gv_$parameter \nWHERE name = 'REMOTE_LOGIN_PASSWORDFILE' \nORDER BY 1;\n\nIn any instance or container, if the PARAMETER_VALUE is set to SHARED, or to a value other than EXCLUSIVE or NONE, that is a finding.\n\nCheck the security permissions on password file within the OS.\n\nOn Unix Systems:\n\nls -ld $ORACLE_HOME/dbs/orapw${ORACLE_SID}\n\nSubstitute ${ORACLE_SID} with the name of the ORACLE_SID for the database.\n\nIf permissions are granted for world access, this is a finding.\n\nOn Windows Systems (from Windows Explorer), browse to the %ORACLE_HOME%\\database\\directory.\n\nSelect and right-click on the PWD%ORACLE_SID%.ora file, select Properties, then select the Security tab.\n\nSubstitute %ORACLE_SID% with the name of the ORACLE_SID for the database.\n\nIf permissions are granted to everyone, this is a finding.\n\nIf any account other than the database management system (DBMS) software installation account is listed, this is a finding.","fixText":"Disable use of the REMOTE_LOGIN_PASSWORDFILE where remote administration is not authorized by specifying a value of NONE.\n\nIf authorized, restrict use of a password file to exclusive use by each database by specifying a value of EXCLUSIVE.\n\nFrom SQL*Plus:\n\nalter system set REMOTE_LOGIN_PASSWORDFILE = 'EXCLUSIVE' scope = spfile;\n\nOR\n\nalter system set REMOTE_LOGIN_PASSWORDFILE = 'NONE' scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.\n\nRestrict ownership and permissions on the Oracle password file to exclude world (Unix) or everyone (Windows).\n\nMore information regarding the ORAPWD file and the REMOTE_LOGIN_PASSWORDFILE parameter can be found here:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/REMOTE_LOGIN_PASSWORDFILE.html","ccis":["CCI-000366"]},{"vulnId":"V-270527","ruleId":"SV-270527r1065266_rule","severity":"medium","ruleTitle":"System privileges granted using the WITH ADMIN OPTION must not be granted to unauthorized user accounts.","description":"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 database administrators (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.","checkContent":"A default Oracle Database installation provides a set of predefined administrative accounts and nonadministrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the CREATE ANY TABLE or ALTER SESSION privilege or EXECUTE privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Nonadministrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNonadministrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n*Subject to change based on version installed.\n\nRun the SQL query:\n\nFrom SQL*Plus:\nselect grantee, privilege from dba_sys_privs \nwhere grantee not in ()\nand admin_option = 'YES'\nand grantee not in\n(select grantee from dba_role_privs where granted_role = 'DBA');\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nIf any accounts that are not authorized to have the ADMIN OPTION are listed, this is a finding.","fixText":"Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and regrant them without the option.\n\nFrom SQL*Plus:\n\nrevoke [privilege name] from user [username];\n\nReplace [privilege name] with the named privilege and [username] with the named user.\n\nRestrict use of the WITH ADMIN OPTION to authorized administrators.\n\nDocument authorized privilege assignments with the WITH ADMIN OPTION in the system documentation.","ccis":["CCI-000366"]},{"vulnId":"V-270528","ruleId":"SV-270528r1064862_rule","severity":"medium","ruleTitle":"System Privileges must not be granted to PUBLIC.","description":"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.","checkContent":"From SQL*Plus:\n\nSelect privilege from dba_sys_privs where grantee = 'PUBLIC';\n\nIf any records are returned, this is a finding.","fixText":"Revoke any system privileges assigned to PUBLIC:\n\nFrom SQL*Plus:\n\nrevoke [system privilege] from PUBLIC;\n\nReplace [system privilege] with the named system privilege.\n\nNote: System privileges are not granted to PUBLIC by default and would indicate a custom action.","ccis":["CCI-000366"]},{"vulnId":"V-270529","ruleId":"SV-270529r1065268_rule","severity":"medium","ruleTitle":"Oracle roles granted using the WITH ADMIN OPTION must not be granted to unauthorized accounts.","description":"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 database administrators (DBAs), object owners, and application administrators (where designed and included in the application's functions). Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.","checkContent":"A default Oracle Database installation provides a set of predefined administrative accounts and nonadministrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the CREATE ANY TABLE or ALTER SESSION privilege or EXECUTE privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Nonadministrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNon-Administrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n*Subject to change based on version installed.\n\nRun the SQL statement:\n\nselect grantee||': '||granted_role from dba_role_privs\nwhere grantee not in\n()\nand admin_option = 'YES' \nand grantee not in\n(select distinct owner from dba_objects)\nand grantee not in\n(select grantee from dba_role_privs\nwhere granted_role = 'DBA')\norder by grantee;\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nReview the system documentation to confirm any grantees listed are information system security officer (ISSO)-authorized DBA accounts or application administration roles.\n\nIf any grantees listed are not authorized and documented, this is a finding.","fixText":"Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and regrant them without the option if required.\n\nSQL statements to remove the admin option from an unauthorized grantee:\nrevoke from ;\ngrant to ;\n\nRestrict use of the WITH ADMIN OPTION to authorized administrators.\n\nDocument authorized role assignments with the WITH ADMIN OPTION in the system documentation.","ccis":["CCI-000366"]},{"vulnId":"V-270530","ruleId":"SV-270530r1065320_rule","severity":"medium","ruleTitle":"Object permissions granted to PUBLIC must be restricted.","description":"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.","checkContent":"A default Oracle Database installation provides a set of predefined administrative accounts and nonadministrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the \"CREATE ANY TABLE\" or \"ALTER SESSION\" privilege, or \"EXECUTE\" privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either \"SYSTEM\" or \"SYSAUX\". Nonadministrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is \"USERS\".\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNon-Administrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, , GSMADMIN_INTERNAL, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n* Subject to change based on version installed.\n\nRun the SQL query:\n\nselect owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\nwhere grantee = 'PUBLIC'\nand owner not in\n();\n\nWith respect to the list of special accounts that are excluded from this requirement, it is expected that the database administrator (DBA) will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.\n\nIf there are any records returned that are not Oracle product accounts, and are not documented and authorized, this is a finding.\n\nNote: This check may return false positives where other Oracle product accounts are not included in the exclusion list.","fixText":"Revoke any privileges granted to PUBLIC for objects that are not owned by Oracle product accounts.\n\nFrom SQL*Plus:\n\nrevoke [privilege name] from [username] on [object name];\n\nAssign permissions to custom application user roles based on job functions:\n\nFrom SQL*Plus:\n\ngrant [privilege name] to [user role] on [object name];","ccis":["CCI-000366"]},{"vulnId":"V-270531","ruleId":"SV-270531r1065272_rule","severity":"high","ruleTitle":"The Oracle Listener must be configured to require administration authentication.","description":"Oracle listener authentication helps prevent unauthorized administration of the Oracle listener. Unauthorized administration of the listener could lead to denial-of-service (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.","checkContent":"If a listener is not running on the local database host server, this check is not a finding.\n\nNote: Complete this check only once per host system and once per listener. Multiple listeners may be defined on a single host system. They must all be reviewed, but only once per database home review.\n\nFor subsequent database home reviews on the same host system, this check is not a finding.\n\nDetermine all listeners running on the host.\n\nFor Windows hosts, view all Windows services with TNSListener embedded in the service name:\n\n- The service name format is:\nOracle[ORACLE_HOME_NAME]TNSListener\n\nFor Unix hosts, the Oracle Listener process will indicate the TNSLSNR executable.\n\nAt a command prompt, issue the command:\nps -ef | grep tnslsnr | grep -v grep\n\nThe alias for the listener follows tnslsnr in the command output.\n\nMust be logged on the host system using the account that owns the tnslsnr executable (Unix). If the account is denied local logon, have the system administrator (SA) assist in this task by adding \"su\" to the listener account from the root account. On Windows platforms, log on using an account with administrator privileges to complete the check.\n\nFrom a system command prompt, execute the listener control utility:\n\nlsnrctl status [LISTENER NAME]\n\nReview the results for the value of Security.\n\nIf \"Security = OFF\" is displayed, this is a finding.\n\nIf \"Security = ON: Password or Local OS Authentication\", this is a finding (Instead, use Local OS Authentication).\n\nIf \"Security = ON: Local OS Authentication\" is displayed, this is not a finding.\n\nRepeat the execution of the lsnrctl utility for all active listeners.","fixText":"By default, Oracle Net Listener permits only local administration for security reasons. As a policy, the listener can be administered only by the user who started it. \n\nOracle Listener authentication is enforced through local operating system authentication. For example, if user1 starts the listener, then only user1 can administer it. Any other user trying to administer the listener receives an error. The super user is the only exception.\n\nRemote administration of the listener must not be permitted. If listener administration from a remote system is required, granting secure remote access to the Oracle database management system (DBMS) server and performing local administration is preferred. Authorize and document this requirement in the system documentation.\n\nRefer to Oracle Database Net Services Reference for additional information.","ccis":["CCI-000366"]},{"vulnId":"V-270532","ruleId":"SV-270532r1064874_rule","severity":"medium","ruleTitle":"Application role permissions must not be assigned to the Oracle PUBLIC role.","description":"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.","checkContent":"From SQL*Plus:\n\nselect granted_role from dba_role_privs where grantee = 'PUBLIC';\n\nIf any roles are listed, this is a finding.","fixText":"Revoke role grants from PUBLIC.\n\nDo not assign role privileges to PUBLIC.\n\nFrom SQL*Plus:\n\nrevoke [role name] from PUBLIC;","ccis":["CCI-000366"]},{"vulnId":"V-270533","ruleId":"SV-270533r1065215_rule","severity":"medium","ruleTitle":"Oracle application administration roles must be disabled if not required and authorized.","description":"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.","checkContent":"Run the SQL query:\n\nselect grantee, granted_role from dba_role_privs\nwhere default_role='YES'\nand granted_role in\n(select grantee from dba_sys_privs where upper(privilege) like '%USER%') \nand grantee not in\n()\nand grantee not in (select distinct owner from dba_tables)\nand grantee not in\n(select distinct username from dba_users where upper(account_status) like\n'%LOCKED%');\n\nWith respect to the list of special accounts that are excluded from this requirement, it is expected that the database administrator (DBA) will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.\n\nReview the list of accounts reported for this check and ensures that they are authorized application administration roles.\n\nIf any are not authorized application administration roles, this is a finding.","fixText":"For each role assignment returned, issue:\n\nFrom SQL*Plus:\n\nalter user [username] default role all except [role];\n\nIf the user has more than one application administration role assigned, then remove assigned roles from default assignment and assign individually the appropriate default roles.","ccis":["CCI-000366"]},{"vulnId":"V-270534","ruleId":"SV-270534r1065274_rule","severity":"medium","ruleTitle":"The directories assigned to the LOG_ARCHIVE_DEST* parameters must be protected from unauthorized access.","description":"The LOG_ARCHIVE_DEST parameter is used to specify the directory to which Oracle archive logs are written. Where the database management system (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.","checkContent":"From SQL*Plus:\n\nselect log_mode from v$database;\nselect value from v$parameter where name = 'log_archive_dest';\nselect value from v$parameter where name = 'log_archive_duplex_dest';\nselect name, value from v$parameter where name LIKE 'log_archive_dest_%';\nselect value from v$parameter where name = 'db_recovery_file_dest';\n\nIf the value returned for LOG_MODE is NOARCHIVELOG, this check is not a finding.\n\nIf a value is not returned for LOG_ARCHIVE_DEST and no values are returned for any of the LOG_ARCHIVE_DEST_[1-10] parameters, and no value is returned for DB_RECOVERY_FILE_DEST, this is a finding.\n\nNote: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ') when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string.\n\nOn Unix Systems:\n\nls -ld [pathname]\n\nSubstitute [pathname] with the directory paths listed from the above SQL statements for log_archive_dest and log_archive_duplex_dest.\n\nIf permissions are granted for world access, this is a finding.\n\nOn Windows systems (from Windows Explorer):\n\nBrowse to the directory specified.\n\nSelect and right-click on the directory >> Properties >> Security tab.\n\nIf permissions are granted to everyone, this is a finding.\n\nIf any account other than the Oracle process and software owner accounts, administrators, database administrators (DBAs), system group, or developers authorized to write and debug applications on this database are listed, this is a finding.","fixText":"Specify a valid and protected directory for archive log files.\n\nRestrict access to the Oracle process and software owner accounts, DBAs, and backup operator accounts.","ccis":["CCI-000366"]},{"vulnId":"V-270535","ruleId":"SV-270535r1065307_rule","severity":"medium","ruleTitle":"The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to FALSE.","description":"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.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = '_trace_files_public';\n\nIf the value returned is TRUE, this is a finding.\n\nIf the parameter does not exist or is set to FALSE, this is not a finding.","fixText":"From SQL*Plus (shutdown database instance):\n\nshutdown immediate\n\nFrom SQL*Plus (create a pfile from spfile):\n\ncreate pfile='[PATH]init[SID].ora' from spfile;\n\nEdit the init[SID].ora file and remove the following line:\n\n*._trace_files_public=TRUE\n\nFrom SQL*Plus (update the spfile using the pfile):\n\ncreate spfile from pfile='[PATH]init[SID].ora';\n\nFrom SQL*Plus (start the database instance):\n\nstartup\n\nNote: [PATH] depends on the platform (Windows or Unix).\n\nEnsure the file is directed to a writable location.\n\n[SID] is equal to the oracle SID or database instance ID.","ccis":["CCI-000366"]},{"vulnId":"V-270536","ruleId":"SV-270536r1064886_rule","severity":"medium","ruleTitle":"Oracle Database production application and data directories must be protected from developers on shared production/development database management system (DBMS) host systems.","description":"Developer roles must not be assigned DBMS administrative privileges to production DBMS application and data directories. The separation of production database administrator (DBA) and developer roles helps protect the production system from unauthorized, malicious, or unintentional interruption due to development activities.","checkContent":"If the DBMS or DBMS host is not shared by production and development activities, this check is not a finding.\n\nReview OS DBA group membership.\n\nIf any developer accounts, as identified in the system documentation, have been assigned DBA privileges, this is a finding.\n\nNote: Though shared production/nonproduction DBMS installations was allowed under previous database STIG guidance, doing so may place it in violation of OS, Application, Network, or Enclave STIG guidance. Ensure that any shared production/nonproduction DBMS installation meets STIG guidance requirements at all levels or mitigates any conflicts in STIG guidance with the authorizing official (AO).","fixText":"Create separate DBMS host OS groups for developer and production DBAs.\n\nDo not assign production DBA OS group membership to accounts used for development.\n\nRemove development accounts from production DBA OS group membership.\n\nRecommend establishing a dedicated DBMS host for production DBMS installations. A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.","ccis":["CCI-000366"]},{"vulnId":"V-270537","ruleId":"SV-270537r1064889_rule","severity":"medium","ruleTitle":"Use of the Oracle Database installation account must be logged.","description":"The database management system (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.","checkContent":"Review documented and implemented procedures for monitoring the use of the DBMS software installation account in the system documentation.\n\nIf use of this account is not monitored or procedures for monitoring its use do not exist or are incomplete, this is a finding.\n\nNote: On Windows systems, the Oracle DBMS software is installed using an account with administrator privileges. Ownership should be reassigned to a dedicated OS account used to operate the DBMS software. If monitoring does not include all accounts with administrator privileges on the DBMS host, this is a finding.","fixText":"Develop, document, and implement a logging procedure for use of the DBMS software installation account that provides accountability to individuals for any actions taken by the account.\n\nHost system audit logs should be included in the DBMS account usage log along with an indication of the person who accessed the account and an explanation for the access.\n\nEnsure all accounts with administrator privileges are monitored for DBMS host on Windows OS platforms.","ccis":["CCI-000366"]},{"vulnId":"V-270538","ruleId":"SV-270538r1064892_rule","severity":"medium","ruleTitle":"The Oracle Database data files, transaction logs and audit files must be stored in dedicated directories or disk partitions separate from software or other application files.","description":"Protection of database management system (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, resource contention and security controls are required to isolate and protect an application's data from other applications. In addition, it is an Oracle best practice to separate data, transaction logs, and audit logs into separate physical directories according to Oracle's Optimal Flexible Architecture (OFA). And finally, DBMS software libraries and configuration files also require differing access control lists.","checkContent":"Review the disk/directory specification where database data, transaction log and audit files are stored.\n\nIf DBMS data, transaction log or audit data files are stored in the same directory, this is a finding.\n\nIf multiple applications are accessing the database and the database data files are stored in the same directory, this is a finding.\n\nIf multiple applications are accessing the database and database data is separated into separate physical directories according to application, this check is not a finding.","fixText":"Specify dedicated host system disk directories to store database data, transaction and audit files.\n\nExample directory structure:\n/*/app/oracle/oradata/db_name\n/*/app/oracle/admin/db_name/arch/*\n/*/app/oracle/oradata/db_name/audit\n/*/app/oracle/fast_recovery_area/db_name/\n\nWhen multiple applications are accessing a single database, configure DBMS default file storage according to application to use dedicated disk directories. \n\n/*/app/oracle/oradata/db_name/app_name\n\nRefer to Oracle Optimal Flexible Architecture:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/optimal-flexible-architecture.html","ccis":["CCI-000366"]},{"vulnId":"V-270539","ruleId":"SV-270539r1064895_rule","severity":"medium","ruleTitle":"Network access to Oracle Database must be restricted to authorized personnel.","description":"Restricting remote access to specific, trusted systems helps prevent access by unauthorized and potentially malicious users.","checkContent":"IP address restriction may be defined for the database listener, by use of the Oracle Connection Manager or by an external network device.\n\nIdentify the method used to enforce address restriction (interview database administrator [DBA]) or review system documentation).\n\nIf enforced by the database listener, then review the SQLNET.ORA file located in the ORACLE_HOME/network/admin directory (this assumes that a single sqlnet.ora file, in the default location, is in use; SQLNET.ORA could also be the directory indicated by the TNS_ADMIN environment variable or registry setting).\n\nIf the following entries do not exist, then restriction by IP address is not configured and is a finding.\n\ntcp.validnode_checking=YES\ntcp.invited_nodes=(IP1, IP2, IP3)\n\nIf enforced by an Oracle Connection Manager, then review the CMAN.ORA file for the Connection Manager (located in the TNS_ADMIN or ORACLE_HOME/network/admin directory for the connection manager).\n\nIf a RULE entry allows all addresses (\"/32\") or does not match the address range specified in the system documentation, this is a finding.\n\n(rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept))\n\nNote: An IP address with a \"/\" indicates acceptance by subnet mask where the number after the \"/\" is the left most number of bits in the address that must match for the rule to apply.","fixText":"Configure the database listener to restrict access by IP address or set up an external device to restrict network access to the DBMS.\n\nMore information can be found at https://docs.oracle.com/en/database/oracle/oracle-database/19/netrf/parameters-for-the-sqlnet.ora.html#GUID-5C3AB641-7541-4CE9-BC9E-BA5DD30616A8.","ccis":["CCI-000366"]},{"vulnId":"V-270540","ruleId":"SV-270540r1064898_rule","severity":"medium","ruleTitle":"Changes to configuration options must be audited.","description":"When standard auditing is in use, 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.","checkContent":"For Unified or mixed auditing, from SQL*Plus:\n\nselect count(*) from audit_unified_enabled_policies where entity_name = 'SYS';\n\nIf the count is less than one row, this is a finding.\n\nFor Standard auditing, from SQL*Plus:\n\nselect value from v$parameter where name = 'audit_sys_operations';\n\nIf the value returned is FALSE, this is a finding.","fixText":"For Standard auditing, from SQL*Plus:\n\nalter system set audit_sys_operations = TRUE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.\n\nIf Unified Auditing is used, to ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor additional information on creating audit policies, refer to the Oracle Database Security Guide:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/configuring-audit-policies.html","ccis":["CCI-000366"]},{"vulnId":"V-270541","ruleId":"SV-270541r1065276_rule","severity":"medium","ruleTitle":"The /diag subdirectory under the directory assigned to the DIAGNOSTIC_DEST parameter must be protected from unauthorized access.","description":"/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.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name='diagnostic_dest';\n\nOn Unix Systems:\n\nls -ld [pathname]/diag\n\nSubstitute [pathname] with the directory path listed from the above SQL command, and append \"/diag\" to it, as shown.\n\nIf permissions are granted for world access, this is a finding.\n\nIf any groups that include members other than the Oracle process and software owner accounts, DBAs, auditors, or backup accounts are listed, this is a finding.\n\nOn Windows Systems (from Windows Explorer):\n\nBrowse to the \\diag directory under the directory specified.\n\nSelect and right-click on the directory >> Properties >> Security tab.\n\nIf permissions are granted to everyone, this is a finding.\n\nIf any account other than the Oracle process and software owner accounts, administrators, database administrators (DBAs), system group or developers authorized to write and debug applications on this database are listed, this is a finding.","fixText":"Alter host system permissions to the /diag directory to the Oracle process and software owner accounts, DBAs, system administrators (SAs) (if required), and developers or other users that may specifically require access for debugging or other purposes.\n\nAuthorize and document user access requirements to the directory outside of the Oracle, DBA, and SA account list.","ccis":["CCI-000366"]},{"vulnId":"V-270542","ruleId":"SV-270542r1064904_rule","severity":"medium","ruleTitle":"Remote administration must be disabled for the Oracle connection manager.","description":"Remote administration provides a potential opportunity for malicious users to make unauthorized changes to the Connection Manager configuration or interrupt its service.","checkContent":"View the cman.ora file in the ORACLE_HOME/network/admin directory.\n\nIf the file does not exist, the database is not accessed via Oracle Connection Manager and this check is not a finding.\n\nIf the entry and value for REMOTE_ADMIN is not listed or is not set to a value of NO (REMOTE_ADMIN = NO), this is a finding.","fixText":"View the cman.ora file in the ORACLE_HOME/network/admin directory of the Connection Manager.\n\nInclude the following line in the file:\n\nREMOTE_ADMIN = NO","ccis":["CCI-000366"]},{"vulnId":"V-270543","ruleId":"SV-270543r1064907_rule","severity":"medium","ruleTitle":"Network client connections must be restricted to supported versions.","description":"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.","checkContent":"Note: The SQLNET.ALLOWED_LOGON_VERSION parameter is deprecated in earlier Oracle Database versions. This parameter has been replaced with two new Oracle Net Services parameters:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT\n\nView the SQLNET.ORA file in the ORACLE_HOME/network/admin directory or the directory specified in the TNS_ADMIN environment variable. \n\nLocate the following entries:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER = 12\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12\n\nIf the parameters do not exist, this is a finding.\n\nIf the parameters are not set to a value of 12 or 12a, this is a finding.\n\nNote: Attempting to connect with a client version lower than specified in these parameters may result in a misleading error:\nORA-01017: invalid username/password: logon denied","fixText":"Edit the SQLNET.ORA file to add or edit the entries:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER = 12\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12\n\nSet the value to 12 or higher.\nValid values for SQLNET.ALLOWED_LOGON_VERSION_SERVER are: 12 and 12a\n\nValid values for SQLNET.ALLOWED_LOGON_VERSION_CLIENT are: 12 and 12a\n\nFor more information on sqlnet.ora parameters refer to the following document:\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/netrf/parameters-for-the-sqlnet.ora.html","ccis":["CCI-000366"]},{"vulnId":"V-270544","ruleId":"SV-270544r1065278_rule","severity":"high","ruleTitle":"Database administrator (DBA) OS accounts must be granted only those host system privileges necessary for the administration of the Oracle Database.","description":"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 nonprivileged account.\n\nDBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.","checkContent":"Review host system privileges assigned to the Oracle DBA group and all individual Oracle DBA accounts.\n\nNote: Do not include the Oracle software installation account in any results for this check.\n\nFor Unix systems (as root):\ncat /etc/group | grep -i dba\ngroups root\n\nIf \"root\" is returned in the first list, this is a finding.\n\nIf any accounts listed in the first list are also listed in the second list, this is a finding.\n\nInvestigate any user account group memberships other than DBA or root groups that are returned by the following command (also as root):\n\ngroups [dba user account]\n\nReplace [dba user account] with the user account name of each DBA account.\n\nIf individual DBA accounts are assigned to groups that grant access or privileges for purposes other than DBA responsibilities, this is a finding.\n\nFor Windows systems, click Start >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Groups >> ORA_DBA.\n\nStart >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Groups >> ORA_[SID]_DBA (if present).\n\nNote: Users assigned DBA privileges on a Windows host are granted membership in the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA privileges to specific Oracle instances only.\n\nMake a note of each user listed. For each user, click Start >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Users >> [DBA username] >> Member of.\n\nIf DBA users belong to any groups other than DBA groups and the Windows Users group, this is a finding.\n\nExamine User Rights assigned to DBA groups or group members by clicking Start >> Settings >> Control Panel >> Administrative Tools >> Local Security Policy >> Security Settings >> Local Policies >> User Rights Assignments.\n\nIf any User Rights are assigned directly to the DBA group(s) or DBA user accounts, this is a finding.","fixText":"Revoke all host system privileges from the DBA group accounts and DBA user accounts not required for database management system (DBMS) administration.\n\nRevoke all OS group memberships that assign excessive privileges to the DBA group accounts and DBA user accounts.\n\nRemove any directly applied permissions or user rights from the DBA group accounts and DBA user accounts.\n\nDocument all DBA group accounts and individual DBA account-assigned privileges in the system documentation.","ccis":["CCI-000366"]},{"vulnId":"V-270545","ruleId":"SV-270545r1064913_rule","severity":"high","ruleTitle":"Oracle Database default accounts must be assigned custom passwords.","description":"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.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne 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.\n\nDatabase management system (DBMS) default passwords provide a commonly known and exploited means for unauthorized access to database installations.","checkContent":"Use this query to identify the Oracle-supplied accounts that still have their default passwords:\n\nSELECT * FROM SYS.DBA_USERS_WITH_DEFPWD;\n\nIf any accounts other than XS$NULL are listed, this is a finding.\n\nXS$NULL is an internal account that represents the absence of a user in a session. Because XS$NULL is not a user, this account can only be accessed by the Oracle Database instance. XS$NULL has no privileges and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.","fixText":"Change passwords for database management system (DBMS) accounts to nondefault values. Where necessary, unlock or enable accounts to change the password, and then return the account to disabled or locked status.","ccis":["CCI-000366"]},{"vulnId":"V-270546","ruleId":"SV-270546r1112478_rule","severity":"medium","ruleTitle":"Oracle Database must provide a mechanism to automatically identify accounts designated as temporary or emergency accounts.","description":"Temporary application accounts could be used in the event of a vendor support visit where a support representative requires a temporary unique account 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.\n\nTo address this in the event temporary application accounts are required, the application must automatically terminate temporary 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.\n\nNote 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.\n\nTemporary database accounts must be identified in order for the system to recognize and terminate them after a given time period. The database management system (DBMS) and any administrators must have a means to recognize any temporary accounts for special handling.","checkContent":"If the organization has a policy, consistently enforced, forbidding the creation of emergency or temporary accounts, this is not a finding.\n\nIf all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism and not by Oracle, this is not a finding.\n\nIf using the database to identify temporary accounts, and temporary accounts exist, there should be a temporary profile. If a profile for temporary accounts cannot be identified, this is a finding.\n\nTo check for a temporary profile, run the scripts below:\n\nTo obtain a list of profiles:\n\nSELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\nTo obtain a list of users assigned a given profile (TEMPORARY_USERS, in this example):\n\nSELECT USERNAME, PROFILE FROM SYS.DBA_USERS\nWHERE PROFILE = 'TEMPORARY_USERS'\nORDER BY USERNAME;","fixText":"Use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a temporary user account is created, assign it to this profile.\n\nTo enable resource limiting via profiles, use the SQL statement:\n\nALTER SYSTEM SET RESOURCE_LIMIT = TRUE;\n\nSet values in the profile as needed for temporary users; refer to below for further information. The values here are examples; set them to values appropriate to the situation:\n\nCREATE PROFILE TEMPORARY_USERS\nLIMIT\nSESSIONS_PER_USER ........... \nCPU_PER_SESSION ............. \nCPU_PER_CALL ................ \nCONNECT_TIME ................ \nLOGICAL_READS_PER_SESSION ... DEFAULT\nLOGICAL_READS_PER_CALL ...... \nPRIVATE_SGA ................. \nCOMPOSITE_LIMIT ............. \nFAILED_LOGIN_ATTEMPTS ....... 3\nPASSWORD_LIFE_TIME .......... 7\nPASSWORD_REUSE_TIME ......... 60\nPASSWORD_REUSE_MAX .......... 5\nPASSWORD_VERIFY_FUNCTION .... ORA12c_STIG_VERIFY_FUNCTION\nPASSWORD_LOCK_TIME .......... UNLIMITED\nPASSWORD_GRACE_TIME ......... 3;\n\nCREATE USER IDENTIFIED BY PROFILE TEMPORARY_USERS;\n\nResource Parameters:\n\nCOMPOSITE_LIMIT - Specify the total resource cost for a session, expressed in service units. Oracle Database calculates the total service units as a weighted sum of CPU_PER_SESSION, CONNECT_TIME,LOGICAL_READS_PER_SESSION, and PRIVATE_SGA.\n\nSESSIONS_PER_USER - Specify the number of concurrent sessions to limit the user to.\n\nCPU_PER_SESSION - Specify the CPU time limit for a session, expressed in hundredths of seconds.\n\nCPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds.\n\nLOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in a session, including blocks read from memory and disk.\n\nLOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch).\n\nPRIVATE_SGA - Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA). Refer to size_clause for information on that clause.\n\nCONNECT_TIME - Specify the total elapsed time limit for a session, expressed in minutes.\n\nIDLE_TIME - Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit.\n\nCOMPOSITE_LIMIT - Refer to Oracle documentation for more details.\n\nPassword Parameters: Use the following clauses to set password parameters. Parameters that set lengths of time are interpreted in number of days. For testing purposes, specify minutes (n/1440) or even seconds (n/86400).\n\nFAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log on to the user account before the account is locked. If omitting this clause, then the default is 10.\n\nPASSWORD_LIFE_TIME - Specify the number of days the same password can be used for authentication. If setting a value for PASSWORD_GRACE_TIME, then the password expires if it is not changed within the grace period, and further connections are rejected. If omitting this clause, then the default is 180 days.\n\nPASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. For these parameters to have any effect, specify an integer for both of them.\n\nIf specifying a value for both of these parameters, then the user cannot reuse a password until the password has been changed the number of times specified for PASSWORD_REUSE_MAX during the number of days specified for PASSWORD_REUSE_TIME.\n\nFor example, if specifying PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to 10, then the user can reuse the password after 30 days if the password has already been changed 10 times.\n\nIf specifying a value for either of these parameters and specify UNLIMITED for the other, then the user can never reuse a password.\n\nIf specifying DEFAULT for either parameter, then Oracle Database uses the value defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED in the DEFAULT profile. If the default setting of UNLIMITED in the DEFAULT profile has not changed, then the database treats the value for that parameter as UNLIMITED.\n\nIf setting both of these parameters to UNLIMITED, then the database ignores both of them. This is the default if omitting both parameters.\n\nPASSWORD_LOCK_TIME - Specify the number of days an account will be locked after the specified number of consecutive failed logon attempts. If omitting this clause, then the default is one day.\n\nPASSWORD_GRACE_TIME - Specify the number of days after the grace period begins during which a warning is issued and logon is allowed. If omitting this clause, then the default is seven days.\n\nPASSWORD_VERIFY_FUNCTION – This clause allows a PL/SQL password complexity verification script to be passed as an argument to the CREATE PROFILE statement. Oracle Database provides a default script, but users can create their own routine or use third-party software instead.","ccis":["CCI-000366"]},{"vulnId":"V-270547","ruleId":"SV-270547r1064919_rule","severity":"medium","ruleTitle":"Oracle Database must provide a mechanism to automatically remove or disable temporary user accounts after 72 hours.","description":"Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account 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.\n\nTo address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature must automatically terminate these accounts after a period of 72 hours. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised.\n\nNote 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.\n\nTemporary database accounts must be automatically terminated after a 72-hour time period to mitigate the risk of the account being used beyond its original purpose or timeframe.","checkContent":"If the organization has a policy, consistently enforced, forbidding the creation of emergency or temporary accounts, this is not a finding.\n\nIf all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nCheck database management system (DBMS) settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if the site uses a mechanism whereby temporary are terminated after a 72-hour time period. If not, this is a finding.","fixText":"If using database mechanisms to satisfy this requirement, use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a temporary user account is created, assign it to this profile.\n\nCreate a job to lock accounts under this profile that are more than 72 hours old.","ccis":["CCI-000366"]},{"vulnId":"V-270548","ruleId":"SV-270548r1064922_rule","severity":"medium","ruleTitle":"Oracle Database must be protected from unauthorized access by developers on shared production/development host systems.","description":"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.\n\nDevelopers 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.","checkContent":"Identify whether any hosts contain both development and production databases. If no hosts contain both production and development databases, this is Not Applicable.\n\nFor any host containing both a development and a production database, determine if developers have been granted elevated privileges on the production database or on the OS. If they have, ask for documentation that shows these accounts have formal approval and risk acceptance. If this documentation does not exist, this is a finding.\n\nIf developer accounts exist with the right to create and maintain tables (or other database objects) in production tablespaces, this is a finding.\n\nTo check the number of instances on the host machine where applicable, check the /etc/oratab. The /etc/oratab file is updated by the Oracle Installer when the database is installed when the root.sh file is executed. Each line in the represents an ORACLE_SID:ORACLE_HOME:Y or N. The ORACLE_SID and ORACLE_HOME are self-explanatory. The Y or N signals the DBSTART program to automatically start or not start that specific instance when the machine is restarted. Check with the system owner and application development team to find what each entry represents. If a system is deemed to be a production system, review the system for development users.","fixText":"Restrict developer privileges to production objects to only objects and data where those privileges are required and authorized. Document the approval and risk acceptance.\n\nConsider using separate accounts for a person's developer duties and production duties. At a minimum, use separate roles for developer privileges and production privileges.\n\nIf developers need the ability to create and maintain tables (or other database objects) as part of their development activities, provide dedicated tablespaces, and revoke any rights that allowed them to use production tablespaces for this purpose.","ccis":["CCI-000366"]},{"vulnId":"V-270549","ruleId":"SV-270549r1112480_rule","severity":"medium","ruleTitle":"Oracle Database must verify account lockouts persist until reset by an administrator.","description":"Anytime an authentication method is exposed, to allow for the use of an application, there is a risk that attempts will be made to obtain unauthorized access.\n\nTo 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.\n\nBy 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.\n\nNote 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.","checkContent":"The account lockout duration is defined in the profile assigned to a user.\n\nTo verify what profile is assigned to a user, enter the query:\n\nSQL>SELECT profile FROM dba_users WHERE username = ''\n\nThis will return the profile name assigned to that user.\n\nThe user profile, ORA_STIG_PROFILE, has been provided to satisfy the STIG requirements pertaining to the profile parameters. Oracle recommends that this profile be customized with any site-specific requirements and assigned to all users where applicable. Note: It remains necessary to create a customized replacement for the password validation function, ORA12C_STIG_VERIFY_FUNCTION, if relying on this technique to verify password complexity.\n\nNow check the values assigned to the profile returned from the query above:\n\ncolumn profile format a20\ncolumn limit format a20\n\nSQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE = 'ORA_STIG_PROFILE';\n\nCheck the settings for password_lock_time - this specifies how long to lock the account after the number of consecutive failed logon attempts reaches the limit. If the value is not UNLIMITED, this is a finding.","fixText":"Configure the database management system (DBMS) settings to specify indefinite lockout duration:\n\nALTER PROFILE ORA_STIG_PROFILE LIMIT PASSWORD_LOCK_TIME UNLIMITED;","ccis":["CCI-000366"]},{"vulnId":"V-270550","ruleId":"SV-270550r1112482_rule","severity":"medium","ruleTitle":"Oracle Database must set the maximum number of consecutive invalid logon attempts to three.","description":"Anytime an authentication method is exposed, to allow for the use of an application, there is a risk that attempts will be made to obtain unauthorized access.\n\nTo 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.\n\nBy 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.\n\nMore 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.\n\nNote 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.\n\nNote also that a policy that places no limit on the length of the timeframe (for counting consecutive invalid attempts) does satisfy this requirement.","checkContent":"The limit on the number of consecutive failed logon attempts is defined in the profile assigned to a user.\n\nCheck the FAILED_LOGIN_ATTEMPTS value assigned to the profiles returned from this query:\n\nSQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES;\n\nCheck the setting for FAILED_LOGIN_ATTEMPTS. This is the number of consecutive failed logon attempts before locking the Oracle user account. If the value is greater than three on any of the profiles, this is a finding.","fixText":"Configure the database management system (DBMS) setting to specify the maximum number of consecutive failed logon attempts to three (or less):\n\nALTER PROFILE {PROFILE_NAME} LIMIT FAILED_LOGIN_ATTEMPTS 3;\n\nORA_STIG_PROFILE is available in DBA_PROFILES. \n\nNote: It is necessary to create a customized replacement for the password validation function, ORA12C_STIG_VERIFY_FUNCTION, if relying on this technique to verify password complexity.","ccis":["CCI-000366"]},{"vulnId":"V-270551","ruleId":"SV-270551r1112483_rule","severity":"medium","ruleTitle":"Oracle Database must disable user accounts after 35 days of inactivity.","description":"Attackers that are able to exploit an inactive database management system (DBMS) account can potentially obtain and maintain undetected access to the database. \n\nOwners of inactive DBMS accounts will not notice if unauthorized access to their user account has been obtained. All DBMS need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.\n\nTo address access requirements, some database administrators choose to integrate their databases with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the database administrator to off-load those access control functions and focus on core application features and functionality. \n\nThis policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local logon administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.\n\nNote 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.","checkContent":"If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nFor accounts managed by Oracle, check DBMS settings to determine if accounts are automatically disabled by the system after 35 days of inactivity. \n\nIn Oracle 12c, Oracle introduced a new security parameter in the profile called INACTIVE_ACCOUNT_TIME. This parameter specifies the number of days permitted the account will be in OPEN state since the last login, after that will be LOCKED if no successful logins happens after the specified duration.\n\nCheck to verify what profile each user is associated with, if any, with this query:\n\nselect username, profile from dba_users order by 1,2;\n\nThen, check the profile to verify what the inactive_account_time is set to in the table dba_profiles; the inactive_account_time is a value stored in the LIMIT column, and identified by the value inactive_account_time in the RESOURCE_NAME column.\n\nSQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'INACTIVE_ACCOUNT_TIME';\n\nIf the INACTIVE_ACCOUNT_TIME parameter is set to UNLIMITED (default) or it is set to more than 35 days, this is a finding.\n\nIf INACTIVE_ACCOUNT_TIME is not a parameter associated with the profile, then check for a script or an automated job that is run daily that checks the audit trail or to ensure every user account has logged in within the last 35 days. If one is not present, this is a finding.","fixText":"For accounts managed by Oracle, issue the statement:\n\nALTER PROFILE profile_name LIMIT inactive_account_time 35;\n\nOr\n\nChange the profile for the DBMS account to ORA_STIG_PROFILE (which has the inactive_account_time parameter set to 35):\n\nALTER USER user_name PROFILE ora_stig_profile;\n\nAn alternate method is to create a script or store procedure that runs once a day.\n\nWrite a SQL statement to determine accounts that have not logged in within 35 days:\n\nExample:\nselect username from dba_audit_trail where action_name = 'LOGON'\ngroup by username having max(timestamp) < sysdate - 36\n\nThen, disable all accounts that have not logged in within 35 days.","ccis":["CCI-003627"]},{"vulnId":"V-270552","ruleId":"SV-270552r1064934_rule","severity":"medium","ruleTitle":"Oracle Database default demonstration and sample databases, database objects, and applications must be removed.","description":"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).\n\nIt 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.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration 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 database management system (DBMS) and host system.","checkContent":"If Oracle is hosted on a server that does not support production systems, and is designated for the deployment of samples and demonstrations, this is Not Applicable.\n\nReview documentation and websites from Oracle and any other relevant vendors for vendor-provided demonstration or sample databases, database applications, schemas, objects, and files.\n\nReview the Oracle DBMS to determine if any of the demonstration and sample databases, schemas, database applications, or files are installed in the database or are included with the DBMS application. If any are present in the database or are included with the DBMS application, this is a finding.\n\nThe Oracle Default Sample Schema User Accounts are:\n\nBI: Owns the Business Intelligence schema included in the Oracle Sample Schemas.\n\nHR: Manages the Human Resources schema. Schema stores information about the employees and the facilities of the company.\n\nOE: Manages the Order Entry schema. Schema stores product inventories and sales of the company's products through various channels.\n\nPM: Manages the Product Media schema. Schema contains descriptions and detailed information about each product sold by the company.\n\nIX: Manages the Information Exchange schema. Schema manages shipping through business-to-business (B2B) applications database.\n\nSH: Manages the Sales schema. Schema stores statistics to facilitate business decisions.\n\nSCOTT: A demonstration account with a simple schema.\n\nConnect to Oracle as SYSDBA and run the following SQL to check for presence of Oracle Default Sample Schema User Accounts:\n\nselect distinct(username) from dba_users where username in\n('BI','HR','OE','PM','IX','SH','SCOTT');\n\nIf any of the users listed above is returned, it means that there are demo programs installed, and this is a finding.","fixText":"Remove any demonstration and sample databases, database applications, objects, and files from the DBMS.\n\nTo remove an account and all objects owned by that account (using BI as an example):\n\nDROP USER BI CASCADE;\n\nTo remove objects without removing their owner, use the appropriate DROP statement (DROP TABLE, DROP VIEW, etc.).","ccis":["CCI-000381"]},{"vulnId":"V-270553","ruleId":"SV-270553r1064937_rule","severity":"medium","ruleTitle":"Unused database components, database management system (DBMS) software, and database objects must be removed.","description":"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).\n\nIt 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.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration 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 database management system (DBMS) and host system.\n\nUnused 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.","checkContent":"Run this query to produce a list of components and features installed with the database:\n\nSELECT comp_id, comp_name, version, status from dba_registry\nWHERE comp_id not in ('CATJAVA','CATALOG','CATPROC','SDO','DV','XDB')\nAND status <> 'OPTION OFF';\n\nReview the list. If unused components are installed and are not documented and authorized, this is a finding.","fixText":"If any components are required for operation of applications that will be accessing the DBMS, include them in the system documentation.\n\nComponents cannot be removed via Database Configuration Assistant (DBCA) or manually once the database has been created, either from a container or a noncontainer database.\n\nHowever DBCA can be used to create a noncontainer database and remove components during the creation process before the database is created.\n\nWhen using DBCA to create a custom noncontainer database, select:\ncreation mode = advanced\nDatabase Template = Custom\nDatabase Options..Database Component\n\nComponents that can be selected or deselected are Oracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle Label Security, Oracle Application Express, and Oracle Database Vault.\n\nFor a container database (CDB), the CDB$ROOT must have all possible database components available. When a pluggable database (PDB) is plugged into the CDB, the CDB must have the same components installed as the PDB. Since it is unknown what components the PDBS may have, the CDB must be able to support all possible PDB configurations.\n\nComponents installed in the CDB$ROOT do not need to be licensed. Components are only considered to be used if they are installed in the PDB.\n\nTo configure a PDB to only use specific components:\n\n1. Create a non-CDB 19.0 database and configure that database with the components desired.\n\n2. Plug the non-CDB database into a CDB database, creating a new PDB. Then if desired, create additional clones from the new PDB.","ccis":["CCI-000381"]},{"vulnId":"V-270554","ruleId":"SV-270554r1065221_rule","severity":"medium","ruleTitle":"Unused database components that are integrated in the database management system (DBMS) and cannot be uninstalled must be disabled.","description":"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).\n\nIt is detrimental for applications to provide, or install by default, any 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.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused, 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.","checkContent":"Run this query to check to verify what integrated components are installed in the database:\n\nSELECT parameter, value\nfrom v$option\nwhere parameter in \n(\n'Data Mining',\n'Oracle Database Extensions for .NET',\n'OLAP',\n'Partitioning',\n'Real Application Testing'\n);\n\nThis will return all of the relevant database options and their status. TRUE means that the option is installed. If the option is not installed, the option will be set to FALSE.\n\nReview the options and check the system documentation to verify what is required. If all listed components are authorized to be in use, this is not a finding.\n\nIf any unused components or features are listed by the query as TRUE, this is a finding.","fixText":"In the system documentation list the integrated components required for operation of applications that will be accessing the DBMS.\n\nFor Oracle Database 12.1 and higher, only the following components can be enabled/disabled:\n\nOracle Data Mining (dm)\nOracle Database Extensions for .NET (ode_net)\nOracle OLAP (olap)\nOracle Partitioning (partitioning)\nReal Application Testing (rat)\n\nUse the chopt utility (an Oracle-supplied operating system command that resides in the /bin directory) to disable each option that should not be available. The command format is \nchopt